I don't think so, I've never had a problem debugging a filter when I have
the data. Filters are one of the simplests things to debug.
> Despite the fact that the output filter has this:
>
>25 permit 207.100.0.16/28 207.100.0.3/32 tcp src eq 23
>26 deny 207.100.0.16/28 0.0.0.0/0 tcp src eq 23
>
> The following packets still seem to be able to penetrate eth0.
>
>TCP from 207.100.0.16.23 to 207.100.0.2.1809 seq 80, ack 0x8D918D34, win 2048, ACK
>TCP from 207.100.0.16.23 to 207.100.0.2.1809 seq 80, ack 0x8D918D34, win 2048, PUSH ACK , 50 bytes
>TCP from 207.100.0.16.23 to 207.100.0.2.1809 seq B2, ack 0x8D918D37, win 2048, ACK
Without knowing where this packet came from and is going to and what filters
it passed through - and the rest of the filter - I can't say where it is.
> It would help to know what packet filters the packets had to pass through,
That is simple. If it comes in a port it goes via the input filter, out
is output filter. Traffic coming in S1 and out onto the ether hits
S1 in and ether0 out filters. Purely logical.
>and which rules permitted their passage. i.e. Filter:eth.out[4]
That would be a major edition since that isn't tracked at all now...
-MZ
-- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 6920 Koll Center Parkway #220, Pleasanton, CA 94566 See me in person: Internet Expo, Boston, MA, October 16-17, Booth 422 ;-)