Just to update this in case anyone looks at this later. I ended up reflashing pfsense and setting up front scratch. I had screen shots of most my setup but even by 2 week old backup was corrupted. My lesson learned is to take backups of individual portions of the setup in case something gets corrupted.

@PeterHouse Sounds like you did everything right. I would additionally add another entry for a device that you have in your test/prep environment to make sure it works as expected before taking it into production.

@johnpoz I really don't understand why Ecobee or any other device would send DHCPRELEASE. It's not even mandatory in the protocol. I wonder more about the (not found) part. The entries were like this: Aug 20 10:34:42 dhcpd 22774 DHCPRELEASE of 192.168.0.43 from 44:61:32:xx:xx:xx via igb1 (not found) Aug 20 18:35:57 dhcpd 22774 DHCPRELEASE of 192.168.0.127 from xx:xx:xx:xx:xx:xx via igb1 (not found) Those IPs are in the DHCP Static Mappings for this Interface.

@johnpoz / @pfpv - Thanks for your comments. I think I got a step further and I tried to summarize what I did and what I am trying to do below: Intended behavior: All DNS requests should be redirected to the pfSense resolver or forwarder (depending on the VLAN) DNS traffic should be routed through pi-hole where it is added in the DHCP settings of the respective VLAN DNSLeaktest should only show one server for the resolver gateway and however many (normally 4-6) for the forwarder gateway (goes through quad9) @johnpoz This relates to your question. In the best case, I only need to add the pi-hole IPs in the DHCP settings Actual behavior: Option 1: Resolver and forwarder works, DNSleaks shows the correct servers, but traffic does not go through the pi-hole servers Option 2: Traffic goes through pi-hole, resolver and forwarder works, but DNSleaks shows the "wrong" servers, as the resolver server leaks into the forwarder gateway, which means I see the resolver DNS servers AND the forwarder DNS servers. Temporary fix (for resolver VLANs): Disable the general DNS redirect NAT rule for resolver VLANs, as I have control over the devices and none of them are going rogue with hardcoded DNS servers, e.g. laptops. iPads, phones etc. I am still missing a permanent solution for the resolver VLANs and a solution at all for the forwarder VLANs, as forwarding does not work without the NAT rule, as this goes out through a Wireguard tunnel. I have posted my NAT rules below. The pi-hole servers are part of the MGMT VLAN in case that is relevant. 10 and 20 are resolver VLANs and 30 is a forwarder VLAN: [image: 1661083305616-9814b7c5-8528-4c19-bea1-5fa32c79584a-image.png] My IOT stuff is in another VLAN, which is also a forwarder VLAN (like 30 in the screenshot), so it would be great to have a solution there to make sure that rogue devices go through pi-hole, then through the pfSense forwarder. This way I can block them in pi-hole if necessary. Thanks for your help!

@doubleopinter said in DHCP Leases page doesn't load: Has anyone seen this before? It just sits there loading the page and nothing ever loads :( I recently disabled the native dns forwarder and resolver and am using nextdns cli client. That's the only thing I can think which changed recently. Eventually the page just times out. This issue has been seen before. For every lease, a DNS (and reverse ?) request is executed. The local DNS should know about every device on your network that has asked a lease, as every lease gets integrated into the local DNS cache. That is, as long as it contains a valid host name. The static MAC leases are also loaded into the local DNS at start. Or, you have stopped all local DNS facilities. All DNS requests are forwarded to ..... some where else = OpenDNS. OpenDNS doesn't know anything about your local devices, so no useful info gets back. Still, the reply should come back quickly : "sorry, no info". The fact DHCP leases page times out implies other DNS issues. I advise you to use the local forwarder, or the local resolver as forwarder, so the local (pfSense) DNS works. I advise you also to look at the other forum posts handling the same subject, they should be in this forum (DHCP and DNS).

@deanfourie said in what look like DGA queries from pfSense: Any ideas what this could be? A client asking for it.. Or you loading a list from that domain, say pfblocker. The only thing pfsense would query for really on its own is to check if there is an update available or your package list.

@johnpoz but the DNS is not static. It will be pushed over VPN. That's why I need to overwrite function. It's a bit of a dilemma. With dd-wrt it wasn't a big deal. They offer the possibility to Ignore WAN DNS. I cannot imagine, that there's no way in/for pfSense to do this.

I forgot to change the gateway in the respective firewall rules ... Problem solved!

Should I just enter this in redmine? It seems like it would be pretty easy to reproduce. At least on my system I can reproduce it at will.

I did a fresh installation from scratch and also asked my ISP to intervene on its configuration. No useful results. The only way to have DNS on PCs is to report it in the DHCP server configuration. Or alternatively it is to set DNS Query Forwarding to "Enable Forwarding Mode"

Thanks, that's very helpful. I understand this is unsupported in pfSense. I'm experimenting because I'm an embedded firmware engineer working with a product that wants to get vendor config from DHCPv6. @derelict said in Restart DHCPD via console / ssh / commandline: There is probably a better way to reload the configuration like kill -HUP 96112 or killall -HUP dhcpd but you'd need to dig into the ISC dhcpd docs to get the proper method. According to How to reload the dhcpd configuration file At this time, the dhcpd server doesn't have any reload mechanism. It doesn't handle HUP signal nor have a 'soft' reconfiguration method. The server has to be stopped and restarted...

Thank you John

@johnpoz It works like a charm. Thanks a lot

@mkcharlie said in Cannot resolve one specific host: actauni.com nslookup on my pfSEnse : [22.05-RELEASE][root@pfSense.local.net]/root: nslookup actauni.com Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: actauni.com Address: 185.45.67.217 nslookup on a PC : C:\Users\Gertjan>nslookup actauni.com Serveur : pfSense.local.net Address: 192.168.1.1 Réponse ne faisant pas autorité : Nom : actauni.com Address: 185.45.67.217 Btw : 192.168.1.1 is the IP of my pfSense.

@kjemison1966 FYI : It's mostly found in WIFI controlled Network same hostname of devices: Reason: Large no of IP blocks like (10.0.0.0/16) Your firewall not running in all day (open and close in office timings) due to this IP leases is not cleared properly. Solution: Use Subnetted IP as per requirements 2.Make your DHCP lease expire in a short time duration These solution is for dynamic DHCP leases only. Thanks

@johnpoz That was it! Thanks for the help!