Leaking DNS
If you have followed my series on setting up OpenVPN, you will have a client capable of connecting to a server and routing most traffic down the pipe. I say most because the DNS requests will not be routed at this stage.
TunnelBlick will warn you about this when it connects to the server.
2025-03-04 09:05:59.143609 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
2025-03-04 09:06:00.250685 *Tunnelblick: Warning: DNS server address is not being used.
2025-03-04 09:06:00.254386 *Tunnelblick: Warning: DNS server address 192.168.1.254 is being used but should not be used. That may indicate that more than one network interface is active. Tunnelblick does not support multiple active network interfacesEssentially the DNS requests are still being routed in the normal fashion from my laptop to my access point running on 192.168.1.254. The access point is routing requests to my ISP as per normal. So although my regular traffic is encrypted and routed via the VPN, my ISP can still see what sites I visit by my DNS requests.
The handy website https://dnsleaktest.com/ makes this very clear
We have a number of options here
- push the DNS setting for the client to use, cutting the ISP out of the picture
- push the DNS setting for the client to use run our own DNS server
Specifying a DNS Server
In there OpenVPN server configuration file there is the option to set a push directive which pushes the IP address of the DNS server to use. We’ll use the Cloudflare DNS for the initial configuration as it’s reliable and quick. Editing the configuration file
sudo nano /etc/openvpn/server.conf
# add the line
push "dhcp-option DNS 1.1.1.1"If you restart the sever and then reconnect a client you will see the message confirming that DNS is being routed over the VPN
2025-03-04 12:49:17.046169 Initialization Sequence Completed
2025-03-04 12:49:17.046218 MANAGEMENT: >STATE:1741092557,CONNECTED,SUCCESS,10.8.0.2,217.160.74.182,1194,,
2025-03-04 12:49:17.046288 Data Channel: cipher 'AES-256-GCM', peer-id: 0
2025-03-04 12:49:17.046300 Timers: ping 10, ping-restart 120
2025-03-04 12:49:17.046308 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
2025-03-04 12:49:18.261799 *Tunnelblick: DNS address 1.1.1.1 is being routed through the VPN
Now the DNS request are being pushed to Clouflare (1.1.1.1) servers.
If you want to see the DNS requests in real time, use a tool like WireShark or DNSTop.
Running a DNS Server
Another option at this point is to install a DNS server on the VPN server. This may sound daunting but it’s actually pretty easy, far easier than getting OpenVPN up an running.
To install
sudo apt-get install bindTo configure the sever, edit the /etc/bind/named.conf.options configuration file
sudo nano /etc/bind/named.conf.options I did a few things beyond the default
- I specified the IP address of the VPN server local subnet. This should mean the DNS server is not visible from externally
listen-on { 10.8.0.1; };
- I only allow queries from the VPN subnet
- allow-query { 10.8.0.0/24; 127.0.0.1; };
- I disabled the forwarding – so the requests will be processed and not simply forwarded.
options {
directory "/var/cache/bind";
recursion yes;
listen-on { 10.8.0.1; };
allow-query { 10.8.0.0/24; 127.0.0.1; };
dnssec-validation auto;
auth-nxdomain no;
};I checked the configuration using the named-checkconf command
john@ubuntu:~$ named-checkconf /etc/bind/named.confand then restarted the bind9 server
sudo systemctl restart bind9I can now resolve hostnames using the local DNS server by specifying the address 10.8.0.1
john@ubuntu:~$ dig @10.8.0.1 google.com
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @10.8.0.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34228
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6e4e750629634dff0100000067cacdb0accd50c81da6b6f6 (good)
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 172 IN A 142.250.185.78
;; Query time: 0 msec
;; SERVER: 10.8.0.1#53(10.8.0.1) (UDP)
;; WHEN: Fri Mar 07 10:42:56 UTC 2025
;; MSG SIZE rcvd: 83Before I get the client to use the DNS sever I have to ensure that the firewall on the local machine will allow requests from the VPN Tunnel to get to the DNS server. This wasn’t initially obvious to me as the VPN Server and DNS Server are on the same machine, but requests will be blocked by the UFW firewall. The “external” firewall, if there is any, will not need to be updated as the DNS server is not going to be internet facing, its just there to support the VPN.
Checking the UFW status now I get
john@ubuntu:~$ sudo ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] 1194/udp ALLOW IN Anywhere
[ 2] OpenSSH ALLOW IN Anywhere
[ 3] 1194/udp (v6) ALLOW IN Anywhere (v6)
[ 4] OpenSSH (v6) ALLOW IN Anywhere (v6) To allow DNS requests just for the VPN clients, I need to specify the tun0 interface, or the subnet address range
john@ubuntu:~$ sudo ufw allow in on tun0 from any to any port 53
Rule added
Rule added (v6)To get the VPN client to use DNS server I have to update the configuration that is pushed to the client. In the file /etc/openvpn/server.conf I update the DNS address to the IP of the VPN Server running on the VPN subnet.
push "dhcp-option DNS 10.8.0.1"This will mean that the DNS requests will be sent to the VPN server, over the VPN (it’s a local subnet). After making the change I restarted the VPN Server
sudo systemctl restart openvpn@serverRunning the DNS check again and it will show the DNS server as being the VPN server address. As the request is processed at the server, it has no visibility of the upstream DNS servers.
On the TunnelBlick log I can see that the DNS server is now set to 10.8.0.1
2025-03-06 20:12:25.554444 *Tunnelblick: DNS address 10.8.0.1 is being routed through the VPNPost Script – DNS Errors
IPv6 errors
When I started the DNS server and allowed clients to connect, I started to see a whole bunch of DNS errors in the log.
ubuntu named[725]: network unreachable resolving 'dns2.udel.edu/AAAA/IN': 2607:f470:1003::ad:3#53After a bit of digging I came to the conclusion that bind was trying to reach IP6 name servers. My server doesn’t have an IPv6 address, so it wouldn’t be able to reach an IPv6 address. To stop the server from trying to use IPv6 I passed the -4 startup option in the /etc/default/named file.
The line
# startup options for the server
OPTIONS="-u bind"became
# startup options for the server
OPTIONS="-4 -u bind"DNS FORMERR Errors
After I got the DNS server up and running I was tailing the /var/log/syslog to make sure that the system was running as expected. However, I started see some FORMERR errors – but only for specific domains.
FORMERR resolving 'dnsleaktest.com/A/IN': 23.239.16.110#53I can reproduce this error using dig whenever I try to resolve that domain. Other domains are resolved without issue. In fact, that is the only domain name that I can find (so far) that generates the error. Work in progress