On Thu, 9 Dec 2004 08:51:37 +1100 (EST) Darren Reed <[EMAIL PROTECTED]> wrote:
> In some email I received from Lloyd Parkes, sie wrote: > > Darren Reed wrote: > > > > Um.. No. Not really. I have the following rules and output from ipmon. > > > > bash-2.05b# ipfstat -in > > @1 block in log on ep0 all > > @12 pass in quick on ep0 from 203.109.146.40/32 to any keep frags > > @13 pass in quick proto icmp from any to any keep state > > @14 pass in on tlp0 all > > @15 pass in on lo0 all > > @16 pass in quick on ep0 proto tcp from any to 10.0.1.25/32 port = 13951 > > flags S/FSRPAU keep state > > > > bash-2.05b# ipmon > > 09/12/2004 08:42:35.318297 lo0 @0:13 b 127.0.0.1 -> 127.0.0.1 PR icmp > > len 20 84 icmp echoreply/0 K-S IN > > 09/12/2004 08:42:36.323418 lo0 @0:13 b 127.0.0.1 -> 127.0.0.1 PR icmp > > len 20 28 icmp echoreply/0 K-S IN low-ttl > > 09/12/2004 08:42:36.323471 lo0 @0:13 b 127.0.0.1 -> 127.0.0.1 PR icmp > > len 20 84 icmp echoreply/0 K-S IN > > If you excuse my confusion, in 4.x, "keep state" may fail for certain > packet types where it plainly makes no sense - e.g. ICMP replies - and > that failure will cause the packet to be blocked, despite the rule > being a "pass" rule. I've not read the whole thread, thus excuse me please for possible duplicates. On my gateways I've faced with such behaviour when ipfs was locked the table (NetBSD kern/24969 and kern/26692). The "ipfs -u" fix this for me. Possible this could related to issue... -- Mishka.
