@bschae1 we are working on a new upcoming release for devel and this should be resolved at that time.

@KOM hi kom i forgot to change the vlan number in switchport option so when i change to 77 it works [image: 1783743322268-screenshot_2026-07-11_12-13-47.png]

I can look into it further if steps are provided to reliably reproduce the issue. I use DoT with an ACME cert along with pfBlockerNG in python mode and haven't noticed any issues.

@Cabledude without details - hard to say what your doing. Do you even have rebind protection enabled. What is the fqdn you are doing query for that returns rfc1918. If you are asking some other ns other than pfsense? If you don't want to post in public - send it to me in a DM. It sure isn't going to be a ttl, rebind protection has been part of pfsense for years and years..

@Gertjan Thanks, yes, but turning off Early Registration is totally fine. I would like my configuration to be as portable as possible, as it were, if you get my drift. Thanks again for confirming this bug...looks like a fix is possibly forthcoming in the October release. Fingers crossed.

@NWOSwamp said in Filterdns has stopped resolving hostnames in firewall aliases: There is a workaround using pfBlockerNG described here: https://forum.netgate.com/topic/199641/psa-domain-name-based-aliases-filterdns-can-fail-silently-use-pfblockerng-instead Good call. A work around which uses this seams to work Leave all generic pfsense Alias definitions, associated port forwards and firewall rules using them as they are. For all alias containing at least one FQDN and more than one entries, for which you want the associated filter to not miss IP addresses (and you can not guarantee there will ever be any duplicates): create an equivalent alias in pfblockerNG (as described above). Give it the same name as the associated generic alias in pfsense (pfblocker will prepend "pfb_" to the name you specify) Clone the associated port forward / firewall rule. Type "pfb_" in front of the alias name & accept the full name pfsense provides in the drop down list. Save the new port forward / firewall rule. The end result is alias / port forward Provides rapid FQDN tracking response (but will miss an IP addresses after the duplicate count decreases). Provides an accurate IP address filter set (particularly for more important IP addresses which have been included for more than one reason) but is updated more slowly (hourly or less often) So not as clean as pfsense aliases actually working reliably, but it is a solution.

@Gertjan @Gertjan said in Kea-dhcp Static Mapping DHCPv6 issue: So you have 3.0.2 also. Aha! So that's something I was unaware of. No wonder Kea is such a pile of crap on CE - it's still using 2.6.2

@wheel5up is there a version of this without paywall?

@scottlindner So this worked for resolving the DDNS issues. The question is: why and what is the real fix?

Not sure what other than restore configuration but the option is now back and working again. I tried the restore earlier and no help but logging out and trying again about 30mins later and now it's working again

@Gertjan and @giuliafw70, thank you both! Guest network has been stable several days now. Will reopen if it recurs.

I think I tracked it down. The SRV query appears to belong to the repository agent (pfSense-repoc). It's trying to find the closest or most available update mirror. I ran the following: pkg -d update The results showed pfSense stuck in a loop checking for system updates. Netgate's repository servers (pfsense-plus-pkg01 and pkg00) were actively rejecting your firewall's built-in client certificate at the application layer, throwing an HTTP 400 Bad Request. Because of this failure, the pkg tool mistakenly attempted to resume partial downloads using bad byte ranges, causing it to endlessly cycle between mirrors and throw erratic errors. Additionally, this update routine caused the firewall to query netgate.com as a relative name, resulting in the netgate.com.foo.org that I saw in the BIND logs. I resolved this as follows: rm -rf /var/db/pkg/repos/* Wipe out the corrupted metadata cache and clear the broken partial download states that were driving the infinite loop. pfSense-upgrade -cc Clean the internal upgrade utility cache. This forced the firewall to dump the stale SSL session tokens and request a fresh mutual TLS (mTLS) authentication challenge from Netgate's registration backend. -- Best regards

@Feline not that I am aware no.. You able to do it with ntop pretty sure - but that wouldn't be doing it in pfsense state table - but in its own listing of traffic.

@marcosm , thanks, that fixed it: no dupes in unbound.conf in failover mode when the VIP and RA Subnet addresses are entered identically in the GUI. I don't know the exact release where the issue arose. My primary ISP has few outages nowadays. Failover definitely worked as recently as last year with similar (identical? ... can't recall) configs. That would have been on one or more of 24.11, 25.07, 25.11. Anyways, glad it's working now ... thanks again!

Yup what are you testing in? That should be fixed in 2.8.1. You my have hit some edge case though.

@Gertjan said in Unique DNS to home Minecraft server.: the LAN devices will never have access to this info. You told them top use another resolver = 1.1.1.1 and/or 1.0.0.1. Now you have to place your DNS override on '1.1.1.1' and '1.0.0.1' ... which is impossible In my distress I restarted pfsense. It has been working since then. I don't know what the problem was. The PTR record is now good, and it returns the correct IP address for the overwritten domain under both Windows and Linux. I am using the Community version and recently updated to the latest version, but I think this is impossible, but I can't say what could have caused the problem. Thank you very much to everyone for the constructive help and advice!!!!

@cybis The referenced index.php and rfc8910.php only apply to captive portal so they won't help. It will be a while before the lease affinity issue is fixed in Kea and they likely have to fix it before pfSense adopts it. Even then, it will only be in the most recent release of pfSense so if you want to run CE, be prepared for a long delay. The longer you keep Kea running without a restart, the closer you are to a solution. Every Kea restart is a do over for IP allocation. You could also ensure your clients keep their leases active as in the static lease suggestion or long lease times that will survive the reboot but again, if they do ever timeout after a reboot, they have no affinity protection any more, even weeks later.