Snort Installation in pfSense: Part Two

snort installationIn part one of this series, we began our look at snort installation. In this article, we continue the process.

Next, add a directory to /usr/local/lib:

cd /usr/local/lib
mkdir snort_dynamicrules

Add the following line to file /etc/passwd (or use the “useradd” or “adduser” command):


Issue the commands below in order to take ownership of all files in /etc/snort:

cd /etc/snort
chown -R snort:snort *

Locate and modify the following variables in your snort.conf file (in directory /etc/snort) as follows (found between lines 40 and 120 in snort.conf):

This assumes the network you are going to monitor is

var RULE_PATH /etc/snort/rules
ipvar HOME_NET
var SO_RULE_PATH /etc/snort/so_rules
var PREPROC_RULE_PATH /etc/snort/preproc_rules
var WHITE_LIST_PATH /etc/snort/rules
var BLACK_LIST_PATH /etc/snort/rules

You will also need an initialization script. You can find one for FreeBSD 8.x at the official snort website. Place this script into the /etc/rc.d directory on your pfSense box.

You also want to make a symbolic link (symlink) in /usr/sbin to point to where the actual snort binary was compiled. You could also copy the snort binary to /usr/sbin as well. To make the symlink, issue these commands:

cd /usr/sbin
ln -s /usr/local/bin/snort snort
chmod 700 snort

If the directory “/var/log/snort” does not exist on your system, issue the following commands as “root”:

cd /var/log
mkdir snort
chmod 700 snort
chown -R snort:snort snort

The commands below will also change the ownership of the directories and files to user “snort” and group “snort:

cd /usr/local/lib
chown -R snort:snort snort*
chown -R snort:snort snort_dynamic*
chown -R snort:snort pkgconfig
chown -R 700 snort*
chown -R 700 pkgconfig
cd /etc
chown -r snort:snort snort
chmod -R 700 snort

Testing Your Snort Installation

At this point, you should be ready to do some testing of snort to see if it actually starts up and reads in the rules. You can check /var/log/messages to catch any fatal errors or crashes.

If you want to test snort startup, issue the following commands:

cd /usr/local/bin
./snort -T -i em0 -u snort -g snort -c /etc/snort/snort.conf

The above command will cause snort to start up in self-test mode, checking all the supplied command line switches and rules files that are passed to it and indicating that everything is ready to proceed. If all the tests are passed, you should see the following:

Snort successfully validated the configuration!
Snort exiting

If no errors are returned, you can proceed. To manually start snort, issue the following commands:

cd /usr/local/bin
 ./snort -i em0 -D -u snort -g snort -c /etc/snort/snort.conf

Make sure that snort initializes properly before proceeding below, you can check /var/log/messages for more information in the event of an error in initialization.

To see if snort is actually running on the system, you can check which processes are running, like so:

ps aux | grep -i “snort”

If snort is working, it should return output that indicates snort is a running process, like so:

19633 ?? Ss 0:00:04 /usr/local/bin/snort -D -i em0 -u snort -g snort -c /etc/snort/snort/conf -l /var/log/snort/

External Links:

The official snort website


Snort Installation in pfSense: Part One

snort installationIf you are running pfSense and are looking for an additional means of securing your network, you may consider installing snort on your pfSense system. Snort installation will be the subject of this next series of articles. Snort is an open source network intrusion prevention system (NIDS), capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching and matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort has three primary uses. It can be used as a straight packet sniffer like tcpdump, a packet logger, or as a full-blown network intrusion prevention system. In sniffer mode, the program will read network packets and display them on the console. In sniffer mode, the porgram will read network packets and display them on the console. In packet logger mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified.

Snort Installation Under FreeBSD 8.x

Snort installation on a  pfSense box begins with  SSHing into the system to access the shell prompt. If you have a recent version of pfSense (2.0 or newer), it should be running under FreeBSD 8.1 or newer. You will need to install the following package via pkg_add: gcc version 4.2.x (including libraries), zlib (1.2.3), libpcap (1.0.0 including libpcap-devel), pcre (8.32), bison (2.7), m4 (1.4.16), flex (2.5.4 including flex-devel), libdnet (1.11 including libdnet-devel), and tcpdump (4.0.0). Versions of these package can be newer than what is listed here. Then download the source code for snort at the official snort website. Download the archive to /usr/local/src. Type the following commands to unpack snort:

cd /usr/local/src
tar -zxvfsnort-

Once you have unpacked snort, do the following to compile snort:

cd /usr/local/src/snort-
./configure -enable-sourcefire
make install

Note any errors which may cause the “configure” step to abort and also check the file “config.log” which is generated from the “configure” line above.

In order to download snort rules from, you must be a registered user or have a paid subscription to download rules sets or VRT rules. Registered users will be able to download rule sets which are approximately one month behind what is available to paid subscription holders.

Continue snort installation by issuing the commands below to copy the configuration files to /etc/snort:

cd /etc
mkdir -p snort
cd snort
cp /usr/local/src/snort-*.
tar -zvxf snortrules-snapshot-.tar.gz
touch /etc/snort/rules/white_list.rules /etc/snort/rules/black_list.rules

This will place the configuration files from the snort unpack and the rules snapshot under the /etc/snort directory. If the rules snapshot file is newer, this is not an issue (since rules are updated on a periodic basis by the snort team). Also, the configuration files are residing in /etc/snort and the rules files will be in /etc/snort/rules and the so_and preprocessor rules will be located in /etc/snort.

In the next article, we will continue our look at snort installation under pfSense.

External Links:

The official snort web site

Ad Links:

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:

Wireless Access Point Configuration in pfSense

wireless access pointWith a wireless card that supports hostap mode, pfSense can be configured as a wireless access point. The following cards support hostap mode:

  • ath(4): Supports cards based on the Atheros AR5210, AR5211 and AR5212 chipsets.
  • ral(4): Ralink Technology wireless network driver – supports cards based on the Ralink RT2500, RT2501 and RT2600 chipsets.
  • wi(4): Supports cards based on Lucent Hermes, Intersil PRISM-II, Intersil PRISM-2.5, Intersil Prism-3, and Symblo Spectrum24 chipsets. These cards support only 802.11b.

In the past, the access point functionality in FreeBSD has suffered from serious compatibility problems with some wireless clients. With FreeBSD 7.0 and newer, this has improved significantly; however there may still be some incompatible devices. These difficulties with client compatibility are not necessarily just a FreeBSD issue. Nevertheless, you may find that a cheap consumer-grade wireless router running in access point mode may provide better compatibility than FreeBSD’s access point capabilities. There is the possibility of finding incompatible devices with any wireless access point, and FreeBSD is no exception. With every passing release of FreeBSD, wireless compatibility improves; however, it’s probably a good idea to check the ap compatibility list at

As long as your wireless cards are compatible, configuring pfSense to act as a wireless access point is fairly easy. Many of the options should be familiar if you have configured other wireless routers before, and some options may be new unless you have used some commercial-grade wireless equipment. There are many different ways to configure access points. In this article, we will cover setting up pfSense as a basic wireless access point (AP) that uses WPA2 encryption.

Configuring pfSense as a Wireless Access Point

First, ensure that the wireless card is in the router, and the antenna is firmly attached. The wireless card must be assigned as an OPT interface and enabled before the remaining configuration can be completed. You need to navigate to Interfaces -> OPTn to begin configuration. Naming the access point “WLAN” (Wireless LAN) or “Wireless” will make it easy to identify a wireless interface in the list of interfaces. If you have a unique SSID, it may be a good idea to use that in the description instead. If pfSense will be driving multiple access points, there should be some way to distinguish them.

Next, since this will be a wireless access point on a dedicated IP subnet, you will need to set the “Type” to “Static” and specify an “IP Address”and subnet mask. Since this is a separate subnet from the other interfaces, it can be any subnet that is otherwise unused. For purposes of this example, assume our subnet is 192.168.10.x.

You need to set the “Wireless Standard” setting, and there are several choices, including 802.11b, 802.11g, 802.11g turbo, 802.11a, and possibly others. Here, assume we choose 802.11g. Set the “Mode” field to “Access Point”, and pfSense will use hostapd to act as an AP. Next you need to set the Service Set Identifier (SSID); this will be the name of the AP as seen by clients. This should be something readily identifiable, yet unique to your setup.

Another setting is “802.11 only”. This setting controls whether or not 802.11b clients are able to associate with this access point. Allowing 802.11b clients to use your wireless access point may be necessary in some environments if devices are still around that require it. Some devices such as the Nintendo DS are only compatible with 802.11b and require a mixed network in order to work. The down side of this is that you will see slower speeds as a result of allowing such devices on your network, as the access point will have to cater to the lowest common denominator when an 802.11b device is present.

Next, there is “Allow intra-BSS communication”. If you check this option, wireless clients will be able to see each other directly, instead of routing all traffic through the AP. If clients will only need access to the Internet, it is usually safer to uncheck this.

There is an option to “Disable SSID Broadcasting”. Normally, the AP will broadcast its SSID so that clients can locate and associate with it easily. However, this is considered by many network admins to be a security risk, as you are announcing to all who are listening that you have a wireless network available. In most cases the convenience outweighs the security risk. At the same time, the benefits of disabling SSID broadcasting are overblown, since it does not actually hide the network from anyone capable of using many freely available wireless security tools that easily find such wireless networks.

Next is “Wireless Channel Selection”. When selecting a channel, you want to be aware of any nearby radio transmitters in similar frequency bands. In addition to wireless access points, there are also cordless phones, Bluetooth, baby monitors, video transmitters, microwaves, and many other devices that use the same 2.4 GHz spectrum that can cause interference. The safest channel to use are 1, 6, and 11 since their frequency bands do not overlap each other. You can specify “Auto” to tell the card to pick an appropriate channel, but this does not work with all wireless cards.

Three types of encryption are supported for 802.11 networks: WEP, WPA, and WPA2. WPA2 with AES is considered the most secure. Even if you are not worried about encrypting the over-the-air traffic, it provides an additional means of access control. A WPA/WPA2 passphrase is also easier to work with and remember than a WEB key; it acts more like a password than a really long string of hexadecimal characters. Some older devices only support WEP or WPA, but most modern wireless cards and drivers will support WPA2. To enable WPA2, you need to uncheck “Enable WEP” and check “Enable WPA”, and set the “WPA Mode” to WPA2. To use WPA2+AES, set “WPA Pairwise” to AES.

This should be enough to get a wireless access point running with 802.11g with WPA2 + AES encryption. There are other settings you can use to tweak the AP’s behavior, but under most circumstances they are not necessary. Press the “Save” button to save the settings and on the next page press the “Apply Changes” button. Now your wireless access point should be up and running.

External Links:

One pfSense wireless config to rule them all at

Ad Links:

Wireless Access with an Existing Router in pfSense

wireless accessIf you have an existing wireless access point or a wireless router that you only want to use as an access point now that you have a pfSense router, there are several ways to incorporate wireless access into your network. We will discuss some of them in this article.

Wireless Access: Turning the Old Router into a WAP

When you replace a simple consumer-grade wireless router, the wireless functionality can be retained by turning the wireless router into a wireless access point (WAP) by following the steps described here. First, you will want to disable the DHCP server if it was previously in use. You will want pfSense to act as the DHCP server, and having two DHCP serviers on your network will cause problems.

Next, you will need to change the LAN IP to an unused IP on the subnet where your access point will reside (commonly the LAN interface). It is probably using the same IP address you will assign to the pfSense LAN interface, so it will require a different address. You will want to retain a functional IP address on the access point for management purposes.

Most wireless routers bridge the wireless onto the internal LAN port(s), which means the wireless will be on the same broadcast domain and IP subnet as the wired ports. For routers with an integrated switch, any of the switch ports will do. You do not, however, want to plug in the WAN or Internet port on your router. This will put your wireless network on a different broadcast domain from the rest of your network, and will result in NATing traffic between your wireless and LAN and double NATing traffic between your wireless and the Internet. This will lead to problems in some circumstances, especially if you need to communicate between your wireless clients and your wired LAN. Where you chose to plug in the LAN interface will depend on your chosen network design.

One means of deploying wireless is to plug the access point directly into the same switch as your LAN hosts, where the AP bridges the wireless clients onto the wired netwrk. This will work, but it offers limited control over the ability of your wireless clients to communicate with your internal systems. But if you want more control over your wireless clients, then adding an OPT interface to pfSense for your access point is the preferred solution. If you want to keep your wireless and wired networks on the same IP subnet and broadcast domain, you can bridge the OPT interface to your LAN interface. This scenario is essentially the same as plugging your access point directly into you LAN switch, except that since pfSense is in the middle, it can filter traffic from your wireless network to provide protection to systems connected to your LAN.

You can also put your wireless network on a dedicated IP subnet if you want, by not bridging the OPT interface on pfSense and assigning it with an IP subnet outside of your LAN subnet; this will enable routing between your internal and wireless networks, as permitted by your firewall rule set. This is done often on larger networks where multiple access points are plugged into a switch than in turn are plugged into the OPT interface on pfSense. It is also preferable when wireless clients must connect to a VPN first.

External Links:

pfSense: Associate with a Wireless Access Point at Addicted to IT

Ad Links:

Wireless Configuration in pfSense

wireless configurationIn the previous article, I covered checking to make sure your wireless card is compatible with FreeBSD (and pfSense). In this article, I will cover wireless configuration. You can assign your wireless card as your WAN interface, or as an OPT WAN in a multi-WAN deployment.

Wireless Configuration

In this article, let’s assume our wireless configuration scenario is setting up the wireless card as the WAN interface. The first step is to navigate to Interfaces -> (assign) and assign the wireless interface to the WAN (or whatever interface to which you want to assign the wireless interface). Click “Add” to add an OPT interface if you want an OPT interface to be your wireless interface. Otherwise, make sure your WAN interface is the wireless one. For example, if you have an Atheros card named ath0, set ath0 with the drop down box as the WAN interface.

Next, browse to Status -> Interfaces for the WAN interface. At “IPv4 Configuration Type“, select the type of configuration (e.g. DHCP, static IP, etc.), and scroll down to the “Wireless configuration section“. Choose Infrastructure (BSS) mode, fill in the SSID, and configure encryption, such as WEP (Wired Equivalent Privacy) or WPA (Wi-Fi Protected Access). Most wireless networks will not need any further configuration, but if your network does, make sure it is configured appropriately for the access point you will be using. Then click on the “Save” button to save the settings. Wireless configuration is now complete.

If you want to check the status of the wireless interface just configured, navigate to Status -> Interfaces. There you can tell whether the interface has successfully associated with the choses access point by looking at the status of the interface. “Status associated” means it is connected successfully. If it shows “No carrier“, however, it was unable to associate. Finally, by navigating to Status -> Wireless, you can see the wireless networks visible in your firewall. Your wireless interface(s) must be configured before this menu item will appear.

Bridging a Wireless Interface

You can bridge a wireless interface, but only wireless interfaces in access point (hostap) mode will function in a bridged configuration. You can bridge a wireless interface in hostap to any other interface to combine the two interfaces on the same broadcast domain. You may want to do this if you have devices or applications that must reside on the same broadcast domain.

Finally, because of the way wireless works in Basic Service Set (BSS) and Independent Basic Service Set (IBSS) modes, you cannot bridge a wireless interface in BSS or IBBS mode, because every device connected to a wireless card in those modes must present the same MAC address. With bridging, the MAC address passed is the actual MAC of the connected device, and in wireless, the only way this can function is if all the devices behind that wireless card present the same MAC address on the wireless network.

External Links:

Wireless Interfaces at

Mailing list posting explaining why you cannot bridge a network interface in BSS or IBBS mode.

Ad Links:

Wireless Support in pfSense

wirelessFirst, I should mention that this is the 100th post on this blog, which if nothing else, shows an unusual (for me) level of persistance on my part. Thanks to all who have visited this blog, visited this site’s Facebook page, or subscribed to this blog’s Twitter feed. I have a number of ideas on how to improve this blog, and I hope to implement some of them in the near future. Now, onto the topic of today’s posting: wireless support in pfSense.

pfSense includes built-in wireless capabilities that allow you to either turn your pfSense box into a wireless access point, use a wireless 802.11 connection as a WAN connection, or both. You can also use another wireless router in conjunction with pfSense. But if you want to use the built-in wireless capabilties, you first need one or more wireless cards supported by pfSense.

FreeBSD has supported wireless cards for a number of years, and there are a variety of wireless cards supported in FreeBSD 8.3. Needless to say, pfSense includes support for every card supported by FreeBSD, although some are supported better than others. Most pfSense developers work with Atheros hardware, so it tends to be the most recommended hardware. Many users have had success with other cards, however, and Ralink is also a popular choice. Other cards may be supported, but do not support all available features. For example, some Intel cards can be used in infrastructure mode but cannot be run in access point mode due to limitations of the hardware itself.

Another factor to take into account is that major wireless card manufacturers commonly change the chipsets used in their wireless cards without changing the model number. As a result, there is no way to ensure a specific model card from these vendors will be compatible, since you have no way of knowing which minor card revision you will end up with. While one revision of a model may be compatible and work, another card of the same model may be incompatible. For this reason, it may be a good idea to avoid cards from major manufacturers such as Linksys, D-Link and Netgear, although if you already have one, it is worth trying to see if it is compatible.

Supported Wireless Drivers

The following drivers are included in pfSense 1.2.1 and newer kernels:

  • ath(4): Supports cards based on the Atheros AR5210, AR5211 and AR5212 chipsets. The following cards are known to work in pfSense:
    • CB9-GP-EXT Cardbus/PCMCIA
    • 5004 MP Atheros 4G
    • DCMA-82 Atheros 6G
    • DCMA-82 Industrial Temp
  • rai(4): Ralink Technology IEEE 802.11 wireless network driver – supports cards based on the Ralink Technology RT2500, RT2501 and RT2600 chipsets. There are too many cards supported to list, but the FreeBSD man page for ral has a list of supported cards.
  • wi(4): Lucent Hermes, Intersil PRISM and Spectrum24’s IEEE702.11 driver supports cards based on the Lucent Hermes, Intersil PRISM-II, Intersil PRISM-2.5, Intersil, Prism-3, and Symbol Spectrum24 chipsets. These cards support only 802.11b, and a list of cards supported can be found at the FreeBSD man mage for wi.
  • an(4): Aironet Communications 4500/4800 wireless network adapter driver supports Aironet Communications wireless network adapters and variants, such as:
    • Aironet Communications 4500 and 4800 series
    • Cisco Aironet 340 and 350 series
    • Xircom Wireless Ethernet Adapter
  • awi(4): AMD PCnetMobile IEEE 802.11 PCMCIA wireless network drive – supports cards based on the AMD 70c930 controller with Intersil PRISM radio chipset, such as:
    • BayStack 650
    • BayStack 660
    • Icom SL-200
    • Melco WLI-PCM
    • NEL SSMagic
    • Netwave AirSurfer Plus
    • Netwave AirSurfer Pro
    • Nokia C020 WLAN
    • Farallon SkyLINE

With the release of pfSense 2.0, even more wireless cards were supported. Again, the list is too large to include here, but there is a spreadsheet of compatible wireless cards that should work with 2.0. Be aware of the “hostap” column, which shows drivers capable of running in wireless access point mode. If that column is marked “N”, then the card could only be used as a client. The second tab on the sheet lists part numbers for a given driver.

In the next article in this series, I will cover how to configure your wireless card.

External Links:

Supported Wireless Cards at

Ad Links:

Deep Packet Inspection Using Layer 7 Traffic Shaping

Deep packet inspection

The Layer 7 tab in the Traffic Shaper in pfSense 2.1.

For quite a while, traffic shaping has been considered an integral part of any good firewall. This necessitates some means of classifying the traffic so the traffic can then be policed. The traditional method of traffic shaping centered on classifying traffic based on network and transport data fields, not using deep packet inspection. This usually centered around the following elements:

  • Service class marks
  • Source and/or destination IP addresses
  • Ports

However, these methods are not always effective in traffic classification. This is especially the case with P2P traffic, which often uses random, non-default ports. An HTTP server utilizing port hopping and encrypted traffic may also defy level 3 (network) and level 4 (transport) classification.

Enter Layer 7 Deep Packet Inspection

One possible solution to the shortcomings of network and transport level classification is layer 7 (L7) classification, which involves deep packet inspection. In L7 classification, user traffic can be identified based on an application pattern, which is a sort of signature used by an application during its communications. All applications either use a specific application pattern or may share the pattern with other applications.

Deep packet inspection

Configuring P2P options in the wizard.

IPCop is a good example of utilizing L7 deep packet inspection and classification. IPCop is a Linux-based firewall that was originally a fork of the SmoothWall firewall. Although not an official part of IPCop, an advanced QoS (Quality of Service) add-on is available. But while IPCop can support classification by application protocol, it does not allow the definition of shaping policies. Rather, it can only block such traffic, which greatly limits the use of this feature.

pfSense, however, has fully incorporated L7 deep packet inspection and classification into its traffic shaper. Traffic shaping is achieved in pfSense through AltQ, which makes available Class Based Queueing (CBQ), Priority Queueing (PRIQ) and Hierarchical Fair Service Curve (HFSC). All of these can be configured automatically through the use of a wizard. Beginning with pfSense 2.0, an additional shaping mechanism called Dummynet became available. Dummynet was originally designed for the ipfw firewall, and has a related application called ipfw-classifyd. This application is able to produce blocking rules for incoming traffic or perform traffic shaping by assigning IP packets to an AltQ queue or a Dummynet pipe or queue. It was modified to work with the pf firewall and is the component responsible for L7 classification. It also allows different types of operations to be applied to an identified application protocol, usually either blocking it or assigning it to a limiter or queue.

In order to invoke ipfw-classifyd, pf uses divert sockets. Essentially, it interrupts the normal flow of packets and sends them to a listening socket (ipfw-classifyd). Overhead is kept to a minimum by teaching pf about the actions to be taken ahead of time and by limitng the number of packets that are diverted from the kernel to the application. All of this is controlled via a graphical interface, in which the user must specify at least one protocol (but may specify more than one). The user can create L7 rules groups containing one or more L7 rules. The user can take any one of the created rules groups and assign it a firewall rule.

But with pfSense, the user does not have to explicitly create L7 rules groups. This is because the Traffic Shaper Wizard in versions 2.0 and newer invokes L7 classification in the Peer-to-Peer and Network Games sections. In both sections, the select box on the top of the page can be enabled, and the related protocols or applications can be blocked one by one. Finally, the user can extend the functionality of L7 packet inspection by uploading new application patterns to the system. This feature is important when the user wants to block an application that uses a protocol pattern that is not defined in the system. If such a pattern is uploaded to the system, it only appears in the list of protocols when a container is created or modified. It does not affect the Traffic Shaper Wizard, which remains unchanged.

Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
Traffic Shaping Wizard: Introduction
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Rules Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter

External Links:

L7 Classification and Policing in the pfSense Platform – a scholarly paper about the addition of layer 7 deep packet inspection to pfSense 2.0.

Ad Links:

Bandwidth Limiting with the pfSense Limiter


Creating a limiter in pfSense 2.1

Although we have covered a number of powerful features that are part of pfSense’s traffic shaping capabilities, we haven’t yet covered one of the most interesting and useful features: the ability to limit users’ upload and download speed. In this article, I will describe how to use the pfSense bandwidth limiter.

Using the Bandwidth Limiter

To invoke the bandwidth limiter, first navigate to Firewall -> Traffic Shaper, and click on the “Limiter” tab. At this tab, click on “plus” to add a new limiter. Check the “Enable limiter and its children” checkbox, and for the “Name” field, enter a name for the new limiter. At “Bandwidth“, click on the “plus” button to add a bandwidth limit. There are four options: “Bandwidth“, “Burst“, “Bw type” and “Schedule“. “Bandwidth” is the maximum transfer rate, while “Burst” is the total amount of data that will be transferred at full speed after an idle period and is apparently a new setting under pfSense 2.1. “Bw type” allows you to select between Kbit/s, Mbit/s, Gbit/s, and bit/s. “Schedule” does not seem to have any options.

In the next nection, “Mask“, you can select “Source address” or “Destination address” in the drop down box. If either one is chosen, a dynamic pipe with the bandwidth, delay, packet loss and queue size specified in the “Bandwidth” section will be created for each source or destination IP address encountered respectively. This makes it possible to easily specify bandwidth limits per host. In the next two fields, you can specify the IPv4 and IPv6 mask bits. At “Description“, you can enter a description, which will not be parsed.

Underneath “Description” is the “Show advanced options” button. Pressing this button reveals some additional settings. “Delay” allows you to specify a delay before packets are delivered to their destination (leaving it blank or entering 0 means there is no delay). “Packet loss rate” allows you to specify the rate at which packets are dropped (e.g. 0.001 means 1 packet per 1000 gets dropped). Again, you can leave this blank. “Queue size” allows you to specify a number of slots for the queue, and “Bucket size” allows you to set the hash size. Finally, press the “Save” button to save the limiter or “Delete virtual interface” to delete it. Press “Apply changes” on the next page to apply the changes.


Creating a firewall rule to limit upload bandwidth. Note that we are using the limiter created in the previous step.

Now, the limiter that we just created should be available when we go to make or edit firewall rules. As an example, we can use the limiter created in the previous step to limit the upload bandwidth to 1 GB. Navigate to Firewall -> Rules, and click on the “LAN” tab. Press the “plus” button to add a new rule. Leave the “Action” as Pass, the “Interface” as LAN, and the “TCP/IP Version” as IPv4. The “Source” should be set to “LAN subnet”, and the “Destination” should be left as Type: any. After entering a “Description“, scroll down to advanced features and press the “Advanced” button next to “In/Out“, and set the “In” queue to the limiter created in the previous step. Then press “Save” to save the rule and “Apply changes” on the next page.

Now, the upload bandwidth on the LAN interface should be limited to 1 Gb/sec. When you navigate to Firewall -> Rules and click on the “LAN” tab, you should see a small purple circle next to the newly-created rule, indicating that the rule invokes the limiter. If you wanted to limited the download bandwidth, this could easily be done; just create another limiter specifying the maximum download bandwidth, and set the “Out” queue in the rule to the new limiter (or if you just want to make the upload and download bandwidth the same, use the original limiter).

Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
Traffic Shaping Wizard: Introduction
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Rules Groups in pfSense 2.1
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

PFSense 2.0 – Limiting users Upload and Download Speeds by Limiting Bandwidth at

pfSense 2.0 – Limit Download & Upload bandwidth per IP at YouTube

Ad Links:

Layer 7 Rules Groups in pfSense 2.1

Layer 7

Adding a layer 7 rules group in pfSense 2.1.

In the previous article, I described how to create a traffic shaping rule to place BitTorrent traffic into the P2P queue. Another way of directing traffic into queues is to create a layer 7 rules group. In this article, I will describe how to do this.

Traditionally, network traffic is identified by looking at IP packet fields or by referring to which port is being used. In the OSI network model, this method is limited to looking at layers 3 and 4. This is highly constricting, but fortunately there is a better way. We can inspect packets at the application layer (also known as deep packet inspection), which provides us with a powerful solution for controlling traffic based on application patterns. Since this functionality is built into pfSense 2.0 and later, we can easily create rules for layer 7 inspection.

Creating an Layer 7 Rules Group

As an illustration, I will again turn to the example of limiting bandwidth used by BitTorrent traffic by placing it in the P2P queue. First, navigate to Firewall -> Traffic Shaper, and click on the Layer 7 tab. Once there, click on the “plus” button to add a new Layer 7 rule. At “Enable/Disable“, check the checkbox to enable this layer 7 container. At “Name“, you can enter a name, and at “Description“, you can enter a description that will not be parsed. At “Rule(s)“, press the “plus” button to add one or more rules. There are three dropdown boxes: “Protocol“, “Structure“, and “Behaviour“. For “Protocol“, you can select any one of dozens of protocols; I won’t list all of them here, but some of the more significant ones are:

  • DHCP: Dynamic Host Configuration Protocol, an application level netwprk protocol used to configure devices that are connected to a network so they can communicate on that network using the Internet Protocol (IP).
  • Finger: The Finger user information protocol, which provides basic user information on some systems.
  • HTTP: Hypertext Transfer Protocol, the main application protocol for the World Wide Web.
  • UUCP: Unix-to-Unix Copy, a suite of computer programs and protocols allowing remote execution of commands and transfer of files, email, and netnews between computers.

In our case, we’ll choose “bittorrent” as the protocol. Under “Structure“, we can choose either “action” or “queue”. “action” seems to have one option under “Behaviour“: “block”. Since we don’t want to block bittorrent traffic, but instead want to put it in the P2P queue, we select “queue”. For “Behavior“, we select “qP2P” (the P2P queue). We could add another rule, but instead we will press the “Save” button to save the rules group, and “Apply changes” on the next page.

This covers how to add an layer 7 rules group. But there is an alternative way of adding a layer 7 rules group: when you first click on the “Layer 7” tab, there should be a hyperlink to add new layer 7 protocol patterns. Click on this link, then on the “Add layer7 pattern” page, press the “Choose” button and select a file with the file dialog box. When you are done, press the “Upload Pattern file” button to upload the file.

This article should be enough to get you started with using layer 7 rules groups, but if you want a more in-depth explanation of Layer 7 traffic control and how it was implemented in pfSense, you may want to read this scholarly paper on L7 in the pfSense platform (also linked to in the external links section).

Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
Traffic Shaping Wizard: Introduction
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

L7 Classification and Policing in the pfSense Platform – a more comprehensive explanation of layer 7 rules and their integration into pfSense.

Traffic Shaping Guide at

Ad Links:

© 2013 David Zientara. All rights reserved. Privacy Policy