Troubleshooting Shaper Issues¶
Traffic Shaping/QoS is a tricky topic, and can prove difficult to get right the first time. This section covers several common pitfalls.
Bittorrent traffic not using the P2P queue¶
Bittorrent is known for not using standard ports. Clients are allowed to declare which port other clients use to reach them, which means chaos for network administrators trying to track the traffic based on port alone. Clients can also choose to encrypt their traffic. Regular shaper rules don’t have any way to examine the packets to tell what program the traffic appears to be, so it is forced to rely on ports. This is why it may be a good idea to use the P2P Catchall rule, and/or make rules for each type of desirable traffic and treat the default queue as low priority.
UPnP traffic shaping¶
Out of the box, traffic allowed in by the UPnP daemon will end up in the default queue. This happens because the rules generated dynamically by the UPnP daemon do not have any knowledge of queues unless UPnP is configured to send traffic into a specific queue.
Depending on what the client devices utilizing UPnP on a network, this may be low priority traffic like Bittorrent, or high priority traffic like game consoles or voice chat programs like Skype.
To configure UPnP to use a specific ALTQ queue:
Setup ALTQ shaping and decide which queue to use for UPnP & NAT-PMP
Navigate to Services > UPnP & NAT-PMP
Enter the chosen ALTQ queue name into the Traffic Shaping field
This trick only works with the ALTQ shaper. At this time, the firewall is not capable of assigning UPnP traffic to a limiter.
ACK queue bandwidth calculations¶
This is a complex topic and most users gloss over it and guess a sufficiently high value. For more detailed explanations with mathematical formulas, check the Traffic Shaping section of the Netgate forum. There is a sticky post in that board which describes the process in great detail, and there is also a downloadable spreadsheet which can be used to help ease the process.
Why is <x> not properly shaped?¶
The reason is nearly always one of these choices:
The traffic matched a different rule than expected
The traffic did not match any rule
As with other questions in this section, this tends to happen because of rules entered either internally or by other packages that do not have knowledge of queues. Since no queue is specified for a rule, it ends up in the default or root queue, and not shaped.
Working around the limitation may require altering the rules to better match the traffic, or disabling internal rules that are matching the traffic in unexpected ways. Another tactic is to identify all other traffic and then use different shaping options on the default queue.
In rare cases, such as bittorrent, it may be impossible to accurately identify all traffic of a given type. One workaround is to isolate the traffic to one specific device on the network and then match based on that client device address.
WAN connection speed changes¶
To update the speed of a WAN if it changes, edit the appropriate queues under Firewall > Traffic Shaper to reflect the new speed.
The queues that need updating are:
The root queue for each WAN interface for the upload speed
The root queue for each LAN interface for the download speed
qInternet queue for each LAN interface for the download speed
If this firewall has multiple WANs, the LAN root and qInternet queue must use the total download speed of all WANs.
Alternately, if the wizard created all of the queues and rules and these have not been changed, then complete the wizard again and update the speed using the wizard.