Idiot Trial: Using a VPN Together with DNSCrypt

Idiot Trial: Using a VPN Together with DNSCrypt

It feels painful sharing this. As this is one of those trials, where I hoped that it's not completely my fault, but in the end, it turns out that it is.

In the last post I showed you how you can use DNSmasq and DNSCrypt together on a Mac. The idea being, that DNSmasq caches your DNS queries and DNSCrypt encrypts all of them, essentially giving you more anonymity.

While I thought that was it, the real challenge was getting it DNSCrypt to work with my VPN. I rely on VPNs all the time, thus, it was essential to me.

First Fail: Choosing the wrong provider

Now I do admit that back when I first learned about VPNs, I simply wanted to use one myself – if only for the additional security in LAN settings.

Thus, I didn't do as much research, not knowing much about the topic at that time, and chose a VPN provider that seemed sound and simple to use: Tunnelbear.

'Simple to use’ is what cost me.

What I Chose to Achieve

What I wanted to do, wasn't too complicated. It seemed logical to me. Even smart.

What I chose to ignore was the other side. The implementation part. The knowledge part. The practical knowledge (I didn’t have). All I knew was what a VPN was and how to make use of it.

What it Looked Like in Reality

Through trial and error I actually found out, that my so beloved plan looked actually like this:

I was indeed oblivious to the idea that VPNs might have a hard time working together with other DNS servers. I learned.

Take it for a spin before you decide to completely implement it.

Check your implementation

Now, I couldn’t let this break my setup. I had to figure out what the issue was. I had to figure it using the tool, I didn’t yet know very well: the terminal.

After I set up DNSmasq and DNSCrypt, I checked whether my implementation actually worked.

$ sudo lsof -Pni UDP:5355
dnscrypt-  83 nobody    7u  IPv4 0x1773f85ff9f8bbef      0t0  UDP

Using lsof I could see that DNSCrypt was running on port 5355.

$ ps A | grep '[d]nscrypt'
83   ??  Ss     0:00.27 /Users/mymac/homebrew/opt/dnscrypt-proxy/sbin/dnscrypt-proxy --local-address= --ephemeral-keys --resolvers-list=/Users/mymac/homebrew/opt/dnscrypt-proxy/share/dnscrypt-proxy/dnscrypt-resolvers.csv --user=nobody

ps A showed me that DNSCrypt was handed the right configuration and using the right IP, i.e. localhost , as you can see by parameters. tcpdump also showed that all the traffic was going through the port 5355.

Connecting to the VPN

In my innocence, I thought this was it. I’d connect to the VPN and all the DNS queries would continue to be passed from DNSmasq to DNSCrypt and forwarded through that secure VPN tunnel.

So I connected to Tunnelbear. To my surprise it ran quite smoothly – no major delays or other issues. I was ecstatic!

That feeling didn’t last long. Maybe a week. Until I stumbled upon what was happening behind the scenes.

The Discovery

I don’t remember what made me curious, but something did. Thus, I started my own investigation into the matter. The first thing I did was to check whether any real traffic was being sent through port 5355 while being connected to the VPN.

$ tcpdump -i en0 port 5355

tcpdump ran blank, which is not that unusual considering that DNS queries are not made all the time. I left it running and opened up another terminal (using CMD + D). I, then, crafted a DNS query on a foreign domain name, one that is not already cached by DNSmasq, using dig.

$ dig

tcpdump on the other screen showed no traffic. The first sign that my setup was not working.

I tried to remember what the normal DNS port was, but couldn’t. Thus, I asked /etc/services to tell me.

$ cat /etc/services | grep "domain name server"
domain           53/udp     # Domain Name Server
domain           53/tcp     # Domain Name Server

Port 53! I restarted tcpdump on the standard DNS port and issued another DNS request.

$ tcpdump -i en0 port 53
$ dig

And there it was!

$ tcpdump -i en0 port 53
20:44:13.135905 IP macbook.52240 > router.domain: 33383+ A? (28)

The query showed up. Shit! Proof that the DNS queries weren’t sent out via DNSCrypt.

Bad enough in itself, yet I didn’t understand the big picture. Why wasn’t it sent out of port 5355? I had to find out!

Digging into Tunnelbear

Tunnelbear, being a convenience VPN, doesn’t have a whole lot of documentation. At least not for people like me.

So I ventured into the terminal:

$ ps aux | grep tunnelbear
root             25622   0.0  0.0  2463720   2248   ??  Ss    9:54PM   0:03.51 /Applications/ --cd /Applications/ --management /var/run/com.tunnelbear.vpn.socket unix --management-hold --management-query-passwords --management-query-remote --auth-user-pass --cipher AES-256-CBC --auth SHA256 --log /var/log/tbeard/vpn.log ...

openvpn, called by Tunnelbear, was luckily handing over the log location as a parameter to the function call.

A quick ls revealed that a dnsManager.log file existed as well:

$ ls
daemon.log     dnsManager.log script.log     vigilant.log   vpn.log

A peak into the file revealed that Tunnelbear was removing my DNS settings when connecting to the VPN and overriding it with its own.

$ cat dnsManager.log
Tue Jul 25 18:47:26 2017 Removing DNS Setup
Tue Jul 25 18:55:30 2017 Restoring saved config
Tue Jul 25 18:55:30 2017 DNS_OLD: <dictionary> { DomainName : localdomain ServerAddresses : <array> { 0 : } }

And restoring the old DNS settings on disconnect. Somehow I couldn’t believe it. But somehow I could.

A quick e-mail to the customer support and the prompt reply confirmed what I already knew.

Thanks for reaching out to us about this.

Unfortunately, we're afraid that we don't have any specific work-arounds for this at this time. Since TunnelBear does make some security adjustments on your device (related to your network) when turned ON, it's possible that it won't play nicely with other apps that might make similar adjustments or changes on your device.

Well, I guess that’s what you get for not proper understanding and research. Because if you look closely, you will understand why Tunnelbear and DNSCrypt weren’t meant to work together from the beginning.

Why Tunnelbear and DNSCrypt Weren’t Meant to Be

It’s quite simple.

  1. Look at the website and you will quickly realize for what users their VPN service is for: people with no technical skills who want to surf more securely and privately the Web.
  2. It’s an out-of-the-box solution, which often come with their own limitations.

Photo by Glenn Carstens-Peters on Unsplash