Re: "pass in" blocks traffic

On Thu, 9 Dec 2004 08:51:37 +1100 (EST)
Darren Reed <darrenr@reed.wattle.id.au> 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.