From owner-freebsd-stable Thu Nov 21 0:37:20 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5429A37B401 for ; Thu, 21 Nov 2002 00:37:18 -0800 (PST) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEA0B43E97 for ; Thu, 21 Nov 2002 00:37:16 -0800 (PST) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.12.6/8.12.6/hmo29jun02) with ESMTP id gAL8b5gm080748 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Nov 2002 09:37:05 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.6/8.12.6/Submit) id gAL8b4Se080747; Thu, 21 Nov 2002 09:37:04 +0100 (CET) (envelope-from hmo) Message-Id: <200211210837.gAL8b4Se080747@sep.oldach.net> Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS In-Reply-To: <200211200820.gAK8Ki6G041336@hugo10.ka.punkt.de> from "Patrick M. Hausen" at "Nov 20, 2002 9:20:44 am" To: hausen@punkt.de (Patrick M. Hausen) Date: Thu, 21 Nov 2002 09:37:04 +0100 (CET) Cc: archie@dellroad.org, guido@gvr.org, dkelly@HiWAAY.net, sullrich@CRE8.COM, greg.panula@dolaninformation.com, FreeBSD-stable@FreeBSD.ORG From: Helge Oldach MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick M. Hausen: > One question to Guido: why would it be necessary to add a new > device - be it called esp0 or fxp_esp0 or similar - to tag the > packets as coming from? Can't the decrypted packets just come > from the already existing gif0 tunnel interface? Essentially because you don't need to use a gif interface at all if you implement ESP tunnel mode. The only purpose for gif is to get the routing straight, which is: You have a route to the remote inside network via the gif interface, and you have a "public" route via the real interface. You can as well implement this by placing the internal route to an IP address which has a static ARP entry with the MAC address of the public default gateway. Been there, it works. Again compared to Cisco IOS, it's even simpler there, as you can create "remote routes" which avoids fiddling with MAC entries, e.g. ! remote (public) via our default gateway ip route 62.12.34.56 255.255.255.255 194.123.123.124 ! remote (internal) ip route 172.16.0.0 255.255.0.0 62.12.34.56 (Note that this isn't possible with the BSD stack. It would simplify things it it would...) The core problem is that we have a single routing table only, and hence we have a mix of internal and public routes. Consequently we will see both internal and external packets on interfaces. Therefore I don't see the need for an extra interface. I regard the gif set-up as confusion already, because this interface isn't used at all. Specifically, a beast such as esp0 would only work for ESP tunnel mode, but again add confusion for ESP transport mode and AH. (What IP addresses do you assign the esp0 interface in transport mode?) Finally, such an implementation would be quite unique in the industry. I would prefer to keep reference to existing implementations. Helge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message