consider merging iptables and ip6tables providers about puppetlabs-firewall HOT 9 CLOSED

I would suggest to separate them nicely: firewall and firewall6. Features are simply not the same and providers don't do a nice job if two apply to the same system.

Helpers like parsing etc can be moved into own module that each can use or ignore.

from puppetlabs-firewall.

@georgkoester I'm not suggesting having two providers we already have that, I'm suggesting one provider that manipulates either ipv6 or ipv4 depending on a parameter or auto-detection perhaps. We can overlap the features, there is only a minor difference in the full options (less than 5% I would think) and we don't have to support the IPv6 features when IPv4 is applied, we can throw errors in those cases.

from puppetlabs-firewall.

@kbarber Would that support machines with ipv4 and ipv6 addresses?

from puppetlabs-firewall.

@georgkoester Yes that would be the idea. You see I totally agree 2 providers doesn't work, you can't purge properly and introspection with puppet resource doesn't work. A perfect example of this is the gem package provider. Now the real fix is to have these problems solved in Puppet - but until that happens this is my proposal.

from puppetlabs-firewall.

@kbarber Ok, I was afraid it would be either ipv4 or v6 for one machine. Now I see - not using the provider param, but something new. That's very good, thanks for the explanation.

from puppetlabs-firewall.

@georgkoester yeah I figure usually one can work these things out, but a separate param that is more like a bitfield (or enum field) might be better. Something like:

network_proto => ['ipv4','ipv6']
network_proto => 'all'
network_proto => 'ipv4'

(not sure if network_proto is the right one to use, just proto is taken, and well - network is the right osi layer).

I'm almost tempted to say the default behaviour should be 'try to apply the rule to all network protocol layers' ... that way people would find ipv6 & ipv4 firewalled when they do things like 'deny all port 22'. Of course, we would need address detection in that case and it makes it tricky.

from puppetlabs-firewall.

@kbarber That would be nice. Your 'all'-functionality is very useful even
without specifying an address. Loopback has to be allowed as a first rule,
then deny-rules without addresses is very valuable and fail-safe - even
more important IMHO.

On Fri, Apr 12, 2013 at 2:32 PM, Ken Barber [email protected]:

@georgkoester https://github.com/georgkoester yeah I figure usually one
can work these things out, but a separate param that is more like a
bitfield (or enum field) might be better. Something like:

network_proto => ['ipv4','ipv6']
network_proto => 'all'
network_proto => 'ipv4'

(not sure if network_proto is the right one to use, just proto is taken,
and well - network is the right osi layer).

I'm almost tempted to say the default behaviour should be 'try to apply
the rule to all network protocol layers' ... that way people would find
ipv6 & ipv4 firewalled when they do things like 'deny all port 22'. Of
course, we would need address detection in that case and it makes it tricky.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-16290348
.

from puppetlabs-firewall.

how about

address_family

instead. Seems more natural to me?

from puppetlabs-firewall.

Hello! We are doing some house keeping and noticed that this issue has been open for a long time.

We're going to close it but please do raise another issue if the issue still persists. 😄

from puppetlabs-firewall.