firewall

Table of Contents

1. Overview - What is the firewall module?
2. Module Description - What does the module do?
3. Setup - The basics of getting started with firewall
   • What firewall Affects
   • Setup Requirements
   • Beginning with firewall
   • Upgrading
4. Usage - Configuration and customization options
   • Default rules - Setting up general configurations for all firewalls
   • Application-Specific Rules - Options for configuring and managing firewalls across applications
   • Additional Uses for the Firewall Module
5. Reference - An under-the-hood peek at what the module is doing
6. Limitations - OS compatibility, etc.
7. Development - Guide for contributing to the module
   • Tests - Testing your configuration

Overview

The firewall module lets you manage firewall rules with Puppet.

Module Description

PuppetLabs' firewall module introduces the firewall resource, which is used to manage and configure firewall rules from within the Puppet DSL. This module offers support for iptables and ip6tables. The module also introduces the firewallchain resource, which allows you to manage chains or firewall lists and ebtables for bridging support. At the moment, only iptables and ip6tables chains are supported.

The firewall module acts on your running firewall, making immediate changes as the catalog executes. Defining default pre and post rules allows you to provide global defaults for your hosts before and after any custom rules. Defining pre and post rules is also necessary to help you avoid locking yourself out of your own boxes when Puppet runs.

Setup

What firewall Affects

• Every node running a firewall
• Firewall settings in your system
• Connection settings for managed nodes
• Unmanaged resources (get purged)

Setup Requirements

Firewall uses Ruby-based providers, so you must enable pluginsync.

Beginning with firewall

In the following two sections, you create new classes and then create firewall rules related to those classes. These steps are optional but provide a framework for firewall rules, which is helpful if you’re just starting to create them.

If you already have rules in place, then you don’t need to do these two sections. However, be aware of the ordering of your firewall rules. The module will dynamically apply rules in the order they appear in the catalog, meaning a deny rule could be applied before the allow rules. This might mean the module hasn’t established some of the important connections, such as the connection to the Puppet master.

The following steps are designed to ensure that you keep your SSH and other connections, primarily your connection to your Puppet master. If you create the pre and post classes described in the first section, then you also need to create the rules described in the second section.

Create the my_fw::pre and my_fw::post Classes

This approach employs a whitelist setup, so you can define what rules you want and everything else is ignored rather than removed.

The code in this section does the following:

• The 'require' parameter in firewall {} ensures my_fw::pre is run before any other rules.
• In the my_fw::post class declaration, the 'before' parameter ensures my_fw::post is run after any other rules.

Therefore, the run order is:

• The rules in my_fw::pre
• Your rules (defined in code)
• The rules in my_fw::post

The rules in the pre and post classes are fairly general. These two classes ensure that you retain connectivity and that you drop unmatched packets appropriately. The rules you define in your manifests are likely specific to the applications you run.

1.) Add the pre class to my_fw/manifests/pre.pp. Your pre.pp file should contain any default rules to be applied first. The rules in this class should be added in the order you want them to run.2.

class my_fw::pre {
  Firewall {
    require => undef,
  }

  # Default firewall rules
  firewall { '000 accept all icmp':
    proto  => 'icmp',
    action => 'accept',
  }->
  firewall { '001 accept all to lo interface':
    proto   => 'all',
    iniface => 'lo',
    action  => 'accept',
  }->
  firewall { '002 reject local traffic not on loopback interface':
    iniface     => '! lo',
    proto       => 'all',
    destination => '127.0.0.1/8',
    action      => 'reject',
  }->
  firewall { '003 accept related established rules':
    proto  => 'all',
    state  => ['RELATED', 'ESTABLISHED'],
    action => 'accept',
  }
}

The rules in pre should allow basic networking (such as ICMP and TCP) and ensure that existing connections are not closed.

2.) Add the post class to my_fw/manifests/post.pp and include any default rules to be applied last.

class my_fw::post {
  firewall { '999 drop all':
    proto  => 'all',
    action => 'drop',
    before => undef,
  }
}

Alternatively, the firewallchain type can be used to set the default policy:

firewallchain { 'INPUT:filter:IPv4':
  ensure => present,
  policy => drop,
  before => undef,
}

Create Firewall Rules

The rules you create here are helpful if you don’t have any existing rules; they help you order your firewall configurations so you don’t lock yourself out of your box.

Rules are persisted automatically between reboots, although there are known issues with ip6tables on older Debian/Ubuntu distributions. There are also known issues with ebtables.

1.) In site.pp or another top-scope file, add the following code to set up a metatype to purge unmanaged firewall resources. This will clear any existing rules and make sure that only rules defined in Puppet exist on the machine.

resources { 'firewall':
  purge => true,
}

To purge unmanaged firewall chains, also add:

resources { 'firewallchain':
  purge => true,
}

Note - If there are unmanaged rules in unmanaged chains, it will take two Puppet runs before the firewall chain is purged. This is different than the purge parameter available in firewallchain.

2.) Use the following code to set up the default parameters for all of the firewall rules you will establish later. These defaults will ensure that the pre and post classes are run in the correct order to avoid locking you out of your box during the first Puppet run.

Firewall {
  before  => Class['my_fw::post'],
  require => Class['my_fw::pre'],
}

3.) Then, declare the my_fw::pre and my_fw::post classes to satisfy dependencies. You can declare these classes using an External Node Classifier or the following code:

class { ['my_fw::pre', 'my_fw::post']: }

4.) Include the firewall class to ensure the correct packages are installed.

class { 'firewall': }

Upgrading

Use these steps if you already have a version of the firewall module installed.

From version 0.2.0 and more recent

Upgrade the module with the puppet module tool as normal:

puppet module upgrade puppetlabs/firewall

Usage

There are two kinds of firewall rules you can use with firewall: default rules and application-specific rules. Default rules apply to general firewall settings, whereas application-specific rules manage firewall settings for a specific application, node, etc.

All rules employ a numbering system in the resource's title that is used for ordering. When titling your rules, make sure you prefix the rule with a number, for example, '000 accept all icmp requests'. 000 runs first, 999 runs last.

Default Rules

You can place default rules in either my_fw::pre or my_fw::post, depending on when you would like them to run. Rules placed in the pre class will run first, and rules in the post class, last.

In iptables, the title of the rule is stored using the comment feature of the underlying firewall subsystem. Values must match '/^\d+[[:graph:][:space:]]+$/'.

Examples of Default Rules

Basic accept ICMP request example:

firewall { '000 accept all icmp requests':
  proto  => 'icmp',
  action => 'accept',
}

Drop all:

firewall { '999 drop all other requests':
  action => 'drop',
}

Example of an IPv6 rule

IPv6 rules can be specified using the ip6tables provider:

firewall { '006 Allow inbound SSH (v6)':
  dport    => 22,
  proto    => tcp,
  action   => accept,
  provider => 'ip6tables',
}

Application-Specific Rules

Puppet doesn't care where you define rules, and this means that you can place your firewall resources as close to the applications and services that you manage as you wish. If you use the roles and profiles pattern then it makes sense to create your firewall rules in the profiles, so they remain close to the services managed by the profile.

This is an example of firewall rules in a profile:

class profile::apache {
  include apache
  apache::vhost { 'mysite': ensure => present }

  firewall { '100 allow http and https access':
    dport  => [80, 443],
    proto  => tcp,
    action => accept,
  }
}

Rule inversion

Firewall rules may be inverted by prefixing the value of a parameter by "! ". If the value is an array, then every item in the array must be prefixed as iptables does not understand inverting a single value.

Parameters that understand inversion are: connmark, ctstate, destination, dport, dst_range, dst_type, iniface, outiface, port, proto, source, sport, src_range, src_type, and state.

Examples:

firewall { '001 disallow esp protocol':
  action => 'accept',
  proto  => '! esp',
}
firewall { '002 drop NEW external website packets with FIN/RST/ACK set and SYN unset':
  chain     => 'INPUT',
  state     => 'NEW',
  action    => 'drop',
  proto     => 'tcp',
  sport     => ['! http', '! 443'],
  source    => '! 10.0.0.0/8',
  tcp_flags => '! FIN,SYN,RST,ACK SYN',
}

Additional Uses for the Firewall Module

You can apply firewall rules to specific nodes. Usually, you will want to put the firewall rule in another class and apply that class to a node. Apply a rule to a node as follows:

node 'some.node.com' {
  firewall { '111 open port 111':
    dport => 111,
  }
}

You can also do more complex things with the firewall resource. This example sets up static NAT for the source network 10.1.2.0/24:

firewall { '100 snat for network foo2':
  chain    => 'POSTROUTING',
  jump     => 'MASQUERADE',
  proto    => 'all',
  outiface => 'eth0',
  source   => '10.1.2.0/24',
  table    => 'nat',
}

You can also change the TCP MSS value for VPN client traffic:

firewall { '110 TCPMSS for VPN clients':
  chain     => 'FORWARD',
  table     => 'mangle',
  source    => '10.0.2.0/24',
  proto     => tcp,
  tcp_flags => 'SYN,RST SYN',
  mss       => '1361:1541',
  set_mss   => '1360',
  jump      => 'TCPMSS',
}

The following will mirror all traffic sent to the server to a secondary host on the LAN with the TEE target:

firewall { '503 Mirror traffic to IDS':
  proto   => all,
  jump    => 'TEE',
  gateway => '10.0.0.2',
  chain   => 'PREROUTING',
  table   => 'mangle',
}

The following example creates a new chain and forwards any port 5000 access to it.

firewall { '100 forward to MY_CHAIN':
  chain   => 'INPUT',
  jump    => 'MY_CHAIN',
}
# The namevar here is in the format chain_name:table:protocol
firewallchain { 'MY_CHAIN:filter:IPv4':
  ensure  => present,
}
firewall { '100 my rule':
  chain   => 'MY_CHAIN',
  action  => 'accept',
  proto   => 'tcp',
  dport   => 5000,
}

Setup NFLOG for a rule.

firewall {'666 for NFLOG':
  proto => 'all',
  jump  => 'NFLOG',
  nflog_group => 3,
  nflog_prefix => "nflog-test",
  nflog_range = 256,
  nflog_threshold => 1,
}

Additional Information

Access the inline documentation:

puppet describe firewall

Or

puppet doc -r type
(and search for firewall)

Reference

Classes:

• firewall

Types:

• firewall
• firewallchain

Facts:

• ip6tables_version
• iptables_version
• iptables_persistent_version

Class: firewall

Performs the basic setup tasks required for using the firewall resources.

At the moment this takes care of:

• iptables-persistent package installation

Include the firewall class for nodes that need to use the resources in this module:

class { 'firewall': }

ensure

Parameter that controls the state of the iptables service on your system, allowing you to disable iptables if you want.

ensure can either be 'running' or 'stopped'. Defaults to 'running'.

pkg_ensure

Parameter that controls the state of the iptables package on your system, allowing you to update it if you wish.

ensure can either be 'present' or 'latest'. Defaults to 'present'.

ebtables_manage

Parameter that controls whether puppet manages the ebtables package or not. If managed, the package will use the value of pkg_ensure as its ensure value.

service_name

Specify the name of the IPv4 iptables service. Defaults defined in firewall::params.

service_name_v6

Specify the name of the IPv6 ip6tables service. Defaults defined in firewall::params.

package_name

Specify the platform-specific package(s) to install. Defaults defined in firewall::params.

Type: firewall

This type enables you to manage firewall rules within Puppet.

Providers

Note: Not all features are available with all providers.

• ip6tables: Ip6tables type provider

  • Required binaries: ip6tables-save, ip6tables.
  • Supported features: address_type, connection_limiting, dnat, hop_limiting, icmp_match, interface_match, iprange, ipsec_dir, ipsec_policy, ipset, iptables, isfirstfrag, ishasmorefrags, islastfrag, length, log_level, log_prefix, log_uid, mark, mask, mss, owner, pkttype, queue_bypass, queue_num, rate_limiting, recent_limiting, reject_type, snat, socket, state_match, string_matching, tcp_flags, hashlimit.

• iptables: Iptables type provider

  • Required binaries: iptables-save, iptables.
  • Default for kernel == linux.
  • Supported features: address_type, clusterip, connection_limiting, dnat, icmp_match, interface_match, iprange, ipsec_dir, ipsec_policy, ipset, iptables, isfragment, length, log_level, log_prefix, log_uid, mark, mask, mss, netmap, owner, pkttype, queue_bypass, queue_num, rate_limiting, recent_limiting, reject_type, snat, socket, state_match, string_matching, tcp_flags, hashlimit.

Autorequires:

If Puppet is managing the iptables or ip6tables chains specified in the chain or jump parameters, the firewall resource will autorequire those firewallchain resources.

If Puppet is managing the iptables or iptables-persistent packages, and the provider is iptables or ip6tables, the firewall resource will autorequire those packages to ensure that any required binaries are installed.

Features

• address_type: The ability to match on source or destination address type.

• clusterip: Configure a simple cluster of nodes that share a certain IP and MAC address without an explicit load balancer in front of them.

• connection_limiting: Connection limiting features.

• dnat: Destination NATing.

• hop_limiting: Hop limiting features.

• icmp_match: The ability to match ICMP types.

• interface_match: Interface matching.

• iprange: The ability to match on source or destination IP range.

• ipsec_dir: The ability to match IPsec policy direction.

• ipsec_policy: The ability to match IPsec policy.

• iptables: The provider provides iptables features.

• isfirstfrag: The ability to match the first fragment of a fragmented ipv6 packet.

• isfragment: The ability to match fragments.

• ishasmorefrags: The ability to match a non-last fragment of a fragmented ipv6 packet.

• islastfrag: The ability to match the last fragment of an ipv6 packet.

• length: The ability to match the length of the layer-3 payload.

• log_level: The ability to control the log level.

• log_prefix: The ability to add prefixes to log messages.

• log_uid: The ability to log the userid of the process which generated the packet.

• mark: The ability to match or set the netfilter mark value associated with the packet.

• mask: The ability to match recent rules based on the ipv4 mask.

• owner: The ability to match owners.

• pkttype: The ability to match a packet type.

• rate_limiting: Rate limiting features.

• recent_limiting: The netfilter recent module.

• reject_type: The ability to control reject messages.

• set_mss: Set the TCP MSS of a packet.

• snat: Source NATing.

• socket: The ability to match open sockets.

• state_match: The ability to match stateful firewall states.

• string_matching: The ability to match a given string by using some pattern matching strategy.

• tcp_flags: The ability to match on particular TCP flag settings.

• netmap: The ability to map entire subnets via source or destination nat rules.

• hashlimit: The ability to use the hashlimit-module

Parameters

• action: This is the action to perform on a match. Valid values for this action are:

  • 'accept': The packet is accepted.

  • 'reject': The packet is rejected with a suitable ICMP response.

  • 'drop': The packet is dropped.

    If you specify no value it will simply match the rule but perform no action unless you provide a provider-specific parameter (such as jump).

• burst: Rate limiting burst value (per second) before limit checks apply. Values must match '/^\d+$/'. Requires the rate_limiting feature.

• clusterip_new: Create a new ClusterIP. You always have to set this on the first rule for a given ClusterIP. Requires the clusterip feature.

• clusterip_hashmode: Specify the hashing mode. Valid values are sourceip, sourceip-sourceport, sourceip-sourceport-destport. Requires the clusterip feature.

• clusterip_clustermac: Specify the ClusterIP MAC address. Has to be a link-layer multicast address. Requires the clusterip feature.

• clusterip_total_nodes: Number of total nodes within this cluster. Requires the clusterip feature.

• clusterip_local_node: Local node number within this cluster. Requires the clusterip feature.

• clusterip_hash_init: Specify the random seed used for hash initialization. Requires the clusterip feature.

• chain: Name of the chain to use. You can provide a user-based chain or use one of the following built-in chains:'INPUT','FORWARD','OUTPUT','PREROUTING', or 'POSTROUTING'. The default value is 'INPUT'. Values must match '/^[a-zA-Z0-9-_]+$/'. Requires the iptables feature.

• checksum_fill: When using a jump value of 'CHECKSUM', this boolean makes sure that a checksum is calculated and filled in a packet that lacks a checksum. Valid values are 'true' or 'false'. Requires the iptables feature.

• clamp_mss_to_pmtu: Enables PMTU Clamping support when using a jump target of 'TCPMSS'. Valid values are 'true' or 'false'.

• connlimit_above: Connection limiting value for matched connections above n. Values must match '/^\d+$/'. Requires the connection_limiting feature.

• connlimit_mask: Connection limiting by subnet mask for matched connections. Apply a subnet mask of /0 to /32 for IPv4, and a subnet mask of /0 to /128 for IPv6. Values must match '/^\d+$/'. Requires the connection_limiting feature.

• connmark: Match the Netfilter mark value associated with the packet. Accepts values mark/mask or mark. These will be converted to hex if they are not hex already. Requires the mark feature.

• ctstate: Matches a packet based on its state in the firewall stateful inspection table, using the conntrack module. Valid values are: 'INVALID', 'ESTABLISHED', 'NEW', 'RELATED', 'UNTRACKED'. Requires the state_match feature.

• date_start: Start Date/Time for the rule to match, which must be in ISO 8601 "T" notation. The possible time range is '1970-01-01T00:00:00' to '2038-01-19T04:17:07'

• date_stop: End Date/Time for the rule to match, which must be in ISO 8601 "T" notation. The possible time range is '1970-01-01T00:00:00' to '2038-01-19T04:17:07'

• destination: The destination address to match. For example: destination => '192.168.1.0/24'. You can also negate a mask by putting ! in front. For example: destination => '! 192.168.2.0/24'. The destination can also be an IPv6 address if your provider supports it.

  For some firewall providers you can pass a range of ports in the format: 'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.

• dport: The destination port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format: 'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.

• dst_range: The destination IP range. For example: dst_range => '192.168.1.1-192.168.1.10'.

  The destination IP range is must in 'IP1-IP2' format. Values in the range must be valid IPv4 or IPv6 addresses. Requires the iprange feature.

• dst_type: The destination address type. For example: dst_type => 'LOCAL'.

  Valid values are:

  • 'UNSPEC': an unspecified address
  • 'UNICAST': a unicast address
  • 'LOCAL': a local address
  • 'BROADCAST': a broadcast address
  • 'ANYCAST': an anycast packet
  • 'MULTICAST': a multicast address
  • 'BLACKHOLE': a blackhole address
  • 'UNREACHABLE': an unreachable address
  • 'PROHIBIT': a prohibited address
  • 'THROW': an unroutable address
  • 'XRESOLVE: an unresolvable address

  Requires the address_type feature.

• ensure: Ensures that the resource is present. Valid values are 'present', 'absent'. The default is 'present'.

• gateway: Used with TEE target to mirror traffic of a machine to a secondary host on the LAN.

• gid: GID or Group owner matching rule. Accepts a string argument only, as iptables does not accept multiple gid in a single statement. Requires the owner feature.

• hashlimit_above: Match if the rate is above amount/quantum. A hash limit option (--hashlimit-upto, --hashlimit-above) and --hashlimit-name are required.

• hashlimit_burst: Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5.

• hashlimit_dstmask: Like --hashlimit-srcmask, but for destination addresses.

• hashlimit_htable_expire: After how many miliseconds do hash entries expire. Corresponds to --hashlimit-htable-expire.

• hashlimit_htable_gcinterval: How many miliseconds between garbage collection intervals. Corresponds to --hashlimit-htable-gcinterval.

• hashlimit_htable_max: Maximum entries in the hash. Corresponds to --hashlimit-htable-max.

• hashlimit_htable_size: The number of buckets of the hash table. Corresponds to --hashlimit-htable-size.

• hashlimit_mode: {srcip|srcport|dstip|dstport} A comma-separated list of objects to take into consideration. If no --hashlimit-mode option is given, hashlimit acts like limit, but at the expensive of doing the hash housekeeping.

• hashlimit_name: The name for the /proc/net/ipt_hashlimit/foo entry. A hash limit option (--hashlimit-upto, --hashlimit-above) and --hashlimit-name are required.

• hashlimit_srcmask: When --hashlimit-mode srcip is used, all source addresses encountered will be grouped according to the given prefix length and the so-created subnet will be subject to hashlimit. prefix must be between (inclusive) 0 and 32. Note that --hashlimit-srcmask 0 is basically doing the same thing as not specifying srcip for --hashlimit-mode, but is technically more expensive.

• hashlimit_upto: Match if the rate is below or equal to amount/quantum. It is specified as a number, with an optional time quantum suffix; the default is 3/hour. A hash limit option (--hashlimit-upto, --hashlimit-above) and --hashlimit-name are required.

• hop_limit: Hop limiting value for matched packets. Values must match '/^\d+$/'. Requires the hop_limiting feature.

• icmp: When matching ICMP packets, this indicates the type of ICMP packet to match. A value of 'any' is not supported. To match any type of ICMP packet, the parameter should be omitted or undefined. Passing in an array of values is not supported. You can either create separate rules for each ICMP type, or alternatively look at the firewall_multi module (https://forge.puppetlabs.com/alexharvey/firewall_multi). Requires the icmp_match feature.

• iniface: Input interface to filter on. Values must match '/^!?\s?[a-zA-Z0-9-._+\:]+$/'. Requires the interface_match feature. Supports interface alias (eth0:0) and negation.

• ipsec_dir: Sets the ipsec policy direction. Valid values are 'in', 'out'. Requires the ipsec_dir feature.

• ipsec_policy: Sets the ipsec policy type. Valid values are 'none', 'ipsec'. Requires the ipsec_policy feature.

• ipset: Matches IP sets. Value must be 'ipset_name (src|dst|src,dst)' and can be negated by putting ! in front. Requires ipset kernel module. Will accept a single element or an array.

• isfirstfrag: If true, matches when the packet is the first fragment of a fragmented ipv6 packet. Cannot be negated. Supported by ipv6 only. Valid values are 'true', 'false'. Requires the isfirstfrag feature.

• isfragment: If 'true', matches when the packet is a tcp fragment of a fragmented packet. Supported by iptables only. Valid values are 'true', 'false'. Requires features isfragment.

• ishasmorefrags: If 'true', matches when the packet has the 'more fragments' bit set. Supported by ipv6 only. Valid values are 'true', 'false'. Requires the ishasmorefrags feature.

• islastfrag: If true, matches when the packet is the last fragment of a fragmented ipv6 packet. Supported by ipv6 only. Valid values are 'true', 'false'. Requires the islastfrag.

• jump: The value for the iptables --jump parameter. Any valid chain name is allowed, but normal values are: 'QUEUE', 'RETURN', 'DNAT', 'SNAT', 'LOG', 'MASQUERADE', 'REDIRECT', 'MARK', 'TCPMSS', 'DSCP', 'NFLOG'.

  For the values 'ACCEPT', 'DROP', and 'REJECT', you must use the generic action parameter. This is to enforce the use of generic parameters where possible for maximum cross-platform modeling.

  If you set both accept and jump parameters, you will get an error, because only one of the options should be set. Requires the iptables feature.

• kernel_timezone: Use the kernel timezone instead of UTC to determine whether a packet meets the time regulations.

• length: Set the value for matching the length of the layer-3 payload. Can be a single number or a range using '-' as a separator. Requires the length feature.

• limit: Rate limiting value for matched packets. The format is: 'rate/[/second/|/minute|/hour|/day]'. Example values are: '50/sec', '40/min', '30/hour', '10/day'. Requires the rate_limiting feature.

• line: Read-only property for caching the rule line.

• log_level: When combined with jump => 'LOG' specifies the system log level to log to. Requires the log_level feature.

• log_prefix: When combined with jump => 'LOG' specifies the log prefix to use when logging. Requires the log_prefix feature.

• log_uid: The ability to log the userid of the process which generated the packet.

• nflog_group: When combined with jump => 'NFLOG' grants the ability to specify the NFLOG group number. Requires the nflog_group feature.

• nflog_prefix: When combined with jump => 'NFLOG' grants the ability to specify a prefix for log entries. Requires the nflog_prefix feature.

• nflog_range: When combined with jump => 'NFLOG' grants the ability to specify the number of bytes to be copied to userspace. Requires the nflog_range feature.

• nflog_threshold: When combined with jump => 'NFLOG' grants the ability to specify the size of the NFLOG threshold. Requires the nflog_threshold feature.

• mask: Sets the mask to use when recent is enabled. Requires the mask feature.

• month_days: Only match on the given days of the month. Possible values are '1' to '31'. Note that specifying '31' will not match on months that do not have a 31st day; the same goes for 28- or 29-day February.

• match_mark: Match the Netfilter mark value associated with the packet. Accepts either of mark/mask or mark. These will be converted to hex if they are not already. Requires the mark feature.

• mss: Sets a given TCP MSS value or range to match.

• name: The canonical name of the rule. This name is also used for ordering, so make sure you prefix the rule with a number. For example:

firewall { '000 this runs first':
  # this rule will run first
}
firewall { '999 this runs last':
  # this rule will run last
}

Depending on the provider, the name of the rule can be stored using the comment feature of the underlying firewall subsystem. Values must match '/^\d+[[:graph:][:space:]]+$/'.

• outiface: Output interface to filter on. Values must match '/^!?\s?[a-zA-Z0-9-._+\:]+$/'. Requires the interface_match feature. Supports interface alias (eth0:0) and negation.

• physdev_in: Match if the packet is entering a bridge from the given interface. Values must match '/^[a-zA-Z0-9-._+]+$/'.

• physdev_out: Match if the packet is leaving a bridge via the given interface. Values must match '/^[a-zA-Z0-9-._+]+$/'.

• physdev_is_bridged: Match if the packet is transversing a bridge. Valid values are true or false.

• physdev_is_in: Match if the packet has entered through a bridge interface. Valid values are true or false.

• physdev_is_bridged: Match if the packet will leave through a bridge interface. Valid values are true or false.

• pkttype: Sets the packet type to match. Valid values are: 'unicast', 'broadcast', and'multicast'. Requires the pkttype feature.

• port: DEPRECATED Using the unspecific 'port' parameter can lead to firewall rules that are unexpectedly too lax. It is recommended to always use the specific dport and sport parameters to avoid this ambiguity. The destination or source port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format: 'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.

• proto: The specific protocol to match for this rule. This is 'tcp' by default. Valid values are:

  • 'ip'
  • 'tcp'
  • 'udp'
  • 'icmp'
  • 'ipv4'
  • 'ipv6'
  • 'ipv6-icmp'
  • 'esp'
  • 'ah'
  • 'vrrp'
  • 'igmp'
  • 'ipencap'
  • 'ospf'
  • 'gre'
  • 'pim'
  • 'all'

• provider: The specific backend to use for this firewall resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform. Available providers are ip6tables and iptables. See the Providers section above for details about these providers.

• queue_bypass: When using a jump value of 'NFQUEUE' this boolean will allow packets to bypass queue_num. This is useful when the process in userspace may not be listening on queue_num all the time.

• queue_num: When using a jump value of 'NFQUEUE' this parameter specifies the queue number to send packets to.

• random: When using a jump value of 'MASQUERADE', 'DNAT', 'REDIRECT', or 'SNAT', this boolean will enable randomized port mapping. Valid values are true or false. Requires the dnat feature.

• rdest: If boolean 'true', adds the destination IP address to the list. Valid values are true or false. Requires the recent_limiting feature and the recent parameter.

• reap: Can only be used in conjunction with the rseconds parameter. If boolean 'true', this will purge entries older than 'seconds' as specified in rseconds. Valid values are true or false. Requires the recent_limiting feature and the recent parameter.

• recent: Enable the recent module. Valid values are: 'set', 'update', 'rcheck', or 'remove'. For example:

# If anyone's appeared on the 'badguy' blacklist within
# the last 60 seconds, drop their traffic, and update the timestamp.
firewall { '100 Drop badguy traffic':
  recent   => 'update',
  rseconds => 60,
  rsource  => true,
  rname    => 'badguy',
  action   => 'DROP',
  chain    => 'FORWARD',
}
# No-one should be sending us traffic on eth0 from localhost
# Blacklist them
firewall { '101 blacklist strange traffic':
  recent      => 'set',
  rsource     => true,
  rname       => 'badguy',
  destination => '127.0.0.0/8',
  iniface     => 'eth0',
  action      => 'DROP',
  chain       => 'FORWARD',
}

Requires the recent_limiting feature.

• reject: When combined with jump => 'REJECT', you can specify a different ICMP response to be sent back to the packet sender. Requires the reject_type feature.

• rhitcount: Used in conjunction with recent => 'update' or recent => 'rcheck'. When used, this will narrow the match to happen only when the address is in the list and packets greater than or equal to the given value have been received. Requires the recent_limiting feature and the recent parameter.

• rname: Specify the name of the list. Takes a string argument. Requires the recent_limiting feature and the recent parameter.

• rseconds: Used in conjunction with recent => 'rcheck' or recent => 'update'. When used, this will narrow the match to only happen when the address is in the list and was seen within the last given number of seconds. Requires the recent_limiting feature and the recent parameter.

• rsource: If boolean 'true', adds the source IP address to the list. Valid values are 'true', 'false'. Requires the recent_limiting feature and the recent parameter.

• rttl: May only be used in conjunction with recent => 'rcheck' or recent => 'update'. If boolean 'true', this will narrow the match to happen only when the address is in the list and the TTL of the current packet matches that of the packet that hit the recent => 'set' rule. If you have problems with DoS attacks via bogus packets from fake source addresses, this parameter may help. Valid values are 'true', 'false'. Requires the recent_limiting feature and the recent parameter.

• set_dscp: When combined with jump => 'DSCP' specifies the dscp marking associated with the packet.

• set_dscp_class: When combined with jump => 'DSCP' specifies the class associated with the packet (valid values found here: http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10103-dscpvalues.html#packetclassification).

• set_mark: Set the Netfilter mark value associated with the packet. Accepts either 'mark/mask' or 'mark'. These will be converted to hex if they are not already. Requires the mark feature.

• set_mss: When combined with jump => 'TCPMSS' specifies the value of the MSS field.

• socket: If 'true', matches if an open socket can be found by doing a socket lookup on the packet. Valid values are 'true', 'false'. Requires the socket feature.

• source: The source address. For example: source => '192.168.2.0/24'. You can also negate a mask by putting ! in front. For example: source => '! 192.168.2.0/24'. The source can also be an IPv6 address if your provider supports it.

• sport: The source port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format:'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.

• src_range: The source IP range. For example: src_range => '192.168.1.1-192.168.1.10'. The source IP range must be in 'IP1-IP2' format. Values in the range must be valid IPv4 or IPv6 addresses. Requires the iprange feature.

• src_type: Specify the source address type. For example: src_type => 'LOCAL'.

  Valid values are:

  • 'UNSPEC': an unspecified address.
  • 'UNICAST': a unicast address.
  • 'LOCAL': a local address.
  • 'BROADCAST': a broadcast address.
  • 'ANYCAST': an anycast packet.
  • 'MULTICAST': a multicast address.
  • 'BLACKHOLE': a blackhole address.
  • 'UNREACHABLE': an unreachable address.
  • 'PROHIBIT': a prohibited address.
  • 'THROW': an unroutable address.
  • 'XRESOLVE': an unresolvable address.

  Requires the address_type feature.

• stat_every: Match one packet every nth packet. Requires stat_mode => 'nth'

• stat_mode: Set the matching mode for statistic matching. Supported modes are random and nth.

• stat_packet: Set the initial counter value for the nth mode. Must be between 0 and the value of stat_every. Defaults to 0. Requires stat_mode => 'nth'

• stat_probability: Set the probability from 0 to 1 for a packet to be randomly matched. It works only with stat_mode => 'random'.

• state: Matches a packet based on its state in the firewall stateful inspection table. Valid values are: 'INVALID', 'ESTABLISHED', 'NEW', 'RELATED', 'UNTRACKED'. Requires the state_match feature.

• string: Set the pattern for string matching. Requires the string_matching feature.

• string_algo: Used in conjunction with string, select the pattern matching strategy. Valid values are: 'bm', 'kmp' (bm = Boyer-Moore, kmp = Knuth-Pratt-Morris). Requires the string_matching feature.

• string_from: Used in conjunction with string, set the offset from which it starts looking for any matching. Requires the string_matching feature.

• string_to: Used in conjunction with string, set the offset up to which should be scanned. Requires the string_matching feature.

• table: Table to use. Valid values are: 'nat', 'mangle', 'filter', 'raw', 'rawpost'. By default the setting is 'filter'. Requires the iptables feature.

• tcp_flags: Match when the TCP flags are as specified. Set as a string with a list of comma-separated flag names for the mask, then a space, then a comma-separated list of flags that should be set. The flags are: 'SYN', 'ACK', 'FIN', 'RST', 'URG', 'PSH', 'ALL', 'NONE'.

  Note that you specify flags in the order that iptables --list rules would list them to avoid having Puppet think you changed the flags. For example, 'FIN,SYN,RST,ACK SYN' matches packets with the SYN bit set and the ACK, RST and FIN bits cleared. Such packets are used to request TCP connection initiation. Requires the tcp_flags feature.

• time_contiguous: When the time_stop value is smaller than the time_start value, match this as a single time period instead of distinct intervals.

• time_start: Start time for the rule to match. The possible time range is '00:00:00' to '23:59:59'. Leading zeroes are allowed (e.g. '06:03') and correctly interpreted as base-10.

• time_stop: End time for the rule to match. The possible time range is '00:00:00' to '23:59:59'. Leading zeroes are allowed (e.g. '06:03') and correctly interpreted as base-10.

• todest: When using jump => 'DNAT', you can specify the new destination address using this parameter. Requires the dnat feature.

• toports: For DNAT this is the port that will replace the destination port. Requires the dnat feature.

• tosource: When using jump => 'SNAT', you can specify the new source address using this parameter. Requires the snat feature.

• to: When using jump => 'NETMAP', you can specify a source or destination subnet to nat to. Requires the netmap feature`.

• uid: UID or Username owner matching rule. Accepts a string argument only, as iptables does not accept multiple uid in a single statement. Requires the owner feature.

• week_days: Only match on the given weekdays. Possible values are 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'.

Type: firewallchain

Enables you to manage rule chains for firewalls.

Currently this type supports only iptables, ip6tables, and ebtables on Linux. It also provides support for setting the default policy on chains and tables that allow it.

Autorequires: If Puppet is managing the iptables or iptables-persistent packages, and the provider is iptables_chain, the firewall resource will autorequire those packages to ensure that any required binaries are installed.

Providers

iptables_chain is the only provider that supports firewallchain.

Features

• iptables_chain: The provider provides iptables chain features.
• policy: Default policy (inbuilt chains only).

Parameters

• ensure: Ensures that the resource is present. Valid values are 'present', 'absent'.

• ignore: Regex to perform on firewall rules to exempt unmanaged rules from purging (when enabled). This is matched against the output of iptables-save. This can be a single regex or an array of them. To support flags, use the ruby inline flag mechanism: a regex such as '/foo/i' can be written as '(?i)foo' or '(?i:foo)'. Only when purge is 'true'.

  Full example:

firewallchain { 'INPUT:filter:IPv4':
  purge  => true,
  ignore => [
    # ignore the fail2ban jump rule
    '-j fail2ban-ssh',
    # ignore any rules with "ignore" (case insensitive) in the comment in the rule
    '--comment "[^"](?i:ignore)[^"]"',
    ],
}

• name: Specify the canonical name of the chain. For iptables the format must be {chain}:{table}:{protocol}.

• policy: Set the action the packet will perform when the end of the chain is reached. It can only be set on inbuilt chains ('INPUT', 'FORWARD', 'OUTPUT', 'PREROUTING', 'POSTROUTING'). Valid values are:

  • 'accept': The packet is accepted.
  • 'drop': The packet is dropped.
  • 'queue': The packet is passed userspace.
  • 'return': The packet is returned to calling (jump) queue or to the default of inbuilt chains.

• provider: The specific backend to use for this firewallchain resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform. The only available provider is:

  iptables_chain: iptables chain provider

  • Required binaries: ebtables-save, ebtables, ip6tables-save, ip6tables, iptables-save, iptables.
  • Default for kernel == linux.
  • Supported features: iptables_chain, policy.

• purge: Purge unmanaged firewall rules in this chain. Valid values are 'false', 'true'.

Note This purge is purging unmanaged rules in a firewall chain, not unmanaged firewall chains. To purge unmanaged firewall chains, use the following instead.

resources { 'firewallchain':
  purge => true,
}

Fact: ip6tables_version

A Facter fact that can be used to determine what the default version of ip6tables is for your operating system/distribution.

Fact: iptables_version

A Facter fact that can be used to determine what the default version of iptables is for your operating system/distribution.

Fact: iptables_persistent_version

Retrieves the version of iptables-persistent from your OS. This is a Debian/Ubuntu specific fact.

Limitations

SLES

The socket parameter is not supported on SLES. In this release it will cause the catalog to fail with iptables failures, rather than correctly warn you that the features are unusable.

Oracle Enterprise Linux

The socket and owner parameters are unsupported on Oracle Enterprise Linux when the "Unbreakable" kernel is used. These may function correctly when using the stock RedHat kernel instead. Declaring either of these parameters on an unsupported system will result in iptable rules failing to apply.

Debian 8 Support

As Puppet Enterprise itself does not yet support Debian 8, use of this module with Puppet Enterprise under a Debian 8 system should be regarded as experimental.

Known Issues

MCollective causes PE to reverse firewall rule order

Firewall rules appear in reverse order if you use MCollective to run Puppet in Puppet Enterprise 2016.1, 2015.3, 2015.2, or 3.8.x.

If you use MCollective to kick off Puppet runs (mco puppet runonce -I agent.example.com) while also using the puppetlabs/firewall module, your firewall rules might be listed in reverse order.

In many firewall configurations, the last rule drops all packets. If the rule order is reversed, this rule is listed first and network connectivity fails.

To prevent this issue, do not use MCollective to kick off Puppet runs. Use any of the following instead:

• Run puppet agent -t on the command line.
• Use a cron job.
• Click Run Puppet in the console.

Reporting Issues

Report found bugs in JIRA:

http://tickets.puppetlabs.com

Development

Puppet Labs modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’t access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.

We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

You can read the complete module contribution guide on the Puppet Labs wiki.

For this particular module, please also read CONTRIBUTING.md before contributing.

Currently we support:

• iptables
• ip6tables
• ebtables (chains only)

Testing

Make sure you have:

• rake
• bundler

Install the necessary gems:

bundle install

And run the tests from the root of the source code:

rake test

If you have a copy of Vagrant 1.1.0 you can also run the system tests:

RS_SET=ubuntu-1404-x64 rspec spec/acceptance
RS_SET=centos-64-x64 rspec spec/acceptance

Supported Release 1.8.2

Summary

This release includes numerous features and bugfixes, See below.

Bugfixes

• Fixing issue with double quotes being removed when part of the rule comment
• Add the --wait flag to the insert/update/delete iptables actions to prevent failures from occuring when iptables is running outside of puppet for iptables >= 1.4.20
• Fix iptables_version and ip6tables_version facts not returning the version

Features

• Support for multiple IP sets in a single rule
• Implement queue_bypass and queue_num parameters for NFQUEUE jump target
• Tighten SELinux permissions on persistent files
• RHEL7 SELinux support for puppet 3
• Manage ip6tables service for Redhat Family

Supported Release 1.8.1

Summary

This release documents an important issue with mcollective that may impact users of the firewall module. Workarounds are suggested as part of this advisory until mcollective can be patched.

Bugfixes

• Add mcollective rule-reversal known limitation

Supported Release 1.8.0

Summary

This release includes numerous features, bugfixes and other improvements including better handling when trying to delete already absent rules.

Features

• Added new 'pkg_ensure' parameter to allow the updating of the iptables package.
• Added new 'log_uid' property.
• Added 'sctp' to the 'proto' property.
• Added support for IPv6 NAT in Linux kernels >= 3.7.
• Added support for the security table.

Bugfixes

• (MODULES-2783) Replaced hardcoded iptables service references with $service_name variable.
• (MODULES-1341) Recover when deleting absent rules.
• (MODULES-3032) Facter flush is called to clear Facter cache get up to date value for ':iptables_persistent_version'.
• (MODULES-2159) Fixed idempotency issue when using connlimit.
• Fixed the handling of chain names that contain '-f'.

Improvements

• Numerous unit and acceptance test improvements.
• Improved handling/use of the '$::iptables_persistent_version' custom fact.
• Better handling of operating systems that use SELinux.

Supported Release 1.7.2

Summary

Small release for support of newer PE versions. This increments the version of PE in the metadata.json file.

2015-08-25 - Supported Release 1.7.1

Summary

This is a bugfix release to deprecate the port parameter. Using the unspecific 'port' parameter can lead to firewall rules that are unexpectedly too lax. It is recommended to always use the specific dport and sport parameters to avoid this ambiguity.

Bugfixes

• Deprecate the port parameter

2015-07-28 - Supported Release 1.7.0

Summary

This release includes numerous features, bugfixes and other improvements including Puppet 4 & PE 2015.2 support as well as ClusterIP and DSCP jump target support.

Features

• Puppet 4 and PE 2015.2 official support
• ClusterIP jump target (including options) now supported
• DSCP jump target (including options) now supported
• SLES 10 now compatible (but not supported)

Bugfixes

• (MODULES-1967) Parse escape sequences from iptables
• (MODULES-1592) Allow src_type and dst_type prefixed with '!' to pass validation
• (MODULES-2186) - iptables rules with -A in comment now supported
• (MODULES-1976) Revise rule name validation for ruby 1.9
• Fix installation hang on Debian Jessie
• Fix for physdev idempotency on EL5

Improvements

• Documentation improvements
• Enforce the seluser on selinux systems
• All the relevent services are now autorequired by the firewall and firewallchain types
• Replace Facter.fact().value() calls with Facter.value() to support Facter 3

2015-05-19 - Supported Release 1.6.0

Summary

This release includes support for TEE, MSS, the time ipt module, Debian 8 support, and a number of test fixes and other improvements.

Features

• Add TEE support
• Add MSS support (including clamp-mss-to-pmtu support)
• Add support for the time ipt module (-m time)
• Add support for Debian 8
• Add support for ICMPv6 types 'neighbour-{solicitation,advertisement}'
• Add support for ICMPv6 type 'too-big'
• Add support for new 'match_mark' property
• Added 'ipv4' and 'ipv6' options to 'proto' property

Bugfixes

• Fix for Systemd-based OSes where systemd needs restarted before being able to pick up new services (MODULES-1984)
• Arch Linux package management fix

2015-03-31 - Supported Release 1.5.0

Summary

This release includes physdev_is_bridged support, checksum_fill support, basic Gentoo compatibility, and a number of test fixes and improvements.

Features

• Add physdev_is_bridged support
• Add checksum_fill support
• Add basic Gentoo compatibility (unsupported)

Bugfixes

• Implementation for resource map munging to allow a single ipt module to be used multiple times in a single rule on older versions of iptables (MODULES-1808)
• Test fixes

2015-01-27 - Supported Release 1.4.0

Summary

This release includes physdev support, the ability to look up usernames from uuid, and a number of bugfixes

Features

• Add netmap feature
• Add physdev support
• Add ability to look up username from uuid (MODULES-753, MODULES-1688)

Bugfixes

• Sync iptables/ip6tables providers (MODULES-1612)
• Fix package names for Amazon and Ubuntu 14.10 (MODULES-1029)
• Fix overly aggressive gsub when ensure => absent (MODULES-1453)
• Unable to parse -m (tcp|udp) rules (MODULES-1552)
• Fix ip6tables provider when iptables-ipv6 package isn't installed for EL6 (MODULES-633)
• Test fixes

2014-12-16 - Supported Release 1.3.0

Summary

This release includes a number of bugfixes and features, including fixing tcp_flags support, and added support for interface aliases, negation for iniface and outiface, and extra configurability for packages and service names.

Features

• Add support for interface aliases (eth0:0) (MODULES-1469)
• Add negation for iniface, outiface (MODULES-1470)
• Make package and service names configurable (MODULES-1309)

Bugfixes

• Fix test regexes for EL5 (MODULES-1565)
• Fix tcp_flags support for ip6tables (MODULES-556)
• Don't arbitrarily limit set_mark for certain chains

2014-11-04 - Supported Release 1.2.0

Summary

This release has a number of new features and bugfixes, including rule inversion, future parser support, improved EL7 support, and the ability to purge ip6tables rules.

Features

• Documentation updates!
• Test updates!
• Add ipset support
• Enable rule inversion
• Future parser support
• Improved support for EL7
• Support netfilter-persistent
• Add support for statistics module
• Add support for mac address source rules
• Add cbt protocol

Bugfixes

• Incorrect use of source => :iptables in the ip6tables provider was making it impossible to purge ip6tables rules (MODULES-41)
• Don't require toports when jump => 'REDIRECT' (MODULES-1086)
• Don't limit which chains iniface and outiface parameters can be used in
• Don't fail on rules added with ipsec/strongswan (MODULES-796)

2014-07-08 - Supported Release 1.1.3

Summary

This is a supported release with test coverage enhancements.

Bugfixes

• Confine to supported kernels

2014-06-04 - Release 1.1.2

Summary

This is a release of the code previously released as 1.1.1, with updated metadata.

2014-05-16 Release 1.1.1

Summary

This release reverts the alphabetical ordering of 1.1.0. We found this caused a regression in the Openstack modules so in the interest of safety we have removed this for now.

2014-05-13 Release 1.1.0

Summary

This release has a significant change from previous releases; we now apply the firewall resources alphabetically by default, removing the need to create pre and post classes just to enforce ordering. It only effects default ordering and further information can be found in the README about this. Please test this in development before rolling into production out of an abundance of caution.

We've also added mask which is required for --recent in recent (no pun intended) versions of iptables, as well as connlimit and connmark. This release has been validated against Ubuntu 14.04 and RHEL7 and should be fully working on those platforms.

Features

• Apply firewall resources alphabetically.
• Add support for connlimit and connmark.
• Add mask as a parameter. (Used exclusively with the recent parameter).

Bugfixes

• Add systemd support for RHEL7.
• Replace &&'s with the correct and in manifests.
• Fix tests on Trusty and RHEL7
• Fix for Fedora Rawhide.
• Fix boolean flag tests.
• Fix DNAT->SNAT typo in an error message.

Known Bugs

• For Oracle, the owner and socket parameters require a workaround to function. Please see the Limitations section of the README.

2014-03-04 Supported Release 1.0.2

Summary

This is a supported release. This release removes a testing symlink that can cause trouble on systems where /var is on a seperate filesystem from the modulepath.

Features

Bugfixes

Known Bugs

• For Oracle, the owner and socket parameters require a workaround to function. Please see the Limitations section of the README.

Supported release - 2014-03-04 1.0.1

Summary

An important bugfix was made to the offset calculation for unmanaged rules to handle rules with 9000+ in the name.

Features

Bugfixes

• Offset calculations assumed unmanaged rules were numbered 9000+.
• Gracefully fail to manage ip6tables on iptables 1.3.x

Known Bugs

• For Oracle, the owner and socket parameters require a workaround to function. Please see the Limitations section of the README.

1.0.0 - 2014-02-11

No changes, just renumbering to 1.0.0.

0.5.0 - 2014-02-10

Summary:

This is a bigger release that brings in "recent" connection limiting (think "port knocking"), firewall chain purging on a per-chain/per-table basis, and support for a few other use cases. This release also fixes a major bug which could cause modifications to the wrong rules when unmanaged rules are present.

New Features:

• Add "recent" limiting via parameters rdest, reap, recent, rhitcount, rname, rseconds, rsource, and rttl
• Add negation support for source and destination
• Add per-chain/table purging support to firewallchain
• IPv4 specific
  • Add random port forwarding support
  • Add ipsec policy matching via ipsec_dir and ipsec_policy
• IPv6 specific
  • Add support for hop limiting via hop_limit parameter
  • Add fragmentation matchers via ishasmorefrags, islastfrag, and isfirstfrag
  • Add support for conntrack stateful firewall matching via ctstate

Bugfixes:

• Boolean fixups allowing false values
• Better detection of unmanaged rules
• Fix multiport rule detection
• Fix sport/dport rule detection
• Make INPUT, OUTPUT, and FORWARD not autorequired for firewall chain filter
• Allow INPUT with the nat table
• Fix src_range & dst_range order detection
• Documentation clarifications
• Fixes to spec tests

0.4.2 - 2013-09-10

Another attempt to fix the packaging issue. We think we understand exactly what is failing and this should work properly for the first time.

0.4.1 - 2013-08-09

Bugfix release to fix a packaging issue that may have caused puppet module install commands to fail.

0.4.0 - 2013-07-11

This release adds support for address type, src/dest ip ranges, and adds additional testing and bugfixes.

Features

• Add src_type and dst_type attributes (Nick Stenning)
• Add src_range and dst_range attributes (Lei Zhang)
• Add SL and SLC operatingsystems as supported (Steve Traylen)

Bugfixes

• Fix parser for bursts other than 5 (Chris Rutter)
• Fix parser for -f in --comment (Georg Koester)
• Add doc headers to class files (Dan Carley)
• Fix lint warnings/errors (Wolf Noble)

0.3.1 - 2013/6/10

This minor release provides some bugfixes and additional tests.

Changes

• Update tests for rspec-system-puppet 2 (Ken Barber)
• Update rspec-system tests for rspec-system-puppet 1.5 (Ken Barber)
• Ensure all services have 'hasstatus => true' for Puppet 2.6 (Ken Barber)
• Accept pre-existing rule with invalid name (Joe Julian)
• Swap log_prefix and log_level order to match the way it's saved (Ken Barber)
• Fix log test to replicate bug #182 (Ken Barber)
• Split argments while maintaining quoted strings (Joe Julian)
• Add more log param tests (Ken Barber)
• Add extra tests for logging parameters (Ken Barber)
• Clarify OS support (Ken Barber)

0.3.0 - 2013/4/25

This release introduces support for Arch Linux and extends support for Fedora 15 and up. There are also lots of bugs fixed and improved testing to prevent regressions.

Changes

• Fix error reporting for insane hostnames (Tomas Doran)
• Support systemd on Fedora 15 and up (Eduardo Gutierrez)
• Move examples to docs (Ken Barber)
• Add support for Arch Linux platform (Ingmar Steen)
• Add match rule for fragments (Georg Koester)
• Fix boolean rules being recognized as changed (Georg Koester)
• Same rules now get deleted (Anastasis Andronidis)
• Socket params test (Ken Barber)
• Ensure parameter can disable firewall (Marc Tardif)

0.2.1 - 2012/3/13

This maintenance release introduces the new README layout, and fixes a bug with iptables_persistent_version.

Changes

• (GH-139) Throw away STDERR from dpkg-query in Fact
• Update README to be consistent with module documentation template
• Fix failing spec tests due to dpkg change in iptables_persistent_version

0.2.0 - 2012/3/3

This release introduces automatic persistence, removing the need for the previous manual dependency requirement for persistent the running rules to the OS persistence file.

Previously you would have required the following in your site.pp (or some other global location):

# Always persist firewall rules
exec { 'persist-firewall':
  command     => $operatingsystem ? {
    'debian'          => '/sbin/iptables-save > /etc/iptables/rules.v4',
    /(RedHat|CentOS)/ => '/sbin/iptables-save > /etc/sysconfig/iptables',
  },
  refreshonly => true,
}
Firewall {
  notify  => Exec['persist-firewall'],
  before  => Class['my_fw::post'],
  require => Class['my_fw::pre'],
}
Firewallchain {
  notify  => Exec['persist-firewall'],
}
resources { "firewall":
  purge => true
}

You only need:

class { 'firewall': }
Firewall {
  before  => Class['my_fw::post'],
  require => Class['my_fw::pre'],
}

To install pre-requisites and to create dependencies on your pre & post rules. Consult the README for more information.

Changes

• Firewall class manifests (Dan Carley)
• Firewall and firewallchain persistence (Dan Carley)
• (GH-134) Autorequire iptables related packages (Dan Carley)
• Typo in #persist_iptables OS normalisation (Dan Carley)
• Tests for #persist_iptables (Dan Carley)
• (GH-129) Replace errant return in autoreq block (Dan Carley)

0.1.1 - 2012/2/28

This release primarily fixes changing parameters in 3.x

Changes

• (GH-128) Change method_missing usage to define_method for 3.x compatibility
• Update travis.yml gem specifications to actually test 2.6
• Change source in Gemfile to use a specific URL for Ruby 2.0.0 compatibility

0.1.0 - 2012/2/24

This release is somewhat belated, so no summary as there are far too many changes this time around. Hopefully we won't fall this far behind again :-).

Changes

• Add support for MARK target and set-mark property (Johan Huysmans)
• Fix broken call to super for ruby-1.9.2 in munge (Ken Barber)
• simple fix of the error message for allowed values of the jump property (Daniel Black)
• Adding OSPF(v3) protocol to puppetlabs-firewall (Arnoud Vermeer)
• Display multi-value: port, sport, dport and state command seperated (Daniel Black)
• Require jump=>LOG for log params (Daniel Black)
• Reject and document icmp => "any" (Dan Carley)
• add firewallchain type and iptables_chain provider (Daniel Black)
• Various fixes for firewallchain resource (Ken Barber)
• Modify firewallchain name to be chain:table:protocol (Ken Barber)
• Fix allvalidchain iteration (Ken Barber)
• Firewall autorequire Firewallchains (Dan Carley)
• Tests and docstring for chain autorequire (Dan Carley)
• Fix README so setup instructions actually work (Ken Barber)
• Support vlan interfaces (interface containing ".") (Johan Huysmans)
• Add tests for VLAN support for iniface/outiface (Ken Barber)
• Add the table when deleting rules (Johan Huysmans)
• Fix tests since we are now prefixing -t)
• Changed 'jump' to 'action', commands to lower case (Jason Short)
• Support interface names containing "+" (Simon Deziel)
• Fix for when iptables-save spews out "FATAL" errors (Sharif Nassar)
• Fix for incorrect limit command arguments for ip6tables provider (Michael Hsu)
• Document Util::Firewall.host_to_ip (Dan Carley)
• Nullify addresses with zero prefixlen (Dan Carley)
• Add support for --tcp-flags (Thomas Vander Stichele)
• Make tcp_flags support a feature (Ken Barber)
• OUTPUT is a valid chain for the mangle table (Adam Gibbins)
• Enable travis-ci support (Ken Barber)
• Convert an existing test to CIDR (Dan Carley)
• Normalise iptables-save to CIDR (Dan Carley)
• be clearer about what distributions we support (Ken Barber)
• add gre protocol to list of acceptable protocols (Jason Hancock)
• Added pkttype property (Ashley Penney)
• Fix mark to not repeat rules with iptables 1.4.1+ (Sharif Nassar)
• Stub iptables_version for now so tests run on non-Linux hosts (Ken Barber)
• Stub iptables facts for set_mark tests (Dan Carley)
• Update formatting of README to meet Puppet Labs best practices (Will Hopper)
• Support for ICMP6 type code resolutions (Dan Carley)
• Insert order hash included chains from different tables (Ken Barber)
• rspec 2.11 compatibility (Jonathan Boyett)
• Add missing class declaration in README (sfozz)
• array_matching is contraindicated (Sharif Nassar)
• Convert port Fixnum into strings (Sharif Nassar)
• Update test framework to the modern age (Ken Barber)
• working with ip6tables support (wuwx)
• Remove gemfile.lock and add to gitignore (William Van Hevelingen)
• Update travis and gemfile to be like stdlib travis files (William Van Hevelingen)
• Add support for -m socket option (Ken Barber)
• Add support for single --sport and --dport parsing (Ken Barber)
• Fix tests for Ruby 1.9.3 from 3e13bf3 (Dan Carley)
• Mock Resolv.getaddress in #host_to_ip (Dan Carley)
• Update docs for source and dest - they are not arrays (Ken Barber)

0.0.4 - 2011/12/05

This release adds two new parameters, 'uid' and 'gid'. As a part of the owner module, these params allow you to specify a uid, username, gid, or group got a match:

firewall { '497 match uid':
  port => '123',
  proto => 'mangle',
  chain => 'OUTPUT',
  action => 'drop'
  uid => '123'
}

This release also adds value munging for the 'log_level', 'source', and 'destination' parameters. The 'source' and 'destination' now support hostnames:

firewall { '498 accept from puppetlabs.com':
  port => '123',
  proto => 'tcp',
  source => 'puppetlabs.com',
  action => 'accept'
}

The 'log_level' parameter now supports using log level names, such as 'warn', 'debug', and 'panic':

firewall { '499 logging':
  port => '123',
  proto => 'udp',
  log_level => 'debug',
  action => 'drop'
}

Additional changes include iptables and ip6tables version facts, general whitespace cleanup, and adding additional unit tests.

Changes

• (#10957) add iptables_version and ip6tables_version facts
• (#11093) Improve log_level property so it converts names to numbers
• (#10723) Munge hostnames and IPs to IPs with CIDR
• (#10718) Add owner-match support
• (#10997) Add fixtures for ipencap
• (#11034) Whitespace cleanup
• (#10690) add port property support to ip6tables

0.0.3 - 2011/11/12

This release introduces a new parameter 'port' which allows you to set both source and destination ports for a match:

firewall { "500 allow NTP requests":
  port => "123",
  proto => "udp",
  action => "accept",
}

We also have the limit parameter finally working:

firewall { "500 limit HTTP requests":
  dport => 80,
  proto => tcp,
  limit => "60/sec",
  burst => 30,
  action => accept,
}

State ordering has been fixed now, and more characters are allowed in the namevar:

• Alphabetical
• Numbers
• Punctuation
• Whitespace

Changes

• (#10693) Ensure -m limit is added for iptables when using 'limit' param
• (#10690) Create new port property
• (#10700) allow additional characters in comment string
• (#9082) Sort iptables --state option values internally to keep it consistent across runs
• (#10324) Remove extraneous whitespace from iptables rule line in spec tests

0.0.2 - 2011/10/26

This is largely a maintanence and cleanup release, but includes the ability to specify ranges of ports in the sport/dport parameter:

firewall { "500 allow port range":
  dport => ["3000-3030","5000-5050"],
  sport => ["1024-65535"],
  action => "accept",
}

Changes

• (#10295) Work around bug #4248 whereby the puppet/util paths are not being loaded correctly on the puppetmaster
• (#10002) Change to dport and sport to handle ranges, and fix handling of name to name to port
• (#10263) Fix tests on Puppet 2.6.x
• (#10163) Cleanup some of the inline documentation and README file to align with general forge usage

0.0.1 - 2011/10/18

Initial release.

Changes

• (#9362) Create action property and perform transformation for accept, drop, reject value for iptables jump parameter
• (#10088) Provide a customised version of CONTRIBUTING.md
• (#10026) Re-arrange provider and type spec files to align with Puppet
• (#10026) Add aliases for test,specs,tests to Rakefile and provide -T as default
• (#9439) fix parsing and deleting existing rules
• (#9583) Fix provider detection for gentoo and unsupported linuxes for the iptables provider
• (#9576) Stub provider so it works properly outside of Linux
• (#9576) Align spec framework with Puppet core
• and lots of other earlier development tasks ...