TunnelVision "technique" aka DHCP/VPN vulnerability (CVE-2024-3661):

Turns out your router can receive a DHCP option 121 and have its routes modified by it. If you’re routing some traffic via VPN or by other means, such a route could be overridden. If course these days most traffic is e2e encrypted, so it’s less likely that your information will leak, but it is possible. You do encrypt DNS, right?

Source: https://www.leviathansecurity.com/blog/tunnelvision

Is there a way to make DHCP client on OpenWrt ignore option 121?

1 Like

Could you adapt the title mentioning the CVE from your source ? That would probably draw some attention :wink: *TunnelVision (CVE-2024-3661):

I'm not affected too much by this because I do not use a kill switch. Traffic goes over the VPN or otherwise is blocked by the firewall. IIRC my router only allows NTP and DHCP from the ISP (very minimal) all other data goes through the tunnel. I have to do some testing to see what it does exactly.

But nevertheless I was really surprised Android of all OS's was not affected by this :crazy_face:

I'm really looking forward to the dev comments about this.

Thanks for the heads-up.

There is an option (not in luci though)

1 Like

You are welcome to make PR against dhcp.sh in netifd flipping the default. Wont save few-packet leaks around VPN state changes completely.

Thanks! I missed it while doing my initial brief search.

uci set network.wan.classlessroute=0
uci commit
service network reload

Thanks for digging that up; seems like such an ez fix for something thats gonna burn a lot of people. Starlink pushes this when you bypass their modem "to maintain access to their system" but idk, they could like stop at the dish, right?

I saw this suggested elsewhere:
Comment out line 39 in

/lib/netifd/dhcp.script: '#[ -n "$staticroutes" ] && set_classless_routes $staticroutes'

You have official parameter to do it, no need to tweak scripts.