SSH hangs whilst on VPN

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
0
down vote

favorite












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.










share|improve this question





















  • 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 at 15:23














up vote
0
down vote

favorite












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.










share|improve this question





















  • 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 at 15:23












up vote
0
down vote

favorite









up vote
0
down vote

favorite











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.










share|improve this question













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.







networking ssh vpn






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Feb 2 at 19:21









obackhouse

1264




1264











  • 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 at 15:23
















  • 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 at 15:23















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 at 15:23




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 at 15:23










2 Answers
2






active

oldest

votes

















up vote
0
down vote













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).






share|improve this answer



























    up vote
    -2
    down vote













    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!






    share|improve this answer




















    • There is no reason to believe this is a VPN problem.
      – Thomas Ward♦
      Feb 8 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 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 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.
      – Thomas Ward♦
      Feb 8 at 15:21











    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "89"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1002453%2fssh-hangs-whilst-on-vpn%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    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).






    share|improve this answer
























      up vote
      0
      down vote













      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).






      share|improve this answer






















        up vote
        0
        down vote










        up vote
        0
        down vote









        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).






        share|improve this answer












        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).







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 8 at 15:20









        Thomas Ward♦

        42k23117167




        42k23117167






















            up vote
            -2
            down vote













            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!






            share|improve this answer




















            • There is no reason to believe this is a VPN problem.
              – Thomas Ward♦
              Feb 8 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 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 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.
              – Thomas Ward♦
              Feb 8 at 15:21















            up vote
            -2
            down vote













            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!






            share|improve this answer




















            • There is no reason to believe this is a VPN problem.
              – Thomas Ward♦
              Feb 8 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 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 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.
              – Thomas Ward♦
              Feb 8 at 15:21













            up vote
            -2
            down vote










            up vote
            -2
            down vote









            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!






            share|improve this answer












            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!







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Feb 8 at 15:09









            Noah

            21




            21











            • There is no reason to believe this is a VPN problem.
              – Thomas Ward♦
              Feb 8 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 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 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.
              – Thomas Ward♦
              Feb 8 at 15:21

















            • There is no reason to believe this is a VPN problem.
              – Thomas Ward♦
              Feb 8 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 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 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.
              – Thomas Ward♦
              Feb 8 at 15:21
















            There is no reason to believe this is a VPN problem.
            – Thomas Ward♦
            Feb 8 at 15:11




            There is no reason to believe this is a VPN problem.
            – Thomas Ward♦
            Feb 8 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 at 15:15




            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 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 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.
            – Thomas Ward♦
            Feb 8 at 15:21





            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 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.
            – Thomas Ward♦
            Feb 8 at 15:21


















             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1002453%2fssh-hangs-whilst-on-vpn%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            pylint3 and pip3 broken

            Missing snmpget and snmpwalk

            How to enroll fingerprints to Ubuntu 17.10 with VFS491