@johnpoz
/me facepalms.
Sorry for not reading the "Basic functionality present in 23.09" sentence all the way to the end.

I usually look at the release notes before running the upgrades. But in this case the combination of :

2.7.0 not suggesting upgrade to 2.7.2 HD Crash leading to fresh install from freshly downloaded 2.7.2 Configuration restore Got deprecation warning at start-up, followed the advice.

did not help.

I guess we can now close this question with a will work later on when kea implements DHCP-> DNS resolver updates.

Thank you very much for your help.

@chrisjx bug reports can be made at Redmine.pfSense.org.

@wmw509 glad you got it sorted.

@kramer9

https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#upgrade-not-offered-library-errors

Whole bunch of exciting work happening for Kea right now. Should be in 24.08-dev snap real-soon-now. (but really, actually, soon!)

@Flemmingss You can either duplicate the DDNS entry in pfSense such that there is one for every A record you want to change. Or you could keep changing only one of the A records and use CNAMES for the others.

@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.