It's really hard to make a robust VPN.
FWIW, I remember reading something similar years ago (I'm not certain it was your specific post, but it might have been). It's strange to see this being described as "novel" now, unless there's something new to it that I am missing.
Cloudflare WARP made a robust VPN but is not cheap.
(Edited to replace "default gateway" with "subnet mask")
[0] https://www.wireguard.com/netns/#the-new-namespace-solution
default via <gateway ip> dev host0 proto static
The issue described in the article is what happens if you take the most basic approach, which is described in the Wireguard article: "instead of replacing the default route, we can just override it with two more specific rules that add up in sum to the default, but match before the default". This is historically what OpenVPN has done, and it's vulnerable to this issue.
I guess it really is the year of the Linux desktop :)
Do you want every distro turning into Ubuntu with cloud services and telemetry all over the place ?
If Linux can do it, why not the others?
The real problem is that encrypted packets from the VPN client use the same routing table as unencrypted packets from applications. This makes it very difficult to create a robust routing policy that says "all unencrypted packets are routed via the VPN, and all encrypted packets are routed via the physical network interface".
worth noting that this really is very dependent on the specifics of your VPN implementation. For example StrongSwan (ipsec) and WireGuard by default afaik use separate route tables. In general using separate route tables for virtual vs physical networks is not exactly rocket science.
But, because of this someone can have a Pineapple with a Starbucks SSID, push option 121 and capture a WHOLE bunch of traffic, even though the person using it has configured NordVPN on their iPhone with the killswitch on.
As I understand it, the problem comes not from the remote network provided by the VPN, but by the local network - the physical link over which the user accesses the Internet.
App (via the openziti sdk): https://blog.openziti.io/no-listening-ports
Browser (the openziti js sdk loads on the fly): https://blog.openziti.io/introducing-openziti-browzer
Disclosure: openziti (apache v2) maintainer
If they were, it would be a simple setting to set an ACL on the network interface to say "DENY all traffic except from VPN application".
You can control your routing table using standard tools (ip route add). You can have helper applications work on it, and get hints from external sources like dhcp, where you can listen to its suggestions (IP, subnet, DNS, extra routes, and other options), or ignore them.
If you take those hints then that's your choice.
With icmp redirects you can choose to allow them or not with settings like net.ipv4.conf.all.accept_redirects.
Then as a belt and braces you have iptables. If you want an ACL on the network interface to say "DENY all traffic except from VPN application", then set your input/output/forward chains to default deny and have a rule to allow from pid=$vpn_pid. I believe you can use pid in pre/postrouting chains.
Personally when I'm travelling I have rules which only allow access to my vpn targets, and from memory just DHCP and arp. Have to temporarily disable it for captive portals but then it's back on. Sometimes a network won't accept UDP, so I generally have to tether for normal response.
edit: ahh I’m dumb, it’s the router (correct me if I’m wrong!). So as others have said, you have to already be on a compromised network, yes?
Among the options strings that DHCP server may provide is DHCP option 121 Classless Static Routes, added in 2002, that can "push" routing information to clients for convenience. Apparently this option 121 can be abused to trick your laptop into set and prioritize `route add [google.com] via [malicious_host] dev wlan0` over `route add [google.com] via [vpn_right] dev vpn0` which routes traffic to [google.com], or 0.0.0.0/0 for that matter, through [malicious_host].
DHCP is more of a convenience feature for private IP address LANs, not strictly necessary for operating IP LAN. I've heard generations prior to ours sometimes leased clothespins labeled with IPs off the wall to guests, along instruction papers. DHCP completely automates that.
You basically have to trust everyone on the remote LAN to not act like a malicious DHCP server.
Reading the other thread, this wouldn't even be just the gateway.. Sounds bad!
But also, if you were using more specific routes for your corporate VPN traffic and not just forwarding all traffic through it, then the simple attack of sending two /1 rules wouldn’t interfere.
You’d still leak some metadata, but you leak a lot by using public networks anyway.
More than that when connecting via WiFi as almost everyone on a laptop does these days: you have to be careful of “evil twin” attacks from random APs nearby.
Though if you are accessing a VPN to get access to internal network resources, and someone uses this hack to redirect you, you are not going to see those resources anyway and you'll know something is wrong. Accessing any insecure resources is a risk (HTTP traffic can be monitored, fake servers could collect authentication credentials such as SSH user+pass info if not using key-based auth) but only if they are otherwise public because your redirected connection won't be able to route to your corporate network's internal hosts.
Unless I'm misreading (possible, I've only skimmed the details) those using VPNs because they already don't trust their outgoing connection, or are otherwise wanting to disguise their ID and/or location, are more at risk than road-worriers (or these days “home warriors” more likely) connecting to DayJob's VPN.
1. Coffee shop Wi-Fi router is compromised. Than that's a possible vector.
2. Bad actor sitting in the coffee shop and trying to carry out attack similar to the one described on the link. Fortunately that won't work on any decent WiFi infra from Meraki, Ubiquiti or similar.
DHCP attacks are always a problem on dumb wired switches though.
- User connects to an untrusted network (public wifi).
- That network uses DHCP to assign IP address for the user.
- A malicious DHCP would push static routes via DHCP that are more specific than a common default route, and send traffic via a malicious gateway.
- User connects to his/her VPN thinking his/her traffic is secured over the insecure network.
- The malicious static routes, being more specific, take precedence over the default route added by the VPN.
Though for new hosts people often don't verify the initial host key at all, just blindly accepting it, so that would be an extra risk vector.
Heck, I'm sure many don't bother verifying a new key when they get the warning, instead just removing the old from .ssh/known_hosts (or equivalent) to quiet the complaining! Though to be honest, with that security posture nothing is going to save them and our efforts are better spent securing others! I know at least one of our clients has automated systems that ignore key changes, because we once had a temporary config cockup that sent some connections to a host with the wrong key and some data was received there without any reported issues…
> And finally we add a convenience feature for still accessing the local network, whereby we allow packets without the fwmark to use the main routing table, not the WireGuard interface's routing table, if it matches any routes in it with a prefix length greater than zero, such as non-default local routes. [https://www.wireguard.com/netns/#improved-rule-based-routing]
Doesn't that completely neutralize the protection against a DHCP server sending malicious routes or a gigantic subnet mask?
Oh most of us will definitely care once linux developers start targeting the Ubuntus instead of the Trisquels (like how developers now target "android" instead of AOSP). I mean just look at how Gnome behaves now that it is the default DE.
A truly mainstream distro would be the death of the Linux desktop. I hope that year never comes.
Today, if some service needs propietary code, it's doomed to rot.
For firmware with desktop users and programmers/devops using Ubuntu at work -not an issue on servers- , it's preferable to use the Xanmod kernel with Trisquel than falling into thw whole cascade of propietary code in Ubuntu.
At least nonfree firmware it's a non burnt hardware ROM; that setup it's 90% free according to the FSF values. Also, you don't get overlayed taxing crap as snaps.
Basically, the DHCP server sends a subnet mask for an absolutely huge subnet (e.g. a /2), and the route for that subnet takes precedence over the VPN route. The attacker can only intercept 25% of the IPv4 address space with a /2 but that's still pretty bad.