PF Blocking

[schrodinger]

Was checking to see what traffic was being blocked by my PF ruleset. Firstly here is a quick diagram of my LAN at home.



Noticed that the odd packet from my laptop was being blocked:

Oct 02 17:05:03.931875 rule 7/(match) block in on ral0: 192.168.1.125.36105 > 207.46.27.19.1863: [|tcp]

However I have "pass quick on $INTIF all" in my ruleset so unsure why this is being blocked.

[jggimi]

Rule #7 is your block drop in log all.

Your incoming packet does not match the only pass rule above it, which is rule #0:

$piq on $V4EXTIF from $worf to ($V4EXTIF).

It is very hard to read your pf.conf, but it obviously does not match any quick or slow rule following rule #7.

[schrodinger]

Thank you jggimi, something that just obviously never occured to me when I was writing it. I've moved some rules around and made sure the black drop in log all is at the top. Would having the management rule about the block for the blacklist table matter either? Sorry about the format of the ruleset I'll attach or paste links in the future.

[schrodinger]

I moved things around and still the same problem, packets continue to match the default deny.

Oct 03 01:07:02.634952 rule 0/(match) block in on ral0: 192.168.1.125.15401 > 84.53.177.18.80: [|tcp] (DF)
Oct 03 01:07:03.684990 rule 0/(match) block in on ral0: 192.168.1.125.32995 > 216.73.84.103.80: [|tcp] (DF)
Oct 03 01:07:03.685663 rule 0/(match) block in on ral0: 192.168.1.125.17317 > 216.73.84.103.80: [|tcp] (DF)

New Ruleset:
http://www.konundrum.org/pf.df

[jggimi]

The code-wrapped pf.conf was not the problem; my difficulty was deciphering your many macros.

I will try and review your new configuration file, but I fear the same result on my part.

[J65nko]

Could you run tcpdump on pflog0 with a greater snap lenght, so we can see whether the initial packet of the 3-way TCP handshake gets blocked or one after the connection has been setup?

# tcpdump -n -s512 -i pflog0

With this simple pf.conf

# pfctl  -vf block.pf   
block drop log all
pass out quick on re0 inet proto udp from any to any port = domain keep state
pass out quick on re0 inet proto udp from any to any port = ntp keep state

tcpdump shows

# tcpdump -ni pflog0 
tcpdump: listening on pflog0, link-type PFLOG
06:08:18.770421 192.168.222.20.27256 > 83.149.97.13.80: [|tcp] (DF)
06:08:20.255487 192.168.222.20.32520 > 83.149.97.13.80: [|tcp] (DF)

With an increases snap length

# tcpdump -n -s512 -i pflog0
tcpdump: listening on pflog0, link-type PFLOG
06:09:07.793215 192.168.222.20.21686 > 83.149.97.13.80: S 2005153514:2005153514(0)
nop,wscale 0,nop,nop,timestamp 3057449203 0> (DF)

We see the TCP flag S. The initial packet of the 3-way TCP handshake is the only TCP packet that only has a single 'S(yn)" flag. Other packets have S(yn) and A(ck).

Try moving the pass quick on $INTIF all rule to the top of your ruleset (directly after the block rule)
And please change that block rule to

block log all

[schrodinger]

looks like moving the pass rule down sorted things out, thanks for all the help.