openssh unix dev - Jun 2002 - [Bug 277] X11 forwarding problem behind Router/NAT box

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





------- Additional Comments From stevesk at pobox.com  2002-06-15 14:19 -------
i don't know what this is:

debug1: Credentials Expired                                                     
debug1: proxy expired: run grid-proxy-init or wgpi first                        
        File=/tmp/x509up_u500                                                   
  Function:proxy_init_cred

i don't have any guesses now.  would like to see sshd -ddd
on solaris for the fail case.



------- 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=277





------- Additional Comments From dtucker at zip.com.au  2002-06-15 20:07 -------
Here's an edited version from a previous (emailed) answer to this:
 
Short answer:
You probably have an MTU/fragmentation problem. For each network interface on 
both client and server set the MTU to 576, eg "ifconfig ethX mtu 576".
If the
problem goes away, read on.

Long answer:
At each routing hop, IP packets bigger than the outgoing interface's MTU get
fragmented. Only the first fragment has TCP port numbers. Firewalls usually drop
everything but the first fragment since it can't be matched against the 
rulebase. Some NAT configuration (eg many-to-one NAT or port address 
translation) can't match the fragments against their translation state
tables.

Logging in and using the shell will normally generate relatively small packets, 
however if you something that generates a lot of data (eg cat'ing a big file
or
starting an X app, you may generate a packet bigger than the MTU.

Let's say it's a 1500 byte IP packet and the router has 2 different MTUs
(say
1500 & 1484) and no firewall. When the router goes to forward it, the packet
is
too big for the interface MTU (1484), so the router breaks it into 2 fragments, 
0 and 1. Fragment 0 contains the first 1484 bytes (including the TCP source and 
dest ports) and fragment 1 contains the remaining 16 bytes. Both fragments are 
sent on to their destinations.

When the first fragment reaches its target, it's held by the IP stack until
the
remaining fragments arrive, at which time the IP packet is reassembled and 
passed up the stack to TCP. If all fragments are not received by the timeout, 
the entire IP packet is discarded and an ICMP "timeout during
reassembly" error
is sent back.

Now add your firewall, which drops fragment 1. Your 1500 byte IP packet times 
out during reassembly and TCP retries, by sending another 1500 byte packet. 
Repeat. Eventually, TCP will time out and you'll get a connection
termination.

IP stack parameters (such as Path MTU Discovery) and external variable (such as 
the MTUs of all the hops between hosts) can also affect whether or not a given 
connection will be affected.

Maybe I ought to submit this to the FAQ maintainer....



------- 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=277

ballen at uwm.edu changed:

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



------- Additional Comments From ballen at uwm.edu  2002-06-15 23:47 -------
Darren -- you were correct -- it was fragmented packets not getting forwarded
by the NAT box.   I am closing out the bug report.  Details follow.

Thanks you!

The following command on the Solaris box:
  ifconfig hme0 mtu 576
solved the problem.  Unfortunately this Solaris box has some NFS mounted
partitions.  These small MTU values really clobber NFS performance so I'll
probably need to reset the mtu value each time I want to to X11 forwarding.
Sigh.

I'll experiment to find the largest acceptable MTU value.
I don't know where the packets are getting fragmented -- probably by my DSL
provider.  And I agree that you should add this to the FAQ -- I read the FAQ
closely before posting my bug report so if I had seen your posting in the FAQ
it would have saved everyone's time and bandwidth!

Thanks again!  I still can't believe how well the open-source model works
when the developers are committed to their products.

Bruce



******************************************

Kevin -- the thing that you didn't recognize is a (failed) certificate-based
authentication attempt.  This is there because I use some Globus Grid resources
which use strictly certificate-based authentication.  I don't know if this
is part of the standard ssh client or if mine has been linked against some
Globus-enhanced libraries.  In any case, it's not the source of my problem,
which Darren correctly identified.




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