Messages

As anticipated, the moment I posted this, I found the reason. I after verifying the options were being pushed, I realized that option 121 was under my advanced options for dhcp. The values were encoded as a string, hence not being able to find it as ascii or binary representations of the CIDR range. I thought that was for something I had set up different but guess it was all me.

A while back, I changed around my home networking plan from a 10.x/ to a 172.x scheme for better compatibility with some of my clients. After the transition was made, systems on DHCP in the user subnet were receiving stale routes to the backend showing the old addressing scheme:

Code Select Expand

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.23.21.1     0.0.0.0         UG    600    0        0 wlp2s0
10.69.240.0     10.69.241.1     255.255.248.0   UG    600    0        0 wlp2s0
10.69.241.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0
72.23.20.0     10.69.241.1     255.255.255.0   UG    600    0        0 wlp2s0
172.23.21.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Packet capture clearly shows these options being sent as classless static routes (option 121)
now, 10.69.x.x no longer exists anywhere in the config file, in any lease file I could find, or anywhere else that I can fathom. It does not appear in netstat -rn on the opnsense machine, or in any lease cache I can find on the clients (though, being as the route is being pushed, that was always a long shot).

What do I need to do to stop dhcpd from pushing these broken routes?