Simplify and orchestrate VPN networking and configuration tasks.
Post Reply
jmccuneBPS
Novice
Posts: 4
Liked: never
Joined: Jan 12, 2011 9:03 pm
Full Name: Jason McCune
Contact:

Traffic going through the tunnel is not preserving source IP address, is there a way to do this?

Post by jmccuneBPS »

I have a working VeeamPN tunnel set up between our main HQ office and a remote site. The primary site is using a subnet of 172.16.0.0/16, and the remote office is using 10.9.0.0/16. I can route traffic between them just fine (I can access resources in the 172.16.x.x network from the 10.9.x.x network, and vice-versa) but it appears that devices on one side of the tunnel can't see the original source LAN IP address of devices on the other side of the tunnel.

For example: I have a server on the remote office side of the tunnel with LAN IP 10.9.12.10. I want to allow this server to send SMTP traffic through our SMTP gateway which is IP 172.16.10.20, which is locked down to only allow SMTP relay from specific systems that I have configured on it. The problem is, the SMTP server sees the source IP as 172.16.10.150, which is the IP of the Veeam PN network hub. So the 10.9 server can route traffic across the VeeamPN appliance correctly, but when it gets to the other end, the 172.16 server thinks the traffic is coming from the Veeam PN hub (which is 172.16.10.150) instead of the source server IP address (which is 10.9.12.10). I don't want to allow traffic for ALL devices that come in through the VPN tunnel, so I need the SMTP relay to see the traffic as coming from the original server, not the VPN appliance.

Is there a way to fix this, and preserve the source IP address, so that devices on the other end of the tunnel see the actual source IP, and not the IP address of the VeeamPN appliance? I was hoping there was a way to tweak IPtables rules in the appliance to make it happen, or maybe there is a setting in the VeeamPN config file that will enable this. I'm not afraid to get in to Linux config files, so if someone can point me in the right direction, that would be a big help!

Thanks!
Jason

AVasilyev
Veeam Software
Posts: 70
Liked: 14 times
Joined: Jan 01, 2006 1:01 am
Contact:

Re: Traffic going through the tunnel is not preserving source IP address, is there a way to do this?

Post by AVasilyev »

Hi Jason,

VeeamPN is implemented as Layer 3 VPN, so to provide two-way site-to-site connectivity it has to do NAT (network address translation). So all addresses get overridden on VPN appliances with valid for other site IP addresses by using masquerading feature of Linux firewall.
Without this "on-the-fly" IP address change the response from the server in another site won't be able to find return path.

For your security tightening I can propose to manually implement filtering on source VeeamPN appliance (allowing access to target address trough VeeamPN for only particular source machines) as I explained in similar article: veeam-tools-for-microsoft-azure-f36/how ... 63684.html
Please make me know if you need more help in writing firewall rules for your particular use case.

Alexey

jmccuneBPS
Novice
Posts: 4
Liked: never
Joined: Jan 12, 2011 9:03 pm
Full Name: Jason McCune
Contact:

Re: Traffic going through the tunnel is not preserving source IP address, is there a way to do this?

Post by jmccuneBPS »

Hello Alexey,

Thank you for your reply!

This isn't making complete sense to me. I have a static route set up in the site with subnet 172.16.x.x, that tells it to send anything destined for 10.9.x.x through the VPN tunnel's LAN IP address. If a device in the 172.16 subnet tries to route to 10.9, it will just get forwarded through the tunnel. The VPN tunnel wouldn't work without this static route. So I don't completely understand the need to re-IP the traffic to a LAN IP address on the other end of the tunnel. Is there a way to turn off the IP masquerading so that the IP address doesn't get changed? I'll see if I can figure out the correct iptables command to make that happen... I was already heading down that path but didn't get too far yet. If you happen to know which one I need to change, that would be great!

I don't really need to do this for security, just so that devices on the other end of the tunnel are seeing the traffic coming from the actual source IP address. I believe this is also preventing our VoIP phones from receiving audio through the tunnel (I only get 1 way audio, but the calls are set up fine).

Thanks,
Jason

bfarmil
Service Provider
Posts: 4
Liked: never
Joined: Mar 28, 2011 9:01 pm
Full Name: Bryce Farmilo
Contact:

Re: Traffic going through the tunnel is not preserving source IP address, is there a way to do this?

Post by bfarmil »

Sorry to bring up an old topic but this is very much the situation I find myself in except that I have found a solution. Unfortunately the solution is temporary.

My use case is that I want to establish a VPN tunnel between two HPE StoreOnce appliances that are being used as repositories for a customers Veeam Backups. The onsite appliance needs to be able to talk to the offsite appliance in a two way fashion so that they can catalyst copy data between them. it is also useful to federate the two StoreOnces. For this to work the IP address that the StoreOnce appears as must be the address it can be connected to. This doesn't work with Veeam PN as it hides the source IP address behind the IP address of the destination Veeam PN appliance. Even if you use NAT that only works in one direction. The destination always sees the originating devices as coming from the IP address of the local Veeam PN appliance.

EXCEPT when I type in this command - "iptables -t nat -D POSTROUTING 1". This removes the IP Masquarade/Hide and the originating IP address is preserved through the Veeam PN appliance to the destination. Everything works perfectly in both directions with routing configured correctly and Veeam PN encapsulating and transferring my traffic between the two sites safely and securely. That is until either end REBOOTS or the VeeamPN Service is restarted and then it breaks until the above command is issued again.

It is definitely the VeeamPN service that is adding the iptables entries to NAT the traffic and while I can understand this can be useful in a Cloud environment where subnet routing is difficult it in my situation I don't want NAT at all and would love to be able to disable it. In truth a simple two way NAT system would be very useful where we have customers with overlapping subnets but that is outside the scope of my expertise at this stage. So my question is

Is there a configuration option that turns off hide NAT for Veeam PN? Is it possible to manipulate the iptables NAT rules within the VeeamPN configuration? What is the recommended/supported way to run commands after the VeeamPN service starts if I am to just issue the command above to achieve a workable solution?

Thanks,
Bryce.

bfarmil
Service Provider
Posts: 4
Liked: never
Joined: Mar 28, 2011 9:01 pm
Full Name: Bryce Farmilo
Contact:

Re: Traffic going through the tunnel is not preserving source IP address, is there a way to do this?

Post by bfarmil »

For those that have been following this thread here is the solution I have come up with. Add the following lines to the /etc/systemd/system/veeampn.service file after the ExecStart= line.

ExecStartPost=/bin/sleep 10
ExecStartPost=/sbin/iptables -t nat -D POSTROUTING 1

This will sleep 10 seconds after the veeampn services are started and then remove the POSTROUTING nat rule. The sleep is required it does not work without it, as for how long the sleep needs to be i'll leave that to someone else with more time on their hands. I can live with 10 and it works :-). You'll need to run 'systemctl daemon-reload' to update the config in memory from the edited file.

Perhaps there is a less brute force way of doing this but it has the beauty of surviving a service stop/start as well as a VM reboot. I expect auto-updating will break this so I need to find a way to stop that next. Perhaps just blocking HTTP from the appliance will be all that is required.

Cheers,
Bryce.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests