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 Static Routes

pfSense Static Route

Output of “netstat -r” on one of my Linux nodes. Notice the default route (Genmask = 0.0.0.0) sends packets to the gateway (192.168.2.1).

In the previous article, I covered configuring a gateway, and in this article I will build on that by using the gateway in a pfSense static route. Static routing is a method of configuring path selection of routers in computer networks. It is the type of routing that takes place in the absence of communication between routers regarding the current topology of the network. This is accomplished by manually adding routes to the routing table. An entire network could be configured using static rules, but it would not be fault tolerant. When there is a change in the network or there is a failure between two static nodes, traffic will not be rerouted. There are, however, times when static routes can improve the performance of a network. Two such examples are:

  • Stub networks: A stub network is a network or part of an internetwork with no knowledge of other networks that will typically send all of its non-local traffic out via a single path, with the network only aware of a default route to non-local destinations. Examples include an enterprise LAN that connects to the corporate router via one router, or a single LAN which never carries packets between multiple routers.
  • Default routes: A default route is the rule that takes effect when no other route can be determined for an IP address. All packets for destinations not established are sent via the default route. In IPv4, the default route is designated as the zero-address (0.0.0.0); a route that does not match any other route falls back to this route. You can see the routing table under UNIX/Linux by typing “netstat -r” at the command line. You can see the routing table under Windows by typing “route print” at the command line.


While excessive reliance on static routing is generally not a good idea, it often proves useful and therefore it is advantageous to know how to configure a pfSense static route.

pfSense Static Route Configuration

pfSense Static Route

Adding a static route in pfSense 2.0.

In this example, I will use the gateway created in the previous article (DMZ_Gateway). For purposes of this example, assume the topology of the network does not provide a path to the DMZ. There is an FTP server on the DMZ that we want to access. First, navigate to System -> Routing. There are three tabs (“Gateways“, “Routes“, “Groups“); click on the “Routes” tab and click the “plus” button to add a new route. At “Destination“, type in the IP address of the destination network, which in our case is the DMZ network (assume it is 192.168.3.0). At the drop-down box, select the number of bits in the subnet mask (assume it is 24). At “Gateway“, choose the gateway we defined in the previous article, or whichever gateway is appropriate. At “Description“, you can enter a description of the route (e.g. “Static route to the DMZ). Press the “Save” button to save the changes, and at the next screen, press the “Apply changes” button if necessary.


By defining a pfSense static route, we have now hard-coded a path to the DMZ, and we can access it through this static route, and this gateway can now be used by other users of this firewall.

External Links:

pfSense Static Routes at doc.pfsense.org

pfSense Static Route Planner

pfSense Gateways Explained

pfSense Gateways

Adding and configuring a gateway in pfSense 2.0.

pfSense gateways are relatively easy to add and configure, and pfSense also supports gateway groups, which I will briefly discuss in this article (a more detailed explanation, however, will be the subject of a future article). A gateway is a router interface connected to the local network that sends packets out of the local network. It has both a physical and a logical address. Since it is involved in sending packets to other networks, it operates at the network layer of the OSI Model. When packets are sent over a network, the destination IP address is examined. If the destination IP is within the network, the router can use the Address Resolution Protocol (ARP) table to find the MAC address of the target host and send the packets.


If the destination IP is outside of the network, however, then will not be able to find the MAC address of the target host in its ARP table. The packet will go to the gateway for transmission outside of the network. In this case, the frame header will add the gateway’s MAC address (the gateway operates on the data link layer of the OSI model as well). The gateway is on the same network as host devices and must have the same subnet mask as host devices. Each host on the network uses the same gateway.

Adding pfSense Gateways

pfSense Gateways

Now that we have added our gateway, it shows up on the list.

Unless you are configuring a gateway group, pfSense gateways should not take long to set up. To add a gateway, navigate to System -> Routing. Click the “Gateways” tab if it is not already selected and click the “plus” button to add a new gateway. At “Interface“, select a network interface for the new gateway. At “Name“, specify a name for the gateway (no spaces). At “Gateway“, specify the IP address for the gateway (it must be a valid IP address on the interface). Check the “Default Gateway” checkbox to make this the default gateway. The next checkbox is “Disable Gateway Monitoring“; check this if you want to disable monitoring so pfSense will consider this gateway as always being up. At “Monitor IP“, you can assign an an alternative address to be used to monitor the link. It will be used for the quality Round Robin Database (RRD) graphs as well as the load balancer entries. Leave it blank to use the gateway’s IP address by default. At “Description“, add a description if desired. Finally, press “Save” to save the changes and “Apply Changes” to apply the changes if necessary. Now the new gateway should appear on the list of pfSense gateways at the “Gateways” tab.

There are a number of advanced options for pfSense gateways you can view by clicking the “Advanced” button just below the “Alternative monitor IP” edit box. The “Weight” drop-down box allows you to assign a weight for the gateway when used in a gateway group. Gateway groups are just what their name implies. They group together gateways to act in a coordinated fashion. Increasing the weight of the gateway increases the likelihood it will be used. “Latency thresholds” defines the low and high water marks for latency in milliseconds. Once latency exceeds the high water mark, the gateway will go down. The default latency thresholds are 10 ms and 50 ms. “Packet Loss Thresholds” define the low and high water mark for packet loss in percentage. Again, once packet loss exceeds the high water mark, the gateway goes down. The defaults are 1% and 5%. “Frequency Probe” defines in seconds how often an ICMP probe will be sent. The default is 1 second. “Down” defines the number of bad probes before the alarm will be sent. The default is 10.

Now that the OPT1 is configured as the gateway, packets whose destination is outside of the network will be forwarded to OPT1. There, the frame will be stripped off the packets, leaving the IP packets with the IP address of the destination host. The gateway interface will then wrap the IP packets in whatever type of frame the outgoing connection needs, and sends them toward the target host.


External Links:

Settings for pfSense Gateways at doc.pfsense.org

How to set up a pfSense firewall when the default gateway is on a different subnet

pfSense Gateway Grouping

Video: Setting up a DMZ in pfSense 2.0

I made another video today. This one covers configuring optional interfaces; in particular, it shows how to set up a demilitarized zone (DMZ).

pfSense Captive Portal: Part Two (RADIUS Server, etc.)

RADIUS Server

Configuring RADIUS settings in pfSense 2.0.

In part one, I covered configuration of a simple captive portal in pfSense. In this part, I continue explaining some of the more esoteric captive portals settings, including a look at what RADIUS is and configuring RADIUS settings.

At “Pre-authentication redirect URL“, you can set the value of the $PORTAL_REDIRURL$ variable. This variable can be accessed using your custom captive portal index.php page or error pages. At “After authentication Redirection URL“, you can provide a URL that clients will be redirected to instead of the one they initially tried to access after they authenticated.

The next option is the “Disable concurrent logins” check box. If this option is set, only the most recent login per username will be active. Subsequent logins will cause machines previously logged in with the same username to be disconnected. Next is the “Disable MAC filtering” check box; if checked, pfSense will make no attempt to ensure that the MAC address of the client stays the same when they are logged in. The “Enable Pass-through MAC automatic additions” check box will ensure that users of that MAC address will never have to authenticate again if this option is checked. Any authenticated users who access the Internet while this is enabled will have a MAC passthrough entry added. To remove an entry, you either have to log in and remove it manually from the “Pass-through MAC tab” or send a POST from another system to remove it. The “Enable Pass-through MAC automatic addition with username” check box will cause pfSense to save the user name used during authentication. Again, to remove the passthrough MAC entry, you either have to log in and remove it manually from the “Pass-through MAC” tab or send a POST from another system to remove it.


The next check box, “Enable per-use bandwidth restriction“, allows you to restrict each user who logs in to a specified default bandwidth. RADIUS can override the default settings. The default download/upload speeds (in Kbit/s) is specified in the next two edit boxes.

RADIUS Explained

The next section is “Authentication“. Here you have three broad options: “No Authentication“, “Local User Manager/Vouchers” (which was the method user in the configuration example in part one), and “RADIUS Authentication“. Remote Access Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for computers that connect and use a network service. It is often used by ISPs and enterprises to manage access to the Internet or internal networks, wireless networks, and integrated e-mail services. If RADIUS is enabled, the user or machine sends a request to a Remote Access Server (RAS) to gain access to a particular network resource using access credentials. The credentials are passed to the RAS device via the link-layer protocol. In turn, the RAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol. The requests includes access credentials, typically in the form of username and password or security certificate provided by the user. The RADIUS server checks that the information is correct using authentication schemes such as PAP, CHAP, or EAP. The RADIUS server returns one of three responses: Access Reject (the user is unconditionally denied access), Access Challenge (the server requests more information), or Access Accept (the user is granted access). If the user is granted network access, the Network Access Server (NAS) will send a packet to the RADIUS server indicating it should begin accounting, which will continue until the user’s network access is closed.

Specifying a RADIUS Server

pfSense gives us a variety of options for RADIUS configuration. Under “Primary RADIUS server“, you can enter the IP address, port, and shared secret (a shared secret is a piece of data known only to the parties involved used either for authentication or to feed a key derivation function to produce keys to use for encryption and/or MACing of messages). There is an identical series of edit boxes under “Secondary RADIUS server“. Under “Accounting“, click the “send RADIUS accounting packets” check box to send accounting packets to the primary RADIUS server. At “Accounting port“, you can specify a port (leaving it blank causes the default port, 1813, to be used). At “Accounting updates“, there are three options: [1] no accounting updates; [2] stop/start accounting, and [3] interim update.

Check “Enable RADIUS MAC authentication” to make the captive portal try to authenticate users by sending their MAC address in the username and the password entered in the “Shared secret” edit box to the RADIUS server. “RADIUS NAS IP attribute” allows you to choose the IP of the Network Access Server. Checking “Use RADIUS Session Timeout attributes” will cause clients to be disconnected after the amount of time retrieved from the RADIUS Session-Timeout attribute is reached. “Type” can be set to “default” or “cisco“; if it is set to Cisco, the value of Calling Station-ID will be set to the client’s IP address and the Called station-ID to the clients MAC address, instead of to the MAC address and WAN UP address respectively.

At “MAC address format“, you can change the MAC address format used for the whole RADIUS system. The default is to have the 48-bit address in hexadecimal separated by colons into octets. Checking “Enable HTTPS login” will cause the username and password to be transmitted over an HTTPS connection to protect against eavesdroppers. The next few fields, “HTTPS server name“, “HTTPS certificate“, “HTTPS private key“, “HTTPS intermediate certificate” are parameters related to configuring your HTTPS server.

Changing Default Portal/Error/Logout Pages

Portal page contents” allows you to upload an HTML/PHP file for the portal page. You must include a form with a submit button (name=”accept”), a hidden field with name “rediurl” and value=””, and “auth_user”, “auth_pass” and “auth_voucher” if authentication is enabled. “Authentication error page contents” allows you to upload an error page to display when an authentication error occurs. Finally, “Logout page contents” allows you to upload an HTML/PHP file to display when the logout popup is enabled.


External Links:

RADIUS at wikipedia.org

How to Set Up a Radius Server on pfSense Using the FreeRadius Package on hubpages.com

Video: Configuring WAN Settings in pfSense (part two)

Here’s the follow-up to my earlier video on configuring WAN settings in pfSense:

pfSense Captive Portal: Part One

Captive portal forces an HTTP client to see a special web page, usually for authentication purposes, before using the Internet normally. A captive portal turns a web browser into an authentication device. This is done by intercepting all packets, regardless of address or port, until the user opens a browser and tries to access the Internet. At that time, the browser is redirected to a web page which may require authentication and/or payment, or simply display an acceptable use policy and require the user to agree. Setting up a pfSense captive portal is fairly simple, yet pfSense 2.0 provides a number of different options which allow admins a high level of control over their networks.

Configuring a pfSense Captive Portal

pfSense Captive Portal

Captive portal settings page in pfSense 2.0.

In order to configure captive portal in pfSense, first navigate to Services -> Captive Portal. From the “Captive portal” tab click the “Enable captive portal” check box. At “Interfaces“, choose one or more interfaces (for this example, we will select OPT1). At “Idle timeout“, specify a timeout (for this example, we will specify 10 minutes). At “Hard timeout“, specify a timeout (for this example, we will specify 90 minutes).


Next, click the “Enable logout popup window” so users may log themselves out when they are finished. At “Redirection URL“, specify a URL (for this example, we will specify http://pfsensesetup.com). At “Authentication“, select “Local User Manager“. Then press “Save” to save the changes.

pfSense Captive Portal

Adding a user with the pfSense User Manager.

Next, navigate to System -> User Manager. Click on the “Users” tab, and click on the “plus” button to add a new user. At “Username“, enter a user name, and at “Password“, enter a password. At “Full name“, type the full name of the user. Then press the “Save” button to save the changes.

Now, any user from the OPT1 network who attempts to browse the web will first have to authenticate. Once authenticated, they will be directed to pfSense Setup HQ, where they may then surf the web before they encounter a timeout which we defined, at which point they will have to authenticate again.

pfSense Captive Portal: Additional Options

Although the above example will enable us to set up a functioning captive portal, there are some additional settings on the captive portal configuration page that are worth mentioning. “Maximum concurrent connections” allows you to limit the number of concurrent connections to the captive portal. It does not limit how many users can be logged into the captive portal, but rather how many users can load the portal page to authenticate at the same time. The default is no limit (0). Otherwise, the minimum setting is 4 connections per client IP address, with a maximum of 100.

Pass-through credits allowed per MAC address” allows passing through the captive portal without authentication a limited number of times per MAC address. Once this number is used up, the client can only log in with valid credentials until a waiting period specified has expired (this parameter is “Waiting period to restore pass-through credits“). Finally, the “Enable waiting period reset on attempted access” check box resets the waiting period to the original duration if access is attempted when all pass-through credits have already been exhausted.

In part two, I will cover some of the other pfSense captive portal options available in pfSense 2.0.


External Links:

Captive Portal on Wikipedia

Captive Portal on doc.pfsense.org

pfSense VLANs

pfSense VLANs

The interface assignment tab in the pfSense web GUI.

A Virtual LAN (VLAN) is a single layer-2 (data link layer) network that is partitioned to create multiple broadcast domains, which are mutually isolated so that packets can only pass between them via one or more routers. To share VLANs on simple devices such as hubs requires running dedicated cabling for each VLAN. More sophisticated devices such as switches or routers can mark packets through tagging, so that a single interconnect (trunk) may be used to transport data for various VLANs. Tagging is used in setting up pfSense VLANs. A VLAN tag defines a separate virtual network. The pfSense firewall can attach to each VLAN by defining VLAN tags on the firewall interfaces. pfSense VLANs can be configured via software instead of physically relocating devices or switches.


VLANs can also be used to create multiple layer 3 (network layer) networks on the same layer 2 switch. For example, if a DHCP server is plugged into a switch, it will serve any host on that switch that is configured to get its IP from a DHCP server. By using VLANs, you can easily split the network up so some hosts will not use the DHCP server and will obtain a link-local address (an IP address that is intended only for communications within the segment of a local network or a point-to-point connection that a host is connected to) or obtain an address from a different DHCP server. Another early use of VLANs was to solve a problem in which centrally located switches became bottlenecks. The solution was to set up several virtual networks within the same physical network, each with its own spanning tree: a red spanning tree, a green spanning tree, and a blue spanning tree. By sending a mix of different packet colors, aggregate bandwidth could be improved.

pfSense VLANs: Configuration

pfSense VLANs

VLAN settings page in pfSense.

To set up a VLAN in pfSense, start by navigating to Interfaces -> (assign). There are several tabs on this page; click on the “VLANs” tab, and then click on the “plus” button to add a new virtual LAN. At “Parent Interface“, select a parent interface. The interface assignment page shows the interface names, and we can use this as a reference. In this case, we want to use OPT1 for the virtual LAN and it is assigned to interface vr0. We will select that.


The next option is “VLAN tag“. Select any integer from 1 to 4094. At “Description“, enter a description, such as “OPT1 virtual LAN”. Next, click on the “Save” button to save the changes.

Now, every packet destined for, or originating from the VLAN will be marked with the VLAN tag, which is how pfSense differentiates the packets from other network traffic.

External Links:

VLANs at Wikipedia

VLAN Trunking on doc.pfsense.org

pfSense Bridges

pfSense Bridges

The bridge settings page in pfSense.

Bridging allows you to join two networks together. Bridging is distinct from routing which allows the networks to communicate independently as separate networks. Unlike routing, which takes place at the network layer of the OSI model, bridging takes place at the data link layer. Like a repeater, a bridge passes frames from one network segment to another. Unlike a repeater, a bridge monitors and records network traffic, eventually reaching the point where it can filter and forward traffic. This makes a bridge more intelligent than a repeater. In most cases, setting up pfSense bridges is relatively easy, but there are many options, which will be covered in this article.

pfSense Bridges: Basic Options

To bridge interfaces, first navigate to Interfaces -> (assign). Then click the “Bridges” tab and click the plus button. At “Member Interfaces“, select two interfaces by clicking on each interface while holding down the CTRL key. At “Description“, enter a description if desired. Then press the “Save” button to save the changes.

pfSense Bridges: Advanced Options

Setting up a bridge can be that easy. However, by clicking on “Show advanced options“, you can also configure other parameters. At “RTSP/STP“, there are several options relevant to setting up a spanning tree. The first is “Enable spanning tree options for this bridge“. A spanning tree, by definition, is a graph with no loops. A physical topology that contains switching or bridge loops is attractive for redundancy, yet a switched loop must not have loops. Loops will create broadcast radiation as broadcasts and multicasts are forwarded by switches out of every port. The switch or switches will repeatedly rebroadcast the broadcast messages, flooding the network. Since the Layer 2 (data link layer) header does not support a time to live (TTL) value, if a frame is sent into a looped topology, it can loop forever. The solution is to allow physical loops, but create a loop-free logical topology using the spanning tree protocol on the network switches.

pfSense Bridges

Advanced options for bridging in pfSense 2.0.

If you want to implement a spanning tree on your bridge, you must choose a protocol, which you can do with the “Protocol” option. There are two choices: Spanning Tree Protocol (STP), and Rapid Spanning Tree Protocol (RSTP). Spanning Tree Protocol is a network protocol that ensures a loop-free topology for any bridged Ethernet local area network. The operation of STP entails the following: [1] selecting a root bridge (the bridge with the lowest bridge ID); [2] determining the least cost paths to the root bridge, and [3] disabling all other root paths. This should leave us with a minimum spanning tree. Obviously if the network topology changes either because new bridges are added or because old ones go offline, then the spanning tree will have to be re-created, and STP is able to do this automatically, although it is somewhat slow in this respect. STP is standardized as 802.1D.

In 2001, the IEEE introduced Rapid Spanning Tree Protocol (RSTP) as 802.1w. RSTP provides significantly faster spanning tree convergence after a topology change, including new convergence behaviors and bridge port rules to do this, and it was designed to be backwards-compatible with standard STP. While STP can take 30 to 50 seconds to respond to a topology change, RSTP is typically able to respond to changes much faster, sometimes within a few milliseconds of a physical link failure. It can typically respond to changes within 3 times the Hello time. The Hello time is a configurable time interval that RSTP uses for several purposes and is configurable; the default value is 2 seconds.

At “STP interfaces“, you can select which interfaces on which STP/RSTP is enabled. At “Valid time“, you can set the time that a STP configuration is valid. The default is 20 seconds. The minimum is 6 seconds, and the maximum is 40 seconds. At “Forward Time” you can set the time that must pass before an interface begins forwarding packets when STP/RSTP in enabled. The default is 15 seconds; the minimum is 4 seconds and the maximum is 30 seconds.

At “Hello time” (mentioned briefly in the description of RSTP), you can set the time between broadcasting of Spanning Tree Protocol configuration messages. The hello time may only be changed when operating in legacy STP mode. The default is 2 seconds; the minimum is 1 second and the maximum is 2 seconds.


At “Priority“, you can set the bridge priority for the Spanning Tree. The default is 32768, but you can set it anywhere from 0 to 61440. The “Hold Count” allows you to set the transmit hold count for the Spanning Tree; this is the number of packets transmitted before being rate-limited. The default is 6 but you can set it to anything from 1 to 10.

Next is a second “Priority” setting, one which allows you to set priorities for individual interfaces. The default is 128 but it can be set anywhere from 0 to 240. Finally, at “Path cost” you can set the Spanning Tree path cost of each interface. The path costs are used to generate the spanning tree. If nothing is entered here, the algorithm will by default calculate path cost based on the link speed. Set the cost to 0 to set it back to the default. The minimum is 1 and the maximum is 2000000000.

The next two settings are “Cache Size” and “Cache entry expire time“. “Cache Size” sets the size of the bridge address cache (the default is 100 entries). “Cache entry expire time” sets the timeout of address cache entries (the default is 240 seconds).

Next is “Span port“. Setting an interface as a span port (also referred to as “port mirroring”) causes that interface to transpit a copy of every frame received by the bridge. This is most useful for snooping a bridged network passively on another host connected to one of the span ports of the bridge. This is commonly used for network appliances that require monitoring of network traffic, such as an intrusion detection system, passive probe or real user monitoring (RUM) that is used to support application performance management (APM). The span interface cannot be part of the bridge member interfaces.

The next two settings are “Edge ports” and “Auto edge ports“. “Edge ports” allows you to set a port that is only connected to one bridge as an edge port so it will automatically transition to the forwarding state. RSTP still continues to monitor the port in case a bridge is connected. “Auto edge ports” allows an interface to automatically detect edge status. This is the default for all interfaces added to a bridge.

The next two settings are “PTP ports” and “Auto PTP ports“. “PTP ports” allows you to set the interface as a point-to-point link. This is required for straight transitions to forwarding and should be enabled on a direct link to another RSTP-capable switch. “Auto PTP ports” automatically detect the point-to-point status on an interface by checking the full duplex link status. This is the default for interfaces added to the bridge. The interfaces selected here will be removed from default autoedge status.


Sticky ports" and "Private ports". "Sticky" ports enables you to mark an interface as "sticky" it is never aged out of the cache or replaced, even if the address is seen on a different interface. "Private ports" enables you to mark an interface as private, so that it does not forward any traffic to any other port that is also a private interface.

If your network topology is simple, then it is probably enough to set up a simple network bridge. In other cases, however, it may behoove you to set up a spanning tree using STP or RST when setting up your pfSense bridges.

External Links:

Spanning Tree Protocol on Wikipedia

Interface Bridges at doc.pfsense.org

First video: pfSense WAN Settings (part one)

I recently made a video showing how to configure WAN settings in pfSense 2.0. While this admittedly isn’t very polished, it is my first attempt at making a video tutorial and I would love to your feedback.

© 2013 David Zientara. All rights reserved. Privacy Policy