Thread: PF Blocking
View Single Post
  #6   (View Single Post)  
Old 3rd October 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,132
Default

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?
Code:
# tcpdump -n -s512 -i pflog0
With this simple pf.conf
Code:
# 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
Code:
# 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
Code:
# 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
Code:
block log all
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote