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.

  • Can you be more specific on the exact SSH error? Have you tried SSHing to the IP directly to see if that's the problem?
    – Thomas Ward
    Feb 8, 2018 at 15:23

2 Answers 2


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 ( and, 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 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 dev lo
    down ip -4 addr del 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 {; };

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!

  • There is no reason to believe this is a VPN problem.
    – Thomas Ward
    Feb 8, 2018 at 15:11
  • I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
    – Noah
    Feb 8, 2018 at 15:15
  • it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and uses ping 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.
    – Thomas Ward
    Feb 8, 2018 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.