Best choices are: Fix your local DNS so the hostname resolves to the local address of the web server and not the firewall. (Split DNS) Enable NAT reflection so requests to the external IP address:port are redirected into the local server (not ideal, but still works) Setup pfSense with HAProxy so it acts as a proxy instead of only performing NAT functions (more complicated, more room for error, but also works around the problem)

Have been using Cloudflare with DNS over TLS for a while and very happy with the performance. Added the Google public DNS servers yesterday as well, but when looking at the DNS Resolver statistics, the Cloudflare servers appear to perform somewhat better. Has anyone done any comparison testing? Thanks in advance.

So your clients don't ask pfsense for anything? If your clients are not using pfsense, then sure you could not run any local cache be it the forwarder or the resolver. Just to let you know that since there is no local caching NS running, when pfsense goes to query stuff in your alias every 5 minutes whatever is returned would not be cached for the TTL of said record, and would have to be be queried for again most likely.. So every 5 minutes you would be doing external queries for everything in your aliases... Vs say looking up something, and then having the local service caching it for the length of the TTL before having to be queried for again. Even if your clients are not using pfsense for name services, prob best to run either the resolver and forwarder so that aliases being used can be cached, and pfsense can cache its own needs - ie checking for updates and packages. Are you using dhcp services on pfsense? If you just point pfsense at some external dns - it would not even be able to resolve local hosts either via dhcp entries being placed in the dns.. And would have no way of setting up specific forwards for domains to be able to find your local stuff.

@gertjan said in DHCPv6 not show leases...: Dono if it is wise to do so but I'll show you my settings : he.net : [image: 1547725191556-ee1c6c12-99dd-4c20-9923-c9b12f31f357-image.png] Note : back then, in 2014, I was stupid. I followed the guide without thinking ;) I shouldn't have take the pie (the Routed /64) , but the entire cake (the Routed /48 which are 65535 parts of /64 pies). Anyway, I decided to use the /64 or 2001:470:1f13:5x0::/64 on my pfSense LAN : I assigned 2001:470:1f13:5x0::1 (mask 64) on my LAN IPv6. I set up the dhcpd6 Server & RA on LAN like this : [image: 1547707961450-b962e61a-3e38-4ffc-b3b8-6803907b772e-image-resized.png] The "2" in 2001:470:1f13:5x0:2::2 - 2001:470:1f13:5x0:2::88 is just my choice. It could be 0 - 1 - or 3 or up until ffff This is my pool. I'm using just a small cut out of the 2001:470:1f13:5x0:0000:0000:0000:0000 to 2001:470:1f13:5x0:ffff:ffff:ffff:ffff range. [image: 1547708220542-c9d3bfbb-bd9b-4b9f-888b-d259e03f4460-image-resized.png] I created a list with DHCPv6 Static Mappings, so all my devices (that are IPv6 aware) always have the same IPv6. Works for me Btw : recently, I started to use parts of my 2001:470:xxcea::/48 chunk to attribute a /64 to my VPN interface. Now my road warrior (that me, actually) has a nIPv6 access even when I'm at placse where only IPv4 is available. he.net is rock solid. It's happens ones or twice that their Tunnel server - in Paris for me, the '216.66.84.42' goes haywire. They always brings things back up rapidly. he.net is a really set it and forget ISP. If you have a good IPv4 ISP, you can have pretty native IPv6 on the fly using toy "/64" and a real "/48". Thank you for the answer :) I use some /64 from /48 instead :) All is ok but you also didn't mention anything about main question witch is why Leases are not shown :) I have 4 ISP, 2 of them are at 10Gbit so pretty decent... PS Now I see that I have RA Disabled... Will try to change some settings there :) Thank you.

Default logging of blocked traffic catch the traffic. The block rule at the bottom is disabled. Logs go to a syslog-server and are analyzed there. UDP Only. No, TCP-ports covered in the port-alias. 80,443, 1024:65535 among other standard ports for outgoing traffic. I would really like the rule set to make sense. Some basics in firewalling is to open on a needed basis. The rule set does just that, and prevents external DNS queries. P2P, not so much. UDP traffic originates from two sources. OpenVPN and a hosted backup solution for customers. Brgs,

Do you still have a copy of the pcap file that we can see? Edit: DHCP request should be in RFC1918 space, no need to obscure that data.

Still nothing for the "suspicious" IP. And to be honest John, I think you've fixed a host of other problems. Hosts losing DNS resolution for internal names at times, ad blocking intermittent, all gone. I can't thank you enough. I really thought I still needed additional servers in the General Setup fields.

Another update: it seems that with every VPN connection, unbound crashed... :(

I finally resolved this using the brute force method... I rebuilt the box. Rather than using a backup I manually recreated my entire config. I had always suspected something had gone wrong with my certificate and cryptographic layer, but was never able to get to the bottom of it. The other symptom I had is that authing over SSH via public key had stopped working as well, while other things, such as HTTPS for the web configurator and my OpenVPN server, still worked correctly. Bizarre. Coincidence or causation - the one thing I could pinpoint is that the DNS related issues started after installing PFBlockerNG, and unfortunately didn't start working again after I uninstalled it. This all broke some time ago (I think around the initial release of PFSense 2.4) so perhaps there was a bug or incompatibility at the time? In any case - local DNS caching, DNSSEC, and DNS over TLS all work perfectly now. Sorry this was the resolution if anyone else runs into this :)

Thank you all for you valuable support, I'll try and come back later (maby with new questions :))

Thanks for pointing out that unbound will restart whenever an interface changes status. Separately I found another thread where a user describes a similar issue (https://forum.netgate.com/topic/139513/dns-resolver-fails-to-work-when-pfsense-has-an-ipv6-address/). I inspected my DHCP log and found that the dhcp6 client was repeatedly releasing and renewing its lease, which then led me to find an erroneous setting in my modem. Unbound now appears to operate stably. Thank you both @johnpoz and @Gertjan. I doubt I'd have discovered the issue without your help and advice.

I did notice that only forward zone domain overrides failed with DNSSEC enabled. Reverse zone donain overrides work perfectly fine whether DNSSEC is disabled or enabled.

I reinstalled the package and it's now there. [image: WId57Ne.png] I don't know why it wasn't in the first place but thanks for the help!

@ronpfs said in Unbound 1.8.1 only single thread processing DNS requests: server:qname-minimisation: yes This is now possible in the gui, no need for it custom just check the box in the gui. [image: 1547111928939-qname-resized.png]

Thank you for answering. Does not make sense, not in my configuration either. But I guess I have to give it a try...

Generally speaking, if you have a Windows Active Directory domain, you should let the AD controller(s) handle your DNS and DHCP duty. Point any FreeBSD/Linux hosts at the AD DNS server(s) for name resolution. The DHCP server in Windows will register hostnames in AD DNS for you. I don't think mixing Active Directory, Samba and ISC dhcpd will work all that well for you.

@jimp -- Thanks for the confirmation on what I'm seeing. I suppose I should follow up with ISC. @johnpoz I completely respect that point of view on reservations. It's just not realistic when I have a dozen worker bees setting up/tearing down stuff every day. They need autonomy w/o getting me involved constantly. At this point, I'm strongly considering going back to dnsmasq -- it worked flawlessly for this. I may absorb the headache of running BIND, but, I'm not sure its really worth the HA benefit that prompted the change in the first place. "don't fix what isn't broken" ¯\(ツ)/¯

Sounds like you might have forwarding on and DNSSEC enabled and are forwarding to forwarders that don't properly forward the DNSSEC forwarding. This is obsured but it totally resolves correctly from the pfsense box itself. WTF? Yes. Unless you set the domain as a private domain in unbound it will not return RFC1918 answers to queries.