From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 19 11:06:56 2009 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B068106568B for ; Mon, 19 Oct 2009 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 103D68FC2A for ; Mon, 19 Oct 2009 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9JB6tKc063482 for ; Mon, 19 Oct 2009 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9JB6tw8063480 for freebsd-ipfw@FreeBSD.org; Mon, 19 Oct 2009 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Oct 2009 11:06:55 GMT Message-Id: <200910191106.n9JB6tw8063480@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 64 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 19 14:50:03 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C42106566C for ; Mon, 19 Oct 2009 14:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C9F708FC08 for ; Mon, 19 Oct 2009 14:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9JEo2cZ057397 for ; Mon, 19 Oct 2009 14:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9JEo2fx057396; Mon, 19 Oct 2009 14:50:02 GMT (envelope-from gnats) Date: Mon, 19 Oct 2009 14:50:02 GMT Message-Id: <200910191450.n9JEo2fx057396@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Ian Smith Cc: Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Smith List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:50:03 -0000 The following reply was made to PR kern/139581; it has been noted by GNATS. From: Ian Smith To: bug-followup@FreeBSD.org, freebsd@alexus.org Cc: Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Date: Tue, 20 Oct 2009 01:24:17 +1100 May be a usage issue; I'll have a go. Partial quoting, out of order. : I'm trying to limit my apache that runs under daemon to up 2Mbit/s : when I do "ipfw pipe show" I don't see anything in my slots other then : very first entry that never chage, nor does it limits my traffic, as : if I look at my MRTG i see way more traffic then 2Mbit/s Unless you specify masks on your pipes you'll only ever see the first connection that used that pipe, that's normal. MRTG sees all traffic on an interface, and your ipfw stats indicate at least 25% more traffic than that due to your webserver, so it's not clear how you could tell if your pipe was exceeding 2Mbit/s or not? Also, it's recommended not to run your inbound and outbound traffic through the one pipe, unless simulating half-duplex connections; see explanation in ipfw(8), EXAMPLES section under TRAFFIC SHAPING. : su-3.2# ipfw show : 00100 1249368 205115325 allow ip from any to any via lo0 : 00200 0 0 deny ip from any to 127.0.0.0/8 : 00300 0 0 deny ip from 127.0.0.0/8 to any : 08380 2838075 3586421013 pipe 1 tcp from any 80 to any uid daemon : 08380 2097473 136454502 pipe 1 tcp from any to any dst-port 80 uid daemon : 65000 5740679 4716157064 allow ip from any to any : 65535 0 0 deny ip from any to any 3.586 GiB outbound from the webserver (served data) 0.136 GiB inbound to the webserver (requests, acks) + --- 3.722 GiB through the pipe. but 4.716 GiB passed from any to any, either way. So there's about 1 Gig of extra traffic shown here, assuming you have net.inet.ip.fw.one_pass=0 and all traffic eventually hits rule 65000 (and 4.7G extra traffic if net.inet.ip.fw.one_pass=1) but there's not enough info to see whether or not it's on the interface MRTG watches? : su-3.2# ipfw pipe show : 00001: 2.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail : mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 : BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp : 0 tcp 64.237.55.83/59388 208.80.152.3/80 4936077 3723134341 0 0 30179 Total packets and bytes match the above, indicating that this was done just after the ipfw show. 0.6% dropped packets indicates some limiting happening, but with a shared in/outbound pipe, not in which direction. If this is still an issue, please: . be more precise than "way more traffic" if you have more data? . say whether the extra ~25% traffic shown is on the same interface as the webserver, ie the interface MRTG monitors, or not? . the value of sysctl net.inet.ip.fw.one_pass ? cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 19 16:30:05 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9FAA106568F for ; Mon, 19 Oct 2009 16:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BEC408FC13 for ; Mon, 19 Oct 2009 16:30:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9JGU5dn042782 for ; Mon, 19 Oct 2009 16:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9JGU5cc042779; Mon, 19 Oct 2009 16:30:05 GMT (envelope-from gnats) Date: Mon, 19 Oct 2009 16:30:05 GMT Message-Id: <200910191630.n9JGU5cc042779@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: alexus Cc: Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alexus List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:30:06 -0000 The following reply was made to PR kern/139581; it has been noted by GNATS. From: alexus To: Ian Smith Cc: bug-followup@FreeBSD.org, freebsd@alexus.org Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Date: Mon, 19 Oct 2009 11:58:41 -0400 On Oct 19, 2009, at 10:24 AM, Ian Smith wrote: > May be a usage issue; I'll have a go. Partial quoting, out of order. > > : I'm trying to limit my apache that runs under daemon to up 2Mbit/s > : when I do "ipfw pipe show" I don't see anything in my slots other > then > : very first entry that never chage, nor does it limits my traffic, as > : if I look at my MRTG i see way more traffic then 2Mbit/s > > Unless you specify masks on your pipes you'll only ever see the first > connection that used that pipe, that's normal. ok new set of rules su-3.2# cat /etc/ipfw.rules flush pipe flush pipe 1 config bw 1Mbit/s mask src-port www pipe 2 config bw 1Mbit/s mask src-port www add 100 allow ip from any to any via lo0 add 200 deny ip from any to 127.0.0.0/8 add 300 deny ip from 127.0.0.0/8 to any add 8381 pipe 1 tcp from any to any dst-port www uid daemon add 8382 pipe 2 tcp from any to any src-port www uid daemon add 65000 pass all from any to any su-3.2# ipfw show 00100 1476 230632 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 08381 482 36368 pipe 1 tcp from any to any dst-port 80 uid daemon 08382 620 743113 pipe 2 tcp from any 80 to any uid daemon 65000 6832 5040856 allow ip from any to any 65535 0 0 deny ip from any to any su-3.2# ipfw pipe show 00001: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 64.237.55.83/49492 66.230.133.69/80 509 38156 0 0 0 00002: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 66.230.133.69/80 64.237.55.83/49492 656 785292 1 1500 1 su-3.2# ipfw pipe show 00001: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 64.237.55.83/49492 66.230.133.69/80 1247 98023 0 0 0 00002: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 66.230.133.69/80 64.237.55.83/49492 1475 1453606 0 0 1 su-3.2# in this case i did specify mask for pipe, yet when I'm issuing ipfw pipe show I still don't see anything in terms of slots that being in use su-3.2# sysctl net.inet.ip.dummynet.pipe_slot_limit net.inet.ip.dummynet.pipe_slot_limit: 100 su-3.2# seems like at all time I see only 1 slot being utilized and as I mention before it never changes. > > MRTG sees all traffic on an interface, and your ipfw stats indicate at > least 25% more traffic than that due to your webserver, so it's not > clear how you could tell if your pipe was exceeding 2Mbit/s or not? > I obviously do have other traffic then www, but majority of it is www. but I see why you coming with this, so let me just give you an example. if I at peak time shutdown my apache, my traffic drops dramatically and by dramatically i mean at least 90% (and in most cases more) my traffic went to as much as 10mbps with supposedly limited pipe of 2mbps, when I set it to 1mbps it seems to be almost there... > Also, it's recommended not to run your inbound and outbound traffic > through the one pipe, unless simulating half-duplex connections; see > explanation in ipfw(8), EXAMPLES section under TRAFFIC SHAPING. i thought about that and as you suggested i did separate them into 2 separate pipes (see on top) > > : su-3.2# ipfw show > : 00100 1249368 205115325 allow ip from any to any via lo0 > : 00200 0 0 deny ip from any to 127.0.0.0/8 > : 00300 0 0 deny ip from 127.0.0.0/8 to any > : 08380 2838075 3586421013 pipe 1 tcp from any 80 to any uid daemon > : 08380 2097473 136454502 pipe 1 tcp from any to any dst-port 80 uid > daemon > : 65000 5740679 4716157064 allow ip from any to any > : 65535 0 0 deny ip from any to any > > 3.586 GiB outbound from the webserver (served data) > 0.136 GiB inbound to the webserver (requests, acks) > + --- > 3.722 GiB through the pipe. > but > 4.716 GiB passed from any to any, either way. > > So there's about 1 Gig of extra traffic shown here, assuming you have > net.inet.ip.fw.one_pass=0 and all traffic eventually hits rule 65000 > (and 4.7G extra traffic if net.inet.ip.fw.one_pass=1) but there's not > enough info to see whether or not it's on the interface MRTG watches? > > : su-3.2# ipfw pipe show > : 00001: 2.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > : mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > : BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > : 0 tcp 64.237.55.83/59388 208.80.152.3/80 4936077 3723134341 0 0 > 30179 > > Total packets and bytes match the above, indicating that this was done > just after the ipfw show. 0.6% dropped packets indicates some > limiting > happening, but with a shared in/outbound pipe, not in which direction. > > If this is still an issue, please: > > . be more precise than "way more traffic" if you have more data? > . say whether the extra ~25% traffic shown is on the same interface > as the webserver, ie the interface MRTG monitors, or not? > . the value of sysctl net.inet.ip.fw.one_pass ? > > cheers, Ian > From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 19 17:38:07 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD14106568F for ; Mon, 19 Oct 2009 17:38:07 +0000 (UTC) (envelope-from chris@smartt.com) Received: from mailout3.smartt.com (mailout3.smartt.com [69.67.187.28]) by mx1.freebsd.org (Postfix) with ESMTP id 713AD8FC28 for ; Mon, 19 Oct 2009 17:38:07 +0000 (UTC) Received: from [69.31.174.220] (unknown [69.31.174.220]) by mailout3.smartt.com (Postfix) with ESMTPA id DA1B310E565; Mon, 19 Oct 2009 10:37:59 -0700 (PDT) Message-ID: <4ADCA3FD.5080004@smartt.com> Date: Mon, 19 Oct 2009 10:38:05 -0700 From: Chris St Denis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ian Smith References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> <4ACF9341.2040406@smartt.com> <4AD8FDD0.30008@smartt.com> <20091017171148.T70724@sola.nimnet.asn.au> In-Reply-To: <20091017171148.T70724@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Lewis , freebsd-ipfw@freebsd.org, Freddie Cash Subject: Re: ipfw: install_state: entry already present, done X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 17:38:07 -0000 Interesting idea, but doesn't seem to help any :( I added it into the workstation set I had with it loading between the 127.0.0.1 rules and the check-state. Message didn't stop and "ipfw show" doesn't show anything hitting that rule. What "ipfw show" does show is a lot on the "allow tcp .... setup keep-state" and "allow udp .... keep-state" rules hitting all the packets (plus one each on 2 of the abuse ones farther down) I tried rolling back my sys/netinet/ip_fw2.c to the latest revision from 7.1 and that didn't help either, so I don't think it was a change to that file. Unless there is a kernel developer aroun who is more familiar with the network stack to fix this or point me in a better direction, I'll keep rolling back individual files trying to find which commit caused this. Ian Smith wrote: > On Fri, 16 Oct 2009, Chris St Denis wrote: > > > > This is definitely a regression in 7.2. > > > > Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test > > server back to 7.2 and the messages come back. > > I notice neither your rules shown below nor the "workstation" rules - > unlike the "client" and "simple" rulesets - allow IP fragments to pass, > and I'm not sure what happens to frags that are associated with stateful > DNS rules. > > The only frags I usually see here are associated with DNS responses from > my forwarders, usually huge lists of NS for spamhaus.org that are almost > always fragmented (around 2Kbytes). > > You could maybe try a specific 'allow log all from any to any frag' ? > > Just a wild stab in the dark, > > cheers, Ian > > > Chris St Denis wrote: > > > check_state doesn't help. The error is also generated from the rc.conf > > > firewall_type="workstation" rule set which includes check_state among > > > several other rules. > > > > > > I made a copy of this server (it's a virtual server under WMware) and > > > downgraded it to 6.4-RELEASE-p7 and I no longer get the error. > > > > > > I downgraded another copy to 7.2-RELEASE (no patches) by copying the > > > generic kernel off the CD. Still gets errors. > > > > > > Downgraded it to 7.0-RELEASE and the message stopped. > > > > > > I'm going to try going to 7.1 and see which behavior it has. > > > > > > Looks like there may have been a regression in 7.2 (or maybe 7.1 pending > > > the results of my further testing) > > > > > > > > > Jason Lewis wrote: > > > > Did you try a check_state? I am using this same rule structure on BSD6 > > > > without a problem. > > > > > > > > Thanks, > > > > Jason > > > > http://jasonlewis.yaritz.net > > > > > > > > > > > > > Freddie Cash wrote: > > > > > > > > > > > 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 > > > > > > > > > > > I added that and restarted bind (thus generating a bunch of UDP > > > > > traffic) > > > > > and the error still floods the console. > > > > > > > > > > Current rule set: > > > > > 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 out xmit em0 keep-state > > > > > 00500 allow ip from any to any > > > > > 65535 deny ip from any to any > > > > > > > > > > _______________________________________________ > > > > > freebsd-ipfw@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > freebsd-ipfw@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > -- > > Chris St Denis > > Programmer > > SmarttNet (www.smartt.com) > > Ph: 604-473-9700 Ext. 200 > > ------------------------------------------- > > "Smart Internet Solutions For Businesses" > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 19 20:14:14 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB554106566B for ; Mon, 19 Oct 2009 20:14:13 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 8079C8FC0C for ; Mon, 19 Oct 2009 20:14:13 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MzycP-0004FN-0C for freebsd-ipfw@freebsd.org; Mon, 19 Oct 2009 13:14:13 -0700 Message-ID: <25964869.post@talk.nabble.com> Date: Mon, 19 Oct 2009 13:14:13 -0700 (PDT) From: PeterJJ To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: PeterJ4ones@hotmail.co.uk Subject: IPFW closing range of ports X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 20:14:14 -0000 I'm new to this, so go easy please. I have put in place a very basic ipfw ruleset in my place of employment. To this i have been asked to block out all peer to peer sharing to ports in the range of 14500-65000. Is it doable? I am currently experiencing issues with users where I work running a music streaming service which at first runs from the free service's own servers, then starts running peer to peer. I am not allowed to block the application. I would like to as it is hogging bandwidth, but have been told I am not permitted. Is there anything I can do? The application will run with the peer to peer option disabled, relying only on the company's server, before eventually getting kicked off after an hour or so (but I don't care about that). Thank you all in advance -- View this message in context: http://www.nabble.com/IPFW-closing-range-of-ports-tp25964869p25964869.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 19 21:30:09 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 868751065672 for ; Mon, 19 Oct 2009 21:30:09 +0000 (UTC) (envelope-from drinking.coffee@gmail.com) Received: from mx1.subnetmask.net (web1.reverse.net [208.101.21.58]) by mx1.freebsd.org (Postfix) with ESMTP id 64EA08FC18 for ; Mon, 19 Oct 2009 21:30:09 +0000 (UTC) Received: from c3p0.reverse.net (c3p0.reverse.net [66.225.200.4]) by mx1.subnetmask.net (Postfix) with ESMTP id 0718B12B80B2 for ; Mon, 19 Oct 2009 16:00:58 -0500 (CDT) Received: from [192.168.2.175] (mx1.reverse.net [66.225.200.253]) by c3p0.reverse.net (Postfix) with ESMTP id CFFEE5730 for ; Mon, 19 Oct 2009 16:00:56 -0500 (CDT) Message-ID: <4ADCD388.5040109@gmail.com> Date: Mon, 19 Oct 2009 16:00:56 -0500 From: Matthew Walker User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <25964869.post@talk.nabble.com> In-Reply-To: <25964869.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: IPFW closing range of ports X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 21:30:09 -0000 You could starve it by using a pipe, allocate 16 kbit/sec. Then technically you aren't blocking it. ipfw add 1000 pipe 10 tcp from any to any 14500-65535 out ipfw pipe 10 config bw 16k queue 100 mask dst-ip 0xff000000 Otherwise, you can block the ports: ipfw add 1000 deny tcp from any to any 14500-65535 out Depends on how much of a BOFH mood your are in that day. -- Matthew PeterJJ wrote: > I'm new to this, so go easy please. > > I have put in place a very basic ipfw ruleset in my place of employment. > To this i have been asked to block out all peer to peer sharing to ports in > the range of 14500-65000. > > From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 22 12:20:03 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD40106566B for ; Thu, 22 Oct 2009 12:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7291B8FC1B for ; Thu, 22 Oct 2009 12:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9MCK2oC088859 for ; Thu, 22 Oct 2009 12:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9MCK2eC088858; Thu, 22 Oct 2009 12:20:02 GMT (envelope-from gnats) Date: Thu, 22 Oct 2009 12:20:02 GMT Message-Id: <200910221220.n9MCK2eC088858@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Ian Smith Cc: Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Smith List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 12:20:03 -0000 The following reply was made to PR kern/139581; it has been noted by GNATS. From: Ian Smith To: alexus Cc: bug-followup@FreeBSD.org, freebsd@alexus.org Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Date: Thu, 22 Oct 2009 23:17:23 +1100 (EST) On Mon, 19 Oct 2009, alexus wrote: > new set of rules > pipe 1 config bw 1Mbit/s mask src-port www > pipe 2 config bw 1Mbit/s mask src-port www Wrong mask syntax entirely. You can see from your pipe masks as shown, it's taken as meaning no mask at all: > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 Anyway, masking pipes creates dynamic pipes per masked flow, each of which gets ALL of the specified bandwidth. If you want to limit total bandwidth to 1Mbit/s, you likely want to use dynamic queues instead. ipfw(8) is a precise reference, but very terse. Suggested reading: http://info.iet.unipi.it/~luigi/dummynet/ and especially the last link from that page: http://info.iet.unipi.it/~luigi/ip_dummynet/original.html for clear examples of sharing evenly a single link - though noting that page is outdated re the sysctls for dummynet, bridging etc. Still looking more like a usage issue than describing a bug, but: > > If this is still an issue, please: > > . say whether the extra ~25% traffic shown is on the same interface > > as the webserver, ie the interface MRTG monitors, or not? > > . the value of sysctl net.inet.ip.fw.one_pass ? cheers, Ian