The feedback from Paul was very useful. But am looking at a very simple scenario without a DNS. I just need to enable setkey to "udp encapsulate packets" irrespective of the presence of a NAT in between. In the lab scenario where I am trying to implement, I just want two systems to be IPSec protected, but also UDP encapsulated. (Basically forcing it).
manually keyed ------IPSec proteced + udp encapsulated------------------manually keyed
Is this already available in setkey ? if not is it possible to add ?
It would be definitely helpful to get some expert opinions to start with.
Is pluto also using the PFKEY interface with KLIPS ?
many thanks and regards,
On 2/28/06, Paul Wouters <firstname.lastname@example.org> wrote:
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
> 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
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
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.