As 25.03 Beta now proposes :

77f0b954-93ab-4ded-b923-ba3cb11a5348-image.png

Get yourself a small guided tour in here : /usr/local/etc/kea/kea-dhcp6.conf
and see how the reservation section is made.
With this knowledge, create your own 'JSON' structure that doubles a lease reservation and past it in the what I've shown above.
What you entered will be 'lint' tested, and beware : kea (json) is picky. Syntax errors are forbidden.

When saved (and pfSense did't explode ^^) go to the DHCP serbver logs and see if kea complained.
If it does, and knowing that kea is "RFC" compliant (right ?), the issue is solved : It's not possible to make double leases as its not allowed.
If it does accept : make a feature request ?!

@RyanM said in switch over from ISC DHCP to Kea DHCP:

I use static DHCP leases and that they are registered in DNS (unbound). ... Any idea when this will become available in CE?

That's a good question. Or better again "Has pfsense Kea DHCP implementation reached feature parity with pfsense ISC DHCP implementation"?

The reason this is a good question is Netgate messaging on the subject has been atrocious in the past. Made worse as somehow they tried to argue miss leading messaging was OK because if you knew it was miss leading you could go to another source, read it carefully and excused them as they left a caveat there.

My reading of the release notes https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html#general suggests Netgate's pfsense Kea implementation has improved but I'm not sure if it has reached feature parity yet.

The warning

ISC DHCP has reached end-of-life and will be removed in a future version of pfSense.

Is relevant to Netgate internal Kea development prioritization but blatantly inappropriate IMO in an inbuilt pfsence warning without their Kea implementation reaching feature parity or at least including a link to a comparison table in the warning.

Hopefully they have reached feature parity now so this concern is no longer relevant.

@ajperson1927
Are your locations not separated clearly in the public DNS?

Just to start, I'm trying to get firstlocation.example.com working within the first location. I have created a domain override in the DNS resolver.

A domain override means, that DNS request for firstlocation.example.com are forwarded to the stated IP address.
You will need to create host overrides for this.

@Terho said in Kea DHCP4 lease file cleanup failed and crashed pfSense:

Two last system log messages just before network was lost:

These are ordinary 'INFO' messages signaling that it was about to clean its less file.
Nothing special, happens all the time.

@Terho said in Kea DHCP4 lease file cleanup failed and crashed pfSense:

DHCP renewal time was 600 secs

Are you sure about that 600 seconds ? 😲
This means renewal happens after 300 seconds.
Why so low ? 7200 seconds or more, ok. 600 is waaaaay to low.

Btw : have a look at the var/lib/kea/ folder, check (read, look at them, the files) where the leases files are stored.
Nothing special ?

Mine are a couple of Kb in size :

[25.03-BETA][root@pfSense.bhf.tld]/var/lib/kea: ls -al total 31 drwxr-xr-x 2 root wheel 6 May 19 11:29 . drwxr-xr-x 4 root wheel 4 Nov 19 2023 .. -rw-r--r-- 1 root wheel 17078 May 19 12:22 dhcp4.leases -rw-r--r-- 1 root wheel 5422 May 19 11:29 dhcp4.leases.2 -rw-r--r-- 1 root wheel 169244 May 19 12:22 dhcp6.leases -rw-r--r-- 1 root wheel 4635 May 19 11:29 dhcp6.leases.2

@jhg

pfSense CE on ...

What version ?
When the issue happens, was unbound listening on IPv6 LAN interfaces ?

[25.03-BETA][root@pfSense.bhf.tld]/root: sockstat -6 | grep ":53"
unbound unbound 53479 3 udp6 *:53 :
unbound unbound 53479 4 tcp6 *:53 :

means "all exiting interfaces", for TCP and UDP.

When you raise the resolver (unbound) log setting to 'very verbose', can you see the IPv6 request arriving @unbound ?
Don't forget to set the log setting back, as it produces a lot of info.

I had the same issue, several of my device went poof with their static IP and when I see the DHCP logs this what shows me.

WARN [kea-dhcp4.alloc-engine.0x3088dc017b00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 xx:xx:xx:xx:xx:xx], cid=[ff:3e:43:3a:49:00:02:00:00:ab:11:35:39:77:96:62:6d:b5:73], tid=0x98a5560c: conflicting reservation for address 172.16.0.4 with existing lease Address: 172.16.0.4 Valid life: 7200 Cltt: 1747537583 Hardware addr: xx:xx:xx:xx:xx:xx Client id: ff:3e:43:3a:49:00:02:00:00:ab:11:37:60:a1:7d:6d:07:47:d8 Subnet ID: 1 Pool ID: 0 State: default Relay ID: (none) Remote ID: (none)

Yeah that assigned it a different IP address for a reason that it had conflicting IP address. went back the ISC because of this.

I hope the upcoming 2.8 have a fix for this.

@ericwentz and the dhcp lease time has zero to do with a dns ttl on a record.. The default is 7200 seconds, or 2 hours.

Which per the rfc Gertjan pointed out the registration of that in dns should be like 1/3 of the lease and not shorter than 10 minutes..

My issue is what you showed in the log of kea was it was writing a record with a ttl of 5 minutes - which to be honest on a local network is insanely low.. Make zero sense to me and clearly not following the rfc.

I'd backup the config.xml, edit it in Notepad++, and "Find/Replace All" the old prefix with the new. Save and import it when the time comes. But that's me, just an idiot on the Interwebs who doesn't even use v6.

@SteveITS I did restart but I have been adding a lot reservations so I I noticed it intermittently and just decided to give up and move away from Kea

I was able to find and delete the entry by searching the XML file and it was in virtual IPs.

@Gertjan Unbound's been running since May 1 on this router. Not using DHCP registration, or even DHCP on this router.

unbound 19499 0.0 2.3 124144 92208 - Ss 1May25 14:45.04 /usr/local/sbin/unbound -c /var/unbound/unbound.conf

One of Jim's comments in 8758 was, "The I state indicates it's sleeping for over 20 seconds and per-se is not the problem because filterdns threads sleep for 1 minute so it will stay as S in the first 20 seconds and then move to I." So that may just be a red herring.

I didn't write it above but the missing IP in question this time was my home, and I log in every single day. Also AFAICT the IP didn't change (no notification in pfSense). So the IP just disappeared from the table one day.

@Andy142

Pretty solid proof then that the ISP device, connected to the pfSense WAN port took down the interface.
Afaik : reasons can be : if its a modem type device : they do this to signal down stream a data carrier loss.
Bad power.
Bad NIC.

Most often, these ISP devices have also a GUI. It's time to have a look at, maybe there are details about the loss available.

@Gokulapandi
The DNS resolver doesn't hand out private IPs by default. You have to enable this with a custom option:

server: private-domain: "<your-domain.tld>"

The server line is only needed if you haven't one already, otherwise you can write the private-domain line below of it.

@johnpoz yeah, I guess 10 would be enough for some IoT devices like light bulbs, you garage door, window blinds or sun shades (whatever the right word).
For the DMZ on the other hand it may be a bit slow.