[Openswan Users] MTU/DF problem with 2.6

Andy fs at globalnetit.com
Mon Feb 13 17:36:00 CET 2006


On Mon, 2006-02-13 at 22:30 +0100, Beschorner Daniel wrote:
> >> On Mon, 2006-02-13 at 16:11 +0100, Beschorner Daniel wrote:
> >> We have an IPSEC scenario with peer MTUs of 1500 and 1492.
> >> Packets with a MTU of 1500 bytes sent from the tunnel router to the 1492
> >> peer won't reach their destination, a destination-unreachable message is
> >> generated und shown in the senders kernel log ("pmtu discovery on SA
> >> ESP...").
> >> But unfortunately this information never reaches the sender inside the
> >> tunnel.
> >> 
> >> So my question is: KLIPS (2.4) sends the ESP packets always without the
> DF
> >> flag, so they reach their destination, even though fragmented.
> >> 
> >> Can I force the 2.6 kernel implementation to also clear the DF flag
> always?
> >>
>  
> > A brute-force answer:
> > "echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc"
> > will turn off pmtud for all packets (not just esp), I believe.
> 
> It's a pity, PMTUD is working well and very useful for non-ESP traffic.

OK, perhaps you can use the mtu lock option in ip route.
I haven't tried this, but it seems it should work. Add a route to the
other SG, like this:
 ip route add <dest> mtu lock 1492

According to the ip manpage:
       mtu lock MTU
              the  MTU along the path to the destination.  If the
modifier lock is not used, the MTU may be updated by the kernel due to
Path MTU Discovery.  If the modifier lock is used, no path MTU discovery
will be
              tried, all packets will be sent without the DF bit in IPv4
case or fragmented to MTU for IPv6.

Presumably, you could even use iptables to mark ESP packets and use the
mark to select this rule.

If you try this, please let me know if it works!


-- 
Andy <fs at globalnetit.com>



More information about the Users mailing list