KEA not respecting reservation

[Dileep]

Hi All,

This issue remains unresolved for me, even after setting match-client-id to false.

System Details:

OPNsense Version: 25.7-amd64

FreeBSD: 14.3-RELEASE-p1

OpenSSL: 3.0.17

Observed Behavior:

On 19th Dec 2025, I created a DHCP reservation for the following:

Subnet: 172.26.80.0/20

Reserved IP: 172.26.84.178

MAC: 7c:0a:3f:xx:xx:xx

On the same day, I removed the device from the network and reconnected it after approximately 3 hours (maximum lease time is 2 hours). The device correctly received the reserved IP address as expected.

However, I powered off the device and reconnected it again on 21st Dec 2025, and this time it was assigned a different IP address (172.26.85.54) instead of the reserved one.

Below are the logs comparing the DHCP logs from 19th Dec and 21st Dec for reference.

19th Dec:

2025-12-19T16:27:59 Informational kea-dhcp4 INFO  [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: trying to send packet DHCPACK (type 5) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-19T16:27:59 Informational kea-dhcp4 INFO  [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_ALLOC [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: lease 172.26.84.178 has been allocated for 7200 seconds
2025-12-19T16:27:59 Informational kea-dhcp4 INFO  [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-19T16:27:59 Informational kea-dhcp4 INFO  [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8
2025-12-19T16:27:58 Informational kea-dhcp4 INFO  [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: trying to send packet DHCPOFFER (type 2) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-19T16:27:58 Informational kea-dhcp4 INFO  [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_OFFER [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: lease 172.26.84.178 will be offered
2025-12-19T16:27:58 Informational kea-dhcp4 INFO  [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-19T16:27:58 Informational kea-dhcp4 INFO  [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8

21st Dec:

2025-12-21T12:29:17 Informational kea-dhcp4 INFO  [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO  [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8
2025-12-21T12:29:17 Informational kea-dhcp4 INFO  [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: trying to send packet DHCPOFFER (type 2) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO  [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_OFFER [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: lease 172.26.85.54 will be offered
2025-12-21T12:29:17 Informational kea-dhcp4 INFO  [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO  [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8

As suggested in earlier posts, we have already configured match-client-id = false, but the issue persists. Interestingly, this behavior is not consistent across all devices—only a random subset of devices is affected, and this occurs across different device brands.

If anyone has observed similar behavior or has insights into additional DHCP options or client-ID–related handling in OPNsense that might cause this, I would appreciate your input.

Thanks in advance.