Support dest/source negation about puppetlabs-firewall HOT 12 CLOSED

Hi,

Can this please become an issue ?
I'm indeed facing a problem on a libvirt server : the libvirt daemon adds its own rules, like these ones :

-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE

Because of that, the iptables.rb provider fails with the following error :
Error: Could not prefetch firewall provider 'iptables': Invalid address from IPAddr.new: !

To work around this, I had to exclude all 192.168.122.* rules from the iptables-save output, by modifying the regex in iptables.rb, but that remains a work around.

Thanks && regards

from puppetlabs-firewall.

Hi!

IMHO this is definitely a problem: If you run an out-of-the-box libvirtd on your system, you no longer able to manage your firewall with this module. I just ran into this problem with Debian wheezy... So I think it's not only an enhancement, but also a bug.

Best Regards,
fonk

from puppetlabs-firewall.

Hi!
I tried the new module yesterday with wheezy and it still did not work for me with default libvirt rules...
Best Regards,
fonk

from puppetlabs-firewall.

Same here, default libvirt on Ubuntu 13.04. Fschaer: can you share more details on your workaround?

from puppetlabs-firewall.

Hi,

Sorry for the delay.
At : firewall/lib/puppet/provider/firewall/iptables.rb:128

Change the “unless” line so that it excludes the libvirt rules from iptables-save, like this (virbr0 in my case, and 192.168.122.XX networks with their netmasks) :

  unless line =~ /^\#\s+|^\:\S+|^COMMIT|^FATAL|virbr0|192.168.122.0\/24|192.168.122.0\/255.255.255.0/

Cheers

from puppetlabs-firewall.

Well, at least the module isn't failing any longer with this "patch", but it's very "quick&dirty" imho, because half of the libvirt rules get managed while other are ignored. For example libvirt inserts the following rules into the forwarding table:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

After executing the firewall module and let it purge all rules, these are (of course) still there:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere

Either all or no libvirt rules should get managed by this module...

from puppetlabs-firewall.

Just met this problem myself (on CentOS 6.4), having set up puppetdb using some official module which relies on this firewall module.
Worked fine until I rebooted and libvirtd was started. My problem surfaced

fonk: The module should preferably handle the rules - at the very least it should handle the rules being there.
If the module could figure out that entries added to FORWARD chain that would be great (i.e. for removal), but managing all the rules would probably not be what you want as the libvirt layer is supposed to dynamically add and remove rules. You have two sources of truth, they need to co-exist.

from puppetlabs-firewall.

I agree, that there should be a possibility to have more than one tool managing iptables rules, but if I tell puppet to purge all rules it should be able to purge all rules! Also libvirt rules are not very dynamic: They only get added or removed if a network is started or stopped and that's nothing I am doing every day. Because of this I'd like to monitor the rules (and their order, as libvirt is not good in doing that!) with puppet but let libvirt manage dnsmasq and other thing related to libvirt networks.

from puppetlabs-firewall.

I'll just add my +1 here: this is messing me up. I can't even create the rule outside of puppet, because the provider blows up badly if I've got that rule with a negation in there.

from puppetlabs-firewall.

+1 to @fonk's comment. Merging with existing rules is one thing, but if it's failing on a purge, that's a pretty critical issue. Makes debugging harder, too, since the error message wasn't very helpful (I spent an hour grepping through my code trying to figure out where the rogue ! was before I realized libvirt was installed and adding these rules without my knowledge.) The whole point of purge is I don't care what is in there, I only want to populate iptables with the rules I'm giving puppet. So to me, the way that purge is implemented is buggy, although it sounds like if we added support for the ! char we get a working purge for free (until the next thing breaks it?)

from puppetlabs-firewall.

Going through bugs finding the ones that would be fixed by PRs I recently opened. This one would be solved by #267

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.