Setup DNS over TLS on pfSense 2.4.5
-
Unbound custom options:
# Block DNS over HTTPS (DOH) client requests so that they are redirected to pfSense server: local-zone: "use-application-dns.net" always_nxdomain local-zone: "cloudflare-dns.com" always_nxdomain local-zone: "dns.google" always_nxdomain local-zone: "dns.quad9.net" always_nxdomain local-zone: "dns9.quad9.net" always_nxdomain local-zone: "dns10.quad9.net" always_nxdomain local-zone: "dns.adguard.com" always_nxdomain local-zone: "dns-family.adguard.com" always_nxdomainNot used in my case, only for Firefox or eventual third party clients
Port forward:
Firewall (same pic as in previous post):
I have it working, I just don't understand what's happening and that's my issue:
- mobile devices (Android): Firewall states shows DNS query from Local IP -> 127.0.0.1:53
- Windows machines (2): Firewall states show query from Local IP -> PfSense Local IP:53
- redirects to DNS:853 appear in the form of WAN IP -> DNS IP:853
-> So, rule 1 (red) created by port forward: not used by windows machine
-> rule 2 (red) must allow all interfaces include WAN for port 853 and maybe ? only Pfsense local IP for :53
Now, rule 3 (red) won't block DNS traffic calls (I added it to ensure my above rules are fine and understand how they work)Why the 127.0.0.1 is not enough always ? and why the firewall needs to allow all WAN and not only its self to query the DNS:853. I did not think that even the DNS resolver is subject to firewall rules
edit: maybe I am understanding: Android devices are trying a direct DNS call which is being redirected by pfSense. The windows machines have the router set as a DNS server
-
@elodie80 said in Setup DNS over TLS on pfSense 2.4.5:
Why the 127.0.0.1 is not enough always ?
127.0.0.1 is never going to be a destination that would be tried by lan to get to.. Its a rule that allows your redirect to work. That is all, if you have some other rule that allows it, like an any rule its not even needed.
What is the point of allowing clients to talk to pfsense on 853.. Are you wanting your clients to use dot to talk to unbound? WHY???
Again your redirection to 853 to unbound is NEVER GOING TO WORK!!! Never!! TLS has to use a cert, the cert fqdn has to match... Did you setup a cert that is valid for dns.google for example - that your clients browser is going to trust?
If your goal is to have clients use unbound, and for unbound to use tls to forward to X.. Just block anything trying to use doh or dot.. So they have to fall back to using local dns.. Because your never going to get a redirect on those to work.
-
Ok, thank you again
So I should just remove the 853 redirect port forwarding rules and add a rule to simply block all 853 from any to any like below ?
This setup in fact works, you are right :-)
Are there still things I should fix in the rules ?
Really thank you for the support as it is not so evident when someone doesn't have a lot of knowledge in the DNS thingsBy the way, from time to time, I get this state:
Is it because of the google DNS ? pfSense states show only DNS server IP:853 entries, and all DNS:53 are from Local -> PfSense IP:53
So that's normal ? -
I can confirm that using only google DNS makes that TLS assumption unknown despite it is properly using TLS over port 853
-
A last feedback please on the rules I setup if they seem better ?
Thank you -
That can only know your using dns over tls, if you directly ask them... So yes using multiple NS could account for why it doesn't show you secure some times.
Yeah those rules look sane.
-
thank you a lot again
-
Just a note that you could simplify your 2 and 3 rules down to a single rule, if you wanted... use the Invert Match checkbox for the destination so pfSense will block all port 53 requests that are NOT to "LAN Address".
My example here is a floating rule, so it's using "This Firewall" to cover all interfaces it applies to, but works just as well.
-
While I agree that ! rules can help trim a rule list down to less actual rules. I would just make sure that rules are working as you expect them to, and fully validate it functions as you desire.
There are some weird little things that can happen with ! rules and especially if you have vips, etc.
So unless your fully familiar with how bang rules operate, and how to validate they are working as expected. Its normally cleaner and easier to tell from a glance of the rules what exactly will or will not pass by using explicit rules.. Allow this, Block that.. etc.
-
I better understand with this example the use of "invert match"
In my case, I just followed the doc guide to create the redirect rule.
I do prefer explicit rules since I am not used at all to the firewall modificationsThank you
