Date: Mon, 26 Mar 2007 21:31:11 +0200 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: Andrew Thompson <thompsa@freebsd.org> Cc: Volker <volker@vwsoft.com>, Andre Albsmeier <Andre.Albsmeier@siemens.com>, freebsd-pf@freebsd.org Subject: Re: 6.2-STABLE: enc0 sees only outgoing packets in pf Message-ID: <20070326193111.GA97943@curry.mchp.siemens.de> In-Reply-To: <20070326050747.GC68655@heff.fud.org.nz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070326193111.GA97943>