@Gertjan I copied the whole packet capture rather than cherry pick lines but it’s only the last 3 that trigger the Kea log error…the timestamps are exact. It just contains all UDP traffic from that MAC.

I figured my issue out... and it's a funny goof and even after fighting this for 5 DAYS now... I just have to laugh at myself... on the i350-T2, One port I have it set as a VLAN port (igb0.125) as I'm expecting my IoT to go throughout the house, and the other is just a port that serves an IP (using dumb APs/switches on this port).. well I goofed and accidentally had set my Guest port in my assignments to igb0 and not igb1.... SOB.. 5 days.. hahaha I realized when I started to try to troubleshoot this more and realized in Packet Capture, looking at the capture options that both LANs referenced igb0... Thanks guys.. my issue was me... Vin

@Gertjan Thanks for your further insights. It got me thinking maybe it could be some very strange interaction with the new PPPoE driver.... Looks like it is the case, as I went into System -> Advanced -> Networking and unticked 'Use if_pppoe kernel module for PPPoE client', rebooted and DynamicDNS updates for the 2nd (PPPoE) WAN started working again. Just to confirm, I re-enabled 'Use if_pppoe kernel module for PPPoE client', rebooted and it stopped working. I have left 'Use if_pppoe kernel module for PPPoE client' disabled for now as while the CPU usage is a bit higher, the Dynamic DNS updates are now going through for the 2nd PPPoE WAN.

@Gertjan said in Changing the MAC address on a Kea static lease does not work: So, still me thinking out loud, maybe you have an issue - and it happens when you use static mac leases and change NICs. => How often does that happen IRL ? We actually do this relatively frequently! Some client devices have static DHCP assignments. When those users get a new device, we update the MAC address in the static DHCP entry and their new device gets that IP. I suspect this is not an uncommon practice. We've been doing this for nearly two decades now with pfSense using ISC. It is only when switching to Kea that this problem presented itself.

@user_not_found said in /services_dyndns_edit.php: Curl error occurred: Could not resolve host: route53.amazonaws.com: Java On a router ? For some minor GUI stuff, maybe. pfSense using for the vast majority PHP, some shell scripts, some python stuff. Years ago, some one (he knows who he is) said that the entire thing should have to be rewritten in Python ... Maybe Rust these days. I still vote for Ansi C. @user_not_found said in /services_dyndns_edit.php: Curl error occurred: Could not resolve host: route53.amazonaws.com: VSCode What's wrong with Notepad++ ?

This issue exists for quiet a while now @Gertjan Hmm, thanks. I was thinking about it overnight and I'm not sure if it was showing in ISC DHCPv6. Sounds like it wasn't. It's not like I spend a lot of time reviewing leases for working devices. :) It seems like it always ought to detect the /64 prefix, since that can easily change, at least on a consumer Internet connection.

Posting the solution to ignoring IAID in DHCPv6 server. With the release of pfsense 25.11 kea is now at version 3.0.2 and libdhcp_flex_id.so is included in the release. The below JSON section can be added to DHCPV6 server custom configuration to ignore IAID. { "hooks-libraries": [ { "library": "/usr/local/lib/kea/hooks/libdhcp_flex_id.so", "parameters": { "identifier-expression": "''", "ignore-iaid": true } } ] }

@JeGr https://github.com/pfsense/pfsense/pull/4740/changes/167ce421a20aab2b3b0e1d98a803d582a7ef433a lovely!

@rgijsen Something kea doesn't log, but ISC did : logging allocated leases. Read here how to add these 'leases' logs for kea : https://forum.netgate.com/topic/196313/how-to-change-kea-dhcp-log-level/12 and from then on you have "leases" logs which are auto maintained - they won't grow in size indefinitely - but you have to go look for them the good old way : ssh (or sftp) into your pfSense. @rgijsen said in Seeing Kea DHCP Issues after upgrade to 24.11: and hence I think one client should never exaust a pool A client can't exhaust a pool. A DHCP server recognizes a client with just one unique ID : the client's MAC address. If, for some reason, the client changes it's MAC for every request, then this client will be able to fill up the DHCP pool ... but I never saw a client behave like that. A "DHCP packet capture" (UDP, port 67 and 68 on the interface that shows issues with full packet details) will probably show more clearly what is happening.

@Summer1000 said in WIFI LOGIN PAGE NOT SHOWING WHEN PC & MAC HAVE DNS 8.8.8.8, 1.1.1.1: we have a wifi portal but some laptops & mac have input there own dns like 8.8.8.8 & 1.1.1.1 On a network where you control everything, router and connected devices, you can can use DHCP to assign IP parameters : the DHCP lease will contain the IP, network, gateway and DNS. Or set up some or all settings statically. It's all up to you. But, if you want your device anywhere (like everywhere) else .... then don't use static network settings on your device. When you offer a captive portal to users (devices) you don't control, these device should use the "original" network settings. If they don't, then they can forget about connecting elsewhere. After all, what happens when you take you device on which you've setup up 192.168.10.10 /24 and gateway + DNS 192.168.10.1 to you neighbor, and he is using 192.168.100.1 ? Right, nothing works .... so stick with DHCP on devices. Troubleshooting Captive Portal [image: 1769498716189-2e4da971-16a3-4094-96ce-90185f1b6ea4-image.png] When a device connects to a network that offers a captive portal, nothing passes before authentication (well : one exception : DHCP traffic). Nothing means : no commercial stuff like '8.8.8.8', facebook, etc. Portal connected devices should / have to use use DHCP. You, as the portal admin, should use the default settings for the DHCP server : the gateway and DNS should be the IP of the 'pfSense' portal network. The good news is : every device you buy uses DHCP ... so, out of the box, everything works just fine. I'm using the captive portal for a hotel, and as far as I know, people who want to connect, can connect. The login page shows up every time. To make the most out of portal support : This forum, in the captive portal part, search for "rfc8910" and read everything that's posted about the subject. A lot of devices support RFC8910 these days (all Apple, all Microsoft, and as usual, some androids - the most recent ones will probably work fine), and it makes the portal support a lot faster and reliable The idea is : as soon as the device makes a DHCP request, it will know that : a portal is present. where to find it.

I've posted the healthcheck and remediation script to GitHub, if anyone wants to take a look or give it a try: luckman212/unboundcheck Appreciate any feedback. Here's how mine is set up currently: [image: 1769468193694-29cbb3b4-7ee0-42f9-a6d6-3dca7e5427c3-image-resized.png]

@sam.newby again - pfsense is not involved in it.. Doesn't matter if they got the lease originally from pfsense or not.. When that lease expires they would do a discover and your windows dhcp server would give them a lease.. There is no such thing as a firewall rule for devices on the same network talking to each other - because pfsense is never involved in such communications. Do you have any sort of dhcp snooping setup on your switch infrastructure? This for sure could cause you all kinds of problems if not setup correctly, or if you forget to change it when you bring up a different dhcp server. I would again suggest you sniff on your dhcp server and force a client to do a discover.. Does your dhcp server see the discover.. A discover is a full broadcast - every single device on the network would/should see that traffic.

thank you for this link. Finally update to KeA

@Gertjan Perfect, thank you.

[image: 1769109778518-ac843c80-c200-4430-a26a-4f092c967e71-image.png]