VPN MTU limit breaks ssh connection to openssh 6.2p2 server

[Ernst Kratschmer]

Hi everybody, 

thank you very much for your quick reply. 

Let me first address Damien's comment. Following some other people's 
"trial and errors" around the internet, I have already started to look for 
ways to limit the "cipher string", but did not have any success. So far, I 
tried using a config file in ~/.ssh/ which specified just a few Ciphers 
and MACs. My debug showed that it did not change the packet length, still 
1460. Next I took a look at /etc/ssh/sshd_config and noticed that it did 
not explicitly specify any Ciphers or MACs, but ssh_config did. I then 
copied the few Ciphers and MACs from ssh_config to sshd_config and 
restarted sshd. Again, my debug showed that it did not change the packet 
length, still 1460. Most likely, I am doing something wrong here, but in 
any case I would greatly appreciate it if you could provide me with 
instructions how to shorten the "cipher string" length by modifying the 
config files. 

If I understand Darren correctly, he is concerned that the packet 
fragmentation causes fragments to get dropped. From my debug, I can see 
that the 1460 byte packet get split into two packets exactly as expected 
from the MTU limit. And both packets get sent to the client. The client 
then resets the communication. This happens regardless of the type of 
client software used, Cygwin, putty, openssh any version, etc. Therefore, 
I wonder if Flavien's comment is correct, or, if somehow all ssh clients 
expect to reveice the "cipher string" in a single packet. I admit that 
this is a wild speculation from someone who hasn't examined the source 
code. I just find it remarkable, that all ssh clients I tried show the 
same behavior in this case. I hope you know the answer. 


-Ernst




From:
Darren Tucker <dtucker at zip.com.au>
To:
Damien Miller <djm at mindrot.org>, Ernst Kratschmer/Watson/IBM at IBMUS, 
openssh-unix-dev at mindrot.org, 
Date:
11/08/2013 06:49 AM
Subject:
Re: VPN MTU limit breaks ssh connection to openssh 6.2p2 server



On Fri, Nov 08, 2013 at 11:52:11AM +0100, Flavien Lebarbe wrote:
> > On Thu, 7 Nov 2013, Ernst Kratschmer wrote:
[vpn + mtu problem]
> Damien answered :
> > I don't think this is something we can fix in OpenSSH.
> 
> I don't get it. Could you elaborate on this ?
> 
> Please correct me if I'm wrong, but from my point of view, TCP
> splitting packets to respect MTU somewhere in transit should not have
> any impact at the functionnal level. We should not expect the values
> returned by read()/recv() to match those we gave to write()/send().

it doesn't.  it does expect that they make it to the other end, though,
which doesn't seem to happen in this case.

> When read()-ing on a socket, the size returned is at the kernel (or
> libc) discretion. If it prefers to send us the data byte by byte, it
> is allowed to, and the process is supposed to wait for more data if
> it expects more.
> 
> I'm not telling it's easy to implement in OpenSSH as I never seriously
> looked at the code but saying it cannot be done surprises me.

TCP is supposed to be a bi-directional reliable byte stream and the ssh
protocol doesn't rely on it being anything more than that.

The network in this case seems broken.  It sounds like the classic "MTU
causes IP fragmentation then something else drops the fragments" problem.
Often something doing this will also reduce the TCP MSS so that the
endpoints don't emit IP packets big enough to fragment, but it seems
not in this case.

It can be worked around in the config as described by Damien but any
attempt to work around it in openssh would be an ugly hack at best and
would likely hurt performace on networks that aren't broken.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.