Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Apr 2008 23:39:10 -0700
From:      Jeremy Chadwick <koitsu@freebsd.org>
To:        Diego Salvador <salvador_d13@yahoo.com.ph>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: PF and State Table
Message-ID:  <20080402063910.GA36819@eos.sc1.parodius.com>
In-Reply-To: <88224.68960.qm@web57401.mail.re1.yahoo.com>
References:  <88224.68960.qm@web57401.mail.re1.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 01, 2008 at 10:26:18PM -0700, Diego Salvador wrote:
> Hi! Can someone explain the details on how PF state table stores stateful filtering option of "keep state" because I know this will be used and applied to TCP, UDP and ICMP/ICMPv6 protocols for stateful filtering. Because when I use this "keep state" option, it is said that it can help in optimizing firewall rules due to rule evaluation will no longer be evaluated when those information are already stored in the table. Is it only IP address (source->destination or destination->source) are being keep in the state table? If it is then does it matter on IP address source-destination direction entries? What about with TCP and its flags? How does PF stored it in the state table? Is there any varying performance if we should specify TCP flags with keep state as compared to TCP with keep state but without flags? For example,
> 
> pass in on $ext_if inet proto TCP from any to 192.168.100.1 keep state 
> pass in on $ext_if inet proto TCP from any to 192.168.100.1 keep state flags S/SA

I think what you're asking is how pf actually keeps track of state, and
how pf rules define when to start tracking state.

Looking at the above two rules you provided, the rule #1 would cause any
inbound TCP packets destined to 192.168.100.1 to cause pf to begin
tracking state -- that means, any TCP packet, with any TCP flags set
(including bogus packets which might set FIN+PSH at the same time, or
other oddities).  This is somewhat risky, because you really don't want
to waste a state entry on something that's half-way in the middle of a
TCP session (well, I suppose you could, but it seems insecure.  You
should track state from the point of an initial connection to the end of
it -- see below).

Rule #2, however, would do the same thing -- except would only begin
tracking state when TCP SYN is seen (and only looking at the SYN and ACK
flags in the TCP header).  This is more along the lines of what you
want.

The state tracking stuff actually causes pf to monitor each state of a
TCP session, ensuring that responses to certain TCP states (that the
sender or receiver has sent/received) are correct -- and simultaneously
uses the state table to permit packets through.

Neither of those rules, however, handle state for UDP or ICMP.  They're
stateless protocols, but pf does keep track of when the UDP connection
closes (or times out after a while), and the same with ICMP.

> What file in PF on FreeBSD kernel does state table structure is located?

I don't understand this question.

-- 
| Jeremy Chadwick                                    jdc at parodius.com |
| Parodius Networking                           http://www.parodius.com/ |
| UNIX Systems Administrator                      Mountain View, CA, USA |
| Making life hard for others since 1977.                  PGP: 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080402063910.GA36819>