Date: Fri, 16 Jul 2010 18:24:23 +0000 From: Mario Lobo <mlobo@digiart.art.br> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: pf behavior question Message-ID: <201007161824.24088.mlobo@digiart.art.br> In-Reply-To: <4C40C7F7.4080005@infracaninophile.co.uk> References: <201007161722.04902.mlobo@digiart.art.br> <4C40C7F7.4080005@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 16 July 2010 20:58:31 Matthew Seaman wrote: > 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.) > Ok. That confirms my suspicions. > 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. > I think that my case applies to that exactly Take the following excerpt from my pf.conf: I tag the packets on their way in from lan. The ports are queued on their way out, prioritizing the ports accordingly. The tag "ftp_proxy" is put there by the ftp-proxy program, which is why this question came up. I want ftp packets to have the lowest priority, so allowing ftp-proxy to tag them, I can direct them to any queue I want on their way in or out. ftp-proxy insert these rules (real example): @0 pass in log inet proto tcp from 172.16.3.145 to 129.128.5.191 port = 61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0 @1 pass out log inet proto tcp from 189.12.120.11 to 129.128.5.191 port = 61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0 look at the outlined pass out rule bellow. These 2 rules will match but parsing continues until they reach the pass out rule, where I queue them where I want. At least that the idea. I am using if-bound and I have altq on both lan_if and ext_if. Allow_tcp_ports_lan = "{21, 53, 67, 68, 80, 443, 143, 445, 587, 995, 1433, 1863, 110, 3000, 5061, 1723, 3389, 8933, 135}" Allow_tcp_ports_lab = "{53, 80, 443, 3389}" # from LAN ----------- pass in log quick on $lan_if inet proto tcp from $lan_if:network to !$lan_if port $Allow_tcp_ports_lan keep state tag to_out pass in log quick on $lan_if inet proto udp from $lan_if:network to !$lan_if port $Allow_udp_ports_lan keep state tag to_out # To INTERNET---------------------------------------------------------- pass out log quick on $ext_if inet proto tcp from any to any port 8933 tagged to_out modulate state queue (ssh_bulk, ack) pass out log quick on $ext_if inet proto tcp from any to any port pptp tagged to_out modulate state queue (ssh_bulk, ack) pass out log quick on $ext_if inet proto tcp from any to any port ssh tagged to_out modulate state queue (ssh_bulk, ssh_login) pass out log quick on $ext_if inet proto tcp from any to any port smtp tagged to_out modulate state queue (mail, ack) pass out log quick on $ext_if inet proto tcp from any to any port http tagged to_out modulate state queue (web) pass out log quick on $ext_if inet proto tcp from any to any port https tagged to_out modulate state queue (web) pass out log quick on $ext_if inet proto tcp from any to any port 444 tagged to_out modulate state queue (web) pass out log quick on $ext_if inet proto tcp from any to any port 81 tagged to_out modulate state queue (web) pass out log quick on $ext_if inet proto tcp from any to any port 82 tagged to_out modulate state queue (web) pass out log quick on $ext_if inet proto tcp from any to any port domain tagged to_out modulate state queue (dns, ack) pass out log quick on $ext_if inet proto udp from any to any port domain tagged to_out keep state queue (dns) -------------------------------------------------- pass out log quick on $ext_if inet proto tcp tagged ftp_proxy modulate state queue (ftp) -------------------------------------------------- pass out log quick on $ext_if inet proto tcp tagged to_out modulate state queue (bulk) pass out log quick on $ext_if inet proto udp tagged to_out modulate state queue (bulk) pass out log quick on $ext_if inet proto icmp tagged to_out modulate state queue (dns) -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winfoes FREE)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007161824.24088.mlobo>