Issue with Kea DHCP server

[coatmaker618]

Update: The rest of the interfaces (everything but LAN) are now working.  I forgot that by default all network traffic on those interfaces is blocked (which is a good default).

So now it's ONLY the LAN interface that's acting up.

Note: I did check the LAN, it has default allow all rules.  So sadly it's not the same problem there too.

[passeri]

There are no requests for, or allocations of, 192.168.1.42 in either log.

So what happens if you set assignment to DHCP rather than manual?

If I set assignments to DHCP (automatic) I don't get an IP on the client.
    "inet 169.254.41.44/16 brd 169.254.255.255 scope global dynamic"

Just to confirm, if the client knows the gateway and is set to get an IP by DHCP then it gets nothing? Is communication from LAN client to server verified as happening, e.g. with a ping?

What does the log show in that situation? Have you tried giving the client's MAC a reserved address above the .1-.199 pool? I found that where I wanted a fixed client IP I needed to reserve rather than relying on manual IP configuration of the client.

The situation is somewhat confused for me because I do not have a consistent case of basic client configuration with an associated log. You can also enable logs of LAN rules to verify the packets are passed on that interface. I am stopping short of packet tracing although that may be a next step.

[coatmaker618]

There are no requests for, or allocations of, 192.168.1.42 in either log.

So what happens if you set assignment to DHCP rather than manual?

If I set assignments to DHCP (automatic) I don't get an IP on the client.
    "inet 169.254.41.44/16 brd 169.254.255.255 scope global dynamic"

Just to confirm, if the client knows the gateway and is set to get an IP by DHCP then it gets nothing? Is communication from LAN client to server verified as happening, e.g. with a ping?

What does the log show in that situation? Have you tried giving the client's MAC a reserved address above the .1-.199 pool? I found that where I wanted a fixed client IP I needed to reserve rather than relying on manual IP configuration of the client.

The situation is somewhat confused for me because I do not have a consistent case of basic client configuration with an associated log. You can also enable logs of LAN rules to verify the packets are passed on that interface. I am stopping short of packet tracing although that may be a next step.

Just to confirm, if the client knows the gateway and is set to get an IP by DHCP then it gets nothing?
Not sure I understand the questions. I thought the gateway came with DHCP assignment from the DHCP server?

Is communication from LAN client to server verified as happening, e.g. with a ping?
Again, not sure what you mean here. Without the client having a valid IP on the subnet how can I ping?
That said, yes if the client is set to DHCP it gets nothing.

What does the log show in that situation?
The OPNSense log or client log?  I posted the OPNSense log here https://forum.opnsense.org/index.php?topic=49321.msg250177#msg250177  only filtered by MAC, so it should have everything with the desktop.  If there's another filter or something else you want me to post, just let me know.

Have you tried giving the client's MAC a reserved address above the .1-.199 pool? I found that where I wanted a fixed client IP I needed to reserve rather than relying on manual IP configuration of the client.
My pool is 100-199, so everything below 100 is actually reserved.

The situation is somewhat confused for me.
Me too!

You can also enable logs of LAN rules to verify the packets are passed on that interface. I am stopping short of packet tracing although that may be a next step.
I have every firewall rule log enabled. I've had too many issues where things weren't obvious and it's cause a firewall rule was allowing/blocking it unexpectedly.

[coatmaker618]

There are no requests for, or allocations of, 192.168.1.42 in either log.

So what happens if you set assignment to DHCP rather than manual?

If I set assignments to DHCP (automatic) I don't get an IP on the client.
    "inet 169.254.41.44/16 brd 169.254.255.255 scope global dynamic"

Just to confirm, if the client knows the gateway and is set to get an IP by DHCP then it gets nothing? Is communication from LAN client to server verified as happening, e.g. with a ping?

What does the log show in that situation? Have you tried giving the client's MAC a reserved address above the .1-.199 pool? I found that where I wanted a fixed client IP I needed to reserve rather than relying on manual IP configuration of the client.

The situation is somewhat confused for me because I do not have a consistent case of basic client configuration with an associated log. You can also enable logs of LAN rules to verify the packets are passed on that interface. I am stopping short of packet tracing although that may be a next step.

Just to confirm, if the client knows the gateway and is set to get an IP by DHCP then it gets nothing?
Not sure I understand the questions. I thought the gateway came with DHCP assignment from the DHCP server?

Is communication from LAN client to server verified as happening, e.g. with a ping?
Again, not sure what you mean here. Without the client having a valid IP on the subnet how can I ping?
That said, yes if the client is set to DHCP it gets nothing.

What does the log show in that situation?
The OPNSense log or client log?  I posted the OPNSense log here https://forum.opnsense.org/index.php?topic=49321.msg250177#msg250177  only filtered by MAC, so it should have everything with the desktop.  If there's another filter or something else you want me to post, just let me know.

Have you tried giving the client's MAC a reserved address above the .1-.199 pool? I found that where I wanted a fixed client IP I needed to reserve rather than relying on manual IP configuration of the client.
My pool is 100-199, so everything below 100 is actually reserved.

The situation is somewhat confused for me.
Me too!

You can also enable logs of LAN rules to verify the packets are passed on that interface. I am stopping short of packet tracing although that may be a next step.
I have every firewall rule log enabled. I've had too many issues in the past where things weren't obvious and it's cause a firewall rule was allowing/blocking it unexpectedly.

[passeri]

coatmaker618, this may seem pedantic but your answers are not actually clarifying things.

The OPNSense log or client log?  I posted the OPNSense log here https://forum.opnsense.org/index.php?topic=49321.msg250177#msg250177  only filtered by MAC, so it should have everything with the desktop.

kea(2).log or kea(3).log? You do not say. This is extracted from my opnsense kea log as an example of a successful allocation to a reserved address (opnsense.lan is a name substitution]:

Code Select Expand

<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="2"] INFO  [kea-dhcp4.packets.0x460dffe76008] DHCP4_PACKET_RECEIVED [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface igc0
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="3"] INFO  [kea-dhcp4.leases.0x460dffe76008] DHCP4_INIT_REBOOT [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: client is in INIT-REBOOT state and requests address 10.2.1.10
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="4"] INFO  [kea-dhcp4.leases.0x460dffe76008] DHCP4_LEASE_ALLOC [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: lease 10.2.1.10 has been allocated for 86400 seconds
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="5"] INFO  [kea-dhcp4.leases.0x460dffe76008] DHCP4_LEASE_REUSE [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: lease 10.2.1.10 has been reused for 81159 seconds
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="6"] INFO  [kea-dhcp4.packets.0x460dffe76008] DHCP4_PACKET_SEND [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: trying to send packet DHCPACK (type 5) from 10.2.1.1:67 to 10.2.1.10:68 on interface igc0
<134>1 2025-10-19T05:58:22+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="1"] INFO  [kea-dhcp4.dhcpsrv.0x460dffe5c008] DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup



My pool is 100-199, so everything below 100 is actually reserved.

Whether you choose a reservation below or above the pool is not critical The question at hand is to

• Check your client configuration is (if possible) pointed at your DHCP server
• In Kea reserve any address so long as it is outside your pool, using the client's MAC address
• Ask the client to renew its lease
• Show exactly what was the client configuration before you tried
• Show /var/log/kea/latest.log where there is any record of the client's MAC or IP.

As a precaution, you may want to restart Kea after step 2.

[passeri]

To clarify for my own part, I am working on information or hypotheses like these:

• I have spotted no errors in your Kea configuration.
• Kea is working for you on other sub-nets
• therefore, I do not believe there is a problem with Kea.
• Your initial logs show in one case zero client communication and in the other, a client being offered one address while manually wanting another, with no resultant communication or configuration.
• I have not seen evidence that the client has requested an address via DHCP
• therefore, I am trying to set up a controlled experiment to see whether there is any such communication in Kea's log.

Given I think the problem is not in Kea which is otherwise a critical component, we try to falsify that before looking elsewhere.