From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 5 04:22:27 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B043B37B401; Tue, 5 Aug 2003 04:22:27 -0700 (PDT) Received: from ns1.cksoft.de (ns1.cksoft.de [62.111.66.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3402143F75; Tue, 5 Aug 2003 04:22:26 -0700 (PDT) (envelope-from ck-lists@cksoft.de) Received: from majakka.cksoft.de (p508A859E.dip0.t-ipconnect.de [80.138.133.158]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ns1.cksoft.de (Postfix) with ESMTP id C8A5E15C008; Tue, 5 Aug 2003 13:22:20 +0200 (CEST) Received: from majakka.cksoft.de (localhost [127.0.0.1]) by majakka.cksoft.de (Postfix) with ESMTP id EEF7844C8C; Tue, 5 Aug 2003 13:22:19 +0200 (CEST) Received: by majakka.cksoft.de (Postfix, from userid 1000) id 1F88E44C87; Tue, 5 Aug 2003 13:22:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by majakka.cksoft.de (Postfix) with ESMTP id 184B244ABA; Tue, 5 Aug 2003 13:22:19 +0200 (CEST) Date: Tue, 5 Aug 2003 13:22:19 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@majakka.cksoft.de To: Luigi Rizzo In-Reply-To: <20030805034145.B49439@xorpc.icir.org> Message-ID: <20030805125910.Y22923@majakka.cksoft.de> References: <200307070113.h671DPeG082710@freefall.freebsd.org> <20030710110751.L84774@majakka.cksoft.de> <20030805034145.B49439@xorpc.icir.org> X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20020300-cksoft-02bz on majakka.cksoft.de cc: freebsd-ipfw@FreeBSD.org cc: Christian Kratzer cc: sam@FreeBSD.org cc: Ari Suutari Subject: Re: kern/53624: patches for ipfw2 to support ipsec packet filtering X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Christian Kratzer List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2003 11:22:28 -0000 Hi, On Tue, 5 Aug 2003, Luigi Rizzo wrote: > Ari, > maybe the problem was with FAST_IPSEC, i seem to remember a related > MFC recently... > > [Sam, this is about the 'ipsec' dummynet option which was reported > as not working with RELENG_4...] ok looks like problem solved for me. The problem we had seemed to be the ipsec option not working. We have since been able to build a case where this works for us. We have also discoverd in which cases ipsec_filtergif does not work in which cases the ipsec flag can of course not be checked either. I feel comfortable with the facts now so here's the situation. Case1 (this is working) ----------------------- We have setup ipsec/racoon on a freebsd box and w2k and xp clients using the micorosft l2tp/ipsec client to connect to it. The windows clients do transport mode ipsec to the freebsd 4.8 box and then build a ppptp connection to the l2tpd daemon on the freebsd box. The l2tp traffic to udp/1701 on the freebsd box is protected by ipsec. We now needed to ensure that udp/1701 on the vpn gateway is only avaiable to the windows clients that are connecting over the ipsec connection. This is working fine with # l2tpd ${fwcmd} add pass log udp from any to me 1701 ipsec This allows udp/1701 packaets coming in from to external interface if ipsec has been properly setup. This also means that my initial diagnosis was not correct. IPSEC_FILTERGIF and the ipsec patch work fine on FreeBSD stable and also on 5.1-RELEASE I have tested the setup with both boxes. Sorry for stirring everything up. We are also not using FAST_IPSEC Case2: ------ In my original rules I was trying to build the nat rules on a box so that only packets not destined for the ipsec vpn would be natted. This would have simplified our nat configuration to just ${fwcmd} add divert natd all from any to any via ${oif} ipsec The problem with this seemed to be that outgoing packets would pass through the divert rules before having ipsec applied if originating from the local host. Also returning packets did not alway get tagged early enough. The were also other issues with the ways we had setup our ipfw rules like filtering some things with "${oif} in" and "${oif} out". I will have to do more thinking about that. I still do not fully understand at which point the kernel encrypts and decrypts ipsec packets in relation to when ipfw rules are handled and if the current setup causes problems with filtering outgoing packets ... Thanks for the help and again sorry for stirring up everything. Greetings Christian -- CK Software GmbH Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen Email: ck@cksoft.de Phone: +49 7452 889-135 Open Software Solutions, Network Security Fax: +49 7452 889-136 FreeBSD spoken here!