Wireguard DNS leak

diameter · June 7, 2020 at 5:30 AM

I've had nothing but trouble with wireguard. Sometimes it works and sometimes it doesn't. It's a coin toss. Sometimes rebooting brings it back. Totally frustrating buggy experience. Now, after the update to 9.2.3, no change in the spottiness of wireguard connecting. However, a serious issue has arisen which others in this community need to be aware of. The dns is leaking. I use an add-on called dnsleaktest. I run it after booting to check on the IP to ensure wireguard IP is showing and also checking for possible DNS leaks. Well, after upgrading to 9.2.3, I run dnsleaktest addon and it shows the wireguard IP, but my ISP IP for DNS. It then says, Conclusion, DNS may be leaking. Hell yes it is. Wow, that's scary. Had I not run this addon, I would have no idea of this serious DNS leak and exposing my ISP IP.

I double checked my .config file and WireGuard.DNS = 1.1.1.1

This is obviously a serious issue. It appears it's ignoring this line and using ISP IP. I urge others using wireguard to download the dnsleaktest addon and run it to check the IP and DNS IP for leaks.

The dnsleaktest addon is an official kodi addon.

Add-on:DNS Leak-Test - Official Kodi Wiki

I also hope this bug can be isolated and resolved. In the meantime, I'm no longer using wireguard with libreelec until this issue is resolved.

**chewitt** · June 7, 2020 at 10:36 AM Official Post

WireGuard support is still new and somewhat experimental and there are some systemd changes being figured out (slowly) in another forum thread to ensure more reliable connectivity. The issue of DNS leaking in known but also not something that will be simple to solve. The issue is that connman will append DNS servers specified in the wireguard config file to /etc/resolve.conf but it will not remove the existing nameserver at the same time because connman does not "manage" the DNS servers. As a result, traffic will route through the tunnel, but DNS will still resolve through the local nameserver as this is still the primary (first listed) nameserver. Resolving [sic] this probably requires a switch to using networkd (part of systemd) which is a non-trivial change for the distro to make, and isn't likely to be done anytime soon. The next-best thing is to write a handler script to remove (and cache) and then restore (from cache) the DNS servers, but there are multiple ways to change network properties while a wireguard tunnel is up, which might alter the list of nameservers, so it's one of those things that sounds simple but is programatically complex with a load of caveats on realiblity. More serious investigation on the changes needed to eliminate DNS leaking are not on my personal to-do list right now; because WireGuard works reliably for me, I don't have much time due to a busy work schedule, and the DNS leak is not important for the personal use-case that I implemented WireGuard support for. Sorry if that sounds rather "not interested" but .. I don't have the time to deal with it so the community at large will need to contribute to solving it.

1marc1 · November 16, 2024 at 12:36 PM

I found this 4+ year old thread because I am having the same issue as the OP. I made a workaround for the issue and wanted to share it here, in case others have the same problem.

I am sure there are multiple ways around the issue, but I implemented one using udev rules in two steps.

Step 1:

Create a file called 99-vpn-dns-fixer.rules in the /etc/udev/rules.d directory.
The contents of this file (a single line): ACTION=="add|remove", SUBSYSTEM=="net", KERNEL=="wg0", RUN="/storage/vpn-dns-fixer.sh"
Reload the udev rules: udevadm control --reload-rules

Step 2::

Create a file called vpn-dns-fixer.sh in the /storage directory.
Make this file executable: chmod +x vpn-dns-fixer.sh
The contents of this file are as follows:

#!/usr/bin/env sh
resolvfile=/run/connman/resolv.conf
tmpresolv=/tmp/resolv.conf
logfile=/tmp/udev.log
cp $resolvfile $tmpresolv
if [ -d "/sys/devices/virtual/net/wg0" ]; then
# wg0 exists, therefore the VPN is up
sed 's/nameserver 8.8.8.8/#nameserver 8.8.8.8/' $tmpresolv > $resolvfile
echo `/usr/bin/date` "$0 Removed 8.8.8.8 from resolv.conf" >> $logfile
else
# wg0 does not exist, therefore the VPN is down
sed 's/#nameserver 8.8.8.8/nameserver 8.8.8.8/' $tmpresolv > $resolvfile
echo `/usr/bin/date` "$0 Added 8.8.8.8 to resolv.conf" >> $logfile
fi

Explanation::

In my case, when I am not connected to the VPN, I am using 8.8.8.8 as my DNS server. When I connect to the VPN, 8.8.8.8 remains as the first listed DNS server in the resolv.conf file and the actual DNS server specified by the WireGuard configuration gets listed as the second DNS server. This means that DNS server is effectively not used.

The 99-vpn-dns-fixer.rules triggers the execution of the /storage/vpn-dns-fixer.sh script whenever udev reports that a network device called wg0 is either added to the system or removed from the system.

When the script runs, it checks for the presence of the /sys/devices/virtual/net/wg0 directory. If it exists, the VPN must have just come online and the script will then update the resolv.conf file by commenting out the line for my "non-VPN" DNS server.

When the script runs and does not find the wg0 directory, it concludes that I just disconnected from the VPN and will then remove the comment for the "non-VPN" DNS server.

I hope this helps someone.

**chewitt** · March 26, 2025 at 2:30 AM

Pinging this thread to raise awareness of new WireGuard capabilities that need testing:

Thread

WireGuard - Experimental support for connecting via FQDN not IP

Regular ConnMan contributor and SailfishOS maintainer Jussi Laakonen has been working on improvements to WireGuard support in ConnMan. Specifically, the ability to define 'Host' (the remote WireGuard server) as a hostname/FQDN instead of an IP address. This eases long-term WireGuard use with servers self-hosted from dynamic IP address ranges, and commercial WireGuard services where each node has multiple IP addresses in DNS that are rotated reguarly to avoid IP blocking. The changes should also…

chewitt

March 25, 2025 at 12:59 PM