> On Sat, 14 Aug 2004, Brian wrote:
>
>> Out of curiousity, does anyone know why NAT-T isnt enabled in the racoon
>> setup? I've had several instances of tunnels failing because of what
>> looks
>> like NAT issues, and am under the impression that adding this
>> functionality would solve the problem entirely. Sure, feel free to blame
>> the particular NAT implementation, but that doesn't solve the problem.
>> :)

The reason I bring this is up is because the linux port of racoon (thanks
to the 2.6 linux kernel supporting KAME's IPSec implementation) allows for
NAT-T (with the option "isakmp_natt <public IP> [4500];" in the listen
section of racoon.conf). Also in racoon.conf, one can set this option in
phase one proposals with "nat_traversal on;". Honestly though, I don't
know for a fact that the BSD version includes this functionality. I'll
search the KAME archives after this.

> First of all, NAT-T (in FreeBSD, at least) is a kernel issue, not a racoon
> issue.  Racoon is just the Key Management daemon.  Why does everyone think
> that everything related to IPsec is in racoon? :-)

Not true, it has a lot to do with the keying daemon. (See RFC listed
further below)

> It's not clear whether FreeBSD has NAT-T support yet.  If so, it may be
> only in the 5.x versions.  And NAT-T is sufficiently new that any support
> for it is probably buggy.  I think most people would rather see the
> existing IPsec work more reliably before adding more bugs, er,
> features. :-)

This may well be true. and isn't something I have yet considered. Yet
another reason to hope m0n0wall gets a 5.x makeover sometime in the
future. :)

>
> Also note that NAT-T is an endpoint feature, not a router feature.  You
> don't say what you're trying to do, but if you're trying to get some
> *other* machine to do IPsec *through* m0n0wall, then NAT-T would need to
> be provided on the *other* machine.

Not true. Granted the "client" endpoint must be NAT-T capable, but by
design, it must initiate keying with an also NAT-T aware endpoint.

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-08.txt

I'm not trying to be argumentative; quite the contrary. Its possible my
understanding is flawed, and I'd appreciate any and all corrections.

Thanks for the reply, and hope to see more. :)

 Brian