floating keep state

[Vadym Chepkov]

I never implied that "floating" means "allow connection on all
interfaces". Rules were created just to illustrate the situation, they
are not part of "production" environment.

In the state table you see packet going from source to destination
#pfctl -ss
self udp 10.10.10.1:53 <- 10.10.11.254:32772       NO_TRAFFIC:SINGLE

It has word "self" in it, which I assume means "not bound to a
particular interface", which is result of "floating" policy.
I thought reply from destination to source would be allowed, isn't
that what "state" mean?
But instead, the packet was blocked by a rule
22:58:14.296965 rule 1/0(match): block in on xl0: 10.10.10.1.53 >
10.10.11.254.32772:  45616*-[|domain]

Vadym


On Thu, Feb 28, 2008 at 1:31 AM, Daniel Hartmeier <daniel at benzedrine.cx> wrote:
> On Wed, Feb 27, 2008 at 11:02:08PM -0500, Vadym Chepkov wrote:
>
>  > My question is, why the reply packet was blocked?
>
>  It seems you're misunderstanding what 'floating state' means.
>
>  It does NOT mean "allow connection on all interfaces".
>
>  If a connection traverses two interfaces, you need to allow it on both,
>  creating two two separate state entries (one incoming, one outgoing).
>
>  The 'floating' would come into play if you had more than two interfaces,
>  and the same connection would traverse all three of them, due to dynamic
>  routing. Without dynamic routing, you can pretty much forget about
>  floating states, they do nothing.
>
>  The first problem in your ruleset is that it does not block by default.
>  Instead, the packet goes out through xl0 based on the implicit pass rule
>  and does not create a second state.
>
>  When the reply comes back in on xl0, there is no matching state (the
>  first one created on xl1 does NOT match, as direction is reversed), and
>  no pass rule matches on that interface in this direction. Hence the
>  block.
>
>  Add a default block, add a 'pass out ... keep state' rule, and it will
>  work.
>
>  You probably thought floating states would do that, but they don't.
>
>  Daniel
>