Forge Home


BSD management with Puppet


1,432 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.5.0 (latest)
  • 2.4.0
  • 2.3.0
  • 2.2.0
  • 2.1.1
  • 2.1.0
  • 2.0.0
  • 1.2.0
  • 1.1.0
  • 1.0.0
  • 0.6.1
  • 0.6.0
  • 0.5.0
  • 0.4.5
  • 0.4.4
  • 0.4.1
  • 0.4.0
  • 0.3.2
  • 0.3.1
  • 0.3.0
  • 0.2.8
  • 0.2.5
  • 0.2.4
  • 0.2.1
  • 0.2.0
  • 0.1.2
  • 0.1.1
  • 0.1.0
released May 2nd 2020
This version is compatible with:
  • Puppet Enterprise 2018.1.x, 2017.3.x, 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
  • Puppet >= 4.5.1 < 6.0.0
  • ,

Start using this module

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

Add this module to your Puppetfile:

mod 'zleslie-bsd', '2.5.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add zleslie-bsd
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install zleslie-bsd --version 2.5.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.



zleslie/bsd — version 2.5.0 May 2nd 2020

Puppet BSD

Puppet Forge Build Status

A Puppet module for managing aspects of BSD. Currently supported are FreeBSD and OpenBSD. In here will be various facts, functions and classes for tuning and configuring a system.

It is intended that Puppet users of this code use only the classes and facts in their manifests. The rest of the code here is simply to support the interface supplied by the manifests. Implementing the functions directly is not advised, as the implementation may shift over time as the module requires.


This module requires the 'ipaddress' ruby gem to be installed.

gem install ipaddress

or let Puppet take care:

package { 'ipaddress':
  ensure   => 'present',
  provider => 'gem',


The easiest way to install is to install from the forge.

puppet module install zleslie/bsd


Network configuration is handled under the bsd::network name space. Under this space you will find classes available to configure basic network configuration items like gateways and static address, to more advanced topics like vlan(4) and carp(4) interfaces.

Ideally, this module should support any useful aspect of network configuration, including things like wireless (AP and client) and static routes.


The gateway can be configured for both router and hosts.


To configure static addressing on a host, first you may wish to configure the gateway(s).

class { 'bsd::network':
  v4gateway => '',
  v6gateway => 'fc00::',


To set the upstream gateway on a router system as well as turn on dual stack forwarding, use the following configuration.

class { 'bsd::network':
  v4gateway    => '',
  v6gateway    => '2001:b:b::1',
  v4forwarding => true,
  v6forwarding => true,


Once you have the gateway set, you may wish to set some interface addresses.

bsd::network::interface { 'em0':
  description => 'Primary Interface',
  addresses   => [ '', 'fc00::b0b/64' ],

This will do the needful of setting the configuration for setting the interface address and gateway.

NOTE: This only sets the configuration, it does not currently set the running interfaces addresses.

Interface configuration order

Clonable interfaces might require other interfaces to be configured first. The bsd::network::interface defined type has a 'parents' parameter that can take a string or array of interface names, that in turn will be required to be configured before. Note that the parent interfaces are not required to be managed via Puppet.


Interface configurations are handled per interface type. Each supported type will have an implementation of the library through the user of functions and expose a manifest to the user for configuration.


To create a vlan(4) interface and assign an address to it, use a manifest like the following.

bsd::network::interface::vlan { 'vlan100':
  id         => 100,
  device     => 'em0',
  address    => [''],
  raw_values => ['!/sbin/route add -net',],

It is sometimes desirable to create a VLAN interface without needing to set any interface addresses on it. In such a case, simply leave off the address, and specify the VLAN ID and the device to attach the VLAN to.

bsd::network::interface::vlan { 'vlan100':
  id      => 100,
  device  => 'em0',


The carp(4) device is supported through the bsd::network::interface::carp defined type. Carp interface preemption is handled via the bsd::network::carp class, and defaults to false. This class is automatically included, when a carp device is managed.

class { 'bsd::network::carp':
  preempt => true,

bsd::network::interface::carp { "carp0":
  id         => 1,
  address    => [''],
  carpdev    => 'em0',
  pass       => 'TopSecret',
  raw_values => ['!/sbin/route add -net',],


Closely related to carp(4) interfaces are the pfsync(4) interfaces. They are supported by bsd::network::interface::pfsync defined type.

bsd::network::interface::pfsync { "pfsync0":
  description => 'PF state sync interface',
  syncdev     => 'bge0',
  syncpeer    => '',
  maxupd      => 128,
  defer       => false,

lagg(4) and trunk(4)

bsd::network::interface::trunk { "trunk0":
  interface => ['em0','em1],
  address   => [''],

vlan trunks

To configure a set of interfaces as a trunk passing multiple vlans, just leave the address off of the trunk(4) interface and use it as the device for the vlan(4) interface.

bsd::network::interface::trunk { "trunk0":
  interface => ['em0','em1'],

bsd::network::interface::vlan { "vlan10":
  id      => 10,
  address => [''],
  device  => 'trunk0',

bsd::network::interface::vlan { "vlan11":
  id         => 11,
  address    => [''],
  device     => 'trunk0',
  raw_values => ['!/sbin/route add -net',],

tun tunnel devices

The tun(4) device is supported directly through the bsd::network::interface defined type.

bsd::network::interface { 'tun0':
  raw_values => [
    '!/usr/local/bin/openvpn --daemon'

gif tunnel devices

The gif(4) device is supported directly through the bsd::network::interface defined type. I.e. an IPv6 via IPv4 tunnel could look like:

bsd::network::interface { 'gif0':
  description => 'IPv6 in IPv4 tunnel',
  parents     => 'em0',
  raw_values  => [
    'inet6 alias 2001:470:6c:bbb::2 2001:470:6c:bbb::1 prefixlen 128',
    '!/sbin/route -n add -inet6 default 2001:470:6c:bbb::1',

Note: Ethernet-over-IP modes are not yet supported via this module.

gre tunnel devices

The gre(4) device is supported directly through the bsd::network::interface defined type. Prior to make GRE interfaces work, GRE needs to be allowed. Additionally WCCPv1-style GRE packets can be enabled as well as MobileIP packets. Example of the bsd::network::gre class below shows the default values.

class { 'bsd::network::gre':
  allowed  => true,
  wccp     => false,
  mobileip => false,

bsd::network::interface { 'gre0':
  description => 'Tunnel interface',
  parents     => 'em0',
  raw_values  => [
    ' netmask 0xffffffff link0 up',

pflow interfaces

The pflow(4) device is supported directly through the bsd::network::interface defined type.

bsd::network::interface { 'pflow0':
  description => 'Pflow to collector',
  parents     => 'em0',
  raw_values  => [
    'flowsrc flowdst',
    'pflowproto 10',

wireless interfaces

There are many networking options for wifi. See [](the openbsd documentation) for more information.

Use the following to connect to a wireless network using WPA.

bsd::network::interface::wifi { 'athn0':
  network_name => 'myssid',
  network_key  => 'mysecretkey',

bridge(4) interfaces

bsd::network::interface::bridge { "bridge0":
  interface => ['em0','em1'],

Storing interface data in Hiera example

Now that the primitives of this module have been outlined, you may want to consider storing the data for your interfaces in Hiera. Below is an outline of how this might easily be accomplished.

First we leverage all the standard interface definitions from our hiera_hash() lookup to pass to create_resources().

class profile::network::interfaces {

  case $::osfamily {
    /(Open|Free)BSD/: {
      include bsd::network

      # Manage physical interfaces
      $interfaces = hiera_hash('bsd::network::interface', {})
      create_resources('bsd::network::interface', $interfaces)

Next we repeat the pattern for the various virtual interfaces, including the above class.

class profile::network::interfaces::trunk {
  include profile::network::interfaces

  case $::osfamily {
    /(Open|Free)BSD/: {
      # Setup the trunk interfaces
      $trunk_interfaces = hiera_hash('bsd::network::interface::trunk', {})
      create_resources('bsd::network::interface::trunk', $trunk_interfaces)

A complete example for one users "Jail Host" role looks like the following, assuming the above two classes are included.

bsd::network::v4gateway: ''
bsd::network::v6gateway: '2001:111:111:111::111'
bsd::network::v4forwarding: true
bsd::network::v6forwarding: true

    description: "Router trunk member interface"
    ensure: 'up'
    description: "Router trunk member interface"
    ensure: 'up'
    description: "Jail service loopback"
    ensure: 'up'
      - '2001:111:111:200::100/120'
      - ''

      - 'igb0'
      - 'igb1'
      - '2001:111:111:111::120/120'
      - ''


Please help make this module better by sending pull requests and filing issues for feature requests or bugs. Please adhere to the style and be mindful of the tests.