From owner-freebsd-stable Tue Nov 19 11: 0:19 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 86EE537B401 for ; Tue, 19 Nov 2002 11:00:16 -0800 (PST) Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id C35CF43E88 for ; Tue, 19 Nov 2002 11:00:13 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 3AF6B296; Tue, 19 Nov 2002 20:00:12 +0100 (CET) Date: Tue, 19 Nov 2002 20:00:12 +0100 From: Guido van Rooij To: "Patrick M. Hausen" Cc: David Kelly , Scott Ullrich , 'Archie Cobbs' , "'greg.panula@dolaninformation.com'" , FreeBSD-stable@FreeBSD.ORG Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Message-ID: <20021119190012.GD43039@gvr.gvr.org> References: <20021119150826.GA42097@gvr.gvr.org> <200211191524.gAJFOurn016546@hugo10.ka.punkt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211191524.gAJFOurn016546@hugo10.ka.punkt.de> 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 On Tue, Nov 19, 2002 at 04:24:56PM +0100, Patrick M. Hausen wrote: > 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 ;-)) Yes, I think there is a problem here in the ipfw code. Let's examine the GIF/ESP setup people described here. Let's examine the following situation: interfaces: fxp0, gif0 gif0: flags=8051 mtu 1280 tunnel inet 192.168.100.1 --> 192.168.100.2 inet 10.0.0.1 --> 10.0.1.1 netmask 0xffffff00 fxp0: flags=8843 mtu 1500 inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 Then suppose I have ESP betwee 10.0.0.1 and 10.0.1.1. When I sent a packet to 10.0.1.1, the following happens: An IP packet is generated, then a new IP header gets added by gif0, then it is encrypted and finally it is sent out. When a packet is received, it is first decrypted, then fed into the gif device and the resulting IP packet gets processed again by ip_input(). I suspect that ipfw somehow records the incoming interface, but never resets it to gif0 when it hits the gif device. I think ipfw should use the 'normal' way of determening the interface, which is to inspect m->m_pkthdr.rcvif. If it doesn't inspect this but adds its own rcvif pointer somewhere, it should reset this pointer whenever a subprotocol handler (e.g. gif for IP in IP packets) is called. Basically a packet coming out of such an interface is to be treated as any other packet entering the system. That is also the reason that the gif device sets m->m_pkthdr.rcvif to be the particular device instance the packet arrived on and puts the packet on the ipintrq like any other driver for a physical interface would do. > > 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. Which is also bad because you have no clue on which real interface the packets came from. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message