Aliases with FQDN not working in pFsense 2.7 CE or Plus 23.05.01
-
Dear,
after updating both the CE and PLUS versions to the latest version we noticed that the firewall rules that use ALIAS FDQN no longer work correctly. Only aliases with IP / Network work. Those with Alias do not allow the rule to generate traffic. For example: if I create an ALIAS with the following FQDN - e.g. download.docker.com - and assign it to a firewall rule to enable HTTPS access for a particular server, this does not work. Outgoing browsing is blocked for everyone. Pfsense correctly resolves DNS (I have internal DNS) and public ones in fallback. -
@the_driver_123 show us your firewall rules.
Also what do the firewall logs show? Is the rule being matched? -
Dear, for example
One of the server (10.99.1.8) have to connect to download.docker.com:443
download.docker.com is resolved (from my pc ) as
13.226.244.77
13.226.244.123
13.226.244.48
13.226.244.19My pc and the server is using the same DNS server. Also the pfSense appliance.
Currently this server is unable to reach the web site (curl https://download.docker --> Time Out)
From PFSENSE I can see
DENY Aug 8 12:17:28 DMZ 10.99.1.8:52756 13.226.244.123:443 TCP:S
The Alias FQDN is created:
Next, the Firewall rule
Table Logs
No traffic is generated
-
@the_driver_123 well if the table has any entries - then no the rule wouldn't work.
But I created the same alias - and table populates just fine here.
-
Still empty
Why no entries are defined?
How I can check this ? -
@the_driver_123 table will not populate until it is actually in a rule. on pfsense does that fqdn resolve - what does the output of dns diag show
its possible your having an issue resolving the cname, which is what that fqdn points too
;; QUESTION SECTION: ;download.docker.com. IN A ;; ANSWER SECTION: download.docker.com. 3600 IN CNAME d2h67oheeuigaw.cloudfront.net. d2h67oheeuigaw.cloudfront.net. 3600 IN A 99.84.160.46 d2h67oheeuigaw.cloudfront.net. 3600 IN A 99.84.160.75 d2h67oheeuigaw.cloudfront.net. 3600 IN A 99.84.160.77 d2h67oheeuigaw.cloudfront.net. 3600 IN A 99.84.160.92 -
Ok but the object is currently used in a rule
I dont understand
Also, pfsense is able to resolve
-
@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: -
uhm ....
-
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.
-
I cannot see unbound entries. Filterdns logs are displayed (but the process seems down , correct?)
No errors seem to be displayed
Other checks?
-
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?
-
@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?
-
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 CNAMENo "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
Yes is correct. I'm trying different docker.com sub domains .... don't worry
Now is working well with the ALIAS and FQDN
Thanks!!!
-
@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.
-
@johnpoz as already explained, I have changed some FQDN using other subdomains. Sorry .
Can I find which rules are using specific ALIAS?
-
@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..
-
@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.
