@tinfoilmatt Thanks Matt.

@tweek said in FreeBSD DHCP Client Vulnerability CVE-2026-42511: I've been building and administering FreeBSD/OpenBSD servers for about 24 years. I'm familiar with building from source. Then you must be aware of the fact that building against the pfSense FreeBSD source tree isn't native FreeBSD. Building (yourself) pfSense is what I would call 'complicated'. My info source is forum posts about the subject. It isn't ./configure make world make install The make file isn't public afaik. @tweek said in FreeBSD DHCP Client Vulnerability CVE-2026-42511: Yup. I'm looking for a yes or no response to whether I can grab a patched dhclient binary and replace the vulnerable one without breaking anything in pfSense, If it exists, it's here : github pfSense somewhere in the "FreeBSD-ports". I cant' find it. I can't say that because I can't find it it's 'yes' - or 'no'. I'll see 'probably'

@crimper unbound runs under chroot as I recall so that’s probably the correct path from unbound’s point of view. Also not all of /var is using tmpfs/RAM disk as I recall…run a “df -h”. We use RAM disks as much as possible but I don’t recall ever disabling DNS Resolver. I wonder if that’s a bug between that and enabling the RAM disk, and after enabling DNS the file is there to be copied in at boot, or something.

@ortizat You put it there when you create the reservation/mapping - you can't put a description on a dynamic lease.. Only one you reserved for a specific client..

@johnpoz said in KEA DHCP lease should not be resumed when client switches VLAN: What/where did you create that graph showing the high network utilization - I would do the sniff there, if pfsense interfaces are seeing the high utilization of network you could just do the packet capture there under diagnostics. The graph I posted was my tool using the controller API. It would be showing the same data that you found in the graph from the current controller, except on a shorter time frame, easier to visualize. What specific APs, firmware and controller version are you running? U6-LR, EA firmware 6.7.51, controller 10.3.58 . edit: oh they moved it... I am running U7 Lites, 8.6.7 firmware with controller software being 10.3.58 running on Unifi OS (5.0.6) on a linux vm.. And it shows up if you click on the device, then airview, then highlight one of the devices (ap) you will see packet capture all the way to the right pop up. Yes, I found that. [image: 1777016609766-packetcapture.jpg] But depending might not be supported, I have older flexHD AP that thinking of deploying outside currently connected and I don't see the packet capture button pop up there, but it does have tcpdump if I ssh to it.. Wonder if packet capture not showing up because I currently have its radio's off? I think packet capture must be specific to certain models. Maybe U6 vs U7, or chipset. Anyway, to get back to the original DHCP issue, I have concluded that there is no problem with pfSense. The issue with getting the wrong IP was related to Radius caching in Unifi. My GUI tool was updating the VLAN for a client in the freeradius config, then immediately forcing a Settings/Reconnect on that Wifi client using the Unifi API. It turns out that Unifi has a cache for Radius authentication, and does not immediately trigger the Radius re-auth, if the client had previously authenticated with Radius within the last minute. I was testing rapidly by clicking back and forth in my GUI. I have a single button that does both the Radius update, and Unifi client reconnect. If I wait about one minute and force reconnect the client again, Unifi forces a Radius reauth, and it switches to the correct VLAN. It was painful to figure that out, as I had to enable debug logging in both pfSense KEA DHCP server and freeradius. Here is what I had to add in the custom DHCP server options in pfSense to enable it. { "loggers": [ { "name": "kea-dhcp4.packets", "output-options": [{ "output": "syslog:kea-dhcp4", "pattern": "%m\n" }], "severity": "DEBUG", "debuglevel": 10 } ] } In freeradius - running in a Ubuntu 24.04 lxc container on proxmox, not in pfSense : root@radius-dev:/etc/freeradius/3.0/sites-enabled# cat /etc/freeradius/3.0/mods-enabled/linelog-vlan linelog vlan_log { filename = /var/log/freeradius/vlan.log format = "%T | %{Calling-Station-Id} | %{reply:Tunnel-Private-Group-Id}" } Then, I added "vlan_log" as the last line of the post-auth section in /etc/freeradius/3.0/sites-enabled/default . This let me trace the incoming Radius requests from Unifi for that client - the only one that I switched VLAN on for testing purposes : root@radius-dev:/etc/freeradius/3.0/sites-enabled# tail -f /var/log/freeradius/vlan* | grep 84-72-07-81-11-ED 2026-04-29-12.38.25.634023 | 84-72-07-81-11-ED | 2 2026-04-29-12.40.11.118653 | 84-72-07-81-11-ED | 1 2026-04-29-12.41.02.423494 | 84-72-07-81-11-ED | 2 2026-04-29-12.45.00.025150 | 84-72-07-81-11-ED | 1 2026-04-29-12.46.48.017847 | 84-72-07-81-11-ED | 2 2026-04-29-12.48.00.218718 | 84-72-07-81-11-ED | 1 2026-04-29-12.49.00.370991 | 84-72-07-81-11-ED | 2 2026-04-29-13.24.48.548272 | 84-72-07-81-11-ED | 2 In the pfSense server DHCP log, I see : Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_RECEIVED [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vtnet1.2 Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_SEND [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: trying to send packet DHCPOFFER (type 2) from 192.168.106.1:67 to 192.168.106.7:68 on interface vtnet1.2 Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_RECEIVED [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vtnet1.2 Apr 29 13:24:48 kea-dhcp4 93031 DHCP4_PACKET_SEND [hwtype=1 84:72:07:81:11:ed], cid=[no info], tid=0xfb: trying to send packet DHCPACK (type 5) from 192.168.106.1:67 to 192.168.106.7:68 on interface vtnet1.2 This is all expected for freeradius and pfsense. Unfortunately, the 2.4 GHz band utilization for this client on the AP it's connected to instantly goes to 100%. There is no increased traffic on the pfSense side. It really looks like a Unifi issue. I have still not been to figure out why. This is a showstopper and completely preventing me from using VLANs with Unifi. I have done a few packet traces on the AP, and am not seeing anything unusual, regardless of which VLAN the client is on. I must not be doing the capture right. I may need to open a support case with Ubiquiti to get to the bottom of this.

@aligator638 said in Kea DHCP Feature Roadmap: Whilst migrating, you have to move over quite some configuration from each DHCP enabled interface, including reservations Not quite sure what you mean here...the "static reservations" list should move back and forth when changing between DHCP servers.

Porkbun had hiccup on their end affecting API recognition. They resolve it shortly. Sorry guys for taking space here. Cheers!

@ulcha If by chance you have an old config which you reinstalled with ZFS, ensure log compression is off since ZFS also does compression. That was frequently a reason for bzip taking longer than expected. But yes rotation every minute would also be a problem. Switched back to ISC DHCP server. Just...get rid of the extra Kea process...?

@Udbytossen I knew to look because I have done the same thing...

@patient0 said in DuckDNS IPv6 update URL ?: e the 'Custom (v6)' template Thanks a lot for your post. I was trying to get IPv4 and IPv6 to work all on the same line. for future me to set this up again: Make two Dynamic DNS Clients, one for IPv4 and another for IPv6. Service Type = Custom (v6) Interface to monitor = WAN HTTP API DNS option = check Force IPv4 DNS Resolution Update URL = notes above Results Match = OK Without checking the HTTP API DNS option I would get an error in the system logs saying. I'm embarrassed how long it took me to figure out what was going on. 'ERROR [phpDynDNS] Curl error occurred: Could not resolve host: www.duckdns.org '

Ah this one's on me. I had some json buried in a static mapping in that subnet that I was trying to use to disable the hostname from being sent out. Obviously kea didn't like that. It would've been really helpful to see the contents of the file that was actually being used by kea when it failed to launch. It seems that as soon as it fails, pfsense reverts the file and restarts.

@johnpoz said in Resolver oddity: that is has nothing to do with the update to 26.03 though Yeah.. I didn't think so because it has been working flawlessly up till now.. Thanks for digging. Ill give them a call.

That's how one typically settles for kludge, sure.

@RianKellyIT said in DNS resolution issues after 26.03 update: Under Services > DNS Resolver, there's a Forward Zones section ?? The only 7 instances of "forward" on the page are under "DNS Query Forwarding"...

@jamie said in Changing the MAC address on a Kea static lease does not work: I can't get it to apply. Version: 2.8.1-RELEASE -> "I only tested it on 26.03-BETA." 2.8.1 is probably just a bit behind on Kea code.

The UNKNOWN class in that allocation failure is the key clue. KEA uses client classification to control which pool an address comes from. When a client shows as UNKNOWN in the allocation failure message, it usually means either the pool has a require-client-classification directive that this client does not satisfy, or there is a client-class restriction on the pool that excludes clients in the UNKNOWN class. Check your kea-dhcp4.conf - if any of your pools have client-class or require-client-classification set, that is likely why this client is being rejected. Also worth checking: is the MAC 90:72:40:02:ec:47 appearing from the expected interface? If that device is somehow arriving on a different VLAN or interface than where the pool is bound, KEA might not be matching it to the right subnet/pool definition at all.