[Openswan dev] Openswan on uClinux

[Venkat Yekkirala]

[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.
> 
> Paul
> 
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
>