Forge Home

packetfilter

Setup basic iptables/ip6tables rules

6,715 downloads

6,171 latest version

5.0 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 2.0.3 (latest)
  • 2.0.2
released May 8th 2018
This version is compatible with:
  • Puppet Enterprise 2023.5.x, 2023.4.x, 2023.3.x, 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x, 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
  • Puppet >= 4.0.0
  • , , ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'puppetfinland-packetfilter', '2.0.3'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add puppetfinland-packetfilter
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install puppetfinland-packetfilter --version 2.0.3

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download

Documentation

puppetfinland/packetfilter — version 2.0.3 May 8th 2018

Build Status

packetfilter

A general-purpose packetfilter module for Puppet. Uses Puppet Labs firewall for the hard lifting. Supports both IPv4 (iptables) and IPv6 (ip6tables).

Module usage

To get a basic set of rules suitable for a traffic endpoint such as normal server or desktop:

include ::packetfilter::endpoint

To create a simple masquerading router:

class { '::packetfilter::router':
  source   => '192.168.0.50/24',
  iniface  => 'br0',
  outiface => 'eth0',
}

Other modules can add their own firewall resources: the ::packetfilter class will realize all virtual firewall resources tagged with 'default'. This feature is quite useful when used within Puppet modules that manage a network-facing daemon (e.g. snmpd, apache2, ssh): the daemon module can open up holes into the firewall as needed. For a typical example see ::postfix::packetfilter.

Historical note on run stages

Previously this module added blanket DENY rules to INPUT and FORWARD chains. This was achieved with a separate run stage which came after the main stage. In Puppet 3 this was a "belt-and-suspenders" approach in that prepending the resource title with, say, '999' already had the same effect. Puppet's parse order changed, however, in Puppet 4, and there was no longer any reasonable way to order a resource except with explicit resource relationships or with run stages. Setting such explicit relationships (as described in current puppetlabs/firewall documentation) only works for simplistic cases, not when firewall rules are combined from several different, independent modules, and when one does not want to create arbitrary dependencies on the "packetfilter::deny" classes.

Unfortunately run stages had two major problems in Puppet 4 at least:

  • Rules in post run stage were not saved to /etc/iptables.save or equivalent
  • They could create dependency cycles in some cases

So run stages had to go. In lieue of explicit resource relationships the only fairly secure approach, which version 1.0.0 of this module uses, is to get rid of the DENY rules, and replace them with a DROP policy for the whole chain. As Puppet now applies resources in the parse order, we can be fairly certain that the ACCEPT rules in packetfilter module get applied first, and only after that the policy is set to DROP in the INPUT and FORWARD chains. Then other modules can apply their ACCEPT rules in whatever order they want.

All this said, puppetlabs-firewall has an interesting property: even though Puppet debug log clearly shows the rules being applied in run-time order, the actual order of the rules will end up being based on the title. So all the refactoring discussed about was probably unnecessary.

Many of the subclasses could probably be merged if parameters and their default values were chosen carefully.