Hello together. Seems almost 2 years later still an issue. I tried out the fix with the route, only change is, that I can now ping the remote-side from the diagnostic menu. DHCP Relay still not working. On the remote side the is no switch, it a virtualized network without any further setting possible. The issue might also be: You can have only one setting for DHCP-Relay. So if you have VLANs on the remote-side that need to communicate with the same DHCP-Server on the central side, the packets won't come from the respective VLAN-interface, and will be routed into the wrong scope of the DHCP. What also is weird, the local DHCP in the PFSense also isn't working, or so to speak only serving the LAN-Interface, not the VLAN-interfaces althoug activated on every interface.

Wow, thanks guys! This helped me get my DHCP leases page working again. I also had reverse lookups redirected to the domain controller DNS via 'Domain Overrides' on the DNS resolver page. Somehow that did time out. I remove the overrides, and now everything works smoothly. Now I just have to figure out how to repair the overrides, or whether I need the reverse lookups for Active Directory at all. Because they obviously didn't work for a while now, and I didn't see any issues so far...

@Gorf Grab it from tcpdump or wireshark. It's truncated in the log. Should look something like this: [image: 1741541877927-a3ae9da6-984e-4f95-a702-54724bd12951-image.png]

@beerguzzle or just a switch capable of vlans.. Any smart switch would work. You can then have uplink to your lan, and uplink to your opt port and they would be isolated networks on your vlan capable switch. but sure 2 dumb switches works too.

@digitalgimpus said in Random DNS Resolver failure with Quad9 over SSL: I'm running 1.18.0. Yes, it is helpful in the future for posters having issues with DNS or DHCP to post the pfSense branch they are using (CE or Plus and which version). The underlying binary components of the DNS Resolver and the DHCP server are quite different between the current 2.7.2 CE branch and the latest 24.11 Plus branches, for example. A number of unbound bugs were fixed upstream in the newer version released with pfSense Plus 24.11 as compared to the much older version bundled back with pfSense 2.7.2 CE. Ditto for kea, the new DHCP server that came out first with 2.7.2 CE. The kea binary and its connections to the DNS Resolver are quite different from (and much more feature-rich) than the original kea still bundled with pfSense CE. When a poster does not state their pfSense version (and thus, by extension, the version of unbound or kea) they are running, it is easy for responders to make false assumptions. For instance, "it's working fine for me" might be true if you are using the latest unbound on pfSense Plus 24.11, but something may well be broken on the older unbound that is bundled with pfSense CE 2.7.2. This is a natural consequence of the growing divergence between features and versions of packages included in pfSense 2.7.2 CE and those of pfSense Plus 24.11 (and soon, 25.03).

@johnpoz Thank youuuu!!! Forgot all about this!

@sifti85 you can do whatever you want - don't make it right, running multiple layer 3 Ip ranges on the same layer 2 is just nonsense.

@rhschuld Unfortunately, I cannot recall what I did to fix this. I may have exported the backup and then edited the xml file to remove it. I did a few full re-configurations since then which might have removed it as well.

Thanx a lot @Gertjan That was it. It was listening on port 953. Since I had not seen any configuration option in the UI I thought it was disabled.

@tman222 localhost not really for security - but localhost would always be up, so unbound kind bind to it when starting - it will route out any wan interface you have and be natted to that ip Not something to worry about really or set, like I said out of the box is fine - but those were things that popped into my head that are different than default.

@marcosm Oh yea, that error is definitely fixed by the patches. Thanks. I posted confirmation on that other thread in case someone else ran into it.

@nobugswanted said in Domain Override works for Debian and Windows but not Ubuntu: Did you verify if the port forwarding worked? How can I verify this? You can sniff the traffic on the localhost with Diagnostic > Packet Capture. Select the localhost interface and enter 53 at the port filter, start the capture and run a DNS lookup on the concerned machine. So I've tested from a VPN-computer only. Maybe the solution you proposed will not work on VPN-clients. Did you push the DNS to the VPN clients or configure the client itself to use your DNS? Which VPN?

@Gertjan said in Devices Not Getting IP from pfSense DHCP Through TP-Link AX95 Router: connect the "TP-Link Archer AX95 WiFi Router" to pfSense with one if it's ("TP-Link Archer AX95 WiFi Router") LAN ports, don't use the WAN port anymore. Disable the DHCP server on the "TP-Link Archer AX95 WiFi Router". Disable DNS. I have followed your suggestion. It mostly seems to work. devices appear to be able to get access from the range extenders. It does really seem to screw up the ability of the AX95 to report on its clients though. Now I can see only between 5 and 12 connected wifi devices when there are 30-35 at any one time. Also, I cannot tell any longer which of them are connected to the Guest network as opposed to the main network. However, all my devices are now in a single broadcast domain, and OneMesh seems to still be working. these were my goals, so, thank you. :-) Michael. @vitorlm

Well, spent the last 15 hours trying to get my SG1100 working again. Ran into trouble at every step of the way. I need an offline installer, since the install program can't connect to the Netgate servers. (I suspect that has to do with the Starlink router using the same address space on the WAN side that pfSense defaults to use on the LAN side.) So I don't know if I'll ever be able to get back to this. Lost 15 hours of time, plus income, plus wife's income (can't work remotely after a snow storm), and I'm wondering if my device is ever going to work again - or if I have to wait for a paycheck so I can get a new one and then just sit around and wait for it to arrive.

@Gertjan No problem! I'll have another opportunity to look into this on Friday and will report back. For now, everything seems to be working fine since the reboot.

@tknospdr said in Resolver, but in 'forwarding' mode?: with the 'query forwarding' box checked and ... and given some DNS servers to forward to : [image: 1740049816470-fa6d4a2d-3633-4f85-a751-bfecf0fcbdb9-image.png] Not a lot of difference. The functionality is the same. dnsmasq, the original (before 2012 ?) forwarder is still there for historical reasons. pfSense started to include Unbound, the resolver, as there are no more good reasons (advantages) to forward to some given = ISP (or chosen by you) corporate DNS server. It's 2025 now, so you can tap into the original "DNS system" that Internet offers you. In short : you can take the info from the source, and you don't need an intermediate services anymore. You've seen it yourself how good it is : when you installed pfSense, before you changed anything, 'DNS' worked. So no more need to forwards to some other resolver. Resolving means it will use DNSSEC if avaible. Still, you can chose what method you want to use. Both methods have their advantages. My point of view is : Netgate has chosen a default setup with a resolver for a reason.

@mb-panketal Something to read : 21.2.1. GSS-TSIG Overview That's what I'm using so Kea's DDNS can communicate with a remote DNS like Microsoft AD (if I understand the doc correctly. Not very surprising, as bind and DC are, imho, the most common ones. So, don't wait, don't switch, don't relay, but : 4. Setup and start the Kea DDNS (see my other post). This probably needed "Kerberos 5" stuff and looking at other "pfSense Microsoft DC" forum posts, pfSense has the needed libraries already. So it issue might be as simple as You want A to talk to B, So : Make them talk. And I get it, this concerns a Microsoft product so finding doc is a bit hard(er) ....

This is what my setup is. Both pfSense firewalls are able to locally resolve DNS using the host override settings. my goal is to have clients to LAN3 resolve dns from LAN0. The 2 pfSense firewalls are connected over VPN [image: 1739891145945-a6c08b14-3d30-4096-8fe3-1db116905b95-image.png] The settings i used is domain override on the DNS Resolver service. Since LAN3 has routing to network 0, i used the remote pfSense address. [image: 1739891129994-623cacba-8fbe-4ea1-a416-dce5c2ff56c4-image.png] Does this going to work ? is that a sufficient setup ?

@johnpoz "If this is a private IP then it’s a little harder. Can’t do a DHCP reservation? Perhaps a “domain” override for that hostname pointing to the remote DNS server?" sadly not, there isn't a local DNS server on the other network. the network is in effect a black network with very limited and extremely controlled connectivity to other resources.