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.
Important
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.
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.
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.
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 192.168.10.0/25 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.