pfSense Load Balancing

pfSense load balancing

Creating a load balancing pool in pfSense 2.2.4.

In the previous article, we covered how to set up load balancing for a multi-WAN configuration. In this article, we will cover load balancing and failover in cases that don’t involve multiple WAN interfaces.

pfSense Load Balancing

To configure a pfSense load balancing pool, log into the pfSense web GUI and navigate to Services -> Load Balancer. On the Pools tab, click the plus button. This will take you to the Load Balancer configuration page.

In the Name field, fill in a name for the failover pool up to 16 characters in length. This will be the name used to refer to this pool in the Gateway field in the firewall rules. In the Description field, you may enter a description for your own reference. The Description field is optional and does not affect functionality, while the Name field is required. For Mode, select either Load Balance to set up a load balancing pool. In Port, enter the port your servers are listening on, and in Retry specify how many times to check a server before declaring it to be down. In Monitor, select the protocol to be used for monitoring the servers (usually ICMP). In Server IP Address, you enter the IP address that will determine whether the chosen interface is available. If pings to this address fail, this interface is marked as down and is no longer used until it is accessible again.

After selecting an interface and choosing a monitor IP, you can press the Add to pool button to add the interface. After adding the first interface to the pool, select the second interface, sselect its monitor IP, and press Add to pool again. When finished adding interfaces to the pool, press save, and then press Apply changes on the next page.


Failover refers to the ability to use only one WAN connection, but switch to another WAN if the preferred connection fails. This is useful in situations where you want certain traffic, or all of your traffic to utilize one specific WAN connection unless it is unavailable.

To set up a failover group, navigate to Services -> Load Balancer, and click on the plus button, the same as you would when configuring a load balancing pool. In the Name field, fill in a name for the failover pool (again, up to 16 characters in length). In the Description field, you may enter a descripton for your reference.

For the Mode, select Failover. In Port, enter the port your servers are listening on, and in Retry, enter the number of times the server should be checked before being declared to be down. In the Monitor field, set a protocol for monitoring, and in Server IP Address, set the monitor IP. Once you have entered all this information, you can press the Add to pool button. You have added the first interface.

Since this is a failover pool, the first interface aded while be used as long as its monitor IP is responding to pings. If the first interface added to the pool fails, the second interface in the pool will be used. Make sure you add the interfaces to the pool in order of preference. The first in the list will always be used unless it fails, at which point the remaining interfaces in the list are fallen back on in top down order.

Additional interfaces can be added by entering the information for them and clicking Add to pool again. When finished adding interfaces to the pool, press Save, and then Apply Changes on the next page.


External Links:

Inbound Load Balancing on doc.pfsense.org
How to Use pfSense to Load Balance Your Servers on howtoforge.com

pfSense Multi-WAN Configuration: Part Four

pfSense multi-WAN

Setting up multi-WAN load balancing with failover in pfSense 2.2.4

The load balancing functionality in pfSense allows you to distribute traffic over multiple WAN connections in a round-robin fashion. This is done on a per-connection basis. A monitoring IP is configured for each connection, which pfSense will ping, if the pings fail, the interface is marked as down and removed from all pools until the pings succeed again.

pfSense Multi-WAN: Load Balancing 

In pfSense 2.0 and above, Services -> Load Balancer is not used to configure load balancing with a multi-WAN setup. Instead, we use Gateway Groups by navigating to System -> Routing and clicking on the Groups tab. Click the plus button to add a new gateway group.

In the Group Name field, you can enter a group name. The Gateway Priority section is where you configure load balancing. The Tier field determines the link priority in the failover group. Lower-numbered tiers have priority over higher-numbered tiers. Multiple links of the same priority will balance connections until all links at that level are exhausted. If all links in a priority level are exhausted, pfSense will use the next available link in the next priority level.

To illustrate how this works, I created three gateways: WAN, WAN1 and WAN2, as can be seen in the screen capture. Let’s assume that the WAN gateway is my main Internet connection (e.g. a cable modem). Assume that the WAN1 and WAN2 gateways are for my backup Internet connections (e.g. DSL). We want WAN to provide our primary connection to the Internet. When WAN is down, we want our Internet connectivity to be load balanced across WAN1 and WAN2. Therefore, we set WAN to Tier 1 and both WAN1 and WAN2 to Tier 2. Thus, when the higher priority WAN is down, the failover will user WAN1 and WAN2. If either WAN1 or WAN2 go down, pfSense will use the remaining functioning gateway, so that even if two of the gateways are down, we should have some Internet connectivity, albeit with limited bandwidth.

The next field in the table, Virtual IP, allows you to select what virtual IP should be used when the gateway group applies to a local Dynamic DNS, IPsec or OpenVPN endpoint. In my example, since I was not setting up the gateway group to be used in any such scenario, I left this field unchanged.

The next field, Trigger Level, allows you to choose which events trigger exclusion of a gateway. The choices are Member Down, Packet Loss, High Latency, and Packet Loss or High Latency. I chose Packet Loss as the trigger. You can enter a brief Description, and press the Save button. On the next page, you’ll need to press the Apply Changes button.

Next, you need to redirect your firewall traffic to the new gateway. Navigate to Firewall -> Rules, and click on the tab of the interface whose traffic you want to redirect (e.g. LAN). Press the plus button to add a new rule. The default settings can be kept for most settings (Source and Destination should both be set to any). Scroll down to Advanced features, and press the Advanced button in the Gateway section. Select the gateway set up in the previous step in the dropdown box. Enter a brief Description, and press the Save button. On the next page, press the Apply Changes button. If you need to redirect traffic on other interfaces, you will have to set up firewall rules for those interfaces as well.

Finally, you need to navigate to System -> General Setup and make sure you have at least one DNS server for each ISP. This ensures that you still have DNS service if one or more gateways goes down. You may need to set up static routes for your DNS servers; part two of this series went into some detail on how to do this.

Once the gateway groups and firewall rules are configured, your multi-WAN load balancing setup should be complete.

External Links:

Network Load Balancing on Wikipedia

Failover with CARP in PF: Part One

Failover with CARP in PF

FailoverCommon Address Redundancy Protocol (CARP) is a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy. It was developed as a non-patent-encumbered alternative to Virtual Router Redundancy Protocol (VRRP), which is defined in RFC 2281 and 3768 and was quite far along towards becoming an IETF-sanctioned standard. It is also an alternative to the Hot Standby Router Protocol (HSRP). It manages failover at the intersection of the link layer and IP layer of the OSI model. Each CARP group has a virtual MAC address, and the CARP advertisements are sent out with this as the source address, which helps switches determine which port the virtual MAC address is currently at.

One of the main purposes of CARP is to ensure that the network will keep functioning even when a firewall goes down because of errors or planned maintenance activities such as upgrades (failover). CARP works by allowing a group of hosts on the same network segment to share an IP address. This group of hosts is referred to as a “redundancy group”. The redundancy group is assigned an IP address that is shared among the group members. Within the group, one host is designated as the master and the other as backups. The master host is the one that currently holds the shared IP; it responds to any traffic or ARP requests directed at it. If the master goes down, one of the backups will inherit the IP address. The handover from one CARP host to another may be authenticated, essentially by setting a shared secret, much like a password. The master then sends out CARP advertisement messages via multicast using the CARP protocol (IP Protocol 112) on a regular basis, and the backup hosts listen for this advertisement. If the advertisements stop, the backup hosts will begin advertising. The advertisement frequency is configurable, and the host which advertises the most frequently is the one most likely to become master in the event of a failure.


CARP is rather similar to VRRP, with a few significant differences:

  • The CARP protocol is address family independent, with the OpenBSD implementation supporting both IPv4 and IPv6.
  • CARP has an “arpbalance” feature that allows multiple hosts to share a single IP address simultaneously (in this configuration, there is a virtual MAC address for each host, but only one IP address).
  • CARP uses a cryptographically strong SHA-1 keyed-hash message authentication code (HMAC) to protect each advertisement.

Some synchronization is required, an at least in the case of PF firewalls, pfsync can handle it. If it is done properly, active connections will be handed over without noticeable interruption. The purpose of pfsync in this context is to act as a virtual network interface specially designed to synchronize state information between PF firewalls. In order to ensure that pfsync meets the packet volume and latency requirements, the initial implementation has no built-in authentication. An attacker who has local link layer access to the subnet used for pfsync traffic can add, change, or remove states from the firewalls. Therefore, it is strongly recommended that a dedicated, trusted network be used for pfsync. This can be as simple as a crossover cable between interfaces on two firewalls.


Failover with CARP: Configuration

Here is a simple example CARP configuration:

sysctl -w net.inet.card.allow=1
ifconfig carp1 create
ifconfig carp1 vhid 1 pass password carpdev em0 \
advskew 100 10.0.0.1 netmask 255.255.255.0

This does the following:

  • Enales receipt of CARP packets (the default setting)
  • Creates a carp(4) interface (carp1)
  • Configures carp1 for virtual host #1, enables a password, sets em0 as the interface belonging to the group, and makes the host a backup die to the advskew of 100 (assuming the master has an advskew less than 100). The shared IP assigned to this group is 10.0.0.1/255.255.255.0.

In the next article, I will cover failover CARP configuration in BSD with some real world scenarios.

External Links:

Firewall Redundancy with CARP and pfsync at openbsd.org

Firewall Failover with pfsync and CARP at countersiege.com

pfSense Hardware Requirements

pfSense Hardware RequirementsBefore you set up your pfSense system, you probably want to consider pfSense hardware requirements. The two main factors that will determine your requirements are:

  • Throughput required
  • Features that will be used

If you require less than 10 Mbps of throughput, then even a Pentium I with a 100 MHz CPU will do. If you require greater throughput, the official pfSense website has the following guidelines (they assure us that the guidelines offer a bit of breathing room):

Summary of pfSense Hardware Requirements

pfSense Hardware Requirements
Throughput Minumum CPU Speed Minimum Interface
10-20 Mbps 266 MHz PCI
21-50 Mbps 500 MHz PCI
51-200 Mbps 1 GHz PCI
201-500 Mbps 2 GHz PCI-X or PCI-e
501+ Mbps 3 GHz PCI-X or PCI-e


Virtually all network cards are supported by pfSense, but not all network cards are created equal. Intel Pro 100/1000 NICs have solid driver support in FreeBSD. NICs such as the Realtek 8139, however, do not perform as well and may require slightly more overhead. Moreover, with some NICs, there are some things that may not work properly at all, such as VLANs or promiscuous mode required for bridging. Generally if you are buying NICs for a new deployment, Intel Pros are the most reliable.

In addition to these guidelines, pfSense’s hardware sizing guidance page mentions the following about pfSense features and how they may relate to pfSense hardware requirements:

  • VPN – Heavy use of any VPN services will increase CPU requirements. Encrypting and decrypting traffic is CPU intensive. A CPU’s encrypted throughput is roughly 20 percent of its unencrypted throughput. For example, a 266 MHz CPU will max out around 4 Mbps of IPsec throughput; a 500 MHz CPU can push 10-15 Mbps of IPSec; and relatively new server hardware deployments (Xeon 800 FSB) are pushing over 100 Mbps with plenty of capacity to spare. Encryption cards can, however, reduce CPU requirements. Check the FreeBSD hardware compatibility list (HCL) before making a purchase, but Soekris VPN-1401 seems to be well-supported. In addition, you may have better luck by switching protocols. OpenVPN, for example, requires less CPU usage than L2TP/IPSec. I am not sure how well PPTP competes with OpenVPN, but presumably it is less CPU intensive, if for no other reason than the fact that it only offers 128-bit encryption versus 256 bits for OpenVPN. As always, the most recent pfSense build will likely provide the best performance. The number of connections is not as significant as the overall throughput required.
  • Captive portal – While the primary concern is typically throughput, environments with hundreds of simultaneous captive portal users will require slightly more CPU power than otherwise, thus increasing the pfSense hardware requirements.
  • Large state tables – State table entries require about 1 KB of RAM each. The default state table, when full at 10,000 entries, takes up a little less than 10 MB RAM. For large environments requiring state stables with hundreds of thousands of connections, you will want to ensure adequate RAM is available.
  • Packages – Some of the packages require more RAM; Snort and ntop are two that should not be installed on a system with less than 512 MB RAM. Also, the Squid package is used for caching web content and requires extensive use of a hard disk with a large amount of storage. It is not for use with an embedded installation where writes to the compact flash card are kept to a minimum.


To show how these pfSense hardware requirements work in practice, let’s assume we want to set up a pfSense box for a small office. The office has a 50 Mbps net connection; we want to anticipate future use, but we don’t anticipate the office getting a connection faster than 100 Mbps in the forseable future. We also anticipate making use of VPNs for remote connections to the office, but we don’t plan on having more than a few VPN connections at any given time. Of the packages available, we opt to install Snort. From this information, we can determine our minimum hardware requirements:

  • 1 GHz CPU
  • 512 MB RAM (1 GB recommended)
  • Unencrypted throughput of 50 Mbps; unencrypted throughput of 10 Mbps
  • 100 Mbps network interface cards (1 Gbps recommended)

If we want to have a failover for the firewall, our requirements would include a second machine to be used as a failover. Keep in mind that the firewall’s throughput is only a bottleneck for traffic passing through it. Traffic to and from the Internet from the LAN and the DMZ meet that requirement, as does traffic between the LAN and the DMZ. Traffic between two systems on the LAN, however, or two systems on the DMZ would not be affected.
This is my take on minimum pfSense hardware requirements, but those of you who have experience in deploying pfSense firewalls may have a different take on this. If so, feel free to add your own comments on this subject.

External Links:

pfSense Hardware Requirements and Sizing Guidance at pfsense.org

VPN Protocol Comparison List – provides some guidance as to overhead for the different protocols

How to speed up IPSec, hardware encryption devices? at forum.pfsense.org

Firewall Failover with CARP

pfSense CARP Firewall Failover

Configuring CARP settings on the primary firewall in pfSense 2.0.

In the past few articles, I have explained some of the typical load balancing and failover scenarios for which pfSense can be used. In this article, I will demonstrate how to set up a CARP redundant firewall using pfSense.

The Common Address Redundancy Protocol (CARP) is a protocol which allows multiple hosts on the same network to share a set of IP addresses. Its primary purpose is to provide failover redundancy, although it can also provide load balancing functionality. If there are two or more computers running CARP, if the primary server fails, then one of the other servers will take over, and pfsyncd will be used to synchronize packet filter states.

A group of hosts using CARP is called a “group of redundancy”; this group allocates itself an IP address which is shared or divided among the members of this group. Within this group, a host is designated as a “Master” and the other members are designated as slaves. The main host is the one that takes the IP address; this host answers any traffic or ARP request brought to the attention of this address. Each host has, in addition to the shared IP address, a second unique IP address is required. For example, if you want to have 2 cluster members, you will need 2 IP addresses for the real interfaces and then an IP for each virtual IP address. So in this case it would amount to 3.


One use of CARP is the creation of redundant firewalls. The virtual IP address allotted to the group of redundancy is indicated as the address of the default router on the computers behind the group of firewalls. If the main firewall breaks down or is disconnected from the network, the virtual IP address will be taken by one of the firewall slaves and the firewall will continue to be available. Setting up a redundant CARP firewall requires two separate an identical pfSense machines. We want each machine to have at least 3 interfaces: a WAN interface, LAN interface, and an interface dedicated to the syncing process (pfsync).

Firewall Failover with CARP, Step One:  Interface Settings

First, we need to set up the WAN, LAN and SYNC interfaces on both machines. On the first system, designated as the primary system, the settings are as follows:

  • WAN: 192.168.4.1
  • LAN: 192.168.1.30
  • SYNC: 192.168.5.1

For the backup system, the settings are as follows:

  • WAN: 192.168.4.2
  • LAN: 192.168.1.31
  • SYNC: 192.168.5.2


Firewall Failover with CARP, Step Two:  Adding Rules and Enabling CARP Synchronization

On both machines, we need to add a firewall rule to allow traffic on the SYNC interface. Navigate to Firewall -> Rules and click on the SYNC interface tab. Click the “plus” button to add a new firewall rule. At “Protocol“, set the protocol to “any“. At “Description“, add an appropriate description. Then press the “Save” button to save the changes and press the “Apply changes” button on the next page if necessary.

Next, we need to go to the backup pfSense machine and enable CARP synchronization. Navigate to Firewall -> Virtual IPs and click the “CARP Settings” tab. In the “State Synchronization Settings (pfsync)” section, check the “Synchronize States” check box. At “Synchronize Interface“, choose SYNC as the interface. Then press the “Save” button to save the changes.

Returning to the primary pfSense machine, we also need to enable CARP synchronization. Again we will navigate to Firewall -> Virtual IPs and click the “CARP Settings” tab. We will again click the “Synchronize States” check box and choose SYNC as the “Synchronize Interface“. In addition, we will check the following:

  • Synchronize Rules
  • Synchronize nat
  • Synchronize Virtual IPs

At “Synchronize Config to IP“, enter the IP address of the backup pfSense system. Also set the “Remote System Password” to the password of the backup pfSense system. Then press the “Save” button and save the changes.

Firewall Failover with CARP, Step Three: Adding Virtual IPs

Finally, we must configure a virtual IP address for the WAN and LAN interfaces on the primary pfSense machine. Navigate to Firewall -> Virtual IPs and click on the “Virtual IPs” tab. Click the “plus” button to add a new virtual IP. At “Type“, choose the CARP radio button. At “Interface”, set the interface to LAN. At “IP Address“, set the address as the single WAN address that will be used for all clients regardless of whether the primary or backup firewall is active. At “Virtual IP Password“, set a password. You can leave “VHID Group” set to 1 and “Advertising Frequency” set to 0. At “Description“, add an appropriate description. Press the “Save” button to save the changes and press the “Apply changes” button on the next page to apply the changes if necessary.

In order to create the virtual IP address for the LAN interface, we can repeat the above steps, with the following modifications:

  • At “Interface“, set the interface to LAN
  • At “IP Address“, set the address to the single LAN address that will be used as the default gateway for all clients regardless of whether the primary or backup firewall is active
  • The default “VHID Group” setting will be 2; leave this unchanged

Now that we have added the virtual IP addresses, configuration is done. The two firewalls will constantly sync their rules, NAT, and virtual IP settings so that if the primary dies, the backup will immediately take its place.

External Links:

Configuring pfSense Hardware Redundancy (CARP) at doc.pfsense.org

How to Configure a pfSense 2.0 Cluster Using CARP

pfSense Load Balancing: Part Three (Web Server Failover)

In parts one and two of this series, I demonstrated how to configure a gateway group for the WAN gateway. In this article, I will cover setting up a cluster for web server failover using pfSense load balancing.

Web Server Failover, Step One: Add the Monitor

Web Server Failover

Setting up the monitor for our web server failover.

First, navigate to Services -> Load Balancer and click on the “Monitors” tab. Here you will see several predefined entries: ICMP (Internet Control Message Protocol), TCP, HTTPS, and SMTP (Simple Mail Transfer Protocol). Click the “plus” button to add a new entry. At “Name“, specify a name, and at “Description“, enter an appropriate description. At “Type“, set the type to HTTP, and set the “Host” to the IP address of the primary web server. Leave “Path” unchanged, and at “HTTP Code“, leave the code as “200 OK”. Press the “Save” button to save changes and on the next screen, press “Apply changes” if necessary.

Web Server Failover, Step Two: Add the Web Server Pool

Web Server Failover

Setting up a simple pool with a primary and backup web server.

Next, click on the “Pools” tab. Click the “plus” button to add a new pool. At “Name“, specify an appropriate name, and at “Mode“, set the mode to “Manual Failover“. At “Description“, add an appropriate description. Since this is a web server failover pool, at “Port” enter 80. You can leave “Retry” blank, or optionally set the number of retries. Under “Add Item to Pool“, set “Monitor” to whatever you named the monitor as in the previous step (in my case “WebsiteFailover“). At “Server IP Address“, add the IP address of the primary web server and click the “Add to pool” button. Then add the IP address of the backup web server and click the “Add to pool” button. The backup server will show up in the “Pool Disabled” text box. Then press the “Save” button to save the changes and press the “Apply changes” button if necessary on the next page.


Web Server Failover, Step Three: Add the Virtual Server

Next, click the “Virtual Servers” tab and click the “plus” button to add a new virtual server. At “Name“, specify an appropriate name and at “Description“, add a description. At “IP address“, set the appropriate address (most likely this will be the WAN IP, so I typed 192.168.3.1 here). At “Port“, type 80, since this is for web server failover. “At Virtual Server Port“, select the web server pool created in the previous step. Leave “Fail Back Pool” unchanged (none) and leave “Relay Protocol” unchanged (tcp). Press the “Submit” button to submit changes and “Apply changes” on the next page if necessary.

Web Server Failover, Step Four: Add the Firewall Rule

Web Server Failover

Adding a firewall rule to allow traffic to pass through to the web servers.

Finally, we must create a firewall rule for the newly-created virtual server. It would be handy to create a an alias for both the primary and backup web server, so first navigate to Firewall -> Aliases. At “Name” enter a name (I chose “VirtualApache”), and at “Description“, enter a description. Leave “Type” unchanged, and at “Hosts“, enter the IP addresses of both the primary and backup web servers (in my example, 192.168.3.20 and 192.168.3.21). Then press the “Save” button to save, and “Apply changes” if necessary.


Navigate to Firewall -> Rules and click the plus button to create a new firewall rule. As “Action“, select “pass” in the drop-down box. At “Interface“, select “WAN” or whatever is being used as the WAN gateway. At “Protocol“, leave the protocol as “TCP”. At “Source“, leave the “Type” as “any” and click on the “Advanced” button to show the source port range. Select “any” in the drop-down box and type 80 in the top edit box (alternatively, you could select “HTTP” in the drop-down box). At “Destination“, select “Single host or alias” as the “Type“, and at “Address” type the alias you defined above (in my case, VirtualApache). You do not need to specify a “Destination port range” and you should probably leave “Log packets that are handled by the rule” unchecked. At “Description“, enter an appropriate description and click the “Save” button. If necessary, click “Apply changes” on the next page. If you want to pass HTTP Secure (HTTPS) traffic, then you will need to create an additional rule. If so, then follow the steps outlined above, but for the source port range, type 443 or select “HTTPS” in the drop-down box.

Conclusion

Now that configuration is complete, pfSense is set up to automatically redirect traffic from the primary web server to the backup web server in the event of a failure. The pool defines the location of the web servers and the failover mode. The virtual server defines the IP addresses used in the NAT and firewall rules to listen for HTTP traffic, which the virtual server redirects to the pool. The monitor will check on the status of the primary web server by periodically making a web request. If it gets back a “200 OK” code, then the pool will send traffic to the primary server; otherwise, it will send traffic to the backup.

Other Articles in This Series:

pfSense Load Balancing: Part Three (Web Server Failover)

pfSense Load Balancing: Part Two

External Links:

Inbound Load Balancing at doc.pfsense.org”>

pfSense Load Balance Fail-Over Setup

Load Balance and Cluster Failover Webserver (includes how to set up and install pfSense)

How to Use pfSense to Load Balance Your Web Servers

 

pfSense Load Balancing: Part Two

In part one on my series on pfSense load balancing, we configured the two WAN gateways. In part two of this series on pfSense load balancing, we will set up a load balanced gateway group.

pfSense Load Balancing: Configuring Interfaces for MultiWAN

pfSense Load Balancing

Configuring the WAN interface.

First, we must configure the interfaces. Navigate to Interfaces -> WAN. and click on “Enable Interface” if it is not already checked. At “Type“, change the interface type to “Static“. At “Static IP Configuration“, type in an IP address (in this case, 192.168.3.12). Select “24” in the drop-down box next to the IP address edit box, to indicate the proper network prefix. This is important, because if the network prefix is not set, we will not be able to enter a monitor IP address later on. At “Gateway“, specify the WAN gateway (192.168.3.11). Set Leave “Block private networks” and “Block bogon networks” checked. Press the “Save” button to save the changes and on the next page press “Apply changes” if necessary.


Now the OPT1 interface must be configured. Navigate to Interfaces -> OPT1 and click on “Enable Interface”. At “Type“, change the interface type to “Static“. At “Static IP Configuration”, type in an IP address (in this case, 192.168.3.2). Again, select “24” in the drop-down box to indicate the network prefix. At “Gateway“, specify the WAN gateway (192.168.3.1).Again, leave “Block private networks” and “Block bogon networks” checked. Press the “Save” button to save the changes and on the next page press “Apply changes” if necessary.

pfSense Load Balancing: Creating the Gateway Group

pfSense Load Balancing

Adding a gateway group in pfSense 2.0.

Now that both interfaces are configured, we can create the gateway group. Navigate to System -> Routing and click on the “Groups” tab. At “Group Name”, enter a name (e.g., “MultiWAN”). At “Gateway Priority“, set both WAN and WAN2 to “Tier 1”. Leave the “Trigger Level” at “Member Down”, and at “Description“, enter a description (e.g., “WAN gateway group”).Press the “Save” button to save the changes and on the next page press “Apply changes” if necessary.


Before we go any further, we may want to enter a Monitor IP. Click on the “Gateways” tab at System -> Routing and click on the “edit” button for WAN. At “Monitor IP“, enter an alternative monitor IP or domain name (I opted for Google, so I entered Google’s IP, 173.194.43.33). Once this is done, click the “Save” button to save changes. Repeat this procedure for the WAN2 interface (it would be prudent to choose a different monitor IP, so that a failure of the host selected for the monitor IP does not result in pfSense thinking both gateways are down). Once you have pressed the “Save” button on the WAN2 configuration page, press “Apply Changes” on the next page if necessary.

pfSense Load Balancing: Adding a Firewall Rule

Now all that is left to do is to configure a firewall rule. Navigate to Firewall -> Rules and click the “plus” button to create a new firewall rule. At “Action“, select “pass” in the drop-down box. At “Interface“, be sure to select the LAN interface. At “Protocol“, set the protocol to “any”. At “Source“, set the source to “any”, and at “Destination”, set the destination to any. At “Description“, add a description. Scroll down to “Advanced features” and press the “Advanced” button next to “Gateway“. Select “MultiWAN” as the gateway. Then press “Save” to save the changes and on the next page, press “Apply Changes” if necessary.

Now, all traffic from our LAN will go through the gateway group. Since the gateway group consists of two WAN gateways on the same level of priority, traffic will alternate back and forth in round-robin fashion. Also, because each gateway within the group is monitoring an external IP address, pfSense will know when a gateway is down and exclude that member from the group.

Other Articles in This Series:

pfSense Load Balancing: Part One

pfSense Load Balancing: Part Three (Web Server Failover)

External Links:

Configure Load Balancing on Your Site Using the pfSense Firewall

pfSense Load Balancing: Part One

pfSense Load Balancing

Configuring OPT1 as WAN2 so we can set up a gateway group later on.

In computer networking, load balancing is a method for distributing workloads across multiple computers or a computer cluster, network links, CPUs, storage devices, or other resources. When load balancing is employed, we are looking not just to distribute workloads but to optimize resource use, maximize throughput, minimize response time, and avoid overhead. Using multiple components with load balancing instead of a single company can also increase reliability through redundancy. Load balancing has implicit failover capabilities, since load balancing software is capable of detecting when a resource (e.g. network interface, hard drive) is down and excludes it from the group. Load balancing is usually provided by dedicated software or hardware, such as a multilayer switch or a Domain Name System process, or, as we shall soon see, through pfSense. In this article, I will begin our look at pfSense load balancing.


pfSense Load Balancing: Gateway Configuration

As an example, let’s assume we want to set up multiple WAN interfaces and use load balancing on the group. A default WAN gateway was already created when pfSense was set up. In this example, we will use OPT1 as an additional gateway, and then add both the default interface and OPT1 to a newly-created gateway group, which will employ pfSense load balancing to distribute the workload in round-robin fashion.

The first part of our configuration follows the steps outlined in my <a href=”http://pfsensesetup.com/pfsense-gateways/”>article on gateways</a>. In order to set up our second gateway, first browse to System -> Routing. Click on the “Gateway” tab, if it is not already selected. Click on the “plus” button to add a new gateway. At “Interface”, select OPT1 in the drop-down box. At “Name”, type a name, such as “WAN2”. At “Gateway”, type in the IP address of the network interface (in this case, 192.168.3.1). Check “Default Gateway”, and at “Description”, add a description. Then press the “Save” button to save changes, and, if necessary, press the “Apply changes” button on the next screen.


Next, we will make some changes to the WAN interface (the one described as “Interface WAN Dynamic Gateway”). From the Gateways tab, click on the “edit” button. We can leave “Interface and Name” unchanged, but at “Gateway” we will type an IP address (in this case, 192.168.3.11). Click on “Default Gateway” and change the description to something appropriate (e.g. “WAN gateway). Then press the “Save” button to save the changes, and press the “Apply Changes” button if necessary.

Now we have the two interfaces configured correctly. In part two of this series on pfSense load balancing, we will take our newly-configured WAN interfaces and add them to a gateway group, and configure load balancing for the group.

Erratum: The Original Instructions I Posted Contained an Error, and Here’s Why

It occurred to me when composing Part Two of this article that I made a mistake. I set the WAN gateway to 192.168.4.1 originally; however, since WAN2 is on the 192.168.3.0 subnet, and both WAN gateways will likely be connecting to the same network, they should be on the same subnet. Therefore, I amended the instructions for Part One so that WAN is set to 192.168.3.11. I apologize for any confusion I may have caused.

Other Articles in This Series

pfSense Load Balancing: Part Two

pfSense Load Balancing: Part Three (Web Server Failover)

External Links:

Load Balancing at Wikipedia

Setup Incoming pfSense Load Balancing at doc.pfsense.org

Multi-WAN Load Balancing at pfsensesolution.blogspot.com

pfSense Virtual IP Addresses: Part One

pfSense Virtual IP Addresses

Virtual IP address configuration page in pfSense.

A virtual IP address (VIP or VIPA) is an IP address that is not assigned to a specific single server or network interface card (NIC). Rather, it is assigned to multiple applications on a single server, multiple domain names, or multiple servers. Normally, a server IP address depends on the MAC address of the attached NIC, and only one logical IP may be assigned per card. However, VIP addressing enables hosting for several different applications and virtual appliances on a server with only one logical IP address. VIPs have several variations and implementations, including Common Address Redundancy Protocol (CARP) and Proxy Address Resolution Protocol (Proxy ARP).

pfSense Virtual IP Addresses: Proxy ARP

pfSense allows four types of virtual IP addresses: Proxy ARP, CARP, Other, and IP Alias. In this article, I will cover how to configure pfSense virtual IP addresses using Proxy ARP and CARP.


The different types of virtual IP addresses have slightly varied properties. With proxy ARP, the properties are:

  • Can only be forwarded by the firewall (cannot be used by the firewall)
  • Uses Layer 2 (the data link layer) traffic
  • Can be in a different subnet than the interface
  • Cannot respond to pings
pfSense Virtual IP Addresses

Once the Virtual IP has been entered and saved, it is added to the list.

To configure a Proxy ARP virtual IP address, browse to Firewall -> Virtual IPs and Click the “plus” button to add a new virtual IP address. At type, there are four radio buttons; select the radio button for “Proxy ARP” (it should be the default selection). For “Interface”, select “WAN”. At “IP Address(es)“, select “Single address” for “Type” (this should be the default). At “Address“, specify an IP address. At “Description“, enter a description if desired. Then press “Save” to save the changes and “Apply changes” to apply changes if necessary.

Now, the newly-created VIP should be listed at the “Virtual IPs” tab at Firewall -> Virtual IPs.

pfSense Virtual IP Addresses: CARP

You can also configure a virtual IP with CARP in pfSense 2.0. The properties for a CARP VIP include:

  • Can be used or forwarded by the firewall
  • Uses Layer 2 (data link layer) traffic
  • Should be used in firewall fail-over or load-balancing scenarios
  • Must be in the same subnet as the interface
  • Will respond to pings if configured properly

To set up a CARP virtual IP address, browse to Firewall -> Virtual IPs and click the “plus” button to add a new virtual IP address. At “Type“, select the “CARP” radio button, and at “Interface“, select “WAN” (it should be the default). At “IP address(es)“, specify an IP address. At “Virtual IP Password“, specify a password. At “VHID Group“, choose a group. At “Advertising Frequency“, select a frequency (0 for master). At “Description“, add a description if desired. Then press “Save” to save the changes and “Apply changes” to apply the changes if necessary.

In part two of this series, I will cover setting up virtual IP addresses with IP Alias and Other types.

Once again, the “Virtual IPs” tab under Firewall -> Virtual IPs should display the newly-created VIP within the list of pfSense virtual IP addresses. In part two, I will cover IP aliases (new to pfSense 2.0) and other VIPs.


External Links:

What are Virtual IP Addresses? at doc.pfsense.org

© 2013 David Zientara. All rights reserved. Privacy Policy