Re: Need help with queuing

From: endus (dont_at_email.invalid)
Date: 12/08/03 

Date: Mon, 08 Dec 2003 13:55:19 -0500

On 05 Dec 2003 19:45:48 GMT, Daniel Hartmeier <daniel@benzedrine.cx>
wrote:

>You need to first (before the pass rules) define the queues,
>as in

Yes, sorry, I just clipped those out for simplicity's sake. Those are
definitely in there in the real pf.conf though.

>You don't have to specify two, one is enough. If you specify
>two, the second one is used for empty ACKs and ToS low-delay
>(like interactive ssh). If only one is specified, everything
>matching the rule goes into that queue.

That makes sense.

>The rule only matches SYNs, yes. But when a matching SYN creates
>state, the queue parameters of the pass rule are noted in the
>state entry, and all further packets of the connection (matching
>the state entry, not the pass rule anymore) will be assigned
>to those queues as well. And, yes, empty ACKs part of the
>connection will go to the second queue specified in the pass rule.

Got it...this is all making MUCH more sense to me now.

>
>> "pass in on $ext_if proto tcp from any to $ext_if flags S/SA \
>> keep state queue (q_def, q_pri)
>> ...
>> Huh? Isn't that rule just blowing a huge hole in the firewall
>> allowing all S/SA packets in? And how does that rule specify anything
>> about ToS lowdelay?
>
>Yes, it's allowing all TCP connections in. It's meant to
>demonstrate the syntax and semantics of queueing, not a
>secure ruleset.

That's what I thought. Now that I get the syntax of the queing that
is much more obvious!

>ToS (type of service) is an attribute an application can set
>on packets it sends. Either 'throughput' or 'low-delay' can
>be chosen. For instance, ssh will use low-delay for interactive
>sessions (as the latency is more important than throughput).
>
>pf will assign empty ACKs and packets with ToS low-delay to
>the second queue specified in the matching pass rule, if there
>are two queues specified. Otherwise all matching packets go
>to the single queue specified. There's no deep meaning hidden
>there, this is just hardcoded behaviour specific to pf,
>empty ACKs and ToS low-delay go to the second queue.

This makes much more sense to me now. I will defiitely specify the
second queue on all of my pass rules so that empty acks are always
prioritized. Man, it's like they designed it this way for a REASON!
=]

>A queue defined on one interface affects outgoing packets
>on that interface. So, a queue on the internal interface can
>throttle traffic flowing to the local workstations (throttling
>downloads).
>
>If you want to throttle uploads (packets flowing from the
>firewall to the Internet), you obviously need to use queues
>on the external interface.

Okay, so I will have to alter the example's rules to work on the
external interface. I am less worried about downloads than uploads
thanks to 5 meg cable.

>The best approach, IMO, is to just try it, then fix until
>it works as desired or back it out. Preparing the perfect
>ruleset offline and loading it a single time rarely works.

Absolutely...beleive me I have spent plenty of time getting my ruleset
right...I'm sure this queueing will involve plenty of pfctl -f
/etc/pf.conf's before I get it right.

>Start with a simple queue setup on one interface, and learn
>to use pfctl -vvsq etc. to check how packets are assigned
>to queues. Try uploads and downloads, verifying what effects
>queueing has. Once that works, add more queues or use more
>complicated schedulers. :)
>
>Connections tunneled over SSH will all go into the same
>queue as non-interactive SSH, i.e. if two different
>connections are tunneled over the same SSH session, there's
>no way to queue them differently.

Hmm...so that means that the interactive SSH packets...i.e. the stuff
I type into SSH will be prioritized into the second queue specified on
the SSH pass rule, while the tunneled traffic will be put into the
first? That might actually be all I need other than maybe splitting
the SSH pass rules into host based rules to queue differently based on
who is conencting. That should work great!

Thanks a TON for your help, this makes much much much more sense to me
now...I know enough to start experiementing which is exactly what I
needed. THANKS!

>
>Daniel 

-- 
endus at the domain endus dot com
Let us visualize the secure man; and by this term, I mean
a man who has settled for financial and personal security
for his goal in life...His ideas and ideals are those of
society in general and he is accepted as a respectable,
but average and prosaic man.  But is he a man?  Has he 
any self-respect or pride in himself?  How could he, when
he has risked nothing and gained nothing...How does he feel
when he realizes that he has barely tasted the meal of life;
when he sees the prison he has made for himself in pursuit
of the almighty dollar?  If he thinks this is all well and
good, fine, but think of the tragedy of a man who has sacrificed
his freedom on the altar of security, and wishes he could turn 
back the hands of time.  A man is to be pitied who lacked the 
courage to accept the challenge of freedom and depart from the 
cushion of security and see life as it is instead of living it
second-hand.  - Hunter S. Thompson, The Proud Highway

Relevant Pages

  • Pfs borrowing
    ... I've been readin up on OBSD's pf and have seen that it supports two ... I would like to define one queue for my complete bandwidth, ... This is queue SSH ...
    (freebsd-net)
  • pf/altq prioritisation (for ssh).
    ... I want to use pf/altq to give ssh a high priority so I don't get lagged ... queue ssh priority 15 priq ... Without the 5.3 miniinst ISO downloading a SSH connection is perfect (no ...
    (freebsd-questions)
  • Re: SSH feature suggestion - inverse connection multiplexing
    ... layer and multiple instances of the transport layer. ... of SSH tunnels)? ... queue, which is pretty much what you'd need to do inside this proposed ssh ...
    (comp.security.ssh)
  • Re: SSH permits root-Logins with wrong password
    ... > If I try to use 'x' as wrong password, ssh won't let me in: ... HTH. ... | active wait queue - shoot Andy"); ...
    (Debian-User)
  • Re: How does bandwidth work?
    ... connections are blocked. ... the download rate is restricted, ... These are small, but important, and if you already have a lot of upwards packets from bittorrent, these packets end up at the back of the queue. ...
    (comp.os.linux.networking)