2

I have a Netscreen vpnc VPN tunnel set up which I connect from different Linux boxes (Ubuntu, Lubuntu, Antergos), and all of them show the same behaviour.

When I use a USB modem attached to the computer to connect to the Internet, I can connect the VPN tunnel and use any service - HTTP, HTTPS, Ping, SSH - then as expected.

If, however, I connect to the Internet via WiFi hotspot (and I already tested with several different ones, from home, office and some free public WiFi), only HTTP, HTTPS and PING seems to work, whilst SSH stucks in the middle of the initial negotiation:

$ ssh -v root@123.45.67.89
OpenSSH_6.7p1 Ubuntu-5ubuntu1.4, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 123.45.67.89 port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
[ ... cut ... ]
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug1: kex: client->server aes128-ctr umac-64@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

and after some time:

Connection closed by 123.45.67.89

Route is setup the same way as with USB modem attached, and iptables are empty. How come that it does not work, and what to I have to do to get it work?

Improve this question
3
  • 2
    Seems like MTU problem. Try to lower MTU on the VPN network interface.
    – Jakuje
    Dec 8, 2016 at 21:49
  • @Jakuje, how did you figure out about the MTU issue based on the ssh log provided?
    – fduff
    Dec 9, 2016 at 8:24
  • 1
    @fduff, an indication that MTU is worth investigating here is that the TCP connection is established, and the initial packets of small size exchange, but the first packet requiring fragmentation fails. I have seen this behaviour with both SSH and https connections over links where path MTU cannot be properly determined.
    – user4556274
    Dec 11, 2016 at 18:02

1 Answer 1

Reset to default
4

The Maximum Transmission Unit (MTU) size should ideally be the same on hotspot and client, but the client's has to be at most the size of the hotspot's.

Lower the MTU size of the client's tunnel device, for example:

$ ip addr show dev tun0
6: tun0: <POINTTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc pfifo_fast state UNKNOWN group default qlen 500

So, the MTU size is 1412 bytes here. Lowering a bit:

$ ip link set tun0 mtu 1000

and voilà, ssh works, too.

Trying to make this change persistent must be done individually.

This problem is outlined in Wikipedia:

The difference between the MTU seen by end-nodes (e.g. 1500) and the Path MTU causes Path MTU Discovery to come into effect, with the possible result of making some sites behind badly configured firewalls unreachable.

Thanks to @Jakuje for pointing this out.

Improve this answer

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.