Solution to potential DHCP option 121 vulnerability on libreCMC routers running OpenVPN/Wireguard

You may have read about a recently demonstrated attack aka TunnelVision and found this page looking for information on what you can do to stop it. Until recently there has been very little information about DHCP option 121 and how it can be used to compromise the privacy of VPN users. In this attack DHCP option 121 is used to update the routes of downstream clients (typically computers or other routing devices). In cases where a user does not trust the ISP/or upstream connection and that connection is obtained via a DHCP request there is a danger of the DHCP server redirecting a users traffic post-the-initial-lease-request.

The best example of this attack would be against a user connecting to a privacy oriented VPN service at a coffee shop offering free wifi. Normally a VPN user would first connect to the free wifi (this is they would make a DHCP request for an IP address), then the user would connect to the VPN. The VPN connection would be established and all traffic bound for the internet would be directed at this new VPN connection rather than through the primary wireless interface (except for the VPN connection itself anyway). The problem becomes DHCP option 121 lets the wifi provider/ISPs update the routes on the end-users computer. It can tell the computer to route all internet bound traffic back through the wifi connection directly. If your DHCP client software/computer respects this DHCP option 121 message anyway.

There has been a lot of confusion about how to fix this and where. For a user running OpenVPN or Wireguard on their router and connecting via DHCP to an ISP that they do not trust one solution is to simply disable classless routes.

The below instructions are a proper fix for routers running libreCMC. By following these directions you will prevent DHCP option 121 attacks on the client DHCP software running in libreCMC. The fix isn’t something you can apply in luci (the web administration interface accessible via the web browser). This is because the fix applies to the DHCP client software on the router, not the DHCP server software that can be configured via the web user interface. It’s the DHCP client software that updates the routes on the router itself.

You have to ssh into the router to apply this:

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

To edit the configuration backup files in a tar.gz file edit /etc/config/network and under config interface 'wan' add:

option classlessroute '0'

A more detailed tutorial on applying the fix is available here.