Re: maximum deny entries?
On Tue, September 12, 2006 5:40 pm, Jin Guojun [VFFS] wrote: > I am not sure if this is a bug or is there some limitation for total > deny entry, when the deny list exceeds a certain length (36 lines at > this case), ipfw stop working (see the *** line below). > > This is on 6.1-R i386 platform. > Is there know problem on this issue? or Did I made some mistake? > > Please CC to me since I am not on the list. Works fine here, with 62 deny rules out of 533 rules in total. While not every deny rule has a matched packet so far, the rules under them all work fine. Freddie Cash [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: maximum deny entries?
On Tue, September 12, 2006 5:40 pm, Jin Guojun [VFFS] wrote: > I am not sure if this is a bug or is there some limitation for total > deny entry, when the deny list exceeds a certain length (36 lines at > this case), ipfw stop working (see the *** line below). > > This is on 6.1-R i386 platform. > Is there know problem on this issue? or Did I made some mistake? > > Please CC to me since I am not on the list. Works fine here, with 62 deny rules out of 533 rules in total. While not every deny rule has a matched packet so far, the rules under them all work fine. FreeBSD 6.1-p6, i386 (P2 333 MHz box). Freddie Cash [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW update frequency
On Friday 30 March 2007 01:40 pm, Julian Elischer wrote: > I have been looking at the IPFW code recently, especially > with respect to locking. > There are some things that could be done to improve IPFW's > behaviour when processing packets, but some of these take a > toll (there is always a toll) on the 'updating' side of things. > > For example. I can make IPFW lock-free during processing > of packets (i.e. not holding any locks while traversing the > list) which would solve problems we have with lock-order reversals > when it needs to look at the socket layer (which needs socket > layer locks). Unfortunatly this would make it a lot more expensive > in the case where new rules are being added to the list. possibly a LOT > more expensive. Now, this would only matter if one was adding (or > deleting) hundreds of rules per second to the firewall, but as I've > discovered, there's always SOMEONE that is doing the very thing you > imagine that no-one would ever do. > > In my imagination, most of the people who did this sort of thing don't > need to do it any more as tables obviate the need for that sort of > thing. > > Is there anyone out there who is adding hundreds (or even dozens) of > rules per second on a continuous basis, or who wants rule changing to > be a really efficient operation? > (does it matter to you if it takes a few milliSecs to add a rule?) If the initial loading of a ruleset via a script counts, then yes. We add 600+ rules each time the script is run. During testing, or when troubleshooting connection issues, the rules could be reloaded several times over 10 minutes. We've moved away from adding rules dynamically, preferring to add rules to the script and reload them all. Keeps the rules in memory in sync with the rules on disk. Otherwise, no. :) -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW update frequency
On Fri, March 30, 2007 4:45 pm, Julian Elischer wrote: > Freddie Cash wrote: >> On Friday 30 March 2007 01:40 pm, Julian Elischer wrote: >> >>> I have been looking at the IPFW code recently, especially >>> with respect to locking. There are some things that could be done >>> to improve IPFW's behaviour when processing packets, but some of >>> these take a toll (there is always a toll) on the 'updating' side >>> of things. >>> >>> For example. I can make IPFW lock-free during processing >>> of packets (i.e. not holding any locks while traversing the list) >>> which would solve problems we have with lock-order reversals when >>> it needs to look at the socket layer (which needs socket layer >>> locks). Unfortunatly this would make it a lot more expensive in >>> the case where new rules are being added to the list. possibly a >>> LOT >>> more expensive. Now, this would only matter if one was adding (or >>> deleting) hundreds of rules per second to the firewall, but as >>> I've >>> discovered, there's always SOMEONE that is doing the very thing >>> you imagine that no-one would ever do. >>> >>> In my imagination, most of the people who did this sort of thing >>> don't need to do it any more as tables obviate the need for that >>> sort of thing. >>> >>> Is there anyone out there who is adding hundreds (or even dozens) >>> of rules per second on a continuous basis, or who wants rule >>> changing to be a really efficient operation? (does it matter to you >>> if it takes a few milliSecs to add a rule?) >> >> If the initial loading of a ruleset via a script counts, then yes. >> We add >> 600+ rules each time the script is run. During testing, or when >> troubleshooting connection issues, the rules could be reloaded >> several times over 10 minutes. We've moved away from adding rules >> dynamically, preferring to add rules to the script and reload them >> all. Keeps the rules in memory in sync with the rules on disk. >> >> Otherwise, no. :) > > the new rules might take a second or two to load.. a load may take a > couple of milliseconds vs less than that for now. That won't adversely affect us, then. We use hostnames in a few rules, so there's a delay the first time the rules are loaded anyway. A second or two extra won't harm us. :) Freddie Cash [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW / if_bridge / NAT
On March 28, 2008 10:35 am Jay L. T. Cornwall wrote: > Hi, > > I have a FreeBSD 7.0 machine bridging two segments of a network: > > vr0 <---> bridge0 <---> vr1 > > bridge0 has both unregistered and public IP aliases. In addition to > bridging, I need the machine to perform NAT on packets originating from > an unregistered subnet (192.168.1.0/24) outbound on interface vr1 to a > public IP and back again. No NAT'ing should occur behind vr1. > > I initially tried to set this up with ipfw diverting packets to natd > like this: > divert natd any from any to any via vr1 > > This seemed to NAT packets outbound correctly, but the replies were > never NAT'd back to the private IPs. I believe the presence of the > bridge affects ipfw's ability to divert the appropriate packets. This > configuration partly works: > divert natd any from 192.168.1.0/24 to any > divert natd any from any to Have you tried restricting your rules to only the vr1 interfaces, with configured directly on vr1: divert natd ip from 192.168.1.0/24 to any out xmit vr1 divert natd ip from any to in recv vr1 -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw (dummynet) adds delay, but not configured to do so
On March 4, 2009 1:14 pm Luigi Rizzo wrote: > On Wed, Mar 04, 2009 at 10:05:53PM +0100, Sebastian Mellmann wrote: > > > On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote: > > > the delay that a packet experiences corresponds to len/bandwidth, > > > often rounded up to the next clock tick (1ms is the default). > > > You get one delay inbound, one delay outbound, so that's 2ms. > > > > Is there any chance to change this clock tick to a lower value? > > I think it's the 'HZ=' option in the kernel config isn't it? > > yes. i believe there is a tunable (so you don't need to rebuild > the kernel) but i do not remember exactly which one. kern.hz in /boot/loader.conf -- Freddie fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipfw (dummynet) adds delay, but not configured to do so
On March 4, 2009 11:17 pm Sebastian Mellmann wrote: > >> > Is there any chance to change this clock tick to a lower value? > >> > I think it's the 'HZ=' option in the kernel config isn't it? > >> > >> yes. i believe there is a tunable (so you don't need to rebuild > >> the kernel) but i do not remember exactly which one. > > > > kern.hz in /boot/loader.conf > > I only got an empty loader.conf file on my system. > > How is the syntax of the 'kern.hz' option? grep kern /boot/defaults/loader.conf: #kern.hz="100" # Set the kernel interval timer rate Thus, just add kern.hz=1000 into /boot/loader.conf to have it set at boot time. -- Freddie fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Does ipfw support interface groups?
On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote:
> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote:
>> can ipfw use somehow interface groups as pf(4) can?
>> From a quick glance at documentation and not so through look at code
>> it does not but i am sending this just if i missed something during my
>> search!
>
> something like
> ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ...
> is perhaps not so nice but does the job.
Seriously??!!
Luigi, you just made my day. :) Writing duplicate sets of rules for
multi-homed firewalls where the only thing that's different is the
incoming interface has been a pain ...
Thanks for the info!!
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Does ipfw support interface groups?
On Thu, May 21, 2009 at 9:41 AM, Steve Bertrand wrote:
> Freddie Cash wrote:
>> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote:
>>> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote:
>>>> can ipfw use somehow interface groups as pf(4) can?
>>>> From a quick glance at documentation and not so through look at code
>>>> it does not but i am sending this just if i missed something during my
>>>> search!
>>> something like
>>> Â Â Â Â ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ...
>>> is perhaps not so nice but does the job.
>>
>> Seriously??!!
>>
>> Luigi, you just made my day. :) Writing duplicate sets of rules for
>> multi-homed firewalls where the only thing that's different is the
>> incoming interface has been a pain ...
>
> Aside from Luigi's piece of trickery, if you are accustomed to making
> frequent changes to live rulesets (and then promptly
> forgetting/neglecting to add them into your startup scripts), might I
> recommend something that has become very useful to me:
>
> I have /etc/ipfw.rules which contains the variable definitions and all
> table configurations as my primary startup script. At the bottom of that
> file, I have:
>
> . /etc/ipfw.include
>
> This instructs the sh script to pick up the data from the ipfw.include
> file, and process it as well.
We do something similar, with a global config file with all the common
variables, tables, queues, etc; and a master script with the rules for
the firewall itself and the master NAT setup, which then pulls in
separate scripts for each 1-to-1 NAT for servers at the sites. We
make very heavy use of shell variables, tables, and the like.
> Instead of implementing the rules live, and then adding them into the
> startup script manually, I simply (from time-to-time) run this
> (copy/paste into CLI):
>
> ipfw list | \
> perl -nle 's/table\((\d+)\)/\"table($1)"/g; print "\$cmd $_";' \
>> /etc/ipfw.include
> chown root:wheel /etc/ipfw.include && chmod 400 /etc/ipfw.include
>
> That then makes a copy of your current live ruleset into your
> /etc/ipfw.include file, which will be loaded upon next reboot.
We do something similar every now and again to keep a backup of the
live rules, just in case. But it's only used to compare against the
live rules at a later date. Due to the heavy use of variables and
formatting in our scripts, there's no way we'd consider using this
output as an input script. :) It's hard enough to read the output of
ipfw when it's running ... I wouldn't want to have to wade through
that to add/update rules saved to a file. :)
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Does ipfw support interface groups?
On Thu, May 21, 2009 at 9:42 AM, Luigi Rizzo wrote:
> On Thu, May 21, 2009 at 08:49:30AM -0700, Freddie Cash wrote:
>> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote:
>> > On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote:
>> >> can ipfw use somehow interface groups as pf(4) can?
>> >> From a quick glance at documentation and not so through look at code
>> >> it does not but i am sending this just if i missed something during my
>> >> search!
>> >
>> > something like
>> > ?? ?? ?? ??... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ...
>> > is perhaps not so nice but does the job.
>>
>> Seriously??!!
>>
>> Luigi, you just made my day. :) Writing duplicate sets of rules for
>> multi-homed firewalls where the only thing that's different is the
>> incoming interface has been a pain ...
>
> you can always put multiple rules that check the variant part
> and skipto the common one
>
> ipfw add 100 skipto 2000 in recv xl1
> ipfw add 100 skipto 2000 in recv bge0
> ...
> ipfw add 100 count // interface not recognised
> ipfw add 2000 ... // do the common part
Skipto is very powerful, and we use it in some cases. But I try not
to use it very often, as it can lead to spaghetti rules that are hard
to follow. :) We have one firewall where it takes a good 10 minutes
to track the path a packet takes through the rulelist, as there are so
many skipto rules and multiple interfaces/vlans (it's scheduled for a
rewrite this summer).
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Does ipfw support interface groups?
On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote:
> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote:
>> can ipfw use somehow interface groups as pf(4) can?
>> >From a quick glance at documentation and not so through look at code
>> it does not but i am sending this just if i missed something during my
>> search!
>
> something like
>
> ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ...
> is perhaps not so nice but does the job.
Just tested this on one off our firewalls, and can report that it
works wonderfully.
Now to compress the rules a bit using this. :)
Thanks again, Luigi!!
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Rules processing in ipfw: processing ends with rule 65535 or first match?
Over the years, various how-tos and docs that I've read comparing ipfw to ipf and pf have categorised them as such: - ipf/pf compares the packet against every rule in the ruleset, and the last matching action is used once the end of the ruleset is reached (last-match-wins) - ipfw compares the packet against the rules, and stops processing the rulesset once a rule matches (first-match-wins) And, if one wants to get the ipfw behaviour in ipf/pf, they can use the "quick" keyword, which stops processing of the ruleset as soon as one of those rules matches. IOW, for a ruleset with 1000 rules, ipf/pf will scan every single rule for every single packet; and ipfw will only scan the ruleset up to the first matching rule. In theory, the ipfw method would be a lot faster, and less intensive. However, reading through the man page for ipfw(8) on FreeBSD 7.2, it lists the following (Description section): The packet passed to the firewall is compared against each of the rules in the firewall ruleset. When a match is found, the action corresponding to the matching rule is performed. And, later, in the Packet Flow section: Also note that each packet is always checked against the complete rule- set, irrespective of the place where the check occurs, or the source of the packet. These make it sound like ifpw processes the entire ruleset for every packet, regardless of when a match occurs. So, which is it? Is ipfw a first-match-wins and rule processing ends setup? Or does it check every single rule for every single packet? -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Rules processing in ipfw: processing ends with rule 65535 or first match?
Okay, so my understanding was (mostly) correct. Thanks for the extra info. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Matching all protocols in /etc/protocols (1 rule)
2009/8/4 Miroslav Chlastak > Hi all, > > it's possible to create one rule to pass (or disable) all traffic (all > protocols - from /etc/protocols)? > I know, that I can use "all" keyword. But this keyword "all" mean only > "tcp, udp, icmp" protocols. > But there is more then tcp, udp and icmp protocol (gre,esp,ospf,...). If I > can allow all of this protocols, so at the moment I have to create 134 rules > (1 rule for 1 protocol from /etc/protocols). > If this is for IPFW, just use "ip" or "any". That will match any IP packets, regardless of what protocol data is inside the packet. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipfw: install_state: entry already present, done
On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis wrote: > Haven't gotten any response on -questions so trying here. I've also opened > a PR (kern/139226) but it's gotten no replies so I figured I should try here > since I'm not certain if it's a bug or not. Regardless I am hoping for at > least a work-around -- a few extra rules or settings to keep my console from > being flooded by errors. So far only option I found is commenting out the > error display line in the kernel source which is far from optimal. > > I'm trying to setup a stateful firewall for my server such that any traffic > can go out, and it's reply come back -- a fairly typical workstation setup. > However I'm getting the error message "ipfw: install_state: entry already > present, done" repeated many times in my logs (tho the rules seemed to work > fine otherwise). > > I stripped down the rules to the minimum I could and discovered the line > causing it is "allow udp from me to any keep-state". > > Only seems to happen when I have bind running as a slave dns server (not > publicly listed, just the zone replication traffic causes the error) but I > assume any other large source of UDP traffic would also do it. > > Full firewall rules: > > dns2# ipfw list > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00400 allow udp from me to any keep-state > 65535 deny ip from any to any > > If you add "out xmit em0" to the udp rule, do the errors stop? -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Dansguardian, nat, & ipfw
On Mon, Nov 16, 2009 at 8:51 PM, Brian wrote: > Trying to configure my gateway box running FBSD 7.2 to provide content > filtering services for some or all clients on a my network. > > The box is configured with natd and running IPFW. I like this combination > and have been using it successfully for years. Not real interested to > changing to squid or pf or whatever else may be known (or better documented) > to work with dansguardian. Dansguardian does not do any pages fetches on its own, it just scans pages returned by a proxy server. You cannot run Dansguardian without some kind of web proxy server. By default, the port will install Squid, but it has been shown to work with TinyProxy. > Dansguardian seems to be the preferred option for content filtering as near > as I can tell. There is lots of documentation out there for configuring > dans with squid. I can't find much of anything for IPFW / NAT > > So, the question is, can this be done? I've seen one or two suggestions out > there giving a brief description of how to use the fwd command to send > packets to dans but unfortunately I am not smart enough to implement that > here. You can use IPFW to fwd packet to Dansguardian quite easily: ipfw add fwd 127.0.0.1:8080 tcp from $local_subnet to any 80 in recv $local_nic ipfw add allow tcp from me to any 80 out xmit $public_nic ipfw add allow tcp from any 80 to me in recv $public_nic established The first rule redirects all HTTP traffic from the local subnet to Dansguardian. Dansguardian will then pass the packets off to a local install of Squid (uses 127.0.0.1:3128 by default). Squid will then connect out to the remote web server to grab the pages (the next two rules). You *MUST* have a web proxy server installed somewhere, that Dansguardian will forward the requests to, and receive the responses from. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Unified rc.firewall ipfw me/me6 issue
On Thu, Dec 17, 2009 at 3:45 PM, Max Laier wrote:
> On Thursday 17 December 2009 08:20:47 David Horn wrote:
> > Thanks for working on rc.firewall, as the old scenario of dualing
> > rc.firewall/rc.firewall6 was not easily used in the default
> configurations
> > when running dual stack. The new rc.firewall has some very decent sane
> > defaults. My testing so far as been concentrated on
> > firewall_type="client", dual stack v4/v6 with SLAAC for IPv6, and DHCP
> for
> > IPv4. I will try some of the IPv6 tunnel scenarios later.
> >
> > I ran some tests against the now committed to -current /etc/rc.firewall,
> > and think have found an issue. In every line that has the "me" token
> > without the equivalent "me6" token, the command is only taking affect
> for
> > ipv4.
> >
> > For example:
> >
> > ${fwcmd} add pass udp from me to any 53 keep-state
> >
> > will allow dns requests from the client to pass, but if the destination
> > host is ipv6, this rule does not work. Instead you need:
> >
> > ${fwcmd} add pass udp from { me or me6 } to any 53 keep-state
> >
> > The same issue exists for several other entries as well. (possible diff
> > attached) The other option is to modify ipfw to actually have three
> > different "me" tokens (me/me4/me6) where the new "me" token would match
> > both ipv4 and ipv6 local interface addresses. Currently "me" matches
> only
> > ipv4 addresses on my amd64 -current box.
>
> The problem with this approach is and has been that it would change the
> meaning of "me". IIRC, it was considered a POLA violation to do that back
> when the IPv6 functionality was merged. An alternative would be to
> introduce a
> new name for me when we don't care which address family - e.g. me_any,
> mine,
> me64, me12, ... pick your color.
>
> But it doesn't change the meaning of "me". "me" is any IP address
configured on any interface. In that sense, there shouldn't be any
differentiation between IPv4 and IPv6, since both are IP.
If we wanted to be pedantic and keep things consistent, then why isn't there
an "any6" keyword? ;)
"me" should be any IP address configured on any interface, regardless of IP
version.
"me4" should be any IPv4 address configured on any interface.
"me6" should be any IPv6 address configured on any interface.
Having just "me" and "me6" is inconsistent and illogical, Jim. ;)
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: rule 00000.
2010/4/6 Erich Jenkins, Fuujin Group Ltd > Pawel Tyll wrote: > >> Unfortunately FreeBSD 8.0-STABLE #0: Mon Apr 5 08:43:58 CEST 2010 >> still has problems. >> >> ipfw show: >> (...) >> 65534 44262253 27617819701 allow ip from any to any >> 1 5335 405460 allow ip from me to any dst-port 123 >> 00 0 ip from any to any >> >> Anything I can do to help? >> > > Pawel: > > My skin crawled the moment I read this post. Could you provide a bit more > information about this issue? I manage a very large deployment of FreeBSD > boxes which are geographically dispersed, and we've started upgrading them > to the 8.0 release. My default policy is to deny everything but the services > running, so I generally end with a "deny all" statement, and the last thing > I want is to lock myself out and have to dispatch a technician... > > Is this problem localized to any particular architecture? (we have sparc64, > amd64 and i386 servers deployed). Is this just the stable branch that's > affected, or was this bug also in the ISO release? (I deploy via > NFS/FTP/bootp from internal servers hosting the ISO images). > > If you read the archives of this list, you'll find that this issue only applies to 8-STABLE after the 8.0 release. Thus, if you upgrade to 8.0-RELEASE, you will not run into this problem. Luigi is doing a bunch of cleanups, refactoring, and updates to the ipfw code in 8-STABLE/9-CURRENT. Things are a bit unstable right now, but getting better with each passing day. IOW, nothing to worry about unless you have plans to upgrade to 8-STABLE. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Problems with ipfw in FreeBSD 8.0 / amd64
On Sun, Apr 11, 2010 at 8:57 AM, Tim Gustafson wrote: > After a build/update to RELENG_8, I'm getting this as the last rule from > "ipfw list" > > 0 ip from any to any > > And then I get these through syslog: > > ipfw: ouch!, skip past end of rules, denying packet > > The box then becomes unavailable over TCP. > > I know that there is some development work going on to clean up ipfw; > that's fine. My question is does anyone know if this is a problem in > RELENG_8_0_0_RELEASE as well? Should I change my csup tag to > RELENG_8_0_0_RELEASE and then do another build/install cycle to fix the > problem, or will the problem still be there? > > Also, I know this a volunteer effort so I have no right to be pushy, but is > there any ETR on this so that I can start tracking RELENG_8 again? > Use RELENG_8_0. That's the security branch for 8.0-RELEASE. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: soft-cap,
On Tue, Jan 4, 2011 at 2:33 PM, Michael Spratt wrote: > Dear friends, linux/ipfw/dummynet/transparent-bridge, am trying to cap > users to upload/TX rates, but allow them to go over if the link is not > congested. > > The example below limits each src-ip mask-IP's TX from 10.10.0.0/20 to > 128Kbp/s, and from 10.20.0.0/20 to 1024Kbp/s. > - > ipfw pipe 1 config bw 128Kbit/s mask src-ip 0x > ipfw pipe 2 config bw 1024Kbit/s mask src-ip 0x Create 1 pipe of "1024+128" Kbps. Then create 2 queues, one with weight 1 (the slow queue) and the other with weight 8 (the fast queue). That will guarantee that traffic sent through queue 1 gets at least 128 Kbps of bandwidth, even when the pipe is full. And traffic sent through queue 2 gets at least 1024 Kbps of bandwidth, even when the pipe is full. The beauty of queues, though, is that either queue can "expand" to fill the full pipe, if there's no traffic in the other queues. Thus, queue 1 is guaranteed 128 Kbps of bandwidth, but can use up to the full pipe worth if queue 2 is empty. And queue 2 is guaranteed 1024 Kbps of bandwidth, but can use up to the full pipe worth if queue 1 is empty. > ipfw 10001 add pipe 1 ip from 10.10.0.0/20 to any out xmit br0 > ipfw 10001 add pipe 2 ip from 10.20.0.0/20 to any out xmit br0 Then, change the above rules to use the queues instead. The way dummynet works, is that pipes set hard limits on the bandwidth. And queues provide minimum guarantees for bandwidth inside of that pipe. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Problem with passive ftp in IPFW!
On Sun, Jan 15, 2012 at 10:36 PM, vip 71541 wrote:
> Good morning, everybody. My name is Eugene. I know that not a new issue ...
> But
> there is a problem as competently / properly write the rules for passive ftp
> in
> ipfw on a gateway for my LAN. Gateway running Freebsd 8.2p6. For kernal NAT.
> Now goes to the local network FTP on such rules here:
>
> 00159 0 0 skipto 65000 tcp from 192.168.10.0/24 to any
> dst-port21,1024-65535
> out xmit em0 keep-state
> --
> 00211 skipto 65000 tcp from any 21,1024-65535 to ${wan_ip} in recv em0
> --
> 65000 0 0 nat 90 ip from any to any via em0
> ---
Personally, I don't use skipto rules, as I find them to just cause
confusion. At least at first. Once you have a working ruleset with
several hundred/thousand rules in it, then skipto can be used to
optimised things.
You only have a NAT rule, you don't have any allow rules. The default
rule (65535) in IPFW is "deny ip from any to any". Thus, if you don't
explicity allow the traffic, then the packets are dropped.
Personally, I also don't use stateful filter rules, just because of
the poor way they interact with NAT in IPFW (at least with
divert/natd; not sure if things are better with in-kernel NAT).
Thus, the rules would be something like the following:
ipfw add allow tcp from 192.168.0.0/24 to any 21,49152-65535 in recv
ipfw add nat 90 tcp from 192.168.0.0/24 to any 21,49152-65535 out xmit
ipfw add allow tcp from to any 21,49152-65535 out xmit
ipfw add nat 90 tcp from any 21,49152-65535 to in recv
established
ipfw add allow tcp from any 21,49152-65535 to 192.168.0.0/24 in recv
established
ipfw add allow tcp from any 21,49152-65535 to 192.168.0.0/24 out xmit
established
The flow of the rules are:
- allow traffic on the internal NIC
- NAT the traffic going out the external NIC
- allow the NAT'd traffic going out the external NIC
And then reverse it for the incoming/return traffic
- NAT the traffic coming in on the external NIC
- allow the NAT'd traffic coming in on the external NIC
- allow the traffic going out the internal NIC
The established at the end of the rule catches only TCP packets that
are part of the outgoing connection.
The 49152-65535 is the default "ephemereal" port range on FreeBSD (and
most TCP/IP using systems), used for things like FTP connections.
It's a much smaller range.
There's also FTP NAT tracking modules for IPFW, but I've never
personally used any of them.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Problem with passive ftp in IPFW!
On Mon, Jan 16, 2012 at 11:40 AM, Michael Sierchio wrote: > On Mon, Jan 16, 2012 at 11:05 AM, Freddie Cash wrote: > >> Personally, I don't use skipto rules, as I find them to just cause >> confusion. ... > > skipto rules are essential in numerous instances, especially once you > start using tableargs, or want to partition your ruleset based on > incoming interface. You deleted the part where I mentioned some situations where they are useful. :) When we started implementing FreeBSD-based firewalls (using FreeBSD 4.0), we used skiptos everywhere. Turned into a giant mess that was very hard to follow and to update. We've since moved away from skipto, and just grouped rules according to server (ex: server1 uses 1-10999, server2 uses 11000-11999, etc). Works great for us. Some firewalls now have several thousand rules (with tables, but not tablearg), and we're considering using skiptos to optimise the path packets take through the rules. It all depends on how you want to manage things. :) But when first starting out, I find that KISS applies best. Which means skipping the skiptos and tables and other fancy features until you have a working ruleset, and a good understanding on how things work in IPFW. >> Personally, I also don't use stateful filter rules ... > > Perhaps not, but they're useful for outbound connections/dns queries/etc. For TCP connections, you just add the "established" criteria to the rules for the inbound packets. Same result, but easier to manage (IMO/IME; YMMV). For UDP, it may be easier to use keep-state, since there's no "established" analogue for UDP. But, when using divert/natd, keep-state is a pain due to the order that the packets are processed. Things may have improved with libalias-based in-kernel NAT. Don't know, never tried, never investigated it. Only this school year that I've started migrating firewalls from divert/natd to "ipfw nat". And all our rulesets are non-stateful. Of course, everyone's use-cases are different. Hence why I prefaced everything with "personally", to show that it's just my experience/opinion, and not "zomg, this is the only way things must be done!1! I am uber!". :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW Table Size
On Fri, May 3, 2013 at 12:33 PM, Michael Sierchio wrote: > Better to have a single table - there's a min penalty for each lookup, + > lg(n) or so. > > You can use the second parameter for interesting things, like a rule number > to skipto > > E.g. > > ipfw add 05000 skipto tablearg ip from any to me in recv $if_wan lookup > src-ip $table_number > First time I've seen the "lookup" syntax. There's next to no information on it in the ipfw man page, and the info there doesn't really make it clear how to use it. Can "lookup" syntax be used as an alternative to "table($number)" syntax (which is a pain to enter on command-lines)? Or are they completely separate? Can the same table be used for both styles of lookups? >From what I can tell, a table can only have 2 items per entry: IP and a number (the tablearg). So where is the "lookup" getting src-ip/dest-ip/etc from? What's the difference between: ipfw add 05000 skipto tablearg ip from any to me in recv $if_wan lookup src-ip $table_number ipfw add 05000 skipto tablearge ip from table\($table_number\) to my in recv $if_wan -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW Table Size
On Fri, May 3, 2013 at 1:13 PM, Michael Sierchio wrote: > The syntax is described in the man page, but there are no examples. My > example works ;-) > > Yes, I know it's in the man page, but the description is beyond vague, and there are no usage examples, nor comparisons to the "normal" table(number) syntax. Hence my questions. :) > The first entry is a network, which might have a /32, in which case it's a > single IP addr. > > > > What's the difference between: > > > > ipfw add 05000 skipto tablearg ip from any to me in recv $if_wan lookup > > src-ip $table_number > > > > ipfw add 05000 skipto tablearge ip from table\($table_number\) to my in > > recv $if_wan > So, the difference would be that you can use table(number) anywhere you can use an IP, but "lookup" syntax goes at the end of a rule and the result of the lookup is then put into the normal rule in the field specified? Meaning, the two examples above are identical (minus my just-noticed typos)? Basically, the "lookup" syntax is a way of doing variable expansion in the normal rule syntax. 1. Do the lookup, get a result 2. Replace in main rule with result from lookup 3. Evaluate the rule and compare the packet to it. Interesting. This would cleanup the syntax of my rules-creation scripts and make it easier to manually type rules at the CLI. Anyone feel like updating the man page to make the syntax easier to understand, and to provide some usage examples? ;) -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: feature of `packet per second`
On Wed, Apr 30, 2014 at 8:31 AM, bycn82 wrote: > On 4/30/14 23:01, Julian Elischer wrote: > >> On 4/30/14, 8:52 PM, bycn82 wrote: >> >>> Hi >>> >>> `packet per second` it is easy to be implemented using iptables, there >>> is a module named `recent`, but in using ipfw, Do we have any solution to >>> fulfill it? check the link below >>> https://forums.freebsd.org/viewtopic.php?f=44&t=42933&p=258441#p258441 >>> >> >> since I don't use linux.. what is "packet per second"?.. does it report >> it or set a limit on it? >> >>> >>> bycn82 >>> >>> ___ >>> freebsd-ipfw@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" >>> >>> >>> >> >> Yes, "Packets Per Second"means limit a connection based on the packets > number, for example, If I allow 2 ICMP packets come to my server in each > individual second. only the first 2 packets will be allow, all others in > the same second will be dropped. > For ICMP, specifically, there's a sysctl to control the rate (per second): # sysctl -d net.inet.icmp.icmplim net.inet.icmp.icmplim: Maximum number of ICMP responses per second For everything else, you'd want to use dummynet(4). -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
IPFW rule sets and automatic rule numbering
Good morning everyone, Just wondering if I'm doing things wrong, or if those two features (rule sets and auto incrementing rule numbers) just don't play well together. Until now, I've used the auto-incrementing feature to minimize the amount of work I need to do when changing/updating/adding rules in the middle of my scripts. This has been working great, and is controlled via the net.inet.ip.fw.autoinc_step sysctl. Recently I was playing with the rule sets feature and using "ipfw set swap" to speed up my firewall rules reloading times. Previously, I'd clear the rules, then load the new rules, but that could leave up to 30 seconds of downtime. With the use of sets, that's under 1 sec. Everything works well on the first run. Everything is loaded correctly into set 1, then swapped into set 0 and made live. All rules are numbered correctly. On the second run, all the rules are loaded into set 1 using rule numbers 65524-65534, and then swapped into set 0. On the third (and all subsequent run), all rules are loaded into set 1 with rule number 65534, and then swapping into set 1. It seems the rule numbers are global across all sets? Meaning, the "last used automatic number" is global across all sets? I was expecting the rule numbers to be unique per set. I do the following to clear out rule set 1 before adding rules: ipfw -f set 1 flush ipfw set disable 1 Then load all my rules into set 1 using the following syntax: ipfw add set 1 allow tcp from 1.2.3.4 to 2.3.4.4 in recv igb0 Then swap the rules at the end using: ipfw set swap 1 0 Is there anything I could be doing differently to get the numbering to work the way I expect it to? Or am I going to have to manually number every rule in my scripts? -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW rule sets and automatic rule numbering
Forgot to mention, this is 64-bit FreeBSD 10.0-RELEASE-p7, using Intel i350-T4 (igb) NICs. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW rule sets and automatic rule numbering
You can replicate it using 3 rules, loaded into two sets: ipfw set disable 1 ipfw add allow ip from any to any ipfw add 65524 allow ip from any to any ipfw add allow ip from any to any ipfw set swap 1 0 Run that two or 3 times. Every rule will be numbered 65534 after the 2nd or 3rd run. I expected it to be numbered 10, 65524, 65534 after every run. However, after reading the man page a few more times and thinking about it a little more, it makes sense that the numbering is global across all sets, as you can have multiple sets enabled simultaneously. It just doesn't mesh with my desire to use auto numbering. I'm in the midst of manually numbering all my rules now. :) ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW rule sets and automatic rule numbering
On Sep 14, 2014 3:37 AM, "Willem Jan Withagen" wrote: > > On 13-9-2014 21:51, Freddie Cash wrote: > > You can replicate it using 3 rules, loaded into two sets: > > > > ipfw set disable 1 > > ipfw add allow ip from any to any > > ipfw add 65524 allow ip from any to any > > ipfw add allow ip from any to any > > ipfw set swap 1 0 > > > > Run that two or 3 times. Every rule will be numbered 65534 after the 2nd or > > 3rd run. > > > > > I expected it to be numbered 10, 65524, 65534 after every run. > > > > However, after reading the man page a few more times and thinking about it > > a little more, it makes sense that the numbering is global across all sets, > > as you can have multiple sets enabled simultaneously. > > > > It just doesn't mesh with my desire to use auto numbering. I'm in the midst > > of manually numbering all my rules now. :) > > ___ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" > > > > This is easily circumvented by making shure that the first rule is Nope. It doesn't matter what the first number is. What matters is the _last_ number used. The auto-increment feature tracks the last rule number used, then adds the auto-increment number (as set by sysctl, I believe the default is 10) to any rules without explicit numbers. My rules start at 2, are specifically numbered up to 20, then I group things together by starting the server- specific scripts on even 100s or 1000s, and auto-increment through that file. Which works great if all you do is: - clear all rules (which resets the "last number" to 0) - load all rules That's what I used to do, and what I do on all school firewall boxes. Works beautifully. Has for years. No sets involved. The only downside is that it breaks all traffic for X seconds while the new rules load. Fine for a school, as it's usually under 2 seconds, and nobody notices. At the main school board office, it takes almost 30 seconds to load the rules, so I was looking into rule sets to allow for almost instantaneous loading (swap) of the rules, minimising downtime. Unfortunately, that's when I hit the ”rule numbers are global across sets ” issue. It took me by surprise. It makes sense to me now, and I can work with it that way. It just want what I expected. Originally, I had hoped to just use sets without changing my scripts like so: - disable and clear set 1 - load into set 1 - swap sets 1 and 0 I can still do that, I just need to manually number all my rules first. And probably try the following: - disable and clear set 1 - load into set 1 - enable set 1 - swap sets 1 and 0 - disable set 1 That way, there shouldn't be any downtime at all, and all connections should continue during the reload. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW rule sets and automatic rule numbering
Just to summarise everything: 1. Automatic rule numbering works beautifully if you only ever use the default rule set (set 0). Meaning, if you don't use any set commands at all. 2. If you manually number every rule, then using rule sets works beautifully. 3. Doing a little set manipulation allows you to load updated rules without disconnecting anyone or dropping any packets: disable set 1 load rules into set 1 enable set 1 swap set 1 0 disable set 1 I understand how everything works a little bit better now. Thanks for all the help and pointers and discussion. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
High intr CPU % and slow throughput
[Not sure if this is more appropriate for the -ipfw or -stable mailing
lists.]
64-bit FreeBSD 10.0-p7
Dual-core AMD Opteron 1218 CPU @ 2.6 GHz
2 GB of DDR2 RAM
Intel i350-T4 quad-port gigabit NIC using igb(4)
Each of the gigabit NIC ports are connected to gigabit links (we have a
gigabit fibre link to our ISP, which has dual 10 Gbps links to the public
Internet).
Using the following simple ruleset (there are more rules, but these are the
ones that match when we test transfers to/from the Internet):
ipfw nat 8668 config ip 142.24.
x.y
same_ports
10 allow ip from any to any via lo0
12 allow carp from any to any
20 reject log logamount 1 ip from 10.0.0.0/8 to any in recv igb0
22 reject log logamount 1 ip from 127.0.0.0/8 to any in recv igb0
2
4 reject log logamount 1 ip from 172.16.0.0/20 to any in recv igb0
26 reject log logamount 1 ip from 192.168.0.0/16 to any in recv igb0
50 skipto 65000 ip from 192.168.0.0/24 to not 142.24.
x.z
/25 in recv igb2
52 skipto 65000 ip from not 142.24.13.128/25 to 142.24.
x.y
in recv igb0
65000 allow ip from 192.168.0.0/24 to any in recv igb2
65002 nat 8668 ip from 192.168.0.0/24 to any out xmit igb0
65004 allow ip from 142.24.
x.y
to any out xmit igb0
65006 nat 8668 ip from any to 142.24.
x.y
in recv igb0
65008 allow ip from any to 192.168.0.0/24 in recv igb0
65010 allow ip from any to 192.168.0.0/24 out xmit igb2
When we start a large download or file transfer from the Internet (a single
file from a single server), CPU usage for the [intr{irq256: igb0:que}]
kernel thread jumps to over 90% (one CPU core) and causes all traffic
through the firewall (even traffic that doesn't go through igb0) to grind
to a standstill. Some TCP connections through other interfaces are even
dropped. During this time, the other CPU core is under 50% usage.
IIUIC, the [intr{irq256: igb0:que}] isn't showing actual CPU usage for
processing hardware interrupts, but is showing the CPU usage used to
process the packets going through IPFW. Correct? "vmstat -i" shows only
10-15 interrupts per second for each of the igb interfaces.
The really depressing part is that throughput (as shown by "iftop -i igb0"
and snmp graphing) never goes above 40 Mbps. :(
What can I do to try and track down exactly why this is occurring?
Is there anything I can do to reduce or mitigate this CPU usage?
Or, is this simply a case of the CPU being too old?
/boot/loader.conf currently has the following (been playing with most of
these lately, without much change in CPU usage):
## Tune the igb(4) interfaces a little
hw.igb.enable_aim="1"
hw.igb.enable_msix="1"
hw.igb.header_split="0"
hw.igb.max_interrupt_rate="16000"
hw.igb.num_queues="0"
hw.igb.rx_process_limit="1000"
hw.igb.rxd="4096"
hw.igb.txd="4096"
## Configure kernel
kern.hz="4000"
## Configure IPFW
net.inet.ip.fw.default_to_accept="1"
net.inet.ip.fw.verbose="1"
## Configure network threads
net.isr.bindthreads="1"
net.isr.direct="1"
net.isr.maxthreads="2"
/etc/sysctl.conf has the following (haven't changed these in a long time):
# IPFW options
net.inet.ip.fw.autoinc_step=2
net.inet.ip.fw.enable=1
net.inet.ip.fw.one_pass=1
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=1
At lunch today, we'll be failing-over to the other firewall, which will be
running without any /boot/loader.conf or /etc/sysctl.conf entries to see if
my "optimisations" are actually "pessimisations".
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: High intr CPU % and slow throughput
Aha! I believe I've found the cause of our current issue. In an effort to allow reloading of the firewall rules during the day without disconnecting anyone (dropping TCP connections), I started playing with rule sets. And everything appeared to be working wonderfully, in that I could restart the rules multiple times without dropping any packets or disconnecting anyone. But, CPU usage skyrocketed on large downloads and we were capped at a little less than 40 Mbps. :( It seems that if you do the following (at least twice, to make sure rules are in both sets), your CPU will melt: - clear set 1 - disable set 1 - load 4000 rules into set 1 - enable set 1 - swap sets 1 and 0 - disable set 1 I thought that would leave only the rules in set 0 active, which would be the equivalent of only having loaded rules into set 0. However, it seems that ipfw still checks rules in disabled sets! Or does some kind of processing with disabled sets. pmcstat was showing lots (200-2000) of unresolved samples and ipfw.ko sitting at 80-90% in the list, even when CPU usage was around 30%. I did the above, but added "ipfw -f set 1 flush" as the last step, and everything is back to normal. pmstat is now empty (0 unresolved). We can now push 75 Mbps through the firewall with CPU usage under 80%. More importantly, though, other traffic is not impacted by large downloads and speedtests and streaming video! And, CPU usage is sitting at under 10% for "normal" traffic. Yes, I know 4000 rules is a lot (doing NAT for 66 systems and 2 local subnets). Until now I was focusing on getting things working (migrating from FreeBSD 7 using IPFW+natd with lots of private IP to private IP rules; to FreeBSD 10 using IPFW + in-kernel NAT and proper double-NAT across networks using public IPs only). Optimisation work is just now beginning. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipwf dummynet vs. kernel NAT and firewall rules
On Wed, Mar 9, 2016 at 10:09 AM, Don Lewis wrote:
> On 9 Mar, Franco Fichtner wrote:
> > Hi Don,
> >
> > If you mean pf(4)-based NAT, there is a patch that originates from
> > m0n0wall that handles the transition. We're using it in OPNsense
> > for that reason. Here is the patch for 10.x, maybe that is what
> > you're looking for:
>
> Nope, I'm using ipfw in-kernel NAT, which is not the default in
> rc.firewall, but is easy to paste in next to or in place of the default
> natd configuration.
>
> case ${firewall_nat_enable} in
> [Yy][Ee][Ss])
> if [ -n "${firewall_nat_interface}" ]; then
> if echo "${firewall_nat_interface}" | \
> grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then
> firewall_nat_flags="ip
> ${firewall_nat_interface} ${firewall_nat_flags}"
> else
> firewall_nat_flags="if
> ${firewall_nat_interface} ${firewall_nat_flags}"
> fi
> ${fwcmd} nat 123 config log ${firewall_nat_flags}
> ${fwcmd} add nat 123 ip4 from any to any via
> ${firewall_nat_interface}
> fi
> ;;
> esac
>
> My suspicion is that if a packet matches the rule to pass it to dummynet
> that it is bypassing NAT.
> ___
> freebsd-ipfw@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
>
Do you have the sysctl net.inet.ip.fw.one_pass set to 0 or 1?
If set to 1, the a dummynet match ends the trip through the rules, and the
packet never gets to the NAT rules. Or, if a NAT rule matches, the trip
through the rules ends, and it never get to the dummynet rules. Depending
on which you have first.
You'll need to set net.inet.ip.fw.one_pass=0 in order to re-inject the
packet into the rules after it matches a dummynet or NAT rule. Or, do the
NAT and dummynet rules on different interfaces to match different traffic.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Question that has dogged me for a while.
On Thu, May 4, 2017 at 9:22 AM, Karl Denninger wrote:
> Consider the following network configuration.
>
>
> Internet --- Gateway/Firewall -- Inside network (including a
> web host)
> 70.16.10.1/28 192.168.0.0/24
>
> The address of the outside is FICTIONAL, by the way.
>
> For policy reasons I do NOT want the gateway machine to actually have
> the host on it. There may be a number of things running on there but
> for the instant moment let's assume a standard pedestrian web host on
> port 80.
>
> I have DNS pointing at "webhost.domain" @ 70.16.10.1.
>
> I have NAT on the gateway (NAT internal to the kernel), and a "hole
> punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as
> pat of the nat configuration statement.
>
> This works fine for anyone on the outside. HOWEVER, anyone on the
> INTERNAL network cannot see the host.
>
> My NAT configuration looks like this:
>
> #
> # Now divert all inbound packets that should go through NAT. Since this
> is NAT
> # it can only match a packet that previously was NATted on the way out.
> #
> ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif}
> #
> # Check stateful rules; we want to go there directly if there is a match
> #
> ${fwcmd} add 7000 check-state
> #
> # Now pick up all *outbound* packets that originated from an inside address
> # and put them through NAT. We then have
> # a packet with a local source address and we can allow it to be sent.
> # Therefore, if the packet is outbound let it pass and be done with it.
> #
> ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit
> ${oif}
> >>${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip}
> ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit
> ${oif}
> ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif}
>
> Without the ">>" line I get nothing; the packets get to the gateway and
> disappear.
>
> With the ">>" line I DO get the packets re-emitted on the internal
> interface HOWEVER there is no translation to the internal interface IP
> on the gateway box. So what I see on the internal box is this:
>
> 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags
> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
> 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags
> [S.], seq 3088872007, ack 292171179, win 65535, options [mss
> 1460,nop,wscale 6,sackOK,eol], length 0
>
> Which won't work because the internal box got and sent this:
>
> 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S],
> seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK],
> length 0
> 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S],
> seq 2666765817, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
> >> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags
> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
> >> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags
> [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
>
> But since the gateway emitted the packet back on the wire *without*
> remapping the source address (to itself) it doesn't match on the client
> box 'cause there's no way back for it.
>
> There has to be a solution to this somewhere and I'm obviously missing
> it. :)
You need to do a double-NAT (or hairpin-NAT or whatever you want to call
it), where you first NAT the destination address on the incoming interface
which will initiate the routing decision for where to send the packet next,
then NAT the source address on the outgoing interface (which can be the
same interface) in order to get the return packets sent back to the correct
gateway.
Something along the lines of:
ipfw nat 100 blah blah blah
ipfw nat 200 blah blah blah
ipfw add nat 200 tcp from 192.168.0.0/16 to 70.16.10.1 80 in recv
ipfw add nat 100 tcp from 192.168.0.0/16 to 192.168.1.1 80 out xmit
ipfw add nat 100 tcp from 192.168.1.1 80 to 70.16.10.x in recv
ipfw add nat 200 tcp from 70.16.10.1 80 to 192.168.0.0/16 out xmit https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Question that has dogged me for a while.
On Fri, May 5, 2017 at 8:34 PM, Karl Denninger wrote: > Can you point me to the ruleset you posted? Thanks in advance. > I can't remember all your network details, and don't have the e-mails saved, so fill in the blanks below. :) And change the ports as needed. IIF= EIF= PUB_IP="me" SRV_IP= PRV_NET= # NAT incoming traffic for port 8080 to server's private IP ipfw nat 100 config same_ports ip $PUB_IP redirect_port tcp $PRV_IP:80 $PUB_IP:8080 # NAT outgoing traffic from private subnet to public IP ipfw nat 200 config same_ports ip $PUB_IP # Allow port 8080 traffic to server from private subnet (in) ipfw add nat 100 tcp from $PRV_NET to $PUB_IP 8080 in recv $IIF ipfw add nat 200 tcp from $PRV_NET to $SRV_IP 80 out xmit $IIF ipfw add nat 200 tcp from $SRV_IP 80 to $PUB_IP in recv $IIF ipfw add nat 100 tcp from $PUB_IP 8080 to $PRV_NET out xmit $IIF # Allow port 8080 traffic from Internet to server (in) ipfw add nat 200 tcp from anyto $PUB_IP 8080 in recv $EIF ipfw add allow tcp from anyto $SRV_IP 80 out xmit $IIF ipfw add allow tcp from $SRV_IP 80 to any in recv $IIF ipfw add nat 200 tcp from $SRV_IP 80 to any out xmit $EIF # Allow clients access to Internet (out) ipfw add allow tcp from $PRV_NET to any in recv $IIF ipfw add nat 100 tcp from $PUB_IP to any out recv $EIF ipfw add nat 100 tcp from any to $PUB_IP in recv $EIF ipfw add allow tcp from any to $PRV_NET out xmit $IIF # Block the rest ipfw add deny log ip from any to any in recv $EIF ipfw add deny log ip from any to any in recv $IIF -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Matching rules on ip4/ip6 with udp/tcp
On Wed, Jun 6, 2018 at 10:36 AM, Dries Michiels wrote: > Is there are way to match packets specifying both network generation ip4 or > ip6 together with the protocol such as tcp or udp? > > Currently the following rules are possible (examples): > > ipfw add 1 allow udp from any to me 22 in recv em0 > > ipfw add 1 allow ip4 from any to me 22 in recv em0 > > > The following rule is not possible (example): > > ipfw add 1 allow ip4 udp from any to me 22 in recv em0 > > > Is there a workaround for this or some reason why this hasn't been > implemented? > > Or do I simply not have the rule syntax right. > One of the following pairs should do what you want, although the man page is a little hard to parse on some of it, so they may not actually work: ipfw add 1 allow from any to me in recv em0 proto ip4 dst-port 22 ipfw add 1 allow from any to me in recv em0 proto ip6 dst-port 22 ipfw add 1 allow udp from any to me in recv em0 proto ip4 dst-port 22 ipfw add 1 allow udp from any to me in recv em0 proto ip6 dst-port 22 Basically, there's a giant section in the man page about the "options" section of the rule (what goes after the interface). You can do just about anything within that section, including a lot of what could be done in the "protocol" and "source address" and "destination address" sections. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipfw managing rules - best practice?
On Wed, Sep 5, 2018 at 2:29 AM Ole wrote: > Hi, > > I'm using ipfw firewall on several machines. Rules are made by users by > hand or by configuration management tools. > > For this the ipfw.rules script sources other files: > > #!/bin/sh > > ipfw -q -f flush > cmd="ipfw -q add" > pif="epair0b" # interface name of NIC attached to Internet > $cmd 00010 allow all from any to any via lo0 > for RULES in `ls /etc/ipfw.rules.d/*.rules` ; do > . $RULES > done > $cmd 0 deny log all from any to any > > If a user or a script alters a file, `service ipfw restart` is called. > This is working fine except one thing. Active connections like sql, > syslog, ssh, etc. get broken. They are defined like > > $cmd 01610 allow tcp from vpn.example.org to me 22 in via $pif setup > limit src-addr 50 > > I understand, that this connections get broken because the dynamic > rules get flushed with the `ipfw -q -f flush` command. But commenting > this command out results in a continuously growing rules table. > > With the `ipfw -d list` command I can see the dynamic rules. > Is there a way to flush the rules but not the dynamic ones? > Or to add them again after flush? > > How do you reload your rules? > Rule sets are made for this. :) Edit your script to create a new rule set 1 as the first step. Then to insert all the rules into rule set 1. As the last line of your script, you swap set 1 and set 0, which makes your new rules live. It's an atomic switch, so no packets are lost or connections dropped. (Note: I've never used stateful filtering with IPFW so not sure how the rule set switch interacts with that, but it shouldn't drop the dynamic connections.) ipfw -f set 1 flush ipfw set 1 disable ... all your normal rules, prepended by "set 1" ipfw set enable 1 ipfw set swap 1 0 ipfw set disable 1 ipfw -f set 1 flush -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipfw: switching sets does stall the machine
On Fri, Jun 14, 2019 at 10:13 AM Peter wrote: > Hi, > I am trying to use two different configurations (production and test) > loaded into different sets, and switch between them with > ># ipfw set disable ... enable ... > > When testing my script, this did work, except once the machine went > into "swap_pager indefinite wait" and was lost. > > Then, after reboot (and automatically loading the production rules) I > tried to load and switch to the test rules, and immediately got ATA > COMMAND TIMEOUT and the machine was lost. > > I repeated this a few times, it is nicely reproducible: withing 3-5 > seconds after the new rules are loaded, the machine locks up and is > lost. > > I analyzed more closely by running "top -HPS" in rtprio, and found > this: > * loading the rules is no problem. > * when switching sets, the command returns, but then within few >seconds the machine gets unresponsive and stays so until watchdog >hits. > * The last thing seen in "top" (before it freezes) is this thread >eating 85% CPU (and running with high priority): >[irq12: uhci0 uhci1] > > > It there a known workaround? > > Details: > Machine : i386 > OS : FreeBSD 11.2-RELEASE-p10 > Command : ipfw set disable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 enable 16 > 17 18 19 20 21 22 23 24 25 26 27 28 29 > Can't speak to this specific lockup, but I'm curious to know if it works when you enable first, then disable (it's how we've used sets here at work). -- Freddie Cash fjwc...@gmail.com ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
