4 ms·

Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services of

Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services offered by the OS. On some popular OS like mobile ones it's just not possible at all. So just to grab an example, NordVPN's implementation does indeed work as the article presents: it monitors the VPN and disables network access for applications if the VPN connection drops. This is indeed vulnerable to any number of potential problems, and depending on the OS and user savvy you can set up better protection using e.g. the iptables owner module. It's very non-portable though, sometimes even between Linux distributions, and hard to support at scale. Actually I'd say a true "no access except through the VPN" rule is easiest to implement on Windows, but NordVPN doesn't seem to do it there either, I'm not sure why. To be fair, it's right in the name: a kill switch is a switch that kills things. It isn't proper network policy like per-process routing tables that are, unfortunately, difficult to implement for consumer machines.

0x457 2y ago
Let's be honest, there're 2 OSs on desktop that matter to VPN providers that provide "all-in-one app" - Windows and macOS. Both have easy to configure from your application. On linux, well, you have to choose: - use iptables style rules regardless of the backend or - use nftables style rules regardless of the backend. So it's 3 firewalls that you have to think about. On mobile, well, on mobile you're mostly at the mercy of the platform owner and generally can't do much. Hence, why connecting phone to "SoftAP/ether_g + VPN" device is better than a direct connection.
banister 2y ago
Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :) On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord really works like this i have an even lower opinion of them than i do currently). On linux - iptables (for example) - just implement a general DROP policy then override with a specific ALLOW on the tunnel interface. On Windows - Use WFP to implement a block everything rule, then provide a higher priority rule to allow on the tunnel interface. All three of these techniques are the recommended way to implement a kill switch and it's used heavily in the VPN industry by anyone sensible. It completely defends against this TunnelVision exploit too. The way that you suggest kill switch is implemented (reactive and monitoring the connection?) is very fragile, racey and prone to leak, i absolutely would not trust it and it shouldn't even be called a kill switch. It's an embarrassment. :)
- jcrawfordor 2y ago
  I'm not saying how it should be implemented, I'm saying how it is implemented by a number of popular VPN services. Take up the argument with them. There are VPN providers that do it right on at least some platforms, but unfortunately the way most document it it's very hard to tell without experimenting with the client to verify. As far as I know, use of the term "kill switch" closely correlates with an untrustworthy implementation. Consider the case of Mullvad who handle this a lot better and also decline to call it a "kill switch" for that reason. And that's not to say that Mullvad is perfect, easy to find forum threads by people who had traffic leakage for various reasons. I wouldn't trust anything you didn't set up yourself.
- Borealid 2y ago
  You wrote three different ways to end up with all traffic dropped and a broken VPN connection. Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic. You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing traffic which is already cloaked by the VPN software (or not cloaked, but used to establish/maintain the tunnel itself). That second category is a bit complicated, because you need to be able to route to the VPN server regardless of which network you're connected to - and the DHCP server tells you how to do that.
  - banister 2y ago
    Yes. I just provided simplified firewall rules in my answer. You also need to whitelist either the VPN endpoint itself (and add a route to that endpoint) or you need to whitelist the process (such as wireguard or openvpn) that hits that endpoint. Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before the VPN comes up. Source: i've implemented this dozens of times (and you probably have too, it sounds like) so let's not quibble over the details ;)
    - Borealid 2y ago

0x457 2y ago

Let's be honest, there're 2 OSs on desktop that matter to VPN providers that provide "all-in-one app" - Windows and macOS. Both have easy to configure from your application. On linux, well, you have to choose: - use iptables style rules regardless of the backend or - use nftables style rules regardless of the backend. So it's 3 firewalls that you have to think about. On mobile, well, on mobile you're mostly at the mercy of the platform owner and generally can't do much. Hence, why connecting phone to "SoftAP/ether_g + VPN" device is better than a direct connection.

banister 2y ago

Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :) On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord really works like this i have an even lower opinion of them than i do currently). On linux - iptables (for example) - just implement a general DROP policy then override with a specific ALLOW on the tunnel interface. On Windows - Use WFP to implement a block everything rule, then provide a higher priority rule to allow on the tunnel interface. All three of these techniques are the recommended way to implement a kill switch and it's used heavily in the VPN industry by anyone sensible. It completely defends against this TunnelVision exploit too. The way that you suggest kill switch is implemented (reactive and monitoring the connection?) is very fragile, racey and prone to leak, i absolutely would not trust it and it shouldn't even be called a kill switch. It's an embarrassment. :)

jcrawfordor 2y ago
I'm not saying how it should be implemented, I'm saying how it is implemented by a number of popular VPN services. Take up the argument with them. There are VPN providers that do it right on at least some platforms, but unfortunately the way most document it it's very hard to tell without experimenting with the client to verify. As far as I know, use of the term "kill switch" closely correlates with an untrustworthy implementation. Consider the case of Mullvad who handle this a lot better and also decline to call it a "kill switch" for that reason. And that's not to say that Mullvad is perfect, easy to find forum threads by people who had traffic leakage for various reasons. I wouldn't trust anything you didn't set up yourself.
Borealid 2y ago
You wrote three different ways to end up with all traffic dropped and a broken VPN connection. Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic. You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing traffic which is already cloaked by the VPN software (or not cloaked, but used to establish/maintain the tunnel itself). That second category is a bit complicated, because you need to be able to route to the VPN server regardless of which network you're connected to - and the DHCP server tells you how to do that.
- banister 2y ago
  Yes. I just provided simplified firewall rules in my answer. You also need to whitelist either the VPN endpoint itself (and add a route to that endpoint) or you need to whitelist the process (such as wireguard or openvpn) that hits that endpoint. Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before the VPN comes up. Source: i've implemented this dozens of times (and you probably have too, it sounds like) so let's not quibble over the details ;)
  - Borealid 2y ago