iptables / route for returning incoming traffic back out of originating interface (eth0)

Question

I'm just getting started with tinkering with Linux / IPTABLES and following this great tutorial here to successfully setup a RaspBerry Pi device (running RaspBerryPi OS / Debian) as a VPN Gateway. Any device on the same network can manually configure their network settings and set their routing to the IP address of the device, which will then process the information via VPN and then send it back (all from the same eth0 interface).

The problem I'm having is the VPN software NordVPN for Linux removes the tun0 interface automatically when I disconnect / logout from VPN, resulting in internet no longer working on the laptop. I understand that this is due to the packets are still being told to forward, and if the tun0 interface doesn't exist those packets have no way to return to the laptop.

What would be the ideal procedure to simply return all incoming traffic on eth0 back out to eth0 when tun0 doesn't exist?

Structure:

Eg: laptop → raspBerry pi (eth0 > tun0 > eth0) → laptop

The iptables on the RaspBerry Pi are as follows:

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

sudo iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

sudo iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

sudo iptables -A INPUT -i lo -j ACCEPT

sudo iptables -A INPUT -i eth0 -p icmp -j ACCEPT

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

sudo iptables -P FORWARD DROP
sudo iptables -P INPUT DROP

So far my research has pointed me to a couple answers:

https://unix.stackexchange.com/a/322386

Always Forward Traffic Out The Interface It Originated On

Maybe something like: ip route add table 2 default via 192.168.0.1 (ip address of my main router?) however I have not tried this yet and not fully sure if this is the direction I should be headed.

Answer 1

Correcting a common misconception: iptables doesn't route. It just controls if routed flows are allowed to proceed or not, but doesn't change their direction (unless using things like NAT which can change the routing fate, still done by the routing stack). That's why the most important thing in the question should be to provide the routes and routing tables (and for this case it looks like the routing rules should have been provided too).

Once the tunnel interface disappears, all routes using it will disappear too. You're getting a router routing on its single interface: its ingress interface is also its egress interface: eth0.

You just need to enable the flow with iptables, since its default policy is to drop forwarded packets:

sudo iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT

and that's about all you need. Normally your RPi has already its default route set to use the 192.168.0.1 router so there's nothing else to do. If the routes aren't standard, they'll have to be added in the question and this answer updated.

Below are the fine prints:

• When a host node sends packets through the RPi, the RPi will detect it's not an optimal route and will send back a few ICMP redirect packets to warn the client that a more direct route is available: through 192.168.0.1 directly. The node can choose to cache the information and send its next packets directly to that router, or can keep using the RPi, which will anyway also keep forwarding these packets. The actual router will most certainly send replies back directly to the host node, creating an asymmetric route. As it's all happening in the same LAN and thus with the same interface this should be fine and not trigger things like Strict Reverse Path Forwarding anywhere.

• For this reason, you should not use additional conntrack rules in this case (those in place are fine). -m conntrack --ctstate NEW,ESTABLISHED is not equivalent to all packets, because from the point of view of conntrack there will be out of window TCP packets caused by the packets bypassing the RPi, that would be tagged INVALID instead (but must be allowed to be forwarded).

Answer 2

I hate answers like this, but here I go. You seem to be using the more 'classic', openVPN-based NordVPN connection. Did you know that the wireguard tunnel format is possible?

Your connection is tunnels, not ethertap, so your connection could be a good candidate.

Benefits:

• I think the tunnel device (wg0 here) doesn't drop if your tunnel is down
• The 'do this or else use that' kind of routing (and DNS) decisions are configured trivially as part of the wireguard setup.

I don't mean to be 'that guy', so I'm sorry that I may appear so. I felt that if you're just starting our with NordVPN as a new connection that it's a perfect opportunity to ensure you've seen the other option and still decided that the openVPN setup is the way to go. Having just started playing with WG instead of VTun (the parent project James left because he didn't want to implement the stuff he implemented anyway in openVPN) I have found it configures at least as easily as OpenVPN if not more easily, and seems to give me a fast and reliable tunnel set.

Having said that, I DID set up a 'send return packets out the same interface they came in' config for a multi-homed proxy droid, which is a challenge on Linux because, unlike Windows that does this by default, the linux kernel itself doesn't remember how a packet came in, usually -- and we have to trick it with some iproute trickery. I'll see if I can find the notes from about 10 years back (early CentOS6) when that box was originally set up.