From owner-freebsd-ipfw@FreeBSD.ORG Sun Jan 3 01:36:56 2010 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 BA3871065692; Sun, 3 Jan 2010 01:36:56 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 256A08FC0C; Sun, 3 Jan 2010 01:36:55 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so1281849fgg.13 for ; Sat, 02 Jan 2010 17:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7e28c5/azjcHdMilHXnUxnK8boqRnSJqtzO6CXuM6Ik=; b=ZUqz7BPDdIucruwUwOWe7VY9WGLcnEW1lJnKwOWD+SdM63ew7ZB8vZveCSM8pwUeI1 EkmVKSDJDje7XZ22ja2ztbzIrEl0pYUZHDPYyz5pUHRLOCVHQnsB03s8cWIjH9bhvRvT piS+SCTeXAJfPXPR4pkV2mNyUAqL3Ue5+GBRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l3KwiPsSUkZpsorePxaF/WIqqo60h4i2+LuqPOYKnVj8MOINtACQ9ipytmeufsCQO7 DDmDx0wOoz7jNobWezBGU2Mi/mkipWKTofzBL3cKjE1eLgVYKjuYDzj/FNb/yGgoHN/+ sD8nJjD6ZotRjBZ/ioLQMxfGZvKD0+x345l4Y= MIME-Version: 1.0 Received: by 10.239.167.83 with SMTP id f19mr2396203hbe.34.1262482605672; Sat, 02 Jan 2010 17:36:45 -0800 (PST) In-Reply-To: References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> Date: Sat, 2 Jan 2010 20:36:45 -0500 Message-ID: <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> From: David Horn To: Hajimu UMEMOTO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue 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: Sun, 03 Jan 2010 01:36:56 -0000 On Fri, Dec 18, 2009 at 10:45 AM, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Fri, 18 Dec 2009 09:12:48 -0500 >>>>>> David Horn said: > > dhorn2000> The updated patch works, but doing a check for [ $ipv6_availab= le -eq 0 ] > dhorn2000> might be more appropriate than checking "net6" or "inet6" vari= ables in these > dhorn2000> no INET6 cases since neither net6 or inet6 variables are invol= ved in these > dhorn2000> statements. > > Thank you for testing. > It is intentional. =A0If firewall_client_net_ipv6 is not set, the IPv6 > rules are not meaningful for the client type, and if > firewall_simple_inet_ipv6 is not set, the IPv6 rules are not > meaningful for the simple type. > > dhorn2000> Yes, "me" matching either ipv4/ipv6 would certainly simplify t= he default > dhorn2000> rc.firewall flow. > > Here is my proposed patch. =A0With this patch, 'me' matches to both IPv4 > and IPv6, and 'me4' is added for matching to only IPv4. > The patch for me4/me6 works perfect in my testing to date. I guess we would need to convince a larger audience to get consensus on changing the behavior for "me" token from just ipv4 to both ipv4/ipv6, but I personally think it is the right direction. ipfw(8) man page already shows: me matches any IP address configured on an interface in the system. me6 matches any IPv6 address configured on an interface in the system. The address list is evaluated at the time the packet is analysed. So, one could argue that your patch would change "me" token behavior to make it match the documented behavior. Of course we would need to add an entry for me4, but that is trivial. On a separate note, you may want to consider adding an explicit "allow" in the default rc.firewall to support dhcpv6-client requests. (at least in client case, but potentially workstation as well) e.g.: # Allow dhcpv6 client traffic - RFC 3315 ${fwcmd} add pass udp from fe80::/10 to me6 546 In normal cases, ipfw does not load the rc.firewall rule set until potentially initial negotiation of dhcpv6 has already occurred, but future requests (e.g. lease renewal, link up/down cases, etc.) would be blocked without the specific allow rule. ---Thanks! ---Dave Horn From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 4 11:07:00 2010 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 0B91B106568F for ; Mon, 4 Jan 2010 11:07:00 +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 EE6FD8FC1A for ; Mon, 4 Jan 2010 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o04B6xo5064931 for ; Mon, 4 Jan 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o04B6xgS064929 for freebsd-ipfw@FreeBSD.org; Mon, 4 Jan 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jan 2010 11:06:59 GMT Message-Id: <201001041106.o04B6xgS064929@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, 04 Jan 2010 11:07:00 -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/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port 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 p kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 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 63 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 4 15:13:33 2010 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 EE4B91065679; Mon, 4 Jan 2010 15:13:33 +0000 (UTC) (envelope-from ume@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C502F8FC12; Mon, 4 Jan 2010 15:13:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o04FDXLQ084896; Mon, 4 Jan 2010 15:13:33 GMT (envelope-from ume@freefall.freebsd.org) Received: (from ume@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o04FDXra084892; Mon, 4 Jan 2010 15:13:33 GMT (envelope-from ume) Date: Mon, 4 Jan 2010 15:13:33 GMT Message-Id: <201001041513.o04FDXra084892@freefall.freebsd.org> To: john.w.court@nokia.com, ume@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: ume@FreeBSD.org Cc: Subject: Re: kern/117234: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 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, 04 Jan 2010 15:13:34 -0000 Synopsis: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 State-Changed-From-To: patched->closed State-Changed-By: ume State-Changed-When: Mon Jan 4 15:12:34 UTC 2010 State-Changed-Why: MFC'ed to RELENG_8. Thank you!! http://www.freebsd.org/cgi/query-pr.cgi?pr=117234 From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 9 19:30:32 2010 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 16EA510656C3 for ; Sat, 9 Jan 2010 19:30:32 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id C35BC8FC28 for ; Sat, 9 Jan 2010 19:30:31 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id o09JUMdc005124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jan 2010 04:30:26 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 10 Jan 2010 04:30:22 +0900 Message-ID: From: Hajimu UMEMOTO To: David Horn In-Reply-To: <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 10 Jan 2010 04:30:26 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue 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, 09 Jan 2010 19:30:32 -0000 Hi, >>>>> On Sat, 2 Jan 2010 20:36:45 -0500 >>>>> David Horn said: dhorn2000> On a separate note, you may want to consider adding an explicit dhorn2000> "allow" in the default rc.firewall to support dhcpv6-client requests. dhorn2000> (at least in client case, but potentially workstation as well) Good catch! The client type firewall rule allows DHCP, implicitly. I've committed to allow DHCPv6 as well for the client type firewall. Since the workstation type firewall rule explicitly allows DHCP, we have the rule to allow DHCPv6 already. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/