Aliases with FQDN not working in pFsense 2.7 CE or Plus 23.05.01

the_driver_123

Ok but the object is currently used in a rule

I dont understand

Also, pfsense is able to resolve

johnpoz

@the_driver_123 ok if pfsense is able to resolve it - then its not a dns related issue, and something with the filter mech.. those aliases get updated by default ever 5 minutes.. Do you show filterdns running?

Possible this?

https://docs.netgate.com/pfsense/en/latest/troubleshooting/filterdns-thread-errors.html

is filterdns running?

[23.05.1-RELEASE][admin@sg4860.local.lan]/root: ps -x | grep filterdns
49726  -  Is        0:00.02 /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1
16872  0  S+        0:00.00 grep filterdns
[23.05.1-RELEASE][admin@sg4860.local.lan]/root:

the_driver_123

uhm ....

Gertjan

The 'filterdns' logs together with 'unbound' into the Status > System Logs > System > DNS Resolver log.

You should see lines like this :

or other lines that indicate why filterdns can't start or fails.

edit : and it's normal your firewall rules don't work : the aliases stay empty, so the rules never match.

Also : I'm using 23.05.01 and filterdns works just fine.

the_driver_123

I cannot see unbound entries. Filterdns logs are displayed (but the process seems down , correct?)

No errors seem to be displayed

Other checks?

the_driver_123

I have set kern.threads.max_threads_per_proc and set it to 4096, re-loading the Table

kern.threads.max_threads_per_proc and set it to 4096.

ps -x | grep filterdns
29219 - Is 0:00.87 /usr/local/sbin/filterdns -p /var/run/filterdns.pid
43627 0 S+ 0:00.00 grep filterdns

Seems to be ok?

johnpoz

@the_driver_123 why would they change from 13 to 18.x.x.x - why no AAAA records?

If your client resolves some fqdn to IP X, and pfsense resoles it to Y then the rule wouldn't work because they wouldn't match up.

Your dns lookup before had AAAA as well.. But now it only has A, and they are completely different IP range?

they for sure can be different based on geo location from where your doing the query from - but odd that you were seeing 13s before and now 18s?

Gertjan

@johnpoz

In the old world :

18.172.213.14	A
18.172.213.21	A
18.172.213.108	A
18.172.213.90	A
2600:9000:2113:4e00:3:db06:4200:93a1	AAAA
2600:9000:2113:4600:3:db06:4200:93a1	AAAA
2600:9000:2113:a000:3:db06:4200:93a1	AAAA
2600:9000:2113:9c00:3:db06:4200:93a1	AAAA
2600:9000:2113:da00:3:db06:4200:93a1	AAAA
2600:9000:2113:ea00:3:db06:4200:93a1	AAAA
2600:9000:2113:7000:3:db06:4200:93a1	AAAA
2600:9000:2113:f000:3:db06:4200:93a1	AAAA
d2h67oheeuigaw.cloudfront.net	CNAME

the_driver_123

Yes is correct. I'm trying different docker.com sub domains .... don't worry

Now is working well with the ALIAS and FQDN

Thanks!!!

johnpoz

@Gertjan yeah I am sure depending on what part of the globe you are in you would get different IPs.. But he showed 13.x before and now 18s - seems odd that the IPs he was seeing before would change so much, unless he is talking to some other dns than he was before, or routing over vpn or something.

Just wanted to point out if client resolves some fqdn to X, and pfsense resolves it to Y.. The rules would never mach up because client would be trying to go to X, while pfsense rule would be using Y addresses.

the_driver_123

@johnpoz as already explained, I have changed some FQDN using other subdomains. Sorry .

Can I find which rules are using specific ALIAS?

johnpoz

@the_driver_123 said in Aliases with FQDN not working in pFsense 2.7 CE or Plus 23.05.01:

Can I find which rules are using specific ALIAS?

Well that should be completely clear just looking at the rules.. You want some single place that lists like what rules are using alias X? I am not aware of something like that in the gui.. But you could just grep the full rules list..

Anry

@johnpoz
Greetings.
I'll tell you my solution to the same problem.
After reading the recommendations on the link
https://docs.netgate.com/pfsense/en/latest/troubleshooting/filterdns-thread-errors.html
set kern.threads.max_threads_per_proc to 4096.
The problem with determining IP addresses remains.
Set kern.threads.max_threads_per_proc to 8192.
Oh miracle! The lists are working.
In fact it turned out that:

The number of filterdns threads turned out to be more than 4096.