[Openswan Users] Nasty MTU problem - Please Help - Second try

[Brian Foddy]

On Wednesday 14 January 2009, James Muir wrote:
> > Sending files from a NetA host to NetB host works fine with scp.  Sending
> > a file via scp from the same NetB host back to NetA always hangs (or long
> > ssh output).  If I wireshark the transfer on the G2 internal eth1 I see
> > the following packets:
> > 10.20.1.10 -> 10.20.0.10 SSHv2 packet len=1448
> > 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation
> > needed) 10.20.1.10 -> 10.20.1.10 SSHv2 packet len-1448
> > 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation
> > needed) 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> > 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
> >
> > 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> > 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
> > 10.20.0.10 -> 10.20.0.10 TCP   [TCP Dup ACK]
> >
> > (I have saved the whole capture and can include if its needed).
> > then similar repeating patterns of 1386 length packets that never make
> > it. The ssh packets are flags with don't fragment.  Its clear ssh is
> > seeing the attempted mtu discovery, but it doesn't seem to be low enough.
> >
> > If I ping from 10.20.1.10 to 10.20.0.10, a "ping -s 1394" will get
> > through, but a "ping -s 1395" wont.  Reversing the pings (from 10.20.0.10
> > to 10.20.1.10), anything over 1394 will produce
> >
> >>From murdock.foddy.home (10.20.0.1) icmp_seq=1 Frag needed and DF set
> >> (mtu =
> >
> > 1422)
> > before the pings start getting through.  Interestingly, if I ssh to G2
> > then to NetB host outside the VPN (normal internet SSH), the transfers
> > never hang. So it seems to only be the vpn connections having the
> > problem.
>
> I just dealt with a similar mtu problem and saw many of the same
> symptoms you've reported.  If you look back in the list archive, then
> you can read my messages.
>
> To fix your problem, try the following.  On NetB, do
>
> 	$ tracepath NetA
>
> tracepath does path mtu discovery.  Suppose the pmtu value it reports is
> 1450.  Now, setup your tunnel from NetB to NetA.  Next, change the mtu
> value of eth0 like so:
>
> 	$ ifconfig eth0 mtu 1450
>
> (I think the command may be slightly different on Redhat/Mandriva.)
> Now, test the tunnel by trying to transfer a file using scp.
>
> -James
>
>
I'm back at this again.  Dropping the MTU on the remote firewall as suggested 
allowed the SSH through the VPN to work, but then the Windows boxes (Vista & 
XP) for traffic not using the VPN failed.  I don't want to start having to 
globally drop the MTU on every box/interface going through the firewall.

I still feel this is a Openswan bug that should be address in the software.  
I've done more net traces, and there never is a ICMP reply dropping the MTU 
below 1438, and it has to get to 1422.  When I trace the outbound eth0 on the 
NetB firewall, they are 1496, clearly too big to be received on NetA's 
firewall.

Brian