On Tue, Mar 10, 2009 at 9:16 PM, Leonardo Rodrigues <leonardov...@gmail.com> wrote: > Hi everyone, > > I'm trying to build a PF / ALTQ ruleset that handles traffic between 3 > internal interfaces and 1 external, so that the internal interfaces > can have different priorities on the available bandwidth they can get > from the external interface. I don't know if that's possible with only > ALTQ rules, or if I'll have to use tagging, so I'm trying to > understand some simple setups before. > > While reading the example #2 on the PF user's guide > (http://www.openbsd.org/faq/pf/queueing.html#example2), I came across > the following ruleset: > > > boss = "192.168.0.200" > ... > altq on fxp0 cbq bandwidth 1.5Mb queue { std_ext, www_ext, boss_ext } > ... > queue boss_ext bandwidth 500Kb priority 3 cbq(borrow) > ... > # filter rules for fxp0 outbound > pass out on fxp0 from $boss to any keep state queue boss_ext <<<------- > > > Where fxp0 is the external interface (internet). My question is about > that last rule above. Assuming that NAT is working so that the "boss" > is able to surf the web, and since NAT translations happen before the > filtering rules, then the rule above shouldn't work... right? The fxp0 > interface would be able to filter only on already translated addresses > (its own address), and not on unstranslated addresses, like > 192.168.200, which is the "boss" IP, on a different subnet. Would a > rule like that work?
No. Without looking at the actual example, I can say that your understanding of NAT/filter interaction is correct and this will not work. > If that setup works, I might be able to implement my original idea, by > doing something like: > pass out on fxp0 from 192.168.0.5 to any keep state queue traffic1_ext > pass out on fxp0 from 192.168.2.5 to any keep state queue traffic2_ext > pass out on fxp0 from 192.168.5.5 to any keep state queue traffic3_ext > > Thanks for any ideas =) > > Leonardo Rodrigues Bear in mind that while a queue is applied to the egress interface, the classification of that traffic may take place on another interface. So you could do something more like this: pass from 192.168.0.5 to ! <mynet> keep state queue traffic1_ext Or use tagging to avoid maintaining a table of your own networks. -HKS
