VPN MTU limit breaks ssh connection to openssh 6.2p2 server

[Darren Tucker]

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.