Bug #10274
firewall: using 0.0.0.0/0 for source and dest works but causes rules to reload
| Status: | Merged - Pending Release | Start date: | 10/25/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Nan Liu | % Done: | 0% | |
| Category: | firewall | Spent time: | - | |
| Target version: | firewall 1.0.0 | |||
| Keywords: | source, dest | Branch: | https://github.com/puppetlabs/puppetlabs-firewall/pull/80 | |
Description
(raised by Nan in another ticket)
Using 0.0.0.0/0 for source and dest works but causes rules to reload.
It also seems to keep applying on CentOS 5.6 iptables v1.3.5:
notice: /Firewall[081 puppetdashboard allow]/source: current_value , should be 0.0.0.0/0 (noop)
notice: /Firewall[081 puppetdashboard allow]/destination: current_value , should be 0.0.0.0/0 (noop)
notice: /Firewall[082 puppet allow]/source: current_value , should be 0.0.0.0/0 (noop)
notice: /Firewall[082 puppet allow]/destination: current_value , should be 0.0.0.0/0 (noop)
notice: Finished catalog run in 0.15 seconds
firewall { '081 puppetdashboard allow':
dport => '3000',
proto => 'tcp',
destination => '0.0.0.0/0',
source => '0.0.0.0/0',
}
firewall { '082 puppet allow':
dport => '8140',
proto => 'tcp',
destination => '0.0.0.0/0',
source => '0.0.0.0/0',
}
Related issues
History
#1
Updated by Ken Barber over 1 year ago
Ok, I have a better idea now, so we need to munge the input and possibly the return value of def destination/source to make sure the ipaddress/netmask is consistent.
Perhaps – or just not allow users to set 0.0.0.0/0 and return an error instead perhaps? Matching against 0.0.0.0/0 is redundant anyway – better to just not try and match in most cases.
So to be clear. The workaround for this problem is to not use ‘source’ or ‘dest’. Based on the above example:
firewall { '081 puppetdashboard allow':
dport => '3000',
proto => 'tcp',
}
firewall { '082 puppet allow':
dport => '8140',
proto => 'tcp',
}
#2
Updated by Ken Barber over 1 year ago
- Assignee set to Nan Liu
- Branch set to https://github.com/nanliu/puppetlabs-firewall/tree/ticket/10274
Nan is working on this now … cheers mate :–).
#3
Updated by Jon Topper about 1 year ago
I hit this bug today too, and I see some changes are sat in the ticket branch that appear to solve the problem. I’m working around it for now, but it’d be great if these could be merged in at some point.
#4
Updated by Dan Carley about 1 year ago
- Branch changed from https://github.com/nanliu/puppetlabs-firewall/tree/ticket/10274 to https://github.com/puppetlabs/puppetlabs-firewall/pull/80
I’ve reworked this a little bit and created a PR. Hopefully that’ll speed things up.
https://github.com/puppetlabs/puppetlabs-firewall/pull/80
#5
Updated by Ken Barber about 1 year ago
- Status changed from Accepted to Merged - Pending Release
- Target version set to firewall 1.0.0