Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.
Sign up to join this community
I connect to a University shared computer facility by connecting to the University VPN and using SSH to log in. This is fine on my Windows installation using Cygwin. However, on my Ubuntu installation the SSH hangs.
Originally the VPN was not getting any internet access whatsoever, but I fixed this by removing dns=dnsmasq from /etc/NetworkManager/NetworkManager.conf, but this did not fix the SSH error.
Also prior warning that I'm new to Ubuntu.
This sounds like a problem with DNS, and more specifically DNS when using dnsmasq with a VPN. There is a known issue when using dnsmasq and NetworkManager with a VPN which will break DNS resolution within dnsmasq. Upstream has acknowledged but also done nothing towards fixing it. This has been an issue since 16.04, and doesn't seem to be on their radar to fix any time soon. My guess is that they have no idea where it's actually breaking. (LP Bug #1588018, among many other bugs on the same problem)
The solution is to not use dnsmasq at all, and instead use a different DNS system or set of DNS servers by default, usually by forcibly overriding the resolvconf service settings.
However, this is a major, nontrivial change, and can cause other problems. Therefore, there's no real workaround currently to this issue.
WARNING: This is my workaround to this problem, and is a non-standard, nontrivial solution to the DNS issue. Use only at your own risk.
My workaround was a painful, non-trivial one. I installed and configured bind9 to be a forwarding DNS resolver, so that it forwards all DNS queries off to Google DNS (8.8.8.8 and 8.8.4.4), and then once that was working I went and edited my /etc/resolvconf/resolv.conf.d/head file to query the local DNS. Note that I had to add a local DNS binding for 127.0.2.1 and in order for that to work I have to roll custom IP ranges in my lo adapter by adding these lines to my /etc/network/interfaces file (I included the default lo auto/loopback declarations for context):
auto lo
iface lo inet loopback
up ip -4 addr add 127.0.2.1/8 dev lo
down ip -4 addr del 127.0.2.1/8 dev lo
... and by setting bind9 in the /etc/bind/named.conf.options folder so that this is now in the options configuration block:
listen-on { 127.0.2.1; };
Once I rebooted the system after making those changes, the system began defaulting to using my local bind9 resolver.
However, this prevents VPNs which have Intranets and internal DNS resolutions and internal domains from properly resolving; this introduced other issues, but nothing I couldn't work around (as a power user and system administrator).
To provide a meaningful answer, we'll need some more information. I'm assuming the VPN is a Cisco Openconnect VPN. Is that right? Without any more information, I'm guessing that your problem is in the setup of the VPN.
If so, there is a proprietary client from Cisco that works very well, but it's not necessary. Your university should provide a link to download and directions to install that client.
If you prefer open source solutions, there is a program called openconnect. Directions for its use are here.
Try 1 of these options. If you don't care about open source, honestly the Cisco client will work most easily. If you do care, then try openconnect.
Best of luck!
ping 8.8.8.8 or uses ssh ip.add.re.ss instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager and dnsmasq components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN and vpnc traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.