pf behavior question

[Matthew Seaman]

On 16/07/2010 18:22:04, Mario Lobo wrote:
> Hi;
> 
> System: 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Fri Jun 11 09:41:37 BRT 2010 
> i386
> 
> The question is about how pf acts on an specific situation.
> 
> Supose I have the following rules:
> 
> 
> pass in log inet proto tcp from $int_if to any port 8021  
> flags S/SA keep state tag test
> 
> rule 2 ....
> rule 3 .....
> .
> rule n ....
> 
> pass in log quick on $int_if inet proto tcp tagged test keep state queue (ftp)
> 
> 
> Suppose the packet matches the first rule.
> 
> According to what I red about pf, it will keep parsing the rules (no "quick" 
> on the first rule). When it reaches the last rule, the tag will match and the 
> packet will pass.
> 
> I don't believe I'll have 2 state table entries for the same packet after the 
> last rule matches. or will I? 
> 
> What is the proper way to use the tag created on the first rule, as far as the   
> state table is concerned?


Correct, essentially.

No, you won't end up with two entries in the state table from this --
it's only the last matching rule that causes the state table to be
modified.  In fact, you simply can't have two state table entries for
the same (i/f, proto, srcaddr, srcport, destaddr, destport) tuple,
because those six quantities are together used as the index into the
state table.  (Note: i/f is usually 'all' unless you've 'set
state-policy if-bound' or equivalent, so generating state on one
interface allows a packet to pass on any interface.)

You don't get much from using tagging in the case you show -- as you've
only got one rule to apply tags you might as well have let that been the
place where you decided to pass or block the packet.  Tagging is a lot
more useful where you need several different rules to identify a
particular class of traffic: you can apply the tag from several
different matching rules, and then have just one rule to express your
policy for that class of traffic.  See the example in
http://www.openbsd.org/faq/pf/tagging.html which gives a pretty good
idea how it all works.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100716/35350ad6/signature.pgp