Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Jun 2008 22:34:14 -0700
From:      "Freddie Cash" <fjwcash@gmail.com>
To:        freebsd-net@freebsd.org
Subject:   Re: Understanding where dummynet fits into an ipfw ruleset
Message-ID:  <b269bc570806282234g3b9eaccdgeb85f70808f3357d@mail.gmail.com>
In-Reply-To: <Pine.BSF.3.96.1080628150610.4653B-100000@gaia.nimnet.asn.au>
References:  <C283B2D1-5193-4D32-8D38-9D72282F5876@mac.com> <Pine.BSF.3.96.1080628150610.4653B-100000@gaia.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 27, 2008 at 11:14 PM, Ian Smith <smithi@nimnet.asn.au> wrote:
> On Fri, 27 Jun 2008, Chuck Swiger wrote:
>  > On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote:
>  > [ ... ]
>  > >> If net.inet.ip.fw.one_pass is true, then you definitely want to
>  > >> apply your deny rules first, as once something matches a pipe
>  > >> rule, it's going to be passed.  The tradeoff is that the
>  > >> accounting/fairness of traffic is less accurate but the firewall
>  > >> ruleset runs faster...
>  > >
>  > > So, in this situation, the "allow" rules would be the queue rules?
>  > >
>  > > To add traffic shaping to the following, using one_pass=1:
>  > >  100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0
>  > >  200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1
>  > >  300 deny ip from any to 2.2.2.2 in recv em0
>  > >
>  > > Would be:
>  > >  100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0
>  > >  200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1
>  > >  300 deny ip from any to 2.2.2.2 in recv em0
>  > >
>  > > Or am I way off here?  :)
>  >
>  > Hmm.  If you have one_pass set, I believe that rule 200 would become
>  > superfluous.  If it was off, rule 200 would be needed to permit
>  > traffic through.

No, the rule is needed.  Packets passing through the firewall go
through the ruleset twice:  once entering the external interface, and
again leaving the internal interface (and vice versa).

The first rule allows the packet in on the external interface, the
second rule allows it out the internal interface, the third rule
denies all other incoming traffic.

> I'm keen to be certain about this myself.  I think that one_pass only
> affects the packet on the current pass, in this case on the incoming
> pass from ip_input at rule 100 above.  So if one_pass is set, the packet
> is queued (and accepted in) and the search terminates, but with one_pass
> off, the packet is reinjected at rule 200 when it leaves the pipe after
> its limitation and/or delay, and would need to be specifically allowed.
>
> However I don't think that affects the outgoing pass, ie after routing
> the packet still has to go through the firewall again (from ip_output),
> so in this case it will be allowed if it's going out to 2.2.2.2 via em1,
> else is denied at rule 300.
>
> Another option might be to only apply pipe/queue actions to 'out' rules,
> but mixing that with both 1:many and 1:1 NAT will complicate matters ..



>  > However, queue rulesets are used to classify traffic
>  > into different bins; then then get pulled out of the bins with packets
>  > waiting is proportion to the weights configured via something like:
>  >
>  >    ipfw queue 1 config pipe 1 weight 10
>  >
>  > ie, you have to attach queue(s) to a pipe for this classification or
>  > sorting to be meaningful.

Yes, I know that.  I was just trying to use very simplified examples
to understand how the traffic shaping works in conjunction with the
packet filtering.  I understand how the queueing works, and have used
it successfully on routers that don't do packet filtering.  It's
adding it to existing packet filter rulesets that is making my head
spin.  :)

> Yes I suspect Freddie might want to use pipe rather than queue here too,
> if just for bandwidth limitation rather than weighted queueing by type
> of traffic?  And is it only wanted for managing the inbound traffic?

No, I want to use queue.  I want to create rules to "reserve"
bandwidth for connections to important servers, as we're moving to
more web-based applications, and I want to make sure students surfing
the web don't impact office staff.  There will be a single pipe, with
two queues, one weighted at twice the value of the other.  That way,
if there is no staff traffic, the students get the whole pipe.  If
there is no student traffic, staff get the whole pipe.  And if there's
a mix, then staff traffic is prioritised ahead of student traffic.

-- 
Freddie Cash
fjwcash@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b269bc570806282234g3b9eaccdgeb85f70808f3357d>