Date: Wed, 27 Aug 2008 21:57:11 +0200 From: Max Laier <max@love2party.net> To: freebsd-pf@freebsd.org Subject: Re: ALTQ and shaping an existing session Message-ID: <200808272157.11585.max@love2party.net> In-Reply-To: <20080827192938.GA1711@icarus.home.lan> References: <64de5c8b0808270347p2d8cf9ccydd63cae3b1ea6a14@mail.gmail.com> <1219864968.1536.14.camel@manwe.buchtikov.borsice.sfn> <20080827192938.GA1711@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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=ED??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 "pf= ctl=20 =2Dk" mechanism, though. In a nutshell every state maintains a reference t= o the=20 rule it was created by (it's parent). The ALTQ queues used by that state c= ome=20 directly from that parent (i.e. the state doesn't store them). If we could= =20 modify the "pfctl -k" mechanism to move a state from one rule to another, t= he=20 ALTQ definitions would change accordingly. I yet have to check how much wo= rk=20 that would be or if there are any problems with the basic idea, but since=20 there is a 3 byte hole in pfioc_state_kill this could even be MFCed. I'll= =20 have a look. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808272157.11585.max>