On Mon, 14 Mar 2005, Darren Reed wrote:
You've chosen a bad pair of rules to be representative of the problem because I doubt many packets are matching your full description.
The "with short" and "with opt lsrr" add extra requirements for the packet to match.
If you had "block in log all" at the top and that wasn't matching packets, I'd be more concerned.
Darren
ok, without revealing all my rules... Lets take SMTP as an example:
[EMAIL PROTECTED]> ipfstat -ih | egrep smtp 0 pass in on le0 all head 200 ... ... 0 pass in quick proto tcp from any to 66.22.104.242/32 port = smtp flags S/FSRPAU keep state keep frags group 200 ... ...
I say again, all the rules listed by ipfstat -ih are at 0 as is ipfstat -oh. Surely this is not true as:
[EMAIL PROTECTED]> ipfstat bad packets: in 0 out 0 IPv6 packets: in 0 out 6 input packets: blocked 32753 passed 309840 nomatch 2 counted 0 short 0 output packets: blocked 6279 passed 279131 nomatch 0 counted 0 short 0 input packets logged: blocked 1242 passed 0 output packets logged: blocked 6273 passed 0 packets logged: input 0 output 0 log failures: input 0 output 0 fragment state(in): kept 0 lost 0 not fragmented 0 fragment state(out): kept 0 lost 0 not fragmented 0 packet state(in): kept 3722 lost 0 packet state(out): kept 10545 lost 0 ICMP replies: 0 TCP RSTs sent: 1 Invalid source(in): 0 Result cache hits(in): 7342 (out): 10660 IN Pullups succeeded: 17 failed: 0 OUT Pullups succeeded: 103 failed: 6 Fastroute successes: 53620 failures: 384 TCP cksum fails(in): 0 (out): 0 IPF Ticks: 156574
Now, these same rules did produce counts previously (version 4.1.3).
