DNS based rules requirements
-
After an upgrade to 2.4.4 and a reboot my DNS based firewall rules no longer work. Can anyone confirm if unbound being in forwarder mode breaks DNS based firewall rules?
-
Without mentioning these rules and unbound settings ?
-
So I have a rule on wan that says allow connection on port 80 from "WAN_ADMIN"
WAN_ADMIN alias is to www.host.org
This rule will work if created while the firewall is up, but when it reboots, the rule no longer works. If I delete and recreate it, it will work, and fails again at the next reboot.
-
Look in your Diagnostics/ Tables for the alias your using... What does it show for this www.host.org IP?
-
This rule is used to "admin" from the WAN side ?
Are you saying that www.host.org isn't resolved for you when pfSense restarts ? You checked the logs ? filterdns (the process that converts FQDN's to IP's) will log over there.
lol, ok, anyway, what @johnpoz said ^^
-
So the table page for that alias is blank.
I can't see anything in the system log for filterdns :/
I do however see that IPSec tunnels fail to come up with an error that the remote endpoint hostname could not be resolved when the system reboots.
-
Well if you can not resolve whatever it is in your alias than your table is going to be empty and your rules using thos aliases not going to work.
You forward to what exactly? You point pfsense just to its loopback? your going t have to go into some more details of your setup.
-
Sorry, I had unbound set in "forwarder mode", I have unset that and it is having no impact.
nslookup for the hostname works as expected.
Tables entry for the WAN_ADMIN alias still show empty, even after adding 4 hostnames to the list.
-
Actually, I have aliases on another box that have both hostname and IP addresses, and only the IP addresses are showing in the list under diagnostics -> tables. It is also on 2.4.4.
On another SG-3100 I have the same wan-admin access rule. It is running 2.4.3 and under diagnostics -> tables it does list the resolved IP address.
-
@bruor said in DNS based rules requirements:
nslookup for the hostname works as expected.
From where to where? Is pfsense pointing to itself for dns?
-
PFsense is set to use the unbound instance on itself to resolve hostnames.
If I go to diagnostics -> dns lookup the names used in the rules resolve OK
-
And if you run
ps -ax | grep filterdns
[2.4.4-RELEASE][root@sg4860.local.lan]/root: ps -ax | grep filterdns 27088 - Is 0:00.00 /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1 6137 0 S+ 0:00.00 grep filterdns [2.4.4-RELEASE][root@sg4860.local.lan]/root:You see filterdns running?
-
There's the issue, it's not starting after the upgrade it appears.
There is also no /var/etc/filterdns.conf file.
-
well if filterdns not running then no your aliases not going to resolve.
Sure your aliases set to hosts(s).. Your not seeing anything in the log about it failing to run?
-
Which log area would I even check for that?
-
I've confirmed that filterdns is not running on 3 of the system I administer that have been upgraded to 2.4.4. 2.4.3 systems seem to be fine.
/var/log/system.log has nothing in it for filterdns
-
Bump up the debug... Guess if not running could be related to
https://redmine.pfsense.org/issues/8758
-
I don't think so, I can't even manually start it...
[2.4.4-RELEASE][admin@pfsense]/root: /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 30 -c /var/etc/filterdns.conf -d 1 filterdns: open file
-
s your .conf not here?
-
On a system that was running 2.4.3 previously there is a config on disk, on a 2.4.4 while setting up a fresh rule with a DNS based alias, no file exists. The config seems to just contain the table entries.
On that the system where the config file exists, a manual launch looks like this.
[2.4.4-RELEASE][adrien@pfsense]/: /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 30 -c /var/etc/filterdns.conf -d 1 filterdns: Could not open device.
-
flush your pid
-
ok, so on a VM instance I can manually launch the process and it'll generate a pid/conf, but the tables status page doesn't show the IP that should be resolved as part of the rule.
On my SG-3100 if I run touch to create the files, and try to run the process manually it still throws the "open file" error. Upon reboot the pid/conf files are gone.
-
On my CE install, the command actually running for filterdns looks like this on 2.4.4
/usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pidany idea what where pflog0 ends up?
-
I found that these entries end up under system logs / system / DNS Resolver. On my CE instance on a VM it is working as exected. ON the SG-3100 it is not.
-
Opened a new issue for filterdns not working on 2.4.4 after upgrade.
https://redmine.pfsense.org/issues/8971?next_issue_id=8970&prev_issue_id=8972
-
@bruor said in DNS based rules requirements:
On my CE install, the command actually running for filterdns looks like this on 2.4.4
/usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pidany idea what where pflog0 ends up?
That is
filterlog(pf log entries), notfilterdns.
-
I responded on https://redmine.pfsense.org/issues/8971 but I'll copy it here:
I do not believe this is a widespread problem. In part due to the fact that if it were, we'd see a lot more feedback about it.
I have 20 systems in my lab (including my edge firewall) and I can't reproduce this on any of them. 4 of these had filterdns running already and have been upgraded across various old versions but are now on 2.4.4 or 2.4.5 (some of each). I added a new alias to all of them which included a hostname, and then used that alias in a rule, and then checked the result. filterdns is running on all of them, the config is populated, the table has the resolved address. There are lots of variations across this lab. Multiple architectures (VMs, bare metal, ARM on SG-1000s and 3100s, even a new aarch64 box) and variations between using the DNS forwarder and resolver and their configuration.
So either this is something specific to your configuration or your environment. The fact that you do not have a
filterdns.conffile present makes me think it's skipping that process for some reason, perhaps because your firewall is crashing or has an error on the console that prevents it from fully booting properly. If the firewall believes it is still booting, it will not write out the filterdns config. Look for/var/run/bootingand see if the file is still present. If so, attach to the console, reboot the firewall, and see why it is not completing the boot process.
-
Drools with Envy over @jimp lab...
While I don't have the lab jim has - I also have never seen this on multiple netgate appliances nor VMs.. I also on purpose put in an alias on my 2.4.4 to resolve with filterdns and not seeing any issues.
-
-
Thanks for the help @jimp, you might be onto something with the shellcmd entries. I use a shellcmd to kick off a python script that stays running as a service.
python2 /usr/local/customscript/server.py
I ended up having to put this in the /usr/local/etc/rc.d folder
Sorry for filing the bug, I figured that I was seeing it across so many systems that it was a core issue and not a shellcmd entry.
-
Hi!
Me too. hostnames in alias doens't resolve, everything else does and dns is running.
I don't have any customization like that. Anyway to troubleshoot this?
-
Do you see filterdns running per the command above?
-
Fyi, I didn't see it running on my systems at boot until after I edited and saved a firewall rule.
-
Well its not going to run unless you have an alias setup that needs to be resolved.
-
I meant I had rules set up than needed filterdns to run. But when I checked at CLI the process wasn't running until I edited and saved a rule with an alias in it. Then like 30 seconds later filterdns was running
-
Had just converted my alias to IP just to get it working. Converted one back to hostname now.
It looks like it running now.[2.4.4-RELEASE][admin@fw.*******]/root: ps -ax | grep filterdns 91818 - Is 0:00.45 /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1 99513 0 S+ 0:00.00 grep filterdnsCan I check if it resolves? Right now the alias I use probably has states open (external backup coming in so can't kill states right now)
-
You can check the contents of the alias at Diagnostics > Tables.
