OPNsense Forum
Archive => 22.7 Legacy Series => Topic started by: JGN1956 on August 22, 2022, 01:01:27 pm
-
Good morning. Some days ago I opened a topic about UNBOUND not responding or responding SERVFAIL to clients in VLANs even though the same request made from the firewall was responded correctly. None of the responses worked in my installation and I decided to try DNSMasq. With DNSMasq everything worked correctly until I activated DNSSEC. With DNSSEC active I could see the following behaviour:
- From the firewall itself DNS requests worked correctly all the time.
- From VLAN clients, if the url was already in cache (from a previous firewall request, for example), everything worked
- From VLAN clients, if the url was not in cache, the request did not work.
In this last case, I made a packet capture for port 53 in both the VLAN and the WAN and I could see that the request went form the local PC to the firewall, and then from the firewall to the configured DNS servers (1.1.1.1 and 8.8.8.8 in my case) which responded with the A record address requested. The strange thing is that, after that, the firewall responded a SERVFAIL to the client and the response was not cached.
To me this looks in some way similar to the problem I had with Unbound. I have been checking OPNSense firewall log in both interfaces, local VLAN and WAN to see if something was rejected and the problem was some missing rule but nothing was rejected apart from the UDP 1900 that I do not allow.
I do not like to have dns configured without DNSSEC but, for now, is what I have since it does not work otherwise, and I would be grateful if somebody could give a way to make it work.
Thank you in advance.
-
In the WAN packet capture, do you see any DNSSEC data (RRSIG records) in the responses?
-
Good afternoon. When I ask from the PC, no RRSIG and, of course, no name resolution. However, when I ask from the firewall, the RRSIG packets are there and the response is correct.
Does it make any sense to you?.
-
Doesn't make sense to me, no. Just to make sure: If you previously experimented with Unbound, keep in mind that you can't have both running simultaneously (on the same port).
-
No, Unbound is not running, OPNSense does not allow both of them running at the same time. I do not know what else to do except start from scratch , test Unbound and DNSMasq with the fresh new installation and later on restore my present configuration from a backup. The problem is that I will have all my devices (including my wife´s PC) disconnected from Internet for some time, and that is keeping me from doing it, above all, because I am not sure that it will solve the problem.
One other thing I was thinking, and I do not think is the problem, but just to discard it. My Firewall is behind the carrier router, and therefore I have double nat. Do you think that may have something to do with the problem. I have to keep it that way because my line is fiber optics and the carrier uses a special configuration for TV.
Thank you very much for your help.
-
DNSSEC validation requires EDNS, large UDP packets and / or TCP. This can cause issues under certain circumstances.
But what doesn't make sense at all is unbound and dnsmasq behaving differently depending on whether a request comes from localhost or somewhere else.
-
Well, I finally decided to do a fresh install from scratch and just Wan and LAN active with no other changes made in config. The results were the same and I checked the DNS logs. With Unbound and using the standard config (DNS pointed to itself), the firewall could not update nor find any URL. Apparently, the internet provider (Movistar Spain fiber optics) is blocking access to the root servers (I checked the requests but there was no answer), and therefore, there is no name resolution, until you specify alternative DNS servers.
Something similar happens with redirect DNSMasq and DNSSEC which is blocked by the operator (not the requests made directly from the firewall).
I looked for these things in Movistar forums and found that they justify it in order to avoid internal DNSs in home or small companies sites, with may have potentially insecure configurations and, therefore, be the target for DNS poisoning. So, to avoid it, they do not admit full DNSs like Unbound or encrypted DNS forwarding. Apparently the configuration is different for other types of network accesses.
So it is like it is in my case and I have to trust that the operator filters DNS traffic correctly. It is their policy and the justification is reasonable.
Anyway, thanks for your help.
-
It is their policy and the justification is reasonable.
I couldn't agree less. That's terrible behaviour.
Still doesn't explain why it apparently worked in some situations. Whatever.
Workaround: Configure Unbound to forward all queries via DoT to server of your choice. Unbound will still perform DNNSSEC validation.
Cheers
Maurice
-
From the firewall itself it works but from internal networks encrypted redirections do not work at all. It is the same that happens with DNSMasq.
-
Asking naively, wouldn't using DNS over HTTPS (DoH) be next to impossible for the ISP to stop?
How to Configure DNS over HTTPS (DoH) Using DNSCrypt-Proxy in OPNsense (https://homenetworkguy.com/how-to/configure-dns-over-https-dnscrypt-proxy-opnsense/)
-
That did the trick :D.
Thank you very much.