Wireless Network Security in pfSense

Wireless Network SecurityIn addition to strong encryption from WPA or WPA2 with AES, some users like to employ an additional layer of encryption and authentication before allowing access to network resources. The two most commonly deployed solutions used to ensure wireless network security are captive portal and VPN. These methods may be used whether you use an external access point or use an optional (OPT) interface or an internal wireless card as your access point.

Wireless Network Security: Captive Portal

By enabling captive portal on the interface where your wireless is, you can require authentication before users can access network resources, thus providing an additional layer of wireless network security. In corporate networks, this is often deployed with RADIUS authentication to Microsoft Active Directory so users can use their Active Directory credentials to authenticate while on the wireless network. I covered captive portal configuration in two separate installments: part one and part two.

Wireless Network Security: VPN

Wireless Network Security

Firewall rules for IPsec VPN. “WLAN net” is the network of the wireless interface, and “Wireless IP” is the IP address of the wireless interface. The rules are slightly different for OpenVPN and PPTP.

Adding captive portal provides another layer of authentication, but it does not offer any additional protection from eavesdropping of your wireless traffic. Requiring VPN before allowing access to the internal network and Internet adds yet another layer of authentication as well as an additional layer of encryption for your wireless traffic, and thus improving wireless network security. The configuration for your chosen type of VPN will be no different from a remote access configuration, but you will also need to configure the firewall rules on the pfSense interface to allow only VPN traffic from your wireless clients.

If you choose to allow only IPsec VPN traffic, you need to set up three rules on you wireless interface. Navigate to Rules -> Firewall, and click on the tab for the wireless interface. Press “plus” to add a new rule. For “Protocol”, select ICMP. For “Source”, select the wireless network; for “Destination”, select the wireless interface IP address. Enter a “Description” and leave the other settings unchanged. Press “Save” to save this rule. Press “plus” to create another rule, and keep the wireless network as the source and the wireless interface IP as the destination. Change the “Prototype” to UDP, and set the destination “Port” to 500. Add a description and press “Save” to save the rule. Press “plus” to create a third rule, and again keep the source as the wireless network and the destination as the wireless interface. Do not set a port and set the prototype to ESP. Then press “Save” to save the rule and on the next page press “Apply changes” to apply the changes.


If you want to use OpenVPN instead, keep the ICMP rule the same, but set the port for the UDP rule to 1194. You do not need a rule to pass ESP traffic. If you want to use PPTP, keep the ICMP rule, add a rule to pass TCP traffic on port 1723, and add another rule to pass GRE traffic on all ports. You do not need a rule to pass UDP or ESP traffic.


External Links:

pfSense OpenVPN Tutorial at YouTube

Secure Your Public WiFi Usage with pfSense IPsec Tunnels at Mostly Secure

Ad Links:

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

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

© 2013 David Zientara. All rights reserved. Privacy Policy