Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Jun 2008 15:01:18 -0700
From:      "Freddie Cash" <fjwcash@gmail.com>
To:        freebsd-net@freebsd.org
Subject:   Re: Understanding where dummynet fits into an ipfw ruleset
Message-ID:  <b269bc570806271501if8ba221qf76b15d56e94e45b@mail.gmail.com>
In-Reply-To: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com>
References:  <b269bc570806271301x3ed43e54k5de0a1d71a9eb676@mail.gmail.com> <58383628-3A79-4271-B62D-C35CC06618F0@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 27, 2008 at 2:37 PM, Chuck Swiger <cswiger@mac.com> wrote:
> On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote:
>> Mainly, I'm wondering where to put the "ipfw queue" rules (the ones
>> that send the packets to dummynet), in relation to the packet
>> filtering rules, or if it even matters.
>>
>> For instance, do the queue rules apply to all the rules in the set, or
>> only to rules that follow after the queue rules (numerically)?
>
> That pretty depends on whether net.inet.ip.fw.one_pass sysctl is set:

[snip man page snippet]

>> Would I put the queue rules at the start of the ruleset or the end?
>> Or in the middle, just above the rules for the workstations?  Do I add
>> them after all the bad packet checks and general deny rules that are
>> at the top of the ruleset?
>>
>> Just wondering how the queue rules interact with the general packet
>> filter rules, since they can have the same parameters.
>
> It's reasonable to place the dummynet queue and pipe statements immediately
> after anti-spoofing checks, if net.inet.ip.fw.one_pass is false; that way,
> all traffic is shaped, including stuff that is later blocked by other IPFW
> statements.  Since the inbound traffic has already passed through your
> external link(s) anyway, you might as well acknowledge that it has.

Makes sense.  That's the bit that was messing me up (one_pass).  I'm
still working my head around how it (one_pass) integrates with all the
rest (divert/natd, fwd, dummynet) in a single ruleset.

Looking at sysctl output on a handful of systems, some of our
firewalls has one_pass enabled, others don't.  That's probably what's
been tripping me up, as sometimes a ruleset worked, other times it
didn't, depending on the FreeBSD release (4.x, 6.x, 7.x) the firewall
started with.

It's only recently that I've started standardising settings across
firewalls with standard hardware configs, generic rc.conf/sysctl.conf,
specific rc.conf.local, and so on.  Which is why I'm asking.

> 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?  :)

-- 
Freddie Cash
fjwcash@gmail.com



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