Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 1787 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VPN Site-to-site problem

eserzet_01
Hello everyone,

we have a problem. Our customer got two networks 172.16.0.0/16 and 172.18.0.0/16. They need a VPN Tunnel to one server in our network (192.168.x.x/24 direct interface in our ASG7).

The problem is, we already use 172.16.0.0/16 (direct interface in our ASG) as our own LAN. The customer isn't able to do NAT oder masqu whatever.

So which chance do we have to realize this VPN Tunnel?

Thanx for your help!

Greets


This thread was automatically locked due to age.
Parents
  • 0
    Of course you know that the right answer is for you to change your internal LAN if you want to coexist with another LAN though a VPN.  Do you need a VPN for securing the traffic?  If not, then why not use DNAT instead?

    If you must use VPN, then you can SNAT the traffic from your customer to make it appear to be coming from the 'Internal (Address)' of your Astaro; this was the solution that one of our clients needed.  The downside to this is that , if you log traffic on the server, all of the traffic from this customer will now appear to be coming from 'Internal (Address)'.

    Cheers - Bob
  • 0 in reply to BAlfson
    Of course you know that the right answer is for you to change your internal LAN if you want to coexist with another LAN though a VPN.  Do you need a VPN for securing the traffic?  If not, then why not use DNAT instead?

    If you must use VPN, then you can SNAT the traffic from your customer to make it appear to be coming from the 'Internal (Address)' of your Astaro; this was the solution that one of our clients needed.  The downside to this is that , if you log traffic on the server, all of the traffic from this customer will now appear to be coming from 'Internal (Address)'.

    Cheers - Bob


    Unfortunately we need to secure the traffic, so DNAT without VPN is no option. [:(]

    So if I understand you right, I have to change in the Remote Gateway section of this VPN connection the remote network to one or two unused networks by us (which arent really exist, therefore fictive). And after that I have to create an SNAT for all traffic from 172.16 and 172.18 will turn into the fictive net ???

    And if this is right won't it bother our own 172. LAN connections to other interfaces (networks)?

    Thanks
  • 0 in reply to eserzet_01
    You know, the more I think about this, the more I think we chose that solution for a different reason.  In any case, your situation is different because you want to establish a site-to-site connection.  I apologize for my mistake.  I'll be back in a few minutes with the solution we used for your precise problem.

    Cheers - Bob
  • 0 in reply to BAlfson
    There may be a more-elegant solution, but this is what we came up with.

    1. Establish a "phantom" 'Additional Address' on the Internal interface of the Astaro.  This should be an address in something like 172.17.0.0/16.

    2. Create a DNAT rule:
    Source: 'Any'
    Service: 'Any'
    Destination: [the phantom address from step 1]
    Destination Translation: [the internal IP of your server]

    Don't specify a 'Service Translation' and we recommend that you create your own, explicit packet filter rules.

    Your customer will access the server at the phantom address you created.

    If that doesn't resolve your problem, then we should consider changing the definition of the site-to-site VPN.

    Please let us know.

    Cheers - Bob
  • 0 in reply to BAlfson
    There may be a more-elegant solution, but this is what we came up with.

    1. Establish a "phantom" 'Additional Address' on the Internal interface of the Astaro.  This should be an address in something like 172.17.0.0/16.

    2. Create a DNAT rule:
    Source: 'Any'
    Service: 'Any'
    Destination: [the phantom address from step 1]
    Destination Translation: [the internal IP of your server]

    Don't specify a 'Service Translation' and we recommend that you create your own, explicit packet filter rules.

    Your customer will access the server at the phantom address you created.

    If that doesn't resolve your problem, then we should consider changing the definition of the site-to-site VPN.

    Please let us know.

    Cheers - Bob


    Sorry for my late answer!

    Here a little description about my first try of building the tunnel:

    Local Networks  Remote Networks
    192.168.x.x/24  172.16.0.0/16
    192.168.x.x/24  172.18.0.0/16

    Here is the routing problem with our own 172.16.0.0/16 network. This tunnel would kill my own network communication. 

    So with your solution the tunnel would be shown as:

    Local Networks  Remote Networks
    172.17.0.0/16  172.16.0.0./16
    172.17.0.0/16  172.18.0.0/16

    If you can see, as I understand you right, there will be persist my problem, because they're coming still from the 172.16.0.0/16 net.

    ???

    Thank you for your offer that could I write to you in German, but I think in here it is better for all of us to stay (to try) in English! [;)]

    Cheers
  • 0 in reply to eserzet_01
    If you have a problem, then I suspect an error in your Remote Gateway definition.  The Remote Network should have a completely different definition like 10.1.1.44.

    Traffic to 172.16.0.0/16 stays inside the network requesting that address whether it is the client's or yours.  The problem is that the client network can't see your server.  This is a trick to get the client to see your server at a different address.  It's a DNAT from an internal interface instead of an external.

    Try it, and you'll see that it works.

    Cheers - Bob
  • 0 in reply to BAlfson
    If you have a problem, then I suspect an error in your Remote Gateway definition.  The Remote Network should have a completely different definition like 10.1.1.44.


    Yes I have a problem: In the moment I define the remote network as 172.16.0.0/16 and click apply, my own 172.16.0.0/16 clients stop communicate correctly, because the ASG fill in a new route before my existing route for 172.16.0.0/16 to the new tunnel device. So after this I got two routes for 172.16.0.0/16 net.

    I think maybe we are talking past each other!?


    Traffic to 172.16.0.0/16 stays inside the network requesting that address whether it is the client's or yours.  The problem is that the client network can't see your server.  This is a trick to get the client to see your server at a different address.  It's a DNAT from an internal interface instead of an external.


    Sorry I just don't see the trick. Maybe you can make a little chart? [8-)]

    My whole network situation (my side):

    eth0 172.16.0.0/16 (my own local network)
    eth15 192.168.10.0/24 (device for the server which our customer have to access)
    eth16 Internet

    Customers situation/side:
    there local lan's
    172.16.0.0/16
    172.18.0.0/16 (these two networks have to access 192.168.10.2)


    Greets

    PS: There is no way, unless our customer change its network 172.16.0.0/16, right?
  • 0 in reply to eserzet_01
    Your 'Site-to-Site IPSec tunnel status' should look like:

    SA: 192.168.10.2/32=[your public IP]  [client's public IP]=10.1.1.44/32 

  • 0 in reply to BAlfson
    Your 'Site-to-Site IPSec tunnel status' should look like:

    SA: 192.168.10.2/32=[your public IP]  [client's public IP]=10.1.1.44/32 



    OK thank you, in the meantime our customer decided to buy us a seperate VPN router for their connections to us... This works too [;)]

    Bye
Reply
  • 0 in reply to BAlfson
    Your 'Site-to-Site IPSec tunnel status' should look like:

    SA: 192.168.10.2/32=[your public IP]  [client's public IP]=10.1.1.44/32 



    OK thank you, in the meantime our customer decided to buy us a seperate VPN router for their connections to us... This works too [;)]

    Bye
Children
No Data