I'm relatively new to OpnSense (migrated over from pfSense after being disappointed in their release cadence). I have my setup working pretty much the way I want. I generally use all static DHCP on my network so I can better understand what is going on when problems arise. However, the other day, I noticed that on my primary LAN pool, while I have a pool of addresses defined (none of which currently in use), if I alter the MAC address on one of my static entries so my device now has to get an IP address dynamically from the pool, I never get allocated an address.
Is there some setting in KeaDHCP to prevent the use of pools? I've poked through the GUI but don't see any settings that would appear to cause this functionality. Is this a defect in 26.1.4? Its certainly possible I have just missed this issue for a while. As I said, most devices on my network have a static DHCP Reservation associated with them.
Yeah, if I switch my Reservation MAC back to match my device, voila, it comes right up. I've tested on multiple devices, if they ask for a DHCP address without matching a Reservation KeaDHCP knows about, it gets ignored. If I have a Reservation setup for the device, it works fine. My subnet is a class C and my pool goes from .11 to .40, so there should be plenty of addresses for it to doll out, if necessary.
Not sure if it matters but I don't have ISC DHCP installed anymore. I also have multiple subnets defined that are each on different VLANs. The subnet I am trying to use is the "default" LAN subnet. I believe this used to work, but its been a while since I might have even noticed. I'm not intentionally trying to do anything to prevent the use of DHCP IP pools.
Sorry for so many spam messages here. I believe I figured out part of the issue. On the Leases DHCPv4 tab, it is showing that KeaDHCP has dolled out all addresses in the pool. I guess it makes sense why it can't doll out any new ones. I am confused what these leases are though. One of them appears to be valid and has a hostname associated with my wife's phone (and a lifetime of 4000, the configured value of "valid lifetime"). The rest all have a large lifetime of 86400 and no hostnames or MAC addresses associated with any of them. Why would KeaDHCP doll out an address to a device without a MAC address?
A trick, you can leave the pool in a subnet empty (dont specify a range in it), then you can work reservation only.
I understand why someone might want to only allow reserved MACs on their network (with this issue, that is essentially where I am at now) but I am not interested in being that tight with my security. I am trying to figure out why OpnSense has dolled out all my pool addresses seemingly to devices not on my network (None of them have hostnames or MAC addresses associated with them)? I can reboot my router when I get a chance (after work) but this seems like a pretty bad "bug"/unintended consequence of something. Anytime KeaDHCP dolls out an IP address, there should be a MAC address associated with it, regardless of being a reservation (static) or not. Am I missing something?
Kea uses client identifiers per default. If you have some device that spams a lot of these they get a lease for each of them.
You can turn that behavior off in each subnet:
Match client-id
By default, KEA uses client-identifiers instead of MAC addresses to locate clients, disabling this option changes back to matching on MAC address which is used by most dhcp implementations.
I appreciate the suggestion but I already have that turned off.
Then you probably have misconfigured vlans.
Check if your setup follows the best practice for them:
https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html
I run a complex HA setup with many vlans, lagg and trunk and managed switches and KEA works fine with no weird things going on. I assume its a configuration or infrastructure issue on your end.
Technically I have VLANs on my network but in this case, OpnSense is running on Proxmox and Proxmox is configured with VLANs and exposes the interfaces to OpnSense. I also don't understand why KeaDHCP dolling out MAC-less IP addresses would have anything to do with VLANs. Everything with a Static reservation is working fine.
I also just rebooted, hoping that would flush the existing DHCP entries but it did not. There are still 39 dolled out IP addresses without a MAC associated with them (even though "Match client-id" is disabled).
Maybe I can ask this another way. If my "valid-lifetime" setting for the KeaDHCP server is 4000 (the default I believe), what does it mean when there is an entry with a lifetime of 86400?
Is there a way to flush the current DHCP cache? I've tried stopping and starting KeaDHCP, I have tried rebooting OpnSense but the entries remain. They are supposed to expire tomorrow. Is my only option really to wait?
I also checked my secondary VLAN which I have all my cloud-connected devices on (thermostats, smart light-bulbs, etc...). It has a pool configured as well but there are no DHCP entries other than ones with a lifetime of 4000.
How can I better debug this? Just hearing "it works for me" isn't very helpful. Can I attach some sort of config here to be analyzed? This used to work just fine. I'm not sure which upgrade caused the problem. Given 86400 is 24 hours, I suppose these could have been dolled out multiple times. I did recently upgrade to 26.1.4 but this doesn't necessarily mean that was the issue. As 95+% of my devices have Reservations, I may not have noticed this for a while.
This also all "just worked" in pfSense. If I can't get DHCP to work reliably in OpnSense, there really isn't a reason to use it.
kea dhcpv4 has the concept of lease affinity, which i use instead, so that returning dhcp clients can obtain the same IP lease, even after the lease has technically expired, but lease affinity not yet expired, it works great, and zero need to mess around with reserved DHCP leases...
Kea DHCPv4 Affinity lifetime is already exposed in OPNsense GUI
Defines in seconds for how long a returning client will be able to retrieve the same lease.
I have kea dhcpv4 lease time = 86400 seconds == 24 hours
and Kea DHCPv4 Affinity lifetime = 2592000 seconds == 30 days.
Ok, interesting side-note, thank you. I would still want reservations as the actual address given to specific hosts on my network is important to me (i.e. I know my printer is .110, my PC is .100, etc...). I don't just want addresses consistent, I want them consistently a specific value. While this information is interesting, thank you, it doesn't appear to be relevant to my issue.
Kea has dolled out 39 IP addresses with a lifetime value that doesn't appear to exist in my configuration and there is no MAC address or hostname associated with these entries. The entirety of the information in the DHCP Leases table is the interface they are on, the IP address given, blank MAC address, 86400 second lifetime (seemingly not configured anywhere I can find), expire time (tomorrow), blank hostname, and the fact they are dynamic leases.
I can't find a way to debug why these leases were given out, nor can I find a way to flush these entries. The only option OpnSense appears to give me is the option to make these entries static. I'm not even sure what that means though. With "Match client-id" disabled on this subnet, the entry should be a link between a MAC address and an IP address. Without a MAC address, how can I make this a reservation?
Thank you for the help.
For both devices that are always on, and devices that are intermittently on, but reconnect before lease affinity expires, zero need for dhcp reservations, it just works thanks to lease affinity.
And printers for several decades now, use SSDP | Bonjour mDNS protocol to advertise their IP address and service information, and modern OS also learn from both SSDP and mDNS propagation advertisements, to dynamically learn printer IP address and service to connect to.
Once the DHCP lease is assigned, it stays assigned ( reserved ) for the affinity lease period when devices are offline, and re-allocated when device connects, and re-allocated when DHCP renew event occurs..
The only time this would not work, is when the dhcp pool has insufficient number of leases, for the number of devices connecting to that particular L2 segment...or for device that do a DHCP release upon shutdown, i've only found one device that behaves this way...
I use KEA, but not actually with DHCPv6.
If you really have disabled DUID-based handout, one would argue that there must be different MACs associated with the filling of the pool. That could in theory by caused by some device(s) that change their MACs for privacy reasons, like iPhones do it these days.
However, what is strange is that apparently, the lease entries do not have a MAC or DUID associated.
My observation is that sometimes, I saw an abundance of IPv4s answering to my ping detection service on my LAN when I had "Interfaces: Neighbors: Automatic Discovery" active. If that serive is active on your OpnSense, I would disable it completely, stop Kea, clean out the DHCPv6 leases manually, restart Kea afterwards and observe if the problem goes away.
Do not ask why this happens - I never investigated any further, I just disabled the service. I cannot even tell if there were actual DHCPv4 leases in those situations. My theory here would be something like: The cause may be the way DHCP makes sure that no IP collisions occur by first pinging a tentative IP:
A (legitimate) client asks for an IP, Kea chooses one, but always gets a ping answer and sets it as reserved (but with no DUID and no MAC), afterwards, it switches to the next free IP, to which it again gets a ping answer, and this repeats until there are no pool IPs left.
Thank you meyergru. You are the first person to suggest something that could theoretically be relevant to my issue. While I don't have KeaDHCPv6 enabled, I did have the Automatic Discovery Enabled. I disabled it to give this a try. Nothing appears to have changed yet, but I guess I would not expect anything to change until these Leases expire.
When you say "clean out DHCPv6 leases manually", as I don't have DHCPv6 enabled, there are no leases currently under v6. Is there a mechanism to clean out v4 leases? On the leases page for these (invalid) entries without a hostname or MAC address, the only option OpnSense gives me for these entries is "add reservation". While I don't want these entries to have a reservation, I tried anyway (as that appears to be my only option). I was thinking maybe I could find a "pool" of addresses I wasn't using and assign these to different addresses outside of my DHCP pool. However, as there is no MAC address associated with these entries, the resulting pop-up to add the reservation fails telling me that a MAC address is required to add a reservation.
This feels like an OpnSense bug to me. Affinity or no, Automatic Discovery or no, any feature I can think of on or off, why would DHCPv4 add leases to devices without a hostname or MAC address? I won't claim to know the entire workings of the DHCP protocol, but my understanding is that a device configured for DHCP simply sends out a broadcast DHCP Discover packet with it's MAC address as the source. As OpnSense is my only DHCP server on my network, it receives that broadcast request and replies with an Offer. As I have "Match client-id" disabled, the DHCP server must use the MAC address of the request as it's key to the dolled out IP address (regardless if a Client ID is present in the discover).
So I am left with 2 questions:
1. How do I clear out DHCPv4 address mappings? I've tried rebooting the entire router, I've tried stopping KeaDHCP but whenever it comes back up, the cache remains.
2. Is there a mechanism for me to log a bug here? Or does anyone have an explanation as to why there are DHCPv4 entries without a hostname or MAC address associated with them? Especially with "Match client-id" disabled.
As I have been looking at this issue closer, I noticed one more thing. There are 3 devices on my network that I have existing reservations for but these invalid leases of time 86400 seconds and no MAC or hostname associated are set to use these IP addresses. So, not only can these leases be given addresses from within my DHCPv4 pool, they can also be given addresses that I have explicitly configured to be reserved for specific MAC addresses (outside of the pool configured for this subnet). Luckily I don't need to use these specific devices for anything right now but this makes the issue more severe from my point of view.
One of these devices is a Proxmox server. It is set to boot using the static IP address I assigned this reservation to, but I can't get to it on my network. This tells me this problem is pretty recent (around the time I upgraded to 26.1.4) as I was using this Proxmox server just a few days ago.
If whatever is going on here can overlap with any IP address on my network and make it unusable, how do I protect this from happening?
If I have not heard any relevant theories on this issue, I will try restoring my 26.1.3 OpnSense VM this evening. I make sure to backup my OpnSense VM prior to any upgrades.
Thank you.
I thought you meant DHCPv6 because of the DUID discussion. As to your questions:
1. I wrote that: Stop the Kea service, delete all entries from /var/db/kea-leases4.csv* or delete the files, start Kea again.
2. I told you how DHCP works in general: If a legitimate client asks for an IP, the DHCP server uses a presumably "free" tentative address from the pool and pings it. If it gets back an answer, it knows it cannot use that IP and uses the next free one from the pool. So if "something" makes "someone" reply to pings, this effect would ensue.
Note that I only know these things for sure:
a. I have seen ping replies for all IPs on my network when I had the host discovery service enabled. I cannot reliably reproduce that behavior, if I could, I would have done a bug report on Github.
b. I know that ISC DHCP works like I said in point 1. I do not know if Kea works the same or if it actually registers such tentative IPs as taken in its database, but my educated guess from your observations seem to indicate that. Also: how should it prevent using an already-dismissed IP otherwise?
P.S.: Going back to 26.1.3 or any 26.1.x version will not fix that problem (if that is the case), because the host discovery service was introduced with that. The only remedy if the host discovery service is the culprit would be to disable it - which I did shortly after I discovered the ping problems.
If you click on Interfaces: Neighbors, there is a tab for "Discovered Hosts". One of the 40 addresses in my pool exists in this table but it is the one that is correct/functioning. The rest of these DHCP entries (the ones in the pool and the ones not in the pool), none of these are in this Discovered Hosts table. While this seems like a plausible theory, the fact that none are in this table makes me feel like that is not my issue.
In /var/db/kea/ there are two files on my router. kea-leases4.csv does not contain any of these bogus entries. There is also a kea-leases4.csv.2 which does contain these entries. Again, no MAC, no hostname:
192.168.6.17,,,86400,1774014491,1,0,0,,1,,0
192.168.6.18,,,86400,1774014501,1,0,0,,1,,0
192.168.6.19,,,86400,1774014511,1,0,0,,1,,0
192.168.6.20,,,86400,1774014521,1,0,0,,1,,0
192.168.6.21,,,86400,1774014531,1,0,0,,1,,0
192.168.6.22,,,86400,1774014541,1,0,0,,1,,0
I will try moving this file in off hours. See if that helps.
I did not say that the host discovery service erroneously detects all hosts.
I think (but cannot reproduce) that the mere active service causes ping responses for any IP "somehow" and "sometimes" (I know that sounds strange given that I cannot reproduce this, but have seen it happen more than once). This alone lets DHCP think the IPs are active.
That has nothing to do with what the host discovery service detects. It works via ARP and NDP, supposedly, but I have not looked into it.
I repeat: If you want to rule this out, you should disable that specific service. Of course, the adresses can onyl be resused once they time out or are beig deleted. None of this has to be taken off-hours, because no step in it will cause service disruption of more than a few seconds - and above all, your DHCP cannot hand out IPs at this time, anyway.
If you leave the host discovery service running and I am right, the deleted IPs will get reserved again. Probaby, you do not need it - before 26.1., it did not exist.
The GUI collects from all lease files
https://github.com/opnsense/core/blob/faf1562b1c2999106d59b016433f4fa80a8ab302/src/opnsense/scripts/kea/get_kea_leases.py#L58
Its not always entirely clear which file contains leases that are actually truthy an in memory at the current moment.
(KEA documents how things should be, but experience while developing KEA features for OPNsense show that things are weird sometimes)
Quote from: stauf on March 19, 2026, 01:27:01 PMIs there a mechanism to clean out v4 leases?
I believe there was some talk on the forum about adding such a feature to the KEA webGUI part of OPNsense :)
Quote from: hharry on March 19, 2026, 02:27:31 AMAnd printers for several decades now, use SSDP | Bonjour mDNS protocol to advertise their IP address and service information, and modern OS also learn from both SSDP and mDNS propagation advertisements, to dynamically learn printer IP address and service to connect to.
Which is horrible and luckily can be disabled via the webGUI of my printer to avoid unnecessary Multicast traffic ;)
And everything works just fine without it too! LOL!
Right, I agree. While having the "Affinity lifetime" is nice, but for me personally, it has zero relevance to my desire to use Reservations. My "need" for reservations is partly my brain (I am a person that remembers numbers and I want to define the addresses my devices are using) and party for hosts like Proxmox. It wants a static address defined and does not want to use DHCP (even if the back end of DHCP would always send a consistent IP). So what I do is setup a reservation that is essentially never used. Proxmox uses the address statically and since KeaDHCP is setup with a reservation, it doesn't doll out that address to anyone else (at least it shouldn't). I suppose I could create another subnet for hosts that have static IP addresses and just not have DHCP running, but my current strategy has always worked, so why complicate things further?
I noticed that even with "Automatic Discovery" disabled, these erroneous DHCP entries refreshed themselves after the 24 hour lifetime expired. So I decided to go in and delete them manually. I stopped KeaDHCP, manually removed these entries from the kea-leases4.csv.2 file and re-started KeaDHCP. The addresses disappeared and the one Proxmox server (I have 4) that was not working is now accessible.
However, now I am noticing something strange starting again. I have 2 deployed containers on this proxmox server. Nothing I "need", just playing around. One is bentopdf, which allows for PDF editing and the other is ConvertX, which does file format conversions. I've used both of these containers multiple times and they have been great. They have worked and were accessible from the single IP address they are configured for. For some reason, KeaDHCP is now adding all sorts of entries for these two containers. What is really strange is that it is adding two entries for each IP address, one, like before, has a lifetime of 86400 seconds, no MAC address and no hostname and claims to be dynamic. The other is a static entry (which I don't have defined), but is mapped to the same IP address. At this point, I am not quite sure what to do short of starting to do some wireshark traces when I bounce KeaDHCP. These containers are set for a single IP address yet KeaDHCP seems to think they are configured for all sorts of addresses. If I ping any of the address KeaDHCP thinks are associated with that container, nothing responds (as expected). I have no idea how KeaDHCP could be filling these entries in.
I suppose the good news is that I can stop KeaDHCP and manually edit these csv files in /var/db/kea/ and blow away these erroneous entries. When I have time, I will try to get a Packet Capture after resetting KeaDHCP and see if I can find any DHCP requests that would account for this behavior.
Quote from: nero355 on March 19, 2026, 04:22:40 PMQuote from: stauf on March 19, 2026, 01:27:01 PMIs there a mechanism to clean out v4 leases?
I believe there was some talk on the forum about adding such a feature to the KEA webGUI part of OPNsense :)
Quote from: hharry on March 19, 2026, 02:27:31 AMAnd printers for several decades now, use SSDP | Bonjour mDNS protocol to advertise their IP address and service information, and modern OS also learn from both SSDP and mDNS propagation advertisements, to dynamically learn printer IP address and service to connect to.
Which is horrible and luckily can be disabled via the webGUI of my printer to avoid unnecessary Multicast traffic ;)
And everything works just fine without it too! LOL!
Bonjour is inherent part of the Airprint protocol developed by apple, and is widely used my millions of users worldwide...the volume of mDNS traffic from Bonjour is minuscule / insignificant, and if it was as 'horrible' as you claim, then apple, Microsoft and Linus would have abandoned Airprint/mDNS support long ago...but they haven't, as it's been a huge overwhelming success! significantly simplifying adding a printer to a network for the masses...
Quote from: hharry on March 20, 2026, 01:44:08 AMit's been a huge overwhelming success! significantly simplifying adding a printer to a network for the masses...
But we are not the masses here, now are we ? ;)
I never understood why, in forums like this, you ask a questions about one thing and, invariably, someone has an axe to grind and insists on trying to alter your workflow. I'm not asking question A in an attempt to get answer B. If you like Bonjour and not using Reservations, that's great, hooray for you. However, just because it works for you, doesn't mean it should be everyone's solution. Also, Bonjour or no, Affinity or no, the information is irrelevant to my issue. No need to hijack someone else's thread.
Anyway, I'm not 100% sure what changed, the only config change I made was disabling Automatic Discovery under Interfaces -> Neighbors. I still had to manually remove these erroneous entries (they were refreshing even with Automatic Discovery disabled) and still don't understand why they would be populated in the first place. I have 1 device (IP) in the dynamic pool of addresses that would be responding and it was setup properly in OpnSense with a 4000 second lifetime and its MAC and hostname were accurate and present. None of the other addresses that were populated by KeaDHCP were addresses that exist, nor were there responses to pings to those addresses. Even if I wanted Automatic Discovery enabled, if there is nothing to respond to the ping, why would the DHCP entry be filled?
Furthermore, I did notice that Automatic Discovery re-enabled itself once after I disabled it (and yes, I applied my change). This may explain why a number of entries re-populated the DHCP cache after I manually removed them.
At this point, things appear to be working properly but I have to say, this experience certainly did not give me a warm/fuzzy feeling about OpnSense. Hopefully Automatic Discovery remains disabled. I suppose if this happens again, the workaround to manually clean it up isn't too bad, I just have to SSH in, get into the shell and manually edit these csv files. Not a problem for me, but its just more than casual users would want to have to do.
Im not sure how automatic discovery can cause any side effects to DHCP.
It's a daemon that attached via netmap to each interface, /without/ promiscuous mode.
The daemon is completely passive, it does /not/ probe actively for devices with icmp.
There should be no technical explanation for any of this.
https://github.com/opnsense/hostwatch
If its disabled of course the entries still auto populate because that are essential kernel features (ndp and arp) that are a requirement for layer2/3 functionality.
I don't know the algorithm Automatic Discovery uses, nor am I 100% sure it caused these problems. Maybe I can do some testing this weekend. It certainly appears that Automatic Discovery added DHCP pool entries for IP addresses that are not being responded to on my network. As I understand it, Automatic Discovery would systematically ping every device on defined subnets and map out what it finds for you? It certainly appears as if in some cases (my entire dynamic pool and a few of my reserved addresses) it sends out the ping but decides to add a 24 hour DHCP cache entry for that IP. Since there is no response to the ping, there is no MAC and no hostname to associate with that entry. One would assume that if nothing responds, OpnSense should not maintain the DHCP entry for that IP. I'm guessing at this point but that is certainly what appears to be what is happening on my network.
Out of curiosity, is anyone successfully using the Automatic Discovery feature and verifying the discovered devices are correct?
Just to quote myself again:
The daemon is completely passive, it does ***NOT*** probe actively for devices with icmp.
Interesting, thank you. Someone was saying that Automatic Discovery sends out pings but I guess that is not the case. The documentation I can find on it shows that it just listens for ARP and NDP messages. Feels like there must be some defect(s) in the Automatic Discovery. If all it does is listen for ARPs and update it's cache if there are devices on the network changing their IP -> MAC mappings, or devices with static entries not using OpnSense to get an IP address, but they would need to send out ARP requests to populate their own ARP cache if they want to talk with other devices on the network. I can't think of anything (other than malicious/malformed ARPs, which I am certainly not sending...at least not intentionally, on my network) that would explain why OpnSense would populate entries in its DHCP table when there is no device on the network that is sending those ARPs.
It might be a nice feature to add a tag to any KeadDHCP MAC->IP entries in the csv files. Basically how was this entry learned. There is already a "Lease Type" column that says it is either static or dynamic. Might be nice to have an "automatic" maybe?
As I have Proxmox and multiple hosts on individual ethernet interfaces, there could be multiple IP/MAC combinations on the same interface, but from an OpnSense point of view, that should not matter at all.
I don't have v6 configured on OpnSense so I assume, even if Automatic Discovery is on, any rogue v6 NDP packets on my network would just get dropped? I suppose in my case, it's a moot point as there are no entries in the KeaDHCPv6 table.
When Automatic Discovery is enabled and it sees ARPs and keeps track, what is the next step? Does it just populate the KeaDHCP cache? Does it create a table somewhere else?
I had reactivated the host discovery service again after this discussion. All went fine until yesterday, when I observed that on one of my VLANs, devices stopped to use their assigned reservations and started to use pool IPs. I had to stop the host discovery service and also delete the lease files completely to fix it, because removing only the affected leases did not work.
At the same time I saw multiple warnings in the Kea log like:
WARN [kea-dhcp4.alloc-engine.0x45007886b008] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 b0:f2:08:33:33:33], cid=[01:b0:f2:08:33:33:33], tid=0x94985f43: conflicting reservation for address 192.168.9.6 with existing lease Address: 192.168.9.6
I only noticed it, because one of the affected IPs was directly monitored and I got an alarm that it became inactive (because it was on another IP).
If I did not notice that so early, this might have ended up in a situation like I described, where after a while, all IPs on the subnet would have been taken and my ping-based network monitor would have shown all IPs as active.
I still do not know how this happens, but I never saw it without the host discovery service. I know that it does not ping by itself and from glacing over the code, I cannot see why or how this should respond to pings, either. Maybe the code triggers an obscure side-effect.
Well good to know. I was going to try to turn on Automatic Discovery and see if I could find a rogue ARP request on my network causing OpnSense to mis-behave like this, but, for now, I think I am good just leaving it off. I, personally, don't really Automatic Discovery and it appears it does more harm than good at the moment. Thanks for checking into it.
Same issue here w/ OPNsense 26.1.4. ICS-DHCP is not installed anymore and DNSmask DHCP is disabled, so only KEA is running.
The DHCP range is going from .200-.249. All IP adresses in the DHCP range AND all unused IP addresses outside the DHCP range are blocked, even for inactive clients w/ fixed leases.
Effectively there is no chance for a client to obtain an IP address at the moment.
This is causing some trouble.
Is there a workaround or a fix in the near future?
If not, I need to get back to ICS or DNSmask DHCP for the time beeing.
The installation was a fresh ISO 26.1.2 installation.
I assume it would make sense to check the KEA logs then why it assigns these leases?
Frank,
For me, there seemed to be two workarounds and my "fix" was to disable Automatic Discovery.
1. Disable Automatic Discovery and wait.
2. If you need a solution faster, you can follow the instructions earlier in this thread. SSH in (you may have to enable SSH), get into the shell and then go to /var/db/kea/. There should be at least 1 .csv file in here. Stop KeaDHCP, edit these files removing the incorrect entries. This may take a few minutes to ensure you do it correctly as the files don't appear to be in order and there may be multiple (I had 2). Restart KeaDHCP. For me, I did this live. I was stuck with all my addresses "in-use" so there didn't seem much harm to me doing it live. Didn't appear to make anything worse. Even with Automatic Discovery disabled, I did have to do this a couple times, but now, a couple days later, I see no erroneous entries in my cache.
As a side note, I did experience Automatic Discovery seemingly turning itself on once. I had disabled and applied but then noticed it was on again sometime later. I was never able to reproduce this so not sure what caused it. I will just caution you to double check a few times that it is disabled, just in case.
I've read the recommendations earlier and disabled "Automatic Discovery". In a first instance this doesn't help.
Maintaining the csv file in /var/db/kea/ was helping, but an hour later all IP addresses have been "in use" again.
The proxmox comment is also the same here. I'm running 2 proxmox nodes, and 2 container are the root cause for utilizing the IP addresses, identified by the MAX addresses in the "Automatic Discovery" log when this was still activated. I coudn't figure out what is different at the two containers compared to the oder ones, apart from the fact, that the interfaces had only IPv6 addresses assigned. But I'm not using nor deploying IPv6 adresses at all by KEA. And no other DHCP server is running. - weired!
I'm also not using VLAN - yet.
FYIY, the csv files do not always represent the current in-memory state of the leases in the KEA daemon itself.
I'm going to address this to make the GUI reflect the correct state more closely by polling the control socket.
https://github.com/opnsense/core/pull/10019
To reinstate something: Automatic Discovery and KEA are two completely different daemons that listen for completely different protocols.
Automatic Discovery -> Listens passively for NDP and ARP messages
KEA -> Listens/responds for DHCPv4/v6 messages
Now please stop all the guessing as there is no overlap in these protocols.
Thanks, that makes total sense based off what I saw. I disabled Automatic Discovery and cleaned up the csv files, but that did not completely fix my problem. Some of the erroneous entries were still showing up in the table. To be fair, once the problem was "mostly" solved, that was enough for me at the time and I didn't pay super close attention to every detail. All I can say is the next day, all of these 86400 second lifetime, MAC-less and hostname-less entries were totally gone from the KeaDHCP Leases table and, so far, have not come back.
Frank, are you saying you are getting buildup of what appear to be erroneous entries in your KeaDHCP Leases table and you have verified that Automatic Discovery is disabled? I'm a bit confused by your statements. You say you aren't using v6, but have v6 addresses assigned? If you have KeaDHCPv6 disabled, these may just be auto assigned v6 addresses by Proxmox or your containers running on Proxmox.
I have not observed my KeaDHCP pool get used up while Automatic Discovery is Disabled nor was I scrutinizing the logs. If you have logs referring to Automatic Discovery, sounds to me like you might still have it enabled.
I may have found the answer - and the observed problem is most probably uncorrelated to the host discovery service.
Matter-of fact, Kea uses two files to register dynamic leases: kea-dhcp4.leases.csv and kea-dhcp4.leases.csv.2. One of them is a journal that is sometimes flushed to the other file: https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#why-is-lease-file-cleanup-necessary
Also note, that unlike with ISC DHCP, Kea registers static reservatione in these files. If you then change something in the reservation, say, for instance, you change a MAC because you exchange a VM for another on your Proxmox host after an upgrade and want to keep its IP or if you only move a client to another VLAN, the lease file will still hold the old entry. Matter-of-fact, that was exactly what I did before the problem that I described before occured again.
When the newly created client with the static reservation now requests an IP via DHCP, there will be a conflict with the message I showed above (https://forum.opnsense.org/index.php?msg=263328).
What is more, is that this seems to trigger a cascading effect in Kea which seems to be a bug and is also discussed here for the "other product":
https://forum.netgate.com/topic/198115/changing-the-mac-address-on-a-kea-static-lease-does-not-work/4
At least one of you who observed the same problem also uses Proxmox, so it is kind of likely that something like this occured.
Thus, for the time being, it seems advisable to stop Kea, manually delete conflicting (or all) leases from both lease files and start Kea again when changes to static reservations are made.
I just did it a bid more radical, after i've identified the two container on proxmox:
1. I've stopped KEA
2. I've renamed both KEA csv-files, no other files exist in that folder (just to keep them)
3. I gave the two proxmox container a new MAC-address (both hat multiple IPv4 addresses assigned to just 1 (!) MAC-address
4. I've maintained the new MAC-addresses in KEA as fix leases for the two proxmox container
5. I've fired KEA up again, immediately a new file "kea-leases4.csv" was created
6. I've fired up the two proxmox container
7. The fix leases are correctly assigned to the proxmox container
Finally, no weired assignments w/ 86400 seconds and no MAC address and no name appear in the csv-file
Out of curiosity, why was Automatic Discovery defaulted to enabled? While I understand this feature could be valuable to some people, most products I have been involved with, new features default to disabled. This allows for easier upgrade/downgrade to/from versions of sw that support/don't support the feature and essentially assures users that new features won't break what they currently have working. I know there were warnings about Automatic Discovery and shame on me for not diving into this more actively, I guess I am just curious at a higher level that this specific feature. Is there a case-by-case discussion on new features deciding to default them to enabled or disabled?
I can certainly imagine some features aren't as clear cut at this one to have them enabled or disabled, but this one seems pretty clear as it is just another daemon sitting there listening for ARPs/NDP messages. Just seems odd to me that it would be enabled by default.
After 48 hours I can confirm, that the procedure above is working.
Non of the weired IP-address reservations was comming back so far.
Even after upgrading to 26.1.5 it's all quiet.
Quote from: stauf on March 23, 2026, 11:00:35 PMOut of curiosity, why was Automatic Discovery defaulted to enabled?
Because it's new and needed for features that will be added or improved in the future and all of us running the Community Edition of OPNsense are technically the ones that test new stuff before it's added to the paid Business Edition :)
However...
They did DISABLE it by DEFAULT in the NANO IMAGE since that's an image that is meant for devices with minimum logging to the storage device :) /EDIT :See : https://forum.opnsense.org/index.php?topic=51324.msg265896#msg265896
For the correct status of this!
It turns out I misunderstood a post in the past... Oops! :)
In the spirit of testing, any idea why I am getting my address pool filled with these bogus entries? Its happening again and I can confirm that I have Automatic Discovery disabled (at least that is what the UI is telling me). Kea is giving away all my IP addresses (even those reserved for specific MAC addresses). This means if the address has been given away before my device grabs it, there are no free addresses to give out and my device doesn't get an IP address at all. This is causing big problems on my network.
All the bogus DHCP table entries in Kea have a lifetime of 86400 seconds (not the lifetime of my standard leases). This is what I was seeing before but I thought we narrowed the problem down to Automatic Discovery being Enabled. I don't mind enabling Automatic Discovery and helping test this (especially since it appears to be happening with Automatic Discovery disabled), it would be helpful to work with someone that was actively working in this area though. Maybe I am doing something wrong?
Regardless of my setup, I would not expect Kea to dole out IP addresses without associating them with a MAC address or hostname. What is the point of doing that other than gumming up the works of the DHCP server?
When you read my explanation (https://forum.opnsense.org/index.php?msg=263439) again closely, you will find that your problem is completely unrelated to the automatic discovery, thus any more complaining about that won't help you a bit.
What really helps to clean up the mess once is also given in my post.
The final solution to this is to use the newly created "delete lease" button in the Kea leases window, which should take care of cleaning out the old lease correctly.
Also the latest update only presents leases from the running KEA socket, no more reading the memfile csv data. The GUI is now as closely to KEA internals as possible.
If there are still unexplainable issues consider asking on the KEA user mailing list.
https://lists.isc.org/mailman/listinfo/kea-users
But please note that if you write random stuff you most likely wont get an answer.
Quote from: nero355 on March 27, 2026, 03:22:43 PMThey did DISABLE it by DEFAULT in the NANO IMAGE since that's an image that is meant for devices with minimum logging to the storage device :)
Not at the moment. It's on my wishlist for the next nano images, but it hasn't been discussed internally yet.
Cheers,
Franco
Quote from: franco on April 24, 2026, 08:55:35 AMNot at the moment. It's on my wishlist for the next nano images, but it hasn't been discussed internally yet.
Oww... OK... I misunderstood then...
** Editing previous post now!
I'm exhumating this thread to give this reference:
https://github.com/opnsense/core/issues/10285
https://github.com/opnsense/core/pull/10294
This probably solves some things described over the course of this thread.
Quote from: Monviech (Cedrik) on May 12, 2026, 11:23:33 AMI'm exhumating this thread to give this reference:
https://github.com/opnsense/core/issues/10285
https://github.com/opnsense/core/pull/10294
This probably solves some things described over the course of this thread.
Thank you for the effort! :)
I think it's something I would like to have DISABLED too so I can't wait to update now! LOL!