Secure DNS over TLS to Cloudflare, no success.
-
I'm a newbie & hope somebody can help. I started with this:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html
I hoped it would help solve my setup problems. it didn't and threw up some other issues bugging me. Before doing anything now I always backup the configuration. After trying several setup settings in DNS resolver, system general setup and saving, there was no success then the router failed to connect via a subnet next day. My pfsense reboots each day and what I discovered is changes to DNS settings saved are not implemented unless the router reboots and the configurtion settings you get or have saved may not be what you expect. So what is it (caches?) that stop settings through the GUI being implement only after a reboot? There's no helpful flag to tell you that changes may be pending a reboot.
The netgate recipe seems recent but I've had no luck (validation failure) and have confirmed by packet capture that DNS requests to 1.1.1.1 cloudflare are on port 53 not 853.
My default certificate is webconfigurator default (5b472a791***) which I assumed is self signed and may be the problem.
The Hostname for 1.1.1.1 is given as cloudflare-dns.com but I can't confirm this after a web search and whatever I put in the hostname field appears to be saved, but moving off and back to the settings screen it tells lies and isn't really saved. I'm thinking the hostname entry only stays stuck if it's verified?
My simple question (for a simple answer) is what more can I do need to get SSL/TLS working for DNS queries to Cloudflare 1.1.1.1? I'm not running a web server, just simple internet browsing using 1.1.1.1 as my DNS lookup. Thanks
-
It is working here without a problem, maybe show some screenshots of the resolver and general setup.
-
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
and have confirmed by packet capture that DNS requests to 1.1.1.1 cloudflare are on port 53 not 853.
Then your doing it wrong.. Using dot or dns over tls would be over 853.. The cert your using for pfsense gui have nothing to do with it.. Keep in mind how your doing the query, if pfsense is not pointing to its loopback, 127.0.0.1 only and you do a query from pfsense directly it would just use 53..
That cert listed in the setup would be if you were wanting to provide dot to unbound from your local clients.. This has nothing to do with unbound forwarding queries it gets asked to 1.1.1.1 via dot.
cloudflare-dns.com but I can't confirm this after a web search and whatever
Its right there on the cloudflare dot info page.
https://developers.cloudflare.com/1.1.1.1/encrypted-dns/dns-over-tlsDNS stub resolver establishes a TCP connection with cloudflare-dns.com:853. DNS stub resolver initiates a TLS handshake. In the TLS handshake, cloudflare-dns.com presents its TLS certificate.Here I just switched to using dot, took all of 10 seconds to setup.
-
@johnpoz Thanks, I've had a break and I'm back on it.
-
@voxmagna1 Well the problem starts with my ignorance and stupidity: My windows clients use fixed IP and DNS server settings not DHCP, so I can assign them to different subnets. I found no way of doing client MAC filtering via pfsense
But I had left client DNS addresses for prefered and Alternate DNS addresses set for Cloudfare DNS IPs in Windows connection settings. I put in the local DNS 127.0.0.1 and outgoing requests are now on port 853 with nothing on port 53. I can replicate what your screen shots show. My mistake also explains why I kept seeing packets with 1.1.1.1 DNS when that server wasn't configured anywhere in pfsense.
I now have to remind myself how to set rules to force windows clients to only use the pfsense local DNS server and nothing configured in their network connection settings. I can block DNS(53) client requests but I don't know if they can be ignored them forced to pfsense local.
I also have to stop my AV complaining each time I enter the Pfsense GUI, that's for another thread. Thanks
-
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
I found no way of doing client MAC filtering via pfsense
Was MAC filtering in DHCP server what you were looking for?
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
so I can assign them to different subnets.
To fully separate them you need them on different a different LAN or VLAN and probably a managed switch.
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
I can block DNS(53) client requests but I don't know if they can be ignored them forced to pfsense local.
You can Block external DNS requests and redirect DNS lookup to pfsense. But redirecting secure communication is more difficult.
-
@patch Thanks but I'm back to square one at the moment.
After telling Windows to use pfsense DNS on 127.0.0.1 all seemed to work just as johnpoz had said. But some while later client browsers stopped connecting and will only connect if the client is told to use an external DNS server, then DNS queries are back to using port 53? I can ping 127.0.0.1 and get back replies also ping web addresses from within pfsense and get replies. The dashboard shows active traffic from the client browser with no firewall blocks, but client browsers and windows network check errors 'can't be resolved'.I have a suspicion that when some changes are made to pfsense configuration with the GUI, they are not always fully implemented until after a reboot, or the same occurs with Windows client caches?
This is the setup I'm trying to get working:
Windows clients on my home network connect to pfsense with a fixed IP address. The first IP range on the same LAN subnet and interface is split - some reserved IP addresses go to an openVPN configured VPN service provider, the second group in the range is reserved for clients to connect direct to WAN by passing the VPN.
A third subnet on a separate pfsense interface is my DMZ used for Smart T.Vs and other devices that can only access streamed content via an exposed connection to my ISP with no filtering rules. I have firewall rules blocking DMZ to LAN and from LAN to DMZ.
DNS routing seems to be my big problem. VPN providers recommend using their DNS servers and if I enter their addresses in pfsense config, there are no leaks for clients routed to the VPN. The problem comes on the LAN interface, an IP sub group and a subnet acting as my DMV where I would want DNS requests to be routed to Cloudflare DNS servers using TLS. Here's an example:
A. 192.168.1.0 - 192.168.16 all traffic routes via OpenVPN to VPN
B. 192.168.17 - 192.168.1.28 all traffic bypasses VPN: LAN to WAN
C. 192.168.99.0 - 192.168.99.5 a DMZ subnet routes all traffic to WAN and nothing either way to A or B.For A. DNS requests use the VPN tunnel.
for B & C DNS requests to be Cloudflare TLS.I'm a begginner so please bear with me. The task above should be simple enough and important for many home users because most homes now have Smart devices (TVs etc) plugged into a router port with no consideration for security implications on the rest of their network. but I haven't got a working pfsense solution yet.
Allocating fixed ips to devices rather than using DHCP ensures a portable client configured as DHCP won't connect. That's fine, but I have to consider clients may have a DNS server setting when I want any DNS request to go to pfsense local resolver. I spent a lot time trying to understand pfsense filtering and my conclusion right or wrong is if you have clients connected on fixed IPs you can selectively filter or block their traffic.
I mentioned MAC ID filtering because that seemed another way and I could revert back to DHCP connection: What's the MAC address of the connected client? Route or block? If Route take the route via VPN, direct to WAN or default go DMZ route to WAN. Seems simple? Thanks for replies.
-
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
I have a suspicion that when some changes are made to pfsense configuration with the GUI, they are not always fully implemented until after a reboot, or the same occurs with Windows client caches
pfsense is a stateful firewall, which means when communication is established across the firewall, ongoing bidirectional communication is allowed. So to see the full effect of rule changes, the rules have to be updated AND stated cleared.
Also, I'm not an expert in setting up pfsense with multiple wan routes, but I suspect you are going to need 3 interfaces (Lan or Vlan) to achieve the network architecture you want, such as
-
Interface A 192.168.1.0/24 (192.168.1.1 - 192.168.1.255) using VPN gateway
-
Interface B 192.168.2.0/24 (192.168.2.1 - 192.168.2.255) using Wan gateway
-
Interface C 192.168.99.0/24 (192.168.99.1 - 192.168.99.255) using Wan gateway and firewall rules ensuring isolation from A & B interfaces
-
-
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
After telling Windows to use pfsense DNS on 127.0.0.1
What? Dude no!! That is pfsense, which is running unbound - not your clients.. You want your clients to ask themselves, 127.0.0.1 is loopback. They would point to pfsense IP.. Which is what auto happens with dhcp, etc..
Point your clients to pfsense for their dns.
-
I am using the IP address on the client which pfsense is looking to route. It's what goes in the DNS server address fields that confuses me? When I first used 10.0.0.1 it worked just as your screen shot configs. Now I have to enter an alternative cloudflare DNS address for the browser to work and it's using that, even though I've told pfsense to use its local DNS not remote.
Pfsense is seeing the client IP address because the firewall settings are sending traffic (in this case) via openVPN. If I change the client fixed IP to another in my subnet examples e.g the DMZ, traffic does the correct thing, but the browser doesn't get DNS replies or there's something stupid I'm doing with Windows client settings?
-
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
Now I have to enter an alternative cloudflare DNS address for the browser to work
No, no you don't
Such a config is going to be nothing be problematic... Why are you pointing to 10.0.0.1? Are you allowing access to that pfsense IP.. What is that some other local dns on your network?
Pointing client to multiple dns that do not resolve the same stuff, is problematic since you never know which one the client will be asking, and if they get back a nx for a domain they would never ask the other one. 1.1.1.1 for example would never be able to resolve any of your local resources - and if you asked for anything.yorulocaldomain.tld it would just return nx.
Why would you not just point this client on the 192.168.1 network to pfsense IP on this network, which would assume is 192.168.1.1
the firewall settings are sending traffic (in this case) via openVPN
If your policy routing traffic out a vpn, you need rules above your policy route to allow a client to talk to pfsense for dns, etc.
https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing
-
@johnpoz Thks. O.K so now I have most working and the problem was my misunderstanding about Windows client settings. funny thing is there's plenty I can find configuring pfsense but not a Windows clientPC I'm connecting to it: Here's my client settings and with your screen shots config for pfsense all packets are showing port 853 no port 53.
All DNS requests are now resolved by pfsense using TLS to cloudflare. This does throw up a false positive for web based DNS leak tests that see a different DNS provider to my VPN, but I can live with that because I haven't yet worked out if I can get pfsense to use my VPN provider private DNS address 10.x.x.x only for static IPs that route via openVPN.
Thanks for your help. -
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
This does throw up a false positive for web based DNS leak tests that see a different DNS provider to my VPN
What? You understand if you are forwarding to 1.1.1.1 in those "dns leak" tests you going to see whatever their resolvers are. Can promise you the source is not going to be 1.1.1.1
So for example using 1.1.1.1 over just normal 53 would show..
And no if your asking unbound for dns, and you forward it to 1.1.1.1 your not going to see your vpn dns in the leak test.
-
@johnpoz I thought this is the way the web URL leak test seems to have worked for me:
If I set pfsense DNS to my VPN provider private DNS address, and all traffic including the DNS requests pass through the encrypted tunnel. The web based leak test seems to only look for the DNS provider IP address and if it's the same as the VPN connection, spits out the green screen 'Your DNS is not leaking'. However, if I set a public DNS in pfsense and route via openVPN, the web test spits out red screens 'Your DNS is leaking' listing the DNS IPs e.g Cloudflare because the DNS server address is now different from the VPN assigned public address.
This will happen whether pfsense uses Cloudflare DNS over port 53 or port 853 TLS. Am I therefore right to conclude that DNS requests over Cloudflare using port 853 are encrypted and on a matter of 'trust' it's whether you trust Cloudflare with DNS requests or a paid for VPN provider?
You can be confident if a pfsense configuration uses the VPN providers DNS server and traffic is tunnelled to them which is easily checked with a web IP test. But once you use a public DNS server like Cloudflare you can't be confident DNS requests have the same level of security unless you have confirmed they are using TLS port 853 and there are no port 53 leaks?
Now you helped me get DNS over Cloudflare 853 working, I get the correct answer from here which never worked before.
This is a useful test for anybody wanting confidence their pfsense configuration for Cloudflare DNS/TLS/853 is working.
https://1.1.1.1/help?
Replies:
Debug Information
Connected to 1.1.1.1 Yes
Using DNS over HTTPS (DoH) Yes
Using DNS over TLS (DoT) Yes
Using DNS over WARP No
AS Name Cloudflare
AS Number 13335
Cloudflare Data Center LHR
Connectivity to Resolver IP Addresses
1.1.1.1 Yes
1.0.0.1 No
2606:4700:4700::1111 No ( I don't use IPV6)
2606:4700:4700::1001 No ( I don't use IPV6) -
@voxmagna1 said in Secure DNS over TLS to Cloudflare, no success.:
Am I therefore right to conclude that DNS requests over Cloudflare using port 853 are encrypted and on a matter of 'trust' it's whether you trust Cloudflare with DNS requests or a paid for VPN provider?
Yes, that's true.
The difference here is that some services use resolver location to detect VPN use and block access. Video streaming services mostly.
So if you use a DNS service that is using an anycast IP like 1.1.1.1 the actual servers you use will be those close to you. The remote service can use a tailored fqdn to discover where you are resolving from and compare that to your public IP to attempt to discover if you're using a VPN.Steve
