From owner-freebsd-net Fri Oct 18 11:25:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6084A37B401 for ; Fri, 18 Oct 2002 11:25:27 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E37A843E77 for ; Fri, 18 Oct 2002 11:25:26 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021018182526.CAJZ11892.rwcrmhc52.attbi.com@blossom.cjclark.org>; Fri, 18 Oct 2002 18:25:26 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g9IIPNWn045992; Fri, 18 Oct 2002 11:25:23 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g9IIPM4w045991; Fri, 18 Oct 2002 11:25:22 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 18 Oct 2002 11:25:22 -0700 From: "Crist J. Clark" To: Matthew Zahorik Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC/NAT issues Message-ID: <20021018182522.GC45449@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <20021018002729.T66900-100000@mail.allcaps.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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