21. Traffic Shaping

Kernun UTM can control the amount of bandwidth consumed by various types of network communication. This feature is known as traffic shaping. Traffic shaping is based on a division of the available network bandwidth into queues of various capacity. The traffic shaping rules then assign outgoing network packets to queues. A queue controls how fast a packet will be sent out. Traffic shaping in Kernun UTM is implemented using the altq(4) framework.


Traffic shaping works only for packets sent by Kernun UTM to a network, internal or external. It is not possible to limit the rate of reception of incoming packets. It is therefore impossible to limit the download speed from the external to the internal network by queuing received packets on the external interface; packets sent by the internal interface must be queued instead.

We will describe a simple traffic shaping configuration aimed at limiting the bandwidth usage by SSH communication of clients in the internal network with servers in the external network, and limiting the download speed of selected HTTP communication. We assume that the maximum speed of both the internal and external network interfaces is 100 Mbits/s.

Let us specify our sample objectives more precisely: 1. For any SSH connection, i.e., a connection to a server in the external network on port 22, we want to limit the data flow to 10 Mbits/s in each direction. 2. Clients from a subset of the internal network accessing HTTP servers in the external network are to have the download speed limited to 10 Mbit/s for selected request URIs at certain time intervals. The 10 Mbit/s limit will be shared by the SSH and HTTP communication.

Figure 5.84. Configuration of traffic shaping queues

Configuration of traffic shaping queues

The first step in traffic shaping configuration is to define the set of queues. This is done by adding sections system.pf-queue and system.packet-filter.altq, see Figure 5.84, “Configuration of traffic shaping queues”. All our queues use the cbq (Class Based Queueing) scheduler, i.e., the bandwidth of a network interface is divided into a hierarchically organized tree of queues. We define a parent queue on the internal network interface by section pf-queue INQ-ALL and subsection altq of section packet-filter. The pf-queue section selects the cbq scheduler and specifies (using the default parameter) that the queue will get all packets that are not explicitly assigned to another queue. The queue can use all 100 Mbits/s available for the interface. Subsection altq specifies that the parent queue, and also its child queues, will handle packets sent to the internal network via the INT interface. The bandwidth is split between two child queues defined by pf-queue INQ-FAST (90 Mbits/s) and pf-queue INQ-SLOW (10 Mbits/s). Moreover, queue INQ-SLOW can borrow unused bandwidth from other queues. Similarly, there are three queues OUTQ-ALL, OUTQ-FAST, and OUTQ-SLOW[41] for handling packets sent to the external network via the EXT interface.

The /usr/local/kernun/conf/samples/cml/altq.cml file contains the complete sample configuration. For detailed description of ALTQ parameters, refer to packet-filter(5) and pf.conf(5).

Traffic shaping can be done at two levels, using either packet filter, or queue selection in proxy ACLs. We will use each of the levels for one of our sample objectives.

Figure 5.85. Traffic shaping by packet filter ACLs

Traffic shaping by packet filter ACLs

The SSH communication speed can be limited using packet filter ACLs, as depicted in Figure 5.85, “Traffic shaping by packet filter ACLs”. Packets in the direction from the server to the client are matched by filter-acl SLOW-SSH-IN as they are sent by tcp-proxy SSH to the internal network. This filter-acl matches packets sent (direction out) on interface INT, from any server IP address and from the server port 22. The packets are accepted and queued via queue INQ-SLOW. Similarly, filter-acl SLOW-SSH-OUT matches packets in the direction from the client to the server as they are sent by tcp-proxy SSH to the external network. It matches packets sent (direction out) on interface EXT, to any server IP address and to the server port 22. The packets are accepted and queued via queue OUTQ-SLOW.

Figure 5.86. Traffic shaping by proxy ACLs

Traffic shaping by proxy ACLs

The HTTP communication speed cannot be limited by the packet filter, because the desired conditions for queue selection cannot be expressed in a filter-acl. Hence, we utilize the possibility to specify a queue in an ACL of a proxy. In Figure 5.86, “Traffic shaping by proxy ACLs”, request-acl SLOW matches response data returned by Web servers for requests issued by clients from the subnet each day between 8 and 22 hours. Requests with URI path beginning with the string /download are exempted from traffic shaping. The matching response data are queued to client-altq INQ-SLOW as they are sent to the client by the proxy. If we wanted to limit speed of request data sent by the client, we would use server-altq OUTQ-SLOW to queue data when they are sent to the server by the proxy.

There are several ways how to check that traffic shaping is working correctly. The command pfctl -s queue -v executed on the shell command line displays the numbers of packets and bytes passed via individual queues. The proxy online monitoring, described in Section 6.3, “Monitoring of Active Sessions”, reports the current data transmission rates of all active sessions. The amount of transferred data and the session duration are reported in a SESSION-END log message for each terminated session.

[41] Unlike INQ-SLOW, this queue cannot borrow bandwidth.