http://bugzilla.mindrot.org/show_bug.cgi?id=792
Summary: mtu and NAT wrong solution
Product: Portable OpenSSH
Version: -current
Platform: All
OS/Version: Linux
Status: NEW
Severity: major
Priority: P4
Component: Miscellaneous
AssignedTo: openssh-bugs at mindrot.org
ReportedBy: e_arizon_benito at yahoo.com
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=792 ------- Additional Comments From djm at mindrot.org 2004-01-22 07:40 ------- MTU is not relevant to port forwarding, as it happens at the application layer. Is that what you are referring to? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=792 ------- Additional Comments From e_arizon_benito at yahoo.com 2004-01-22 08:20 ------- 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 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
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.