[Openswan Users] MTU again (netkey fragmentation)

[Harald Scharf]

.... but if DF is set, then the packets are discarded anyway,
or am I wrong?
If I have a packet with 1450 Bytes, DF set, and a MTU of 1300,
then I get "fragmentation needed", and the packet is thrown away on
the gateway with the "small" MTU, isn't it?

Regards

Harald

-----Ursprüngliche Nachricht-----
Von: Paul Wouters [mailto:paul at xelerance.com] 
Gesendet: Mittwoch, 28. Februar 2007 17:35
An: Harald Scharf
Cc: users at openswan.org
Betreff: Re: [Openswan Users] MTU again (netkey fragmentation)

On Wed, 28 Feb 2007, Harald Scharf wrote:

> I analyzed the MTU problem in my openswan / netkey environment
> again. Here is my summary (suggestions will be very welcome)
>
> My setup:
> Two boxes (openswan/netkey/kernel 2.6.19.1)
> Windows XP on subnet 192.168.101.0/24
> Windows XP on subnet 172.20.0.0/16
>
> Fragmentation Test with ping -f under Windows.
> Source is my XP in the Network 192.168.101.0/24
>
> First try (simple routing without ipsec tunnel)
> ping -l 1420 -f 172.20.0.2                      <- OK
>
> Second Try (with IPSEC Connection)
> Ping -l 1420 -f 172.20.0.2                     <- NOT OK
> Fragmentation needed
>
> OpenSWAN Box in my side replies with
>
> OK21:55:01.712984 IP (tos 0xc0, ttl  64, id 43973, offset 0, flags
> [none], proto: ICMP (1), length: 576) 192.168.101.75 > 192.168.101.76:
> ICMP 172.20.0.1 unreachable - need to frag (mtu 1428), length 556
>
> Third try (with IPSEC)
> Flushed the Routing cache on Windows (route -f) and made a
>
> ip route change 172.20.0.0/16 dev eth0 mtu 16230          <-Tip from
> Paul on openswan List on the ipsec box.

Actually, my suggestion was to reduce the mtu. I just mentioned that
stock klips has an mtu on ipsec interfaces that is much larger then
the physical interface, so that it will edhere to the physical mtu.
so try:

ip route change 172.20.0.0/16 dev eth0 mtu 1300

> Ping -l 1420 -f 172.20.0.2                     <- NOT OK
> Fragmentation needed
>
> Fourth try (basic routing to the internet, other gateway):
>
> Ping -l 1420 -f any-internet-ip                <-OK
>
> Fith try (FreeSwan with KLIPS)
> Ping -l 1420 -f 172.20.0.2                     <- OK
>
> So now, I have no idea, what I should do next.
>
> I cannot use KLIPS (does not work with padlock-aes), but
> in my case, a webserver produces packets, with DF set.
> I read about, that KLIPS removes the DF Flag from the IP Header, before
> the packet goes into the tunnel.
> Why does`nt netkey?

The scenario is basically "doomed if you do, doomed if you don't". This is
why you notice a difference in behaviour between freeswan and openswan.
IPv6 was supposed to fix this, by not having a separate ICMP for Path MTU
discovery, but we aren't there yet with IPv6 deployment.

Try: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

(try the combination of both smaller mtu and no path mtu discovery as well)

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155