That’s why half decent VPN apps also add firewall rules to prevent leakage. Although nothing can beat Linux and shoving the real interface in a namespace so it’s plainly not available to anything except the VPN process.
Yes, I don’t agree with the no way to mitigate statement.
I suspect on windows the only real defence is something like.
Check if the network has suspicious multiple routes setup from the DHCP
If so, either use the IP/Mask/Gateway with manual IP config (to not receive the CIDR routes) or steer clear of an at best questionable network entirely.
Maybe use the windows firewall to block all traffic outbound EXCEPT from the firewall program (with perhaps exceptions for local networks as per below linux example). For whatever reason the windows firewall doesn’t seem to have a way to specify an interface. But you can specify a program.
I did look for some way to control Window’s handling of DHCP options. But it seems there isn’t anything obvious to limit this otherwise. I do not know if the windows firewall has this kind of fine-grained control with its own fire
For linux, I used to have my own blackout firewall rules. That only allowed the specific LAN range (for mobile use you could include all RFC1918 ranges) and the specific VPN IP out of the internet facing interface. Only the VPN interface could otherwise access the internet.
Some providers have managed to make split tunnelling work fine so those I suspect are not affected because they override the routing at the driver level. It’s really only the kinda lame OpenVPN wrappers that would be affected. When you have the custom driver, you can affect the routing. It’s been a while since I’ve tested this stuff on Windows since obviously I haven’t been paid to do that for 6 years, but yeah I don’t even buy that all providers are affected and that it’s unfixable. We had workarounds for that when I joined PIA already so it’s probably been a known thing for at least a decade.
The issues we had is sometimes you could get the client to forget to remove the firewall rules or to add back the routes and it would break people’s internet entirely. Not great but a good problem to have in context.
That’s why half decent VPN apps also add firewall rules to prevent leakage. Although nothing can beat Linux and shoving the real interface in a namespace so it’s plainly not available to anything except the VPN process.
Yes, I don’t agree with the no way to mitigate statement.
I suspect on windows the only real defence is something like.
I did look for some way to control Window’s handling of DHCP options. But it seems there isn’t anything obvious to limit this otherwise. I do not know if the windows firewall has this kind of fine-grained control with its own fire
For linux, I used to have my own blackout firewall rules. That only allowed the specific LAN range (for mobile use you could include all RFC1918 ranges) and the specific VPN IP out of the internet facing interface. Only the VPN interface could otherwise access the internet.
Some providers have managed to make split tunnelling work fine so those I suspect are not affected because they override the routing at the driver level. It’s really only the kinda lame OpenVPN wrappers that would be affected. When you have the custom driver, you can affect the routing. It’s been a while since I’ve tested this stuff on Windows since obviously I haven’t been paid to do that for 6 years, but yeah I don’t even buy that all providers are affected and that it’s unfixable. We had workarounds for that when I joined PIA already so it’s probably been a known thing for at least a decade.
The issues we had is sometimes you could get the client to forget to remove the firewall rules or to add back the routes and it would break people’s internet entirely. Not great but a good problem to have in context.
I’ve never checked the box, when I set address and DNS to manual and add my own routes, not dhcp inherited
ignore automatically provided routesWould seem like a thing to do now?