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.


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

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

A client at the main site (say can ping and but not (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

1 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 (otherwise just one MASQUERADE rule wouldn't be enough).

This behaviour mean, that once you try to communicate from main site with it is properly route via VPN tunnel to and than to (you can try to catch the traffic on and the most probably you will see incoming data). The problem is with reply. node have no idea how to communicate with nor 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 so direct it properly back to "VPN GW" where it is "de-NATed" and properly send back via tunnel.

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

ip route add via
ip route add via

Then retry communication without MASQUERADE rule on 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 (as VPN is using .1 the GW may be .254 :) ). Then it can be also working as would send it back normally via default GW but it would send it back to "VPN GW"...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.