I've solved it with a script and a cron-job in the mean time: #!/bin/sh Fetch public IP with debugging PUBLIC_IP=$(curl -4 ipinfo.io/ip 2>/dev/null) if [ -z "$PUBLIC_IP" ]; then logger -t ddns "Failed to get public IP from ipinfo.io" exit 1 fi logger -t ddns "Public IP: $PUBLIC_IP" No-IP update NOIP_USER="USERNAME" NOIP_PASS="PASSWORD" NOIP_HOST="SUBDOMAIN.ddns.net" NOIP_RESPONSE=$(curl -s "http://$NOIP_USER:$NOIP_PASS@dynupdate.no-ip.com/nic/update?hostname=$NOIP_HOST&myip=$PUBLIC_IP") logger -t ddns "No-IP ($NOIP_HOST): $NOIP_RESPONSE" But I still want to figure out the official fix of course!

@justme2 Get your SFTP browser, open /usr/local/www/services_dhcp_relay.php Or use the console or SSH, and edit /usr/local/www/services_dhcp_relay.php Locate : if ($dhcpd_enabled) { print_info_box(gettext('DHCP Relay cannot be enabled while DHCP Server is enabled on any interface.'), 'danger', false); } Chance for : if ($dhcpd_enabled) { print_info_box(gettext('DHCP Relay cannot be enabled while DHCP Server is enabled on any interface. !! OVERRIDDEN !!'), 'danger', false); $dhcpd_enabled = false; } Note : the "!! OVERRIDEN !!" is my personal choice, and not needed. Save. Now, for example : I disabled the DHCP server (kea) for this interface : [image: 1757669144546-1208eea8-273b-4632-aa28-447a19ca7d92-image.png] Save and Apply. Back to DHCP relay, select IDRAC - add a DHCP Relay server : [image: 1757669183530-4a1df8ab-bc3b-41ce-9da3-edd2d04bfacc-image.png] and Save. Check : [25.07.1-RELEASE][root@pfSense.bhf.tld]/root: ps aux | grep 'dhc' root 26880 10.2 0.6 43768 23968 - S 11:18 0:00.10 /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf root 27281 9.9 0.6 43728 23532 - S 11:18 0:00.09 /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf root 24435 0.0 0.1 14404 2980 - Is 20Aug25 0:00.02 dhclient: system.syslog (dhclient) root 41257 0.0 0.1 14404 3100 - Is 20Aug25 0:00.05 dhclient: ix3 [priv] (dhclient) root 51257 0.0 0.1 14308 3460 - SCs 20Aug25 0:39.41 /usr/sbin/syslogd -O rfc5424 -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf -b 192.168.1.1 _dhcp 51487 0.0 0.1 14408 3268 - SCs 20Aug25 0:05.22 dhclient: ix3 (dhclient) root 52757 0.0 0.1 14128 2900 - Is 20Aug25 0:06.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid ix3 root 56422 0.0 0.1 16812 4776 - Is 11:10 0:00.00 /usr/local/sbin/dhcrelay -id igc2 -iu ix3 192.168.10.1 The kea DHCPv4 is still running. If all goes well, it doesn't touch/use the igc2 - my "IDRAC" - interface. As you can see, dhcrelay is running also - using 'igc2' - my IDRAC interface. You'll notice that on the DHCPv4 (kea, as that's what I'm using) there are also red messages showing. [image: 1757668428078-c8d71175-a0b8-4fd6-b081-18138c5027b5-image.png] Also for the LAN, and other interfaces. I guess you know now how to make these GUI pages more "smart", and don't show messages if they are not needed. On the DHCP Relay GUI page you could even modify the list with shown network, by excluding the networks that have the DHCPv4 active on them. In my case : this list should only shown "IDRAC" instead of : [image: 1757669589057-fe81bc41-f103-4a54-be83-890688b52a39-image.png] Btw : I did not test this dhcrelay service. I don't have a network where this is needed / don't know how to use it. Also : I presume you cant' save DHCOPv4 ((kea) settings and network pages anymore, as on this pages the test 'is dhcp relay' running also exist (Generaol settings page : just the test, on the interface(s) page - the same PHP file is used for all interfaces the test also exist, and name some love). I'll leave it up to you a make something nice, safe and fool proof out of it. Like : If you select an interface, like my IDRAC, that has a dhcp relay activated on it, show the red message and don't allow the user to Enable it with an active DHCP server. This is now already the case. Make the code a bit smarter by testing the (this) interface is used by dhcp relay, and only allow the DHCP server (kea) to be activated on that interface if it is not used by dhcp relay. See /usr/local/www/services_dhcp.php- here : [image: 1757669965048-4812bf5d-0bca-4afb-a4f0-8e0173cd984f-image.png] how to make these decisions.

@Gertjan As soon as I can I'll do the tests and update you.

@Gertjan I did/do what you've described - and I only use IPv4 so don't even have to worry about DUIDs - and it doesn't work. It's rock solid at being buggy/broken, yes. If it were only me....sure, that could be my issue, but I'm not alone here with seeing the same problem. See my linked post - I showed you that the Kea DHCP process is doing the wrong thing via packet capture. There's no discernable reason why it's doing the wrong thing, it just does. Switch back to ISC and instantly all problems resolved. If you can tell me how I can figure out how/why it's broken, I'm listening.

@Luca-De-Andreis Hello, i have the same problem look here: https://forum.netgate.com/topic/198723/after-restart-unbound-dns-resolver-don-t-work/3?_=1757403706907

@patient0 Still the same issue with if_pppoe.

@terryzb said in Printer losing its DHCP lease in 25.07.1: printer because with DHCP it would fail back to link-local after 6 hours or so So around 3 hours from the initial printer power up == initial 'BOOT' DHCP request, start some time before, like 30 minutes or so, like at initial lease+150 minutes, you should be able to packet capture with the printer MAC to see if pfSense actually receives a DHCP request from the printer.

@Jeremy11one said in Confused about DNS forwarding and local domains: Here's a 2018 Microsoft page I found with contrary advice: link. I'm interested in your opinion to see if there's something that article hasn't taken into consideration. While generally @johnpoz does have a point on the issues with leaky DNS when using public domains internally, it should be noted it only happens if mistakes are made in internal DNS setup (like fx. Transparent vs. Static, and searchdomains and such). There are a lot of arguments for using a public internal domain when it comes to user transparency/understanding and just generally making lives easier because of “easy use” of short hostnames instead of FQDN. Also, I highly disagree with the argument that a private domain internally makes things easier - it does not in the majority of management cases with large userbases. It will create a lot of double maintenance in DNS, proxies and firewall setups (reflection) if your userbase generally are using webbased tools in their interaction with company ressources that are a mix of internally and externally hosted servers. Much easier to maintain with a public internal domain, and no need for NAT reflection which is a PITA. So both solutions works and each have their advantages. It’s safe to assume MS made that recommendation from years of support and understanding what problems was caused by each model. Yes, a private domain is the “correct” technical solution, but ease of use and maintenance has a tendency to win ;-) It should be noted as we increasingly move towards SAAS in cloudservices, the public internal domain advantage in maintenance does “diminish” as those require you to make double maintenance in DNS if they are named in the public domain.

Ooo, missed this. You are just adding that section to the custom Kea json config? Edit: Yup

Update from my side: issue hasn't appeared again since disabling ntopng, so seems that was the culprit (or one of them, anyway).

@Gertjan off track, but i am trying to integrate home connect into home assistant which is a vm inside of truenas. linking the cloud account doesn't like. i was using the wan access only to check that i got duckdns and letscrypt sorted. now i am trying to figure out how i get haos working. i guess i can revert back to my pfsense certifcate once haos is running

@Woodsomeister said in Use and persist dhclient rapid commit option: Adding the option is not what I need You are again right, you would need dhclient to respond appropriated according to the RFC4039. Checking the source code, dhcpcd 10.2.0 can handle it (no configuration needed) and it's compiled in in pfSense. Would be interesting to see if you get an IP when manually running it. Not very practical though. Even less sure if you could script it by setting WAN IPv4 to None or Static as a placeholder and run whatever necessary yourself. Or set it to DHCP and use a dhclient hook to run dhcpcd. Maybe Sir @stephenw10 has done something similar in the past? Maybe a feature request to Netgate would help: to be able to choose which DHCP client app to use, dhclient or dhcpcd. For IPv6 dhcpcd is already used. Btw: ISC DHCP and ISC KEA don't support rapid-commit but dnsmasq does. Gave a it go and dhcpcd would work, running manually dhcpcd -4B <WAN interface> --option=rapid_commit on the pfSense (client) and tcpdump on the dnsmasq server shows DHCPDISOVER & DHCPACK. Running the standard dhcpcd -4B <WAN interface> --nooption=rapid_commit shows the standard 4 packages sequence.

@SteveITS This has been an issue for me for YEARS. But it only crops up every so often (like today). It's long enough apart that I forget about the filterdns issue and waste several hours looking at the wrong things. Maybe I just need to set up a cron job to kill and restart filterdns every hour? Would that work? Break something else?

@NETLOGIC Pick any - read - apply - done

@Gertjan I think you misunderstood, the lease works fine, the machine gets the proper IP, it just that it doesn't register the IPv6 to the DNS Resolver.

@kingrazor said in DNS config tips with pfsense behind ISP router: We're using Comcast as our ISP and I have for many years had issues with their DNS servers, so I never use them if I can help it. So the only sure thing is that I don't want anything on the network using Comcast's DNS servers. One more reason why the pfSense default DNS setup would be perfect for you. No ISP (Comcast) DNS is used by default. That said, I do presume that Comcast allows you to use the internet, and thus the Internet's 'default' DNS traffic. If they start blocking ordinary DNS traffic then an ISP change would be the your best solution. That said, if they really would do that, they won't stay in business long time ...

@webdawg said in KEA DHCP missing "Register DHCP leases in DNS Resolver...": Is 2.8.0 community working with KEA and DNS Resolver? Yes, I am on 2.8.0, and KEA now works well with DNS resolver. The DNS server now resolves client.mydomain.xx for leases received via KEA DHCP server.

@marcg Thanks I have switched to ISC, will remain there till they figure out the issues with KEA