[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] NAT-T?
 Date:  Mon, 16 Aug 2004 19:21:54 -0700 (PDT)
On Mon, 16 Aug 2004, Brian wrote:
> > 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.

AFAIK the racoon sources are common, so OS-specific aspects would most
likely relate to the properties of the OSes involved.

> > 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)

Well, OK, there are *also* issues with key management.  But the most
significant aspect is whether the encapsulation/decapsulation code
understands it, and that part is in the kernel.  To confuse things
further, there are *two* IPsec implementations to choose from in FreeBSD,
the one that can use hardware crypto and the one that supports IPv6 (you
can't have both), and they're not always in sync with respect to bugs and
features.

> > 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.

Exactly.  But you didn't specify (earlier) that the m0n0wall was supposed
to be an endpoint.

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

That's not an RFC, it's a draft. :-) As I said, pretty new.

On Mon, 16 Aug 2004, Brian wrote:

> > 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.
> 
> Oops, forgot to mention my intended usage.
> 
> m0n0wall is used as an exterior firewall, allowing IPSec access in from
> various roadwarrior clients. All clients initiating a connection from a
> routable IP (read: not behind NAT) have no issues keying and initiating a
> tunnel. Some clients that are behind NAT have no issues whatsoever, and
> there are those few poor souls who are stuck behind ancient NAT
> implementations which do not work. I myself cannot pass traffic from
> behind an older PIX, though both phases 1 and 2 complete successfully. I
> know what you're thinking, and no, its not an ACL or other intentional
> restrictive policy. :)

How do the "no issues" NAT implementations handle it?  With an IKE proxy
manipulating the NAT tables to key to the proper SPIs?  Or with manual
configuration for specific cases?

You could presumably run a NAT-T-aware endpoint *behind* a m0n0wall, but
if you needed to use m0n0wall's IPsec as well, one or the other would need
to run on a nonstandard IKE port (unless the cases could be distinguished
by remote IP).

					Fred Wright