Why is this MASQUERADE rule necessary?

Question

I currently have a VPN site-to-site setup where a Centos7 Server is set up as a VPN client to the tunnel at a remote site. The tunnel is established fine and I am trying to access resources at the remote site through the tunnel, but so far I cannot ping anything besides the VPN client itself, nothing behind it.

The remote site VPN client (centos7 server) can ping and access resources but clients behind the VPN client firewall cannot.

Setup:

MAIN SITE: Router/Firewall: 192.168.150.1 (running openvpn/sophos firewall)

CLIENT SITE: Centos7 Server 192.168.200.1 (eth0 address) / 192.168.201.1 (tun0 address)

A client at the main site (say 192.168.150.2) can ping 192.168.200.1 and 192.168.201.2. but not 192.168.200.50 (a resource at the client site).

On the client site I have the following direct rules in place in firewalld:

ipv4 filter FORWARD 0 -i tun0 -o eth0 -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
ipv4 filter FORWARD 0 -i eth0 -o tun0 -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

ipv4 forwarding has been enabled in the kernel. Each interface is in its own zone in firewalld.

Adding THIS RULE fixes the problem, and connectivity is established. But WHY? I don't want anything NAT'd.

ipv4 nat POSTROUTING 0 -o eth0 -j MASQUERADE

Answer 1

From the complete description I can guess that on "main site" everything goes well and all needed routing stuff is set up properly. The "issue" I would see on the host with IP 192.168.200.50 (otherwise just one MASQUERADE rule wouldn't be enough).

This behaviour mean, that once you try to communicate from main site with 192.168.200.50 it is properly route via VPN tunnel to 192.168.201.1 and than to 192.168.200.50 (you can try to catch the traffic on 192.168.200.50 and the most probably you will see incoming data). The problem is with reply. 192.168.200.50 node have no idea how to communicate with 192.168.201.0/x nor 192.168.150.0/y. The result is that the response is routed to default gateway and not reach the destination...

With the NAT rule the traffic seems like originating on 192.168.200.1 so 192.168.200.50 direct it properly back to "VPN GW" where it is "de-NATed" and properly send back via tunnel.

Try to add these rules on 192.168.200.50 (let assume both mask /24):

ip route add 192.168.201.0/24 via 192.168.200.1
ip route add 192.168.150.0/24 via 192.168.200.1

Then retry communication without MASQUERADE rule on 192.168.200.1 and I think it will work as suppose. Good Luck !

-- edit / Sat Jun 22 21:09 UTC 2019 --

Alternatively you can try to add static route on default GW for 192.168.200.0/24 (as VPN is using .1 the GW may be .254 :) ). Then it can be also working as 192.168.200.50 would send it back normally via default GW but it would send it back to "VPN GW"...