ANSWERED [Opinion] Best solution against DNS leak on pfSense

securvark

Oke, some may disagree with this solution, but I have had a MAJOR struggle to stop DNS leaks to my WAN and this (I believe!) fixed my issue.

Please, if you believe I am missing something, or providing incorrect information, feel free to correct!

I've tested this extensively with packet dumps on my WAN connection, pfSense "seemingly random" sends DNS queries to the default gateway, regardless of any settings. Sometimes, mutliple test queries from pfSense and clients in the LAN would not trigger a single packet to be sent out over the default gateway, and then suddenly, for whatever reason, I see queries over the WAN for a DNS query test I was doing. Just one, after which it was quiet again for a few queries. Moreover, it leaks your internal domain as well by appending the local domain suffix to a domain I am testing. Example:

12:40:48.313250 IP (tos 0x0, ttl 64, id 15226, offset 0, flags [none], proto UDP (17), length 67)    192.168.1.1.17078 > 84.200.69.80.53: [udp sum ok] 51473+ [1au] A? google.com. ar: . OPT UDPsize=4096 OK (39)12:40:48.341439 IP (tos 0x0, ttl 64, id 24297, offset 0, flags [none], proto UDP (17), length 67)    192.168.1.1.60070 > 84.200.69.80.53: [udp sum ok] 41295+ [1au] AAAA? google.com. ar: . OPT UDPsize=4096 OK (39)12:40:48.368481 IP (tos 0x0, ttl 64, id 17792, offset 0, flags [none], proto UDP (17), length 67)    192.168.1.1.7038 > 84.200.70.40.53: [udp sum ok] 38162+ [1au] CNAME? google.com. ar: . OPT UDPsize=4096 OK (39)12:40:48.404360 IP (tos 0x0, ttl 64, id 37382, offset 0, flags [none], proto UDP (17), length 81)    192.168.1.1.13371 > 84.200.69.80.53: [udp sum ok] 3273+ CNAME? google.com.internal.mydomain.com. (53)

Also, sometimes pfSense (DNS Resolver, actually), queries root servers directly over the default gateway. I haven't figured out why or when. Again, this seems to happen randomly.

I've read everything I could find, I've set gateways for DNS servers to VPN gateways and I've tested VPN gateway addresses as DNS servers (the private range IP's, 10.4.0.1 for example). I tried creating port forwards for DNS and "catch" the DNS queries and forward them to the VPN gateway. Things would look oke for a few minutes and I thought I fixed it, but then suddenly, for no apparent reason, I see packets flying out over the default gateway or I see root server queries out of the blue. I got so tired of this ... .

Enough, the solution:

Disable DNS forwarding in DNS Resolver.

Remove ALL DNS servers under General Setup.

In DNS Resolver, enable DNSCrypt.

In DNS Resolver, under Advanced, tick the following options:

These actually don't help hiding your DNS queries, they are simply "advised" to enable.

- Hide Identity

- Hide Version

- Prefetch Support

- Prefetch DNS Key Support

- Harden DNSSEC Data

In DNS Resolver, make it listen to LAN and localhost only (unless you know you require another interface as well).

In DNS Resolver, make WAN (no VPN, but only your direct internet connection) the ONLY outgoing interface for queries (trust me on this one).

Then, in the custom config box, place the following text:

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853

Save and apply.

Double check you have removed ALL DNS servers from General Settings and you have disabled DNS Query Forwarding in DNS Resolver.

In the above custom config box, you basically told DNS Resolver to forward ALL queries ("." is a wildcard) to 1.1.1.1 or 1.0.0.1 at port 853 and enable SSL/TLS on that link.

Any public DNS server that supports DNS over TLS will do. Adjust the IP and port in forward-addr: to reflect your DNS server of choice.

At this point I can hear you scream behind your PC: but this will send out all my DNS queries out over the default gateway!

Yes, you are correct. Except, nothing will recognizable and not even with packet sniffers or DPI will they be able to see which domains you are trying to resolve. No spying eyes are possible on your queries since they are encrypted over TLS.

The IP addresses above are Cloudflare servers. They guarantee anonymity and apply no DNS blacklisting or filtering.

Another incredible plus with this setup, is that this is EXTREMELY FAST! Most of my queries resolve within 10ms, this is insanely fast. Querying google public DNS directly typically does 40ms from my location. Running DNS over VPN sometimes does 400ms or even more. I can NOTICABLY see a difference in response in my web browser.

Please enjoy! And again, comments, corrections are more than welcome!

Funny result from ipleak.net:

DNS Address - 0 servers, 100 errors.

It doesn't even see which DNS servers I am using.

Thanks!

go558a83nk

Oke, some may disagree with this solution, but I have had a MAJOR struggle to stop DNS leaks to my WAN and this (I believe!) fixed my issue.

Please, if you believe I am missing something, or providing incorrect information, feel free to correct!

I've tested this extensively with packet dumps on my WAN connection, pfSense "seemingly random" sends DNS queries to the default gateway, regardless of any settings. Sometimes, mutliple test queries from pfSense and clients in the LAN would not trigger a single packet to be sent out over the default gateway, and then suddenly, for whatever reason, I see queries over the WAN for a DNS query test I was doing. Just one, after which it was quiet again for a few queries. Moreover, it leaks your internal domain as well by appending the local domain suffix to a domain I am testing. Example:
12:40:48.313250 IP (tos 0x0, ttl 64, id 15226, offset 0, flags [none], proto UDP (17), length 67)    192.168.1.1.17078 > 84.200.69.80.53: [udp sum ok] 51473+ [1au] A? google.com. ar: . OPT UDPsize=4096 OK (39)12:40:48.341439 IP (tos 0x0, ttl 64, id 24297, offset 0, flags [none], proto UDP (17), length 67)    192.168.1.1.60070 > 84.200.69.80.53: [udp sum ok] 41295+ [1au] AAAA? google.com. ar: . OPT UDPsize=4096 OK (39)12:40:48.368481 IP (tos 0x0, ttl 64, id 17792, offset 0, flags [none], proto UDP (17), length 67)    192.168.1.1.7038 > 84.200.70.40.53: [udp sum ok] 38162+ [1au] CNAME? google.com. ar: . OPT UDPsize=4096 OK (39)12:40:48.404360 IP (tos 0x0, ttl 64, id 37382, offset 0, flags [none], proto UDP (17), length 81)    192.168.1.1.13371 > 84.200.69.80.53: [udp sum ok] 3273+ CNAME? google.com.internal.mydomain.com. (53)
Also, sometimes pfSense (DNS Resolver, actually), queries root servers directly over the default gateway. I haven't figured out why or when. Again, this seems to happen randomly.

I've read everything I could find, I've set gateways for DNS servers to VPN gateways and I've tested VPN gateway addresses as DNS servers (the private range IP's, 10.4.0.1 for example). I tried creating port forwards for DNS and "catch" the DNS queries and forward them to the VPN gateway. Things would look oke for a few minutes and I thought I fixed it, but then suddenly, for no apparent reason, I see packets flying out over the default gateway or I see root server queries out of the blue. I got so tired of this ... .

Enough, the solution:
Disable DNS forwarding in DNS Resolver.
Remove ALL DNS servers under General Setup.
In DNS Resolver, enable DNSCrypt.
In DNS Resolver, under Advanced, tick the following options:
These actually don't help hiding your DNS queries, they are simply "advised" to enable.
- Hide Identity
- Hide Version
- Prefetch Support
- Prefetch DNS Key Support
- Harden DNSSEC Data
In DNS Resolver, make it listen to LAN and localhost only (unless you know you require another interface as well).
In DNS Resolver, make WAN (no VPN, but only your direct internet connection) the ONLY outgoing interface for queries (trust me on this one).

Then, in the custom config box, place the following text:
server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853

Save and apply.

Double check you have removed ALL DNS servers from General Settings and you have disabled DNS Query Forwarding in DNS Resolver.

In the above custom config box, you basically told DNS Resolver to forward ALL queries ("." is a wildcard) to 1.1.1.1 or 1.0.0.1 at port 853 and enable SSL/TLS on that link.

Any public DNS server that supports DNS over TLS will do. Adjust the IP and port in forward-addr: to reflect your DNS server of choice.

At this point I can hear you scream behind your PC: but this will send out all my DNS queries out over the default gateway!

Yes, you are correct. Except, nothing will recognizable and not even with packet sniffers or DPI will they be able to see which domains you are trying to resolve. No spying eyes are possible on your queries since they are encrypted over TLS.

The IP addresses above are Cloudflare servers. They guarantee anonymity and apply no DNS blacklisting or filtering.

Another incredible plus with this setup, is that this is EXTREMELY FAST! Most of my queries resolve within 10ms, this is insanely fast. Querying google public DNS directly typically does 40ms from my location. Running DNS over VPN sometimes does 400ms or even more. I can NOTICABLY see a difference in response in my web browser.

Please enjoy! And again, comments, corrections are more than welcome!

Thanks!

One thing I like to make sure is that my devices (streaming media devices like Shield TV) don't use some other DNS that's coded into its OS or whatever app I'm using. I often see them trying to use google DNS.

Anyway, I've gone the way of assigning whatever DNS server I want to use to DHCP clients, forcing them to use only that via firewall rules, and also forcing all those requests through a VPN tunnel so it can't be seen by my ISP.

Your way sounds pretty cool but I have a couple questions off the top of my head.

1) does the forward "all" as you say really mean that attempts to use other DNS as I wrote about are re-written, so to say, to go instead to 1.1.1.1?

2) what if you're using a VPN server quite far away and want your DNS queries to resolve to CDN close to that server? It seems that your way here would resolve to CDN close to your real location. right?

securvark

One thing I like to make sure is that my devices (streaming media devices like Shield TV) don't use some other DNS that's coded into its OS or whatever app I'm using. I often see them trying to use google DNS.

I am assuming you're using pfSense ...

The way to catch LAN DNS queries, regardless of whatever server they have configured, is by making sure a client default gateway is set to pfSense and creating a port forward and associated firewall rule. The steps are outlined in Step 6 in this guide.

I tested this extensively and I can set my DNS server to 1.2.3.4 (doesn't exist!) and DNS simply works. Never do I see packets fly out over port 53 on my WAN. The NAT+rule above will catch ALL packets on port 53 that wants to go OUT, will get caught and redirected to pfSense. Then, if pfSense is configured as I described above, no one will ever be able to see your queries, except Cloudflare DNS server, but they guarantee they don't keep personal logs (anonimized only).

Anyway, I've gone the way of assigning whatever DNS server I want to use to DHCP clients, forcing them to use only that via firewall rules, and also forcing all those requests through a VPN tunnel so it can't be seen by my ISP.

As I describe above, in my situation, this still randomly leaks DNS info to your ISP over WAN.

1) does the forward "all" as you say really mean that attempts to use other DNS as I wrote about are re-written, so to say, to go instead to 1.1.1.1?

No. The NAT + Rules redirect all DNS traffic. The procedure I describe above only makes sure that DNS Resolver from pfSense sends its queries to 1.1.1.1.

2) what if you're using a VPN server quite far away and want your DNS queries to resolve to CDN close to that server? It seems that your way here would resolve to CDN close to your real location. right?

I think you misunderstand how things work (or I misunderstand your question).

When your browser requests a webpage using a domain name (and not an IP address directly), your PC first queries whatever DNS server it has configured for that domain. It will get an IP address back, and will do a handshake with that IP address over HTTP/HTTPS. This handshake is sent over the VPN tunnel. Your URL is sent along with some other information, so that the server accessing knows which domain and URL you are trying to access. The communication from the handshake and following, runs over your VPN tunnel. Whether the initial DNS query is sent over VPN, depends on your configuration. In my config I describe above, it is NOT sent over VPN, but that doesn't matter because its TLS encrypted traffic to the DNS server.

So, it doesn't matter where the VPN server is, or where your webserver or CDN is located. The DNS query is always done by your client whether you're using a VPN or not. Your client cannot communicate with a domain name or URL directly, the internet does not "talk" in domain names or URL's, only in IP addresses. DNS resolution is always the first step done by your client.

go558a83nk

One thing I like to make sure is that my devices (streaming media devices like Shield TV) don't use some other DNS that's coded into its OS or whatever app I'm using. I often see them trying to use google DNS.

I am assuming you're using pfSense ...

The way to catch LAN DNS queries, regardless of whatever server they have configured, is by making sure a client default gateway is set to pfSense and creating a port forward and associated firewall rule. The steps are outlined in Step 6 in this guide.

I tested this extensively and I can set my DNS server to 1.2.3.4 (doesn't exist!) and DNS simply works. Never do I see packets fly out over port 53 on my WAN. The NAT+rule above will catch ALL packets on port 53 that wants to go OUT, will get caught and redirected to pfSense. Then, if pfSense is configured as I described above, no one will ever be able to see your queries, except Cloudflare DNS server, but they guarantee they don't keep personal logs (anonimized only).

>Anyway, I've gone the way of assigning whatever DNS server I want to use to DHCP clients, forcing them to use only that via firewall rules, and also forcing all those requests through a VPN tunnel so it can't be seen by my ISP.

As I describe above, in my situation, this still randomly leaks DNS info to your ISP over WAN.

1) does the forward "all" as you say really mean that attempts to use other DNS as I wrote about are re-written, so to say, to go instead to 1.1.1.1?

No. The NAT + Rules redirect all DNS traffic. The procedure I describe above only makes sure that DNS Resolver from pfSense sends its queries to 1.1.1.1.

2) what if you're using a VPN server quite far away and want your DNS queries to resolve to CDN close to that server? It seems that your way here would resolve to CDN close to your real location. right?

I think you misunderstand how things work (or I misunderstand your question).

When your browser requests a webpage using a domain name (and not an IP address directly), your PC first queries whatever DNS server it has configured for that domain. It will get an IP address back, and will do a handshake with that IP address over HTTP/HTTPS. This handshake is sent over the VPN tunnel. Your URL is sent along with some other information, so that the server accessing knows which domain and URL you are trying to access. The communication from the handshake and following, runs over your VPN tunnel. Whether the initial DNS query is sent over VPN, depends on your configuration. In my config I describe above, it is NOT sent over VPN, but that doesn't matter because its TLS encrypted traffic to the DNS server.

So, it doesn't matter where the VPN server is, or where your webserver or CDN is located. The DNS query is always done by your client whether you're using a VPN or not. Your client cannot communicate with a domain name or URL directly, the internet does not "talk" in domain names or URL's, only in IP addresses. DNS resolution is always the first step done by your client.

Yes, I'm using pfsense.

Maybe I'll have to keep a closer eye on things but whenever I've looked I don't see any leaks out the WAN for DNS queries...though I did realize that if the VPN tunnel went down my firewall rules were allowing non-VPN devices to send their DNS requests out the WAN. But, I fixed that.

My point in the second question is this basically: Say you're connected to a Netherlands VPN server but you physically reside in the USA. With your setup your DNS queries will resolve to a physically nearby youtube CDN. However, you'd want your VPN tunneled devices to access a Netherlands youtube CDN for best performance of youtube. The only way to make that happen is for DNS queries of VPN tunneled devices to go through the VPN tunnel as well.

securvark

Yes, I'm using pfsense.

Maybe I'll have to keep a closer eye on things but whenever I've looked I don't see any leaks out the WAN for DNS queries...though I did realize that if the VPN tunnel went down my firewall rules were allowing non-VPN devices to send their DNS requests out the WAN. But, I fixed that.

My point in the second question is this basically: Say you're connected to a Netherlands VPN server but you physically reside in the USA. With your setup your DNS queries will resolve to a physically nearby youtube CDN. However, you'd want your VPN tunneled devices to access a Netherlands youtube CDN for best performance of youtube. The only way to make that happen is for DNS queries of VPN tunneled devices to go through the VPN tunnel as well.

I'm pretty sure Youtube works based on your VPN exit point location and not the originating DNS request like some CDN providers do. In most cases when they do, you can still select a different country anyway.

I see your point though and its a valid one. You can always decide to route your DNS over TLS traffic through the VPN so that your VPN exit point is taken as the originating DNS requester. But this will result in higher latencies and for me personally, isn't worth it. Your mileage may very of course.

What I'd do if I were you is open a terminal window on your internet router. If that is pfSense (does it have your external IP?), and get the list of interfaces. On the public / WAN interface, run a tcpdump -i {int} -vvv -nnn dst port 53.

If you see packets flying by on your outgoing WAN with recognizable domain names in them, you're leaking. The problem is, people rely on websites to tell them whether they are leaking DNS, which is ONLY based on the DNS servers that are recognized by that website. If those are your providers DNS servers, they say you're leaking. If they are not, they say you're not leaking. But this is simply not true. Regardless of which DNS servers you're using, if DNS traffic goes out over your WAN unencrypted, they can see which DNS server you're querying and which domains (because if tcpdump shows it, they can see that too, it is that simple).

In my experience, you cannot rely on pfSense and DNS resolver (unbound) to NOT send out DNS requests to the default gateway. My tests have shown me that whatever solution I implement from blogs, forum posts, and from my own thinkable solutions, unbound simply does what it wants and does not 100% honor your configuration.

Now, if you have DNS completely configured to use TLS over port 853 and it goes out either over the default gateway or your VPN tunnels, you could create a floating rule from any source to any destination besides LAN address (pfsense) port 53 TCP/UDP and reject those packets. Devices ignoring your DHCP DNS servers and use their own (like Google's 8.8.8.8), can be caught with the aforementioned NAT+firewall rule.

Casper31

What I'd do if I were you is open a terminal window on your internet router. If that is pfSense (does it have your external IP?), and get the list of interfaces. On the public / WAN interface, run a tcpdump -i {int} -vvv -nnn dst port 53.

Hello Securvark,

I want to know more about tcpdump. If I use the command ,I get "cant find device" or "not configured". Perhaps you can tell me more about tcpdump ;specially how to use this on Pfsense?

Gr,Casper

securvark

What I'd do if I were you is open a terminal window on your internet router. If that is pfSense (does it have your external IP?), and get the list of interfaces. On the public / WAN interface, run a tcpdump -i {int} -vvv -nnn dst port 53.
Hello Securvark,
I want to know more about tcpdump. If I use the command ,I get "cant find device" or "not configured". Perhaps you can tell me more about tcpdump ;specially how to use this on Pfsense?

Gr,Casper

On pfSense terminal (command line), type ifconfig to get a list of interfaces and their configured ip's/subnets. Use that name (re0, re1, ovcpnc1, ovpnc2, etc) after '-i' parameter. So if re0 has your public IP and you want to see all packets going out to port 53, you'd type:

tcpdump -i re0 -vvv -nnn dst port 53

go558a83nk

To check for leaks I've always looked at the state table to make sure no connections are being made that I don't want, filtering it to see what I want. Is that a flawed method?

Casper31

What I'd do if I were you is open a terminal window on your internet router. If that is pfSense (does it have your external IP?), and get the list of interfaces. On the public / WAN interface, run a tcpdump -i {int} -vvv -nnn dst port 53.
Hello Securvark,
I want to know more about tcpdump. If I use the command ,I get "cant find device" or "not configured". Perhaps you can tell me more about tcpdump ;specially how to use this on Pfsense?

Gr,Casper
On pfSense terminal (command line), type ifconfig to get a list of interfaces and their configured ip's/subnets. Use that name (re0, re1, ovcpnc1, ovpnc2, etc) after '-i' parameter. So if re0 has your public IP and you want to see all packets going out to port 53, you'd type:

tcpdump -i re0 -vvv -nnn dst port 53

Thank you securvark for the help. It worked and no leaks.

Like your contribution on dns-resolver in Pfsense .

Have a good weekend,Casper

hydrotux

Hi folks,

I found this topic by accident as I'e been trying to resolve the DNS leaks for a while now. I already had a similar setup to that proposed by securvark. What I didn't have was the bit in the "custom config box" where the DNS traffic is routed the Cloudflare server. Here is how it worked for me. I thought I would post it here to share with other.

After doing some tests with and without the above custom config options, this is what I obtained:

**Option A: wih the custom box settings**

a) dnsleaktest.com reports 36 Cloudflare servers based in UK

ipleaks.net reports 0 servers and 100 errors not appearing to be able to resolve the DNS server location (just like securvark)

**Option B: wihout the custom box settings**

a) dnsleaktest.com reports 1 ISP server based in UK (my ISP)

ipleaks.net reports 1 server and 100 tests and eventually shows the ISP server based in the UK county I live in (yeah, managed to go down at county level ...)

So option A seems to be the most suitable option. Its unclear to me though if the DNS traffic is acutally encrypted as DNScrypt as reported in step 3 above, appears to not exist in the DNS Resolver tab of pfSense (do you have to install DNSCrypt as a package .... although I haven't seen it in the available packages). The main concern I have is whether Option A is showing the location of the Cloudflare server as in UK being a coincidence or whether there is a real leak.

I've tried to capture traffic on the WAN port and, from what I can understand, the traffic is going to port 883. Actually, there are only 3 IP in the capture on the WAN interface:

a) the above Cloudflare IP 1.0.0.1

the IP of the VPN provider

c) the IP of my pfsense WAN port (192.168.10.2) which is sitting after an ADSL modem (192.168.10.1)

Question 1: This to me seems correct? How else can I understand from the capture that traffic to the DNS server is being encrypted?

Question 2: Are the locaitons of the Cloudflare servers being in the UK a coincidence or is there any DNSleak component here? The fact that 36 servers are being reported seems to me like there is no DNSleak component in terms of geolocation otherwise there would be only one reported? I'm just wondering whether this is going to cause me headaches with some sites that see the DNS request being processed in the UK as an assumption of the originator geolocation being in the same country

Observations 1: this solution proposed by securvark is by far a better option to that I had. In fact, I had the DNS Resolver using the VPN interface as the ONLY outgoing interface for queries. It worked well but when the VPN failed, my whole network was without internet because I couldn't resolve DNS queries. By having it on the WAN, it's independent of whether a VPN is up and running or not. I guess the downside is that when VPN fails, traffic could be going straight through the ISP without me knowing it.

I'd like to know your thoughts on this and I look forward to hearing what other members think of this.

BTW, I'm only resticted to 1 post/24 hrs until I get a few more approved. Just wanted to say that I'm glad I found this AirVPN community. I've read more on the motivations and history around AirVPN. I have lots more questions, particularly around jurisdiction, geolocation, etc. but I understand it would be offtpic in this forum so I will be patient.

securvark

Hi folks,

I found this topic by accident as I'e been trying to resolve the DNS leaks for a while now. I already had a similar setup to that proposed by securvark. What I didn't have was the bit in the "custom config box" where the DNS traffic is routed the Cloudflare server. Here is how it worked for me. I thought I would post it here to share with other.

After doing some tests with and without the above custom config options, this is what I obtained:

**Option A: wih the custom box settings**
a) dnsleaktest.com reports 36 Cloudflare servers based in UK
ipleaks.net reports 0 servers and 100 errors not appearing to be able to resolve the DNS server location (just like securvark)

**Option B: wihout the custom box settings**
a) dnsleaktest.com reports 1 ISP server based in UK (my ISP)
ipleaks.net reports 1 server and 100 tests and eventually shows the ISP server based in the UK county I live in (yeah, managed to go down at county level ...)

So option A seems to be the most suitable option. Its unclear to me though if the DNS traffic is acutally encrypted as DNScrypt as reported in step 3 above, appears to not exist in the DNS Resolver tab of pfSense (do you have to install DNSCrypt as a package .... although I haven't seen it in the available packages). The main concern I have is whether Option A is showing the location of the Cloudflare server as in UK being a coincidence or whether there is a real leak.

I've tried to capture traffic on the WAN port and, from what I can understand, the traffic is going to port 883. Actually, there are only 3 IP in the capture on the WAN interface:
a) the above Cloudflare IP 1.0.0.1
the IP of the VPN provider
c) the IP of my pfsense WAN port (192.168.10.2) which is sitting after an ADSL modem (192.168.10.1)

Question 1: This to me seems correct? How else can I understand from the capture that traffic to the DNS server is being encrypted?

Question 2: Are the locaitons of the Cloudflare servers being in the UK a coincidence or is there any DNSleak component here? The fact that 36 servers are being reported seems to me like there is no DNSleak component in terms of geolocation otherwise there would be only one reported? I'm just wondering whether this is going to cause me headaches with some sites that see the DNS request being processed in the UK as an assumption of the originator geolocation being in the same country

Observations 1: this solution proposed by securvark is by far a better option to that I had. In fact, I had the DNS Resolver using the VPN interface as the ONLY outgoing interface for queries. It worked well but when the VPN failed, my whole network was without internet because I couldn't resolve DNS queries. By having it on the WAN, it's independent of whether a VPN is up and running or not. I guess the downside is that when VPN fails, traffic could be going straight through the ISP without me knowing it.

I'd like to know your thoughts on this and I look forward to hearing what other members think of this.

BTW, I'm only resticted to 1 post/24 hrs until I get a few more approved. Just wanted to say that I'm glad I found this AirVPN community. I've read more on the motivations and history around AirVPN. I have lots more questions, particularly around jurisdiction, geolocation, etc. but I understand it would be offtpic in this forum so I will be patient.

I'll try and answer your questions, but I'm not an authority by any measure. Keep that in mind.

First things first. In my very personal opinion, there are different opinions of what a DNS leak actually is. Here's mine . Imagine the piping system in your house that's distributing water. When you open a tap, do we call that a leak? Of course not. When half way down the pipe, water drips from a bad connection. Do we call that a leak? Yes we do.

With DNS (again, my personal opinion on this), when you make a request to a DNS server, that server ALWAYS has your IP, your query and the result it sends back. Whether they keep logs or not, at the time of the request, it has all that. Is that a leak? Your query ends up where it needs to be, where you intended it to be ... a destination you chose to trust ... of course that's not a leak! They are the tap that's open. But when you send your request unencrypted to that server that you trust, and your ISP or anyone else who can see the packets you send across the internet, can see the origin (your IP), your domain name query, the destination you're sending it to, and the result it sends back ... do we have a leak? Yes, we definitely do! So what do we do about it? We fix the pipe! We make sure there are no drips, besides the final destination that you choose to trust.

Whatever DNS provider you choose, you need to make sure your pipe doesn't leak to prying eyes that you do not trust.

So how do we fix the pipe? We use encryption. In my example above, this uses TLS. It goes out over your ISP connection but they only see where it's from and where it goes. There is no way for anyone but the source and destination to see what domain you're querying and what answer is coming back. So someone may argue that you're leaking your source and destination IP's. While true, you're doing that with AirVPN server connections too. What does that tell anyone except that you just talked to a DNS server or a VPN server in some datacenter, it tells them nothing else whatsoever.

So Q1, capture traffic on the router on the interface with the public IP on it. Any other capture is useless. Set it to destination port 53 and see what happens. If it stays quiet for an hour or more, after you and your household buddies/family have been browsing around, used youtube, facebook, snapchat, you're good. Next, set it to destination port 853 (you had it wrong, its not 883 unless that was a typo?) and see what happens. If you see packets with indistinguishable and unreadable garbage, that's good too (IMO!! ISP sees queries, but don't know what it is). You could send those queries over VPN. Extra layer of obscurity and maybe security, your choice.

Q2, The leak here (if that's what you want to call it) is that 1.1.1.1 and 1.0.0.1 are "special" addresses. They use a little trick and they are routed to a cluster of DNS servers closest to you to provide the best and fastest experience. So if you are in the UK, that is no coincidence. Read up on Cloudflare's policy, and what info they gather and make up your choice. They gather anonimized data and geolocation among some other things, but no source IP addresses or other identifiable data. Your choice to trust that or not.

Your observation is difficult. I want my internet to go down when VPN is down, but this is a choice. The ONLY traffic that goes out it DNS over TLS to Cloudfare and encrypted UDP tunnel to AirVPN. Not entirely true, I watch Netflix so I have a bypass for AWS and Netflix servers. The problem with AirVPN DNS is that you need to "fix" that DNS server IP address to a gateway address that may vary, depending on your OpenVPN configuration. Using a fixed DNS server to your VPN gateway address only works when you connect your OpenVPN client directly to a server or IP address. But when you use a country FQDN like de.vpn.airdns.org, you may end up on a gen2 server that hands out a different subnet and gateway address to your client, and your DNS won't work anymore. See my post here for more info on how that actually works. I totally love airVPN for their setup with country FQDN's and their load balancing, I really do, but they killed that feature when they chose to push different subnets to clients from Gen2 servers and I had to resort to the fix in that link.

Hope that helps man, feel free to criticise and challenge my thoughts!

hydrotux

Thanks mate for you very detailed response. I'm happy with Q2, I now understand that its just the way Cloudflare is routing the query I send and the fact that its routing to UK servers is probably a way of making the response as rapid as possible.

Regarding Q1, you are right!. I did a capture on WAN/53 and zero traffic from the entire internal network. On the other hand, loads of traffic between 192.168.10.2 and 1.0.0.1. I loaded the capture on WIreshark. I'm no expert on this stuff but I think there is nothing that gives out what app made the request, what address, and what response came back. There is something on destination GeoIP but nothing on source GeoIP. Something on source port.

Here is an example line (a request from 192.168.10.2 to 1.0.0.1 (btw, I deleted the MAC addresses of source and destination ...). I don't hink anything can be deducted from this, would you agree? Maybe I don't understand much about packets and using Wireshark so may be missing something.

Frame 141: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: May 27, 2018 16:23:41.243196000 BST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1527434621.243196000 seconds
    [Time delta from previous captured frame: 0.000041000 seconds]
    [Time delta from previous displayed frame: 0.000041000 seconds]
    [Time since reference or first frame: 0.445195000 seconds]
    Frame Number: 141
    Frame Length: 54 bytes (432 bits)
    Capture Length: 54 bytes (432 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src:,                Dst: Netgear_
    Destination: Netgear_
        Address: Netgear_
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source:
        Address:
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.0.2, Dst: 1.0.0.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 40
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x7925 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.0.2
    Destination: 1.0.0.1
    [source GeoIP: Unknown]
    [Destination GeoIP: Research, 07, Australia, -37.700001, 145.183304]
        [Destination GeoIP City: Research, 07]
        [Destination GeoIP Country: Australia]
        [Destination GeoIP Latitude: -37.700001]
        [Destination GeoIP Longitude: 145.183304]
Transmission Control Protocol, Src Port: 23566, Dst Port: 853, Seq: 1, Ack: 1, Len: 0
    Source Port: 23566
    Destination Port: 853
    [stream index: 6]
    [TCP Segment Len: 0]
    Sequence number: 1    (relative sequence number)
    Acknowledgment number: 1    (relative ack number)
    Header Length: 20 bytes
    Flags: 0x010 (ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 0... = Push: Not set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······A····]
    Window size value: 513
    [Calculated window size: 65664]
    [Window size scaling factor: 128]
    Checksum: 0xc1c5 [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    [sEQ/ACK analysis]
        [This is an ACK to the segment in frame: 140]
        [The RTT to ACK the segment was: 0.000041000 seconds]
        [iRTT: 0.028319000 seconds]

jbkolb

Thank you for this info @securvark. One issue I've found with this method is that any domain overrides you may have set up in DNS resolver no longer work. Is there any way to fix that?

securvark

Thank you for this info @securvark. One issue I've found with this method is that any domain overrides you may have set up in DNS resolver no longer work. Is there any way to fix that?

I'm not sure, I never tried it but it makes sense I guess (for it not to work anymore).

I've been thinking about it and I don't think its possible, at least I don't know how.

If you need one domain to be resolved by a specific DNS server, you could simply query that DNS server manually for the domain, and take the IP address and place it in your clients' hosts file.

flat4

I suggest you look at https://nguvu.org/pfsense/pfsense-baseline-setup/

see how he setup his airvpn and how it prevents dns leaks

securvark

I suggest you look at https://nguvu.org/pfsense/pfsense-baseline-setup/

see how he setup his airvpn and how it prevents dns leaks

Like I explained in one of my replies here, it all depends on how exactly you define a leak. He is, in my definition, leaking DNS queries.

My first issue is he's using OpenDNS, which is owned by a large, commercial organisation. If someone chooses to trust them, fine. I don't.

Second, he's using unencrypted DNS, a search on his article on dnssec gives 2 hits but nowhere does he actually configure dnssec.

Thirdly, he confuses obscurity for security; changing the port on dns to 5353 does nothing if that traffic is simply readable. Anyone can read his DNS requests. You can see how that looks in my post.

He wrote a nice guide that suits his needs. If that's all you need than that's great. It is in my humble opinion, not secure enough.

If he'd do a tcpdump on his pfsense on his WAN interface for dns traffic he'd see a lot of traffic, probably more than he realises.

SunshineSuperman

Might want to reread the nguvu site...

DNS Configuration

One of the biggest changes to my system since creating the 2.3 guide is to my DNS resolution setup. I now make use of 3 sets of DNS servers.

    Local ISP servers: Used for guest network
    DNS Forwarder: Using OpenDNS servers to resolve lookups on my clearnet network. This affords the ability to retain a degree of privacy from my ISP when not using the VPN connection. Local name resolution is forwarded to my DNS Resolver.
    DNS Resolver: Used for VPN network and resolving internal names. It is authoritative for my local.lan domain which means that names not resolved as part of local.lan are not forwarded to the root notes for resolution preventing unneeded leakage of information.

I.e. 3 different DNS tiers... for differing uses (Guest, Clear Net & VPN).

securvark

Might want to reread the nguvu site...

DNS Configuration

One of the biggest changes to my system since creating the 2.3 guide is to my DNS resolution setup. I now make use of 3 sets of DNS servers.

    Local ISP servers: Used for guest network
    DNS Forwarder: Using OpenDNS servers to resolve lookups on my clearnet network. This affords the ability to retain a degree of privacy from my ISP when not using the VPN connection. Local name resolution is forwarded to my DNS Resolver.
    DNS Resolver: Used for VPN network and resolving internal names. It is authoritative for my local.lan domain which means that names not resolved as part of local.lan are not forwarded to the root notes for resolution preventing unneeded leakage of information.

I.e. 3 different DNS tiers... for differing uses (Guest, Clear Net & VPN).

I've read that and I thought I explained it but I'll be more elaborate.

He says he wants the ability to retain a degree of privacy from his ISP when he's not using VPN. So he's using OpenDNS instead of ISP DNS servers. But it's not encrypted so his ISP sees everything anyway. Many countries ISP's need to log traffic and store it for several years. Those queries will be plain text in their logging. In my OP (first post) you can see what those packets look like, they contain the DNS query plainly readable. Anyone with access to that packet stream can see that, regardless of which DNS server you're querying because its unencrypted. It's the whole point of encrypting traffic over the internet in the first place.

Furthermore, using pfsense's resolver or forwarder will trigger unbound to do root lookups, and it's hardcoded to use the default gateway (I posted on the Netgate forums about this too, it's by design). No rule will redirect that traffic away from the internet.

I'm sure his setup suits his needs (he seems to have put a lot of thought and energy into it) but I've got different requirements. My setup above suits my needs. So if anyone quotes that article in reply to my post as if it is a better way for my needs, than I must argue it's not. I'm not saying his setup sucks, I'm just saying in light of my needs and my posted solution, I think it's actually worse (for me, it may work for you though).

I've tested my setup extensively and its 100% secure, no leaks ever, no root queries from unbound, and no can see my DNS queries, except (very obviously), Cloudflare, because they decrypt my tcp stream and resolve my queries to send it back to me, encrypted.

There is one possible downside to this setup, brought up here which has to do with your VPN exit point and your geolocation based on your DNS resolver. Some sitations might send you to a cluster closest to your home and not closest to your VPN exit point. See the posts above for more info.

The other issue that was brought up, is that with the unbound TLS custom config, domain overrides no longer seem to work in pfsense. For home situations, an override in a clients' hosts file will suffice.

Both issues do not affect me personally though.

Hope that clarifies.

SunshineSuperman

Hope that clarifies.

You are picking apart a section relating to 'clear net' access, where the author clearly acknowledges that it only affords 'a degree of privacy from my ISP when not using the VPN connection'. If you have no need for this, then do not use it.

I use something similar to the way nguvu configures DNS access - with a key difference being that I run OpnSense rather than pfSense - I can assure you there are no leaks when using my VPN connections (even with your tcpdump test). Your method may work just fine, my comments were not critical in that respect... rather, for anyone else reading this now and in the future, I am simply pointing out that your dismissal of nguvu's walk-through may be premature.

Open mind and all that...

flat4

Hope that clarifies.
You are picking apart a section relating to 'clear net' access, where the author clearly acknowledges that it only affords 'a degree of privacy from my ISP when not using the VPN connection'. If you have no need for this, then do not use it.

I use something similar to the way nguvu configures DNS access - with a key difference being that I run OpnSense rather than pfSense - I can assure you there are no leaks when using my VPN connections (even with your tcpdump test). Your method may work just fine, my comments were not critical in that respect... rather, for anyone else reading this now and in the future, I am simply pointing out that your dismissal of nguvu's walk-through may be premature.

Open mind and all that...

Nice to see different points of view, I like nvguru and it fits me just fine.

I remember when opensense was in version 10 how has it matured?

Sent from my BND-L34 using Tapatalk

dIecbasC

I suggest you look at https://nguvu.org/pfsense/pfsense-baseline-setup/

see how he setup his airvpn and how it prevents dns leaks

Like I explained in one of my replies here, it all depends on how exactly you define a leak. He is, in my definition, leaking DNS queries.

My first issue is he's using OpenDNS, which is owned by a large, commercial organisation. If someone chooses to trust them, fine. I don't.

Second, he's using unencrypted DNS, a search on his article on dnssec gives 2 hits but nowhere does he actually configure dnssec.

Thirdly, he confuses obscurity for security; changing the port on dns to 5353 does nothing if that traffic is simply readable. Anyone can read his DNS requests. You can see how that looks in my post.

He wrote a nice guide that suits his needs. If that's all you need than that's great. It is in my humble opinion, not secure enough.

If he'd do a tcpdump on his pfsense on his WAN interface for dns traffic he'd see a lot of traffic, probably more than he realises.

One reason to separate the CLRNET onto its own DNS Forwarder mode is it frees the clrnet interface from any complications associated with introducing pfblocker onto the DNS resolver which is used on the secured VLANs to increase privacy etc. The CLRNET interface is not secured by VPN so DNS leakage from the DNS Forwarder isnt a concern. The use of port 5353 is to enable the forwarder to use a different port to DNS resolver and still allow local lookups to function - its not to obfuscate traffic externally.

Theres a degree of separation having an ISP snoop on traffic to external DNS servers and actually resolve the queries themselves. My ISP censors a number of web sites too which arent affected by resolving with OpenDNS.

You can swap out the OpenDNS servers on the CLRNET for any other DNS servers you fancy, OpenDNS is one of the more reliable ones with less snooping than the more typical Google 8.8.8.8 etc.

I've verified again there are no DNS leaks via WAN from the VPN subnets.

There are a number of improvements to DNS available now which can improve privacy further, ie DNS TLS and a redirect for any hardcoded DNS servers in android devices etc.

securvark

Hope that clarifies.

You are picking apart a section relating to 'clear net' access, where the author clearly acknowledges that it only affords 'a degree of privacy from my ISP when not using the VPN connection'. If you have no need for this, then do not use it.

I use something similar to the way nguvu configures DNS access - with a key difference being that I run OpnSense rather than pfSense - I can assure you there are no leaks when using my VPN connections (even with your tcpdump test). Your method may work just fine, my comments were not critical in that respect... rather, for anyone else reading this now and in the future, I am simply pointing out that your dismissal of nguvu's walk-through may be premature.

Open mind and all that...

Well I'm sorry to read that once again, you seem to misunderstand what I am saying. I'm not sure if its my incompentence to get a message across or whether you're a very selective reader, I guess it doesn't matter.

I picked apart that section because you quoted it and the author himself said he wants privacy from his ISP, and then configures it in a way that does NOT provide privacy. I can't make it much clearer than that.

I credit him for a nice guide, I'm grateful you brought it up and I read it twice. I've been completely repectful to peoples' differing needs. I invited feedback and I've looked into every comment I got, acknowledged problems where they were real with my setup and helped people fix it, but you accuse me of not having an open mind. Whatever dude ...

SunshineSuperman

I remember when opensense was in version 10 how has it matured?

I had been trying opnsense off and on for a while after the initial fork, although I think it was around this time when I made a permanent change (mid 17.7.x releases) - pretty much just on a philosophical basis. Can't lie - it was tough initially!

There still isn't a pfBlocker drop in replacement but plenty of alternative methods to achieve similar outcomes. Suricata/nmap is temperamental on what interfaces it'll work on (& there is no snort option). tls-crypt is not yet part of their openvpn gui.. but other things just seem much simpler. Code feels leaner but somehow more polished (the features that are there work well!), there is a positive feel to the community and I've had great responses from the developers on a few issues along the way. IMHO the web interface is more logically laid out... but that can make following pfsense examples *slightly* more troublesome! Ha!

If you haven't checked it out lately, I'd say it is worth a revisit.

flat4

I remember when opensense was in version 10 how has it matured?
I had been trying opnsense off and on for a while after the initial fork, although I think it was around this time when I made a permanent change (mid 17.7.x releases) - pretty much just on a philosophical basis. Can't lie - it was tough initially!

There still isn't a pfBlocker drop in replacement but plenty of alternative methods to achieve similar outcomes. Suricata/nmap is temperamental on what interfaces it'll work on (& there is no snort option). tls-crypt is not yet part of their openvpn gui.. but other things just seem much simpler. Code feels leaner but somehow more polished (the features that are there work well!), there is a positive feel to the community and I've had great responses from the developers on a few issues along the way. IMHO the web interface is more logically laid out... but that can make following pfsense examples *slightly* more troublesome! Ha!

If you haven't checked it out lately, I'd say it is worth a revisit.

I think I will spin up a VM and give it a go,

Sent from my BND-L34 using Tapatalk

SunshineSuperman

I think I will spin up a VM and give it a go,

Have fun!

ANSWERED [Opinion] Best solution against DNS leak on pfSense

Recommended Posts

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Join the conversation