[Ipsec-tools-users] Re: [Openswan Users] nat_traversal in manual keying ?

[Paul Wouters]

On Tue, 28 Feb 2006, Pjothi wrote:

> when I use pluto and in efffect KLIPS,
> NAT-T happens (although I have some problems, but for now it does work) and
> packets are udp encapsulated.

So you applied the CONIFG_IPSEC_NAT_TRAVERSAL patch to the kernel. Good. Yes
that works.

> But, when I try to do the same with Racoon, when I enable NAT traversal with
> racoon using Preshared keys, it says NAT-T support not compiled in. (I do
> see some nat-t parameters in sample racoon.conf but still it gives me this
> error)

NETKEY does support NAT-T, but it is located within its own code, and not in
the more generic udp code like the KLIPS NAT-T patch. So NETKEY does support
NAT-T, but if you dont use that code (eg unload the modules), you also lose
the NAT-T support in general. This is why
1) KLIPS still needs a NAT-T patch
2) The CONIFG_IPSEC_NAT_TRAVERSAL patch is independant of the KLIPS stack.

> I do not understand this behaviour, does this mean NETKEY IPsec
> implementation still does not support NAT-T or racoon still does not support
> NAT-T.

I guess racoon and NETKEY are not aware nor compatible with their nat-t capabilities.

> Can anyone clarify this ? Because, atleast forcing UDP encapsulation is
> going to help me in a demo setup scenario where a SIP client and SIP proxy
> can automatically setup SAD and SPD using setkey and bootstrap IPSec and
> protect themselves.

Did you ever look at Openswan's "Opportunistic Encryption"? That is exactly
what you are looking for. Automated key distribution via DNS(SEC) where one
peer can have a key in the forward DNS (sip client behind nat) as long as
the other end (server/proxy) has a key in the forward. And autodetection
for establishing new tunnels on demand.

Though with NAT things are more complicated. See also the BTNS working
group on anonymous IPsec channels with channel bindings.

Paul