configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?
-
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.
-
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?
-
@raffi_ said in configuring DNS over TLS in pfSense 2.4.5 -- are these steps right?:
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
-
@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.htmlSo 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.
-
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..
-
@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!
-
@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.
-
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.
-
@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).
-
@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... ;)
-
@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!
-
@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..
-
@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.
-
@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..
-
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.
-
@imthenachoman What you're saying in terms of adding the rules make sense and if you do it the way you are stating they should be correct. I agree with @johnpoz that the way you initially posted them in that table would lead most pfSense users and especially the veterans to think the order is reverse of what you want. We see them posted top down and we think they would be placed in your rule list the same way. In future posts I would highly recommend you don't list rules the way you have them in that table to avoid confusion like this. The best thing would be to take a screenshot of the actual rules. If this is a proof of concept and the rules aren't actually created yet, then post them the way they would physically show up in pfSense since that would make sense for the vast majority of us.
Thanks,
Raffi
