Forge Home

iptables

Flexible iptables management bypassing the need for order specification

31,256 downloads

1,396 latest version

4.8 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.1.0 (latest)
  • 2.0.0 (deleted)
  • 2.0.0-alpha
  • 1.1.0
  • 1.0.0
  • 0.2.0
  • 0.1.1
  • 0.1.0
released Aug 11th 2020
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 >=3.8.0

Start using this module

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

Add this module to your Puppetfile:

mod 'mighq-iptables', '2.1.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add mighq-iptables
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install mighq-iptables --version 2.1.0

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

mighq/iptables — version 2.1.0 Aug 11th 2020

iptables

Overview

Flexible iptables management by puppet.

Based on concept of "immutable" and "open" chains.

immutable / builtin

Chain, which is defined at once, on one place in catalogue. The order of rules is fixed. Cannot be changed later in catalogue.

Builtin chains also have default policy attribute, they are like immutable otherwise.

open

Chain defined without rules in it. Rules can be added from multiple places in catalogue. Order of rules does not matter.

unmanaged

Chain which is defined to be created and can be referenced, but puppet will ignore its contents. Good for chains, which are managed by some other software (ie. docker).

As an alternative, these chains can be declared in a "wildcard" (or rather - regexp) fashion. This does not cause the module to create any chains (as the exact name to be created is not known), but any matching chain will be fully preserved, including all rules, counters etc, when ruleset is applied to kernel.

Example usage

# manage iptables
include iptables

# define structure of input rules
iptables::chain::builtin { 'filter:INPUT':
  policy => 'DROP',
  jumps  => [
    'SERVICES',
  ],
}

# we are not router, drop forwarding
iptables::chain::builtin { 'filter:FORWARD':
  policy => 'DROP',
}

# define structure of NAT rules
iptables::chain::builtin { 'nat:PREROUTING':
  policy => 'ACCEPT',
  jumps  => [
    'LOAD_BALANCE',
  ],
}

# immutable chain, where the rule order matters
iptables::chain::immutable { 'nat:LOAD_BALANCE':
  comment => 'balance web traffic to 2 workers',
  rules => [
    '-m tcp -p tcp --dport 80 -m statistic --mode nth --every 2 -j DNAT --to-destination 1.2.3.4:80',
    '-m tcp -p tcp --dport 80 -m statistic --mode nth --every 1 -j DNAT --to-destination 5.6.7.8:80',
  ],
}

# create chain for docker forwarding rules but do not manage the content
iptables::chain::unmanaged { 'filter:DOCKER-USER' :
  comment => 'Used by Docker',
}

# preserve Calico chains when refreshing the ruleset
iptables::chain::unmanaged { 'filter:/cali-(fw|tw)-cali[0-9a-f]{11}/' :
  comment => 'Calico forwarding chains',
}

# flexible chain for adding services (rule order does not matter)
iptables::chain::open { 'filter:SERVICES':
  comment => 'put allowed services here',
}

# allow web server
iptables::rule { 'ssh server':
  table   => 'filter',
  chain   => 'SERVICES',
  command => '-m tcp -p tcp --dport 22 -j ACCEPT',
}

# allow mail server
iptables::rule { 'mail server':
  table   => 'filter',
  chain   => 'SERVICES',
  command => '-m tcp -p tcp --dport 25 -j ACCEPT',
}

Known problems

  • does not sync definition file with runtime settings in the kernel, only on file refresh
  • support for IPv4 only