[Previous: Packet Queueing and Prioritization] [Contents] [Next: Packet Tagging]

PF: Address Pools and Load Balancing

Table of Contents

• Introduction
• NAT Address Pool
• Load Balancing Incoming Connections
• Load Balancing Outgoing Traffic
  • Ruleset Example

Introduction

There are four methods for using an address pool:

• bitmask - grafts the network portion of the pool address over top of the address that is being modified (source address for nat rules, destination address for rdr rules). Example: if the address pool is 192.0.2.1/24 and the address being modified is 10.0.0.50, then the resulting address will be 192.0.2.50. If the address pool is 192.0.2.1/25 and the address being modified is 10.0.0.130, then the resulting address will be 192.0.2.2.
• random - randomly selects an address from the pool.
• source-hash - uses a hash of the source address to determine which address to use from the pool. This method ensures that a given source address is always mapped to the same pool address. The key that is fed to the hashing algorithm can optionally be specified after the source-hash keyword in hex format or as a string. By default, pfctl(8) will generate a random key every time the ruleset is loaded.
• round-robin - loops through the address pool in sequence. This is the default method and also the only method allowed when the address pool is specified using a table.

Except for the round-robin method, the address pool must be expressed as a CIDR (Classless Inter-Domain Routing) network block. The round-robin method will accept multiple individual addresses using a list or table.

The sticky-address option can be used with the random and round-robin pool types to ensure that a particular source address is always mapped to the same redirection address.

NAT Address Pool

In this example a pool of two addresses is being used to translate outgoing packets. For each outgoing connection PF will rotate through the addresses in a round-robin manner.

nat on $ext_if inet from any to any -> { 192.0.2.5, 192.0.2.10 }

One drawback with this method is that successive connections from the same internal address will not always be translated to the same translation address. This can cause interference, for example, when browsing websites that track user logins based on IP address. An alternate approach is to use the source-hash method so that each internal address is always translated to the same translation address. To do this, the address pool must be a CIDR network block.

nat on $ext_if inet from any to any -> 192.0.2.4/31 source-hash

This nat rule uses the address pool 192.0.2.4/31 (192.0.2.4 - 192.0.2.5) as the translation address for outgoing packets. Each internal address will always be translated to the same translation address because of the source-hash keyword.

Load Balance Incoming Connections

web_servers = "{ 10.0.0.10, 10.0.0.11, 10.0.0.13 }"

rdr on $ext_if proto tcp from any to any port 80 -> $web_servers \
    round-robin sticky-address

Successive connections will be redirected to the web servers in a round-robin manner with connections from the same source being sent to the same web server. This "sticky connection" will exist as long as there are states that refer to this connection. Once the states expire, so will the sticky connection. Further connections from that host will be redirected to the next web server in the round robin.

Load Balance Outgoing Traffic

One additional piece of information that's needed to do this is the IP address of the adjacent router on each Internet connection. This is fed to the route-to option to control the destination of outgoing packets.

The following example balances outgoing traffic across two Internet connections:

lan_net = "192.168.0.0/24"
int_if  = "dc0"
ext_if1 = "fxp0"
ext_if2 = "fxp1"
ext_gw1 = "68.146.224.1"
ext_gw2 = "142.59.76.1"

pass in on $int_if route-to \
   { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
   from $lan_net to any keep state

The route-to option is used on traffic coming in on the internal interface to specify the outgoing network interfaces that traffic will be balanced across along with their respective gateways. Note that the route-to option must be present on each filter rule that traffic is to be balanced for. Return packets will be routed back to the same external interface that they exited (this is done by the ISPs) and will be routed back to the internal network normally.

To ensure that packets with a source address belonging to $ext_if1 are always routed to $ext_gw1 (and similarly for $ext_if2 and $ext_gw2), the following two lines should be included in the ruleset:

pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 \
   to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 \
   to any

Finally, NAT can also be used on each outgoing interface:

nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

A complete example that load balances outgoing traffic might look something like this:

[Previous: Packet Queueing and Prioritization] [Contents] [Next: Packet Tagging]