From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 12 11:06:59 2007 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 6681916A504 for ; Mon, 12 Nov 2007 11:06:59 +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 52AE113C4B0 for ; Mon, 12 Nov 2007 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lACB6xYR089714 for ; Mon, 12 Nov 2007 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lACB6w3G089710 for freebsd-ipfw@FreeBSD.org; Mon, 12 Nov 2007 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Nov 2007 11:06:58 GMT Message-Id: <200711121106.lACB6w3G089710@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, 12 Nov 2007 11:06:59 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw ipfw is seems to be broken to limit number of connecti o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o bin/113803 ipfw [patch] bin/ipfw.8 - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 28 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Nov 13 04:50:45 2007 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 D61F916A469 for ; Tue, 13 Nov 2007 04:50:45 +0000 (UTC) (envelope-from 10143477@lon1-web-2.msh.demon.net) Received: from lon1-mail-2.visp.demon.net (lon1-mail-2.visp.demon.net [193.195.70.5]) by mx1.freebsd.org (Postfix) with ESMTP id 6C47A13C4EE for ; Tue, 13 Nov 2007 04:50:45 +0000 (UTC) (envelope-from 10143477@lon1-web-2.msh.demon.net) Received: from lon1-msh-1-streamvip.msh.demon.net (EHLO lon1-web-2.msh.demon.net) ([192.168.217.161]) by lon1-mail-2.visp.demon.net (MOS 3.7.5a-GA FastPath queued) with ESMTP id FPK94169; Mon, 12 Nov 2007 11:11:42 +0000 (GMT) Received: from 10143477 by lon1-web-2.msh.demon.net with local (Exim 4.10) id 1IrI8V-0006nJ-00 for freebsd-ipfw@freebsd.org; Sun, 11 Nov 2007 19:06:23 +0000 To: freebsd-ipfw@freebsd.org From: ROLLING SPIN LOTTERY UK MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Sender: 10143477 <10143477@lon1-web-2.msh.demon.net> Date: Sun, 11 Nov 2007 19:06:23 +0000 Subject: CONGRATULATIONS(winner) 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: Tue, 13 Nov 2007 04:50:45 -0000 ROLLING SPIN LOTTERY UK 25 Lincoln 's Inn Fields London WC2A 3EE UNITED KINGDOM Dear Winner, We are pleased to announce you as one of the 3 lucky winners in the ROLLING SPIN LOTTERY UK draw held on 10th of November 2007. All 3 winning addresses were randomly selected from a batch of 5,000,000 international emails. Your email address emerged alongside 2 others as a 3rd category winner in this month's draw. Consequently,you have therefore been approved for a total pay out of £2,000,000 Pounds (Two million pounds) only. The following particulars are attached to your lotto payment order: (i) Winning numbers: 3,2132,7,29,38 (ii) Serial number:21-8-14 (iii) Lotto batch number: RSL-351 (iv) Reference number: SCF-427-01 Please contact the under listed claims officer as soon as possible for the immediate release of your winnings: Philip Bell Claims Department Manager SummerCrest Finance UK Email:summercrestfinancesdeptuk6@yahoo.co.uk Tel:+44 70457 12473 Tel:+44 70059 31081 Fax:+44 70059 47103 Fax:+44 70059 78942 Due to mix up of some numbers and names, we ask that you keep your Winning information confidential until your claim have been processed. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participant. Once again on behalf of all our staff, CONGRATULATIONS!!! Sincerely, Jonathan Banks Promotions Manager N.B: 1.All claims are nullified after 10 working days from today. 2.Your Ref number must be in all your mails with the claims officer. 3.Do inform the claims officer of any change of names or addresses. 4.All winners under the age of 18 are automatically disqualified. 5.Please contact your claims agent by fax or email (Philip Bell). From owner-freebsd-ipfw@FreeBSD.ORG Tue Nov 13 23:06:36 2007 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 8854916A418 for ; Tue, 13 Nov 2007 23:06:36 +0000 (UTC) (envelope-from curby.public@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4744A13C447 for ; Tue, 13 Nov 2007 23:06:36 +0000 (UTC) (envelope-from curby.public@gmail.com) Received: by el-out-1112.google.com with SMTP id s27so547339ele for ; Tue, 13 Nov 2007 15:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Rez9qsJugw3BzvKU7nAbti/03prRZmlBjj2QT6WuryI=; b=NyiVYL7aIXhesqX3NRghne0MZUxz3hMjwemz8MdmqGYvJ1LWZq3ewe4UWQ7IGk6MNQLHOjMUFI5G3Wo7Vv56Z+A0jZNYzwMpb4sOyV+iilQ4/sRn2szJ2vnZ0MNphV1RiDi8PlZO6hCWHf8FRQbHnR+JW2Auucy2LwCsJ6CIf5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OAjUeAVkL9SiNbsx4pjwqmxIKoDCTZfPhf39vXAuO4vMK5WTk2phs9/eDTN0JkBWAy5AG+PJlgHlhWpai1i+4N1JkFMsJW1CBA31NlXAvv4dGrAOo1GYl8sV5tx48Cnoje5/e6ambtAuFJAYwV2eDrEK5Sa18tthjXADGQrfMRA= Received: by 10.142.214.5 with SMTP id m5mr422018wfg.1194993598795; Tue, 13 Nov 2007 14:39:58 -0800 (PST) Received: by 10.142.72.16 with HTTP; Tue, 13 Nov 2007 14:39:58 -0800 (PST) Message-ID: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> Date: Tue, 13 Nov 2007 15:39:58 -0700 From: Curby To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Fragmented Packet Reassembly and IPFW2 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: Tue, 13 Nov 2007 23:06:36 -0000 Hi, this is slightly off-topic as it relates to IPFW2 in Mac OS X (as of Tiger, 10.4.x). I've read that when a FreeBSD machine running IPFW2 receives a fragmented TCP packet (and let's say that the machine itself is the intended destination), the packet is reassembled before it gets to IPFW2, and IPFW2 sees a single TCP packet. Basically, the (first) question is whether this is the case in OS X. Next, and especially if reassembly occurs before the firewall, what is the point of the frag flag in a rule body, e.g.: add 04010 deny log all from any to any frag in Question 2 in a nutshell: what's the point of "frag" if frags are already being reassembled? Is this meant to reject incoming frags that aren't reassembled by the kernel (i.e. crap traffic)? I'm actually using the exact rule above in my laptop firewall configuration, and the only time I've seen it triggering is at a conference's wifi network, where other clients would be sending multicast frags to 224.0.0.251. (If that's crap traffic, why would it be rampant at that conference?) Thanks! From owner-freebsd-ipfw@FreeBSD.ORG Tue Nov 13 23:09:31 2007 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 96ACB16A468 for ; Tue, 13 Nov 2007 23:09:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outH.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 86B9713C455 for ; Tue, 13 Nov 2007 23:09:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 13 Nov 2007 15:09:29 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B6071126A03; Tue, 13 Nov 2007 15:09:28 -0800 (PST) Message-ID: <473A2EAA.3090606@elischer.org> Date: Tue, 13 Nov 2007 15:09:30 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Curby References: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> In-Reply-To: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: Fragmented Packet Reassembly and IPFW2 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: Tue, 13 Nov 2007 23:09:31 -0000 Curby wrote: > Hi, this is slightly off-topic as it relates to IPFW2 in Mac OS X (as > of Tiger, 10.4.x). > > I've read that when a FreeBSD machine running IPFW2 receives a > fragmented TCP packet (and let's say that the machine itself is the > intended destination), the packet is reassembled before it gets to > IPFW2, and IPFW2 sees a single TCP packet. Basically, the (first) > question is whether this is the case in OS X. I don't believe that happens in FreeBSD.. where did you hear that? *adds looking at the code to 10,000 item list of things to do* > > Next, and especially if reassembly occurs before the firewall, what is > the point of the frag flag in a rule body, e.g.: > > add 04010 deny log all from any to any frag in > > Question 2 in a nutshell: what's the point of "frag" if frags are > already being reassembled? Is this meant to reject incoming frags > that aren't reassembled by the kernel (i.e. crap traffic)? I'm > actually using the exact rule above in my laptop firewall > configuration, and the only time I've seen it triggering is at a > conference's wifi network, where other clients would be sending > multicast frags to 224.0.0.251. (If that's crap traffic, why would it > be rampant at that conference?) Thanks! > _______________________________________________ > 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 Wed Nov 14 04:44:19 2007 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 65E0516A417 for ; Wed, 14 Nov 2007 04:44:19 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id C5A5613C457 for ; Wed, 14 Nov 2007 04:44:18 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 7298E1D12CD for ; Wed, 14 Nov 2007 10:24:39 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKBWk4IvGblj for ; Wed, 14 Nov 2007 10:24:37 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id DCEF91D12D5 for ; Wed, 14 Nov 2007 10:24:37 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 10:24:37 +0600 Received: from nuclight.avtf.net ([78.140.2.188]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 10:24:37 +0600 To: freebsd-ipfw@freebsd.org References: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> Message-ID: Date: Wed, 14 Nov 2007 10:24:35 +0600 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 14 Nov 2007 04:24:38.0091 (UTC) FILETIME=[44B729B0:01C82676] Subject: Re: Fragmented Packet Reassembly and IPFW2 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, 14 Nov 2007 04:44:19 -0000 14.11.07 @ 04:39 Curby wrote: > Hi, this is slightly off-topic as it relates to IPFW2 in Mac OS X (as > of Tiger, 10.4.x). > > I've read that when a FreeBSD machine running IPFW2 receives a > fragmented TCP packet (and let's say that the machine itself is the > intended destination), the packet is reassembled before it gets to > IPFW2, and IPFW2 sees a single TCP packet. Basically, the (first) > question is whether this is the case in OS X. > > Next, and especially if reassembly occurs before the firewall, what is > the point of the frag flag in a rule body, e.g.: > > add 04010 deny log all from any to any frag in > > Question 2 in a nutshell: what's the point of "frag" if frags are > already being reassembled? Is this meant to reject incoming frags No, you've read something wrong,. Packets are not reassembled before firewall. At least they shouldn't do, no documentation says that it must be. So are that rules - they're really dealing with fragments, no reassembly. No firewall does reassembly by default, pf also must be told explicitly to do this by 'scrub' keyword. May be you've misunderstood somewhat while reading about 'divert', and thought it reassembles all the time, not only there? But that also occurs _after_ the firewall, anyway... -- WBR, Vadim Goncharov From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 14 06:45:17 2007 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 6A16016A419 for ; Wed, 14 Nov 2007 06:45:17 +0000 (UTC) (envelope-from curby.public@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id A3A9B13C459 for ; Wed, 14 Nov 2007 06:45:15 +0000 (UTC) (envelope-from curby.public@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so2638055pyb for ; Tue, 13 Nov 2007 22:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=TdD5cIHa8+ZSuCPJl6RGRmmemrlmo1ois0F9SkEBEkE=; b=Ysq+fKRs0UxxRfQqRDWcAOGGCN5zMozWcYca3mAU3JiJRKDW0lRKcUihfv4uLO0RiZ5AtCXiXbYr3ZMpghsflbVhFJtAWXmetGPWPdHuMgTWp+ZHorAAirN1T+fAgj12HF3Wz/oVPTSv102NgFm3Hput/31IfcHfA3ff7wk/wvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RPACbJVEJbGy12PEHA//H0GRg0yaIEHfRk2vlhPzT+M/cd/BMJOCiujwrKdwciotgogUUxvPDGlzOdOyxmnohvkmy8Otz6hdu+1TjlL+WTUXAHfg4vJbolSysxR8wyJqYxUxciZZnZQiEWabPje2wTbTejLpmBFJKR+g1m2M63E= Received: by 10.143.16.9 with SMTP id t9mr938004wfi.1195022701107; Tue, 13 Nov 2007 22:45:01 -0800 (PST) Received: by 10.142.72.16 with HTTP; Tue, 13 Nov 2007 22:45:01 -0800 (PST) Message-ID: <5d2f37910711132245n3e699b57i1746594462725a09@mail.gmail.com> Date: Tue, 13 Nov 2007 23:45:01 -0700 From: Curby To: freebsd-ipfw In-Reply-To: <5d2f37910711132244w39e73eb0nb8d8ac460dd15fcd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> <5d2f37910711132244w39e73eb0nb8d8ac460dd15fcd@mail.gmail.com> Subject: Fwd: Fragmented Packet Reassembly and IPFW2 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, 14 Nov 2007 06:45:17 -0000 Julian and Vadim, thank you both for your replies. Here's a really old quote: "The ip_input() routine in the kernel then dequeues the packet, performs sanity checks on the packet and determines the destination for the packet. If the destination is the local computer, the kernel will perform packet reassembly. " from http://usenix.net/events/bsdcon02/full_papers/lidl/lidl_html/index.html Also, this poster is less sure but suggests that this might happen: http://osdir.com/ml/freebsd.isp/2003-02/msg00091.html I also think that Linux iptables only sees reassembled packets (at least some of the time, e.g. when it is legitimate traffic destined for the host itself), so this isn't altogether wild and crazy. If in fact reassembly does not happen, I should remove that rule as frags will likely not match using a check-state rule because they lack tcp/udp header information. Is there a way in ipfw to allow frags that claim to be related to a known-good first frag but drop others? Something like check-state but for fragments 1 and above, in other words. The odd thing is that I didn't see any dropped packets in my logs or notice any disrupted traffic (e.g. in a web browser) before this conference, where frags were suddenly flying all over. Thanks again for your help! --Mike From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 14 07:02:17 2007 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 D961616A420 for ; Wed, 14 Nov 2007 07:02:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id BD24913C44B for ; Wed, 14 Nov 2007 07:02:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 13 Nov 2007 23:01:56 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2C9D61269FA; Tue, 13 Nov 2007 23:01:56 -0800 (PST) Message-ID: <473A9D65.7000002@elischer.org> Date: Tue, 13 Nov 2007 23:01:57 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Curby References: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> <5d2f37910711132244w39e73eb0nb8d8ac460dd15fcd@mail.gmail.com> <5d2f37910711132245n3e699b57i1746594462725a09@mail.gmail.com> In-Reply-To: <5d2f37910711132245n3e699b57i1746594462725a09@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw Subject: Re: Fwd: Fragmented Packet Reassembly and IPFW2 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, 14 Nov 2007 07:02:17 -0000 Curby wrote: > Julian and Vadim, thank you both for your replies. Here's a really old quote: > > "The ip_input() routine in the kernel then dequeues the packet, > performs sanity checks on the packet and determines the destination > for the packet. If the destination is the local computer, the kernel > will perform packet reassembly. " The firewall is the first thing ip_input does. it happens BEFORE reassembly. > > from http://usenix.net/events/bsdcon02/full_papers/lidl/lidl_html/index.html > > Also, this poster is less sure but suggests that this might happen: > http://osdir.com/ml/freebsd.isp/2003-02/msg00091.html he says "I think" and he's wrong. check netinet/ip_input.c > > I also think that Linux iptables only sees reassembled packets (at > least some of the time, e.g. when it is legitimate traffic destined > for the host itself), so this isn't altogether wild and crazy. maybe, but you are asking about FreeBSD > > If in fact reassembly does not happen, I should remove that rule as > frags will likely not match using a check-state rule because they lack > tcp/udp header information. Is there a way in ipfw to allow frags > that claim to be related to a known-good first frag but drop others? > Something like check-state but for fragments 1 and above, in other > words. not in ipfw. you might check pf and ipf > > The odd thing is that I didn't see any dropped packets in my logs or > notice any disrupted traffic (e.g. in a web browser) before this > conference, where frags were suddenly flying all over. Thanks again > for your help! frags are usually the result of tunnelling. People at a conference often have tunnels running. > > --Mike > _______________________________________________ > 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 Wed Nov 14 08:05:39 2007 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 BE42C16A469 for ; Wed, 14 Nov 2007 08:05:39 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4A713C47E for ; Wed, 14 Nov 2007 08:05:38 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 7D3A21D12CF for ; Wed, 14 Nov 2007 14:05:34 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlaM9n5Aw08l for ; Wed, 14 Nov 2007 14:05:31 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id AA4E810DB90 for ; Wed, 14 Nov 2007 14:05:31 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 14:05:31 +0600 Received: from nuclight.avtf.net ([78.140.2.188]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 14:05:31 +0600 Date: Wed, 14 Nov 2007 14:05:27 +0600 To: freebsd-ipfw References: <5d2f37910711131439x56bb2028maa40b0475feffde4@mail.gmail.com> <5d2f37910711132244w39e73eb0nb8d8ac460dd15fcd@mail.gmail.com> <5d2f37910711132245n3e699b57i1746594462725a09@mail.gmail.com> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <5d2f37910711132245n3e699b57i1746594462725a09@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 14 Nov 2007 08:05:31.0483 (UTC) FILETIME=[205A4AB0:01C82695] Subject: Re: Fwd: Fragmented Packet Reassembly and IPFW2 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, 14 Nov 2007 08:05:39 -0000 14.11.07 @ 12:45 Curby wrote: > "The ip_input() routine in the kernel then dequeues the packet, > performs sanity checks on the packet and determines the destination > for the packet. If the destination is the local computer, the kernel > will perform packet reassembly. " Yes, but this happens AFTER the firewall. And only for local computer, not transit traffic. > from > http://usenix.net/events/bsdcon02/full_papers/lidl/lidl_html/index.html This is article about BSD/OS ipfw, not FreeBSD's ipfw - they're very different. > Also, this poster is less sure but suggests that this might happen: > http://osdir.com/ml/freebsd.isp/2003-02/msg00091.html He's wrong. > I also think that Linux iptables only sees reassembled packets (at > least some of the time, e.g. when it is legitimate traffic destined > for the host itself), so this isn't altogether wild and crazy. I don't know about Linux' behaviour in this case (and anyway, it's irrelevant to FreeBSD). > If in fact reassembly does not happen, I should remove that rule as > frags will likely not match using a check-state rule because they lack > tcp/udp header information. Is there a way in ipfw to allow frags > that claim to be related to a known-good first frag but drop others? > Something like check-state but for fragments 1 and above, in other > words. No, that needs reassembly. You can try using divert socket as the first rule on the input, though, as packets are get reassembled before diverting. You need to put something listening on the divert socket and echoing packets back. It can be ng_ksocket + ng_echo, try to experiment with them. Or use pf scrub instead of ipfw. -- WBR, Vadim Goncharov