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. :)
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!).
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 :)
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. :)