Video: Adding Firewall Rules

Since I made a video yesterday on NAT port forwarding, I thought I’d build on that by covering firewall rules in pfSense 2.0:

pfSense UPnP and NAT-PMP

In a previous article, I described how to configure port forwarding in pfSense. But what if port forwarding could be done automatically? That is the object of the Universal Plug and Play Protocol and Nat Port Mapping Protocol, and both are supported by pfSense. In this article, I will explain how to configure pfSense UPnP and NAT-PMP protocols.

UPnP and NAT-PMP Explained

Universal Plug and Play (UPnP) is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices to seamlessly discover each other’s presence on the network and establish functional network services for data sharing, communications, and entertainment. It is intended primarily for residential networks without enterprise class devices (the reasons for this will become apparent soon) and is primarily used in Microsoft systems. The concept of UPnP is an extension of plug-and-play, a technology for dynamically attaching devices directly to a computer.

Among other things, UPnP provides a solution for NAT traversal via its implementation of the Internet Gateway Device Protocol. Many routers and firewalls expose themselves as Internet Gateway Devices, allowing any local UPnP control point to perform a variety of actions, including retrieving the external IP address of the device, enumerate existing port mappings, and add or remove port mappings. By adding a port mapping, a UPnP controller behind the IGD can enable traversal of the IGD from an external address to an internal client. UPnP uses UDP port 1900 and TCP port 2869.

NAT Port Mapping Protocol (NAT-PMP) is another means of accomplishing what UPnP does. It was introduced by Apple in 2005 as an alternative to IGD. NAT-PMP allows a computer in a private network to automatically configure the router to allow parties outside the private network to contact it. It automates the process of port forwarding. Included in the protocol is a method for retrieving the public IP address of a NAT gateway. NAT-PMP runs over UDP port 5351.

Configuring pfSense UPnP and NAT-PMP

pfSense UPnP

Enabling UPnP and NAT-PMP in pfSense 2.0.

As it happens, both UPnP and NAT-PMP are supported by pfSense 2.0. Enabling pfSense UPnP and NAT-PMP  is relatively easy as well. To enable these services, first navigate to Services -> UPnP & NAT-PMP. Check the “Enable UPnP & NAT-PMP” check box. Below that, check either “Allow UPnP Port Mapping“, “Allow NAT-PMP Port Mapping“, or both. At “Interfaces (generally LAN)“, select an interface (or hold down the CTRL key while clicking to select multiple interfaces). Then press the “Change” button to change the settings. You have now configured pfSense UPnP and/or NAT-PMP.


There are several additional options that are worth noting. Below “Interfaces”, you can specify a “Maximum Download Speed” (in Kbits/s). You can also specify a “Maximum Upload Speed” (also in Kbits/s). “Override WAN address” can be used to override the miniupnp listening address. “Traffic Shaping Queue” allows you to specify an already-defined traffic shaping queue (for more information, see parts one, two, and three of my series on traffic shaping). Checking “Enable Log Packets” will keep a log of UPnP and NAT-PMP traffic. Checking “Use system uptime instead of UPnP and NAT-PMP service uptime” will use the system’s uptime in the logs. Checking “By default deny access to UPnP & NAT-PNP” will block UPnP and NAT-PNP traffic except for traffic specifically allowed in the below “User specified permissions“. There, you can define up to four permissions in the following format: [allow or deny][external port or range][internal IP address or IP address/CIDR][internal port or range].

pfSense UPnP and NAT-PNP:  Potential Security Risks

Now that I have described pfSense UPnP and NAT-PNP and how to configure them, I suppose it is only fair to note that enabling these services and allowing devices to make and modify their own firewall rules has some serious security implications. In January 2013, the security company Rapid7 reported on a six-month research program in which a team scanned for signals from UPnP-enabled devices announcing their availability for internet connect. Some 6900 products from 1500 companies at 81 million IP addresses responded to their requests. 80% of the devices are home routers; others include printers, webcams, and surveillance cameras. With this in mind, it is little wonder that UPnP  is not targeted many at home routers and not enterprise-level networking equipment, as IT departments would likely be wary of deploying equipment with such glaring security vulnerabilities. I do not know of any similar studies covering NAT-PMP devices, but I would assume this has more to do with the greater popularity of UPnP than it has anything to do with NAT-PMP devices being more secure. It might be prudent to dedicate a separate interface to UPnP and/or NAT-PMP devices. It might be even more prudent to use the “By default deny access to UPnP & NAT-PNP” feature and only allow specific pfSense UPnP and NAT-PMP traffic.


External Links:

UPnP at Wikipedia

NAT-PMP at Wikipedia

What is pfSense UPnP? at doc.pfsense.org

UPnP flaws turn millions of firewalls into doorstops at nakedsecurity

Video: NAT Port Forwarding

I made another video; this one covers NAT port forwarding and shows how pfSense automatically generates a rule for each port forwarding entry:

Video: Using Aliases

Here’s another video I made. This one covers creating aliases in pfSense 2.0:

pfSense PPPoE Server Configuration

In previous articles, setting up VPN tunnels in pfSense was discussed, but not how to set up a server using Point-to-Point Protocol over Ethernet for a VPN. In this article, I will describe how to set up a pfSense PPPoE server.

Point-to-Point Protocol Explained

pfSense PPPoE Server

Configuring a PPPoE server in pfSense 2.0.

The Point-to-Point Protocol over Ethernet is a network protocol for encapsulating PPP frames inside Ethernet frames. It was defined in RFC 2516 in February 1999. PPPoE was developed to solve a problem DSL service providers were encountering. In the mid and late 1990s, dialup service using Point-to-Point Protocol (PPP) was the dominant means of connecting to the internet for home users, whereas small office/home office (SOHO) users who did not require or could not afford a T1 or faster but found dialup insufficient gravitated towards Integrated Services Digital Network (ISDN) connections. By 1998, DSL technology was becoming more affordable, but a protocol that would work with DSL and meet the requirements of the typical small business customer that DSL providers envisioned as their typical users did not exist. Such a protocol would have to allow for easily connecting an entire LAN to the internet, providing services on a local LAN accessible from the far side of the connection, and simultaneous access to multiple data sources, among other requirements.


DSL providers, hoping to build upon PPP, already ubiquitous with dialup services, soon gravitated towards PPPoE. Essentially all operating systems at the time had a PPP stack, and the design of PPPoE allowed for a simple shim at the line-encoding stage to convert from PPP to PPPoE, thus enabling vendors to heavily leverage their existing software and deliver products quickly. Moreover, since PPPoE used a different frame type, the DSL hardware could act as a simple bridge, passing some frames and ignoring others. As a result, DSL modems could be much simpler than routers. As of 2013, PPPoE seems to be on the way out, as many providers are implementing other methods of broadband delivery. However, PPPoE continues to be in wide use.


Configuring a pfSense PPPoE Server

pfSense PPPoE Server

The newly-created server now appears in the table at Services -> PPPoE Server.

To enable a pfSense PPPoE server, first navigate to Services -> PPPoE Server, then click on the “plus” button to add a new PPPoE instance. On the next page, check “Enable PPPoE Server“. At “Interface“, choose an interface (you probably want to set it to the WAN interface), and at “Subnet Mask“, input the subnet mask. At “No. PPPoE Users“, enter the maximum number of clients you wish to allow. At “Server Address“, set the address to an unused IP address that pfSense will use to serve PPPoE clients. At “Remote Address Range“, set the range range to the starting unused IP address. The range will run as far as the maximum number of clients specified at “No. PPPoE Users“. At “Description“, enter an appropriate description. At “DNS Servers“, you can enter a set of DNS servers or leave it blank if you want the defaults to be used. Unless you want to use a RADIUS server for authentication, skip past the RADIUS settings and scroll down to “User(s)“. Click on the “plus” button and add at least one username, password, and IP address. When you are done, press the “Save” button to save the settings and the next page, press “Apply changes” button to apply the changes.

pfSense PPPoE Server

Adding a firewall rule for the PPPoE server.

Now, all that remains to be done is to add a firewall rule to allow traffic to permit traffic from PPPoE clients. Navigate to Firewall -> Rules and click on the “PPPoE Server” tab. Once there, click on the “plus” button to add a new rule. At “Action“, choose “Pass“, and at “Interface“, choose “PPPoE VPN“. For “Protocol“, select “any”, and for “Destination“, select the target destination for PPPoE clients (e.g. LAN subnet). You can probably keep “Log packets that are handled by this rule” unchecked, and at “Description“, enter an appropriate description. Finally, press the “Save” button to save changes, and “Apply changes” to apply the changes. Once the rule has been created, our pfSense PPPoE server will be ready for to be accessed.

External Links:

pfSense PPPoE Server Settings at doc.pfsense.org

Video: Configuring DHCP Settings in pfSense 2.0

I just completed another video. This one covers configuring DHCP settings, including setting up DHCP static mappings in order to prevent unknown clients from accessing the DHCP server. Don’t forget to press “Save” and “Apply changes” after finishing configuration.

pfSense OLSR (Optimized Link State Routing)

pfSense 2.0 incorporates a number of useful services, a number of which will be the focus of future articles on this site. In this article, I will cover the Optimized Link State Routing Protocol (OLSR): what it is, why it is useful, and how to enable pfSense OLSR.

OLSR Explained

The Optimized Link State Routing Protocol (OLSR) is an IP routing protocol optimized for mobile ad hoc networks, which can also be used on other wireless ad hoc networks. It was defined in RFC 3626 in October 2003. Mobile ad hoc networks (MANETs) are self-configuring, infrastructureless network of mobile devices connected by wireless. OLSR is a proactive link-state routing protocol which uses hello and topology control (TC) messages to discover and then disseminate link state information throughout the mobile ad hoc network. Individual nodes use this topology to computer next hop destinations for all nodes in the network using shortest hop forwarding paths. Unlike link-state routing protocols such as Open Shortest Path First (OSPF), in which there is a designated router on every link to perform flooding of topology information, the OLSR protocol uses Hello messages to discover 2-hop neighbor information and perform a distributed election of a set of multipoint relays (MPRs).


MPRs are the key concept used in the OLSR protocol. The MPRs forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. As a result, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may choose to report only links between itself and its MPR selectors. Thus, unlike in the classic link state algorithm, partial link state information is distributed in the network and used for route calculation.

Enabling pfSense OLSR

pfSense OLSR

Enabling the OLSR daemon in pfSense 2.0.

In order to enable pfSense OLSR via the pfSense web GUI, first navigate to Services -> OLSR and check the “Enable OLSR” check box. At “Link Quality Level“, you have a choice of 0, 1 or 2. A link quality of 0 will cause link hysteresis to take effect, which will result in more robust links at the cost of speed. A link quality of 1 will only use link quality calculations when calculating/selecting MPRs. Finally, a link quality of 2 will cause routes to be calculated based on link quality information. As of this writing, 0 and 1 seem pretty safe options, whereas setting Link Quality to 2 seems to cause olsrd to crash. At “Interface“, choose an interface (use the CTRL key to select multiple interfaces). Then press the “Save” button to save the changes.

Additional pfSense OLSR Options

Now, pfSense OLSR will be enabled. However, there are several other options for OLSR in pfSense, the most notable of which is the HTTPInfo plugin. Enabling the HTTPInfo plugin allows us to view and monitor the status of the OLSR mesh network. You can enable this plugin by checking the “Enable HTTPInfo Plugin” check box. Below that, we need to specify an “HTTPInfo Port” (the port that HTTPInfo will listen on), and specify “Allowed Host(s)” (hosts that are allowed to access the HTTPInfo service). We also need to specify the subnet mask at “Allowed Host(s) Subnet“.


There are a few other pfSense OLSR options that should be noted. Checking “Enable Dynamic Gateway” enables the OLSR Dynamic Gateways plugin. This plugin dynamically detects when nodes obtain and lose Internet connectivity and updates the host and network association (HNA) information based on this. The main object of this plugin is to poll for an Internet route and add or remove such a route from the local HNA set if a change is detected. The “Announce self as Dynamic Gateway” enables the OLSR Dynamic Gateways Announcing feature. At “Announce Dynamic local route“, enter the IP address and netmask of the dynamic local route. “Ping” allows you to specify a host to ping to ensure connectivity, and “Poll” specifies how long to look for an internet gateway in seconds. Finally, “Enable Secure mode” allows you to enable the secure mode, and “Key” holds the secure OLSR key information.

External Links:

The official OLSR site – see also the site’s explanation of dynamic gateways

Optimized Link State Routing Protocol at Wikipedia

pfSense OLSR Daemon at doc.pfsense.org (not very much here; putting a link in case someone adds to the entry)

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

© 2013 David Zientara. All rights reserved. Privacy Policy