Inconsistent behaviour between configuring custom DHCP option as String or HEX
Hi,
I recently encountered a situation where I needed to configure DHCP clients to install static routes in order to reach their DNS servers, which are provided via DHCP but reside outside the client subnet.
Network Context:
-
Client subnet: 10.35.0.1/24
-
DNS servers: 10.51.0.15 and 10.51.0.22 (reachable via the subnet gateway at 10.35.0.1)
This setup works fine under normal circumstances. However, problems arise when some clients enable a full-tunnel VPN, which installs a broad static route like 10.0.0.0/8 and overrides more specific paths. Unfortunately, modifying this VPN behavior is not an option.
To address this, I attempted to advertise static routes for the DNS subnets using DHCP Option 121.
Config Using String Format (does not work):
-
Option Code: 121
-
Type: String
-
Content: 24,10,51,0,10,35,0,1
This results in a malformed route. In Wireshark, I noticed that the third value (51) is misinterpreted as a subnet mask width, resulting in an invalid “mask width 51” error.
Config Using HEX Format (works):
-
Option Code: 121
-
Type: HEX
-
Content: 18:0A:33:00:0A:23:00:01
This correctly represents the desired route:
-
Destination: 10.51.0.0/24 → 0x18 0x0A 0x33 0x00
-
Gateway: 10.35.0.1 → 0x0A 0x23 0x00 0x01
What I would like/expect:
I’ve managed to make it work using the hex format, but managing routes via the string format would be much more convenient and readable
Would appreciate any insights or workarounds. Thanks!