From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 14:14:09 2004 Return-Path: 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 BCD4416A4CE for ; Fri, 29 Oct 2004 14:14:09 +0000 (GMT) Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 894C843D31 for ; Fri, 29 Oct 2004 14:14:09 +0000 (GMT) (envelope-from tataz@sitadelle.com) Received: from droopy.tech.sitadelle.com (213-223-184-193.dti.cegetel.net [213.223.184.193]) by smtp.cegetel.net (Postfix) with ESMTP id 1D46C672A0; Fri, 29 Oct 2004 16:14:07 +0200 (CEST) Received: by droopy.tech.sitadelle.com (Postfix, from userid 1000) id 2167AFC00E; Fri, 29 Oct 2004 16:14:11 +0200 (CEST) Date: Fri, 29 Oct 2004 16:14:11 +0200 From: Jeremie Le Hen To: Aaron Nichols Message-ID: <20041029141411.GE10641@sitadelle.com> References: <62721446609.20041028214724@star-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i cc: freebsd-net@freebsd.org Subject: Re: Problems with NAT on gif interface for VPN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 14:14:09 -0000 > Rather than a "problem" with ipfw however, I think I've got a > fundamental problem with how to do this. If I understand correctly, in > order for natd to "reverse" a divert rule (translate the destination > IP back to the original IP on return traffic) the packet has to come > through the same interface it was originally seen by natd on - is this > correct? > > For whatever reason I still seem to be unable to use gif0 for this > purpose, which seems to be the closest thing to an "ipsec interface" > available (I'm beginning to think it's nowhere near as useful as enc0 > on OpenBSD). Thus, I'm stuck translating packets when they either > enter the LAN interface or leave the WAN, the former seems the best > option. IIRC, I read somewhere this is precisely the reason why enc(4) was written. -- Jeremie Le Hen jeremie@le-hen.org