Shorewall

Updated 13 July 2022

Shorewall or, more precisely, Shoreline Firewall is a firewall configuration tool. Technically, it is a Netfilter (iptables/ipchains) kernel subsystem add-on that implements simplified configuration methods. It provides a higher level of abstraction for firewall rules description.

Installing Shorewall

In Calculate Linux Desktop and Calculate Directory Server, Shorewall is included in the basic distribution. On other Calculate flavours, you have to install it:

To get more firewall functionality, try these:

• net-firewall/xtables-addons+, extensions not added to kernel/iptables (to define p2p traffic)
• net-misc/l7-filter-userspace, p classification by contents (to detect traffic by contents)
• net-libs/gupnp-igd, for UPnP functionality

To install them, run:

Shorewall configuration

Shorewall is not a daemon, i.e. it does not operate continuously. The rules are stored in text files. When shorewall starts, it reads its configuration files and converts them into settings that ipchains/iptables can understand, after which these firewall settings take effect until the operating system restarts.

• Zones Shorewall considers the network in which it operates as a set of zones. This is why you need to define one or more zones in the /etc/shorewall/+zones when you start configuring Shorewall. Zones are individual IP addresses of hosts, subnets, or incoming/outgoing packets for a specific interface. They can refer to an external network, an internal network, or a [DMZ] (https://en.wikipedia.org/wiki/DMZ_(computing)) network.
• Interfaces Zones are recognized either by the network interface associated to them, as defined in /etc/shorewall/ interfaces, or by the IP address of the subnet specified in /etc/shorewall/hosts. One zone can be associated to several interfaces, as well as one interface can be associated to several zones. Note that Shorewall considers the firewall system as its own zone.
• Actions Once the zones have been defined, you need to set the default action in /etc/shorewall/policy (such as ACCEPT or DROP), to be applied to the traffic between each source zone and destination zone.
• Policies Finally, the /etc/shorewall/rules file contains policy exceptions that allow access to specific ports, etc.

Zone declaration

To declare a zone, you have to edit the /etc/shorewall/zones file. To declare a zone, you need to specify its name (ZONE) and its type (TYPE) (mind that "firewall" is the firewall zone, while "ipv4" is the standard zone).

The order in which zones are described is important because it is in this order that iptables chains will be called to check for packets forwarded from one zone to another. In other words, a packet addressed to the firewall is first checked for net, and then for loc~, as shown in the example above. This rule is important if one zone includes the other. For example, you can create a "phone" zone within loc, which would include several IP addresses from ~loc. Now, if you describe ~loc~ first and then "phone", the policy described for "phone" will never be executed, because the traffic will go to ~loc~ chains. This problem can be solved by specifying the "phone" zone as a subzone of loc ("phone:loc ipv4").

Here is a configuration example for two network cards:

• The firewall (fw), firewall
• The Internet connection (net) uses ipv4
• The local network (loc) uses ipv4

#ZONE   #TYPE
fw      firewall
net     ipv4
loc     ipv4

To learn more about how to edit this file, type man shorewall-zones.

Linking the interface to a specific zone

To assign the interface to a zone, edit the /etc/shorewall/interfaces file. You can also define in this file which filters to use when processing incoming packets.

To assign an interface to a certain zone, you must specify the name of this zone (ZONE), the interface name (INTERFACE), the broadcast address (BROADCAST) ("detect" is the recommended value), and, if necessary, list the filters (OPTIONS).

Here is an example with two network cards.

In the file, specify that eth0~ is for Internet access (net), while eth1~ stands for the local network (~loc). The filters for incoming traffic are tcpflags, routefilter, nosmurfs, logmartians.

• tcpflags means that incoming packets are checked for wrong combination of TCP flags;
• routefilter adds anti-spoofing checkup.
• nosmrfs avoids skipping a packet with a broadcast outbound address.
• logmartians stands for logging the packets containing an impossible outgoing address.

?FORMAT 2
#ZONE       INTERFACE       OPTIONS
net         eth0            tcpflags,routefilter,nosmurfs,logmartians
loc         eth1            tcpflags,routefilter,nosmurfs,logmartians

To learn more about how to edit this file, type man shorewall-interfaces.

Linking IPs to a specific zone

To link IP addresses or subnets to the zone, edit the /etc/shorewall/hosts file. To assign hosts/subnetworks to a zone, you must provide a zone name (ZONE) and a network interface with its subnet or IP addresses (HOST).

This is an example of a "vpn" zone definition. The current gateway sets up a tunnel with another gateway that is connected to segment ~10.0.0.0/24~.

#ZONE       HOSTS
vpn         eth0:10.0.0.0/24

This is an example of allocating IP addresses for phones (IPs ranging from ~192.168.0.60~ to ~192.168.0.80~~) to a separate "phone" zone. This can be convenient for access managing policies, not exceptions.

#ZONE       HOSTS
phone       eth1:192.168.0.60-192.168.0.80

To learn more about how to edit this file, type man shorewall-hosts.

Setting default behaviour for packets

The default action, or policy applied to traffic between each source zone and destination zone is specified in the /etc/shorewall/policy file. A rule is described as follows: source zone (SOURCE), destination zone (DEST), default rule (POLICY) (DROP, ACCEPT, REJECT) and, if necessary, the logging level (e.g. info).

The policy considers packets that create new connections. * RELATED / ESTABLISHED * packets (packets of the established connection) are skipped by default.

For an example, set the following policies:

1. enable the Internet connection in the local network
2. allow access from the firewall anywhere
3. discard all packets that came from the Internet and do the logging
4. reject other packets with an error message and do the logging

#SOURCE     DEST    POLICY      LOGLEVEL
loc         net     ACCEPT
$FW         all     ACCEPT
net         all     DROP        info
all         all     REJECT      info

To learn more about how to edit this file, type man shorewall-policy.

Adding masquerading

IP masquerading is a method of remapping one IP address space into another by substituting the sender's address dynamically, depending on the address assigned to the interface.

The Dynamic NAT (Masquerading) and Source NAT (SNAT) are define in в /etc/shorewall/snat.

To add masquerading to a specific interface, you have to define it (INTERFACE:DEST), then indicate the subnetwork for which this masquerading (SOURCE) and outgoing address (ADDRESS) for SNAT will be used. If the outgoing address is not specified, then the dynamic NAT will be used.

For example, for all packets sent via eth0 from your internal network (~192.168.0.0/24~~), you should use SNAT (~24.56.78.21~).

#ACTION             SOURCE              DEST
SNAT(24.56.78.21)   192.168.0.0/24      eth0

If necessary, you can exclude NAT when sending packets to specific subnets, for example, for ipsec tunnelling.

For example, to disable NAT when sending a packet to subnet ~192.168.2.0/24~~:

#ACTION             SOURCE              DEST
SNAT(24.56.78.21)   192.168.0.0/24      eth0:!192.168.2.0/24

To learn more about how to edit this file, type man shorewall-masq.

Adding rules

You need to define rules that describe exceptions to policies applied to traffic. Those are contained in the /etc/shorewall/rules file.

This file contains three sections: RELATED, ESTABLISHED, NEW, which stand for three connection statuses. Status conditions are defined by the conntrack criterium, that can classify packets depending on how they relate to connections. The NEW status allows to select only packets that open new connections, the ESTABLISHED status stands for packets belonging to the established connections, and the RELATED status corresponds to packets that open new connections that are logically related to the ones already established (for example, data connection in passive FTP mode). The INVALID status means that it is impossible to determine the connection the packet belongs to (INVALID is also included in the NEW section). As explained earlier, the policy describes the behavior for the NEW section, while ACCEPT is applied by default to the RELATED and ESTABLISHED sections.

The following examples are written to the NEW section.

Deny Internet access from some nodes

#ACTION     SOURCE                          DEST
REJECT      loc:10.0.0.100-10.0.0.254       net

Forward port (DNAT) 80

#ACTION     SOURCE      DEST
HTTP/DNAT   net         loc:10.0.0.5

If this rule must be also applied to the packets sent from LAN to the external IP of the gateway, edit the "masq" and "interfaces" files.
In "interfaces", add the routeback option for loc~, allowing the router to send packets from one local network to another.

#ACTION     SOURCE      DEST        PROTO
loc         eth1        detect      tcpflags,routeback

Add a SNAT rule to "masq" so that a packet for ~10.0.0.5 be sent from the IP of the gateway (~10.0.0.1 is the internal gateway IP).

#ACTION       SOURCE    DEST
eth1:10.0.0.5 eth1      10.0.0.1

To the rule added above add DNAT in "rules", so that all packets from the local network be sent to 10.0.0.5 (~1.2.3.4~~ , i.e. the external IP of the gateway must be placed in ORIGINAL DEST).

#ACTION     SOURCE      DEST            PROTO       DPORT      SPORT
HTTP/DNAT   loc         loc:10.0.0.5    -           -          1.2.3.4

Forwarding port 222 to 22

#ACTION     SOURCE      DEST                PROTO       DPORT
DNAT        net         loc:10.0.0.5:22     tcp         222

Forward LDAP port

For example, to enable remote replication for unix, samba, and mail services to the Calculate Directory Server:

#ACTION     SOURCE      DEST
LDAP/DNAT   net         loc:10.0.0.5

In the 80 port example, a macro is used, which is a rule(s) template. The sample macros are stored in / usr / share / shorewall and called macro.macroname. HTTP macro contents

#ACTION     SOURCE      DEST        PROTO       DPORT
PARAM       -           -           tcp         80

According to the contents of the macro, using it is equivalent to:

#ACTION     SOURCE      DEST            PROTO       DPORT
DNAT        net         loc:10.0.0.5    tcp         80

The sender and receiver of the packet can be defined as follows.

To learn more about how to edit this file, type man shorewall-rules.

Detection of network tunnels

In order for Shorewall not to reset encrypted traffic, the tunnel must be described in /etc/shorewall/tunnels . This file describes the rules for passing encapsulated (usually encrypted) traffic between Shorewall and a remote gateway.

The description contains the type of tunnel (TYPE), the original zone (ZONE) and the address of the remote gateway (GATEWAY).

As an example, define an IPSEC tunnel (ESP) between the current gateway and the remote one (at ~4.33.99.124~).

#TYPE           ZONE        GATEWAY
ipsec:esp       net         4.33.99.124

To learn more about how to edit this file, type man shorewall-tunnels.

Add Shorewall to autostart

In order for Shorewall to start when the gateway is started, run:

Configuring bandwidth management

The queue organization (queue) determines how the data is sent. It is important to understand that only the transmission rate of the data being sent can be managed.

As the Internet appears now, we cannot control the amount of incoming traffic. This is somewhat like a letterbox installed on the inside of your door: you cannot choose how much mail you get, unless perhaps you speak to everyone who writes to you.

However, the Internet mostly operates based on the TCP/IP protocol, which has a few useful features. TCP/IP ignores the network bandwidth between two hosts, so it sends data faster and faster (this is called "slow start"). In case of overload, packets are being lost and the connection becoming sluggish. (It is a bit more complicated - and smarter that than, as we shall explain later.)

Queue processing disciplines define the way data is transmitted. Disciplines can be "classless" or "classful".
They generally receive data, reorder, delay, or destroy it. Classful disciplines allow to use classes for a specific type of traffic. Therefore, there is a root discipline for the given interface that is either classful or classless. A classful discipline, in its turn, contains several classes that allow you to manage traffic.

To manage traffic, it is necessary to define the root discipline applied to the device.

Incoming traffic is fed into the incoming discipline, which can contain a number of filters to process packets. Those can thus be discarded, lost, filtered. This is called policing.
It happens pretty early in time, before the packet is forwarded for further processing, in order to decrease the CPU usage.

If a packet safely passes this stage, it can be forwarded either to local applications (in this case it gets in the IP stack for further processing) or to the network through the outgoing classifier to another network node. User applications can also send data to the network, which similarly is forwarded through the outgoing classifier. The outgoing classifier splits the traffic into queues, each of which has its own discipline. By default, pfifo_fast is the only outgoing queue. This is called "queuing".

Once in a queue, the packet waits for the kernel to pass it on to the network interface. This is called "fetching from the queue".

Enable traffic management on an interface

To enable traffic management, edit the /etc/shorewall/tcdevices file.

This file describes the channel width for the interface on which you want to use bandwidth management. The channel width can be measured in kbps, mbps, kbit, mbit and bps.

IN-BANDWIDTH defines the bandwidth of the incoming signal for the interface. Keep in mind that you cannot manage incoming traffic, because it has already been received. What you can do is limit the allowed traffic. Then packets that exceed this value will be dumped. If you do not want to dump, set value to 0 or -.

OUT-BANDWIDTH defines the bandwidth of the outgoing signal for the interface. This maximum speed is used as "full" when classifying traffic. The incoming traffic that exceeds this value will be dumped.

If Shorewall is installed on a gateway on which it is important to manage transit traffic, then for both interfaces it is necessary not to specify incoming traffic, since there may be problems later when managing bandwidth.

Here is how to set a channel of 10 mbit at the gateway (incoming traffic from the Internet is managed as outcoming to the local network):

#NUMBER:        IN-BANDWITH     OUT-BANDWIDTH
eth0            -               10mbit
eth1            -               10mbit

To learn more about how to edit this file, type man shorewall-tcdevices.

Traffic class definition

Classes are define in /etc/shorewall/tcclasses. Each line defines a traffic class, namely: the INTERFACE for which the class is being created, the MARK to define the class trafic belongs to, the guaranteed traffic RATE, the desired throughput (CEIL), the PRIORITY and additional OPTIONS.

The marker will be used when setting the rules (tcrules) for traffic belonging to a specific class. The guaranteed and desired bandwidth can be specified as an absolute value or compared to the total bandwidth provided for the interface (e.g. 2*full/3, two thirds of the channel). _ Guaranteed bandwidth_ means that at peak loads this type of traffic will have at least the specified bandwidth, desired bandwidth means that bandwidth for this type of traffic will not exceed the specified value. The lower the priority value, the higher the priority for traffic. Traffic with lower priority will not be processed until traffic with higher priority has been processed Additional parameters are comma-separated and can take the following values:

• default is the class by default. All unmarked traffic will be put here.
• tos=0xvalue[/0xmask] means traffic classification based on TOS .
• tos-tosname establishes TOS traffic classification based on five standard values
• tcp-ack - for detection of tcp ask packets that are under 64 bytes in size
• pfifo tells to use the pfifo discipline instead of SFQ for the class.
• limit = number - specifies the maximum number of packets that can be placed in this queue

For an example of classification, see below:

• 100-180kbit for TOS byte 68/b8 traffic (EF and AFF3-1 VOIP traffic)
• Interactive traffic, TCP acks and any packet marked as 2 will have a guaranteed 1/4 of the entire bandwidth and can take the entire channel.
• Unclassified traffic and packets marked as 3 will have a guaranteed 1/4 of the entire bandwidth and can take the entire channel.
• Packets marked as 4 have the lowest priority, they are guaranteed 1/8 of the bandwidth and can take 80% of the channel.

#INTERFACE  MARK    RATE        CEIL        PRIO        OPTIONS
eth0        1       100kbit     180kbit     1           tos=0x68/0xfc,tos=0xb8/0xfc
eth0        2       full/4      full        2           tcp-ack,tos-minimize-delay
eth0        3       full/4      full        3           default
eth0        4       full/8      full*8/10   4

To learn more about how to edit this file, type man shorewall-tcclasses.

Traffic marking configuration

Traffic marking can be configured by editing /etc/shorewall/mangle. Thanks to marking, the entries in this file determine the class the packet belongs to. The fields defining the marked conditions are as follows:

• ACTION
• SOURCE stands for the packet's sender.
• DEST stands for the packet's recipient.
• PROTO stands for the connection protocol.
• DEST PORT stands for the recipient's port(s).
• SOURCE PORT stands for the sender's port(s).
• USER is the user who owns the process that created the packet (it makes sense only for traffic originating from the firewall itself).
• TEST stands for the defined marker.
• LENGTH stands for the packet size.
• TOS stands for the TOS byte value
• CONNBYTES stands for the range of forwarded connection data
• HELPER is the name of the Netfiler helper module, e.g. to define ftp, sip, amanda, etc.

The mark is defined as follows:

• "MARK(value)[:{C|F|P|T|CF|CP|CT}]"
  "F" - marked in the FORWARD chain
  "P" - marked in the PREROUTING chain
  "T" - marked in the POSTROUTING chain
  "CF" - marked in the FORWARD chain
  "CP" - marked in the PREROUTING chain
  "CT" - marked in the POSTROUTING chain
• "RESTORE[/mask]" - restore the packet mark from the connection marking
• "SAVE[/mask]" - save the packet mark to the connection marking
• CONTINUE - do not process subsequent rules in the mark table

Example:

• All GRE packets (protocol 47), that were not created in the firewall system and with target IP 155.186.235.151 must be marked as 1.
• All SSH packets coming from 192.168.1.0/24 and going to 155.186.235.151 must be marked as 2.
• All P2P packets are to be marked as 4.

#ACTION         SOURCE          DEST            PROTO       DPORT       SPORT    USER      TEST
MARK(1):T       0.0.0.0/0       155.182.235.151 47
MARK(2):T       192.168.1.0/24  155.182.235.151 tcp         22
RESTORE         0.0.0.0/0       0.0.0.0/0       all         -           -        -         0
CONTINUE        0.0.0.0/0       0.0.0.0/0       all         -           -        -         !0
MARK(4):T       0.0.0.0/0       0.0.0.0/0       ipp2p:all
SAVE            0.0.0.0/0       0.0.0.0/0       all         -           -        -         !0

The latter four rules mean the following:

If the packet was not classified (marked as 0), then copy the connection mark to the packet mark. If the packet's mark is already defined, no more actions are required. If the packet is P2P, set the packet's mark tom 4. If the packet's mark is defined, save it as the connection mark.

To learn more about how to edit this file, type man shorewall-tcrules.

Configuration examples

Example of firewall configuration with VPN

Imagine that below is your network:

• computers in the internal network have IPs ~192.168.1.0/24~
• a Calculate Directory Server, connected to the internal network at eth1 with the IP address set 192.168.1.1 and with Internet access at eth0 with the IP address set ~1.2.3.4~ (gateway)
• OpenVPN or WireGuard server with network 192.168.20.0/24

First define the necessary zones: net for Internet, loc for local network, fw for firewall, vpn for VPN:

#ZONE       TYPE
fw          firewall
net         ipv4
loc         ipv4
vpn         ipv4

Now define net as served by the eth0 interface, loc~ as served by eth1, ~vpn as served by ~tun0~. The incoming traffic will be filtered on both network interfaces with tcpflags, routefilter, nosmurfs, and logmartians:

?FORMAT 2
#ZONE       INTERFACE       OPTIONS
net         eth0            tcpflags,nosmurfs,routefilter,logmartians
loc         eth1            tcpflags,nosmurfs,routefilter,logmartians
vpn         tun0
#vpn        wg0

Describe the default rules, or policies for transport through the gateway: the local network (~loc) and gateway ($FW~) are allowed access to all zones, packets from the network (~net) are dumped, the REJECT rule with logging is applied to the rest:

#SOURCE     DEST        POLICY          LOGLEVEL
loc         all         ACCEPT
vpn         all         ACCEPT
$FW         all         ACCEPT
net         all         DROP
all         all         REJECT          info

Add masks for the local network packages going to the Internet via VPN:

#ACTION         SOURCE              DEST
SNAT(1.2.3.4)   192.168.1.0/24      eth0
SNAT(1.2.3.4)   192.168.20.0/24     eth0

Describe a OpenVPN tunnel, associating it to the vpn zone:

#TYPE                   ZONE            GATEWAY                 GATEWAY_ZONE
openvpnserver:udp       net             0.0.0.0/0               vpn

Or else describe a WireGuard tunnel, associating it to the vpn zone as well:

#TYPE                   ZONE            GATEWAY                 GATEWAY_ZONE
openvpnserver:udp:51820 net             0.0.0.0/0               vpn

The gateway providing Internet access to the local network is ready to use. Add some rules:

• allow gateway pings from the Internet
• allow remote SSH connection to the gateway

?SECTION NEW
#ACTION         SOURCE                              DEST
Ping/ACCEPT     net                                 fw
SSH/ACCEPT      net                                 fw

Enable IP forwarding, TCP Clamp MSS and shorewall startup:

...
IP_FORWARDING=Yes
CLAMPMSS=Yes
STARTUP_ENABLED=Yes

Gateway configuration

Imagine that below is your network:

• computers in the internal network have IPs ~192.168.1.0/24~
• a Calculate Directory Server, connected to the internal network at eth1 with the IP address set 192.168.1.1 and with Internet access at eth0 with the IP address set ~1.2.3.4~ (gateway)
• the local network has a mail server, 192.168.1.10

First define the necessary zones: 'net' for the Internet, 'loc' for the local network, 'fw' for CDS:

#ZONE       TYPE
fw          firewall
net         ipv4
loc         ipv4

Now associate net with the eth0 interface and loc with the eth1 interface. The incoming traffic will be filtered on both network interfaces with tcpflags, routefilter, nosmurfs, and logmartians:

?FORMAT 2
#ZONE       INTERFACE       OPTIONS
net         eth0            tcpflags,nosmurfs,routefilter,logmartians
loc         eth1            tcpflags,nosmurfs,routefilter,logmartians

Describe the default rules (or policies) for traffic passing through the gateway: local network (~loc) and gateway (~$FW) allowed access to all zones, packets from the Internet (net) are dumped, the REJECT rule is applied to all other packets and the whole process is logged:

#SOURCE     DEST        POLICY          LOGLEVEL
loc         all         ACCEPT
$FW         all         ACCEPT
net         all         DROP
all         all         REJECT          info

Add masquerading for packets coming from the local network to the Internet:

#ACTION         SOURCE              DEST
SNAT(1.2.3.4)   192.168.1.0/24      eth0

The gateway providing Internet access to the local network is ready to use. Now add some rules:

• allow gateway pings from the Internet
• allow remote SSH connection to the gateway
• deny Internet connection from IPs 192.168.1.100 to 192.168.1.254
• forward IMAP/IMAPS ports for access to the mail server from the Internet
• forward the SMTP port to the mail server

?SECTION NEW
#ACTION         SOURCE                              DEST
Ping/ACCEPT     net                                 fw
SSH/ACCEPT      net                                 fw
REJECT          loc:192.168.1.100-192.168.1.254     net
IMAP/DNAT       net                                 loc:192.168.1.10
IMAPS/DNAT      net                                 loc:192.168.1.10
SMTP/DNAT       net                                 loc:192.168.1.10

Enable shorewall to start:

STARTUP_ENABLED=Yes

Enabling IP telephony

Add IP telephony to the previous example:

• the phones are connected to the main network and their IP addresses range from ~192.168.1.70~ to ~192.168.1.99~~
• install Asterisk on server 192.168.1.10

Declare a new zone, phone~ for phones. ~phone must be announced before loc~:

#ZONE       TYPE
fw          firewall
net         ipv4
phone       ipv4
loc         ipv4

Assign phones from the loc zone to phone:

#ZONE       HOST
phone       eth1:192.168.1.70-192.168.1.99

Describe a policy forbidding phones (~phone) from going online (~net):

#SOURCE     DEST        POLICY          LOG
phone       net         DROP
loc         all         ACCEPT
$FW         all         ACCEPT
net         all         DROP
all         all         REJECT          info

Ping the SIP and IAX ports at 192.168.1.10:

?SECTION NEW
#ACTION         SOURCE          DEST                PROTO       DEST
...
SMTP/DNAT       net             loc:192.168.1.10
# SIP
DNAT            net             loc:192.168.1.10    udp         5060
# IAX
DNAT            net             loc:192.168.1.10    udp         4569

IPSEC tunnelling

Modify the network of the previous example according to the diagram (adding a remote subnet):

• The gateway establishes an ipsec tunnel with a remote gateway, connecting segment ~192.168.3.0/24~+
• The IP of the remote gateway is 1.2.3.5

Add the "vpn" zone for the remote subnet:

#ZONE       TYPE
fw          firewall
vpn         ipv4
net         ipv4
phone       ipv4
loc         ipv4

Define vpn (packets coming to eth0 and located in subnet ~192.168.3.0/24~):

#ZONE       HOSTS
phone       eth1:192.168.1.70-192.168.1.99
vpn         eth0:192.168.3.0/24

Describe the tunnel: ipsec, the tunnel goes via the net~ zone, the IP address of the remote gateway is as follows:

#TYPE      ZONE        GATEWAY          GATEWAY ZONE
ipsec      net         1.2.3.5

Disable masquerading for packets sent from the local network (~loc) to the remote subnet (~vpn):

#ACTION         SOURCE              DEST
SNAT(1.2.3.4)   192.168.1.0/24      eth0:!192.168.3.0/24

Describe the policy to allow "vpn" connection to the local loc zone:

#SOURCE     DEST        POLICY          LOGLEVEL
phone       net         DROP
vpn         loc         ACCEPT
loc         all         ACCEPT
fw          all         ACCEPT
net         all         DROP
all         all         REJECT          info

Example of traffic management

You have a 5 Mbit channel that you want to split as follows:

• SIP from the Internet, 256Kbit guaranteed and maximum, maximum priority
• SIP through a 1 Mbit tunnel, guaranteed and maximum, maximum priority
• RDP through a 1 Mbit tunnel guaranteed and the entire channel minus SIP maximum (5Mbit-1Mbit-256Kbit), normal priority
• http traffic with low priority, 256 Kbit guaranteed and the entire channel minus the SIP maximum
• ftp traffic with high priority, 256 Kbit guaranteed and the entire channel minus the SIP maximum
• regular priority for all other traffic, 256 Kbit guaranteed and the entire channel minus SIP maximum

Set the width of the incoming and of the outgoing channels:

#NUMBER:        IN-BANDWITH     OUT-BANDWIDTH
eth0            -               5mbit
eth1            -               5mbit

Define traffic classes. Since eth0 handles the Internet connection, it must be referred to for all outcoming traffic, while eth1 is used for local connections and, therefore, all incoming traffic relates to it.

#INTERFACE      MARK        RATE        CEIL        PRIO
# INBOUND
eth1            1           256kbit     256kbit     1
eth1            2           1mbit       1mbit       1
eth1            3           1mbit       3768kbit    3
eth1            4           256kbit     3768kbit    2
eth1            5           256kbit     3768kbit    4
eth1            256         256kbit     3768kbit    3

# OUTBOUND
eth1            1           256kbit     256kbit     1
eth1            2           1mbit       1mbit       1
eth1            3           1mbit       3768kbit    3
eth1            4           256kbit     3768kbit    2
eth1            5           256kbit     3768kbit    4
eth1            256         256kbit     3768kbit    3

Define the rules for the traffic to be assigned to a particular class:

#MARK       SOURCE          DEST            PROTO   DEST        SOURCE      USER    TEST    LENGTH  TOS     CONNBYTES   HELPER
# SIP internet
MARK(1)     0.0.0.0/24      0.0.0.0/24      udp     5060
MARK(1)     0.0.0.0/24      0.0.0.0/24      udp     -           5060
MARK(1)     0.0.0.0/24      0.0.0.0/24      all     -           -           -       -       -       -       -           sip
# SIP tunnel
MARK(2)     192.168.3.0/24  192.168.1.0/24  udp     5060
MARK(2)     192.168.1.0/24  192.168.3.0/24  udp     5060
MARK(2)     192.168.3.0/24  192.168.1.0/24  udp     -           5060
MARK(2)     192.168.1.0/24  192.168.3.0/24  udp     -           5060
MARK(2)     192.168.3.0/24  192.168.1.0/24  all     -           -           -       -       -       -       -           sip
MARK(2)     192.168.1.0/24  192.168.3.0/24  all     -           -           -       -       -       -       -           sip
# RDP tunnel
MARK(3)     192.168.3.0/24  192.168.1.0/24  tcp     3389
MARK(3)     192.168.1.0/24  192.168.3.0/24  tcp     3389
MARK(3)     192.168.3.0/24  192.168.1.0/24  tcp     -           3389
MARK(3)     192.168.1.0/24  192.168.3.0/24  tcp     -           3389
# high priority FTP
MARK(4)     0.0.0.0/24      0.0.0.0/24      all     -           -           -       -       -       -       -           ftp
# low priority http,https
MARK(5)     0.0.0.0/24      0.0.0.0/24      tcp     http,https

There is something special in this configuration: since all classes are directly subordinated to the root discipline, RDP and http (for instance) together may take the entire channel. If you do not want the channel allocated for sip traffic to deal with other traffic, use a hierarchical structure similar to this one:

In use this classification, you have to specify the "classify" option for each interface:

#INTERFACE      IN_BANDWITH     OUT_BANDWIDTH       OPTIONS
eth0            -               5mbit               classify
eth1            -               5mbit               classify

Let's modify the traffic classes according to the structure presented above:

#INTERFACE      MARK        RATE        CEIL        PRIO
# SIP
1:10            -           1256kbit    1256kbit    1
eth1:10:101     -           256kbit     256kbit     1
eth1:10:102     -           1mbit       1mbit       1

# OTHER
1:20            -           3768kbit    3768kbit    2
eth1:20:201     -           1mbit       3768kbit    3
eth1:20:202     -           256kbit     3768kbit    2
eth1:20:203     -           256kbit     3768kbit    4
eth1:20:204     -           256kbit     3768kbit    3

# OUTBOUND
2:30            -           1256kbit    1256kbit    1
eth0:30:301     -           256kbit     256kbit     1
eth0:30:302     -           1mbit       1mbit       1

# OTHER
2:40            -           3768kbit    3768kbit    2
eth0:40:401     -           1mbit       3768kbit    3
eth0:40:402     -           256kbit     3768kbit    2
eth0:40:403     -           256kbit     3768kbit    4
eth0:40:404     -           256kbit     3768kbit    3

Redefine the rules for traffic to be assigned to a class:

#MARK               SOURCE          DEST            PROTO   DEST        SOURCE  USER    TEST    LENGTH  TOS   CONNBYTES HELPER
# SIP internet
CLASSIFY(10:101)    0.0.0.0/24      0.0.0.0/24      udp     5060
CLASSIFY(10:101)    0.0.0.0/24      0.0.0.0/24      udp     -           5060
CLASSIFY(10:101)    0.0.0.0/24      0.0.0.0/24      all     -           -       -       -       -       -     -         sip
CLASSIFY(30:301)    0.0.0.0/24      0.0.0.0/24      udp     5060
CLASSIFY(30:301)    0.0.0.0/24      0.0.0.0/24      udp     -           5060
CLASSIFY(30:301)    0.0.0.0/24      0.0.0.0/24      all     -           -       -       -       -       -     -         sip

# SIP tunnel
CLASSIFY(10:102)    192.168.3.0/24  192.168.1.0/24  udp     5060
CLASSIFY(30:302)    192.168.1.0/24  192.168.3.0/24  udp     5060
CLASSIFY(10:102)    192.168.3.0/24  192.168.1.0/24  udp     -           5060
CLASSIFY(30:302)    192.168.1.0/24  192.168.3.0/24  udp     -           5060
CLASSIFY(10:102)    192.168.3.0/24  192.168.1.0/24  all     -           -       -       -       -       -     -         sip
CLASSIFY(10:302)    192.168.1.0/24  192.168.3.0/24  all     -           -       -       -       -       -     -         sip
# RDP tunnel
CLASSIFY(20:201)    192.168.3.0/24  192.168.1.0/24  tcp     3389
CLASSIFY(40:401)    192.168.1.0/24  192.168.3.0/24  tcp     3389
CLASSIFY(20:201)    192.168.3.0/24  192.168.1.0/24  tcp     -           3389
CLASSIFY(40:401)    192.168.1.0/24  192.168.3.0/24  tcp     -           3389
# high priority FTP
CLASSIFY(20:203)    0.0.0.0/24      0.0.0.0/24      all     -           -       -       -       -       -     -         ftp
CLASSIFY(40:403)    0.0.0.0/24      0.0.0.0/24      all     -           -       -       -       -       -     -         ftp
# low priority http,https
CLASSIFY(20:204)    0.0.0.0/24      0.0.0.0/24      tcp     http,https
CLASSIFY(40:404)    0.0.0.0/24      0.0.0.0/24      tcp     http,https