In the previous article, we followed a packet through a VPN tunnel and saw how WireGuard encrypts and encapsulates our traffic before sending it over the physical network.
But there’s one question we left unanswered.
What happens if the VPN connection suddenly goes down?
Under normal circumstances, Linux can reach the internet through our physical network interface. If the VPN tunnel disappears, what’s stopping Linux from simply using that interface again and sending our traffic outside the VPN?
That’s the problem a VPN kill switch is designed to solve.
In this final part of our Networking in Linux series, we’re going to investigate how Proton VPN’s Standard Kill Switch works under the hood.
We’ll look at what happens when the VPN server becomes unreachable, when the tunnel interface disappears unexpectedly, and when we deliberately disconnect from the VPN.
Along the way, we’ll examine a few Linux routing tables and network interfaces to understand how the kill switch prevents our internet traffic from falling back to the physical network.
Let’s get started.
The Kill Switch Interface
We’re using Proton VPN on Fedora Linux, with the Standard Kill Switch enabled. If you haven’t installed Proton VPN yet, you can download it here.
Let’s start by looking at the network interfaces on our machine.
$ ip -br addr
enp2s0 UP 172.16.1.14/24
wlp3s0 UP 192.168.8.53/24
proton0 UNKNOWN 10.2.0.2/32
pvpnksintrf0 UNKNOWN 100.85.0.1/24We already know proton0 from our previous articles. It’s the WireGuard tunnel interface through which our VPN traffic travels.
But there’s another interface here: pvpnksintrf0.
This is a dummy interface created by Proton VPN’s kill switch. Unlike our Ethernet interface or WireGuard tunnel, it doesn’t provide a path to another network. It’s effectively a dead end for packets routed through it.
Why would we want that?
Let’s look at our routing table.
$ ip route
default via 100.85.0.1 dev pvpnksintrf0 metric 98
default via 172.16.1.1 dev enp2s0 metric 100
default via 192.168.8.1 dev wlp3s0 metric 600Notice something interesting.
Our Ethernet and Wi-Fi connections both have valid default routes to the internet. But Proton VPN has installed another default route through pvpnksintrf0, with a metric of 98.
Linux prefers the default route with the lowest metric, so this dummy route takes priority over Ethernet (100) and Wi-Fi (600).
Does that mean our internet traffic is being discarded even while the VPN is connected?
Not quite.
As we explored in the first article, Proton VPN also uses policy routing to direct ordinary internet traffic through proton0. That routing decision happens before the system falls back to the default route through our dummy interface.
We can confirm this:
$ ip route get 1.1.1.1
1.1.1.1 dev proton0 table 245447468 src 10.2.0.2Our packet is still going through the VPN tunnel.
The dummy interface is there as a safety net. If the VPN tunnel disappears and its policy routes are removed, the preferred default route still points to pvpnksintrf0 rather than our physical network.
Instead of sending ordinary internet traffic directly through Ethernet, Linux sends it into a dead end.
That’s the basic idea behind the Standard Kill Switch on our Linux system.
A quick word From our Sponsor
This article is made possible by Proton VPN.
Proton VPN has apps for Linux, Windows, macOS, Android, iOS, and more, plus a Linux CLI for those who prefer the terminal. Its apps are open source and independently audited, and it supports multiple VPN protocols, including WireGuard, OpenVPN, and its own Stealth protocol.
Proton has also provided an exclusive discount for SYSXPLORE readers:65% off the 2-year VPN Plus plan or 55% off the 1-year VPN Plus plan when you sign up through the link below.
If the link doesn’t open, your ad blocker may be blocking it. Temporarily disable it and try again.
Now, let’s see what happens when things start going wrong.
What Happens When the VPN Server Becomes Unreachable?
Let’s start with a common failure scenario.
Our VPN is connected, everything is working normally, and then the VPN server suddenly stops responding.
You might expect Linux to notice the connection failure, abandon the tunnel, and start sending traffic through Ethernet.
But that’s not what happens.
To simulate this, we can temporarily block outgoing WireGuard traffic to our VPN server using an nftables rule.
sudo nft add table inet vpn_test
sudo nft 'add chain inet vpn_test output { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpn_test output ip daddr 31.13.189.226 udp dport 443 dropThis prevents our machine from reaching the VPN server (31.13.189.226) over its WireGuard transport connection, without deliberately disconnecting the VPN.
Now, here’s the interesting part.
Even though the server is unreachable, the proton0 interface remains available, and Linux continues routing ordinary internet traffic through it.
$ ip route get 1.1.1.1
1.1.1.1 dev proton0 table 245447468 src 10.2.0.2From Linux’s perspective, the route still exists. WireGuard continues accepting packets, encrypting them, and attempting to send them through the tunnel.
But because communication with the server is blocked, those packets cannot reach their destination.
The result? Our internet connection stops working.
Importantly, Linux doesn’t automatically switch to the Ethernet default route simply because the VPN server isn’t responding.
And that’s an important distinction: a VPN server becoming unreachable isn’t the same thing as the VPN interface disappearing.
In this scenario, the tunnel remains configured, so our traffic continues to follow the VPN route, even though the connection is effectively broken.
But what happens if the VPN connection itself is deactivated and its routes disappear?
That’s where our dummy interface becomes particularly useful.
When the VPN Connection Disappears
Now let’s take things a step further.
Instead of making the VPN server unreachable, what happens if the VPN connection itself is deactivated?
To find out, we can use NetworkManager to bring down the WireGuard connection without issuing a normal disconnect command through Proton VPN.
sudo nmcli connection down proton0This removes the active VPN connection, including the routing rules that previously directed our internet traffic through proton0.
Under normal circumstances, Linux would fall back to another available default route, such as the one through enp2s0.
But remember the dummy interface we discovered earlier?
Let’s see where Linux sends our traffic now.
$ ip route get 1.1.1.1
1.1.1.1 via 100.85.0.1 dev pvpnksintrf0There it is.
With the VPN routing rules gone, Linux consults its main routing table. And because the dummy interface has a lower default-route metric than Ethernet or Wi-Fi, it becomes the preferred path.
But pvpnksintrf0 doesn’t actually forward packets anywhere.
So what happens to the traffic?
Any ordinary internet traffic that would otherwise fall back to Ethernet or Wi-Fi is instead directed to pvpnksintrf0, where it gets dropped.
The same fallback protection applies to IPv6 traffic.
In other words, Linux still has working physical network connections and valid gateways, but ordinary internet traffic is being directed into an interface that can’t deliver it.
That’s the kill switch doing its job.
And notice that we don’t need to block every destination with individual firewall rules. In this implementation, Proton VPN uses Linux’s existing routing mechanisms to prevent ordinary internet traffic from falling back to the physical network.
As long as that dummy default route remains in place, losing the VPN tunnel doesn’t automatically mean losing the protection.
But what if the WireGuard interface itself is deleted?
Let’s find out.
What Happens If the VPN Interface Is Deleted?
So far, we’ve seen what happens when the VPN server becomes unreachable and when the VPN connection is deactivated.
But let’s try something different.
What if the WireGuard interface itself suddenly disappears?
We can simulate this by deleting proton0 directly:
sudo ip link delete proton0Unlike the previous scenario, we’re not asking NetworkManager to deactivate the VPN connection. We’re removing the network interface underneath it.
You might expect the VPN to remain broken until we manually reconnect.
But something interesting happens.
NetworkManager detects that the interface has disappeared and automatically recreates proton0.
During that brief interruption, traffic that would otherwise fall back to our physical network is directed to the dummy interface, where it gets dropped.
Here’s how it works:
The
proton0interface disappears.Traffic temporarily loses its route through the VPN tunnel.
The dummy interface catches packets during the interruption.
NetworkManager recreates
proton0, restoring the VPN route.
The important part isn’t how quickly NetworkManager recreates the interface.
It’s what happens between the interface disappearing and coming back.
Our ordinary internet traffic doesn’t fall back to Ethernet. The dummy route provides a dead end while the VPN connection is being restored.
This is exactly the kind of unexpected interruption a kill switch is designed to handle.
But there’s one final scenario we haven’t explored.
What happens when we intentionally disconnect from Proton VPN?
Does the kill switch continue blocking our internet connection?
What Happens When We Disconnect Intentionally?
There’s one important distinction we need to make.
So far, we’ve been looking at unexpected VPN connection failures.
But what happens when we disconnect normally?
Let’s try it using Proton VPN’s CLI.
protonvpn disconnectThis time, the behavior is different.
Proton VPN removes the WireGuard connection and the dummy interface used by its Standard Kill Switch.
With proton0 and pvpnksintrf0 gone, Linux can once again use the default route through our physical network interface.
$ ip route get 1.1.1.1
1.1.1.1 via 172.16.1.1 dev enp2s0Our normal internet connectivity is restored.
And that’s intentional.
Proton VPN’s Standard Kill Switch is designed to prevent accidental exposure when the VPN connection fails unexpectedly. It isn’t meant to keep your internet connection blocked after you’ve deliberately disconnected from the VPN.
Proton VPN also offers an Advanced Kill Switch, which can continue blocking internet access even when the VPN is manually disconnected. That provides a different level of protection, but it’s beyond the scope of this guide.
And with that, we’ve seen how the Standard Kill Switch behaves across several different scenarios: a healthy VPN connection, an unreachable server, a deactivated tunnel, a deleted interface, and finally, an intentional disconnect.
Putting It All Together
So, what have we learned?
A VPN kill switch doesn’t necessarily need to inspect every packet or block traffic using firewall rules.
As we’ve seen with Proton VPN’s Standard Kill Switch on Linux, routing alone can provide an effective way to prevent ordinary internet traffic from escaping when the VPN connection fails.
When the VPN is connected, policy routing directs our traffic through proton0. If the VPN server becomes unreachable, that traffic continues following the tunnel route rather than automatically switching to Ethernet.
And if the VPN connection disappears entirely, the dummy interface pvpnksintrf0 provides a fallback route that leads nowhere.
That’s the clever part.
Instead of removing our physical internet connection, the kill switch changes where Linux tries to send our traffic.
Our Ethernet and Wi-Fi interfaces can remain connected, and their gateways can still be reachable. But ordinary internet traffic won’t simply fall back to those interfaces when the VPN fails.
And when we intentionally disconnect, Proton VPN removes the Standard Kill Switch and restores normal routing.
Of course, this doesn’t mean every VPN implements its kill switch in exactly the same way. Some rely on firewall rules, while others use routing mechanisms or a combination of both.
But the underlying goal remains the same: prevent traffic that should travel through the VPN from accidentally leaving through an unprotected connection.
And that brings us to the end of our three-part VPNs In Linux series.
We started by exploring how VPN tunnels work, followed a packet through the tunnel to understand encapsulation and encryption, and finally investigated what happens when that tunnel fails.
Hopefully, the next time you connect to a VPN, you’ll have a much clearer picture of what’s happening underneath.
Thanks for reading, and keep exploring!