As an enthusiast of cutting-edge network solutions, I eagerly transitioned to Kea DHCP on my pfSense firewall shortly after its release. While exploring its capabilities, I encountered a perplexing issue: the inability to resolve names for locally assigned static IP leases. Although dynamic assignments should inherently support resolution, the lack of it for fixed leases was a notable drawback. Despite this, I adapted and continued using Kea, navigating around this limitation within my home network. Aside from occasional, unexplained Kea DHCP server outages that necessitated a full firewall restart – a rather disruptive quirk – my network operation remained relatively stable.
Recently, a network modification involving the relocation of my IP PBX to a new subnet brought to light a more critical problem. This change required updating provisioning files with the new server address and configuring the TFTP server address within the DHCP options. Kea DHCP seemingly offered a dedicated “tftp server” option within its interface, suggesting a straightforward setup.
However, reality diverged sharply from expectation. My IP phones, upon booting, would obtain an IP address, briefly display an “error” message, and then reboot – entering an endless loop. After meticulously reviewing my configurations and confirming the correctness of the overall procedure, I resorted to packet sniffing to diagnose the issue at a deeper level.
Analyzing the DHCP Discover response from the Kea DHCP server revealed a standard set of options:
- Option 53: DHCP Message Type (Offer)
- Option 1: Subnet Mask
- Option 3: Router
- Option 6: DNS
- Option 12: Hostname
- Option 15: Domain Name
- Option 51: Lease Time
- Option 54: DHCP Server Identifier
- Option 255: End Option
Notably absent was the “tftp” option that I had explicitly configured within the pfSense DHCP Server options. This discovery prompted further investigation into how to incorporate custom options beyond those available in the GUI. Consulting the Kea documentation, I proceeded to manually edit the /usr/local/etc/kea/kea-dhcp4.conf file. Within the option-def section, I added the following definition to recognize the TFTP server address option:
{ "space": "dhcp4", "name": "tftp-server-address", "code": 150, "type": "ipv4-address" }Subsequently, I navigated to the subnet configuration and included the TFTP server address within the option-data array:
{ "subnet": "192.168.1.0/24", "option-data": [ { "name": "tftp-server-address", "data": "192.168.1.1" } ] }After validating the configuration and restarting the Kea DHCP server, I re-examined the network traffic. Disappointingly, the TFTP server information remained absent from the DHCP Offer. A precautionary reboot of the firewall yielded no change. The TFTP server option was simply not being transmitted.
In a move to isolate the issue, I switched the DHCP server configuration from Kea back to ISC DHCP. Almost instantaneously, the IP phone, which had been perpetually rebooting, initiated the configuration loading and provisioning process. This stark contrast immediately highlighted a significant discrepancy in functionality between the two DHCP server implementations.
This experience raises a critical question: how can a DHCP server software lacking such fundamental option support be presented as a viable solution, particularly in environments where specific DHCP options are essential for device provisioning and network functionality? While I understand that pfSense offers flexibility to choose between different software packages like OPNsense or others, the fact that Kea, a product aimed at the B2B market, exhibits such limitations is concerning. Should businesses be compelled to rely on supplementary hardware or complex workarounds to compensate for core DHCP server deficiencies? (For instance, employing an IP helper on a Layer 3 Cisco switch, although feasible, feels like an unnecessary complication).
While I made a genuine effort to utilize Kea DHCP for an extended period, these recent and critical shortcomings in its functionality, specifically the inability to reliably pass essential DHCP options like the TFTP server address, prevent me from recommending it for production environments. The lack of basic features and unexpected behaviors raise concerns about its maturity and suitability as a robust DHCP server solution, especially when considering the prominent deprecation warnings associated with ISC DHCP, which has proven to be a stable and feature-rich alternative.
