Bug 792

Summary:	mtu and NAT wrong solution
Product:	Portable OpenSSH	Reporter:	Enrique Arizon Benito <e_arizon_benito>
Component:	Miscellaneous	Assignee:	OpenSSH Bugzilla mailing list <openssh-bugs>
Status:	CLOSED INVALID
Severity:	major
Priority:	P4
Version:	-current
Hardware:	All
OS:	Linux

Description Enrique Arizon Benito 2004-01-22 07:10:54 AEDT

It's well known that ssh tunneling have problems crossing an IP masquerading
gateway and solutions point to reduce the interface MTU. But reducing the
interface MTU makes many other applications not to work or to run extremly
slowly. For example Windows clients behind the NAT can't connect to terminal
servers when I reduce it. 
So I think it must be considered a bug or a "requested feature" to let ssh
choose the length of its own data packets.

Due to this problem I can't properly use ssh for tunneling VNC or SMB shares or
even cvs (with -Z option activated).


P.S.:
 All the test I have made are based on ADSL 256/128 and RDSI connections.

 Also notice that all the VPN solutions I have tested provide for some method to
control packet length to avoid problems .( CIPE, POPTOP, OpenVPN) so maybe is
just a matter of "copy and paste" some free available code.

Comment 1 Damien Miller 2004-01-22 07:40:41 AEDT

MTU is not relevant to port forwarding, as it happens at the application layer.
Is that what you are referring to?

Comment 2 Enrique Arizon Benito 2004-01-22 08:20:10 AEDT

Well, the problem affect ssh in general when traversing a NAT (IP masquerading)
firewall. But since sshd is usually located in the gateway-NAT and used as Tunel
terminator the problem get mainly noticed when tunneling (port forwarding) some
other protocol (VNC, SMB, ...).

More info available on this issue in:
 http://www.snailbook.com/faq/mtu-mismatch.auto.html

Comment 3 Darren Tucker 2004-01-22 11:08:10 AEDT

Actually, the problem can affect any application, it's just that ssh's traffic
patterns hit the problem more often than most.

TCP has an elegant solution to the problem called "Path MTU Discovery" (which
the FAQ mentions it but does not detail): the stack sets the DF bit on the
outgoing TCP segments and relies on ICMP "fragmentation neeeded" messages being
sent back if the size exceeds the MTU on the way.  The problem is many firewalls
and NAT devices drop those ICMP packets.  Try turing it on if your hosts support it.

OpenSSH works with TCP.  IP Packet sizes and interface MTUs are not its problem.
 The MTU fix in the FAQ is a really a work-around for broken networks.  If you
aren't happy with the performance, fix your network.  Otherwise live with it.

BTW:
* if you have apps that don't work with lower MTUs either the app or the IP
stack is broken.  Note that you'll have to reduce the MTU on *all* of the
machines behind your NAT box.

* The other products you mention are all packet-based VPNS.  OpenSSH isn't.
(OpenVPN and CIPE use UDP for data packets, PoPToP uses IP directly).

* If you're using ADSL you're probably using PPPoE.  If that's the case, you
only need to reduce the MTU to 1492 (assuming you're using classic ethernet
encapsulation, if you're using 802.3 then subtract another 8 bytes).

Comment 4 Damien Miller 2004-04-14 12:24:20 AEST

Mass change of RESOLVED bugs to CLOSED