can't get rid of DNS leaks on Linux

[rlmkt 0]

I somehow can't get rid of DNS leaks on Linux. I'm checking for them on www.dnsleaktest.com and sometimes it's fine, but then other times my ISP's DNS is leaking.

 

I'm using OpenVPN and the AirVPN UDP-443.ovpn file. I've googled this issue and some people said to install "resolvconf" and add these lines to the .ovpn file:

 

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

 

I did this, but the DNS still leaks. What do I do?

[zhang888 1066]

What do I do?

 

You post your logs to being with.

[Staff 9973]

There are no DNS leaks on Linux.

[rlmkt 0]

@zhang888: I'm quite new to Linux and VPNs, so I don't know where I would find logs about this. I'm on Debian and using OpenVPN.

 

@Staff: Bit confused by this response. I just said in my opening post that I am experiencing DNS leaks on Linux. I'm sure it's a problem on my end, that's why I'm asking here what I could do about it. I hope that "your problem actually doesn't exist" is not the only kind of answer I can expect from the staff of the official AirVPN support forums?

[zhang888 1066]

The logs are either on the terminal you started OpenVPN in or in /var/log/syslog, or /var/log/openvpn.log.

This also depends if you run OpenVPN from terminal or with Network Manager.

 

The fact that there are no DNS leaks on Linux is quite true, unless OpenVPN fails to overwrite your resolv file.

The term leak is reserved to a specific behavior on Windows, which sends DNS queries across all interfaces,

in your case it is probably a misconfiguration of some kind. But that's just terminology. 

[rlmkt 0]

I run OpenVPN from the network manager, not from the terminal. I've found this in syslog after connecting to a AirVPN Netherlands server, this might be the relevant part:

 

 

NetworkManager[1007]: <info> VPN connection 'AirVPN_Netherlands_UDP-443' (IP Config Get) reply received.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> VPN connection 'AirVPN_Netherlands_UDP-443' (IP4 Config Get) reply received.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> VPN Gateway: 213.152.161.137
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Tunnel Device: tun0
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> IPv4 configuration:
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   Internal Gateway: 10.4.0.1
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   Internal Address: 10.4.72.209
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   Internal Prefix: 16
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   Internal Point-to-Point Address: 0.0.0.0
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   Maximum Segment Size (MSS): 0
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   Forbid Default Route: no
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   Internal DNS: 10.4.0.1
Dec 15 16:43:03 xpc NetworkManager[1007]: <info>   DNS Domain: '(none)'
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> No IPv6 configuration
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): link connected
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> VPN connection 'AirVPN_Netherlands_UDP-443' (IP Config Get) complete.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> VPN plugin state changed: started (4)
Dec 15 16:43:03 xpc nm-openvpn[4618]: Initialization Sequence Completed
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> NetworkManager state is now CONNECTED_LOCAL
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> NetworkManager state is now CONNECTED_GLOBAL
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Writing DNS information to /sbin/resolvconf
Dec 15 16:43:03 xpc nm-dispatcher: Dispatching action 'vpn-up' for tun0
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) starting connection 'tun0'
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Dec 15 16:43:03 xpc NetworkManager[1007]: <info> Activation (tun0) successful, device activated.

 

I should also mention that I only see my ISP DNS on www.dnsleaktest.com about every third or fourth time I run the extended test, not each time.

[zhang888 1066]

What is the content of your /etc/resolv.conf file after you are connected?

[rlmkt 0]

What is the content of your /etc/resolv.conf file after you are connected?

 

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 10.4.0.1

nameserver 192.168.0.1

search sitecomwl351

[zhang888 1066]

The default behavior for resolv.conf and the resolver is to try the servers in the order listed.

The resolver will only try the next nameserver if the first nameserver times out. The resolv.conf manpage says:

 

Name server IP address

 

Internet address (in dot notation) of a name server that the resolver should query.

Up to MAXNS (currently 3, see ) name servers may be listed, one per keyword.

If there are multiple servers, the resolver library queries them in the order listed.

 

 

The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers,

then repeat trying all the name servers until a maximum number of retries are made.

 

This is what happens in your case for some reason.

Try removing the 192.168.0.1 server from the Network Manager and this should be solved.

 

Again, terminology-wise, this is not a leak, this is how resolvonf works and it's well documented.

Same as if your tun0 will fail and traffic will be sent over your main eth0 cannot be called a leak.

[Staff 9973]

@Staff: Bit confused by this response. I just said in my opening post that I am experiencing DNS leaks on Linux.

 

That's impossible. Even if you insert a third-party nameserver in the resolv.conf file, the DNS query will be tunneled. If the local router is also a DNS server and forwards DNS queries in the clear, then again this is not a DNS leak by Linux (Linux has just sent some traffic inside the local network, traffic which is, must be and is compelled to stay outside the tunnel).

 

A DNS leak occurs when a DNS query to some DNS server on the Internet is NOT tunneled in spite of the routing table. This can't happen on Linux, unless explicitly configured to do so.

 

However, DNS leaks can happen in Windows, because there is no DNS implementation there (there is something that emulates a DNS implementation in some circumstance but in reality it's something very different, and very alien).

 

I'm sure it's a problem on my end, that's why I'm asking here what I could do about it. I hope that "your problem actually doesn't exist" is not the only kind of answer I can expect from the staff of the official AirVPN support forums?

 

We can't support you to solve a problem that does not exist.. If you open a ticket you'll get full support, but of course on the problem that you really have, not on the problem that you think you have.

 

Don't worry, the support tickets are handled without this joking spirit.

 

Kind regards

[rlmkt 0]

 

 

The default behavior for resolv.conf and the resolver is to try the servers in the order listed.

The resolver will only try the next nameserver if the first nameserver times out. The resolv.conf manpage says:

 

 

Name server IP address

 

Internet address (in dot notation) of a name server that the resolver should query.

Up to MAXNS (currently 3, see ) name servers may be listed, one per keyword.

If there are multiple servers, the resolver library queries them in the order listed.

 

 

The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers,

then repeat trying all the name servers until a maximum number of retries are made.

This is what happens in your case for some reason.

Try removing the 192.168.0.1 server from the Network Manager and this should be solved.

 

Again, terminology-wise, this is not a leak, this is how resolvonf works and it's well documented.

Same as if your tun0 will fail and traffic will be sent over your main eth0 cannot be called a leak.

 

 

 

 

 

 

Was looking around a bit in the network manager (there's actually not too much there), and I can't find a way to remove this. I can go into the settings for Wifi and the entries for each of my .ovpn files, but there is no option to remove 192.168.0.1 anywhere. In the VPN settings, there's a "DNS" entry under "IPv4", which is set to automatic. I can manually enter a DNS server below. Entering 10.4.0.1 does not help, turning off automatic does not help either.

 

Is there perhaps anything I could enter in Terminal to remove this entry from resolv.conf?

 

Edit: screenshot of the VPN IPv4 settings menu: https://s28.postimg.org/amu62cey5/Screenshot.png

 

Tried manually entering 10.4.0.1, switching automatic off under DNS, but I still see my ISP on dnsleaktest.

[zhang888 1066]

The problem with Network Manager is that it auto-generates the .ovpn config files and ignores some options.

How does the config looks like? Normally it is in /etc/NetworkManager/system-connections/

[rlmkt 0]

Again for the Netherlands one:

 

 

[vpn]
service-type=org.freedesktop.NetworkManager.openvpn
ta-dir=1
connection-type=tls
remote=nl.vpn.airdns.org
cipher=AES-256-CBC
comp-lzo=yes
cert-pass-flags=0
port=443
remote-cert-tls=server
cert=/home/j/Documents/AirVPN/linux/user.crt
ca=/home/j/Documents/AirVPN/linux/ca.crt
key=/home/j/Documents/AirVPN/linux/user.key
ta=/home/j/Documents/AirVPN/linux/ta.key
dev=tun

[ipv6]
method=auto

[ipv4]
method=auto

[zhang888 1066]

This means that the Network Manager omitted the up and down directives of resolvconf scripts.

You can add them there and then chances are that it will respect them and pass to openvpn correctly.

However some weird distributions, Mints from various kinds, broke even that functionality. 

[rlmkt 0]

You mean, enter the 3 lines from my initial post to this file? I tried that, like this:

 

 

[vpn]
service-type=org.freedesktop.NetworkManager.openvpn
ta-dir=1
connection-type=tls
remote=nl.vpn.airdns.org
cipher=AES-256-CBC
comp-lzo=yes
cert-pass-flags=0
port=443
remote-cert-tls=server
cert=/home/j/Documents/AirVPN/linux/user.crt
ca=/home/j/Documents/AirVPN/linux/ca.crt
key=/home/j/Documents/AirVPN/linux/user.key
ta=/home/j/Documents/AirVPN/linux/ta.key
dev=tun
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

[ipv6]
method=auto

[ipv4]
method=auto

 

Didn't change anything in resolv.conf though.

 

EDIT: I just manually changed the resolv.conf file and removed the 192.168 line. Don't see my ISP DNS anymore now on dnsleaktest. However, I'm sure this file will be automatically changed back again? Is there any way to avoid this?

[zhang888 1066]

networkmanager-openvpn functionality is still severely broken when it comes to advanced configs.

Add it to /etc/network/if-up.d/openvpn then, it should have the same effect but bypass the NM lack of support.

 

Debian with openvpn should have this:

 

#!/bin/sh

OPENVPN=/usr/sbin/openvpn
OPENVPN_INIT=/etc/init.d/openvpn
SYSTEMCTL=/bin/systemctl
SYSTEMD=/run/systemd/system

if [ ! -x $OPENVPN ]; then
  exit 0
fi

if [ -n "$IF_OPENVPN" ]; then
  for vpn in $IF_OPENVPN; do
    ## check systemd present
    if [ -d $SYSTEMD ]; then
      $SYSTEMCTL --no-block start openvpn@$vpn
    else
      $OPENVPN_INIT start $vpn
    fi
  done
fi

 

 

Add "/etc/openvpn/update-resolv-conf" to the end of it, like this:

 

 

#!/bin/sh

OPENVPN=/usr/sbin/openvpn
OPENVPN_INIT=/etc/init.d/openvpn
SYSTEMCTL=/bin/systemctl
SYSTEMD=/run/systemd/system

if [ ! -x $OPENVPN ]; then
  exit 0
fi

if [ -n "$IF_OPENVPN" ]; then
  for vpn in $IF_OPENVPN; do
    ## check systemd present
    if [ -d $SYSTEMD ]; then
      $SYSTEMCTL --no-block start openvpn@$vpn
    else
      $OPENVPN_INIT start $vpn
    fi
  done
fi

/etc/openvpn/update-resolv-conf

 

 

[rlmkt 0]

I did this, but it still keeps readding the 192.168 line to resolv.conf every time I reconnect to a VPN server. I guess I could just always manually remove that line, it's just really annoying and doesn't seem safe at all when I want to rely on my PC using AirVPN's DNS. Seems weird to me that it's so seemingly impossible to make Debian use the correct DNS. If you have any other ideas, I'll gladly try.

[zhang888 1066]

Running the official Eddie client for Linux will be the shortest way to solve this

[cm0s 118]

i set my local to static and went with an open source router