Network namespace doesn't work with vpn

Question

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 8.8.8.8 from the network namespace works normally:

sudo ip netns exec ppn ping 8.8.8.8

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

Below you find my iptables and ip route lists:

• wlo1 is on 192.168.2.106
• tun0 is on 10.8.1.12

sudo iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -s 5.180.62.60/32 -i wlo1 -j ACCEPT
-A INPUT -s 5.180.62.60/32 -i enp5s0 -j ACCEPT
-A INPUT -i wlo1 -j DROP
-A INPUT -i enp5s0 -j DROP
-A OUTPUT -d 5.180.62.60/32 -o wlo1 -j ACCEPT
-A OUTPUT -d 5.180.62.60/32 -o enp5s0 -j ACCEPT
-A OUTPUT -o wlo1 -j DROP
-A OUTPUT -o enp5s0 -j DROP

sudo iptables -t nat -S

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 192.168.163.0/24 -o wlo1 -j SNAT --to-source 192.168.2.106

ip route

0.0.0.0/1 via 10.8.1.1 dev tun0 
default via 192.168.2.1 dev wlo1 proto dhcp metric 600 
5.180.62.60 via 192.168.2.1 dev wlo1 
10.8.1.0/24 dev tun0 proto kernel scope link src 10.8.1.12 
128.0.0.0/1 via 10.8.1.1 dev tun0 
169.254.0.0/16 dev tun0 scope link metric 1000 
192.168.2.0/24 dev wlo1 proto kernel scope link src 192.168.2.106 metric 600 
192.168.163.0/24 dev veth-b proto kernel scope link src 192.168.163.254 

sudo ip netns exec ppn ip route

default via 192.168.163.254 dev veth-a 
192.168.163.0/24 dev veth-a proto kernel scope link src 192.168.163.1

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

-------EDIT-------

sysctl net.ipv4.ip_forward = 1 in my system

Answer 1

When packets leave the network namespace they have (in your case) a source address in the 192.168.163.0/24-network. 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 192.168.163.0/24-network, 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 192.168.163.0/24 -o tun0 -j MASQUERADE