Setup DNS over TLS on pfSense 2.4.5

phil80

Ok, I really need help
When I moved the rules like above, keeping the allow all rules at the end, all my DNS traffic is blocked and I have no more internet access
So, it seems like the DNS resolver is not working !

Here's the setup in the DNS resolver:

DNS in General tab are the google ones and the DNS override is unchecked there:

Firewall states:

WAN	tcp	xxxxxxx:60087 -> 8.8.4.4:853	FIN_WAIT_2:FIN_WAIT_2	13 / 10	1 KiB / 4 KiB	
WAN	tcp	xxxxxxx:46355 -> 8.8.8.8:853	FIN_WAIT_2:FIN_WAIT_2	13 / 10	1 KiB / 5 KiB

This is without a custom DNS setup in the client, just quering pfSense as a DHCP server with above rules in firewall
Why the allow rule for 127.0.0.1 is not working ?

phil80

A final debug post: any help with the firewall rules please:

They are just for debugging, I understand some rules are not useful:

rule 1 in red: doesn't work, doesn't seem to be used, DNS queries fail. It was created by the port forward rule
rule 2: without it, all DNS queries fail. If I restrict rule 2 to LAN address as source, DNS queries fail also. That part is the most wired. Why DNS fails if I restrict source to the LAN ?

And why the redirect to 127.0.0.1 is not working ?

thank you

johnpoz

What do you have in your custom you have it cut off.

If what you want to do is forward traffic that hits pfsense on 53. to pfsense (unbound).. then have unbound use dot..

You have not shown your port forwards.. you can not redirect without port forwards.

edit: here this took all of 30 seconds to setup.

Set 1.1.1.1 in general, setup unbound to forward and use tls. Created my port forward. my pc using pfsense for dns..

Tested that using encrypted dns to cloudflare..

phil80

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_nxdomain

Not 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

johnpoz

@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.

phil80

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 things

By 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 ?

phil80

I can confirm that using only google DNS makes that TLS assumption unknown despite it is properly using TLS over port 853

phil80

A last feedback please on the rules I setup if they seem better ?
Thank you

johnpoz

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.

phil80

thank you a lot again

MikeV7896

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.

johnpoz

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.

phil80

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 modifications

Thank you