Shorewall

Shorewall

Shorewall is the default firewall management tool in Calculate Linux. Shorewall, or more accurately 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.

Shorewall is not a daemon: it only operates when you need it. The rules are stored in text files. At startup, Shorewall reads its configuration files and converts them into a format accepted by ipchains/iptables. The firewall configuration is then effective until the operating system is restarted.

App package

Shorewall is provided with Calculate Linux Desktop and Calculate Directory Server. If you have another CL on board, you will have to install it first:

emerge shorewall

If you also need examples and documentation, turn on the doc USE flag before installing Shorewall.

To benefit from extended functionality, you can install:

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

Firewall settings

  • Zones Shorewall represents the network in which it operates as consisting a set of zones. The first thing to do to configurate it is thus to define one or more zones in /etc/shorewall / zones . Zones are IPs of hosts, subnets, or incoming/outgoing packets for a specific interface. They can refer to an external or an internal network or to a DMZ.
  • 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 of the zone description is important, since it is in this order that the "iptables" chains will be called, checking packets sent from one zone to another. Which means that, when a packet addressed to the firewall arrives, it is first checked for belonging to the "net" zone, and then to the "loc" zone. This rule is important for embedded zones. For example, you can create a "phone" zone inside the "loc" zone. "phone" would be constituted by several IP addresses from the "loc" zone. That is, if you describe first the "loc" zone and then the "phone" zone, the policy for "phone" will never be applied, because the relevant traffic will be retained in "loc" strings. This problem can be solved by defining the "phone" zone as a "loc" subzone ("phone: loc ipv4").

Here is a configuration example for two network cards:

  • the router ("fw") is named firewall ,
  • the Internet ("net") uses ipv4,
  • the local network ("loc") uses ipv4.

/etc/shorewall/zones

#ZONE   #TYPE
fw      firewall
net     ipv4
loc     ipv4

Run man shorewall-zones to learn more.

Linking the interface to a specific zone

To link the interface to a zone, use the /etc/shorewall/interfaces file. Here you can also specify which filters should handle 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.

Let's edit this file so that eth0 provides the Internet connection ("net"), while eth1 gives access to the local network ("loc"). "tcpflags", "routefilter", "nosmurfs", "logmartians" are filters for the incoming traffic.

  • tcpflags are packets fetched via the relevant interface, checked for incorrect TCP flags combinations.
  • 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.

/etc/shorewall/interfaces

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

Run man shorewall-interfaces to learn more about editing this file.

Linking IPs to a specific zone

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

Below is an example of defining a "vpn" zone. The current gateway establishes a tunnel with another gateway that is connected to segment 10.0.0.0/24:

/etc/shorewall/hosts

#ZONE       HOSTS
vpn         eth0:10.0.0.0/24

Let us allocate a separate "phone" zone to the phone IPs (192.168.0.60 to 192.168.0.80). This can be convenient for access managing policies, not exceptions.

/etc/shorewall/hosts

#ZONE       HOSTS
phone       eth1:192.168.0.60-192.168.0.80

To learn more about this configuration file, run 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. The rule is defined as follows: source zone (SOURCE), destination zone (DEST), default rule (POLICY) (DROP, ACCEPT, REJECT) and, if applies, logging level (for example, 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

/etc/shorewall/policy

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

To learn more about this, run 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 specify it (INTERFACE:DEST), along with the sub-net to which the masquerading policy will be applied (SOURCE) and the outgoing address (ADDRESS) for SNAT. If the outgoing address is not specified, then the dynamic NAT will be used.

For example, let's make to use SNAT (24.56.78.21) for all packets going to eth0 from our internal network (192.168.0.0/24).

/etc/shorewall/snat

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

If necessary, you can exclude NAT when sending packets to some subnets, for example, for ipsec tunnel configuration.

Let's disable NAT when sending a packet to the subnet 192.168.2.0/24:

/etc/shorewall/snat

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

To learn more about this configuration file, run 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.

It contains three sections: RELATED, ESTABLISHED, NEW, which correspond to the connection status conditions. 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

/etc/shorewall/rules

#ACTION     SOURCE                          DEST
REJECT      loc:10.0.0.100-10.0.0.254       net

Forward port (DNAT) 80

/etc/shorewall/rules

#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.
Add the routeback option for the "loc" network in "interfaces", thus allowing the router to forward packets from a local network to another local network.

/etc/shorewall/rules

#ACTION     SOURCE      DEST        PROTO
loc         eth1        detect      tcpflags,routeback

Add the SNAT rule in "masq" so that the packet for 10.0.0.5 was sent from the IP gateway (10.0.0.1 is the internal IP address of the gateway).

/etc/shorewall/rules

#ACTION       SOURCE    DEST
eth1:10.0.0.5 eth1      10.0.0.1

Add DNAT to the rule added as shown above to "rules" for all LAN packets to be sent to 10.0.0.5 (the external IP of the gateway, 1.2.3.4 is to be put in ORIGINAL DEST).

/etc/shorewall/rules

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

Forwarding port 222 to 22

/etc/shorewall/rules

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

Forward LDAP port

For instance, to allow the online replication of unix, samba and mail services on the Calculate Directory Server:

/etc/shorewall/rules

#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

/usr/share/shorewall/macro.HTTP

#ACTION     SOURCE      DEST        PROTO       DPORT
PARAM       -           -           tcp         80

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

/etc/shorewall/rules

#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.

Example Description
dmz:192.168.2.2 node 192.168.2.2 in DMZ zone
net:155.186.235.0/24 subnet 155.186.235.0/24 on the Internet
loc:192.168.1.1,192.168.1.2 nodes 192.168.1.1 and 192.168.1.2 in local network
loc:~00-A0-C9-15-39-78 node in the local network with MAC address 00: A0: C9: 15: 39: 78
net:192.0.2.11-192.0.2.17 nodes from 192.0.2.11 to 192.0.2.17 on the Internet
net:!192.0.2.11-192.0.2.17 all nodes on the Internet, with the exception of those from 192.0.2.11 to 192.0.2.17
net:155.186.235.0/24!155.186.235.16/28 subnet 155.186.235.0/24 on the Internet, with the exception of 155.186.235.16/28

To learn more about this configuration file, run 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 includes the tunnel type (TYPE), the zone tunnel traffic comes from (ZONE) and the remote gateway address (GATEWAY).

As an example, let us define a IPSEC tunnel (ESP) between the current gateway and the remote (4.33.99.124) one:

/etc/shorewall/tunnels

#TYPE           ZONE        GATEWAY
ipsec:esp       net         4.33.99.124

To learn more about how to configure this, run man shorewall-tunnels.

Add Shorewall to autostart

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

rc-update add shorewall boot

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.

The size of the incoming traffic cannot be control with the Internet being what it is now. 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 is mainly based on the TCP/IP protocol, which has some 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. Note that it is impossible to manage incoming traffic, since it has already been received, but you can specify the maximum amount of traffic to receive. All packets exceeding this amount will be discarded . If you do not want to reset the traffic, set this 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. If the outgoing traffic exceeds the maximum value, it will be reset .

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 an example of setting up a 10 Mbit channel on a gateway (incoming traffic from the Internet is managed as outgoing to the local network):

/etc/shorewall/tcdevices

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

Run man shorewall-tcdevices to learn more about editing this file.

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 mark will be used when editing the rules ("tcrules") that define the classes traffic belongs to. The guaranteed and desired bandwidth can be specified as an absolute value or as a part of the full bandwidth assigned to the interface (for instance, 2 * full / 3, or 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] - classify traffic based on TOS.
  • tos-tosname - another TOS classification based on five standard values
  • tcp-ack - for detection of tcp ask packets that are under 64 bytes in size
  • pfifo - 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 traffic with tos byte 68/b8 (EF and AFF3-1 traffic for VOIP devices)
  • 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.

/etc/shorewall/tcclasses

#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 editing this file, run man shorewall-tcclasses.

Traffic marking configuration

Traffic marks can be configured by editing the "/etc/shorewall/mangle" file. 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 stands for the process owner that generated the packet (only makes sense for traffic originating from the firewall)
  • TEST stands for the defined marker.
  • LENGTH stands for the packet size.
  • TOS is the value of the TOS byte.
  • CONNBYTES stands for the range of forwarded connection data
  • HELPER stands for the Netfiler helper module, to define, for instance, ftp, sip, amanda, etc.

The mark is defined as follows:

  • "MARK (value) [: {C|F|P|T|CF|CP|CT}]" "F" - marking in the FORWARD chain "P" - marking in the PREROUTING chain "T "- marking in the POSTROUTING chain " CF "- connection marked in the FORWARD chain " CP "- connection marked in the PREROUTING chain " CT "- connection 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) with target address 155.186.235.151, not created in the firewall, must be marked as 1.
  • All SSH packets originating from 192.168.1.0/24 and designed for 155.186.235.151 must be marked as 2.
  • Mark all P2P packets as 4.

/etc/shorewall/mangle

#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 shorewall configuration, read man shorewall-tcrules.

Configuration examples

Gateway configuration

Suppose you have the network described below:

Example of gateway configuration

  • the internal network hosts have IPs 192.168.1.0/24
  • a Calculate Directory Server connected to the internal network via the eth1 interface with installed IP 192.168.1.1 and having an Internet connection via the eth0 interface with installed IP 1.2.3.4 (gateway)
  • a mail server is provided by the local network (IP 192.168.1.10

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

/etc/shorewall/zones

#ZONE       TYPE
fw          firewall
net         ipv4
loc         ipv4

Now you have to specify that the 'net' zone is managed via the eth0 interface, while the 'loc' zone is managed via the 'eth1' interface. Incoming traffic on both interfaces will be filtered by: "tcpflags", "routefilter", "nosmurfs", "logmartians":

/etc/shorewall/interfaces

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

Describe the default rules for traffic passing through the gateway: the local network ("loc") and the gateway ("$ FW") are allowed to access all zones, the packets from the network ("net") are discarded, the rest is subject to the REJECT rule with logging:

/etc/shorewall/policy

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

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

/etc/shorewall/snat

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

The gateway providing access to the Internet from LAN is ready. Now add a few rules:

  • allow gateway pings from the Internet
  • allow ssh connection with the gateway from the Internet
  • prohibit Internet access from the 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

/etc/shorewall/rules

?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:

/etc/shorewall/shorewall.conf

STARTUP_ENABLED=Yes

Adding IP telephony

Edit the network of the previous example by adding phone IPs to it:

Adding IP telephony

  • the phones are connected to the main network and their IP addresses are ranged 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. The "phone" zone must be imperatively declared before the "loc" zone:

/etc/shorewall/zones

#ZONE       TYPE
fw          firewall
net         ipv4
phone       ipv4
loc         ipv4

Group the phones from the "loc" zone in the "phone" zone:

/etc/shorewall/hosts

#ZONE       HOST
phone       eth1:192.168.1.70-192.168.1.99

Define a policy forbidding the phones ("phone") access to the Internet ("net"):

/etc/shorewall/policy

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

Forward SIP and IAX ports to 192.168.1.10:

/etc/shorewall/rules

?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 example above according to the screenshot (adding a remote subnet):

IPSEC tunnelling

  • The gateway establishes an ipsec tunnel with a remote gateway over the Internet by connecting segment 192.168.3.0/24
  • The remote gateway has IP 1.2.3.5.

Add the "vpn" zone for the remote subnet:

/etc/shorewall/zones

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

Define the "vpn" zone (packets coming to eth0 and located in the 192.168.3.0/24 sub-net):

/etc/shorewall/hosts

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

Describe the tunnel: ipsec via the "net" zone, the IP address of the remote gateway to be specified:

/etc/shorewall/tunnels

#TYPE      ZONE        GATEWAY          GATEWAY ZONE
ipsec      net         1.2.3.5

Disable masquerading for packets sent from the local network ("loc") to a remote sub-net ("vpn"):

/etc/shorewall/snat

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

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

/etc/shorewall/policy

#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

We have a 5 Mbit channel and want to divide it in the following way:

  • 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:

/etc/shorewall/tcdevices

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

Define traffic classes. Since eth0 is for the Internet connection, it controls the outgoing traffic, while eth1 controls the incoming traffic as it is for the local network.

/etc/shorewall/tcclasses

#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:

/etc/shorewall/mangle

#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

Note in the configuration above that, since all classes are subordinated directly to the root discipline, then in the absence of sip traffic, RDP and HTTP (for example) can take the whole channel together. If you need the channel allocated for sip traffic not to deal with other traffic, use a hierarchy like the one below:

Example of traffic management

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

/etc/shorewall/tcdevices

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

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

/etc/shorewall/tcclasses

#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:

/etc/shorewall/mangle

#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