Unified rc.firewall ipfw me/me6 issue

[Max Laier]

On Thursday 17 December 2009 08:20:47 David Horn wrote:
> Hajimu --
> 
> Thanks for working on rc.firewall, as the old scenario of dualing
> rc.firewall/rc.firewall6 was not easily used in the default configurations
> when running dual stack.  The new rc.firewall has some very decent sane
> defaults.  My testing so far as been concentrated on
>  firewall_type="client", dual stack v4/v6 with SLAAC for IPv6, and DHCP for
>  IPv4.  I will try some of the IPv6 tunnel scenarios later.
> 
> I ran some tests against the now committed to -current /etc/rc.firewall,
>  and think have found an issue.  In every line that has the "me" token
>  without the equivalent "me6" token, the command is only taking affect for
>  ipv4.
> 
> For example:
> 
> ${fwcmd} add pass udp from me to any 53 keep-state
> 
> will allow dns requests from the client to pass, but if the destination
>  host is ipv6, this rule does not work.   Instead you need:
> 
> ${fwcmd} add pass udp from { me or me6 } to any 53 keep-state
> 
> The same issue exists for several other entries as well. (possible diff
> attached) The other option is to modify ipfw to actually have three
> different "me" tokens (me/me4/me6) where the new "me" token would match
>  both ipv4 and ipv6 local interface addresses.  Currently "me" matches only
>  ipv4 addresses on my amd64 -current box.

The problem with this approach is and has been that it would change the 
meaning of "me".  IIRC, it was considered a POLA violation to do that back 
when the IPv6 functionality was merged. An alternative would be to introduce a 
new name for me when we don't care which address family - e.g. me_any, mine, 
me64, me12, ... pick your color.
 
> Thoughts anyone?
> 
> --Thanks!
> 
> -_Dave Horn
> 
> P.S., might also be nice to have an UPDATING entry for unified rc.firewall
> 
> 
> !DSPAM:4b29e29a301561928620662!
>