From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 10 11:06:52 2008 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 B4000106568E for ; Mon, 10 Nov 2008 11:06:52 +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 9B1848FC2B for ; Mon, 10 Nov 2008 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAAB6qPc049751 for ; Mon, 10 Nov 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAAB6qPH049747 for freebsd-ipfw@FreeBSD.org; Mon, 10 Nov 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Nov 2008 11:06:52 GMT Message-Id: <200811101106.mAAB6qPH049747@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, 10 Nov 2008 11:06:52 -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/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 kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 48 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Thu Nov 13 23:19:47 2008 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 7110E1065674 for ; Thu, 13 Nov 2008 23:19:47 +0000 (UTC) (envelope-from ienfant@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 22E0D8FC18 for ; Thu, 13 Nov 2008 23:19:47 +0000 (UTC) (envelope-from ienfant@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so523502ywe.13 for ; Thu, 13 Nov 2008 15:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=tlSmRhSTBymaHrb57MXjGl9cj628/tzc5dojH4xpbj8=; b=UxMbJ2iIGK6GEDa2VFUlswZyYoN11v21R9Kl9z92kXe5JXQt5IGFULNPyZ3FnwnXMQ 3A8J/LQ2JlJfTTFDn3WR+EOAdBpvdJ5DI3KXau9/jlXxrJBtAmcONgog/6lYK3iN+vJn eGLWeU4diLxpLxPjfGe7mlFBojZJVEZ2aOVVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=S9sOA+DaZgU6br0SLvBtOAS0itWFjPjJXelwf/0KRcBIDSR7nNNBUDeUbU2VdYj/g6 f3hWLLNSqIHBf9MrGPcAF/Rti/9NY0NKOTqylmLSAHFd86WdWJjbgdnVLW/mlrkEXeQo zDC+wjQZgvZJUD4Z7ubXJ+wpVzQEvWch9BpFY= Received: by 10.151.103.2 with SMTP id f2mr568282ybm.121.1226616722495; Thu, 13 Nov 2008 14:52:02 -0800 (PST) Received: by 10.151.143.5 with HTTP; Thu, 13 Nov 2008 14:52:02 -0800 (PST) Message-ID: <8db0c7c40811131452v70d2c2fds672384a42da5c5@mail.gmail.com> Date: Fri, 14 Nov 2008 07:52:02 +0900 From: "Son, Yeongsik" To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: change specific linux iptables rule set to ipfw rule set 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: Thu, 13 Nov 2008 23:19:47 -0000 One of linux server contains rule set like these: iptables -A INPUT -p tcp --syn --dport 80 - m connlimit --conlimit-above 20 -j DROP iptables -A INPUT -m recent --name KIN -rcheck --seconds 300 -j DROP iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -m recent --name KIN -set -j DROP simply means, drop ip try to connect tcp port 80 over 20 connections. when it happens, drop ip for 5 minutes. iptables -A INPUT -p udp --dport 53 -m length --length 512:65535 -j DROP briefly, drop ip try to connect udp port 53 which packet length is 512 ~ 65535. I want using those rules on freebsd servers, but I don't know those kind of sophisticated functions of ipfw. Is that possible freebsd? Let me share your knowledge. From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 00:50:15 2008 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 8F4AD1065697 for ; Fri, 14 Nov 2008 00:50:15 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 62AD68FC23 for ; Fri, 14 Nov 2008 00:50:15 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 13 Nov 2008 16:38:54 -0800 Message-ID: <491CC89C.2040702@elischer.org> Date: Thu, 13 Nov 2008 16:38:52 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Son, Yeongsik" References: <8db0c7c40811131452v70d2c2fds672384a42da5c5@mail.gmail.com> In-Reply-To: <8db0c7c40811131452v70d2c2fds672384a42da5c5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: change specific linux iptables rule set to ipfw rule set 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: Fri, 14 Nov 2008 00:50:15 -0000 Son, Yeongsik wrote: > One of linux server contains rule set like these: > > iptables -A INPUT -p tcp --syn --dport 80 - m connlimit --conlimit-above 20 > -j DROP > iptables -A INPUT -m recent --name KIN -rcheck --seconds 300 -j DROP > iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 > -m recent --name KIN -set -j DROP > > simply means, > drop ip try to connect tcp port 80 over 20 connections. > when it happens, drop ip for 5 minutes. > > iptables -A INPUT -p udp --dport 53 -m length --length 512:65535 -j DROP > > briefly, > drop ip try to connect udp port 53 which packet length is 512 ~ 65535. > > I want using those rules on freebsd servers, but I don't know those kind of > sophisticated functions of ipfw. > > Is that possible freebsd? not in ipfw but I think pf can do that. Some people may have done that with ipfw using an external agent, but I don't know who/how. > > Let me share your knowledge. > _______________________________________________ > 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" From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 02:18:34 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFBF1065680; Fri, 14 Nov 2008 02:18:34 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id E803D8FC12; Fri, 14 Nov 2008 02:18:33 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 13 Nov 2008 17:50:09 -0800 Message-ID: <491CD94F.3020207@elischer.org> Date: Thu, 13 Nov 2008 17:50:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: FreeBSD Net , ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: rc.firewall quick change 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: Fri, 14 Nov 2008 02:18:34 -0000 At home I use the following change. basically, instead of doing 8 rules before and after the nat, use a table and to 1 rule on each side. any objections? (warning, cut-n-paste patch.. will not apply) Index: rc.firewall =================================================================== --- rc.firewall (revision 184948) +++ rc.firewall (working copy) @@ -231,19 +231,24 @@ ${fwcmd} add deny all from ${onet} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} + ${fwcmd} table 1 add 10.0.0.0/8 + ${fwcmd} table 1 add 172.16.0.0/12 + ${fwcmd} table 1 add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} + ${fwcmd} table 1 add 0.0.0.0/8 + ${fwcmd} table 1 add 169.254.0.0/16 + ${fwcmd} table 1 add 192.0.2.0/24 + ${fwcmd} table 1 add 224.0.0.0/4 + ${fwcmd} table 1 add 240.0.0.0/4 + # Stop the above nets with the table + + ${fwcmd} add deny all from any to "table(1)" via ${oif} + + # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP @@ -260,19 +265,8 @@ esac # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + ${fwcmd} add deny all from "table(1)" to any via ${oif} - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) - # on the outside interface - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} - # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 03:11:13 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16980106564A; Fri, 14 Nov 2008 03:11:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5A34A8FC0A; Fri, 14 Nov 2008 03:11:12 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAE2rSLe051643; Fri, 14 Nov 2008 13:53:28 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 14 Nov 2008 13:53:28 +1100 (EST) From: Ian Smith To: net@freebsd.org, ipfw@freebsd.org Message-ID: <20081114134925.E70117@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Subject: Re: Speaking of rc.firewall .. (fwd) 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: Fri, 14 Nov 2008 03:11:13 -0000 ---------- Forwarded message ---------- Date: Fri, 17 Oct 2008 05:24:43 +1100 (EST) From: Ian Smith To: freebsd-ipfw@freebsd.org Subject: Re: Speaking of rc.firewall .. On Thu, 16 Oct 2008, Ian Smith wrote: > I see that both HEAD and RELENG_7 rc.firewall have been updated for in- > kernel NAT functionality, but only for the 'open' and 'client' rulesets. > > Is there any (functional) reason that the ${firewall_nat_enable} case is > not also included in the 'simple' rules, where its different placement > is determined by being preceded and anteceded by anti-spoofing rules? > > I'm also slightly bemused by the lack (still) of any rules to allow any > ICMP (especially necessary icmptypes for MTU discovery) in 'simple'? To put my patch where my mouth is, assuming that the answer to my first question is likely 'no', this is against the present RELENG_7 version. It addresses the second (ICMP) issue for 'client' and 'simple', and I see no harm in enabling outbound pings for such out-of-the-box setups? Hope this format's useful (just diff -u), and also that inline is ok. cheers, Ian --- rc.firewall.1.52.2.3 Fri Oct 17 01:34:56 2008 +++ rc.firewall Fri Oct 17 04:27:36 2008 @@ -116,15 +116,14 @@ # will then be run again on each packet after translation by natd # starting at the rule number following the divert rule. # -# For ``simple'' firewall type the divert rule should be put to a +# For ``simple'' firewall type the divert rule is included in a # different place to not interfere with address-checking rules. # -case ${firewall_type} in -[Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt]) +setup_nat () { case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} + ${fwcmd} add $1 divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -138,11 +137,11 @@ firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} - ${fwcmd} add 50 nat 123 ip4 from any to any via ${firewall_nat_interface} + ${fwcmd} add $1 nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac -esac +} ############ # If you just configured ipfw in the kernel as a tool to solve network @@ -157,6 +156,7 @@ # case ${firewall_type} in [Oo][Pp][Ee][Nn]) + setup_nat 50 ${fwcmd} add 65000 pass all from any to any ;; @@ -172,6 +172,8 @@ # set this to your local network net="$firewall_client_net" + setup_nat 50 + # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me @@ -197,6 +199,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + # Allow outbound pings + ${fwcmd} add pass icmp from me to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 + # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. @@ -248,13 +256,7 @@ # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. - case ${natd_enable} in - [Yy][Ee][Ss]) - if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} - fi - ;; - esac + setup_nat # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} @@ -298,6 +300,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + + # Allow outbound pings from our net + ${fwcmd} add pass icmp from any to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 03:11:14 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61F301065678; Fri, 14 Nov 2008 03:11:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id A5E388FC1C; Fri, 14 Nov 2008 03:11:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAE2mfhe051406; Fri, 14 Nov 2008 13:48:41 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 14 Nov 2008 13:48:41 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <491CD94F.3020207@elischer.org> Message-ID: <20081114133913.K70117@sola.nimnet.asn.au> References: <491CD94F.3020207@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change 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: Fri, 14 Nov 2008 03:11:14 -0000 On Thu, 13 Nov 2008, Julian Elischer wrote: > At home I use the following change. > > > basically, instead of doing 8 rules before and after the nat, > use a table and to 1 rule on each side. > > > any objections? Only that if people are already using tables for anything, chances are they've already used table 1 (well, it's the first one I used :) How about using table 127 for this as a rather less likely prior choice? Apart from that, this will speed up 'simple' on a path every packet takes, which has to be a good thing. While I'm at it, I'll offer my own rc.firewall patch again in the following message. Perhaps you'd care to review it in this context? cheers, Ian > (warning, cut-n-paste patch.. will not apply) > > Index: rc.firewall > =================================================================== > --- rc.firewall (revision 184948) > +++ rc.firewall (working copy) > @@ -231,19 +231,24 @@ > ${fwcmd} add deny all from ${onet} to any in via ${iif} > > # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} > - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} > + ${fwcmd} table 1 add 10.0.0.0/8 > + ${fwcmd} table 1 add 172.16.0.0/12 > + ${fwcmd} table 1 add 192.168.0.0/16 > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > RESERVED-1, > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > E) > # on the outside interface > - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} > - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} > - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} > - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} > + ${fwcmd} table 1 add 0.0.0.0/8 > + ${fwcmd} table 1 add 169.254.0.0/16 > + ${fwcmd} table 1 add 192.0.2.0/24 > + ${fwcmd} table 1 add 224.0.0.0/4 > + ${fwcmd} table 1 add 240.0.0.0/4 > > + # Stop the above nets with the table > + > + ${fwcmd} add deny all from any to "table(1)" via ${oif} > + > + > # Network Address Translation. This rule is placed here deliberately > # so that it does not interfere with the surrounding address-checking > # rules. If for example one of your internal LAN machines had its IP > @@ -260,19 +265,8 @@ > esac > > # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} > - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} > + ${fwcmd} add deny all from "table(1)" to any via ${oif} > > - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > RESERVED-1, > - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > E) > - # on the outside interface > - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} > - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} > - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} > - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} > - > # Allow TCP through if setup succeeded > ${fwcmd} add pass tcp from any to any established > > _______________________________________________ > 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" > From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 08:31:26 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7AD81065675; Fri, 14 Nov 2008 08:31:26 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9EA8FC17; Fri, 14 Nov 2008 08:31:26 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 00:31:26 -0800 Message-ID: <491D375D.1070809@elischer.org> Date: Fri, 14 Nov 2008 00:31:25 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Ian Smith References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> In-Reply-To: <20081114133913.K70117@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change 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: Fri, 14 Nov 2008 08:31:26 -0000 Ian Smith wrote: > On Thu, 13 Nov 2008, Julian Elischer wrote: > > At home I use the following change. > > > > > > basically, instead of doing 8 rules before and after the nat, > > use a table and to 1 rule on each side. > > > > > > any objections? > > Only that if people are already using tables for anything, chances are > they've already used table 1 (well, it's the first one I used :) How > about using table 127 for this as a rather less likely prior choice? yes I thought of that.. in fact it should be ${BLOCKTABLE} and let the user define what he wants. (defaulting to 99 or something). Remember though that a user wouldn't be using 'simple' if he's using his own tables etc. > > Apart from that, this will speed up 'simple' on a path every packet > takes, which has to be a good thing. > > While I'm at it, I'll offer my own rc.firewall patch again in the > following message. Perhaps you'd care to review it in this context? > > cheers, Ian > > > (warning, cut-n-paste patch.. will not apply) > > > > Index: rc.firewall > > =================================================================== > > --- rc.firewall (revision 184948) > > +++ rc.firewall (working copy) > > @@ -231,19 +231,24 @@ > > ${fwcmd} add deny all from ${onet} to any in via ${iif} > > > > # Stop RFC1918 nets on the outside interface > > - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} > > - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} > > - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} > > + ${fwcmd} table 1 add 10.0.0.0/8 > > + ${fwcmd} table 1 add 172.16.0.0/12 > > + ${fwcmd} table 1 add 192.168.0.0/16 > > > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > > RESERVED-1, > > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > > E) > > # on the outside interface > > - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} > > - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} > > - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} > > - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} > > - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} > > + ${fwcmd} table 1 add 0.0.0.0/8 > > + ${fwcmd} table 1 add 169.254.0.0/16 > > + ${fwcmd} table 1 add 192.0.2.0/24 > > + ${fwcmd} table 1 add 224.0.0.0/4 > > + ${fwcmd} table 1 add 240.0.0.0/4 > > > > + # Stop the above nets with the table > > + > > + ${fwcmd} add deny all from any to "table(1)" via ${oif} > > + > > + > > # Network Address Translation. This rule is placed here deliberately > > # so that it does not interfere with the surrounding address-checking > > # rules. If for example one of your internal LAN machines had its IP > > @@ -260,19 +265,8 @@ > > esac > > > > # Stop RFC1918 nets on the outside interface > > - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > > - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} > > - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} > > + ${fwcmd} add deny all from "table(1)" to any via ${oif} > > > > - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > > RESERVED-1, > > - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > > E) > > - # on the outside interface > > - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} > > - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} > > - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} > > - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} > > - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} > > - > > # Allow TCP through if setup succeeded > > ${fwcmd} add pass tcp from any to any established > > > > _______________________________________________ > > 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" From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 09:10:08 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF67F106564A; Fri, 14 Nov 2008 09:10:08 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4878FC08; Fri, 14 Nov 2008 09:10:08 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 01:10:08 -0800 Message-ID: <491D406F.5030806@elischer.org> Date: Fri, 14 Nov 2008 01:10:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Ian Smith References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> In-Reply-To: <491D375D.1070809@elischer.org> Content-Type: multipart/mixed; boundary="------------030006060207050901060508" Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change 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: Fri, 14 Nov 2008 09:10:09 -0000 This is a multi-part message in MIME format. --------------030006060207050901060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > Ian Smith wrote: >> On Thu, 13 Nov 2008, Julian Elischer wrote: >> > At home I use the following change. >> > > > basically, instead of doing 8 rules before and after the nat, >> > use a table and to 1 rule on each side. >> > > > any objections? >> >> Only that if people are already using tables for anything, chances are >> they've already used table 1 (well, it's the first one I used :) How >> about using table 127 for this as a rather less likely prior choice? > > yes I thought of that.. > in fact it should be ${BLOCKTABLE} and let the user define what he > wants. (defaulting to 99 or something). > Remember though that a user wouldn't be using 'simple' if he's using his > own tables etc. > so here's a slightly improved diff: --------------030006060207050901060508 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ipfw.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw.diff" Index: rc.firewall =================================================================== --- rc.firewall (revision 184948) +++ rc.firewall (working copy) @@ -216,11 +216,13 @@ # firewall_simple_inet: Inside network address. # firewall_simple_oif: Outside network interface. # firewall_simple_onet: Outside network address. + # firewall_block_table: Table to use blocking stuff. ############ # set these to your outside interface network oif="$firewall_simple_oif" onet="$firewall_simple_onet" + tbl=${firewall_block_table:-99} # set these to your inside interface network iif="$firewall_simple_iif" @@ -231,19 +233,24 @@ ${fwcmd} add deny all from ${onet} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} + ${fwcmd} table ${tbl} add 10.0.0.0/8 + ${fwcmd} table ${tbl} add 172.16.0.0/12 + ${fwcmd} table ${tbl} add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} + ${fwcmd} table ${tbl} add 0.0.0.0/8 + ${fwcmd} table ${tbl} add 169.254.0.0/16 + ${fwcmd} table ${tbl} add 192.0.2.0/24 + ${fwcmd} table ${tbl} add 224.0.0.0/4 + ${fwcmd} table ${tbl} add 240.0.0.0/4 + # Stop the above nets with the table + + ${fwcmd} add deny all from any to "table(${tbl})" via ${oif} + + # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP @@ -260,19 +267,8 @@ esac # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + ${fwcmd} add deny all from "table(${tbl})" to any via ${oif} - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) - # on the outside interface - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} - # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established --------------030006060207050901060508-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 10:38:29 2008 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67FF1065674; Fri, 14 Nov 2008 10:38:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 382A78FC1A; Fri, 14 Nov 2008 10:38:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mAEAM3PT022097; Fri, 14 Nov 2008 21:22:03 +1100 Received: from c122-106-151-199.carlnfd1.nsw.optusnet.com.au (c122-106-151-199.carlnfd1.nsw.optusnet.com.au [122.106.151.199]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mAEALt9I015701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 21:21:58 +1100 Date: Fri, 14 Nov 2008 21:21:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Julian Elischer In-Reply-To: <491D375D.1070809@elischer.org> Message-ID: <20081114211043.W54700@delplex.bde.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith Subject: Re: rc.firewall quick change 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: Fri, 14 Nov 2008 10:38:30 -0000 On Fri, 14 Nov 2008, Julian Elischer wrote: > Ian Smith wrote: >> On Thu, 13 Nov 2008, Julian Elischer wrote: >> > At home I use the following change. >> > > > basically, instead of doing 8 rules before and after the nat, >> > use a table and to 1 rule on each side. >> > > > any objections? >> >> Only that if people are already using tables for anything, chances are >> they've already used table 1 (well, it's the first one I used :) How about >> using table 127 for this as a rather less likely prior choice? > > yes I thought of that.. Separate rules provide more statistics. > in fact it should be ${BLOCKTABLE} and let the user define what he wants. > (defaulting to 99 or something). I use shell variables giving lists of interfaces to be blocked so that there aren't very many rules: %%% rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 ${fwcmd} add deny log all from any to ${rfc1918n} via ${oif} ${fwcmd} add deny log all from any to ${dmanningn} via ${oif} ... (divert rule) ${fwcmd} add deny log all from ${rfc1918n} to any via ${oif} ${fwcmd} add deny log all from ${dmanningn} to any via ${oif} %%% I use separate lists mainly for documentation purposes but they also provide separate statistics. > Remember though that a user wouldn't be using 'simple' if he's using his own > tables etc. Separate rules are also simplest for documentation purposes. >> Apart from that, this will speed up 'simple' on a path every packet takes, >> which has to be a good thing. Are tables faster than lists of addresses? I would expect lists to be slightly more efficient. Bruce From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 18:16:27 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD8C106567A; Fri, 14 Nov 2008 18:16:27 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id C8E298FC13; Fri, 14 Nov 2008 18:16:27 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 10:16:28 -0800 Message-ID: <491DC07B.6070304@elischer.org> Date: Fri, 14 Nov 2008 10:16:27 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Bruce Evans References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> In-Reply-To: <20081114211043.W54700@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith Subject: Re: rc.firewall quick change 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: Fri, 14 Nov 2008 18:16:28 -0000 Bruce Evans wrote: > On Fri, 14 Nov 2008, Julian Elischer wrote: > >> Ian Smith wrote: >>> On Thu, 13 Nov 2008, Julian Elischer wrote: >>> > At home I use the following change. >>> > > > basically, instead of doing 8 rules before and after the nat, >>> > use a table and to 1 rule on each side. >>> > > > any objections? >>> >>> Only that if people are already using tables for anything, chances >>> are they've already used table 1 (well, it's the first one I used :) >>> How about using table 127 for this as a rather less likely prior choice? >> >> yes I thought of that.. > > Separate rules provide more statistics. true but generally people don't need to distinguish between those, and if you do then you probably want to log them. > >> in fact it should be ${BLOCKTABLE} and let the user define what he >> wants. (defaulting to 99 or something). > > I use shell variables giving lists of interfaces to be blocked so that > there aren't very many rules: > > %%% > rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 > dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 > > ${fwcmd} add deny log all from any to ${rfc1918n} via ${oif} > ${fwcmd} add deny log all from any to ${dmanningn} via ${oif} > > ... (divert rule) > > ${fwcmd} add deny log all from ${rfc1918n} to any via ${oif} > ${fwcmd} add deny log all from ${dmanningn} to any via ${oif} > %%% > > I use separate lists mainly for documentation purposes but they also > provide separate statistics. > >> Remember though that a user wouldn't be using 'simple' if he's using >> his own tables etc. > > Separate rules are also simplest for documentation purposes. > >>> Apart from that, this will speed up 'simple' on a path every packet >>> takes, which has to be a good thing. > > Are tables faster than lists of addresses? I would expect lists to be > slightly more efficient. I think the table is faster for mor ethan about 8 addresses (so we are borderline) but it's be hard to test.. You however use two rules so that would be slower. In my sites I tend to have other stuff put in those tables too > > Bruce From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 20:34:10 2008 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8277E106564A for ; Fri, 14 Nov 2008 20:34:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 20D458FC14 for ; Fri, 14 Nov 2008 20:34:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 6497 invoked by uid 399); 14 Nov 2008 20:07:29 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Nov 2008 20:07:29 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <491DDA7F.1040004@FreeBSD.org> Date: Fri, 14 Nov 2008 12:07:27 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.17 (X11/20081010) MIME-Version: 1.0 To: Julian Elischer References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> In-Reply-To: <491DC07B.6070304@elischer.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith , Bruce Evans Subject: Re: rc.firewall quick change 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: Fri, 14 Nov 2008 20:34:10 -0000 Julian Elischer wrote: > I think the table is faster for mor ethan about 8 addresses (so we > are borderline) but it's be hard to test.. You however use two rules > so that would be slower. I'm not a firewall expert so I won't comment on the specifics but I do want to say that as a general rule "it works + fast/efficient" is MUCH more important for default settings than "it works really well" or "it works + more features." For better or worse we live in a world where most users don't read the manuals, and that includes the ones running "benchmarks" with default settings. OTOH I do think it would be entirely appropriate to include a "better" example commented out next to the "fast" default. I take a similar approach with the default named.conf and have had good feedback from users who appreciate pointers to more information when they actually do get curious. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 20:49:50 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C093106564A; Fri, 14 Nov 2008 20:49:50 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 03F568FC08; Fri, 14 Nov 2008 20:49:49 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 12:49:50 -0800 Message-ID: <491DE46D.8070205@elischer.org> Date: Fri, 14 Nov 2008 12:49:49 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Doug Barton References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> <491DDA7F.1040004@FreeBSD.org> In-Reply-To: <491DDA7F.1040004@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith , Bruce Evans Subject: Re: rc.firewall quick change 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: Fri, 14 Nov 2008 20:49:50 -0000 Doug Barton wrote: > Julian Elischer wrote: >> I think the table is faster for mor ethan about 8 addresses (so we >> are borderline) but it's be hard to test.. You however use two rules >> so that would be slower. > > I'm not a firewall expert so I won't comment on the specifics but I do > want to say that as a general rule "it works + fast/efficient" is MUCH > more important for default settings than "it works really well" or "it > works + more features." For better or worse we live in a world where > most users don't read the manuals, and that includes the ones running > "benchmarks" with default settings. I think the change is better from the point of view that it is easier to read (for me) and behaves better. > > OTOH I do think it would be entirely appropriate to include a "better" > example commented out next to the "fast" default. I take a similar > approach with the default named.conf and have had good feedback from > users who appreciate pointers to more information when they actually > do get curious. > > > hth, > > Doug > From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 15 05:51:58 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC1B1065670; Sat, 15 Nov 2008 05:51:58 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 78A298FC12; Sat, 15 Nov 2008 05:51:57 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAF5pp4a005289; Sat, 15 Nov 2008 16:51:52 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 15 Nov 2008 16:51:51 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <491D406F.5030806@elischer.org> Message-ID: <20081115024024.O70117@sola.nimnet.asn.au> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <491D406F.5030806@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change 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: Sat, 15 Nov 2008 05:51:58 -0000 On Fri, 14 Nov 2008, Julian Elischer wrote: > Julian Elischer wrote: > > Ian Smith wrote: > > > On Thu, 13 Nov 2008, Julian Elischer wrote: > > > > At home I use the following change. > > > > > > basically, instead of doing 8 rules before and after the nat, > > > > use a table and to 1 rule on each side. > > > > > > any objections? > > > > > > Only that if people are already using tables for anything, chances are > > > they've already used table 1 (well, it's the first one I used :) How > > > about using table 127 for this as a rather less likely prior choice? > > > > yes I thought of that.. > > in fact it should be ${BLOCKTABLE} and let the user define what he wants. > > (defaulting to 99 or something). I prefer binary, but whatever :) > > Remember though that a user wouldn't be using 'simple' if he's using his > > own tables etc. This is an important point. Please allow me a little pent-up critique: Originally, eg for me over 10 years ago, till recently, the only way to use the 'client' or 'simple' rulesets was to hack rc.firewall, which I did relentlessly, like many people I'm sure .. that is, we treated it more as a starter example, not something that could be used as is. More recent updates have introduced rc vars that concievably make these rulesets usable out of the box, in as much as you could tell a newbie to FreeBSD firewalls and ipfw in particular, "setup these vars for your network, select the 'client' or 'simple' ruleset as appropriate, and you have a fair chance of having a fairly functional and reasonably secure firewall to get yourself online and going until you learn a bit more". Combined with the deprecatory and in many instances just plain erroneous info in the only section of the Handbook that I've felt to try rewriting more or less from scratch - ie the ipfw part of the firewall chapter 31, which suggests some quite (to me) bizarre example rulesets after having dissed using the rc.firewall rulesets out of hand - we're not doing much good at advocating new users trying ipfw, which I think does it some injustice. Not intending here to deprecate pf or ipf in any way. Anyhow, this leaves us with two good reasons that 'client' and 'simple' sections ought to work effectively: secondly as an example illustrating good techniques - and I think your use of a table that the user can add entries to out of band for such as blackholing hosts/nets without having to reconfigure or restart the firewall IS good technique - but firstly as a basically functional and secure minimal firewall in and of itself. It's for both those reasons (and fixing an apparent oversight) that I've offered my unreviewed patch (which I'll do properly by PR if anyone says it's worth pursuing), after years of not being able to fathom supposedly usable firewall configuration for a client or small net, with or without NAT, that has never passed =ANY= ICMP traffic, not even to or from the hosts in one's own net! Am I missing something, thinking that matters, and that functioning path MTU discovery matters? > so here's a slightly improved diff: This may be a bit nitpicky, but how about keeping the firewall_simple_* varset naming consistent, maybe firewall_simple_blocktable or something? The 'workstation' vars have kinda busted that idea anyway, but still .. Also maybe rephrase mentioning the draft-manning-blah after the divert? HTH, Ian From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 15 22:04:43 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E42931065673 for ; Sat, 15 Nov 2008 22:04:43 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by mx1.freebsd.org (Postfix) with SMTP id D18DF8FC17 for ; Sat, 15 Nov 2008 22:04:43 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: (qmail 87691 invoked from network); 15 Nov 2008 21:38:03 -0000 Received: from unknown (HELO ?192.168.2.14?) (jguojun@75.37.2.43 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 15 Nov 2008 21:38:03 -0000 X-YMail-OSG: U3QdqWsVM1kFQUyMNBbD_ENy9LroQxs_4nbeez3GnWNCir9Q7Uy02MnmpCUPFECFVIiAxNefHSZu_Lwf3KIFwglqfvIGcrUIVb2gLhcOuXfRSp3duyvbyYiWmFFnzmBlBdA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <491F413A.4020108@gmail.com> Date: Sat, 15 Nov 2008 13:38:02 -0800 From: "Jin Guojun[VFF]" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20071201 X-Accept-Language: en, zh, zh-CN MIME-Version: 1.0 To: questions@freebsd.org, ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: some ipfw filter does not function under Release 6.3 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: Sat, 15 Nov 2008 22:04:44 -0000 Below is set of ipfw rules, but it seems that not all rules are functioning properly. From rule 361 to first two of rule 567 are not blocking any traffic and not measuring any traffic. Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a known issue in R-6.3? The second and third rules in rule set 567 seem working well. -Jin ---------------- ipfw rule sets --------- 00330 3108378 2700826874 allow tcp from any to any established 00361 0 0 deny ip from 203.83.248.93 to any 00361 0 0 deny ip from 72.30.142.215 to any 00567 0 0 deny ip from 193.200.241.171 to any 00567 0 0 deny ip from 221.192.199.36 to any 00567 3 180 deny ip from 118.153.18.186 to any 00567 3 180 deny ip from 203.78.214.180 to any 00567 0 0 deny ip from 118.219.232.123 to any 65500 220 20043 allow udp from any to any 65535 2 120 deny ip from any to any ------ traffic captured by tcpdump behind ipfw machine ----- 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200229998:200229998(0) win 8192 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200229999:200229999(0) win 0 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200233658:200233658(0) win 8192 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200233659:200233659(0) win 0 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200244634:200244634(0) win 8192 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200244635:200244635(0) win 0 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S 2422872529:2422872529(0) win 65535 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack 3968474717 win 65535 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) ack 1 win 65535 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) ack 473 win 0 From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 15 22:51:09 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBBC1065688 for ; Sat, 15 Nov 2008 22:51:09 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2DAF88FC14 for ; Sat, 15 Nov 2008 22:51:09 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:65257 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1L1TkF-0003L1-6V for ipfw@freebsd.org; Sat, 15 Nov 2008 23:35:59 +0100 Received: (qmail 25870 invoked from network); 15 Nov 2008 23:35:56 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 15 Nov 2008 23:35:56 +0100 Received: (qmail 49044 invoked by uid 1001); 15 Nov 2008 23:35:56 +0100 Date: Sat, 15 Nov 2008 23:35:56 +0100 From: Erik Trulsson To: "Jin Guojun\[VFF\]" Message-ID: <20081115223556.GA45503@owl.midgard.homeip.net> References: <491F413A.4020108@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <491F413A.4020108@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1L1TkF-0003L1-6V. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1L1TkF-0003L1-6V 22e0fbebd77daa630ac2ea70ee8485db Cc: questions@freebsd.org, ipfw@freebsd.org Subject: Re: some ipfw filter does not function under Release 6.3 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: Sat, 15 Nov 2008 22:51:09 -0000 On Sat, Nov 15, 2008 at 01:38:02PM -0800, Jin Guojun[VFF] wrote: > Below is set of ipfw rules, but it seems that not all rules are > functioning properly. > From rule 361 to first two of rule 567 are not blocking any traffic and > not measuring any traffic. > Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a > known issue in R-6.3? In general the first matching rule is the one that is applied. In your case this means that if a packet matches your rule 330 then it will be allowed through, and the rules further down the list will not be considered. > > The second and third rules in rule set 567 seem working well. > > -Jin > > ---------------- ipfw rule sets --------- > 00330 3108378 2700826874 allow tcp from any to any established > 00361 0 0 deny ip from 203.83.248.93 to any > 00361 0 0 deny ip from 72.30.142.215 to any > 00567 0 0 deny ip from 193.200.241.171 to any > 00567 0 0 deny ip from 221.192.199.36 to any > 00567 3 180 deny ip from 118.153.18.186 to any > 00567 3 180 deny ip from 203.78.214.180 to any > 00567 0 0 deny ip from 118.219.232.123 to any > 65500 220 20043 allow udp from any to any > 65535 2 120 deny ip from any to any > > ------ traffic captured by tcpdump behind ipfw machine ----- > > 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200229998:200229998(0) win 8192 > 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200229999:200229999(0) win 0 > 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200233658:200233658(0) win 8192 > 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200233659:200233659(0) win 0 > 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200244634:200244634(0) win 8192 > 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200244635:200244635(0) win 0 > 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S > 2422872529:2422872529(0) win 65535 > 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack > 3968474717 win 65535 > 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) > ack 1 win 65535 > 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) > ack 473 win 0 > -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 15 23:00:55 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6402D1065687 for ; Sat, 15 Nov 2008 23:00:55 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by mx1.freebsd.org (Postfix) with SMTP id 4E2B78FC0C for ; Sat, 15 Nov 2008 23:00:55 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: (qmail 77567 invoked from network); 15 Nov 2008 23:00:55 -0000 Received: from unknown (HELO ?192.168.2.17?) (jguojun@75.37.2.43 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 15 Nov 2008 23:00:54 -0000 X-YMail-OSG: cIasTBsVM1kzMeOW0w0xsZfaTyQWBdrqEY7A0r9NwpN.0kzR.abbcI0G1z2KQOZ7nnilps_k5o8W8EcbaQwEIrWSkUy8XBCLFePVYB316LEiPSUF8b77cxz1iw72VcHB99GR3VJ8SpNj2tApFLlAU6jwWDmB5GCL4rvEiIA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <491F54A0.9090702@gmail.com> Date: Sat, 15 Nov 2008 15:00:48 -0800 From: "Jin Guojun[VFF]" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20071201 X-Accept-Language: en, zh, zh-CN To: Erik Trulsson References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> In-Reply-To: <20081115223556.GA45503@owl.midgard.homeip.net> Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: questions@freebsd.org, ipfw@freebsd.org Subject: Re: some ipfw filter does not function under Release 6.3 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: Sat, 15 Nov 2008 23:00:55 -0000 But the rule 330 should only allow established TCP pass through. In other words, Sync should NOT allowed by rule 330, or I missed something for this rule? Erik Trulsson wrote: On Sat, Nov 15, 2008 at 01:38:02PM -0800, Jin Guojun[VFF] wrote: Below is set of ipfw rules, but it seems that not all rules are functioning properly. From rule 361 to first two of rule 567 are not blocking any traffic and not measuring any traffic. Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a known issue in R-6.3? In general the first matching rule is the one that is applied. In your case this means that if a packet matches your rule 330 then it will be allowed through, and the rules further down the list will not be considered. The second and third rules in rule set 567 seem working well. -Jin ---------------- ipfw rule sets --------- 00330 3108378 2700826874 allow tcp from any to any established 00361 0 0 deny ip from 203.83.248.93 to any 00361 0 0 deny ip from 72.30.142.215 to any 00567 0 0 deny ip from 193.200.241.171 to any 00567 0 0 deny ip from 221.192.199.36 to any 00567 3 180 deny ip from 118.153.18.186 to any 00567 3 180 deny ip from 203.78.214.180 to any 00567 0 0 deny ip from 118.219.232.123 to any 65500 220 20043 allow udp from any to any 65535 2 120 deny ip from any to any ------ traffic captured by tcpdump behind ipfw machine ----- 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200229998:200229998(0) win 8192 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200229999:200229999(0) win 0 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200233658:200233658(0) win 8192 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200233659:200233659(0) win 0 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200244634:200244634(0) win 8192 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200244635:200244635(0) win 0 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S 2422872529:2422872529(0) win 65535 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack 3968474717 win 65535 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) ack 1 win 65535 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) ack 473 win 0