Kea DHCP Reservations Not Being Honored

KStarRunner

For all of my subnets, I have a portion that's for reservations and a portion for dynamic issuance.

For example, on the 192.168.100.0/24 subnet,
192.168.100.10 - 192.168.100.50 is for reservations.
192.168.100.100 - 192.168.100.150 is for dynamic issuance.

Back in the ISC DHCP days, a new device would be connected to a subnet, it'd get an IP (say 192.168.100.101). I'd then get the MAC address from DHCP status page, and assign it a reservation (say 192.168.100.20). Then, the next time the device reboots it'll get it's reserved IP.

Since switching to Kea, this doesn't happen. Now, once a dynamic IP address has been assigned, Kea will ALWAYS issue that dynamic IP (in my example, 192.168.100.101). Doesn't matter that I created a reservation, or rebooted the device, or forcing an address renewal.

If I switch back to ISC, all those systems on dynamic IPs switch back to their assigned reservation at their new refresh.

As best I can tell, if I pre-create the reservation before the device is connected, Kea will give it that reserved IP. But, if a new device is one for even a second, Kea will ALWAYS give it a dynamic IP. No amount of effort on my part can get Kea to give out its reserved IP.

Is this a bug? Is there a known workaround? Every other DHCP server I've used will honor reservations over long-expired dynamic leases.

patient0

@KStarRunner Are you on pfSense Plus 24.11? It is working as expected for me, with Linux clients.

KStarRunner

@patient0 Yes, pfSense+, 24.11-RELEASE (amd64)

Having issues with iOS, MacOS, Windows 11, Windows 10, and multiple IOT devices (don't know what underlying OS). Haven't had to create a reservations for Linux since the switch to Kea.

tedquade

@KStarRunner I'm on 24.11 and not seeing this with a variety of Windows 10 and 11 clients along with a bunch of Linux devices and some mystery os Iot devices, two Android cell devices and 2 Canon printers.

Ted

patient0

@KStarRunner And in the DHCP logs of pfSense you see entries for KEA giving out the dynamic leases to these devices. What are the DHCP lease times?

Addition: I have only Linux VMs to work with at the moment: just added one and it work as it was with ISC DHCP

What's listed in the lease file, /var/lib/kea/dhcp4.leases. MAC address correct as listed by dynamic address?

KStarRunner

@patient0 For testing reasons, I reduced the DHCP lease time to 600s.

Below is the dhcp4.leases and a cropped DHCP leases page. The big things I've noticed: The DHCP status page shows both the reservation and the dynamic IP for the same MAC address. In this example, Win10, MacOS, and iPadOS. The dhcp4.leases file ONLY has the dynamic address for the problematic devices.

Of note, not all of my reservations are reflected in dhcp4.leases file. Is there someplace that Kea is pulling reservations from? I.e. is there some other config file that might be getting corrupted?

I tried clearing out the contents of dhcp4.leases and dhcp4.leases.2, but that didn't change the behavior. It's as if Kea doesn't know about the reservations (i.e. the web GUI is not updating a config file that Kea uses).

KStarRunner

Answered my own question. I checked /usr/local/etc/kea/kea-dhcp4.conf, all my reservations are showing up there (including the ones from the above screenshot).

KStarRunner

This is interesting though, when I restart Kea, I get the below in the DHCP log. I get it for every interface configured with DHCP.

Dec 11 16:14:59 XXXX kea-dhcp4[XXXX]: WARN  [kea-dhcp4.dhcpsrv.XXXX] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface XXXX.2, reason: failed to bind fallback socket to address X.X.X.1, port 67, reason: Address already in use - is another DHCP server running?
Dec 11 16:14:59 XXXX kea-dhcp4[XXXX]: WARN  [kea-dhcp4.dhcpsrv.XXXX] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface XXXX.3, reason: failed to bind fallback socket to address X.X.X.1, port 67, reason: Address already in use - is another DHCP server running?
Dec 11 16:14:59 XXXX kea-dhcp4[XXXX]: WARN  [kea-dhcp4.dhcpsrv.XXXX] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface XXXX.4, reason: failed to bind fallback socket to address X.X.X.1, port 67, reason: Address already in use - is another DHCP server running?

KStarRunner

Okay, I figured it out. When I stopped Kea via the web GUI, there was still a Kea process listening on UDP 67:

sockstat -l | grep :67

So I killed the rouge Kea:

kill -9 XXXX

Then restarted Kea via the web GUI. Now the binding errors are gone, and my reservations are being honored.

Super weird issue, no idea how I ended up with two running instances of Kea.