From owner-freebsd-stable Thu Nov 21 4:29:43 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 8A83F37B401 for ; Thu, 21 Nov 2002 04:29:41 -0800 (PST) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id F18A543E6E for ; Thu, 21 Nov 2002 04:29:39 -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 gALCSSgm082104 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Nov 2002 13:28:34 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.6/8.12.6/Submit) id gALCSPn4082102; Thu, 21 Nov 2002 13:28:25 +0100 (CET) (envelope-from hmo) Message-Id: <200211211228.gALCSPn4082102@sep.oldach.net> Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS In-Reply-To: <200211210852.gAL8qscD076629@hugo10.ka.punkt.de> from "Patrick M. Hausen" at "Nov 21, 2002 9:52:54 am" To: hausen@punkt.de (Patrick M. Hausen) Date: Thu, 21 Nov 2002 13:28:25 +0100 (CET) Cc: freebsd-stable-21nov02@oldach.net, hausen@punkt.de, 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=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: > > 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. > Well, in this case - what would you suggest to differentiate > packets that come in for the first time and packets that have been > decrypted and come in again? I'd say this is the wrong question... The issue really is at which point in time the ipfw rules catch in. The FreeBSD paradigm (actually, KAME) is that a packet is being "pushed back onto the IP stack" after de-capsulation, which causes the ipfw rules catch the packets *twice*. This is an interface-centric approach. Other implemenations follow a packet-centric approach, that is: they define a flow of operations which are applied to the packets as they travel through the stack. Again, for example Cisco, the flow for a packet coming into the router and leaving it through another interface: · If IPSec then check input access list · Decryption · Check input access list · Check input rate limits · Check input accounting · Inspect · NAT outside to inside · Policy routing · Routing · Redirect to web cache · NAT inside to outside · Check crypto map and mark for encryption · Check output access list · Inspect · TCP intercept Note that ipfw is roughly equivalent to "Inspect". Note also the distinction between filtering ("input access list") and firewall ("Inspect"). Clearly the original problem that was discussed here would be a no-brainer with this flow. Helge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message