I know it’s not really perceived this way any more, but once upon a time end-user (non-corporate) VPN software and services were aimed at exactly that use case: you’re on a public network or hotspot and don’t trust it (e.g. you’re on public wifi at an airport in a “less friendly” country), so you use a VPN to surf from a safer standpoint. But oops — turns out, maybe you weren’t.
Yep, indeed. I’m wondering if it makes any difference if it’s the station operator doing it, though; i.e. “less friendly” country wants to compromise your privacy, so the airport public wifi sends you option 121 to defeat your VPN use.
There’s definitely still threat vectors for some to worry about. And while most wireless networks are configured this way it is nearly impossible to verify it in any given situation. So caution is warranted. Overall though, I feel like the linked article and the general consumer VPN market is based on a 2010 idea of public networks where low level criminals could eavesdrop on unencrypted HTTP traffic and swipe your gmail credentials.
Summary: a machine in your LAN can send you bad DHCP packets
No, if I read it correctly it’s that a machine on the same VPN that you’ve connected to can send you bad DHCP packets. When you connect to a VPN it’s also, in a sense, a virtual LAN. Other VPN users are connecting to that same network. They may be able to send bad DHCP packets to others.
It does seem like something that could be fixed by the VPN providers: i.e. ensure that client connections can’t send packets between each other. I’m not sure if there’s any reason why that wouldn’t be practical.
Edit: Ok, I’ve been re-reading and think this was the wrong take, and you’re correct - the DHCP packets need to be sent over the local network. The linked article makes that fantastically unclear; it really does limit the scope of the attack.
Sorry, I think I’m misunderstanding something here. I would disable this option to protect myself, for example when traveling. Now, if I disable it on my laptop/device, how can that affect anything you run? How can you run a dhcp client that is under my control?
Vaelatern’s original comment is a bit whimsical, addressing would-be authors or maintainers of DHCP client software. You could imagine that some disable or remove support for the option in response to this revelation, and if Vaelatern happened to use software that did so, their setup would break.
It would not be sane – the network topology in a very large network might bear no relation to a home network, and guests to that very large network do not need the extra stress or load on IT to diagnose why e.g. split horizon DNS has been broken (assuming public and local traffic go through different routers).
It’s notable that not all VPN apps are susceptible. https://old.reddit.com/r/Tailscale/comments/1cm9s5t/comment/l31c6m8/ points out that the Tailscale VPN app on Linux sets up a different routing table that gets priority, before the route advertised by option 121 can take effect.
Perhaps it would be more sane for VPN apps to stop selling snake oil like privacy from Facebook and actually be good at being a VPN.
Folks with those very large networks are presumably corporate in which case they have control over the end user’s machine and can turn back on whatever features they want, and can probably additionally force users to run whatever corporate operating system they want.
As a specific example, windows already has home and pro editions and it would likely be reasonable/sane for windows to disable it by default for home use and allow it for pro.
And yeah there are other VPNs, that lock down the routing table, cisco anyconnect is one I’m thinking of. It’s impossible to use because I typically need multiple network connections on different interfaces to get my job done.
You forget universities. Or public services. Municipalities. Anywhere where bringing your own device is possible.
DHCP is just that. Dynamic Host Configuration Protocol. If I have endpoint configuration, I don’t need option 121 at all.
The real message of this post is “Don’t trust coffee shop DHCP.” Or perhaps “VPN apps are not suitable for privacy purposes on Mac/Windows.” Not “Ah yes make it so Windows computers can’t reach Vaelatern’s home servers unless you dig around in a bunch of menus first.”
This is why I plead “don’t turn off option 121.” People should not read this news and think Android has the right of it by not implementing the standard.
Using network namespaces on Linux can completely fix this behavior
[…]
it’s not clear if there is a solution for Windows, MacOS, or other operating systems
This can also implemented by passing the interface to a container/VM and let the VPN run inside the container/VM. The host will get only the vpn endpoint passed out. This should be possible on all OS.
Lack of namespaces is one of the things that I was surprised to find I miss, given how fragile they are on Linux.
I use this thing, which basically wraps Wireguard’s namespace hack into a (set of) systemd service(s) because:
I actually need to run only a handful of applications inside a VPN, primarily in order to prevent trivial attacks and to confuse the ad bots a bit. I don’t need serious anonymisation/security features, my threat model for encryption (whether at rest or in transit) is primarily about things like burglary or pissing off people with short attention spans but lots of free time on Discord.
Both Docker and podman are remarkably inept when it comes to managing networks. I’d allowed all my knowledge of networking to evaporate between 2006 and 2016 or so, only to rediscover it once Docker became standard.
It turns out to be the thing I miss the most under both Windows and macOS. Running either WSL or container/virtualization solutions on macOS while also running a VPN is a constant source of pain and astonishment. Most of these applications will gladly plow through multiple steps of building an obviously incorrect network configuration, with no error checks between steps, and no indication about what it’s meant to achieve, at least, so that you can debug it. It’s like nobody wanted to do the network bring-up/teardown part so they just had an intern do it and once it worked on their machine they just committed it to Github and never touched it again.
It mentions a “DHCP option 121” that overrides routing for some reason, is that the “feature” hotels use to hijack your connection and show you their own page until you log in / pay through the browser?
Pushing routes to clients via dhcp is more typically used in large networks (eg. like a college campus) where there may be several other networks/gateways connected. I think these days most networks are a bit more “hub and spokey” and just have a default gateway handling routing more centrally vs pushing routes to all clients via dhcp, but I’ve used option 121 a few times for special cases (eg. having a few clients do something specific via dhcp).
(Disclaimer: I’m talking all this at face value so far, and I’m not 100% convinced that’s correct.)
Assuming they’re right and the leaks from most possible countermeasures are just as bad as they sound on a relatively uncritical first-pass read so far…
The network namespaces feature they advocate reminds me of the approach whonix takes to prevent traffic from leaking off tor. The whonix approach seems very likely fruitful here for platforms that don’t have a feature equivalent to network namespaces out of the box.
Summary: a machine in your LAN can send you bad DHCP packets that add entries to your routing table, so now your traffic isn’t routed via the VPN.
Mitigations:
Don’t use untrusted LANs/remove untrustworthy devices from your LANs (e.g. use a hotspot while travelling)
Use android (doesn’t support the required DHCP feature)
Disable DHCP option 121
Use a network namespace on Linux
Thank you.
Sounds like a non-issue for most users, unless you’re on a public network.
It’s another way for vulnerable or malicious IoT devices on your LAN to attack you, which I think is notable.
I know it’s not really perceived this way any more, but once upon a time end-user (non-corporate) VPN software and services were aimed at exactly that use case: you’re on a public network or hotspot and don’t trust it (e.g. you’re on public wifi at an airport in a “less friendly” country), so you use a VPN to surf from a safer standpoint. But oops — turns out, maybe you weren’t.
Most public wireless networks have station isolation features that make them more of a 1:1 internet gateway than a LAN.
Yep, indeed. I’m wondering if it makes any difference if it’s the station operator doing it, though; i.e. “less friendly” country wants to compromise your privacy, so the airport public wifi sends you option 121 to defeat your VPN use.
There’s definitely still threat vectors for some to worry about. And while most wireless networks are configured this way it is nearly impossible to verify it in any given situation. So caution is warranted. Overall though, I feel like the linked article and the general consumer VPN market is based on a 2010 idea of public networks where low level criminals could eavesdrop on unencrypted HTTP traffic and swipe your gmail credentials.
I’m not sure I agree. Routers are notoriously targets for malicious actors, I did a quick search on Ars and this article is from 6 days ago https://arstechnica.com/security/2024/05/hacker-free-for-all-fights-for-control-of-home-and-office-routers-everywhere/
It’s definitely possible for someone to bootstrap into this attack.
If your router is compromised it’s pretty much game over though?…
Not if you actually pay attention to identify verification failures (and CAs are doing their job of not issuing bogus certificates.)
You won’t be able to get a valid connection, but you should be able to determine that there is a problem.
[Comment removed by author]
No, if I read it correctly it’s that a machine on the same VPN that you’ve connected to can send you bad DHCP packets. When you connect to a VPN it’s also, in a sense, a virtual LAN. Other VPN users are connecting to that same network. They may be able to send bad DHCP packets to others.It does seem like something that could be fixed by the VPN providers: i.e. ensure that client connections can’t send packets between each other. I’m not sure if there’s any reason why that wouldn’t be practical.Edit: Ok, I’ve been re-reading and think this was the wrong take, and you’re correct - the DHCP packets need to be sent over the local network. The linked article makes that fantastically unclear; it really does limit the scope of the attack.
Please don’t disable dhcp option 121. I’m using it to glue my networks together with a VPN link that’s not on the gateway.
How would me disabling DHCP option on my network prevent you from doing stuff on your network?
How would you disable the dhcp option on your network? Just don’t serve it.
More likely someone disables the option in a dhcp client and I end up running that client.
Sorry, I think I’m misunderstanding something here. I would disable this option to protect myself, for example when traveling. Now, if I disable it on my laptop/device, how can that affect anything you run? How can you run a dhcp client that is under my control?
Vaelatern’s original comment is a bit whimsical, addressing would-be authors or maintainers of DHCP client software. You could imagine that some disable or remove support for the option in response to this revelation, and if Vaelatern happened to use software that did so, their setup would break.
It would be sane for them to disable it by default for the uninformed user.
You know what you’re doing, and you can turn it back on.
It would not be sane – the network topology in a very large network might bear no relation to a home network, and guests to that very large network do not need the extra stress or load on IT to diagnose why e.g. split horizon DNS has been broken (assuming public and local traffic go through different routers).
It’s notable that not all VPN apps are susceptible. https://old.reddit.com/r/Tailscale/comments/1cm9s5t/comment/l31c6m8/ points out that the Tailscale VPN app on Linux sets up a different routing table that gets priority, before the route advertised by option 121 can take effect.
Perhaps it would be more sane for VPN apps to stop selling snake oil like privacy from Facebook and actually be good at being a VPN.
Folks with those very large networks are presumably corporate in which case they have control over the end user’s machine and can turn back on whatever features they want, and can probably additionally force users to run whatever corporate operating system they want.
As a specific example, windows already has home and pro editions and it would likely be reasonable/sane for windows to disable it by default for home use and allow it for pro.
And yeah there are other VPNs, that lock down the routing table, cisco anyconnect is one I’m thinking of. It’s impossible to use because I typically need multiple network connections on different interfaces to get my job done.
You forget universities. Or public services. Municipalities. Anywhere where bringing your own device is possible.
DHCP is just that. Dynamic Host Configuration Protocol. If I have endpoint configuration, I don’t need option 121 at all.
The real message of this post is “Don’t trust coffee shop DHCP.” Or perhaps “VPN apps are not suitable for privacy purposes on Mac/Windows.” Not “Ah yes make it so Windows computers can’t reach Vaelatern’s home servers unless you dig around in a bunch of menus first.”
This is why I plead “don’t turn off option 121.” People should not read this news and think Android has the right of it by not implementing the standard.
Would be nice when posting the original source directly: https://www.leviathansecurity.com/blog/tunnelvision
The most important part is at fixes:
This can also implemented by passing the interface to a container/VM and let the VPN run inside the container/VM. The host will get only the vpn endpoint passed out. This should be possible on all OS.
I liked the linked (older) post as a very concise summary.
Lack of namespaces is one of the things that I was surprised to find I miss, given how fragile they are on Linux.
I use this thing, which basically wraps Wireguard’s namespace hack into a (set of) systemd service(s) because:
It turns out to be the thing I miss the most under both Windows and macOS. Running either WSL or container/virtualization solutions on macOS while also running a VPN is a constant source of pain and astonishment. Most of these applications will gladly plow through multiple steps of building an obviously incorrect network configuration, with no error checks between steps, and no indication about what it’s meant to achieve, at least, so that you can debug it. It’s like nobody wanted to do the network bring-up/teardown part so they just had an intern do it and once it worked on their machine they just committed it to Github and never touched it again.
It mentions a “DHCP option 121” that overrides routing for some reason, is that the “feature” hotels use to hijack your connection and show you their own page until you log in / pay through the browser?
No, that’s typically a captive portal.
Pushing routes to clients via dhcp is more typically used in large networks (eg. like a college campus) where there may be several other networks/gateways connected. I think these days most networks are a bit more “hub and spokey” and just have a default gateway handling routing more centrally vs pushing routes to all clients via dhcp, but I’ve used option 121 a few times for special cases (eg. having a few clients do something specific via dhcp).
Appreciate the explanation, chur :)
(Disclaimer: I’m talking all this at face value so far, and I’m not 100% convinced that’s correct.)
Assuming they’re right and the leaks from most possible countermeasures are just as bad as they sound on a relatively uncritical first-pass read so far…
The network namespaces feature they advocate reminds me of the approach whonix takes to prevent traffic from leaking off tor. The whonix approach seems very likely fruitful here for platforms that don’t have a feature equivalent to network namespaces out of the box.