On Thu, May 18, 2006 at 04:38:44PM -0400, Chad M Stewart wrote: > # cat /etc/pf.conf |grep -v ^# |grep block > set block-policy return > block in log all > block log quick inet proto tcp from <ssh-denied> to $ssh_servers port > ssh label accessive-ssh
Ok, so all your block rules do have the 'log' option. That rules out the most obvious explanation. There are other causes for a packet to get dropped by pf, besides matching a block rule. The packet could be invalid (like, be too short, or have invalid checksums), or the source-tracking limits (which I see you're using) are kicking in, or the packet might almost (but not quite) match a state entry. In these cases, a ruleset evaluation is not needed (as the packet is dropped unconditionally), hence it can't match any block rule (with or without 'log' option). But all such cases increment various counters. Run pfctl -si, note the output, reproduce the blocked packet that doesn't get logged. Then run pfctl -si again. Compare the two outputs. Are any counters increasing? At least a packet and byte counter should increase, but do other counters increase as well? Reproducably, correlating with the blocked packets that aren't logged? Also, explain what packet the test with telnet you described is expected to cause, in what direction on what interface, with what source and destination addresses and ports. Even better, verify that expectation and capture the first SYN packet of that telnet test with tcpdump and post it. Incoming packets are seen by tcpdump even when pf blocks them. If you don't see the packet with tcpdump at the pf box, it might simply never arrive there, and pf isn't blocking it at all. Daniel
