From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 9 17:15:07 2009 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B5891065697 for ; Mon, 9 Mar 2009 17:15:07 +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 1777F8FC2E for ; Mon, 9 Mar 2009 17:15:07 +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 n29HF6Jq045286 for ; Mon, 9 Mar 2009 17:15:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n29HF6BK045282 for freebsd-ipfw@FreeBSD.org; Mon, 9 Mar 2009 17:15:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Mar 2009 17:15:06 GMT Message-Id: <200903091715.n29HF6BK045282@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, 09 Mar 2009 17:15:07 -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/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 55 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 12 06:23:31 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B11FE106564A; Thu, 12 Mar 2009 06:23:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 83A978FC2F; Thu, 12 Mar 2009 06:23:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2C6NVSt070063; Thu, 12 Mar 2009 06:23:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2C6NVcW070059; Thu, 12 Mar 2009 06:23:31 GMT (envelope-from linimon) Date: Thu, 12 Mar 2009 06:23:31 GMT Message-Id: <200903120623.n2C6NVcW070059@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/132553: [ipfw] ipfw doesn't understand ftp-data port 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, 12 Mar 2009 06:23:35 -0000 Old Synopsis: ipfw doesnt understand ftp-data port New Synopsis: [ipfw] ipfw doesn't understand ftp-data port Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 12 06:22:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132553 From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 13 13:31:19 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FEDE106564A for ; Fri, 13 Mar 2009 13:31:19 +0000 (UTC) (envelope-from sebastian.mellmann@net.t-labs.tu-berlin.de) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id 226B58FC28 for ; Fri, 13 Mar 2009 13:31:18 +0000 (UTC) (envelope-from sebastian.mellmann@net.t-labs.tu-berlin.de) Received: from [192.168.1.2] (e179077073.adsl.alicedsl.de [85.179.77.73]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id AE9C3700D498; Fri, 13 Mar 2009 14:31:17 +0100 (CET) Message-ID: <49BA6027.3020004@net.t-labs.tu-berlin.de> Date: Fri, 13 Mar 2009 14:31:19 +0100 From: Sebastian Mellmann User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ian Smith References: <5431.62.206.221.107.1236336345.squirrel@anubis.getmyip.com> <20090306234700.F71460@sola.nimnet.asn.au> In-Reply-To: <20090306234700.F71460@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: Can't see other flows in pipe 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, 13 Mar 2009 13:31:19 -0000 > On Fri, 6 Mar 2009, Sebastian Mellmann wrote: > [.. after merciless snippage ..] > > > $cmd pipe 500 config bw $bottleneck_bandwidth > > $cmd add pipe 500 all from any to any via $in_if > > > > $cmd pipe 510 config bw $bottleneck_bandwidth > > $cmd add pipe 510 all from any to any via $out_if > > > ipfw pipe show gives me the following: > > > > 00510: 100.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > > Pkt/Byte Drp > > 0 tcp 192.168.5.4/47753 192.168.7.1/22 610244 609078476 2 > > 104 1 > > > 00500: 100.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > > Pkt/Byte Drp > > 0 tcp 192.168.5.4/47753 192.168.7.1/22 609337 607754332 2 > > 1552 0 > > > Why do I only see ONE connection inside the 500/510 pipe? > > I thought I could see any connection going through that pipe. > > With no masking specified, all flows use the same bucket (0) so totals > shown are of all packets through that pipe. src/dest addr/ports shown > are those of the first packet using that bucket, not the most recent. > > Ok that makes sense. But when I have a look at the "drop" value does it tell me the overall drops in that pipe or only the drops for the specific flow (in this case between 192.168.5.4 and 192.168.7.1)? > You may also find http://info.iet.unipi.it/~luigi/ip_dummynet/ helpful. > > cheers, Ian > Thanks for the help! Regards, Sebastian From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 13 21:06:20 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 564D1106567B for ; Fri, 13 Mar 2009 21:06:20 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp5.apollo.lv (smtp5.apollo.lv [80.232.168.197]) by mx1.freebsd.org (Postfix) with ESMTP id 11F7F8FC1E for ; Fri, 13 Mar 2009 21:06:19 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from [81.198.53.40] (unknown [81.198.53.40]) by smtp5.apollo.lv (Postfix) with ESMTP id 9BB8130E041 for ; Fri, 13 Mar 2009 22:47:20 +0200 (EET) From: Dmitriy Demidov To: freebsd-ipfw@freebsd.org Date: Fri, 13 Mar 2009 22:46:48 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903132246.49159.dima_bsd@inbox.lv> X-Lattelecom-MailScanner-Information: Please contact the ISP for more information X-Lattelecom-MailScanner-ID: 9BB8130E041.A5552 X-Lattelecom-MailScanner: Found to be clean X-Lattelecom-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.806, required 5, BAYES_00 -2.60, RDNS_NONE 0.10, SPF_FAIL 0.69) X-Lattelecom-MailScanner-From: dima_bsd@inbox.lv X-Spam-Status: No Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 13 Mar 2009 21:06:20 -0000 Hi list. I'm using DNS cache server Unbound-1.2.1. I want to start using DNSSEC via DLV (unbound gracefully allows it). My system is FreeBSD7-STABLE. I'm using ipfw. Original ipfw configuration: add check-state add deny icmp from any to any frag add allow icmp from any to me icmptypes 0,3,11 add allow icmp from me to any out keep-state add allow tcp from me to any out keep-state add allow udp from me to any out keep-state add deny ip from any to any /etc/sysctl.conf net.inet.ip.fw.dyn_udp_lifetime=60 The problem is that Unbound can't do DNSSEC validation using this firewall configuration. It blames some thing like this: [1236970569] unbound[9096:3] info: resolving [1236970569] unbound[9096:3] info: failed to prime trust anchor -- could not fetch DNSKEY rrset [1236970569] unbound[9096:3] info: Could not establish a chain of trust to keys for Unbound starts working only then I put in ipfw this set of rules to handle all UDP packets outside from keep-state rules: add allow udp from any to any add check-state add deny icmp from any to any frag add allow icmp from any to me icmptypes 0,3,11 add allow icmp from me to any out keep-state add allow tcp from me to any out keep-state add allow udp from me to any out keep-state add deny ip from any to any It looks like dynamicaly created rules some how inadequately handles big UDP packets (DNSSEC answers are big). Is there any who can help to investigate this issue (looks like I can't do it myself)? Can it be ipfw related issue? Thanks. From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 13 21:38:13 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 743EA1065670 for ; Fri, 13 Mar 2009 21:38:13 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 3A75F8FC12 for ; Fri, 13 Mar 2009 21:38:13 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CE1AE73098; Fri, 13 Mar 2009 22:43:27 +0100 (CET) Date: Fri, 13 Mar 2009 22:43:27 +0100 From: Luigi Rizzo To: Dmitriy Demidov Message-ID: <20090313214327.GA1675@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903132246.49159.dima_bsd@inbox.lv> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 13 Mar 2009 21:38:13 -0000 On Fri, Mar 13, 2009 at 10:46:48PM +0200, Dmitriy Demidov wrote: > Hi list. > > I'm using DNS cache server Unbound-1.2.1. I want to start using DNSSEC via DLV (unbound gracefully allows it). > My system is FreeBSD7-STABLE. I'm using ipfw. > > Original ipfw configuration: > add check-state > add deny icmp from any to any frag > add allow icmp from any to me icmptypes 0,3,11 > add allow icmp from me to any out keep-state > add allow tcp from me to any out keep-state > add allow udp from me to any out keep-state > add deny ip from any to any > > /etc/sysctl.conf > net.inet.ip.fw.dyn_udp_lifetime=60 > > The problem is that Unbound can't do DNSSEC validation using this firewall configuration. It blames some thing like this: > [1236970569] unbound[9096:3] info: resolving > [1236970569] unbound[9096:3] info: failed to prime trust anchor -- could not fetch DNSKEY rrset > [1236970569] unbound[9096:3] info: Could not establish a chain of trust to keys for > > Unbound starts working only then I put in ipfw this set of rules to handle all UDP packets outside from keep-state rules: > add allow udp from any to any > add check-state > add deny icmp from any to any frag > add allow icmp from any to me icmptypes 0,3,11 > add allow icmp from me to any out keep-state > add allow tcp from me to any out keep-state > add allow udp from me to any out keep-state > add deny ip from any to any > > It looks like dynamicaly created rules some how inadequately handles big UDP packets (DNSSEC answers are big). > Is there any who can help to investigate this issue (looks like I can't do it myself)? > Can it be ipfw related issue? it is not related to dynamic rules, but to the fact that that the firewall is called before reassembling packets. The info (port numbers especially) is not available in the fragments so the firewall cannot do anything. The only solution would be to call the firewall after reassembly. I am not sure if there is any work in progress for that. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 14 14:38:19 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD2A106564A for ; Sat, 14 Mar 2009 14:38:19 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from sunner.semmy.ru (sunner.semmy.ru [195.54.209.159]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA8F8FC1B for ; Sat, 14 Mar 2009 14:38:19 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.76.79] (helo=[172.16.100.19]) by sunner.semmy.ru with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LiUTJ-0006ao-8y; Sat, 14 Mar 2009 17:04:17 +0300 Message-ID: <49BBB94A.7040208@FreeBSD.org> Date: Sat, 14 Mar 2009 17:03:54 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dmitriy Demidov References: <200903132246.49159.dima_bsd@inbox.lv> In-Reply-To: <200903132246.49159.dima_bsd@inbox.lv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 14 Mar 2009 14:38:19 -0000 Dmitriy Demidov wrote: > Unbound starts working only then I put in ipfw this set of rules to handle all UDP packets outside from keep-state rules: > add allow udp from any to any What if you add: add allow ip from any to any frag instead the line above? > add check-state > add deny icmp from any to any frag I'm not sure the line above is correct. > add allow icmp from any to me icmptypes 0,3,11 > add allow icmp from me to any out keep-state > add allow tcp from me to any out keep-state > add allow udp from me to any out keep-state > add deny ip from any to any > > It looks like dynamicaly created rules some how inadequately handles big UDP packets (DNSSEC answers are big). > Is there any who can help to investigate this issue (looks like I can't do it myself)? > Can it be ipfw related issue? -- Dixi. Sem. From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 14 18:31:57 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71177106566C for ; Sat, 14 Mar 2009 18:31:57 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp3.apollo.lv (smtp3.apollo.lv [80.232.168.198]) by mx1.freebsd.org (Postfix) with ESMTP id BDFA98FC1D for ; Sat, 14 Mar 2009 18:31:56 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Scan: scanned Received: from [81.198.53.40] ([81.198.53.40] verified) by smtp3.apollo.lv (CommuniGate Pro SMTP 5.2.3) with ESMTP id 338947462; Sat, 14 Mar 2009 20:31:54 +0200 From: Dmitriy Demidov To: Sergey Matveychuk , Luigi Rizzo Date: Sat, 14 Mar 2009 20:31:53 +0200 User-Agent: KMail/1.9.10 References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> In-Reply-To: <49BBB94A.7040208@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903142031.53326.dima_bsd@inbox.lv> Cc: freebsd-ipfw@freebsd.org Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 14 Mar 2009 18:31:57 -0000 On Saturday 14 March 2009, Sergey Matveychuk wrote: > What if you add: > > add allow ip from any to any frag > > instead the line above? Hi Sergey. Yes, it works this way. Unbound can do DNSSEC queues via this rule (and can not without it). Here is a example (both ipfw and unbound is just restarted) before DNSSEC queue 00100 106 22184 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 allow ip from any to any frag 00500 0 0 check-state 00600 0 0 allow icmp from any to me icmptypes 0,3,11 00700 0 0 allow icmp from me to any out keep-state 00800 0 0 allow tcp from me to any out keep-state 00900 1 76 allow udp from me to any out keep-state 01000 30 1882 deny ip from any to any 65535 20 3300 deny ip from any to any after DNSSEC queue 00100 164 33830 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 1 461 allow ip from any to any frag 00500 0 0 check-state 00600 0 0 allow icmp from any to me icmptypes 0,3,11 00700 0 0 allow icmp from me to any out keep-state 00800 0 0 allow tcp from me to any out keep-state 00900 67 16551 allow udp from me to any out keep-state 01000 50 3134 deny ip from any to any 65535 20 3300 deny ip from any to any --- Hi Luigi. Thank you for answer. It is a big "surprise" for me that reassembling of IP datagrams is done not *before* they go into firewall, but *after* :( I have two questions. 1) Do modern Ethernet cards with enabled hardware offloading functions (and supported driver) can help in this situation (can they do reassembling)? 2) How hard it would be to extend ipfw functionality with feature that will enable him to make at least IP reassembling (just like pf scrub do it)? About my second question. If there is no any other way to solve this problem using current ipfw/FreeBSD implementation, then I can offer 500 WMZ (webmoney) bounty to any one who will extend ipfw (or FreeBSD ip stack?) functionality with "scrubber" that can do at least IP reassembling, and which code quality will be good enough for including him in official FreeBSD code base. Unfortunately 500$ is my upper limit at this moment. :)