[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