openconnect is connected but does not use the right dns
Solution 1
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
allowssudo openconnect
to work withoutsystemd-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 thinkssystemd-resolved
is being used even if it is disabled.This is why I got an error when using
sudo openconnect
withsystemd-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 detectsystemd-resolved
as the DNS resolver being used based on that row innsswitch.conf
. It should check ifsystemd-reolved
is enabled IMHO.
Solution 2
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
Related videos on Youtube
Goof'Nat'
Updated on September 18, 2022Comments
-
Goof'Nat' over 1 year
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
-
Thomas Ward over 4 yearsHow is your OpenConnect configured? Does your remote OpenConnect server at your company set DNS for OpenConnect connections? If not, then this is a configuraiton issue at their end.
-
Goof'Nat' over 4 yearsI don't know how it is configured, just like "out of Ubuntu install configured" (or lack of thereof).
-
Goof'Nat' over 4 years@ThomasWard I think it has more to do with something on my side. See right now I am using another laptop with a live usb of linux mint use openconnect and everything works like a charm... (with the same command as I used in my post)
-
-
Thomas Ward over 4 yearsNote that these commands may not work properly on newer systems, where Netplan or
systemd-resolved
are powering the networking and resolvers. Just a thought. -
Goof'Nat' over 2 yearsNice, thanks for the addition!