From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 31 11:07:06 2011 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 171EF106568E for ; Mon, 31 Oct 2011 11:07:06 +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 062D48FC21 for ; Mon, 31 Oct 2011 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VB75xc056784 for ; Mon, 31 Oct 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VB75rc056782 for freebsd-ipfw@FreeBSD.org; Mon, 31 Oct 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Oct 2011 11:07:05 GMT Message-Id: <201110311107.p9VB75rc056782@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, 31 Oct 2011 11:07:06 -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/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 o kern/156770 ipfw [ipfw] [dummynet] [patch]: performance improvement and 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 IPFIREWALL does not allow specify rules with ICMP code 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/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o 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 f kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n p 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/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 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 40 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 2 16:05:24 2011 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 1AFC5106564A for ; Wed, 2 Nov 2011 16:05:24 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 045C88FC12 for ; Wed, 2 Nov 2011 16:05:23 +0000 (UTC) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mail-01.cse.ucsc.edu (Postfix) with ESMTP id 82E281009B90; Wed, 2 Nov 2011 08:46:11 -0700 (PDT) Date: Wed, 2 Nov 2011 08:46:11 -0700 (PDT) From: Tim Gustafson To: freebsd-ipfw@freebsd.org Message-ID: <1048019764.24079.1320248771403.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <1335821625.24060.1320248576610.JavaMail.root@mail-01.cse.ucsc.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_24078_854098216.1320248771394" X-Originating-IP: [128.114.49.22] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 ([unknown])/6.0.9_GA_2686) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IPFW Problems 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: Wed, 02 Nov 2011 16:05:24 -0000 ------=_Part_24078_854098216.1320248771394 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I'm using IPFW on a Jail server. I have system-wide rules set up at the top of my rule-set, like this: 00100 allow ip from any to any via lo0 00101 check-state 00102 allow icmp from me to any keep-state 00103 allow udp from me to any keep-state 00104 allow tcp from me to any keep-state 00105 allow icmp from 1.2.0.0/16 to me keep-state And then each Jail server has a set of rules, like this: 01000 allow tcp from 1.2.0.0/16 to 1.2.3.4 dst-port 22 keep-state 01001 allow tcp from any to 1.2.3.4 dst-port 80 keep-state 01002 allow tcp from any to 1.2.3.4 dst-port 443 keep-state What I've been noticing is that the web server is accumulating a large number of dynamic rules that are not going away, and consequently FreeBSD is keeping a large number of sockets open for long periods of time, which are sending out tons of ACK packets to remote hosts that connected to our web server a long time ago, and have long since closed their side of the TCP connection. I've attached two graphs: one shows the number of dynamic firewall rules over time, and the other shows the number of open sockets over time. Each time I re-load my firewall rules (which includes a "flush"), the graphs drop back down to a reasonable number (hence the sawtooth effect you see in the graph). Can anyone help me understand what is going on here? Have I found some sort of bug, or do I have my firewall incorrectly configured? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------=_Part_24078_854098216.1320248771394-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 2 16:46:52 2011 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 D1337106566C for ; Wed, 2 Nov 2011 16:46:52 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 726558FC12 for ; Wed, 2 Nov 2011 16:46:52 +0000 (UTC) Received: by wwf22 with SMTP id 22so4838115wwf.1 for ; Wed, 02 Nov 2011 09:46:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.204.204 with SMTP id fn12mr6463386wbb.21.1320252411085; Wed, 02 Nov 2011 09:46:51 -0700 (PDT) Received: by 10.180.81.193 with HTTP; Wed, 2 Nov 2011 09:46:51 -0700 (PDT) In-Reply-To: <1048019764.24079.1320248771403.JavaMail.root@mail-01.cse.ucsc.edu> References: <1335821625.24060.1320248576610.JavaMail.root@mail-01.cse.ucsc.edu> <1048019764.24079.1320248771403.JavaMail.root@mail-01.cse.ucsc.edu> Date: Wed, 2 Nov 2011 09:46:51 -0700 Message-ID: From: Michael Sierchio To: Tim Gustafson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Problems 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: Wed, 02 Nov 2011 16:46:52 -0000 On Wed, Nov 2, 2011 at 8:46 AM, Tim Gustafson wrote: > What I've been noticing is that the web server is accumulating a large nu= mber of dynamic rules that are not going away... > Can anyone help me understand what is going on here? =A0Have I found some= sort of bug, or do I have my firewall incorrectly configured? You may want to tweak the sysctl items that control the lifespan of dynamic rules. sysctl net.inet.ip.fw in particular, the default value of net.inet.ip.fw.dyn_ack_lifetime is probably way too long for your purposes. From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 2 16:56:42 2011 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 C8C74106566B for ; Wed, 2 Nov 2011 16:56:42 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id B7E6B8FC12 for ; Wed, 2 Nov 2011 16:56:42 +0000 (UTC) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mail-01.cse.ucsc.edu (Postfix) with ESMTP id 695181009C01; Wed, 2 Nov 2011 09:56:42 -0700 (PDT) Date: Wed, 2 Nov 2011 09:56:42 -0700 (PDT) From: Tim Gustafson To: Michael Sierchio Message-ID: <1475430265.24464.1320253002379.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.114.49.22] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 ([unknown])/6.0.9_GA_2686) Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Problems 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: Wed, 02 Nov 2011 16:56:42 -0000 > You may want to tweak the sysctl items that control the lifespan > of dynamic rules. > > sysctl net.inet.ip.fw > > in particular, the default value of net.inet.ip.fw.dyn_ack_lifetime > is probably way too long for your purposes. Here's what I have right now: root@bsd-02: sysctl net.inet.ip.fw net.inet.ip.fw.static_count: 48 net.inet.ip.fw.default_to_accept: 0 net.inet.ip.fw.tables_max: 128 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.enable: 1 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_max: 32768 net.inet.ip.fw.dyn_count: 805 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 I'm assuming that's in seconds. Is 300 seconds too long? It seems like the dynamic rules are hanging around for hours or days, and I think the timeout is getting reset by the fact that the system is constantly sending out ACK packets to clients that aren't acknowledging them. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-