ALTQ and shaping an existing session

Max Laier max at love2party.net
Wed Aug 27 19:57:14 UTC 2008


On Wednesday 27 August 2008 21:29:38 Jeremy Chadwick wrote:
> On Wed, Aug 27, 2008 at 09:22:48PM +0200, Michal Buchtik wrote:
> > Rajkumar S pí??e v st 27. 08. 2008 v 16:17 +0530:
> > > The problem is that even when a new ip is added to or removed from
> > > <badguys> already existing sessions from the newly added ip continues
> > > to have previous shaping configuration. All new sessions are shaped as
> > > expected. I have tried rules without "keep state", but results are the
> > > same. Is  this the expected behavior of pf? Can the shaping be
> > > performed for existing sessions also when an ip is added to <badguys>?
> >
> > I have same problem. The only way I found is kill existing states of
> > affected ip's. But this is uncomfortable for users. Is there another
> > solution?
>
> It sounds like the root of this problem is that "flags S/SA" is implicit
> on RELENG_7 for TCP rules.  "keep state" is also implicit (on TCP, UDP,
> and ICMP rules).
>
> The only solutions I see, both of which have consequences:
>
> 1) Use "flags any", but this *is not* something you would want to use in
> conjunction with "keep state", since you only want to cause pf to begin
> tracking state when SYN of SYN+ACK is set, and not on FIN, RST, or other
> combinations.  There is probably some combination of rules you could set
> up which could utilise "flags any" correctly, but the risks are high.
>
> 2) Add "no state" to rules you want shaping to occur on.  This has the
> added drawback of pf not being able to keep track of state on such
> packets (performance hit), and you'll need to tune your pf rules to
> match on traffic going both directions (since there's no longer a state
> kept)
>
> Max, does this sound correct?

Yes, about right.  There might be a way to solve this by hacking up the "pfctl 
-k" mechanism, though.  In a nutshell every state maintains a reference to the 
rule it was created by (it's parent).  The ALTQ queues used by that state come 
directly from that parent (i.e. the state doesn't store them).  If we could 
modify the "pfctl -k" mechanism to move a state from one rule to another, the 
ALTQ definitions would change accordingly.  I yet have to check how much work 
that would be or if there are any problems with the basic idea, but since 
there is a 3 byte hole in pfioc_state_kill this could even be MFCed.  I'll 
have a look.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News


More information about the freebsd-pf mailing list