Unix & Linux
networking openvpn network-namespaces
Updated Fri, 20 May 2022 10:27:03 GMT

Network namespace doesn't work with vpn

I have created a network namespace (named ppn) to run certain application in it. This works perfectly but when my commercial VPN (based on OpenVPN) is also enabled it seems that the traffic is only unidirectional.

For the creation of the network namespace, this logic was followed (also same ip addresses used): https://askubuntu.com/a/499850/820897

When VPN is disabled pinging from the network namespace works normally:

sudo ip netns exec ppn ping

When VPN is enabled though, I get no ICMP echo replies although tcpdump -i tun0 host logs the ICMP echo requests.

Below you find my iptables and ip route lists:

  • wlo1 is on
  • tun0 is on

sudo iptables -S

-A INPUT -s -i wlo1 -j ACCEPT
-A INPUT -s -i enp5s0 -j ACCEPT
-A INPUT -i wlo1 -j DROP
-A INPUT -i enp5s0 -j DROP
-A OUTPUT -d -o wlo1 -j ACCEPT
-A OUTPUT -d -o enp5s0 -j ACCEPT
-A OUTPUT -o wlo1 -j DROP
-A OUTPUT -o enp5s0 -j DROP

sudo iptables -t nat -S

-A POSTROUTING -s -o wlo1 -j SNAT --to-source

ip route via dev tun0 
default via dev wlo1 proto dhcp metric 600 via dev wlo1 dev tun0 proto kernel scope link src via dev tun0 dev tun0 scope link metric 1000 dev wlo1 proto kernel scope link src metric 600 dev veth-b proto kernel scope link src 

sudo ip netns exec ppn ip route

default via dev veth-a dev veth-a proto kernel scope link src

How could I make the network namespace functional also under VPN ?


sysctl net.ipv4.ip_forward = 1 in my system


When packets leave the network namespace they have (in your case) a source address in the Locally, routing back into the network namespace work just fine, but once the packets leave your local system, you need to translate this source address into an address your next-hop/gateway knows how to route back to you.

This is what -j SNAT does in the POSTROUTING chain in the nat table. However, in your case, you only SNAT packets leaving the wlo1 interface. This is why routing via wlo1 works fine, but via tun0 (the VPN interface) fails.

When packets are routed through tun0, they still have a source address in the, and your VPN server does not know how to return packets from this source address.

To resolve this, you need to SNAT packets leaving the tun0-interface. Simplest option here (since the glue net addresses usually are dynamic) is to use the -j MASQUERADE target:

iptables -A POSTROUTING -t nat -s -o tun0 -j MASQUERADE

External Links

External links referenced by this document: