Subject: Re: ICMP acting weird in ipf 4.1.3? (netbsd-2.0_RC1)
To: Rich Neswold <firstname.lastname@example.org>
From: Pavel Cahyna <email@example.com>
Date: 09/30/2004 22:49:52
On Thu, 30 Sep 2004 15:46:58 +0000, Rich Neswold wrote:
> On Thu, 30 Sep 2004 07:58:28 -0700 (PDT), Hisashi T Fujinaka
> <firstname.lastname@example.org> wrote:
>> On Wed, 29 Sep 2004, Hisashi T Fujinaka wrote:
>> ... (unable to ping external interface starting a month or so ago) ...
>> Not working:
>> > pass out log level local1.info on le0 proto icmp from any to any keep state
>> > pass in log level local1.info quick on le0 proto icmp from any to 192.168.1.18/32
>> So the question remains, what changed? The first rule used to work.
> Maybe there was a bug in the earlier version of IPF? The first rules
> say you'll accept incoming ICMP packets and allow (and remember state)
> for outgoing ICMP packets.
> The question is should KEEP STATE rules only match packets that are
> setting up state? In your case, an ICMP echo request is clearly
> allowed in. The outgoing reply, however, is now getting blocked
> whereas before it was passed. Was it a bug that the echo reply (which
> shouldn't set up any remembered state since it's the final reply) was
> getting accepted by the KEEP STATE rule?
IMHO earlier versions of IPF were correct. If the default is to pass and
there are no block ... rules, packets should not be blocked. I would not
expect rules starting with "pass" to block anything. If the echo reply is
accepted by keep state rule is irrelevant, because even if it is not
accepted, this is not a reason to block it, as there are no "block" rules.
Do you agree?