[banister]

No, you're wrong again. I just tested this (simulating routes added by a DHCP option 121) and it works exactly as I said.

C is what happens. But it doesn't happen the way you say at all.

Only the traffic heading to the new 121 routes are blocked - why is it blocked? because the routes are on the physical interface, and the firewall rules blocks all off-VPN traffic (except traffic to the VPN endpoint itself)

The tunnel stays up because the tunnel connection is over the physical interface. The VPN endpoint has a physical route from the host to the VPN endpoint which is whitelisted in the firewall. So new physical routes (which option 121 would push) don't impact anything as VPN endpoint route is physical anyway. Also it's impossible for the DHCP server to push a route MORE specific than the endpoint route (which is a /32) that already exists, so it can't be overridden (and it wouldn't matter anyway since it would still be a physical route, which is what is desired here).

Can you stop just talking and actually TRY it? it's all theoretical for you since you're not actually testing it and your theory is completely wrong.

I am actually testing it, so i know I am correct.

[Borealid]

Could you please show me a rule so I can "try it"? I'd love it if this worked.

Let's say:

- the physical interface name is "wlan0"

- the VPN virtual interface name is "tun0"

- the VPN server is 10.1.1.1 on TCP port 8888

- the DHCP server on initial lease sends "0.0.0.0/0 via 10.8.8.8"

- the DHCP server on renew sends the above rule and also "10.0.0.0/8 via 10.9.9.9"

- Before the renew, traffic not routed via 10.8.8.8 is blocked

- After the renew, traffic with a destination IP matching 10.0.0.0/8 not routed via 10.9.9.9 is blocked

What should the firewall rule look like to let the VPN connection stay up both before and after the new rule, while also ensuring that traffic to 10.7.7.7 goes via the VPN and not via 10.9.9.9 or 10.8.8.8?

EDIT: you keep saying "I'm wrong" but I'm just asking how this firewall rule can be structured to do what you say. It occurs to me that perhaps you're saying you can make traffic for 10.7.7.7 get blocked. But in the above, and before, what I'm asking for is how to make traffic for 10.7.7.7 continue to get sent over the VPN after the new rule addition, just like it was before - in other words, no dropped packets.

[banister]

Your examples are strange as you're using rfc1918 addresses (i.e private range) rather than public ips. So all your examples are very odd.

10.7.7.7 will get dropped. This is correct behaviour based on the routing rules in your example. The VPN connection will stay up as it has a /32 route setup through the wlan0 interface.

What we're concerned about with TunnelVision is preventing LEAKS, this is what constitutes VPN security. If the DHCP server sends a route that forces traffic through the physical interface instead, then the best you can do is BLOCK it. If you really wanted to you could detect and remove the route, but that's a different question and still has nothing to do with the question we're concerned about which is plugging LEAKS.

Also why on earth are you using rfc1918 addresses as an example, it's more meaningful to be using public ip addresses - i.e the DHCP server pushes a 1.1.1.1/32 route. The issue with rfc1918 addresses is it's totally not clear if they will get routed at all as you didn't specify whether they're on-link or not as you didn't provide a subnet mask.

The rules are: * an ALLOW rule on the vpn endpoint ip + a /32 route for the endpoint * an ALLOW rule on tun0 traffic * a BLOCK rule on EVERYTHING else - i.e just a iptables -I OUTPUT -j DROP

Can we please stop the back and forth now, it's really starting to chew up too much time. I don't want to have a conversation about the specific addressing scheme you're using - you should have used public ips to make things much clearer, i don't want a long argument now about subbets and whether certain addreses in your example are on-link or require a routing hop. This is so tiring. :)

[Borealid]

I used RFC1918 addresses as examples only.

10.7.7.7 shouldn't get dropped, because it's supposed to be routed over the VPN. The DHCP server shouldn't be able to cause VPN-bound traffic to be dropped, in my opinion.

As I replied to one of your other comments, I don't think making the attack go from privacy-breach to denial-of-service is "preventing" the attack: you've only partially mitigated it. Full mitigation requires more than the firewall rules you've described.

Said differently, a malicious DHCP server should not be able to denial-of-service traffic within your VPN (or, by selectively pushing routes and then observing the impact on generated traffic, probabalistically determine the IPs with which you're communicating!).

[banister]

Ok. Well, the attack is so rare that i don't believe putting mitigations against the DoS is worth the effort. The mitigations are not that trivial (though it's arguable that just removing the route is kind of trivial, but still not worth it IMO). Better a DoS than a leak in any case :)