From owner-freebsd-stable Sun Nov 17 22:52:23 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 A8EE537B401 for ; Sun, 17 Nov 2002 22:52:19 -0800 (PST) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B2C440D8 for ; Sun, 17 Nov 2002 22:51:34 -0800 (PST) (envelope-from ari.suutari@syncrontech.com) Received: from linux (coffee.syncrontech.com [62.71.8.37]) by guinness.syncrontech.com (8.12.6/8.12.6) with ESMTP id gAI6pGHB082018; Mon, 18 Nov 2002 08:51:17 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Content-Type: text/plain; charset="iso-8859-1" From: Ari Suutari Organization: Syncron Tech Oy To: greg.panula@dolaninformation.com, David Kelly Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Date: Mon, 18 Nov 2002 08:54:29 +0200 User-Agent: KMail/1.4.3 Cc: FreeBSD-stable@FreeBSD.ORG References: <200211142157.57459.dkelly@HiWAAY.net> <3DD4F4D1.83C77B0@dolaninformation.com> In-Reply-To: <3DD4F4D1.83C77B0@dolaninformation.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211180854.29349.ari.suutari@syncrontech.com> X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) 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 Hi, =09I think that this is caused by changes in ip_input.c, =09version 1.130.2.40: "MFC: 1.214: Get rid of checking for ip sec history. It is true that packets are not supposed to be checked by the firewall rules twice. However, because the various ipsec handlers never call ip_input(), this never happens anyway. This fixes the situation where a gif tunnel is encrypted with IPsec. In such a case, after IPsec processing, the unencrypted contents from the GIF tunnel are fed back to the ipintrq and subsequently handeld by ip_input(). Yet, since there still is IPSec history attached, the packets coming out from the gif device are never fed into the filtering This fix was sent to Itojun, and he pointed towartds http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction. This patch actually implements what is stated there (specifically: Packet came from tunnel devices (gif(4) and ipip(4)) will still go through ipf(4). You may need to identify these packets by using interface name directive in ipf.conf(5)." =09This means that packets decapsulated from ipsec =09packets are passed again to ipfw rule processing. =09Things used to be like this some releases ago. =09Although this might break some rulesets I like it =09since it gives better security for some of my cases. =09 =09=09Ari S. On Friday 15 November 2002 15:21, Greg Panula wrote: > David Kelly wrote: > > Ran cvsup this morning (11/14/2002), built world, installed world, bu= ilt > > and installed new kernel, forgot mergemaster, rebooted, and my VPN to > > another FreeBSD box was not working. Did not update the other box. > > > > Discovered I had not done mergemaster on the problem box so did that > > and rebooted again. Still have the same problem. > > > > What I have found is packets that are supposed to be on fxp0 are bein= g > > killed by ipfw for appearing on fxp1 by this rule. fxp1 is my exteral > > NIC connected to the ISP: > > > > 00600 14 1122 deny ip from any to 10.0.0.0/8 via fxp1 > > > > But if I add this rule in front of the above (so I don't have to rety= pe > > the above to add it back) then all is working as it once did: > > > > 00550 2 168 allow ip from 192.168.100.0/24 to 10.0.0.0/24 in recv > > fxp1 > > > > The above are prior to my divert rule. > > > > Much later in my ruleset (after divert to natd) I was allowing these > > packets via fxp0, the internal interface. Some are still going that w= ay. > > > > The distant end is still 4.6-STABLE and shares practically the same > > ipfw ruleset and everything. Rule 600 doesn't cause a problem there. > > Wasn't a problem before the latest update for 4.7-stable. > > > > No doubt I'm lost as to how IPsec packets traverse thru these layers. > > When setting the system up was surprised to find nothing came thru > > gif0. At least nothing ipfw sees. > > > > -- > > David Kelly N4HHE, dkelly@hiwaay.net > > gif tunnels aren't really needed for passing IPSec traffic between > locations. I have stopped using them. > > You might try adding an allow rule for esp traffic just before your rul= e > 600. > > Something like: > ipfw add 550 allow esp from to out via fxp1 > ipfw add 555 allow esp from to in via fxp1 > or > ipfw add 550 allow esp from any to any via fxp1 > > If you are using gif tunnels for passing your ipsec traffic thru you > might want to try not using them. I ran into some similar funkyness a > while back. Packets traverse the gif tunnel, get decrypted and then ge= t > rejected by the firewall rules for the external interface. > > If you would like a quickie example of ipsec tunnel setup between two > freebsd boxes, let me know. > > Sorry, I couldn't really answer why you're setup doesn't work after > upgrading to 4.7. > > greg > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message --=20 Ari Suutari / Syncron Tech Oy Lappeenranta, Finland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message