From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 4 11:06:45 2013 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F229A959 for ; Mon, 4 Feb 2013 11:06:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E3DA4D05 for ; Mon, 4 Feb 2013 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r14B6jWZ028784 for ; Mon, 4 Feb 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r14B6jU8028782 for freebsd-ipfw@FreeBSD.org; Mon, 4 Feb 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Feb 2013 11:06:45 GMT Message-Id: <201302041106.r14B6jU8028782@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 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:06:46 -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/174749 ipfw Unexpected change of default route o kern/169206 ipfw [ipfw] ipfw does not flush entries in table o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157796 ipfw [ipfw] IPFW in-kernel NAT nat loopback / Default Route o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f 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/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 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/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o bin/65961 ipfw [ipfw] ipfw2 memory corruption inside add() o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw 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 44 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 5 23:44:48 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A084EDBE for ; Tue, 5 Feb 2013 23:44:48 +0000 (UTC) (envelope-from gmnt99@gmail.com) Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 78772F3F for ; Tue, 5 Feb 2013 23:44:48 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id c11so1072567ieb.15 for ; Tue, 05 Feb 2013 15:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=XpdQ5Rf6dArqLS+KayHaRaOl3BYIv7wmKkXlEaFOk+I=; b=uv8nj99KM+Hz3GkLE2JpqI51h2w7DnenPcqFxczVcpBh6ueujsyHiuUOJ+MbCsk2tX 7BaxhaYEI1Y8pP/44IJ03eiuaPA8RALP1aAp75uiCWBkiBCbDwgPuEZSyqStetZ54iAy q7YXMtuGEfcXhzFOVbes4eP1tJOusHH9BGzh1cjCGHrH0ZSMFVfwelWaeRkLMmUh3F8D yCFiedFw3Q3Mzfep+jLku1U5VWr3LSo8XkCFsUkbw8UO6fsD0PwhbhyJugoKh++xNqxI MrBL1Tu+57a36c0LFvq+VObWbsLEHV6IwVdwIFoveMBxAsU5UTO0/sG2uHCzE+vJfq8y F5dA== MIME-Version: 1.0 X-Received: by 10.50.149.168 with SMTP id ub8mr1584649igb.111.1360107887290; Tue, 05 Feb 2013 15:44:47 -0800 (PST) Received: by 10.64.23.133 with HTTP; Tue, 5 Feb 2013 15:44:47 -0800 (PST) Date: Tue, 5 Feb 2013 23:44:47 +0000 Message-ID: Subject: Retrieving the destination port in an ipfw fwd'ed UDP packet From: Gerald McNulty To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 23:44:48 -0000 I'm trying to get the destination port from a UDP packet that's been ipfw fwd'ed to my code. Getting the destination IP address works fine with * setsockopt(...,IP_RECVDSTADDR,...)* and then *recvfrom*, but there doesn't seem to be a way to get the port. For TCP I could just use getsockname(2)and getpeername(2) for all the IP address info but this only returns the locally bound address and port, not the actual destination. Is there an elegant way to get the destination IP port from an ipfw fwd'ed packet? Thanks From owner-freebsd-ipfw@FreeBSD.ORG Thu Feb 7 12:40:14 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 045EC86A; Thu, 7 Feb 2013 12:40:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD58AEB; Thu, 7 Feb 2013 12:40:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r17Ce415023805; Thu, 7 Feb 2013 23:40:05 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 7 Feb 2013 23:40:04 +1100 (EST) From: Ian Smith To: "Eggert, Lars" Subject: Re: high cpu usage on natd / dhcpd In-Reply-To: Message-ID: <20130207231943.O21988@sola.nimnet.asn.au> References: <510A87B8.7000705@luckie.org.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-net@freebsd.org" , freebsd-ipfw@freebsd.org, Matthew Luckie X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 12:40:14 -0000 On Thu, 7 Feb 2013 08:08:59 +0000, Eggert, Lars wrote: > On Jan 31, 2013, at 16:03, Matthew Luckie wrote: > > > > 00510 allow ip from me to not me out via em1 > > 00550 divert 8668 ip from any to any via em1 > > > > Rule 510 fixes it. > > Yep, it does. Can I ask someone to commit this to rc.firewall? The ruleset Matthew posted bears no resemblance to rc.firewall, so I don't see that (or how) it solves any generic problem. > (And I wonder if the rules for the ipfw kernel firewall need a > similar addition, because the system locks up under heavy network > load if I use that instead of natd.) > > Lars Which rc.firewall ruleset are you referring to? There certainly are problems with the 'simple' ruleset relating to use of $natd_enable vs $firewall_nat_enable (not to mention the denial of ALL icmp traffic) that I posted patches to a couple of years ago in ipfw@ to rc.firewall and /etc/rc.d/{ipfw,natd) addressing about 4 PRs .. sadly to no avail. I suggest following up to ipfw@ (cc'd) rather than net@ cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu Feb 7 12:50:54 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85AF8A85; Thu, 7 Feb 2013 12:50:54 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 69A84B6D; Thu, 7 Feb 2013 12:50:54 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,622,1355126400"; d="scan'208";a="17566565" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 07 Feb 2013 04:50:53 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r17Coqa0009706; Thu, 7 Feb 2013 04:50:52 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0328.009; Thu, 7 Feb 2013 04:50:52 -0800 From: "Eggert, Lars" To: Ian Smith Subject: Re: high cpu usage on natd / dhcpd Thread-Topic: high cpu usage on natd / dhcpd Thread-Index: AQHN/49K3QG1cuBZpEGa6wjl1WYXnJhkDzQAgAqMkACAAEu6AIAAAwSA Date: Thu, 7 Feb 2013 12:50:51 +0000 Message-ID: References: <510A87B8.7000705@luckie.org.nz> <20130207231943.O21988@sola.nimnet.asn.au> In-Reply-To: <20130207231943.O21988@sola.nimnet.asn.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "" , Matthew Luckie X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 12:50:54 -0000 Hi, On Feb 7, 2013, at 13:40, Ian Smith wrote: > On Thu, 7 Feb 2013 08:08:59 +0000, Eggert, Lars wrote: >> On Jan 31, 2013, at 16:03, Matthew Luckie wrote: >>>=20 >>> 00510 allow ip from me to not me out via em1 >>> 00550 divert 8668 ip from any to any via em1 >>>=20 >>> Rule 510 fixes it. >>=20 >> Yep, it does. Can I ask someone to commit this to rc.firewall? >=20 > The ruleset Matthew posted bears no resemblance to rc.firewall, so I=20 > don't see that (or how) it solves any generic problem. sorry for having been imprecise. What I was asking for was this change: --- /usr/src/etc/rc.firewall 2012-11-17 12:36:10.000000000 +0100 +++ rc.firewall 2013-02-06 11:35:45.000000000 +0100 @@ -155,6 +155,7 @@ case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then + ${fwcmd} add 49 allow ip from me to not me out via ${natd_interface} ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} fi ;; >> (And I wonder if the rules for the ipfw kernel firewall need a=20 >> similar addition, because the system locks up under heavy network=20 >> load if I use that instead of natd.) >=20 > Which rc.firewall ruleset are you referring to? My rc.conf has: gateway_enable=3D"YES"=20 firewall_enable=3D"YES"=20 firewall_type=3D"OPEN"=20 natd_enable=3D"YES" natd_interface=3D"bce0" With the patch above, that seems to work fine. I tried to replace the natd_* lines with: firewall_nat_enable=3D"YES" firewall_nat_interface=3D"bce0" which caused the machine to lock up under load, similar to when natd starte= d eating CPU cycles. This made me wonder if a similar patch to the above fo= r the firewall_nat_* case in rc.firewall might be needed. > There certainly are=20 > problems with the 'simple' ruleset relating to use of $natd_enable vs=20 > $firewall_nat_enable (not to mention the denial of ALL icmp traffic)=20 > that I posted patches to a couple of years ago in ipfw@ to rc.firewall=20 > and /etc/rc.d/{ipfw,natd) addressing about 4 PRs .. sadly to no avail. >=20 > I suggest following up to ipfw@ (cc'd) rather than net@ Will subscribe, thanks. Lars= From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 8 14:10:55 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 03BF22FA; Fri, 8 Feb 2013 14:10:55 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6D518840; Fri, 8 Feb 2013 14:10:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r18EAjdP076787; Sat, 9 Feb 2013 01:10:45 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 9 Feb 2013 01:10:45 +1100 (EST) From: Ian Smith To: "Eggert, Lars" Subject: Re: high cpu usage on natd / dhcpd In-Reply-To: Message-ID: <20130208012008.L21988@sola.nimnet.asn.au> References: <510A87B8.7000705@luckie.org.nz> <20130207231943.O21988@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "" , "freebsd-net@freebsd.org" , Matthew Luckie X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 14:10:55 -0000 On Thu, 7 Feb 2013 12:50:51 +0000, Eggert, Lars wrote: > Hi, > > On Feb 7, 2013, at 13:40, Ian Smith wrote: > > On Thu, 7 Feb 2013 08:08:59 +0000, Eggert, Lars wrote: > >> On Jan 31, 2013, at 16:03, Matthew Luckie wrote: > >>> > >>> 00510 allow ip from me to not me out via em1 > >>> 00550 divert 8668 ip from any to any via em1 > >>> > >>> Rule 510 fixes it. > >> > >> Yep, it does. Can I ask someone to commit this to rc.firewall? > > > > The ruleset Matthew posted bears no resemblance to rc.firewall, so I > > don't see that (or how) it solves any generic problem. > > sorry for having been imprecise. What I was asking for was this change: > > --- /usr/src/etc/rc.firewall 2012-11-17 12:36:10.000000000 +0100 > +++ rc.firewall 2013-02-06 11:35:45.000000000 +0100 > @@ -155,6 +155,7 @@ > case ${natd_enable} in > [Yy][Ee][Ss]) > if [ -n "${natd_interface}" ]; then > + ${fwcmd} add 49 allow ip from me to not me out via ${natd_interface} > ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} > fi > ;; That could break the 'client' ruleset, which also includes this section, so to do this you may need another case for just 'open' to add that allow first, then the existing code for 'client' as well. Bit messy. My patch made it a setup_nat() function called with or without rule number, so it could be used in 'simple' too, which currently lacks kernel nat. That allows all outbound IP (4 or 6) from any address on your box (me) without trying to divert it via natd - which is a sensible aim for 'open', and as julian@ has said (paraphrasing perhaps) "Never waste natd's time with a packet it doesn't care about", which these are. I think you'd do better for this case to either put these few rules you need, including the following '65000 allow all..' into /etc/my.rules and set firewall_type="/etc/my.rules", or copy rc.firewall to rc.mywall, modify only that and set firewall_script="/etc/rc.mywall" in rc.conf ? Either way you'll still get setup_loopback() and setup_ipv6_mandatory() rules. If it improves performance, can you instrument that at all? > >> (And I wonder if the rules for the ipfw kernel firewall need a > >> similar addition, because the system locks up under heavy network > >> load if I use that instead of natd.) Perhaps finding the root cause of 'lock up' would be useful to pursue? Is there any ipv6 involved with this? Is your upstream DHCP server giving you an address in public or RFC1918 space? What packet rates? > > Which rc.firewall ruleset are you referring to? > > My rc.conf has: > > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > natd_enable="YES" > natd_interface="bce0" > > With the patch above, that seems to work fine. > > I tried to replace the natd_* lines with: > > firewall_nat_enable="YES" > firewall_nat_interface="bce0" > > which caused the machine to lock up under load, similar to when natd > started eating CPU cycles. This made me wonder if a similar patch to > the above for the firewall_nat_* case in rc.firewall might be needed. Well it shouldn't, but maybe you've reached some load / pps limit on your hardware in ipfw_nat too? Again, avoiding trying to do NAT on ineligible (outbound, from me) packets is not a bad idea per se. One of the issues in outstanding PRs for /etc/rc.d/ipfw is that if you still have natd_enable set, it won't load the ipfw_nat module needed, ie you currently need to know you must disable natd when enabling ipfw_nat. > > I suggest following up to ipfw@ (cc'd) rather than net@ > > Will subscribe, thanks. > > Lars I'll leave you to pull this out of net@ if you think it best. cheers, Ian