Kea Option 150?

[OrlyP]

Currently using a dedicated Windows Server as DHCP and everything is working ok. I want to streamline my home network and collapse more, if not all functions on OPNsense.

So I'm trying out Kea DHCP.

Unfortunately, it doesn't appear to have support for Option 150. This is required for Cisco IP phones to figure out the IP address of the TFTP server.

In Kea > Subnets, there's a field for a TFTP server. I've put in the IP address of the TFTP server but the phones aren't seem to be getting it.

Routing is working fine and all other devices on this particular subnet can ping or access the TFTP server, so this is not a reachability issue as far as I can tell.

Any help is appreciated. Thanks!

[pfry]

It's a reach, but are you using Socket Type "udp"? I have a switch that only works with "raw".

[OrlyP]

It's a reach, but are you using Socket Type "udp"? I have a switch that only works with "raw".

Being new to Kea, I've left everything default. It's currently set to "raw" and I might play around and try UDP later. Will revert back whatever the results may be.

Thanks for the suggestion.

[EricPerl]

It seems pretty trivial to look at the traffic (Interfaces > Diagnostics > Packet Capture), filter on interface, IPv4, UDP & port 68.
Unplug & replug a phone. The full capture seems pretty readable.
I'm no expert but the client seems to be requesting various options and the server obliges when it can.

[EricPerl]

The TFTP server name option is 66 per Wikipedia.
I hacked my dhclient.conf to request it and Kea obliged with the value specified in the subnet, per packet capture.

[OrlyP]

It seems pretty trivial to look at the traffic (Interfaces > Diagnostics > Packet Capture), filter on interface, IPv4, UDP & port 68.
Unplug & replug a phone. The full capture seems pretty readable.
I'm no expert but the client seems to be requesting various options and the server obliges when it can.

Not sure what I'm doing wrong but the capture is empty.

If I go check the Kea DHCP leases, the IP phone is there, so that indicates that it is getting an IP address at least.

I should add that the IP phones are behind a Layer-3 switch, which is on a VLAN/subnet different from the LAN subnet on OPNsense. The L-3 switch is doing DHCP-relay (ip helper-address in Cisco-speak).

To illustrate:

[EricPerl]

Did you do the capture on the interface corresponding to the VLAN?

[dseven]

The VLAN doesn't exist on OPNsense - only on the layer 3 switch.

I think DHCP relay uses port 67, not 68, so that's probably why the packet capture isn't seeing anything...

[EricPerl]

My bad. 68 is the DHCP client port which works in direct cases but apparently not in the relay case. 67 is the DHCP server port which is a better choice for filtering when doing captures on the server side. I typically snoop on the client side via port mirroring... I had ran a quick test to check the output on the server side and found it remarkably expanded/useful. The network capture port can be either source or destination.

That's how I was able to verify that option 66 returned the TFTP name entered in Kea.

This particular use of L3 switches still baffles me. It looks like it requires extra configuration (routes, relays, ...) and I don't see any benefits.

[EricPerl]

A little more research indicates that option 150 is Cisco proprietary for the same functionality 😒
The network capture output recognizes both: TFTP-Server-Address (150), TFTP (66).
Kea only handles 66.

While the OP could hack the Kea config, updates don't survive changes in the GUI so that's not practical.
ISC has support for custom options.
For Kea, it's in the works per Kea dhcp - vendor specific options

[OrlyP]

A little more research indicates that option 150 is Cisco proprietary for the same functionality 😒
The network capture output recognizes both: TFTP-Server-Address (150), TFTP (66).
Kea only handles 66.

While the OP could hack the Kea config, updates don't survive changes in the GUI so that's not practical.
ISC has support for custom options.
For Kea, it's in the works per Kea dhcp - vendor specific options

Thank you for this info. I honestly thought that adding vendor-specific/custom options on most any DHCP servers was something trivial.

I was going to use ISC but since it's being deprecated and with Kea taking its place, I decided to deploy the latter for future-proofing. Cisco IP phones are ubiquitous and it's been around for the last 20+ years. I would've thought that custom Options support is "standard" across DHCP servers. For the same purpose, Avaya IP phones require Option 176, and I think it's going to run into the same problem on Kea.... at least for now.

I guess I'll stay with Windows Server DHCP for the time being until Kea adds support for custom Options.

Thanks guys!

[EricPerl]

I haven't looked into the details of the upcoming change but given support in the config file, it seems what's missing is UX to handle/populate the config file.
I haven't been using OPN long enough to know when Kea was introduced/ported but it seems to lag on some aspects compared to the legacy ISC.

Personally, with ISC being default (and not knowing until later about deprecation), I'm still using it.
There's a migration tool (KeaMA). I'll look into it later...

[dseven]

I think there's a general consensus that Kea itself, and its integration into OPNsense, are "still maturing". I tried it for a while (also trying to be "future-proof"), then went back to ISC.

[OrlyP]

So just for the heck of it, I tried setting up ISC.

Apparently, it does not support multiple subnet pools on the same interface?

As mentioned a few posts back, I have an L-3 switch that does the inter-VLAN routing and then a single routed connection to OPNsense for Internet. The L-3 switch does DHCP relay and for the most part, works well in Kea (sans Option 150) but seems not possible in ISC.

So in summary:

Kea - Supports multiple subnet pools on the same interface (ie. LAN) but lacks vendor-specific Option settings
ISC - Supports ONE subnet pool per interface (or VLAN) on OPNsense. Apparently supports vendor-specific Option settings but I haven't gone that far to test it out due to the aforementioned limitation

[EricPerl]

I'm sorry but your configuration is beyond my skill level. Splitting VLAN management across the router and switch this way looks like a headache...