[Openswan Users] Nasty MTU problem - Please Help

[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
>
>

James,
Thanks for the reply.  I was hoping to not have to turn the remote firewall 
network's mtu down, but I may have to.  However your suggested command opened 
another interesting and possibly critical symptom.

tracepath from 10.20.0.10 (NetA) produces 
tracepath 10.20.1.10
 1:  starfire.foddy.home (10.20.0.10)                       0.184ms pmtu 1500
 1:  murdock.foddy.home (10.20.0.1)                         0.731ms
 1:  murdock.foddy.home (10.20.0.1)                         0.670ms
 2:  murdock.foddy.home (10.20.0.1)                         1.714ms pmtu 1422
 2:  windward.ia.foddy.home (10.20.1.1)                   134.293ms
 3:  pvr.ia.foddy.home (10.20.1.10)                       132.832ms reached
     Resume: pmtu 1422 hops 3 back 62


However tracepath from 10.20.1.10 (on NetB) only goes to the G2 gateway, 
before going to "no reply" until it quits.
tracepath 10.20.0.10
 1:  pvrfe.ia.foddy.home (10.20.1.11)                       0.254ms pmtu 1438
 1:  windward.ia.foddy.home (10.20.1.1)                     0.436ms
 2:  no reply
 3:  no reply
 4:  no reply

Never getting to NetA hosts; but the reverse works.  This sounds significant, 
is it??

Brian