[Openswan dev] IPComp

[Dominique Blas]

Hi again,

I'm currently testing openswan 2.2.0dr1 on native 2.6 IPSEC and I encounter something curious with IPComp.
I know that native IPComp is not advised to be used but here, it is the IPcomp scenario that works better.

I have to say that my VPN head is a small machine with << only >> 64 MB of memory. That's fine for testing such configuration.
I'm convinced that with 128MB I'd not see these behaviours.

The gateway on the other size is a SuperFreeswan 1.99.3. 



       Openswan 2.2.0dr1 <====================> SFreeswan 1.99.3
Test are made from here.

Indeed, when using IPComp it works, when not using the compress it doesn't not work any more (no packet comes back through the tunnel).
With IPComp it works but only packets that size less than 348 bytes (ping -s 319 works) can come back through the tunnel (they go through but don't come back; however the echo reply
has exactly the same size as the echo request packet) and there is no error in the syslog.
I confirm that the scenario is the same with packets of 1500 bytes : they go through but don't come back.

Of course, when I try to send packet from the SFreeswan, only packets with an overall size of less that 348 (ping -s 320) can go through.

WITHOUT compression big packets (> 1000 bytes) can go through the interface (and come back) BUT many memory allocations from pluto failed (lack of memory) and,
finally, the tunnel hangs.

So here we are : with IPComp, even if the packet are smaller (it depends on their own compression rate) pluto needs some memory for them to carry, doesn't it ?
So why there is no error of memory allocation and why this strange size of 347 bytes (an internal buffer ) ? And why this lack of symmetry in the process ?

On the opposite, without IPComp, why does Pluto make me memory allocation errors ?


To hear from you,

db