[banister]

Read my reply to the other poster, i answer exactly this. Actually test it yourself. Stop theorizing. I tested it. It works exactly as I said.

I think i know where you're confused. There is a firewall whitelist on the VPN endpoint route. Also it's impossible for the DHCP server to push a route more specific than this since it's a /32 route, so it's unaffected (together with the firewall rule allowing it) by anything the DHCP server attempts to do.

[Borealid]

I think you might be saying to add rules like `iptables -A OUTPUT -d <vpnserver>/32 -j ACCEPT`, `iptables -A OUTPUT -o vpn0 -j ACCEPT`, and `iptables -A OUTPUT -j DROP`.

I'm a bit confused though because you only mentioned one rule and that's three. But also, I think using that combination of rules would result in dropping all traffic that someone attempts this attack against - in other words, turning it into a denial-of-service attack instead of a loss-of-confidentiality one.

But there's no technical need to drop the maliciously-routed traffic, is there?

[banister]

Yes exactly. It becomes a "denial of service" against the option 121 pushed subnet routes. That's already discussed in the paper, i assumed you knew that already.

There's nothing else you can do in this situation other than detecting and then removing those routes, which is possible. In lieu of deleting the routes the best and most secure option is to block that subnet. A DoS is infinitely better than a LEAK.

There are SOME things you could do (other than just removing the routes) to prevent the DoS i guess if you REALLY wanted - there is some package rewriting capabilties in the mac pf firewall and windows WFP would support this too (though it would require a 'callout' driver (kernel code) at the IP_OUTBOUND layer), and linux allows something like this too with fwmarks and multiple routing tables + a source NAT, but it's not really worth the effort in a rare case like this. Easiest just to let those packets be blocked. The network you're on is controlled by a bad actor with a malicious DHCP server. Best option for you is to GTFO.

[Borealid]

Okay, I'm glad we've got that sorted out.

What I do is put the VPN client into a tagged network namespace (yes, fwmark), and then have a routing rule that makes everything else use a separate routing table.

The DHCP server inserts rules into the routing table used only by the VPN client.

Doing it that way, all leaks are prevented, and also there's no way to denial-of-service traffic within the tunnel - no matter what routes are pushed, it keeps flowing as normal.

No source NAT is required, only `MANGLE`.

[banister]

Cool! glad we're on the same page finally :)

Yeah, lots of cool stuff you can do with Linux. just wish that the other OSes were half as good, unfortunately most of them require kernel code to do what would be a simple shell script in linux