Date: Fri, 18 Oct 2002 11:25:22 -0700 From: "Crist J. Clark" <crist.clark@attbi.com> To: Matthew Zahorik <matt@hottub.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC/NAT issues Message-ID: <20021018182522.GC45449@blossom.cjclark.org> In-Reply-To: <Pine.GSO.4.40.0210180628271.5762-100000@hottub> References: <20021018002729.T66900-100000@mail.allcaps.org> <Pine.GSO.4.40.0210180628271.5762-100000@hottub>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 18, 2002 at 06:39:51AM -0700, Matthew Zahorik wrote:
> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>
> > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> > packet will get rejected when it reaches the other IPSEC node.
>
> Not exactly true. I use a Windows Nortel Contivity client behind NAT just
> fine.
>
> If you're using an AH association (header authentication) that will not
> pass through NAT. I'm sure someone on this list may come up with a fancy
> trick for FreeBSD, but generally the statement is true. AH detects the
> NAT changes as header corruption.
>
> But if you're only using ESP (encryption of payload) that will work fine.
>
> Most turn on both AH and ESP by default, but that isn't always the case as
> in the Nortel boxes.
Not exactly true. The current ESP standard has its own header
authentification mechanism. To verify end-to-end header integrity, you
need only use ESP with this option turned on (excuse me if I don't go
to the RFC to remind myself of the formal name of the option).
And as another data point, the Cisco VPN Concentrator (formerly
Altiga) run just fine through NAT by default. They do ESP without
header integrity checks and UDP encapsulation of the ESP to make it
easier to run it through NAT (although that isn't "real" IPsec
anymore).
> On another note, I'd *love* to use my FreeBSD NAT box as a VPN tunnel
> endpoint rather than my windows boxes. It's a dynamic IP, so it's
> catch-22 right now. I can't create a tunnel or SPD policy entry before I
> know the IP addresses, and IKE/racoon can't start without those things.
>
> So, if someone happens to be ripping the IPsec processing apart, something
> to eliminate this catch-22 would be nice (: (spd entries pointing to an
> unconfigured or dummy tunnel, for example)
What's the problem with just having the script that builds the SPD
discover the IP address on its own?
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021018182522.GC45449>