I added clarification that the HTTPS part is assuming that the attacker has already performed the DHCP attack. Thanks for the note!
The DHCP race is one part I didn't go into detail about since I'm not very familiar with the details, but what you wrote makes sense. One potential danger is a hacker at a coffee shop, where the shop owner is unlikely to be monitoring the network, and there are going to be many new connections coming in all the time. It's still an unlikely scenario, but it also isn't a particularly difficult attack.
I see what you mean now. I wouldn't advocate for people to disable DHCP features either. It should be the VPN provider's responsibility to provide a proper VPN client that mitigates attacks like these.
why is a split tunnel relevant? I thought all VPNs are vulnerable unless they use a firewall like I do, or network namespaces.
At least the way I understand it, a normal VPN redirects your internet traffic to instead go through a virtual network interface, which then encrypts and sends your traffic through the VPN. This attack uses a malicious DHCP server to inject routes into your system, redirecting traffic to the attacker instead of towards the virtual network interface.
How do you route all a host system's traffic through Gluetun? If you use routing tables, wouldn't it similarly be affected by TunnelVision? In which case you would still need a firewall on the host...
Also, the host system likely makes network requests right after boot, before a Gluetun container has time to start. How do you make sure those don't leak?
I am curious though, how you were able to route all host traffic through Gluetun. I know it can be used as a http/socks proxy, but I only know of ways to configure your browser to use that. What about other applications and system-level services? What about other kinds of traffic, like ssh?
Though if you have any alternatives for vanilla wireguard users like me, I'll gladly switch. I know somebody mentioned Gluetun but I thought that was for docker only. Do you know of any others?
I added clarification that the HTTPS part is assuming that the attacker has already performed the DHCP attack. Thanks for the note!
The DHCP race is one part I didn't go into detail about since I'm not very familiar with the details, but what you wrote makes sense. One potential danger is a hacker at a coffee shop, where the shop owner is unlikely to be monitoring the network, and there are going to be many new connections coming in all the time. It's still an unlikely scenario, but it also isn't a particularly difficult attack.