[Openswan dev] Fwd: Bug#275662: update - also happens with kernel 2.6 native ipsec support

[Rene Mayrhofer]

Hi all,

I do not have enough in-depth knowledge to comment on this. openswan pluto 
seems to be involved in this issue, because the user reported earlier that 
the problem does not occur in combination with racoon. It also seems to work 
correctly with the older freeswan KLIPS (see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275662 for the initial bug 
report).

best regards,
Rene

----------  Forwarded Message  ----------

Subject: Bug#275662: update - also happens with kernel 2.6 native ipsec 
support
Date: Sunday 10 October 2004 12:37
From: "Marc H. Thoben" <marc at thoben.org>
To: 275662 at bugs.debian.org

Hi there,

I've been investigating this problem some more.

Summary: I believe it not to be a problem of openswan, rather than a
problem of the current native ipsec implementation of kernel 2.4 and
2.6. I'm not entirely sure, since I don't know whether the kernel itself
or openswan (and racoon) set the DF flag on ESP packets. The DF flag is
the problem.

First off, a correction of my former statement:
> The problem does _not_ occure, when using the native ipsec support
> of kernel 2.6.8.1 with racoon on the client side (MachineB).

Not true, the problem _does_ occure, when using the native ipsec support
of kernel 2.6.8.1, too. Seems like we've just been lucky in the beginning.


So then, I used tcpdump to compare the traffic if using the ipsec device
and if using the kernel's native ipsec support:

To my suprise both implementations send packets with a length of 1496 to
that dsl user (MachineB), who has a mtu of 1492. The difference is, when
using the kernel's native ipsec support the DF (Don't Fragment) flag
_is_ set, while with the ipsec device in use it is _not_. Also, the
message "MachineB unreachable - need to frag (mtu 1492)" is not
received, when no DF is set.


My first idea was to look at www.netfilter.org for a mangle target to
remove the DF flag from all ESP packets. Since my search there was not
successful, google brought up this page:
http://mordor.strace.net/iptables/

(Thanks to Babel Fish) I was able to compile and install the needed
ipt_DF.o and libipt_DF.so and then used target DF in the POSTROUTING
chain of the mangle table if protocol esp is matched (all this done on
MachineA, which has the highter mtu (1500) and is receiving the "need to
frag" message).


Guess what, now it works !


Reading on, whether fragmenting ESP packets should be allowed or not, I
came across this:
http://bgp.potaroo.net/ietf/idref/draft-ietf-ipsec-esp-v2/#page-13

> An IP packet to which ESP has been applied may itself be fragmented
> by routers en route, and such fragments must be reassembled prior to
> ESP processing at a receiver.

If I understood it right (3.3.5 Fragmentation) it should be allowed,
shouldn't it ? Is openswan or the ipsec implementation of the kernel
setting the DF flag on ESP packets ?


--
Best regards,
   Marc

-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20041010/1efdb1e9/attachment.bin