From owner-freebsd-pf@FreeBSD.ORG Mon Mar 26 19:31:15 2007 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F12C16A402; Mon, 26 Mar 2007 19:31:15 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id E1C9513C45A; Mon, 26 Mar 2007 19:31:14 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l2QJVDGG004277; Mon, 26 Mar 2007 21:31:13 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l2QJVC3D008627; Mon, 26 Mar 2007 21:31:12 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.13.8/8.13.8) id l2QJVCjj016878; Date: Mon, 26 Mar 2007 21:31:11 +0200 From: Andre Albsmeier To: Andrew Thompson Message-ID: <20070326193111.GA97943@curry.mchp.siemens.de> References: <20070323115043.GA6991@curry.mchp.siemens.de> <46052572.9070402@vwsoft.com> <20070324185928.GC45070@heff.fud.org.nz> <46071AAC.2020101@vwsoft.com> <20070326050747.GC68655@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070326050747.GC68655@heff.fud.org.nz> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Volker , Andre Albsmeier , freebsd-pf@freebsd.org Subject: Re: 6.2-STABLE: enc0 sees only outgoing packets in pf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 19:31:15 -0000 On Mon, 26-Mar-2007 at 17:07:47 +1200, Andrew Thompson wrote: > On Mon, Mar 26, 2007 at 02:58:20AM +0200, Volker wrote: > > Andrew, Andre & all, > > > > I've checked it out once more (with a corrected setup) and now have > > been able to block traffic on enc0 in both directions (no matter if > > the tunnel endpoint is final destination or not). > > Great. Thanks for looking into it anyway. Volker was so kind to send me his rules. They didn't contain any surprises but there is one difference: While my IPSec setup uses a GIF-tunnel, his doesn't. Unfortunately, I can't easily switch to a setup without GIF but I did some more tests: First I added these two rules on top of the whole pf ruleset: pass in log quick on enc0 pass out log quick on enc0 These two rules should handle all of the IPSec traffic. They don't use 'keep state' which means we won't have any secretly created rules. They use the 'quick' option which means they are executed immediatley and no subsequent rules will interfere. (Please correct me if anything I said is wrong.) Then I sent a single ICMP Packet from the remote side to my local tunnel endpoint box. This should have produced two log entries: First the incoming ICMP echo request (by the first rule) than the outgoing ICMP echo reply (by the second rule). The only thing that appeared in the logs was: rule 1/0(match): pass out on enc0: 192.168.164.81 > 10.0.1.32: ICMP echo request, id 32773, seq 0, length 64 which is the reply. Concurrently I also checked the state table to be absolutely sure the first packet couldn't slip through by any automatically created rule. Then I tried to connect from the remote side to my local tunnel endpoint on port 26273 (which has nothing listening on it). Again we would expect to see first the SYN coming in through the first rule and then the reply going out through the second rule. Unfortunately, the SYN is missing in the logs but the reply can be found. rule 1/0(match): pass out on enc0: 192.168.164.81.26273 > 10.0.1.32.53599: R 0:0(0) ack 24550328 21 win 0 Next thing was to do the same tests using a kernel on my local side without the IPSEC_FILTERGIF option (in case this would interfere somehow) but the test results were the same :-(. While I have no doubt that Volker really had success in filtering IPSec traffic with enc0 in both directions, I can't confirm that this works when using GIF-based tunnels. In this case incoming packets seems to slip away silently (w.r.t. enc0). I think the best would be to clarify if: - My above setup (with these two rules on top of all others) should have produced log entries in BOTH directions (I am pretty sure they should). - enc0 should also work for IPSec setups which use GIF tunnels. - Maybe someone else who uses IPSec through GIF-tunnels can confirm that he can (or cannot) filter incoming traffic with enc0. -Andre