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 220.127.116.11 from the network namespace works normally:
sudo ip netns exec ppn ping 18.104.22.168
When VPN is enabled though, I get no ICMP echo replies although
tcpdump -i tun0 host 22.214.171.124 logs the ICMP echo requests.
Below you find my iptables and ip route lists:
sudo iptables -S
-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -s 126.96.36.199/32 -i wlo1 -j ACCEPT -A INPUT -s 188.8.131.52/32 -i enp5s0 -j ACCEPT -A INPUT -i wlo1 -j DROP -A INPUT -i enp5s0 -j DROP -A OUTPUT -d 184.108.40.206/32 -o wlo1 -j ACCEPT -A OUTPUT -d 220.127.116.11/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
0.0.0.0/1 via 10.8.1.1 dev tun0 default via 192.168.2.1 dev wlo1 proto dhcp metric 600 18.104.22.168 via 192.168.2.1 dev wlo1 10.8.1.0/24 dev tun0 proto kernel scope link src 10.8.1.12 22.214.171.124/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 ?
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
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
External links referenced by this document: