Back in May 2024, there were reports of a VPN “vulnerability” named “TunnelVision”. The “vulnerability” uses DHCP Option 121, RFC 3442, to advertise a static route to DHCP clients. The clients then use this route as it is more specific than 0.0.0.0/0 typically defined for a non-split VPN tunnel and send the traffic elsewhere. The authors of the RFC acknowledged it in December of 2002, the RFC publishing date. It is surprising it took almost 22 years for this to make news. And while DHCP Option 121 is a pretty obscure and not widely used option, it can act as a very convenient routing helper.
Scenario
Suppose I have VLAN 12, 192.168.12.0/24 and VLAN 34, 192.168.34.0/24. Utilizing a router-on-a-stick topology, the default gateways for each subnet are X.X.X.1 (the interface IPs for each VLAN). The router is connected to a core which also has the access switches connected to it. Majority of the client traffic is going out to the internet utilizing the router as their default gateway.
Challenge
But what do we do for the inter-VLAN routing? Usually, we have 2 options:
- have the router handle it but this adds an extra forward from the switch to the router and back and thus latency and additional load on the router.
- if the switch supports Layer 3 routing, do it on the switch acting as the default gateway for the VLANs. But this adds an extra hop for the internet traffic.
Solution
A better solution is DHCP option 121. This option allows for keeping the router as the default gateway but adds a static route between VLAN 12 and VLAN 34 with the switch acting as the next hop.
Configure your Layer 3 switch as you normally would. For example, for Cisco:conf t
ip routing
vlan 12
vlan 34
interface Vlan12
ip address 192.168.12.111 255.255.255.0
no shutdown
interface Vlan34
ip address 192.168.34.111 255.255.255.0
no shutdown
end
In your DHCP server, add Option 121 (usually it’s a custom option). This option requires a specific encoding for the routers. You can use a calculator like this one to generate the string to add to the DHCP server.
The sting for VLAN12 in our example would be 0x00C0A80C0118C0A822C0A80C6F and 0x00C0A8220118C0A80CC0A8226F for VLAN34.
Simple as that. This way:
- All internet-bound traffic travels the usual path, with no extra hops.
- All inter-VLAN traffic between VLAN 12 and VLAN 34 is handled by the Layer 3 switch.
- Improved routing and switching efficiency and (depending on the load) freeing up the router resources.
Discussion
One of the questions left unanswered is why bother with Option 121 when you can set the route directly on the machine? And the answer is iOS (Apple’s not Cisco’s) and other mobile devices.
In my environment, I have a bunch of iPhones and iPads in VLAN 12 that need to access a WebDAV file sever (running over https and accessed by its fqdn) residing in VLAN 34. This is the traffic I want to offload off the router. I could create another vNIC on the WebDAV server and place it into VLAN 12, making the server effectively local for the iPhones and iPads. But then I’d need to set up a split brain DNS to return different IP addresses based on the VLAN.
DHCP Option 121 provides a perfect solution to my challenge. It is more flexible than the deprecated(?) Option 33. I use /32 subnet mask for the route towards VLAN 34 as I need access to only one server. But for the return traffic I need /24 so Option 33 wouldn’t be an option (pun intended).
This is it for now. Now we’re using enterprise solutions as Layer 3 routing and custom DHCP options in our homelab. Enterprise at home, indeed…