openconnect is connected but does not use the right dns

sudo openconnect --protocol=nc [corporate vpn url]
GET [corporate vpn url]
Connected to [corporate vpn ip]:443
SSL negotiation with [corporate vpn url]
Connected to HTTPS on [corporate vpn url]
Got HTTP response: HTTP/1.1 302 Found
GET [corporate vpn url]/auth/url_13/welcome.cgi
SSL negotiation with [corporate vpn url]
Connected to HTTPS on [corporate vpn url]
frmLogin
username: [a username]
password: [a password]
POST [corporate vpn url]/auth/url_13/login.cgi
Got HTTP response: HTTP/1.1 302 Moved
GET [corporate vpn url]/home/starter0.cgi?check=yes
Connected as [new ip address], using SSL, with ESP in progress
ESP session established with server

It seems to be fine in the sense that torguard shows a different IP address and country before and after the openconnect is connected.

However it seems I cannot access to the corporate websites, when I try with say Chrome, I end up with:

Server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

Like if the dns wasn't fetched or something like.

It's weird though cause when I am doing this from a live cd, that is without any prior connection to any network, it works just fine...

I am wondering how the DNS is fetched.

[EDIT]

I am right now using Linux Mint live to see what is the DNS in use or is there anything special setup:

For the Wireless connection:

mint@mint:~$ nmcli device show wlp1s0
GENERAL.DEVICE: wlp1s0
GENERAL.TYPE: wifi
GENERAL.HWADDR: E0:94:67:32:46:AF
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: [our wireless hotspot at home]
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
IP4.ADDRESS[1]: 192.168.1.104/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 600
IP4.ROUTE[2]: dst = [what an ip address?!], nh = 0.0.0.0, mt = 600
IP4.ROUTE[3]: dst = [yet another one!], nh = 0.0.0.0, mt = 1000
IP4.ROUTE[4]: dst = [an address, geez], nh = 192.168.1.1, mt = 0
IP4.DNS[1]: 192.168.1.1
IP4.DOMAIN[1]: home
IP6.ADDRESS[1]: [ipv 6 craziness]
IP6.ADDRESS[2]: [woooa]
IP6.ADDRESS[3]: [asdasdad]
IP6.GATEWAY: [&*^$]
IP6.ROUTE[1]: dst = [incredible]::/64, nh = ::, mt = 600
IP6.ROUTE[2]: dst = ::/0, nh = [beyond understanding], mt = 600
IP6.ROUTE[3]: dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE[4]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[5]: dst = fe80::/64, nh = ::, mt = 600
IP6.DNS[1]: [fantastic!]

And the VPN created interface:

mint@mint:~$ nmcli device show tun0
GENERAL.DEVICE: tun0
GENERAL.TYPE: tun
GENERAL.HWADDR: (unknown)
GENERAL.MTU: 1400
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: tun0
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/2
IP4.ADDRESS[1]: [magic ip]
IP4.GATEWAY: 0.0.0.0
IP4.ROUTE[1]: dst = [magic ip], nh = 0.0.0.0, mt = 0
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 0.0.0.0, mt = 0
IP6.ADDRESS[1]: [magic ip again]
IP6.GATEWAY: --
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256

Interestingly enough, it seems that the etc/resolv.conf has been changed when I connected to the vpn:

#@VPNC_GENERATED@ -- this file is generated by vpnc
# and will be overwritten by vpnc
# as long as the above mark is intact
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
options edns0
nameserver [some address 1]
nameserver [some address 2]
search home [loads of corporate related names]

... and when I disconnect from the VPN:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0
search home

3 Answers

I found something that works from an answer on the Manjaro Forum: Weird DNS issue over VPN

So basically what did I do:

• sudo systemctl stop systemd-resolved
• sudo systemctl disable systemd-resolved
• Remove symlink between /etc/resolv.conf and /run/systemd/resolve/resolv.conf
• Comment out the line with hosts: ... in /etc/nsswitch.conf
• Reboot

Tbh, it's still a bit voodoo to me about why it works.

The hypothetical underlying reason about why this works from the author is pasted below:

My understanding is that commenting out the line with hosts in /etc/nsswitch.conf allows sudo openconnect to work without systemd-resolved. Indeed, openconnect relies on /etc/vpnc/vpnc-script to detect which type of DNS resolver is used and if it finds a row containing the word "resolve" in /etc/nsswitch.conf, it thinks systemd-resolved is being used even if it is disabled.

This is why I got an error when using sudo openconnect with systemd-resolved disabled. And this is also why I did enable this service afterwards. However it seems this caused some errors and even if the symlink technique did work, I was still having some issues with DNS leaks. Well, simply commenting this line in /etc/nsswitch.conf is what is recommended in the above link and it indeed works. Now, although systemd-resolved is being disabled (the default in Manjaro apparently), sudo openconnect does't complain anymore about it and works properly.

I don't know whether vpnc-script is at fault here: it should not detect systemd-resolved as the DNS resolver being used based on that row in nsswitch.conf. It should check if systemd-reolved is enabled IMHO.

I had this issue. I was due to a known bug. This workaround worked for me:

add this to /etc/network/if-up.d/globalprotect:

#!/bin/sh
# Hacky workaround bug in NM not setting the default routes.
if [ "$IFACE" = "vpn0" ]; then ip route replace default via 0.0.0.0 dev vpn0
fi

Try to flush dns.

• Launch Terminal by pressing Ctrl+Alt+T.

• Type the following command, then press Enter:

  sudo /etc/init.d/dns-clean restart

• Now, type

  sudo /etc/init.d/networking force-reload 

• Press Enter.