Since I upgraded to 164, my clients, which use ipfire as their dns, fail to get an ip address for several sites (including ipfire.org). I tracked it down to a problem with the DNS in ipfire. When switching to the Domain Name System page on the GUI, it normaly shows “working”, but when i hit “Check DNS Servers”, it takes a long time and afterwars the page shows “Broken”. Hovering the mouse cursor over the “error” message in the status column, the popup shows several messages like this:
truncated reply from n.n.n.n@53(UDP), retrying over TCP; connection timeout for n.n.n.n@53/TCP)…
where n.n.n.n stands for any DNS I try. These are my ISPs, but 1.1.1.1 or 8.8.8.8 are no better. Obviously, DNS is not completely broken, but does not get all input, hence the effect that some adress resolution works, but others not. I changed my pc to use the ISP’s DNS directly. This way I could write this message, but I lost my local name resolution this way and all my portable devices still have a problem. What can I do?
red us attached to a cable modem connected by ethernet to my cable provider, which is part of the swiss quickline the modem is configured in bridge mode and provides a static ip-adress to ipfire by dhcp
blue is the internal wifi adapter of the firewall
orange is a configured ethernet segment, but there are currently no hosts on this segment
green is an ethernet segment, connected to a switch that provides the internal connections
I rebooted everything completely (power off) including switches, but the problem remain
I’ll post output of iptables -L -n -v after completing this post, same with the screenshots and the exerpt from messages (don’t want to loose this text by screwing something up - don’t know this editor well)
I don’t see any warning when executing commands either with the web interface and/or ssh. I executed dmeg on ssh and do not see something disturbing me, but anywey: here is it’s output:
Same issue with my IPFire installation. Just updated to 164 and all DNS traffic stopped working after I switched on the new function. Even deactivating and restoring the backup before the update did not help. Currently the clients can use DNS by modifying the DHCP server’s DNS option to use the ISP DNS servers.
But all the internal DNS clients are not reachable now. Is there maybe any quick workaround on the command line available to make DNS usable again?
Geoblockiing and/or Intrusion Prevention definitely has something to do with the DNS Problem. I had both enabled when doing the upgarde to 164. Now I disabled both and rebooted - And DNS works again. Of course I’d like to have both GB and IPS back. So if I can help to investigate things further please let me know.
Andreas
Can you confirm that you are using the Talos VRT rulesets in your IPS setup. If you remove those rulesets and use the Emerging Threats ruleset and turn on IPS does your DNS then work.
I am running CU164 with IPS using Emerging Threats and Abuse.ch rulesets and my DNS is working fine (TLS based).
It could be that the IPS problem with the Talos VRT rulesets mentioned in an earlier post could be causing an interference with the DNS.
Talos VRT ruleset seems to be the problem with 164 on my system. I re-endabled IPS with abuse.ch like suggested, and DNS kept on going. Then I turned on Geoblockin again, and DNS still seems to work - At least “check dns servers” immediately returns with a green OK. I’ll let it run now for a while and have an eye on it. @pmueller: This is an update: After 16h and a reboot, all is still going well, and there is another thing: ipfire reacts much more snapier again since I removed Talos ruleset. I did not recognise this immediadely, but with 164 and Talos ruleset, not only DNS experienced problems with truncated replies from upstream DNS servers, but the whole system reaction was slugish. This is gone now.
although I am sorry Core Update 164 caused such trouble, I am glad this thread boils down to the known issue with Talos IPS rules, and we are not dealing with another bug.
Therefore, I am closing this as a duplicate thread. Please post additional things related to this issue here, so we can keep track of this bug in one place.
Thanks for your understanding, and best regards,
Peter Müller
