Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
On 2014-02-13, Peter N. M. Hansteen pe...@bsdly.net wrote:
On Wed, Feb 12, 2014 at 09:18:09PM -0800, Scott Vanderbilt wrote:
This is running OpenBSD 5.5-beta on i386 (Jan. 22 snapshot).
5.5-beta has the new traffic shaping code in it, and there was an
irresolvable conflict over the 'queue' keyword.
In the general case I would say you could opt to switch over
to the new queues system (which requires a bit of man page reading
or waiting until the refreshed Book of PF that I'm working on comes out)
or for now do a simple search and replace to replace 'queue' with
'oldqueue' and keep most ALTQ setups intact until you have read up on
the new system a bit. But seeing that you use only priorities, you could
skip the queueing for now and just use the priorities that we've
had since OpenBSD 5.0.
This means, ditch this part
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri on $ext_if priority 7
queue q_def on $ext_if priority 1 priq(default)
and replace this with
match out on $ext_if from $localnet nat-to ($ext_if) queue (q_def, q_pri )
something like
match out on $ext_if from $localnet nat-to ($ext_if) set prio (3, 6)
(the default priority is 3, do the two-priority trick with priorities only,
no queues necessary)
This is quite a different rule; the old one limits outgoing bandwidth to
100Kb/s and _within that 100Kb/s_ it prioritizes certain traffic. This
suggested replacement isn't throttling the packets going out of the
interface at all, so unless there's a huge amount of data being sent, the
priorities aren't going to come into play. If this is the common case
of queueing on a firewall that's behind a modem connected to a WAN link
that is slower than the ethernet interface, you're just going to fill
the modem's buffers..
I'm not sure how set prio fits together with the new queueing code yet,
I've played a bit but don't have a good way to visualize the traffic
and get a good feel for how it works (I used to use ttt to get nice
live-updating graphs per-flow when testing queue configuration, but that
needs tkBLT which doesn't run with current Tk versions; everything else
I've found that can produce graphs useful for this is after-the-fact,
which makes it harder to see the effect of config changes on a live
network).
Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
Stuart Henderson s...@spacehopper.org writes: This is quite a different rule; the old one limits outgoing bandwidth to 100Kb/s and _within that 100Kb/s_ it prioritizes certain traffic. This suggested replacement isn't throttling the packets going out of the interface at all, so unless there's a huge amount of data being sent, the priorities aren't going to come into play. Priorities won't make much difference unless you're close to your actual bandwidth limit, certainly. In the fairly common case where actually available bandwidth is different (less than) your interface bandwidth, you probably want a queue setup in place with a defined upper limit to play with. I'm not sure how set prio fits together with the new queueing code yet, Well, the main difference is that in the new world priorities and queues are independent-ish. Queues serve to slice up your bandwidth into known-sized chunks (which may be flexible, hfsc-style), while priorities play within whatever limits are in place. You can get rather close to the queues with fixed priorities scheme by using both set queue and set prio in the same match or pass rule. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
On Wed, Feb 12, 2014 at 9:18 PM, Scott Vanderbilt li...@datagenic.com wrote: I am at my wits' end trying to figure out why I keep getting syntax errors when loading the pf ruleset below. The rules worked fine until I started to add altq rules, in anticipation of adding VOIP service to the local network. I am following the example in Peter Hansteen's tutorial [1] and his Book of PF, more or less. When checking the rule set, pfctl issues syntax errors on the two lines which define my child queues (indented in ruleset below), and I am at a loss to figure what it finds objectionable. WHY DIDN'T YOU QUOTE THE ERROR OUTPUT? This is running OpenBSD 5.5-beta on i386 (Jan. 22 snapshot). The hardware is a Soekris 6501. So you're saying you're running -current, but haven't read http://www.openbsd.org/faq/current.html#20131012 ? Note: the 'queue' keyword should only be changed where it starts a line and not in the middle of the altq line...though you'll want to read pf.conf(5) and replace the altq line Real Soon Now... For those following along at home, here's how I did this: 1) copy provided pf.conf lines into a file /tmp/f 2) since the error message wasn't quoted by the original poster (HINT HINT HINT), run pfctl -f /tmp/f -nv to see if more info was present that the poster left out 3) hmm, darn. Add a blank line and rerun to verify it moves with the 'queue' line. 4) man pf.conf, search for 'queue'. scan some hits; search for 'altq' and get *no* hits. wait, what? 5) read current.html and search for 'altq' (No, really, those were the steps I performed.) Philip Guenther
Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
On Wed, Feb 12, 2014 at 09:18:09PM -0800, Scott Vanderbilt wrote:
This is running OpenBSD 5.5-beta on i386 (Jan. 22 snapshot).
5.5-beta has the new traffic shaping code in it, and there was an
irresolvable conflict over the 'queue' keyword.
In the general case I would say you could opt to switch over
to the new queues system (which requires a bit of man page reading
or waiting until the refreshed Book of PF that I'm working on comes out)
or for now do a simple search and replace to replace 'queue' with
'oldqueue' and keep most ALTQ setups intact until you have read up on
the new system a bit. But seeing that you use only priorities, you could
skip the queueing for now and just use the priorities that we've
had since OpenBSD 5.0.
This means, ditch this part
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri on $ext_if priority 7
queue q_def on $ext_if priority 1 priq(default)
and replace this with
match out on $ext_if from $localnet nat-to ($ext_if) queue (q_def, q_pri )
something like
match out on $ext_if from $localnet nat-to ($ext_if) set prio (3, 6)
(the default priority is 3, do the two-priority trick with priorities only,
no queues necessary)
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
Remember to set the evil bit on all malicious network traffic
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
