We have demonstrated how queues can be added and how existing queues can be edited, but the traffic shaping rules control how network traffic is assigned into these queues. If a packet matches a rule, it will be assigned into the queue that the rule specifies. Thus traffic shaping rules are essentially a subset of the firewall rules covered in Chapter 4, pfSense as a Firewall.
In older versions of pfSense, traffic shaper had a separate tab called Rules. This tab showed all the rules generated by the traffic shaper. This is no longer the case. To see the traffic shaper rules, navigate to Firewall | Rules and click on the Floating tab. The traffic shaper rules will be listed here, mixed in with any other floating rules that you created yourself. Nonetheless, you should be able to distinguish the trafficshaper rules from the nontraffic-shaper rules by their description. In addition, all traffic-shaper rules will have a value specified for Queue (for example, qOthersLow, qVoIP, and so on), whereas other rules may not have a queue specified.
To edit a rule, click on the edit icon (represented by a pencil); to delete a rule, click on the delete icon (represented by a trash can). Both options can be found in the Actions column (the right most column in the table). You can also change the order of rules in two different ways. You can click on a rule in the table and drag it to a different position. If you need to move more than one rule, it may be more convenient to check the rules (the checkbox for each rule is in the left most column) and then click on the Move checked rules above this one icon in the Actions column for the rule, which the checked rules are to be moved ahead of. To add a new blank rule, click on one of the Add buttons at the bottom of the list (the Add button with the up arrow creates a new rule at the top of the list, while the one with the down arrow creates a new rule at the bottom of the list). To create a rule based on an existing rule, click on the copy icon (represented by two sheets) in the Actions column of the rule you want to copy.
Each rule will have several matching criteria. These criteria are what ensure that traffic is fed into the proper queue. Traffic shaping rules can have separate inbound and outbound queues, but most of the rules generated by the pfSense traffic shaper wizard have the same queue for inbound and outbound traffic. This is because the wizard generates floating rules, which apply to traffic in both directions. This saves us from having to generate separate rules for inbound and outbound traffic, but it also means that inbound and outbound traffic must be fed into the same queue, since each rule can only assign traffic into one queue.
If we click on the Edit option for any traffic shaper rule, we can see that such a rule has much in common with any other firewall rule, although there are some significant differences. The first field is the Action drop-down box. Traffic shaping rules do not utilize the Pass, Block or Reject options used by most other firewall rules, but instead use the Match option. As mentioned in Chapter 4, pfSense as a Firewall, this option allows pfSense to match traffic without affecting its pass/block status. The interface selected in the Interface list box is usually the WAN interface. The Direction drop-down box determines whether the rule applies to inbound traffic, outbound traffic, or both. As mentioned previously, most of the rules generated by the pfSense traffic shaper wizard appear to take advantage of the fact that floating rules can apply to traffic in both directions; therefore, the traffic shaper rules are generally set to any.
The aforementioned settings are the same for all the autogenerated rules, but the elements that differentiate traffic are the core of traffic shaping rules. The two factors that seem to be used most often to filter traffic are protocol (TCP is most commonly used, but many VoIP and gaming services use UDP) and port number. Consider, for example, an autogenerated rule to divert DCC traffic into the P2P queue. TCP is selected as Protocol (which is not unusual), and Destination port range is set to 6666 to 6668. This rule might not be that effective, since the end user can easily circumvent it by changing the port range on their DCC client (easy to circumvent in the case of receiving files; sending files via DCC requires adding a NAT port forwarding entry). On the other hand, our traffic shaper rules should work pretty well with services that always use the same ports. For example, our rule to send all port 25 traffic into the low-priority queue should be effective in ensuring that all SMTP traffic is given a lower priority.
A good example of a rule which uses both protocol and port as matching criteria is an autogenerated rule created by pfSense to assign a higher priority to Ventrilo voice traffic. Here, the protocol is UDP, so UDP is selected in the Protocol drop-down box. Port 6100 is also used, so it is specified as Destination port range.
Although they seldom seem to be used by the pfSense autogenerated rules, another way of matching traffic is to use the TCP flags. The TCP flags indicate various states of a connection, and they can be matched on whether or not they are set, cleared, or we can leave the checkboxes unchecked if we don't care whether they are set. Since we covered the TCP flags in detail in Chapter 4, we won't cover it here, other than to be aware that they may be used as matching criteria.
The last option in the Advanced Options section is Ackqueue/Queue, and this is where the matching traffic is assigned to a queue. The first drop-down box selects the queue for ACK traffic; the second drop-down box selects the queue for all other traffic. In practice, Ackqueue is often left undefined (set to None) and Queue is the only selection made, although it is good practice to set up a dedicated queue for ACK traffic to prevent delays caused by the remote node waiting for ACKs that are stuck in a queue with other traffic.
Armed with this information, we should now be able to make changes to traffic shaping rules if necessary. As always, you may want to make a backup before making any rule changes, in case the changes lead to unfavorable results and you want to revert back to your old ruleset.