[Openswan dev] Openswan on uClinux
vyekkirala at TrustedCS.com
Tue Dec 18 14:42:13 EST 2007
[CC'ing Herbert Xu]
> -----Original Message-----
> From: dev-bounces at openswan.org [mailto:dev-bounces at openswan.org]On
> Behalf Of Paul Wouters
> Sent: Tuesday, December 18, 2007 11:46 AM
> To: aparna.dutta
> Cc: dev at openswan.org
> Subject: Re: [Openswan dev] Openswan on uClinux
> On Tue, 18 Dec 2007, aparna.dutta wrote:
> > But we noticed another issue while testing Openswan between
> 2 Suse-Linux
> > machines. We have set up a tunnel between the two and can
> clearly see ESP
> > packets being exchanged. But one of the machines does not
> encrypt TCP
> > packets sometimes. Using Ethereal, we see some TCP packets
> among the ESP
> > packets. This is happening in only one of the machines, the
> other one sends
> > only ESP packets.
> Are the packets that are not encrypted non-initial fragments of TCP ?
> Are you using NETKEY or KLIPS?
> On NETKEY, fragmentation happens before the ipsec stack is
> hit, so NETKEY
Actually even on NETKEY all xfrms should be applied BEFORE the
packet ends up in ip_finish_output->ip_fragment, so frag/reassembly
should be happening transparently (like they should). So, fragments
shouldn't be going out in the clear. Is there a scenario where
this isn't true?
> happilly encrypts the first fragment (the one which contains
> the port numbers)
> The second fragment will not match an ipsec selector, and
> will therefor not
> get encrypted.
> KLIPS does not have this issue, because KLIPS ipsec0
> interfaces have an mtu of
> 16384, and so KLIPS is responsible for fragmenting and does
> so correctly for
> all fragments.
> > Does this indicate any specific configuration problem?
> If you are using NETKEY, you just ran into a KAME issue.
> AFAIK, there is no
> solution for this on the KAME stack.
> Dev mailing list
> Dev at openswan.org
More information about the Dev