Re: PF and outgoing traffic

[jared r r spiegel <jrrs@ice-nine.org>]

On Wed, Jul 02, 2003 at 04:59:34PM +0200, Bc. Radek Krejca wrote:
> 
>   That is true, but if client downloads data, the traffic is outgoing
>   from int card. If client sends data, the traffic is outgoing from
>   ext card, can I use it and how?
> 

  i think i just abandonned a pf.conf which had a lot of time invested
  in it due to a perception i had about this it seemed to me that 
  i could not have my cake and eat it too, with respect to both A)
  being able to limit outgoing on $ext_if ( for purposes of limiting
  client send rate ) *and* limit outgoing data on $int_if ( for purposes
  of limiting client receive rate ); *and* do this all statefully.

  it's clear to see that limiting client send rate is easy, so take
  the example of robert doing an http download.

  you could say:

pass out on wi0 from any port 80 to $net_robert keep state queue robert 
 
  which should queue that xfer on over to robert's LAN block, and queue it
  too. ...  but it seemed to me that it actually would not; as the packets
  coming from the webserver back to robert's PC would not match that rule, 
  as they would already have matched a rule earlier where the outgoing 
  connection from robert's PC to that webserver was 'pass'ed and state was
  kept - therefore being subject to robert's upload queue.

  in speaking about this with a friend of mine last night, we believe this
  kind of up- and download rate queueing is indeed possible - provided there
  are two boxes running pf inline with one another.

  as in:

current scenario could be:

[internet] -- uplink -- [openbsd box] -- lan

"solution scenario" (hehe.. solution... ) could be:

[internet] -- uplink -- [openbsd box 1] -- [openbsd box 2] -- lan

  then we had some great idea, but my mind is drawing a blank...  

  maybe it was that 'box 2' was not stateful, and very loose-ruled -- as in
  not so much using pf as a "firewall" but more as a queuer...  

  you still have no control over the link saturation with respect to what
  henning brought up; but you might be able to juggle things up a bit and
  get closer to success like that...

  but enough poorly-though-out / undereducated babble from me.

  suffice it to say i had the impression that the biggest kryptonite to
  being able to use one pf box to discretely queue both
  outgoing-from-lan and incoming-to-lan data was the stateful nature of the
  initial outgoing-from-lan connection.

  jared

-- 
[ openbsd 3.3 current/GENERIC ( jun 28 ) // i386 ]