VPN Site-to-site problem

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

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

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

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

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

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

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

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?

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 

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