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.
MTU is not relevant to port forwarding, as it happens at the application layer. Is that what you are referring to?
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
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).
Mass change of RESOLVED bugs to CLOSED