2

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

3
  • 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

0

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

You must log in to answer this question.

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