Cloudflare DNS + PIA
-
Has anyone been able to configure their system so that non-vpn DNS requests go through encrypted Cloudflare and their PIA DNS requests go to PIA servers? Currently, all my DNS requests are going through cloudflare's servers.
I've been able to get PIA to work smoothly as a client within pfsense, and I've even assigned it an interface. I tried configuring different DNS servers for different interfaces under General -> System Setup however that did not work for me.
My suspicion is that it has something to do with the custom option directives under Services -> DNS Resolver -> General Settings, specifically
forward-zone: name: "." forward-addr: 1.1.1.1@853 forward-addr: 1.0.0.1@853I probably need to also toggle on/off upstream SSL.
-
my router is configured like this
general dns servers> PIA server gateway = none and nothing else there
services > dhcp server > top DNS server is PIA. 2nd server is cloudfare
my vpn traffic uses PIA. and passes leak tests. my devices that data travels over the wan uses cloudfare
-
If you're using 2.4.4, DNS-SSL support has been added. But as noted on the configu page, when you go SSL for forwarders, all forwarders are expected to support SSL. (This is an unbound limitation)
I've been able to come up with a hybrid solution to secure DNS via WAN during bootup, then fallback to using the non-SSL via VPN links once the links are up. Have tried to go full DNS-SSL (can't use PIA servers for this), but so far still having some issues that I'm still working through troubleshooting, though reports in the 2.4 forum say it's fully working with just cloudflare & SSL.
To setup the hybrid config to secure WAN DNS (using pfSense 2.4.4:
Basically configure your DNS as normal (non-SSL) under System >> General, then
Under Services >>> DNS Resolver, add a domain override for "privateinternetaccess.com" to point to cloudflares DNS and check the use DNS-SSL. This will force all lookups for privateinternetaccess.com to cloudlfare using DNS-SSL (via both WAN & VPN).
Then create two outbound float rules on your WAN interface, the first to allow only DNS-SSL to CloudFlare, and the second to block/reject any non SSL DNS out the WAN. This will restrict only DNS-SSL out the wan while the WAN is being used for DNS until the VPN links come up and DNS traffic is routed out the VPN.
What should happen is that when firewall starts up and goes to lookup the hostname for the PIA link, it will try all configured DNS, but the firewall will only allow DNS-SSL to cloudflare. Cloudflare returns the ip for the VPN host, the vpn link is brought up and routing is updated to the VPN link.
Once the VPN links are up then all non DNS-SSL is then routed via the defined routes (or default if def1 is being set) via VPN.
-
@TechyTech:
Then create two outbound float rules on your WAN interface, the first to allow only DNS-SSL to CloudFlare, and the second to block/reject any non SSL DNS out the WAN. This will restrict only DNS-SSL out the wan while the WAN is being used for DNS until the VPN links come up and DNS traffic is routed out the VPN.
For the second rule you mentioned, I assume you would create this rule by blocking any traffic whose destination port is 53 and destination IP is not 1.1.1.1?
Also, have you tried your configuration with any dns leak testing sites? i.e. dnsleaktest.com or whoer.net? My problem is, regardless of my settings, I get US based Cloudflare is detected as my DNS server.
For example, when I use my normal LAN connection with my regular default gateway, I get Cloudflare US as my DNS (as expected). When change the default gateway of my LAN to my VPN connection (which is a tunnel to the UK or New Zealand) I'm still getting Cloudflare's US based DNS servers even though I should be getting Cloudflare's servers in those countries.
Based on this behavior, from what I can tell, It's almost like the DNS traffic has its own independent tunnel outside of the VPN/default gateway.
-
@sparkman123 said in Cloudflare DNS + PIA:
@TechyTech:
Then create two outbound float rules on your WAN interface, the first to allow only DNS-SSL to CloudFlare, and the second to block/reject any non SSL DNS out the WAN. This will restrict only DNS-SSL out the wan while the WAN is being used for DNS until the VPN links come up and DNS traffic is routed out the VPN.
For the second rule you mentioned, I assume you would create this rule by blocking any traffic whose destination port is 53 and destination IP is not 1.1.1.1?
Basic answer Yes. I actually have a few rules I use depending on what I'm playing with. Since I also have been testing Tenta's DNS-SSL, I create an alias of DNS forward hosts, then one rule to allow only DNS-SSL (port 853) to allowed forwarders (defined by host alias), then another rule to block any other DNS (53/853) in case any other client tries to use their own DNS, so that only my defined forwarders are allowed only DNS-SSL out the WAN and any other DNS activity (SSL 853 & non-ssl 53) is blocked. Mix and match as you need but the jist of it is to allow only DNS-SSL, restricted to the DNS provider of your choice if you desire, then block any other DNS activity egressing via the WAN that didn't pass the first rule, until the VPN link is up and routes to DNS are shifted over.
Ultimately I only have rules on my WAN that allow only DNS-SSL to specified forwarders and OpenVPN to specified VPN hosts, and everything else egressing the WAN is blocked. This allows DNS to get the VPN service host address, and connection of the VPN links, and blocks anything else that may default out the WAN until the VPN links are brought up the the routing is shifted over to the VPN links.
Also, have you tried your configuration with any dns leak testing sites? i.e. dnsleaktest.com or whoer.net? My problem is, regardless of my settings, I get US based Cloudflare is detected as my DNS server.
1.1.1.1 like googles 8.8.8.8 is an ANYcast address. Basically when you access it it's like saying give me the closest UNIcast address associated to this ANYcast address. How your ISP handles AS group routing may affect the use of ANYcast addresses and the resulting UNIcast accessed host.
As example: When I run the DNS leak test, it detects the actual IP's of the Cloudflare DNS servers that got accessed, not the 1.1.1.1 / 1.0.0.1 address that is configured as the forwarder.
For example, when I use my normal LAN connection with my regular default gateway, I get Cloudflare US as my DNS (as expected). When change the default gateway of my LAN to my VPN connection (which is a tunnel to the UK or New Zealand) I'm still getting Cloudflare's US based DNS servers even though I should be getting Cloudflare's servers in those countries.
Based on this behavior, from what I can tell, It's almost like the DNS traffic has its own independent tunnel outside of the VPN/default gateway.This depends on where the traffic is coming from and what you have configured for outbound interfaces under DNS resolver. If coming from your LAN it will go via policy or default route as LAN rules define, but if initiated from the firewall, coming from the DNS resolver, unbound will try to access all configured DNS directly out each configured outbound interface, even bypassing routing. To wit, it will keep track of which DNS was accessed and how quickly, via each interface and attempt to optimize future activity from there.
When using a VPN client and shifting your default route this can cause some unexpected behavior between expected routing due to direct out the interface access. So, in short, where your LAN client is getting routed to, and where pfSense sourced services are routing to do not always go the same routes.
Simplest way around this is to only use on the lo or 127.0.0.1 interface as the outbound interface for DNS resolver under pfSense, this will cause all traffic from the firewall dns to go through routing, as well as limit unbound from attempting to access each defined forwarder more than once (all forwarders per each outbound interface), such that when your VPN client is up and becomes the default route, your DNS traffic will shift to the temporary default route (def1) accordingly. Similarly is to define a gateway for each DNS under System >> General, this will cause a static route to be created for that DNS when the defined gateway is up, otherwise it goes through default routing, but he same direct out interface issues noted above still come into play if you have additional interfaces defined.