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?


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:


Always Forward Traffic Out The Interface It Originated On

Maybe something like: ip route add table 2 default via (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.

2 Answers 2


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 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 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).

  • This works perfectly and makes sense now. Appreciate the thorough explanation!
    – Joe
    Nov 18, 2020 at 20:21

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.


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

  • I'm actually using WireGuard via NordLynx: nordvpn.com/blog/nordlynx-protocol-wireguard The interface reference I had used in my question (tun0) is actually (nordlynx) which is set by using their Linux package: nordvpn.com/download/linux I changed to (tun0) just to make my question clear. I'm sure I'd have more control if I configured manually within WireGuard - Nord is a little controlling with this aspect and I don't believe provide WG profile details, but for a beginner like me who already had a paid account - this made things so much easier to get up and going.
    – Joe
    Nov 19, 2020 at 4:32
  • That's how they do their WG? Argh. But I'm thinking this hack won't work for you either -- because it needs to act on the tun0 interface and assume it's up all the time, I think. It's gotta be something in with your WG config, then, as when that device goes away and tears down the associated routes, you should be awesome with a good route out -- but I think there's a all-via-tunnel WG config that specifically is set to blackhole anything when the wg0 goes down.. Watch the config doesn't remove your default, and adjust the WG config so it doesn't block you any more. Nov 19, 2020 at 8:11

You must log in to answer this question.

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