6.2-STABLE: enc0 sees only outgoing packets in pf

[Andre Albsmeier]

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