@johnpoz Thank you. Yes we have for example: www.ourdomain.com externally hosted. I have an A record for it in our AD DNS. So all queries for ourdomain.com should be resolvable from our internal DNS whether they are private or public IP addresses. I have done a domain migration to fix this type of a situation in the past and it is not an easy task. (another company running Exchange on an AD with a single label domain lol) If the rebinding protection exclusion does not work I will have to look at some work around. Thanks again for the replies.

@johnpoz Thanks for your help, it is now working.

@Gertjan Unbelievable, it worked. I can't wrap my head around why that would be the case though. Thank you so much for taking the time man

Thank you @johnpoz. I did try using the fqdn for legion, but it did not resolve. I appreciate you pointing out my private domain is not good. I've corrected that. Should only take a couple of hours for it to clear up with the DHCP renewals. I was using a Windows machine when performing the nslookups, so the error was not visible. I didn't get the warning you are referring to in your dig. Legion is a test CentOS box I've been playing with. I'll start using that for testing rather than my PC. I used the below documentation for deploying my DNS resolver on Pi-hole. I'm not expecting you to read it, just putting it here for reference. https://docs.pi-hole.net/guides/dns/unbound/ To be honest, I'm mostly ignorant about this stuff, but I can follow directions, even though I may not know exactly what I'm doing. I'll review the rebinding protections document you linked to. I did create a port forward rule in pfSense to allow the Pi-hole to access external DNS servers, so I don't think it's in a loop. I can nslookup from the Pi-hole using Cloudflare for example, but it fails on a garbage IP as I would expect.

@haroldh said in DNS Resolver and IPsec: buy by default that setting is set to "Any". Wouldn't that also allow the resolver to choose an interface according to the routing table? Yes, it does of course. But since you requested this, my assumption was, that you have currently selected only WAN. Other posts suggest setting it to a specific interface. But the IPsec tunnel is not an 'interface' in that list. Policy-based IPSec connections are not treated as interfaces. You would only get interfaces for VTI IPSec. But I don't assume, that you need to specify an interface in the DNS Resolver settings for a server IP on the remote site of a policy-based IPSec. I guess, pfSense routes traffic to it anyway. And why do other posts suggest choosing the Localhost interface? Is that used by requests that are resolved by pfSense's own resolver? No idea, what the benefit of selecting localhost should be here.

Maybe unbound and pfblocker should be set up before your cloud software and everything else. Immutable data types were just mentioned on youtube. I had to have a crack at threads misbehaving. You do have cache misses. Also you only have 4 gigs of memory. Last time I ran wildcards in pfBlocker with it maxed out (and with Suicata maxed out) I ended up chewing through over 32 gigs of ram and halfway into a swap. With and without the python part it was and with and without suricata, it still took loads of memory.

@netbug For what it's worth, I ran into this same issue recently and found a workaround that seems to be effective. In pfSense, I added the cron package and then created a job that runs every 19 minutes with the following command that creates a static arp entry such as: arp -s 192.168.9.10 00:11:32:7b:29:7d Hopefully you or someone else stumbling across this post will find this information helpful.

@Gertjan Thanks a lot for the help.

@johnpoz said in Could interface-automatic block pfSense Unbound Resolver from running proper DoH server?: @ddoh94 said in Could interface-automatic block pfSense Unbound Resolver from running proper DoH server?: version of Unbound to accept DoH (DNS over HTTPS) Pretty sure unbound requires nghttp2 to do doh, is that available in pfsense? I have never looked into it very deep because well not really of fan of either dot or doh.. Other than blocking it from my clients using it ;) I have zero use for either of them... Sorry, I’m little bit shocked about You: with a so lot of knowledge, ignoring the fact that DoH/DoL become standard (because incredibly rapidly growing numbers of DNS-related attacks in both on private business/industrial and government level) - that’s looks like no having “bird view” what happened in communication world. Am I wrong ? Take my apologies again, I appreciate You in general. While they might have some use in some scenarios.. The way browsers are forcing use of doh on users that have no clue is not good.. And the way it can be leverage to circumvent local dns controls is again not good.. But IN EVERYDAY’S REALITY most browsers (Safari, Chrome, Firefox) extensively using DoT/DoH. So this is reality (also like TTL of DNS records decreasing year by year) in which we may live. Other than a learning exercise I can really not see a scenario where I would want to use doh locally.. Who would be sniffing dns traffic on my local secure network?? Other than me?? For example: any black hacker, that compromise one node and obtain access to one of pfSense’s internal LANs. And this is not only about CARP.

@Antibiotic I am not using pfblocker for dnsbl - I only use it to create aliases that I use in my firewall rules myself. So I have no use for it.

Works fine on this end, exactly the same way but the configuration in 2.7.2 no longer asks for a username for Cloudflare. Instead, it is blank and the password is the API key.

@ebsense the log is from the KEA dhcp server (the new DHCP that will replace ISC DHCP in the future) but in the settings screenshot it looks like you using ISC DHCP. Which one do you use? And a /28 subnet is pretty small (14 usable IPs) so is the pool you created set accordingly?

@thearamadon KEA is not fully functioning. Go back to ISC until they fix it. System/Advanced/Networking.

@johnpoz Got it. Thanks.

@littlebi Again : select "ISC" as your DHCP server, as this is the one that makes the manual valid again. Read the blog post, and you'll understand.