Verify SNAT Configuration

Question, in the vpn config what have you specified as your "local network"?
only traffic with a source of your local network will go over the vpn tunnel, so if you want the traffic to be coming from your external IP of the asg, this should be the definition you have in your "local network" in the vpn config. 

To check the traffic, you can login to the astaro via ssh and use tcpdump to see if the traffic is going out the ipsec or external interface. I believe you can also check the nat table, but I forget the command ... maybe: iptables -L -t nat

If I disable my SNAT, then it shows traffic in their logs but with my systems internal IP address, not my ASG external address.

That's the way it's supposed to work.  The SNAT can't work with a site-to-site VPN.  Depending on the VPN definition, the packet filter rule may be unnecessary.  What is the reason for wanting your external IP to appear in their logs?

Cheers - Bob

Troy, I was thinking about this.  Although this won't work in your ASG, if you have a fixed internal IP for your system, have you tried having them do a SNAT on their end?

Traffic source: My systems internal IP address
Traffic service: FTP
Traffic destination: Their internal systems IP address
NAT Mode: SNAT
Source: External IP Address of my ASG
Source Service: [If Astaro, always leave this blank when not changing!]

Cheers - Bob

Hi Bob,

I have this problem (not so far from Troy's Issue):

LAN (192.168.0.0 /24) -> ASTARO SG7 SW -> VPN SiteToSite -> Remote Network 

Of course, the real answer is that you should change your IP addresses...

I haven't done this exact thing, but I think the following should give your internal network access to things at the remote site:

Traffic source: Internal (Network)
Traffic service: Any
Traffic destination: [Remote network used in your VPN setup]

NAT Mode: SNAT

Source: [10.34.0.1 = An Additional Address which you have added to your Internal interface]
Source Service: [In Astaro, always leave this blank when not changing!]

Does that solve your issue?

Cheers - Bob

I have already tried this configuration and it doesn't works.

Please, see attached images of my configuration.

What exactly you mean for "An Additional Address which you have added to your Internal interface"?

Thank you very much for your support,
Ethan

The Additional Address should not be a part of the remote network.  If that is 10.34.0.0/24, then choose something like 10.1.0.1.  You will need to add [Additional Address] to 'Local Networks' in your IPsec Connection.

At the remote site, they will need to have 10.1.0.1 in their definition of your network as, I suspect, the "Other Network" already has reserved 192.168.0.0/24.

What I'm not sure of is what will happen when two different devices go through the tunnel after having been SNATted from 10.1.0.1.  I believe that Conntrac should take care of it.  The only downside should be that any IP-tracking in the Remote Network will list an access from any device in your network as coming from 10.1.0.1.

Cheers - Bob

Ethans, and also Troys problem, is solvable.  As Ethans problem is more specific I will explain how to solve this probem then the problem of Troy should be clear, too.

Ethan wants to build a VPN tunnel between two networks with each has the same IP range. Even if the tunnel came up (can be it would come up, have never tested), of course no routing could happen between the networks.

So here´s the trick:

The "real" network on both sides is 192.168.0.0/24
Assume 10.1.1.0/24 and 10.2.2.0/24 are two networks which do not exist on any of the two sides. I will call them the "virtual" networks. Net 10.1.1.0 will be assigned to loc1, net 10.2.2.0 to loc2
The VPN tunnel definitions ("local" and "remote" networks) on both sides have to contain ONLY these two virtual networks - no 192.168.0-Network may be contained on both sides! This will lead to the vpn tunnel comes up without any problems.

Now also the routing is just clear: if someone from location1 (the "client") wants to  initiate a connection to location2 (a "server"), there must be
1) an SNAT rule in loc1
2) a DNAT rule in loc2


Example: 
Client 192.168.0.4 in loc1 wants to make a connection to server 192.168.0.5 in loc2
1) loc1- SNAT rule: src:192.168.0.4 dst:10.2.2.0/24  new src: 10.1.1.4 (for example)
2) loc2-DNAT-rule: src: 10.1.1.4 dst:10.2.2.5  new dst:192.168.2.5

So, the "client" has to contact the "server" with the "virtual-server-ip" 10.2.2.5. The packet goes from client to ASG1, which will SNAT the clients IP (192.168.0.4) to the "virtual-client-ip" 10.1.1.4  and - as this packet matches now the tunnel definition - send it via the VPN to the remote side. The gateway there (hopefully also an ASG...let´s call it asg2) will DNAT the packet to the real servers ip 192.168.0.5.
The reverse packet will be natted vice versa.

Of course, you won´t need a separate SNAT rule for every client in loc1 - if the admin (or the server) in loc2 doesn´t have to have a separate src ip of any client connection. then one SNAT rule for ALL clients would be sufficient.
However, for every separate SERVER in loc2, the asg2 in loc2 wil need a separate DNAT rule. This is one of thevery seldom cases where a "NAT-range" feature would be nie in ASG (instead of creating 100 NAT rules for 100 servers, use 1 rule for range 1 to 100 or so).

This setup  sounds complex but if you only have some few servers on each side which have to be contacted from the other side the setup is just some minutes. It´s proofen in many customer installations.

I agree that Ölm's solution works great.  In Ethan's case, I think my idea might work since the target network (10.34.0.0/24) is not the same as his (192.168.0.0/24).

He needs to show up over the tunnel with an IP that's different from another VPN connected to the target network.  I'm still curious to see if this might work.

Cheers - Bob

Hm, Ethan has written:

>> LAN (192.168.0.0 /24) -> ASTARO SG7 SW -> VPN SiteToSite -> Remote Network