[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange ? keep state behaviour





Sven wrote:
On Thu, 06 Jan 2005 18:06:48 -0500, Jason Murray <[email protected]> wrote:

I'm cc'ing the pf list so that the whole thread is archived.

I've included the whole pf.conf file. There isn't much more than what you
already have.

Your suggestion does work, but it weakens the rule set. Instead of a
default deny stance, I have a default deny inbound on the external interface.

It also doesn't provide any clue as to why "keep state" isn't carrying
across the interfaces.


Because you block all traffic on $uat_if

<snip>

I think you misunderstand keep state. From man pf.conf:


     If a packet matches a pass ... keep state rule, the filter creates a
     state for this connection and automatically lets pass all subsequent
     packets of that connection.

The emphasis is on subsequent. In your case the first packet, the one
that's supposed to create the state, is blocked on $uat_if because of
the "block log all" rule.

I must have read that statement a dozen times. If I understand things properly when the packet comes in on $ext_if it creates the state. Because the state is floating it should be picked up when the packet tries to go out on $uat_if. Since it is in the state table it should pass no problem.


To have to create a "keep state" rule on each interface a packet traverses seems counter intuitive to the way it is described. But, that does seem to be what is needed.

This suggests that if I do:
pass quick log from any to $marlin flags S/SA keep state
It should also solve my problems. I'll try this tomorrow and see what results I get.


The rule you added is a good solution to your problem.

However, the implication is that if you want to be highly granular with your ruleset, then you will have to add more rules.