floating keep state

All,

I must be doing something wrong, but I can't figure it out.
I actually simplify the network structure, to keep it
simple

- a client and a web server are on different network
segments;
- all incoming connections to the client are prohibited;
- client should be allowed to access web server and get a
reply;

Here are the rules:

set state-policy floating
pass in quick proto tcp to <www_servers> port
$www_tcp_ports flags
S/SA keep state
block in log to <protected_dev_net>

In the pflog I can see that reply packet from www server is
blocked on
server's segment interface. I thought 'set state-policy
floating'
should create a rule interface independent and allow a
reply? Am I
wrong?

Thank you,
Vadym Chepkov
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

I didnt understand this rule:
 pass in quick proto tcp to <www_servers> port
$www_tcp_ports flags
 S/SA keep state

I think is:
pass in quick proto tcp from any to <www_servers> port
$www_tcp_ports
flags S/SA keep state


-- 
Gilberto Villani Brito
System Administrator
Londrina - PR
Brazil
gilbertovb(a)gmail.com



On 27/02/2008, Vadym Chepkov <vchepkovgmail.com> wrote:
> All,
>
>  I must be doing something wrong, but I can't figure it
out.
>  I actually simplify the network structure, to keep it
simple
>
>  - a client and a web server are on different network
segments;
>  - all incoming connections to the client are
prohibited;
>  - client should be allowed to access web server and
get a reply;
>
>  Here are the rules:
>
>  set state-policy floating
>  pass in quick proto tcp to <www_servers> port
$www_tcp_ports flags
>  S/SA keep state
>  block in log to <protected_dev_net>
>
>  In the pflog I can see that reply packet from www
server is blocked on
>  server's segment interface. I thought 'set
state-policy floating'
>  should create a rule interface independent and allow a
reply? Am I
>  wrong?
>
>  Thank you,
>
> Vadym Chepkov
>  _______________________________________________
>  freebsd-pffreebsd.org mailing list
>  
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>  To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
>
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

You can omit 'from any' or 'to any' as redundant if
pf.conf.

# pfctl -sr|grep www_servers
pass in quick proto tcp from any to <www_servers> port
= http flags
S/SA keep state
pass in quick proto tcp from any to <www_servers> port
= https flags
S/SA keep state


On Wed, Feb 27, 2008 at 4:10 PM, Gilberto Villani Brito
<linuxgiboia.org> wrote:
> I didnt understand this rule:
>
>  pass in quick proto tcp to <www_servers> port
$www_tcp_ports flags
>   S/SA keep state
>
>  I think is:
>  pass in quick proto tcp from any to
<www_servers> port $www_tcp_ports
>
> flags S/SA keep state
>
>
>  --
>  Gilberto Villani Brito
>  System Administrator
>  Londrina - PR
>  Brazil
>  gilbertovb(a)gmail.com
>
>
>
>
>
>  On 27/02/2008, Vadym Chepkov <vchepkovgmail.com> wrote:
>  > All,
>  >
>  >  I must be doing something wrong, but I can't
figure it out.
>  >  I actually simplify the network structure, to
keep it simple
>  >
>  >  - a client and a web server are on different
network segments;
>  >  - all incoming connections to the client are
prohibited;
>  >  - client should be allowed to access web server
and get a reply;
>  >
>  >  Here are the rules:
>  >
>  >  set state-policy floating
>  >  pass in quick proto tcp to <www_servers>
port $www_tcp_ports flags
>  >  S/SA keep state
>  >  block in log to <protected_dev_net>
>  >
>  >  In the pflog I can see that reply packet from
www server is blocked on
>  >  server's segment interface. I thought 'set
state-policy floating'
>  >  should create a rule interface independent and
allow a reply? Am I
>  >  wrong?
>  >
>  >  Thank you,
>  >
>  > Vadym Chepkov
>  >  _______________________________________________
>  >  freebsd-pffreebsd.org mailing list
>  >  
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>  >  To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
>  >
>  _______________________________________________
>  freebsd-pffreebsd.org mailing list
>  
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>  To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
>
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

I created a lab configuration with the minimum settings

dns server has ip 10.10.10.1
client has ip 10.10.11.254
between them is 6.3-RELEASE-p1 with 10.10.10.6 and
10.10.11.1 interfaces

here is /etc/pf.conf

set block-policy return
set state-policy floating
pass in log quick proto udp from any to 10.10.10.1 port
domain keep state
block in log from any to 10.10.11.254

Now I make nslookup on the client, here is the output of
tcpdump -n -l
-e -i pflog0

22:58:14.296303 rule 0/0(match): pass in on xl1:
10.10.11.254.32772 >
10.10.10.1.53:  45616+[|domain]
22:58:14.296965 rule 1/0(match): block in on xl0:
10.10.10.1.53 >
10.10.11.254.32772:  45616*-[|domain]

State is
#pfctl -ss
self udp 10.10.10.1:53 <- 10.10.11.254:32772      
NO_TRAFFIC:SINGLE

My question is, why the reply packet was blocked?
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

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
<danielbenzedrine.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
>
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

It was not my intention to argue with anybody, I was trying
to understand 
why the packet was blocked and reply to Daniel got bounced,
so I posted it 
in the distro. I got it now, IN packet state doesn't match
IN packets, only 
OUT. Thank you.

Vadym


----- Original Message ----- 
From: "Kian Mohageri" <kian.mohagerigmail.com>
To: "Vadym Chepkov" <vchepkovgmail.com>
Cc: <freebsd-pffreebsd.org>
Sent: Thursday, February 28, 2008 9:56 AM
Subject: Re: floating keep state


> On Wed, Feb 27, 2008 at 8:02 PM, Vadym Chepkov
<vchepkovgmail.com> wrote:
>>  set block-policy return
>>  set state-policy floating
>>  pass in log quick proto udp from any to 10.10.10.1
port domain keep 
>> state
>>  block in log from any to 10.10.11.254
>>
>>  22:58:14.296303 rule 0/0(match): pass in on xl1:
10.10.11.254.32772 >
>>  10.10.10.1.53:  45616+[|domain]
>>  22:58:14.296965 rule 1/0(match): block in on xl0:
10.10.10.1.53 >
>>  10.10.11.254.32772:  45616*-[|domain]
>>
>
> States not only have address/port pairs in them (among
other things),
> but they also have a direction.
>
> The request packet (coming in on xl1) creates a state
that will match
> the following:
>
>   10.10.11.254:32772 ==> 10.10.10.1:53  (IN)
>   10.10.10.1:53          ==> 10.10.11.254:32772
(OUT)
>
> The same packet is filtered again on xl0, but notice it
will not match
> this state because its direction is now
"out".  As Daniel said, it's
> passed anyway because of the implicit pass rule at the
end of your
> ruleset (by the way this makes it difficult to
troubleshoot problems).
>
> Server receives packet and replies:
>
>   10.10.10.1:53 ==> 10.10.11.254:32772 (IN)
>
> Notice this will not match the state created above
(direction is IN,
> not OUT), and it will also be blocked by your second
rule.
>
> -Kian
>
> PS: You'd be smart to listen to Daniel's suggestions as
he wrote pf ;) 

_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On Wed, Feb 27, 2008 at 8:02 PM, Vadym Chepkov
<vchepkovgmail.com> wrote:
>  set block-policy return
>  set state-policy floating
>  pass in log quick proto udp from any to 10.10.10.1
port domain keep state
>  block in log from any to 10.10.11.254
>
>  22:58:14.296303 rule 0/0(match): pass in on xl1:
10.10.11.254.32772 >
>  10.10.10.1.53:  45616+[|domain]
>  22:58:14.296965 rule 1/0(match): block in on xl0:
10.10.10.1.53 >
>  10.10.11.254.32772:  45616*-[|domain]
>

States not only have address/port pairs in them (among other
things),
but they also have a direction.

The request packet (coming in on xl1) creates a state that
will match
the following:

   10.10.11.254:32772 ==> 10.10.10.1:53  (IN)
   10.10.10.1:53          ==> 10.10.11.254:32772 (OUT)

The same packet is filtered again on xl0, but notice it will
not match
this state because its direction is now "out".  As
Daniel said, it's
passed anyway because of the implicit pass rule at the end
of your
ruleset (by the way this makes it difficult to troubleshoot
problems).

Server receives packet and replies:

   10.10.10.1:53 ==> 10.10.11.254:32772 (IN)

Notice this will not match the state created above
(direction is IN,
not OUT), and it will also be blocked by your second rule.

-Kian

PS: You'd be smart to listen to Daniel's suggestions as he
wrote pf ;)
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On Thu, Feb 28, 2008 at 7:12 AM, Vadym Chepkov
<vchepkovgmail.com> wrote:
> It was not my intention to argue with anybody, I was
trying to understand
>  why the packet was blocked and reply to Daniel got
bounced, so I posted it
>  in the distro. I got it now, IN packet state doesn't
match IN packets, only
>  OUT. Thank you.
>

Glad that made sense.

http://undeadly.org/cgi?action=article&sid=2006
0928081238

Daniel's article from a while back explains it all really
well (see
"Debugging states").  The 2 other articles in that
series are equally
good.  Highly recommended.

-Kian
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"