Date: Sat, 2 Jan 2010 20:36:45 -0500 From: David Horn <dhorn2000@gmail.com> To: Hajimu UMEMOTO <ume@freebsd.org> Cc: freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue Message-ID: <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> In-Reply-To: <yged42c4770.wl%ume@mahoroba.org> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <ygek4wmyp3j.wl%ume@mahoroba.org> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <yged42c4770.wl%ume@mahoroba.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 18, 2009 at 10:45 AM, Hajimu UMEMOTO <ume@freebsd.org> wrote:
> Hi,
>
>>>>>> On Fri, 18 Dec 2009 09:12:48 -0500
>>>>>> David Horn <dhorn2000@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25ff90d61001021736p7b695197q104f4a7769b51b71>