[Bug 792] mtu and NAT wrong solution

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=792

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From dtucker at zip.com.au  2004-01-22 11:08 -------
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).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.