On Mon, Aug 30, 2004 at 09:06:33PM -0400, Jason Opperisano wrote: > On Mon, 2004-08-30 at 14:18, cmustard wrote: > > rule 1/0(match) block in on rl0: 84.2x.xxx.xx > 192.168.3.2.6346: tcp 0 (DF) > > rule 1/0(match) block in on rl0: 224.2x.xxx.xx > 192.168.3.2.6346: tcp 0 (DF) > > to me, this rule says it's blocking traffic on my external interface that is > > comming from any (internet) and bound for my dmz interface. > > are those the complete log entries? my log entries look more like > (produced with "tcpdump -netttr /var/log/pflog"):
> are those the complete log entries? my log entries look more like - no, i truncated, I was running tcpdump -neq -ttt -r /var/log/pflog they were the 'standard/normal' entries: Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.74.50.80 > 192.168.x.xxx.61265: P 4294966553:0(743) ack 1 win 5792 (DF) Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.xx.xx.80 > 192.168.xx.x1.61265: P 4294966553:0(743) ack 1 win 5792 (DF) etc,... > > rule 0/0(match): block out on hme1: 10.1.1.15.139 > 10.1.2.16.32962: R > 8:8(0) ack 1 win 58410 (DF) > > the reason i ask, is because all your rules use "flags S/SA" and "keep > state" which; in the normal course of operation, create a lot of log > entries where the flags are RST-ACK, FIN-ACK, etc... they are just > trailing packets that arrive after the state entry has been removed... > -hmmm, so your saying just because I see a rule being matched it doesnt' mean a packet is being blocked. it may be matching flags S/SA but is still passing in to the interface, cool, I haden't thought of that, thanks. that's what I get using rules I don't really understand yet,... :) -mus
