1

I wish to access a server, say x.x.x.x which is in a VPN. The VPN's gateway is y.y.y.y. I'm using openconnect VPN client to connect to the gateway y.y.y.y, and I'm successfully able to connect using my VPN credentials.

Pinging and running traceroute to x.x.x.x after connecting to the VPN are also successful. Strangely, when I'm trying to connect to x.x.x.x using ssh with my username, the ssh command hangs and does not prompt for password. I used the following command to connect:

ssh username@x.x.x.x

I'm using Ubuntu 16.04 with VPN client openconnect.


Update-1

I'm able to connect to that server using puTTY for Ubuntu, so this means that the server is accepting inbound ssh connections. But what still beats me is that ssh at the command line is still unable to connect to the server. I ran netcat x.x.x.x 22 after connecting to VPN, the response was: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4.

I badly want to connect using ssh in command line because I need X11 forwarding, and I can do it using -X flag in ssh.

Also, I'm unable to use X11 forwarding using puTTY in Ubuntu (it is easy in windows thanks to Xming).


Update-2

ssh threw an error saying -d is an unknown option. I tried -v (verbose) flag with ssh. The following is the output:

OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/varshaneya/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to x.x.x.x:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

And hangs after that...

1
  • Anything pertinent from ssh -d user@x.x.x.x?
    – roaima
    Jun 11, 2018 at 9:52

2 Answers 2

2

I found answer for my question was answered here in superuser site. Thank you @jagguli for the solution.

Basically I had to reduce the MTU size of the ethernet connection and that did the trick. Check this out.

2
  • I would have never guessed it could be something about MTU. Cheers! Jun 11, 2018 at 10:33
  • There is a mechanism called "Path MTU Discovery" (or PMTUD for short) that should detect and solve MTU issues like that automatically. It has been in operating systems since Windows 95 at least... but it can be broken if a firewall or a VPN is not allowing ICMP "fragmentation needed" packets to pass through. As VPNs and cloud services become more common, PMTUD becomes even more important. Please make sure your firewall set-ups don't just blindly block all ICMP.
    – telcoM
    Jun 11, 2018 at 10:42
0

I came on this site because of a similar problem. When connected to my home network over vpn I was not able to connect to my Ubuntu VM over ssh. The simple answer to my problem was that my router creates a VLAN for VPN users. Im blocking inter VLAN traffic of course but this was not the first thing came into my mind. Took a while to figure that out. But creating a simple firewall rule to allow VPN connections to connect to my VM solved the problem. On Unifi products its a LAN out rule. Maybe this helps others as well.

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.