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

  • Please also show output from sysctl net.ipv4.ip_forward
    – cryptarch
    Commented Feb 16, 2021 at 23:25
  • You only SNAT through the wlo1 interface. You should SNAT through tun0 as well (assuming your VPN server doesn't know about your internal network).
    – user234931
    Commented Feb 17, 2021 at 11:01
  • this worked. You can post it as an answer ,so that this topic can be closed. Also would you mind clarifying in your answer why did the communication previously only worked partially? I thought it was enough to just forward my network namespace traffic in the default namespace and from then on the VPN configuration will take over and tunnel them appropriately as it does for the rest of the traffic generated in the default namespace. Do you know why this wouldn't work ? Commented Feb 17, 2021 at 11:35

1 Answer 1


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .