Filterdns stops working

Birke

seems i forgot to add:
the google-alias is type network (the "small subnets"-hint only affects the host type i think), only timeserver and heise are type host.
the size of the google-alias should not do any harm (it is exact one line in the backup-xml:

).

the google and timeserver aliases are always shown in the allowlist-alias table. the google ip-ranges are not split up to ips, they stay networks in the allowlist-alias table.
only the heise-alias is not resolved and then of course not added to allowlist.

if it is really the size of the table, then i wonder why the same alias works on 3 other pfsenses v2.3.4.

Derelict

If the problem is in filterdns, you need to look at what is being put here:

/var/etc/filterdns.conf

Note that when you combine FQDNs with network addresses the entire alias has to be rebuilt by the filterdns process so all of the addresses in the table must be included.

You are probably reaching the point where it might be better to separate into two aliases. One without FQDNs to be resolved and one without.

Yes, that might be a little more work.

Birke

in filterdns.conf the networks are one line each. the complete filterdns.conf is 83 lines long.

but maybe you are right, it might be easier to split the alias. i think i do that next time the filterdns stops working.

Birke

Ok, seems the problem is not solved :(

I put all FQDNs in one alias and all IPs in another. Today filterdns stopped again.
If i add a new FQDN to the alias or to a seperate new alias, it is added immediately to /var/etc/filterdns.conf (the whole file is now 18 lines long).

If i check on console with "ps -A | grep filterdns" i see 5 running filterdns processes. (on my 2.3.4 machines i see only 1 process)
Stopping the unbound-service doesnt change anything.
If i try to kill the filterdns-processes, the process status only changes from Is to Ss and then switches back.

Is there a normal way to stop/restart filterdns?
Or what kill-options do i have to use to stop these processes?
Then i could start a single process of filterdns and see it that solves the problem.

Derelict

Can the firewall even reliably resolve names?

Post the complete output from Diagnostics > DNS Lookup for one of the filterdns FQDNs.

Grimson

https://redmine.pfsense.org/issues/8001 might be related.

Birke

Here is the output of dnslookup for heise.de:

Results
Result 	Record type
193.99.144.80	A
2a02:2e0:3fe:1001:302::	AAAA

Timings
Name server 	Query time
127.0.0.1	14 msec
127.0.0.1	0 msec
8.8.8.8	13 msec
9.9.9.9	13 msec
81.173.194.77	8 msec
194.8.194.60	9 msec

@Grimson:

https://redmine.pfsense.org/issues/8001 might be related.

Yep, i guess its the same bug.
Somewhere in this forum someone mentioned it could help to put in 127.0.0.1 as first DNS in general setup (thats why it is shown twice in the output above). That way one DNS always answers even when the others dont respond.

Derelict

I don't understand why you are mixing "normal" name servers like 8.8.8.8 with 9.9.9.9 - They will give different answers to the same queries. 8.8.8.8 might return A / AAAA records where 9.9.9.9 might return NXDOMAIN. This can make troubleshooting difficult.

If you want to use quad9 properly you have to use dnsmasq (DNS Forwarder), or unbound (DNS Resolver) in forwarding mode, or disable the local forwarder/resolver and tell pfSense to use quad9 exclusively and disable the localhost nameserver from the list using the checkbox on the general settings page.

Having 127.0.0.1 listed twice is also pretty much nonsense.

Is anything being logged in the resolver log that might point to what it doesn't like?

I currently have a name that's not resolving and I get:

filterdns failed to resolve host vpn1.redacted.com will retry later again.

That does get an instant NXDOMAIN, however.

The filterdns debug level is hard-coded in /etc/inc/filter.inc

You might try changing -d 1 to -d 3 there and seeing if anything meaningful is logged.


 /*
                                 * FilterDNS has three debugging levels. The def
ault chosen is 1.
                                 * Available are level 2 and greater then 2.
                                 */
                                if (isset($config['system']['aliasesresolveinter
val']) && is_numeric($config['system']['aliasesresolveinterval'])) {
                                        $resolve_interval = $config['system']['a
liasesresolveinterval'];
                                } else {
                                        $resolve_interval = 300;
                                }
                                mwexec("/usr/local/sbin/filterdns -p {$g['varrun
_path']}/filterdns.pid -i {$resolve_interval} -c {$g['varetc_path']}/filterdns.c
onf -d 1"); /* <---- Change it here */

Birke

ok, deleted 9.9.9.9 and 127.0.0.1 from dns server settings.

i have configured unbound in forwarding mode.

the resolver.log doesnt show anything suspicious. the entries where name couldnt be resolved are already removed from all aliases (they were just old entries).
i will try changing the debug-level and see what is beeing logged, thx for the tip.

i will also reboot the pfsense tomorrow, then i hopefully only have 1 instance of filterdns running.

Derelict

There can be several different filter DNS processes running legitimately. There can be one for aliases and one for IPsec endpoints that must be resolved, for instance. There might be others.

ps axww | grep filterdns

should show them. That should also show the different config files they are using, etc.

Birke

As IPsec-endpoints he have IPs, so that wont need filterdns.

According to the ps axww all processes use the same config file (/var/etc/filterdns.conf) and the same .pid-file.
I guess that are instances that i manually started to make the name resolution for aliases work again.

Birke

ok, after the restart of the pf i only have one filterdns-process running and the names are resolved correct.
lets hope it stays this way :)

m0nji

i have the same problem. after several days, filterdns stopped working. just a reboot of the pfsense solve the problem for the next few days.
i just have 5 fqdn (dynamic dns) entrys in my ip alias table.

(2.4.2 p1)

m0nji

this is annoying, it happened again this night. yesterday after 11pm no more updates.
for the moment i will add a cronjob to restart filterdns every hour.

![2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png](/public/imported_attachments/1/2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png)
![2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png_thumb](/public/imported_attachments/1/2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png_thumb)

Doboy

I have the exact same issue on 2.4.2-RELEASE-p1. I really hope someone finds a fix to this issue.

maybe the cronjob is what i need for now?

Doboy

@m0nji:

this is annoying, it happened again this night. yesterday after 11pm no more updates.
for the moment i will add a cronjob to restart filterdns every hour.

Can you share your cron job with me? I'm not that familiar with cronjob's and i have the same issue. would like a temp fix for now until they fix the bug.

m0nji

@Doboy:

Can you share your cron job with me? I'm not that familiar with cronjob's and i have the same issue. would like a temp fix for now until they fix the bug.

sure….
look at the picture below

Content of cron_filterdns.sh


#!/bin/sh
pkill filterdns
/usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 240 -c /var/etc/filterdns.conf -d 1

![2018-01-10 12_12_26-Services_ Cron_ Edit.png](/public/imported_attachments/1/2018-01-10 12_12_26-Services_ Cron_ Edit.png)
![2018-01-10 12_12_26-Services_ Cron_ Edit.png_thumb](/public/imported_attachments/1/2018-01-10 12_12_26-Services_ Cron_ Edit.png_thumb)

jimp

When the problem happens, does /var/run/filterdns.pid contain a valid PID for filterdns? (Check the "ps uxaww" output to find the filterdns pid)

If you do "killall -HUP filterdns" do the entries resolve again, or are they still missing?

The code in place now tries not to restart filterdns unless it absolutely has to, but perhaps there is some issue when it's running for prolonged periods were it gets confused or fails to update when expected.

m0nji

i will disable my cronjob and give you feedback when it happens again @jimp

Birke

a little update from me:
after the reboot 8 days ago everything still works (with the modification of the aliases).