[Openswan Users] Nasty MTU problem - Please Help

[James Muir]

Brian Foddy wrote:
> 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??

I don't know if this is significant.  Assuming that the path NetB --> 
NetA is the reverse of NetA --> NetB, it looks like murdock.foddy.home 
does not want to respond to tracepath queries orginating from NetB. 
There are lots of hosts that won't respond to tracepath queries, which 
are sent using udp.  My guess is that this isn't a big deal.

On NetB, set up your tunnel to NetA; next, set the mtu value of eth0 on 
NetB to 1422.  I bet this will fix your icmp fragmentation problem.

-James