From owner-freebsd-stable Tue Nov 19 7:25:14 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 9555937B401 for ; Tue, 19 Nov 2002 07:25:12 -0800 (PST) Received: from hugo10.ka.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.FreeBSD.org (Postfix) with SMTP id EDA2343E4A for ; Tue, 19 Nov 2002 07:25:10 -0800 (PST) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.12.3/8.12.3) with ESMTP id gAJFOuZE016547; Tue, 19 Nov 2002 16:24:56 +0100 (CET) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.12.3/8.12.3/Submit) id gAJFOurn016546; Tue, 19 Nov 2002 16:24:56 +0100 (CET) From: "Patrick M. Hausen" Message-Id: <200211191524.gAJFOurn016546@hugo10.ka.punkt.de> Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? In-Reply-To: <20021119150826.GA42097@gvr.gvr.org> To: Guido van Rooij Date: Tue, 19 Nov 2002 16:24:56 +0100 (CET) Cc: David Kelly , Scott Ullrich , "'Archie Cobbs'" , "'greg.panula@dolaninformation.com'" , FreeBSD-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL92 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 Hello! Guido wrote: > > The problem is that while ESP packets arrive to be processed by > > IPsec just fine thru my ipfw rules, when the packets are de-encrypted > > and re-inserted into the kernel they appear to ipfw to be coming from > > my external interface (the one they arrived on via ESP). tcpdump can't > > find them (decrypted) on the external interface. > > THe reason tcpdump cannot find them on the external interface is because > they are coming out of your gif interface. In case ipfw thinks they are coming > from your physical external interface, ipfw has a bug that needs to be fixed. I had exactly the same problem a while ago, when I implemented a VPN/firewall setup for two offices of one of our customers. This was around the time of 4.4-RELEASE. ESP packets arrive on external interface and get passed to ipfw - so far so good. I had a rule that skipped diverting to natd for ESP - worked, too. Then the packet gets decrypted and reinserted into the ipfw chain rule chain again. And - this is what complicated matters immensely - the packet is still being flagged as coming from the external network interface ("in via fxp0" for example) instead of coming from the gif interface ("in via gif0"). This made it impossible to implement NAT, VPN _and_ filtering on one box, since you could not use anti-spoofing rules ("deny from rfc1918 to any in via external_if"). The decrypted packets were coming with source and destination from private address space, so you had to pass that and hope your ISP didn't have any holes allowing source routing or similar tricks. After talking to Luigi on BSDCon Europe 2001 I ended deploying two boxes per side. External one in bridge mode doing the filtering and internal one in router mode doing VPN and NAT. So I could configure rather faschist packet filters on the outside and then safely assume "everything coming in will be OK" on the inside box. Used PCs were cheap and from the talk with Luigi I got the impression that there was a design issue that made it impossible to have the packets appear to be coming "in via gif0". Now you tell it may be a bug in ipfw - finally there's a light ;-)) I always envied Linux users with Free/SWAN, since they seem to have decrypted ESP packet payload coming from interface "ipsec0" or similar and can tune their firewall rules accordingly. Regards, Patrick M. Hausen Technical Director -- punkt.de GmbH Internet - Dienstleistungen - Beratung Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100 76135 Karlsruhe http://punkt.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message