[Openswan dev] Question about UDP in ESP encapsulation in Openswan

[Kevin Wilson]

Thanks a lot for your quick answer, Paul!

I tried to find out exactly where does this happen with the help of your
question.

 I am talking about kernel > 2.6.22 , so by quick looking in the
source code it seems to me to be done by netkey in:
pfkey_add_sa() ;
with pfkey_build(pfkey_x_nat_t_type_build(
                        &extensions[K_SADB_X_EXT_NAT_T_TYPE]  ...)

in conjunction with xfrm_encap_tmpl.

> > Where in the kernel such encapsulation is done ?

> new style: via xfrm hook in net/ipv4/udp.c

It seems to me that in net/ipv4/udp.c we do decapsulation,
((**removing** the UDP header) when **receiving** a packet,  by
setting xfrm4_udp_encap_rcv.

I think that encapsulation (**inserting** the UDP header) is done
in   esp_output() (net/ipv4/esp4.c). This is done by using
xfrm_encap_tmp which is part of the SA (xfrm_state)

I should delve into it more.
Thanks again,


rgs,
Kevin

On Tue, Oct 26, 2010 at 9:52 PM, Paul Wouters <paul at xelerance.com> wrote:
> On Tue, 26 Oct 2010, Kevin Wilson wrote:
>
>> As far as I understand, when adding nat-traversal=yes to ipsec.conf
>> and when  both sides are behind NAT,
>
> If one or both sides are behind NAT.
>
>> As far as I understand, openswan usespace pluto daemon  is opening
>> sockets and sends these two types packets.
>
> Correct.
>
>> My question is about regular traffic
>
>> This traffic also should have UDP encapsulation for NAT-T ; who
>> performs this ?
>
> The kernel. Either the XFRM NAT-T hooks (netkey and klips on linux > 2.6.22)
> or the KLIPS NAT-T patch (linux <= 2.6.22)
>
>> is it a job done by the kernel ? who tells the kernel
>> that the traffic should be UDP encapsulated for NAT-T ? or is it done
>> by openswan (I believe it ain't so).
>
> Yes, the socket is marked as UDP_ENCAP using a setsockopt.
>
>> 1) Where in the kernel such encapsulation is done ?
>
> old style: net/ipv4/udp.c
> new style: via xfrm hook in net/ipv4/udp.c
>
> Paul
>