Date: Fri, 18 Oct 2002 06:39:51 -0700 (PDT) From: Matthew Zahorik <matt@hottub.org> To: freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues Message-ID: <Pine.GSO.4.40.0210180628271.5762-100000@hottub> In-Reply-To: <20021018002729.T66900-100000@mail.allcaps.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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) Thanks! - Matt 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?Pine.GSO.4.40.0210180628271.5762-100000>