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