Traffic Shaping in pfSense: Part Seven

Editing traffic shaping settings in pfSense.

Editing traffic shaping settings in pfSense.

After using the shaper wizard, you might find that the rules it generates do not fit your requirements. Fortunately, once the basic rules have been created by the wizard, it should be relatively easy to edit or copy those rules and create custom ones of your own.
The queues are where bandwidth and priorities are actually allocated. Each queue is assigned a priority from 0 to 7. When there is an overload of traffic, the higher-numbered queues are preferred over the lower-numbered queues. Each queue is assigned either a hard bandwidth limit, or a percantage of the total link speed. The queues can also be assigned other attributes that control how they behave. For example, they can be set up so they have low latency or they might have certain congestion avoidance algorithms applied. Queues may be changed by navigating to Firewall -> Traffic Shaper and clicking on the By Queues tab. A list of rules will apeear.

Editing queues can be a complex tast with powerful results. Still, without a thorough understanding of the settings involved, it is probably best to stick with the queues generated by the wizard and alter their settings.

The queue listings have changed somewhat in pfSense 2.2. Each queue is listed on the left side of the tab. Clicking on one of the queues will bring up a listing for each of that queues subordinate queues (one for each interface). Clicking on any of these subordinate queues will allow you to edit the settings for it. The screen capture at the top of this article shows the settings for one such queue. At the top of the page, there’s a check box which allows you to enable/disable the queue and its children. There are settings for the queue name, the queue priority (0-7), the queue limit in packets, and various scheduler options. There is also a field in which you can enter an optional description. At the bottom of the page, there are two buttons: a “Save“ button to save the queue and a “Delete this queue“ button to delete it. You should not attempt to delete a queue if it is being referenced by a rule.

External Links:

PF: Packet Queueing and Prioritization at openbsd.org

Traffic Shaping in pfSense: Part Two

Traffic shaping in pfSense

Configuring interfaces in the pfSense traffic shaper wizard.

Wrapping a GUI around the underlying traffic shaping components in pfSense proved to be difficult. Lacking functionality in the underlying system in some areas also limits its capabilities. The traffic shaper was rewritten for pfSense 2.0 and accommodates multiple interfaces.

Traffic to the LAN IP is queued in the same manner as traffic traversing the firewall. If your web interface uses HTTPS, and your traffic shaper queue for HTTPS is filled, it will delay your traffic to the management interface the same as if your HTTPS request were going out to the Internet. If you use pings to the LAN IP from a monitoring system, you may see significant delay for the same reason.


In addition, the shaper is not capable of truly differentiating between protocols. Traffic using TCP port 80 is considered as HTTP, whether it’s really HTTP or it’s P2P application using port 80; traffic using port 443 is considered as HTTPS, and so on. This can be a significant problem in some cases.

Traffic Shaping in pfSense: A Brief Look at PF Rules

Traffic shaping functionality, as with everything else in pfSense, is provided by PF. If you’re willing to write your own rules, this gives you considerable flexibility in configuring traffic shaping. For example, consider the hypothetical from the first article in which there is a backlog of ACK packets on an asymmetric Internet connection. We want to alter the rule set so ACK packets have a higher priority than other packets, so we set up two separate data queues. The result might look something like this:

ext_if="kue0"

altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
    queue q_pri priority 7
    queue q_def priority 1 priq(default)

pass out on $ext_if proto tcp from $ext_if to any flags S/SA \
    keep state queue (q_def, q_pri)

pass in on $ext_if proto tcp from any to $ext_if flags S/SA \
    keep state queue (q_def, q_pri)

Here, a priority-based queue is set up on the external interface ($ext_if) with two subordinate queues. On subqueue has a high priority value of 7 (q_pri), while the other has a low priority value of 1 (q_def). Once a connection is assigned to the main queue, ALTQ inspects each packet’s type of service (ToS) field. ACK packets have the ToS Delay bit set to low, indicating that the sender wanted the speediest delivery possible. When ALTQ sees a low-delay packet and queues of differing priority are available, it will assign the packet to the higher-priority queue.

For those of us who don’t want to be bothered manually rewriting the rules, there’s the traffic shaper wizard. You can access the traffic shaper wizard from the pfSense web interface by navigating to Firewall -> Traffic Shaper and clicking on the Wizard tab. It is generally a good idea to configure traffic for the first time using the wizard. If you need custom rules, you can always step through the wizard, approximate what you need, then make the custom rules afterward. Each screen will setup unique queues, and rules that will control what traffic is assigned into those queues. Should you want to configure everything manually, simply specify your WAN speed at the first screen, then click Next through all the remaining screens without configuring anything.

In the next article, we’ll step though the pfSense traffic shaper wizard.


External Links:

Traffic Shaping Guide at doc.pfsense.org

Traffic Shaping Rules in pfSense 2.1

Creating traffic shaping rules in pfSense 2.x is handled a bit differently than in previous versions of pfSense. In the old pfSense, traffic shaping rules were controlled by navigating to Firewall -> Traffic Shaper, clicking on the “Rules” tab, and then adding or editing rules as needed. Now, all rules, whether they invoke traffic shaping queues or not, are controlled by navigating to Firewall -> Rules.

An Example: Creating Traffic Shaping Rules for BitTorrent

Traffic Shaping Rules

Adding a traffic shaping rule to put BitTorrent traffic into the P2P queue in pfSense 2.1.

The option to place traffic into a queue can be found by scrolling down to “Advanced Features“, and pressing the “Advanced” button next to Ackqueue/Queue. To illustrate the process, let’s create traffic shaping rules to explicitly direct BitTorrent traffic coming in and out of a specific port into the P2P queue. Although we’re doing it here just to illustrate the process, if you are using BitTorrent, there may be a legitimate reason to make a special rule for this traffic. pfSense relies primarily on ports to tell what program the traffic appears to be rather than examining the packets. Since BitTorrent relies on non-standard ports, it is quite possible that such traffic will not automatically go into the P2P queue. There is a way of identifying traffic based on the content of the packets instead of just the source or destination ports known as layer 7 shaping (deep packet inspection). This feature is only found in pfSense version 2.0 and newer. Layer 7 shaping will be the subject of a future article, but for purposes of this exercise, we will assume that this is not an option. Therefore, we endeavor to take the following measures: [1] use the P2P Catchall rule; [2] treat the default queue as low priority, and [3] make rules for each type of traffic you want.

Traffic Shaping Rules

Configuring the queues under Advanced Settings at Firewall -> Rules.

The P2P Catchall rule is added by using the traffic shaper wizard, which was covered in a previous article, and editing queue settings was also covered in a previous article, so I will focus on making rules to cover BitTorrent traffic. To begin, we will go to Firewall -> Rules and click on “plus” to add a firewall rule. We want to leave the “Action” as Pass, and choose WAN as the “Interface“. For “TCP/IP Version“, we will select IPv4+IPv6. We’ll leave the “Protocol” as TCP and leave “Source” unchanged. For “Destination“, we’ll select “Single host or alias” and type in the address of the target computer (in this case, 192.168.1.10). For “Destination port range“, we will put our BitTorrent port (22453). We will not log packets, but we will enter a brief “Description“. Scrolling down to “Advanced Features“, press the “Advanced” button next to “Ackqueue/Queue“. Select “qACK” for the Ackqueue and “qP2P” for the queue. [This assumes we set up a P2P queue earlier.] Then press the “Save” button to save the rule and press “Apply changes” on the next page.


Now we have a rule to handle incoming BitTorrent traffic, but there is also outgoing traffic, and we want to set up a rule to handle that as well. To do so, click on the “plus” button. We will keep most of the settings for the previous rule, but we will change “Interface” to LAN and “Destination” to WAN subnet. We will again specify 22453 for the “Destination port range” and “qACK” and “qP2P” for the queues. Again, press “Save” to save the rule and “Apply changes” on the next page.

Now, we have traffic shaping rules for both incoming and outgoing BitTorrent traffic on port 22453 configured, thus ensuring that traffic on that port will go into the P2P queue. You’ll want to enable the P2P Catchall queue if you didn’t already, and limit the bandwidth used by the default queue, but otherwise, we should be set up to handle BitTorrent on our chosen port.


Other Articles in This Series:

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

External Links:

pfSense Bandwidth Management – How to Configure the Traffic Shaper at hubpages.com

Link Ads:


Queue Configuration in pfSense 2.1

traffic shaping queue

Configuring the qVoIP traffic shaping queue under pfSense 2.1.

In the previous articles, I covered the basics of the traffic shaper and how to configure it using the wizard. In this article, we’ll examine how to monitor traffic shaping and some advanced configuration techniques.

In order to make sure the traffic shaper is working as it should, you can monitor it. In order to do so, navigate to Status -> Queues. This screen will show each queue listed by name, its current usage, and some other statistics. The graphical bar on this screen shows you how full a queue is. The rate of data in the queue is shown as both packets per second (or pps) and bits per second (or b/s). Borrows happen when a neighboring queue is not yet full and capacity is borrowed from there when needed. Drops happen when traffic in a queue is dropped in favor of higher priority traffic. It is normal to see drops, and this does not mean that a full connection is dropped, just a packet. Usually, one side of the connection will see that a packet was missed and then resend it, often slowing down to avoid future drops. The suspends counter indicates when a delay action happens.

If you find that the rules generated by the traffic shaper do not quite fit your requirements, you may want to edit the shaper queues manually. You may have a service that is not handled by the wizard, a game that uses a different port, or other services not covered by the wizard. It should be relatively easy to cover these cases.

The queues are where bandwidth and priorities are actually allocated. In pf, each queue is assigned a priority, from 0 to 7. When there is an overload of traffic, the higher-numbered queues are preferred over the lower-numbered ones. Each queue is assigned either a hard bandwidth limit or a percentage of the total link speed. The queues can be assigned other attributes that control how they behave. Queues may be changed by navigating to Firewall -> Traffic Shaper and clicking on the Interfaces tab. You will see a list of rules here, sorted by interface. Clicking on one of the queues will enable you to edit the settings for it.


Queue Configuration Options

Editing queues is not easy, and if you do not have a thorough understanding of the settings involved, it is best to leave the settings alone. That having been said, here are the options. “Enable/Disable queue and its children” and “Queue Name” are self-explanatory. “Priority” assigns a priority to the queue from 0 to 7 (7 is highest). The “Queue limit” field specifies the queue limit in packets per second. Next is “Scheduler options“; there are five different options here:

  • Default Queue: Selects this queue as the default, the one which will handle all unmatched packets. Each interface should have one and only one default queue.
  • Random Early Detection (RED): This is a method to avoid congestion on a link; it will actively attempt to ensure that the queue does not get full. If the bandwidth is above the maximum given for the queue, drops will occur. Also, drops may occur if the average queue size approaches the maximum. Dropped packets are chosen at random, so the more bandwidth in use by a given connection, the more likely it is to see drops. The net effect is that the bandwidth is limited in a fair way, encouraging a balance. RED should only be used with TCP connections; TCP is capable of handling lost packets and can resend when needed.
  • Random Early Detection In and Out (RIO): Enables RED with in/out, which will result in having queue averages being maintained and checked against for incoming and outgoing packets.
  • Explicit Congestion Notification (ECN): Along with RED, it allows the sending of control messages that will throttle connections if both ends support ECN. Instead of dropping the packets as RED will normally do, it will set a flag in the packet indicating network congestion. If the other side sees and obeys the flag, the speed of the ongoing transfer will be reduced.
  • CoDel Active Queue: A newish form of AQM (Active Queue Management) designed to solve at least in part the problem of bufferbloat (persistently full buffers). The three primary innovations of CoDel are: [1] using the local minimum queue as the queue measure; [2] simplified single-state variable tracking of how long the minimum has been above or below the target value for standing queue delay rather than keeping a window of values to compute the minimum; and [3] use of queue-sojourn time rather than measuring queue size in bytes or packets. This simple description does not do justice to the CoDel AQM, but you can read more about it at the ACM white paper on CoDel: (HTML PDF).

The next two fields are fairly self-explanatory: at “Description“, you can enter a brief description, and at “Bandwidth“, you can specify the total bandwidth allocated to this queue. The options for “Service Curve” are interesting because they enable you to configure a Hierarchical Fair Service Curve (HFSC) for the queue. I covered HFSC in somewhat greater depth in a previous article, but here are the options in a nutshell:

  • m1: Burstable bandwidth limit
  • d: Time limit for the bandwidth burst, specified in milliseconds
  • m2: Normal bandwidth limit

For example, you need m1 bandwidth within d time, but with a normal maximum of m2. Within the time set by d, m1 is the maximum. After d milliseconds has expired, if the traffic is still above m2, it will be shaped. If you read my article about HFSC or any of the other material relating to it, you will see that m1 and m2 are two different slopes for the curve.


Each of the values m1, d and m2 can be set for the following uses:

  • Upper Limit: Maximum bandwidth allowed for the queue. Will do hard bandwidth limiting.
  • Real Time: Minimum bandwidth guarantee for the queue. This is valid only for child queues.
  • Link Share: The bandwidth share of a backlogged queue. It will share the bandwidth between classes if the Real Time guarantees have been satisfied.

Finally, at the bottom of the page, there is a “Save” button to save the changes to a queue, “Add new queue” if you want to add a queue, and “Delete queue” to delete it. This covers the queue options in pfSense 2.1. In writing this article, it has occurred to me that I have not yet addressed some of the configuration and troubleshooting issues involved with traffic shaping, so these subjects will likely be topics for future blog postings.

Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
Traffic Shaping Wizard: Introduction
QoS Management Using the Traffic Shaper Wizard
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic Shaper in pfSense 2.0 – doesn’t cover 2.1, but it’s still a good article.

Controlling Queue Delay at queue.acm.org – this is the white paper on the CoDel AQM.

Link Ads:


Traffic Shaping in pfSense: What it Does

traffic shapingTraffic shaping is a computer network traffic management technique designed to delay some or all datagrams to bring them into compliance with a traffic profile. Without traffic shaping, packets are processed on a first in/first out basis by the firewall. Traffic shaping, or Quality of Service (QoS) offers a means of prioritizing different types of traffic. This ensures that higher priority services receive the bandwidth they need before lesser priority services. This helps to optimize or guarantee performance, improve latency, and/or increase usable bandwidth for some kinds of packets by delaying other kinds.

Another way of managing computer traffic is traffic policing. The difference between policing and shaping is that traffic policing propagates bursts. When the traffic rate reaches the configured maximum rate, excess traffic is dropped or remarked. The result is an output rate that appears on a graph as a saw-tooth with crests and troughs. In contrast to policing, traffic shaping retains excess packets in a queue and then schedules the excess for later transmission over increments of time. The result of traffic shaping is a smoothed packet output rate.


For purposes of this discussion, we are concerned mainly with traffic shaping in pf (and therefore pfSense). The way traffic shaping is accomplished in pf is that incoming traffic from the Internet going to a host on the LAN is actually shaped coming out of the LAN interface from the pfSense system. In the same manner, traffic going from the LAN to the Internet is shaped when leaving the WAN. This is because traffic has to be limited in a place where pf/pfSense can actually control the flow of data.

There are two means by which traffic shaping is accomplished: traffic shaping queues and traffic shaping rules. The queues are where bandwidth and priorities are actually allocated, while traffic shaping rules control how traffic is assigned into those queues. If a packet matches a shaper rule, it will be assigned into the queues specified by that rule. In that manner, traffic shaping rules are similar to firewall rules, with matching criteria and with outcomes dictated based on whether a packet matches the criteria.

Traffic Shaping: Reasons

The primary reasons you would use traffic shaping are to control access to available bandwidth, to ensure that traffic conforms to the policies established for it, and to regulate the flow of traffic in order to avoid congestion that can occur when the sent traffic exceeds the access speed of its target (remote) interface. Here are some examples why you might want to use traffic shaping:

  • Control access to bandwidth when policy dictates that the rate of a given interface should not on the average exceed a certain rate even though the access rate exceeds the speed.
  • If the network has differing access rates. Suppose that one end of the link in a Frame Relay network runs at 256 kbps and the other end of the link runs at 128 kbps. Sending packets at 256 kbps could cause failure of the applications using the link.
  • If you offer a subrate service. In this case, traffic shaping enables you to use the router to partition your T1 or T3 links into smaller channels.
  • Smoothing out asymmetric links, where the download speed differs from the upload speed (such as DSL connections). Some links are so out of balance that the maximum download speed is unattainable because it is difficult to send out enough ACK packets to keep traffic flowing. By using the traffic shaper to prioritize ACK packets you can achieve faster and more stable download speeds on asymmetric links.
  • Prioritizing VoIP calls. If your VoIP calls use the same circuit as data, then uploads and downloads may degrade your call quality. pf/pfSense can prioritize the call traffic above other protocols and ensure the calls make it through without breaking up.
  • Network gaming. There are also options to give priority to the traffic associating with networking gaming, even if you are downloading while playing.
  • P2P applications. By lowering the priority of traffic associated with known peer-to-peer ports, pf/pfSense ensures that P2P applications will not interfere with other traffic on your network.


Other Articles in This Series:

Traffic Shaping Wizard: An Introduction
QoS Management Using the Traffic Shaper Wizard
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic shaping at Wikipedia

Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting [QoS Policing] at www.cisco.com

Ad Links:


© 2013 David Zientara. All rights reserved. Privacy Policy