On Sunday 07 June 2009 20:20:24 Florian Fainelli wrote:
> Le Sunday 07 June 2009 15:59:20 Malte S. Stretz, vous avez écrit :
>[...]
> > So I guess I've got to change that.
> >
> > [2] suggests to discuss the ideas in advance so double work can be
> > avoided. I like that idea, so here's my proposal to add IPv6 support to
> > uci_firewall:
> >
> > * uci_firewall will automagically detect if IPv6 rules are needed, based
> > on the availability of ip6tables and kmod-ipv6. There will probably be
> > some corner cases, like when kmod-ipv6 is loaded after the firewall was
> > already set up, but these should be fixable.
>
> Why not get ip6tables install its uci_firewall6 script for instance? Just
> like iptables installs its firewall script, since firewalling without
> ip6tables is not possible.
I thought about splitting the firewall package into a firewall4 and a
firewall6, both would put something into /lib/firewall and the main
iptables() wrapper would detect the existence of these scripts, a bit like
sysupgrade does it.
But after thinking about it I came to the conclusion that this would be some
overhead and the complexity might become hard to debug and I doubt its worth
the few bytes saved. In a few (1 <= $few <= 3) years we'll have native IPv6
anyway, so I don't think it makes much sense to split the script. But if you
think otherwise, I'm easy to be convinced :)
> > * All rules which don't explicitly state a $src or $dst will be generated
> > for both. (The same is true for chains.) If one of those is given, the
> > script will look at the address format and generate the proper rules.
>
> I am fine with this.
>
> > * This will be done by replacing $IPTABLES with an iptables() funtion
> > which does the magic (guess this will be easier once nftables [3] is
> > around but I've got to work with the stuff we have).
>
> Last I tried, there was quite a lot of IPv4 specific cases which did make
> all rules apply, and those which were would not give a coherent firewall.
> This was with the old firewall though.
The current uci_firewall.sh doesn't look like there are many places where this
is still the case.
I'd love to be able to configure a single firewall and it just works for both
versions of IP. We'll see if it works out.
> > * Seems like the uci_firewall needs some general love, there seem to be
> > some non-local or even variables with undefined values hanging around.
> >
> > * Maybe I'll additionally add an explicit src_ipv4 and src_ipv6 (and
> > dst_ipv{4,6} respectively) if that makes sense.
>
> Ok
>
> > * I also thought about introducing host aliases which bundle the IPvX
> > addresses of a host and are then referenced in the rules (if you used
> > m0n0wall, you know what I mean). But that would be a later feature.
>
> If it does not add that much overhead, I am ok with that. An user is most
> likely to know that computer with IPv4 a.b.c.d is named foo or bar on his
> local network
I tend to forget it, especially for some esotheric hosts on networks I only
see once in a while. And the last time I had to renumber a mid-sized IPv4
network (20 workstations, 6 servers, a bunch of print servers) it was a real
PITA fixing all those firewall rules etc. manually. Especially the point
below would make this almost trivial.
And once you've got both IPv4 and IPv6 on the net, you'd need to create each
rule twice. It would be a lot easier just to assign n IPvX addresses to each
alias and build the rules based on that. My next dream is that a host alias
can be tied to a MAC address (and/or some other identifying key) and the
firewall rules for this host are updated eg. when the DHCP lease changes
(this might of course be possible with dst_mac already, haven't checked yet).
> > * Contrary to m0n0wall the host aliases should be accompanied by net
> > aliases so renumbering a net becomes trivial.
> >
> > Any comments, ideas, flames? I'm also hanging around on #openwrt as
> > moonflux.
>
> I really like the idea, being an IPv6 user and enthousiast ;)
That's good to hear :)
Cheers,
Malte
--
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
