Filterdns has stopped resolving hostnames in firewall aliases

slu

@SteveITS did you test/saw this:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/filterdns-thread-errors.html

Maybe we hit a limit because of pfBlockerNG?

SteveITS

@slu That's the "Unable to create monitoring thread" error; not seeing that here.

slu

@SteveITS not seeing this error, but I increase the value anyway and for the moment both systems working again. Monitoring that for the next days...

Gertjan

@slu said in Filterdns has stopped resolving hostnames in firewall aliases:

Maybe this is the issue, because ACME doesn't work if all lists are enabled/blocked.

I've checked them all, and activated, for years now :

I also use the ACME pfSense package for a long time now.
No issues what so ever.

the acme.sh shell script uses the available DNS to find the Letsencrypt server (or alternative) for the renewal request. As pfSense resolves by default, it doesn't care and won't use any 'DoH' DNS servers.

If you set up pfSense, the resolver, as a forwarder, and you forward to a 'DoH/DoT/DoQ' listed server, then unlist that DNS server.

slu

@Gertjan said in Filterdns has stopped resolving hostnames in firewall aliases:

I also use the ACME pfSense package for a long time now.
No issues what so ever.

Off topic:
Thanks for the feedback, interesting this works in your setup. For some reason the ACME script try different DNS server and get a timeout because pfBlockerNG reply (for example) for one.one.one.one NXDOMAIN. Maybe its relevant how ACME is configured.

Since we use the DNS servers from our ISP this can't be the issue here.

Gertjan

@slu said in Filterdns has stopped resolving hostnames in firewall aliases:

aybe its relevant how ACME is configured.

Nice catch !
This :

implies that when you set DNS Sleep to '0', it's the script itself that starts polling every 'x' seconds the domain name servers.
If its using one of the Doh etc, (which you've blocked with pfBlockerng) then yeah, that fails ...

Set DNS Sleep to "200" or so and solved ^^

ohbobva

@SteveITS This has been an issue for me for YEARS. But it only crops up every so often (like today). It's long enough apart that I forget about the filterdns issue and waste several hours looking at the wrong things.

Maybe I just need to set up a cron job to kill and restart filterdns every hour? Would that work? Break something else?

SteveITS

I ran across https://redmine.pfsense.org/issues/14734 which sounds like a possible cause...the IP is incorrectly removed if an FQDN resolving to it changes IPs.

Also per https://forum.netgate.com/topic/199152/unexpected-alias-behaviour-two-ranges/ aliases that contain IPs and an FQDN may fail to populate all the IPs.

SteveITS

14734 was marked as a duplicate of https://redmine.pfsense.org/issues/13792.

I am trying to think of a way around that...have a separate alias+rule for FQDNs that might ever overlap, say for each laptop...?

Patch

Agree
That bug really does make alias much less useful. Two example I currently use aliases for which will fail with this bug

White list for remote access to work server from periheral sites. The laptops will roam between sites

Peripheral site DDNS FQDN
Peripheral site relatively static IPv4 addresses
Laptop 1 DDNS FQDN
Laptop 1 DDNS FQDN

White list from a VoIP supplier with redundant servers in multiple cities. During fault conditions the supplier redirects traffic to better functioning servers in another city

city1.Voipsuppler.com
city2.Voipsuppler.com
city3.Voipsuppler.com
city4.Voipsuppler.com
city5.Voipsuppler.com
city6.Voipsuppler.com
city7.Voipsuppler.com
city8.Voipsuppler.com

Imo
The variable FQDN component of an alias should be completely recalculated from scratch then combined with the constant (explicitly specified) IPs each time. After which only changes from the current IP addressees written to filterdns to update the firewall filtering.