[Openswan Users] packets get dropped by the ipsec

Egor N. Martovetsky egor at pasemi.com
Wed Nov 14 20:34:40 EST 2007


with the help of the coworker(Olof), I was finally able to get the ipsec 
working. The packets now go through the tunnel.
The problem turned out to be a bug in Openswan, but it shows up only on
a 64-bit big-endian machine, which I happen to be using.  In file
linux/net/ipsec/pfkey_v2_ext_process.c there is a line:

            unsigned long *ulsap = (unsigned long *)sap;
            *ulsap = ((struct sockaddr_in*)s)->sin_addr.s_addr;

This cast is incorrect!
The address ends up being zero.

When I change it to
            unsigned int *ulsap = (unsigned int *)sap;
            *ulsap = ((struct sockaddr_in*)s)->sin_addr.s_addr;

then things work fine.

Another issue I stumbled upon is that ipsec_init doesn't check the
return value of openswan_inet_add_protocol() calls.  This causes a
problem when CONFIG_INET_AH or  CONFIG_INET_ESP are defined
in the kernel, since openswan protocol handler is not able to register,
but there is no indication that something went wrong.  This will result
in ipsecX device never getting the packet on the receive side.


Paul Wouters wrote:

>On Fri, 26 Oct 2007, Egor N. Martovetsky wrote:
>>example to set up a host-to-host tunnel using 2 machines on the same subnet
>>running 2.6.22 kernel.
>>things were working fine when I was using kernels with NETKEY.  The pings from
>>machine made it to the other through the tunnel.  However, I realized I need
>>to use KLIPS in order to get hw acceleration through OCF, so that's what I'm
>>using now.
>>the connection is still established, but the pings to the left machine from
>>right machine
>>get dropped by ipsec at the source machine.
>    leftnexthop=        # correct in many situations
>    right=              # Remote vitals
>Can you try commenting out leftnexthop and adding type=%direct ?
>(or add a "router" between the two machines for a proper test)

Egor N. Martovetsky

More information about the Users mailing list