I have a new OPNSense install that I am setting up, and one of the new things I'm doing is using Kea as the DHCP server instead of the (apparently now defunct per https://docs.opnsense.org/manual/isc.html#isc-dhcp) ISC.
So far I really like Kea from a GUI perspective, it's much more straightforward and clear than ISC so I'd prefer to keep using it. However I am not getting DHCP assigned on my LAN. Interestingly, I am seemingly getting DHCP addresses on the VLANs (at least from a preliminary look). I know everything is setup correctly as setting a static IP on my desktop (on the LAN) works perfectly.
To confuse things further I went to Kea's logs and did a few searches which seem to indicate that it is seeing a DHCP request from my desktop and trying to issue a DHCP lease to it -- at least per my reading of the logs. I've attached the results of a search of the desktop MAC (which is not getting an IP via DHCP).
It turns out that while setting up I did unintentionally activate dnsmasq, but that has been stopped and OPNSense has been rebooted so I hope that's now just a red herring.
Post your interface assignments and IPs, Kea settings and subnets.
Quote from: coatmaker618 on October 15, 2025, 04:39:08 PMI have a new OPNSense install that I am setting up, and one of the new things I'm doing is using Kea as the DHCP server instead of the (apparently now defunct per https://docs.opnsense.org/manual/isc.html#isc-dhcp) ISC.
So far I really like Kea from a GUI perspective, it's much more straightforward and clear than ISC so I'd prefer to keep using it. However I am not getting DHCP assigned on my LAN. Interestingly, I am seemingly getting DHCP addresses on the VLANs (at least from a preliminary look). I know everything is setup correctly as setting a static IP on my desktop (on the LAN) works perfectly.
To confuse things further I went to Kea's logs and did a few searches which seem to indicate that it is seeing a DHCP request from my desktop and trying to issue a DHCP lease to it -- at least per my reading of the logs. I've attached the results of a search of the desktop MAC (which is not getting an IP via DHCP).
It turns out that while setting up I did unintentionally activate dnsmasq, but that has been stopped and OPNSense has been rebooted so I hope that's now just a red herring.
Quote from: pfry on October 15, 2025, 07:20:57 PMPost your interface assignments and IPs, Kea settings and subnets.
Is there any easy way to export those? I only ask as screenshots are kind of tough with the low filesize limit.
Quote from: coatmaker618 on October 16, 2025, 03:27:00 AMIs there any easy way to export those? I only ask as screenshots are kind of tough with the low filesize limit.
Heh. Not that I know of. I'm not an image-editing wizard, and I have bad eyes to boot. But it's tough to speculate without your config. I didn't see anything in the log that stood out.
Quote from: coatmaker618 on October 16, 2025, 03:27:00 AMIs there any easy way to export those? I only ask as screenshots are kind of tough with the low filesize limit.
Plenty of screenshots have been posted here without issues around file size. You can reduce size if needed while keeping it screen-viewable.
I use Kea so would try to help if I could see the settings.
Quote from: pfry on October 16, 2025, 04:32:29 AMQuote from: coatmaker618 on October 16, 2025, 03:27:00 AMIs there any easy way to export those? I only ask as screenshots are kind of tough with the low filesize limit.
Heh. Not that I know of. I'm not an image-editing wizard, and I have bad eyes to boot. But it's tough to speculate without your config. I didn't see anything in the log that stood out.
Hah, fair enough. Turns out it may be a red herring after all!
I just tried the old ISC DHCP server on the LAN interface and the desktop is STILL not getting a DHCP address. I've used that DHCP server enough to be reasonably comfortable with it, so I think it's pretty unlikely I did anything wrong there. Besides, now I have two DHCP servers not working!
So I'm thinking it must be something common, as in not the DHCP server itself but some other router setting? I'm at a loss, but I can give you the list of VLANs if that'll help, or (probably easier) delete most of them and re-add them once I have this working.
Here's what I can piece together. I've disabled a bunch of entries just for the sake of testing but it's still problematic.
you should check the log file in Services: Kea DHCP: Log File, be sure to set the log level in the pull down box to informational.
Also do you see kea listening on the expected interfaces from the ssh cli command as below example
root@OPNsense:~ # sockstat -ln | egrep -ai 'user|:67'
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
0 kea-dhcp4 19321 15 udp4 10.0.1.138:67 *:*
root@OPNsense:~ #
The total logfile is a bit long (a little over 5k lines, but I did a search for the MAC of my desktop as well as the MAC of a server getting a static assignment successfully via DHCP) so you can see the results of each. I guess I've been restarting the server a lot while debugging!
Per the command request:
root@OPNsense02:~ # sockstat -ln | egrep -ai 'user|:67'
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
0 kea-dhcp4 73038 15 udp4 192.168.1.3:67 *:*
0 kea-dhcp4 73038 17 udp4 192.168.2.3:67 *:*
0 kea-dhcp4 73038 19 udp4 192.168.3.3:67 *:*
0 kea-dhcp4 73038 21 udp4 192.168.10.3:67 *:*
0 ntpd 32097 23 udp6 fe80::5a47:caff:fe79:6752%igc0:123 *:*
These are just a couple of things I noticed and which caused me to pause. It is not an analysis but a couple of queries which may or may not matter.
In Kea(2).log it simply keeps offering 192.168.1.40 with no apparent reply, but why do the offers appear to be coming from 192.168.1.3 when your implied gateway in Kea Subnets is 192.168.1.1 (192.168.1.1/24)?
In your Kea(3).log you have a warning DHCPSRV_LEASE_SANITY_FAIL where it thinks subnet ID 4 should be subnet ID 3 (lines 4-27 of your log). This is described in Kea docs (https://kea.readthedocs.io/en/kea-2.2.0/kea-messages.html) as:
QuoteThis warning message is printed when the lease being loaded does not match the configuration. Due to lease-checks value, the lease will be loaded, but it will most likely be unused by Kea, as there is no subnet that matches the IP address associated with the lease.
It then appears to allocate successfully from 192.168.10.3
Ahhh, I can explain. So the 192.168.x.y is a format I'm using. The x represents the subnet, easy enough. The y is 3 for the router since there's a longterm goal of using this router in a HA/failover setup. I did setup CARP on each interface to be the .1 address but I turned that off days ago as it adds more complexity to troubleshooting.
But that's why you're seeing a strange number choice. I can turn CARP back on (or reboot yet again) if that would help (eg: if something is looking for .1 -- it shouldn't be a problem since this is the only router so it's always master/main on the CARP interface). But I hope that helps explain the strange IPs you're seeing (.3 for a router instead of .1).
Note that this is the same on 192.168.1.y & 192.168.10.y
Also, is 'implied gateway' just because a.b.c.1 is the started gateway or is it stated somewhere in the log/settings? I didn't see it, but I sure could be looking right at it and missing it.
Implied because it is the default or usual gateway in a /24 range.
What about the failure of a device to respond at all to an offer, or where is the client request? Is the client config consistent with the gateway?
Ok, just making sure it wasn't a problem.
Static assignment config is attached.
I don't think it's a client issue because everything works with the old OPNSense router. It's just old hardware and has some quirks built up after years of use, a fresh start seemed to be in order.
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?
Quote from: passeri on October 17, 2025, 07:24:32 AMThere 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"
From the server side, I guess nothing because I was jumping back and forth a lot with this.
Was there something more specific you wanted me to check?
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.
Quote from: coatmaker618 on October 18, 2025, 03:11:47 AMQuote from: passeri on October 17, 2025, 07:24:32 AMThere 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.
Quote from: passeri on October 18, 2025, 05:07:56 AMQuote from: coatmaker618 on October 18, 2025, 03:11:47 AMQuote from: passeri on October 17, 2025, 07:24:32 AMThere 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.
Quote from: passeri on October 18, 2025, 05:07:56 AMQuote from: coatmaker618 on October 18, 2025, 03:11:47 AMQuote from: passeri on October 17, 2025, 07:24:32 AMThere 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.
coatmaker618, this may seem pedantic but your answers are not actually clarifying things.
Quote from: coatmaker618 on October 18, 2025, 08:12:49 PMThe 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]:
<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
QuoteMy 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.
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.
"coatmaker618, this may seem pedantic but your answers are not actually clarifying things." Nah, that's a pretty important aspect of answering questions, given that I'm not running for office. Also, I appreciate your breakdown of assumptions.
What I really should've clarified is that I'm not sure I'm understanding what you were asking for exactly.
1. Check your client configuration is (if possible) pointed at your DHCP server
I'm not sure what configurations you want me to check when I set network info to "automatic". Doesn't that, by definition mean there are no configs?
2. In Kea reserve any address so long as it is outside your pool, using the client's MAC address
I appreciate you saying outside your pool instead of above here. I have several reserved/statically assigned IPs in Kea that work fine on other interfaces. In fact this is my preferred method of IP assignment. This includes the desktop, it already has a statically reserved IP in Kea on the LAN interface.
3. Ask the client to renew its lease
I admit I mostly do this by unplugging a cable rather than using release/refresh/renew commands, I assume that is sufficient (overkill) if I wait a few seconds? if not I can look up the commands, but given how messy things are right now, I do lean towards simple/overkill.
4. Show exactly what was the client configuration before you tried
Again, not sure what client configuration you would like.
5. Show /var/log/kea/latest.log where there is any record of the client's MAC or IP.
At the moment let us assume there is not -- since as you said my logs don't match yours. What does this mean, especially on the LAN?
An interesting note:
I ran into an issue a few days ago where I lost internet connection -- TL;DR that ended up being Verizon's fault but I was obviously suspicious & troubleshooting since things currently aren't stable.
During the course of troubleshooting I brought in my laptop (Linux) and noted that the laptop also does not get a DHCP lease on the LAN but also works fine with static IP. However laptop does get an IP on other network interfaces which interestingly the windows desktop does not. I don't know what logs you want from where, but let me know and I'll be happy to share.
This does make me think that there's something wrong with desktop, but I think there's also something wrong with LAN although it may NOT be Kea (I do not know what else it could be, gateway maybe as that's the other piece of info you provide in a static IP?).
Update: I found out that part of the problem is that when I introduced the new router I also introduced a new switch. It turns out that part of the problem is that the two switches (old & new) handle VLAN 1 differently, which is leading packets to be tagged to incorrect VLANs on incorrect ports leading to unexpected behavior. Since VLAN 1 is where my management ports are, I suspect that this is a major factor in the problems I'm seeing on that network.
While I don't know that this explains all the problems I'm running into, I do believe it explains enough that it warrants investigation. This "investigation" so to speak, is a complete rebuild of my network. This will obviously take some time, and I will report back when done -- hopefully with success.
I am happy that it seems (at least for now) that the problem is not Kea, or OPNSense at all.
This is why you should never use VLAN 1: Many manufacturers handle that internally as the equivalent of the untagged VLAN, which is technically not the same. In Proxmox, I use a restriction to only use VLANs 2-4095 for that very reason.
Sorry coatmaker618, I have been busy out of town for a while. It seems you have an angle to pursue so I'll wait on that. As I mentioned earlier, I am reasonably convinced at this point that your problem is not in Kea. I choose not to use VLANs so I cannot pursue that line with you.