configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?

imthenachoman

I have been reading various blogs/articles on enabling DNS over TLS. Most of them say the same things but some have some contradiction.

I'm trying to combine all the steps into something simple and need help confirming I am not missing anything?

This is for a fresh install of pfSense 2.4.5 and using Cloudflare's DNS servers.

Steps:

Make a backup of settings:
1. Go to "Diagnostics" > "Backup & Restore"
2. In "Backup & Restore" > "Backup Configuration":
  1. "Backup area": Select "All"
  2. "Skip packages": Uncheck "Do not backup package information."
  3. "Skip RRD data": Check "Do not backup RRD data"
  4. "Encryption": Uncheck "Encrypt this configuration file."
  5. Click "Download configuration as XML"
Disable DNS Forwarder
1. Go to "Services" > "DNS Forwarder"
2. In "General DNS Forwarder Options":
  1. "Enable": Uncheck "Enable DNS forwarder" (should already be unchecked)
  2. Click "Save"
  3. Click "Apply Changes"
Configure DNS servers:
1. Go to "System" > "General Setup"
2. In "DNS Server Settings":
  1. "DNS Servers": (table below)
  2. "DNS Server Override": Uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN"
  3. "Disable DNS Forwarder": Uncheck "Do not use the DNS Forwarder/DNS Resolver as a DNS server for the firewall"
  4. Click "Save"
Configure DNS Resolver:
1. Go to "Services" > "DNS Resolver"
2. In "General Settings" > General DNS Resolver Options":
  1. "Enable": Check "Enable DNS resolver"
  2. "Network Interfaces": Shift click all of the interfaces except any of the WAN ones (because we do not want to offer a DNS service on WAN)
  3. "Outgoing Network Interfaces": Select "WAN"
  4. "DNSSEC": Uncheck "Enable DNSSEC Support" (some guides say to check this so I'm not sure)
  5. "DNS Query Forwarding": Check Enable Forwarding Mode
  6. Check Use SSL/TLS for outgoing DNS Queries to Forwarding Servers
  7. Click "Save"
  8. Click "Apply Changes"
3. In "Advanced Settings" > "Advanced Resolver Options":
  1. "Prefetch Support": Check "Message cache elements are prefetched before they expire to help keep the cache up to date"
  2. "Prefetch DNS Key Support": Check "DNSKEYs are fetched earlier in the validation process when a Delegation signer is encountered"
  3. "Harden DNSSEC Data": Uncheck "DNSSEC data is required for trust-anchored zones." (can only be checked if "DNSSEC" is enabled)
  4. Click "Save"
  5. Click "Apply Changes"
Block outbound DNS from LAN clients:
1. Go to "Firewall" > "Rules"
2. In "Floating": (MUST BE DONE IN THIS ORDER)
  1. Add rules (to the top) from "Firewall Rules" below, in order from top to bottom
  2. Click "Save"
  3. Click "Apply Changes"
  4. Test by running nmap -Pn -sT -sU -p 53,853 1.1.1.1 as root and confirming none say open. open|filtered or filtered are okay.
3. Redirect outbound port 53 traffic (for any clients hardcoded to use 53):
  1. Go to "Services" > "DNS Resolver"
  2. In "General Settings" > General DNS Resolver Options":
  3. Go to "Firewall" > "NAT"
  4. In "Port Forward":

DNS Servers:

Address	Hostname	Gateway
1.1.1.1	cloudflare-dns.com	none
1.0.0.1	cloudflare-dns.com	none

Firewall Rules:

Action	Quick	Interface	Address Family	Protocol	Destination	Destination Port Range	Description
Reject	Checked	LAN	IPv4+IPv6	TCP/UDP	any	DNS over TLS (853)	Block LAN DNS 853
Reject	Checked	LAN	IPv4+IPv6	TCP/UDP	any	DNS (53)	Block LAN DNS 53
Pass	Checked	LAN	IPv4+IPv6	TCP/UDP	LAN address	DNS over TLS (853)	Pass LAN DNS 853 to pfSense
Pass	Checked	LAN	IPv4+IPv6	TCP/UDP	LAN address	DNS (53)	Pass LAN DNS 53 to pfSense

NOTE: After you've added the rules, they should be in reverse order than above. You should add rules to the top in pfSense starting with the first row in the table above. When you're done, the last row/rule will be the top/first rule.

Does this look right? Am I missing anything?

--

References/sources:

Raffi_

@imthenachoman

I think it looks right for the most part. I used DoT for a while with pfSense. I recently reverted back to the pfSense default which is letting DNS Resolver (unbound) do the resolving and not forwarding to any external servers. If security is your concern, the default should be better. If privacy is your concern, the default should be better then too.

johnpoz

Firewall rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.

If you have a rule that blocks access to ANY on 853 or 53 above where you allow... How would you ever get to your allow rules?

you create your allow rule above where you block..

Why are you allowing 853 to lan address even, you want to use dns over tls to unbound from devices on your own lan? Why? Who would be sniffing on your own lan to get your dns queries?

imthenachoman

@raffi_ said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

@imthenachoman

I think it looks right for the most part. I used DoT for a while with pfSense. I recently reverted back to the pfSense default which is letting DNS Resolver (unbound) do the resolving and not forwarding to any external servers. If security is your concern, the default should be better. If privacy is your concern, the default should be better then too.

But internet requests would eventually have to be forwarded, no? My pfSense won't be able to resolve www.company.com -- it would need to ask the DNS server, no?

@johnpoz said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

Firewall rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.

Yes. Maybe it is not clear but the idea is to add rules to the top, starting with the rules at the top of the table. So when you're done the PASS rules would be on top.

Why are you allowing 853 to lan address even, you want to use dns over tls to unbound from devices on your own lan? Why? Who would be sniffing on your own lan to get your dns queries?

Fair. So which rule would I delete? What I am trying to do is make sure:

pfSense only uses DoT
All LAN devices use pfSense for resolving and do not try do any resolving themselves (no outbound from LAN 53/853 to WAN) -- I want every single DNS query to go through pfSense so I can log/trace/block/etc.
I know some devices hardcode lookups on 53, and I want to redirect those to pfSense DoT

Raffi_

@imthenachoman said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

But internet requests would eventually have to be forwarded, no? My pfSense won't be able to resolve www.company.com -- it would need to ask the DNS server, no?

Here is an explanation of how pfSense will handle resolving DNS queries by default.
https://docs.netgate.com/pfsense/en/latest/services/dns/resolver.html

So in other words, by default you are cutting out the "middleman". Instead of your pfSense going and asking Cloudflare's DNS server what is this IP, and getting the response www.company.com, pfSense (Unbound) goes directly to the root DNS servers which pretty much any DNS server would do and asks them directly. This is done securely and over time Unbound would create its own cache of these DNS entries and therefore make your future queries immediately.

It's a very good solution and that is why the pfSense devs made it the default.

johnpoz

What is your concern with normal dns, that you want only dot? Is your isp intercepting your dns? With dot you just and handing over trust from your isp that carries all your traffic anyway, to some other dns provider.

I personally think dot and doh are horrible direction, an attempt to centralize the dns is not a good direction.

Until such time that excrypted sni is widespread and supported everywhere. It is not really possible to hide the domain your going to anyway. Since the normal https/tls handshake includes the server name in the clear.. And your isp would always know what IP your going to anyway.

As stated just resolving is better option for pretty much everyone. The only time that dot would make sense is if your isp was intercepting your dns.. And you didn't want to do full blown vpn through your ISP network.

But to be honest your not hiding anything the isp couldn't find out if they really wanted to with dot or even doh.. Since as stated your IP your going to is still going to be seen, and the sni is not encrypted. So simple sniff of the traffic would show them the exact domain your going to - just like your dns query would show them..

imthenachoman

@raffi_

@raffi_ said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

So in other words, by default you are cutting out the "middleman". Instead of your pfSense going and asking Cloudflare's DNS server what is this IP, and getting the response www.company.com, pfSense (Unbound) goes directly to the root DNS servers which pretty much any DNS server would do and asks them directly.

I see. I assume the default configuration of queries directly to the root server are not using encryption?

@johnpoz said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

...

I hear you. I don't disagree with you. I'm not saying I will keep this enabled forever. It is more me just playing and learning. It's how I learn. :/ I got everything setup and just wanted to make sure it was accurate or was there something I'm missing. Knowing if I am missing something would be an educational lesson for me.

The BS around DNS privacy is ridiculous. If you want absolute privacy throw away all of your gadgets. Cash only. Don't drive or take the bus. Don't show your face in public. Folks, DNS is the LEAST of you privacy worries!

imthenachoman

@jwj I do not disagree with you. I wasn't enabling it for privacy reasons. This was an educational experience for me. Networking is my weakest subject and this seemed like an easy thing to play with to learn. I will probably undo it later. I just want to make sure what I did does what I expect/want to make sure my understanding is right.

Raffi_

I agree with the others, but I can also understand going through the setup for the purpose of learning so I won't go further trying to convince you not to set that up. Are you having any specific issue with the setup you outlined?

@imthenachoman It's all good. Fun educational activities could include WPA-Enterprise and Radius on your pfsense box. A test network and the IDS/IPS of your liking. Segregating your traffic by access profile, setting up the VLANS and firewall rules. There is always something interesting to learn.

imthenachoman

@Raffi_ No. It seems to be working but just cause it appears working doesn't mean it is doing what I expect/want it to. Hence why I wanted to check with others to confirm if the steps I have are complete/accurate for the purpose.

@jwj Oh I've got a laundry list of things to do next. pfBlockerNG is first I think. Then IDS/IDP. The other stuff I will have to wait until I get my Unifi APs (waiting for the Wifi 6 ones).

Thanks all!

@imthenachoman Nice! Do be careful with IDS/IPS. Not on your primary network. For a home network IDS/IPS is a quick path to frustration and not a solution to any home network security needs (everything, almost, is SSL/TLS so the IDS/IPS is blind to the traffic).

Raffi_

@imthenachoman said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

@Raffi_ No. It seems to be working but just cause it appears working doesn't mean it is doing what I expect/want it to. Hence why I wanted to check with others to confirm if the steps I have are complete/accurate for the purpose.

You can go to Diagnostics > Packet Capture and run a capture on the LAN. You should see your clients going to pfSense on port 53. Then you can run a capture on WAN and check that pfSense is going out on 853 for queries.

Edit,
If you haven't already install Wireshark to look into those capture files.

@raffi_ Do remember that pfsense may be hitting your DNS provider (as configured in general settings) on port 53. That's to be expected.

If you really, really want to see no port 53 out the WAN you put localhost (127.0.0.1) in the general settings and then configure the DoT in the custom settings for unbound by hand. Just saying you can do that. Don't do that... ;)

imthenachoman

@jwj I only have one home/primary network. I don't need IDS/IDP but getting my hands dirty is the only way I will learn. Plus, I take backups before I muck with anything so I can restore if I really muck it up.

@Raffi_ Thanks!

johnpoz

@imthenachoman said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

This was an educational experience for me

All for that - might want to start with firewall rule order ;) heheheh

Your rules as stated wouldn't even allow clients to query pfsense for dns let alone anything else, since your block rules are above your allow.

Since you have them marked as quick - take it those are floating rules. Are they on the inbound direction or the outbound. If outbound they are pointless..

Advice - if you want help post up picture of your rules, and the interface they are on..

imthenachoman

@johnpoz said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

All for that - might want to start with firewall rule order ;) heheheh

The rule order is right. My thought was that rules would be added to the top of pfSense starting with the top of the table -- top down. So the first rule added would become the bottom rule. I should have worded it better.

Advice - if you want help post up picture of your rules, and the interface they are on..

I learned what I wanted from the DoT rules so I reverted back to no DoT. I've moved on to my next issue. :) Right now I am trying to figure out why I'm having speed issues. pfSense WAN out is getting full speed, LAN client to pfSense is getting full speed, but LAN to WAN out is getting about half. I might just do a reset this weekend. Let's see.

johnpoz

@imthenachoman said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:

The rule order is right.

No it is NOT.. Not how you posted them...

The 2nd rule block any and all dns.. How would I get past that rule to query the lan address for 53..

So the first rule added would become the bottom rule.

Dude - come on.. really? That makes no sense at all, nobody would think like that.. This is why when you want help with firewall rules.. Post the rules, not how you want them, not how you say they are.. The actual rules you put in...

There have been many a post where user says the rules are any any, but ping isn't working, etc.. Well that is because their rule is tcp only not any any.. But they were SURE it was a bug in pfsense because the rules were any any, etc..

imthenachoman

@johnpoz

The first button in the add rule window is to "add rule to top". If the table had final rule order, the someone who doesn't understand FW rules would add them, top down using the "add rule to top" button. No?

In my head that is what I would do/see/understand. If the instructions didn't say "add to top" and instead said "add rules to match the table" then I could understand.

In fact, even the Netsense documentation says to add in the order I have -- I just put it into a table.