[Openswan Users] Nasty MTU problem - Please Help
muir.james.a at gmail.com
Fri Jan 16 10:02:10 EST 2009
Brian Foddy wrote:
> 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.
More information about the Users