shorewall-secmarks

title: shorewall-secmarks(5)

summary: Shorewall file

text:
# shorewall-secmarks(5)

## NAME
secmarks - Shorewall file

## SYNOPSIS
/etc/shorewall[6]/secmarks

## DESCRIPTION

Important

Unlike rules in the shorewall-rules[1](5) file, evaluation of rules in this file will continue after a match. So the final secmark for each packet will be the one assigned by the LAST rule that matches.

The secmarks file is used to associate an SELinux context with packets. It was added in Shorewall version 4.4.13.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

SECMARK - {SAVE|RESTORE|context|?COMMENT comment}

SAVE

If an SELinux context is associated with the packet, the context is saved in the connection. Normally, the remaining columns should be left blank.

RESTORE

If an SELinux context is not currently associated with the packet, then the saved context (if any) is associated with the packet. Normally, the remaining columns should be left blank.

context

An SELinux context.

?COMMENT

The remainder of the line is treated as a comment which is attached to subsequent rules until another ?COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word ?COMMENT.

CHAIN - {P|I|F|O|T}[:{N|I|U|IU|NI|NU|NIU|NUI:E|ER}]

This column determines the CHAIN where the SELinux context is to be applied: P - PREROUTING

I - INPUT

F - FORWARD

O - OUTPUT

T - POSTROUTING

It may be optionally followed by a colon and an indication of the Netfilter connection state(s) at which the context is to be applied: :N - NEW connection

:I - INVALID connection

:NI - NEW or INVALID connection

:E - ESTABLISHED connection

:ER - ESTABLISHED or RELATED connection

Beginning with Shorewall 4.5.10, the following additional options are available :U - UNTRACKED connection

:IU - INVALID or UNTRACKED connection

:NU - NEW or UNTRACKED connection

:NIU - NEW, INVALID or UNTRACKED connection.

This column was formerly labelled CHAIN:STATE.

SOURCE - {-interface|[interface:]address-or-range[,address-or-range]...}[exclusion]

May be:

1.An interface name - matches traffic entering the firewall on the specified interface. May not be used in classify rules or in rules using the T in the CHAIN column.

2.A comma-separated list of host or network IP addresses or MAC addresses.

3.An interface name followed by a colon (":") followed by a comma-separated list of host or network IP addresses or MAC addresses.

MAC addresses must be prefixed with "~" and use "-" as a separator.

Example: ~00-A0-C9-15-39-78

You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion[2](5)).

Addresses may be specified using an ipset name preceded by '+'.

DEST - {-|{interface|[interface:]address-or-range[,address-or-range]...}[exclusion]

May be:

1.An interface name. May not be used in the PREROUTING or INPUT chains. The interface name may be optionally followed by a colon (":") and an IP address list.

2.A comma-separated list of host or network IP addresses. The list may include ip address ranges if your kernel and iptables include iprange support.

You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion[2](5)).

Addresses may be specified using an ipset name preceded by '+'.

PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]

See shorewall-rules(5)[1] for details. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

DPORT - [-|port-name-number-or-range[,port-name-number-or-range]...]

Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See https://shorewall.org/configuration_file_basics.htm#ICMP[3]. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed.

This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is suggested that this field contain "-"

This column was formerly labelled DEST PORT(S).

SPORT - [-|port-name-number-or-range[,port-name-number-or-range]...]

Optional source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges. This column was formerly labelled SOURCE PORT(S).

USER - [!][user-name-or-number][:group-name-or-number]

This optional column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given).

Examples:

joe

program must be run by joe

:kids

program must be run by a member of the 'kids' group

!:kids

program must not be run by a member of the 'kids' group

MARK - [!]value[/mask][:C]

Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field.

!

Inverts the test (not equal)

value

Value of the packet or connection mark.

mask

A mask to be applied to the mark before testing.

:C

Designates a connection mark. If omitted, the packet mark's value is tested.

## EXAMPLE
Mark the first incoming packet of a connection on the loopback interface and destined for address 127.0.0.1 and tcp port 3306 with context system_u:object_r:mysqld_t:s0 and save that context in the conntrack table. On subsequent input packets in the connection, set the context from the conntrack table.

/etc/shorewall/interfaces:

```
#ZONE      INTERFACE      BROADCAST       OPTIONS
-          lo             -               ignore
```

/etc/shorewall/secmarks:

```
#SECMARK                              CHAIN      SOURCE  DEST       PROTO   DPORT      SPORT       USER      MARK
system_u:object_r:mysqld_packet_t:s0  I:N        lo      127.0.0.1  tcp     3306
SAVE                                  I:N        lo      127.0.0.1  tcp     3306
RESTORE                               I:ER
```

## FILES
/etc/shorewall/secmarks

/etc/shorewall6/secmarks

## SEE ALSO
http://james-morris.livejournal.com/11010.html

https://shorewall.org/configuration_file_basics.htm#Pairs[4]

shorewall(8)

## NOTES
1.

shorewall-rules

https://shorewall.org/manpages/shorewall-rules.html

2.

shorewall-exclusion

https://shorewall.org/manpages/shorewall-exclusion.html

3.

https://shorewall.org/configuration_file_basics.htm#ICMP

https://shorewall.org/configuration_file_basics.htm#ICMP

4.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-snat

package: shorewall

title: shorewall-snat(5)

text:
# shorewall-snat(5)

## NAME
snat - Shorewall SNAT/Masquerade definition file

## SYNOPSIS
/etc/shorewall[6]/snat

## DESCRIPTION
This file is used to define dynamic NAT (Masquerading) and to define Source NAT (SNAT). It superseded shorewall-masq[1](5) in Shorewall 5.0.14.

Warning

The entries in this file are order-sensitive. The first entry that matches a particular connection will be the one that is used.

Warning

If you have more than one ISP link, adding entries to this file will not force connections to go out through a particular link. You must use entries in shorewall-rtrules[2](5) or PREROUTING entries in shorewall-mangle[3](5) to do that.

Beginning with Shorewall 5.2.6, the snat file supports two different formats:

1.The SPORT (source port) column is omitted. This is the default unless a "?FORMAT 2" compiler directive is included.

2.The SPORT column immediately follows the DPORT column.

The columns in the file are as follows.

ACTION

Defines the type of rule to generate. Beginning with Shorewall 5.1.9, with the exception of NFLOG and ULOG, the action may be followed by a colon (":") and a log level (see shorewall-logging(5)[4]). Choices for ACTION are:

action[+][(parameter,...)][:level]

where action is an action declared in shorewall-actions(5)[5] with the nat option. See https://shorewall.org/Actions.html[6] for further information.

CONTINUE[+]:level

Causes matching packets to be exempted from any following rules in the file.

LOG:level

Added in Shorewall 5.1.9. Simply log the packet and continue with the next rule.

MASQUERADE[+][([lowport[-highport]][random])][:level]

Causes matching outgoing packages to have their source IP address set to the primary IP address of the interface specified in the DEST column. if lowport-highport is given, that port range will be used to assign a source port. If only lowport is given, that port will be assigned, if possible. If option random is used then port mapping will be randomized. MASQUERADE should only be used when the DEST interface has a dynamic IP address. Otherwise, SNAT should be used and should specify the interface's static address.

NFLOG[(nflog-parameters)]

Added in Shorewall 5.1.9. Queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See shorewall-logging(5)[4]. The nflog-parameters are a comma-separated list of up to 3 numbers:

•The first number specifies the netlink group (0-65535). If omitted (e.g., NFLOG(,0,10)) then a value of 0 is assumed.

•The second number specifies the maximum number of bytes to copy. If omitted, 0 (no limit) is assumed.

•The third number specifies the number of log messages that should be buffered in the kernel before they are sent to user space. The default is 1.

NFLOG is similar to LOG:NFLOG[(nflog-parameters)], except that the log level is not changed when this ACTION is used in an action or macro body and the invocation of that action or macro specifies a log level.

SNAT[+]([address-or-address-range][:lowport[-highport]][:random][:persistent]|detect)[:level]

If you specify an address here, matching packets will have their source address set to that address. If ADD_SNAT_ALIASES is set to Yes or yes in shorewall.conf[7](5) then Shorewall will automatically add this address to the INTERFACE named in the first column (IPv4 only). You may also specify a range of up to 256 IP addresses if you want the SNAT address to be assigned from that range in a round-robin fashion by connection. The range is specified by first.ip.in.range-last.ip.in.range. You may follow the port range with :random in which case assignment of ports from the list will be random. random may also be specified by itself in this column in which case random local port assignments are made for the outgoing connections.

Example: 206.124.146.177-206.124.146.180

You may follow the port range (or :random) with :persistent. This is only useful when an address range is specified and causes a client to be given the same source/destination IP pair.

You may also use the special value detect which causes Shorewall to determine the IP addresses configured on the interface named in the DEST column and substitute them in this column.

DNS Names names are not allowed.

Normally, Netfilter will attempt to retain the source port number. You may cause netfilter to remap the source port by following an address or range (if any) by ":" and a port range with the format lowport-highport. If this is done, you must specify "tcp", "udp", "dccp" or "stcp" in the PROTO column.

Examples:

```
        192.0.2.4:5000-6000

        :4000-5000
```

You may also specify a single port number, which will be assigned to the outgoing connection, if possible.

ULOG[(ulog-parameters)]

IPv4 only. Added in Shorewall 5.1.9. Queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See shorewall-logging(5)[4]. Similar to LOG:ULOG[(ulog-parameters)], except that the log level is not changed when this ACTION is used in an action or macro body and the invocation of that action or macro specifies a log level.

Normally Masq/SNAT rules are evaluated after those for one-to-one NAT (defined in shorewall-nat[8](5)). If you want the rule to be applied before one-to-one NAT rules, follow the action name with "+": This feature should only be required if you need to insert rules in this file that preempt entries in shorewall-nat[8](5).

SOURCE (Optional) - [interface|address[,address...][exclusion]]

Set of hosts that you wish to masquerade. You can specify this as an address (net or host) or as an interface. Unless you want to perform SNAT in the INPUT chain (see DEST below), if you give the name of an interface (deprecated), the interface must be up before you start the firewall and the Shorewall rules compiler will warn you of that fact. (Shorewall will use your main routing table to determine the appropriate addresses to masquerade). The preferred way to specify the SOURCE is to supply one or more host or network addresses separated by comma. You may use ipset names preceded by a plus sign (+) to specify a set of hosts.

DEST - {interface[:digit][,interface[:digit]]...|$FW}[:[dest-address[,dest-address]...[exclusion]]

Outgoing interfaces and destination networks. Multiple interfaces may be listed when the ACTION is MASQUERADE, but this is usually just your internet interface. If ADD_SNAT_ALIASES=Yes in shorewall.conf[7](5), you may add ":" and a digit to indicate that you want the alias added with that name (e.g., eth0:0). This will allow the alias to be displayed with ifconfig. That is the only use for the alias name; it may not appear in any other place in your Shorewall configuration. Beginning with Shorewall 5.1.12, SNAT may be performed in the nat table's INPUT chain by specifying $FW rather than one or more interfaces.

Each interface must match an entry in shorewall-interfaces[9](5). Shorewall allows loose matches to wildcard entries in shorewall-interfaces[9](5). For example, ppp0 in this file will match a shorewall-interfaces[9](5) entry that defines ppp+.

Where more that one internet provider share a single interface[10], the provider is specified by including the provider name or number in parentheses:

```
        eth0(Avvanta)
```

In that case, you will want to specify the interface's address for that provider as the SNAT parameter.

The interface may be qualified by adding the character ":" followed by a comma-separated list of destination host or subnet addresses to indicate that you only want to change the source IP address for packets being sent to those particular destinations. Exclusion is allowed (see shorewall-exclusion[11](5)) as are ipset names preceded by a plus sign '+';

If you wish to inhibit the action of ADD_SNAT_ALIASES for this entry then include the ":" but omit the digit:

```
        eth0(Avvanta):

        eth2::192.0.2.32/27
```

Comments may be attached to Netfilter rules generated from entries in this file through the use of ?COMMENT lines. These lines begin with ?COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another ?COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line containing only ?COMMENT.

PROTO (Optional) - {-|[!]{protocol-name|protocol-number}[,...]|+ipset}

If you wish to restrict this entry to a particular protocol then enter the protocol name (from protocols(5)) or number here. See shorewall-rules(5)[12] for details. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

Beginning with Shorewall 4.6.0, an ipset name can be specified in this column. This is intended to be used with bitmap:port ipsets.

{PORT|DPORT} (Optional) - {-|[!]port-name-or-number[,port-name-or-number]...|+ipset}

The column was renamed to DPORT in Shorewall 5.2.6. Beginning with that release, both PORT and DPORT are accepted in the alternative input format, If the PROTO column specifies TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136) then you may list one or more port numbers (or names from services(5)) or port ranges separated by commas.

Port ranges are of the form lowport:highport.

Beginning with Shorewall 4.6.0, an ipset name can be specified in this column. This is intended to be used with bitmap:port ipsets.

SPORT {-|[!]port-name-or-number[,port-name-or-number]...|+ipset}

FORMAT 2 only. If the PROTO column specifies TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136) then you may list one or more port numbers (or names from services(5)) or port ranges separated by commas.

Port ranges are of the form lowport:highport.

An ipset name can be specified in this column. This is intended to be used with bitmap:port ipsets.

IPSEC (Optional) - [option[,option]...]

If you specify a value other than "-" in this column, you must be running kernel 2.6 and your kernel and iptables must include policy match support. Comma-separated list of options from the following. Only packets that will be encrypted via an SA that matches these options will have their source address changed.

reqid=number

where number is specified using setkey(8) using the 'unique:number option for the SPD level.

spi=<number>

where number is the SPI of the SA used to encrypt/decrypt packets.

proto=ah|esp|ipcomp

IPSEC Encapsulation Protocol

mss=number

sets the MSS field in TCP packets

mode=transport|tunnel

IPSEC mode

tunnel-src=address[/mask]

only available with mode=tunnel

tunnel-dst=address[/mask]

only available with mode=tunnel

strict

Means that packets must match all rules.

next

Separates rules; can only be used with strict

yes

When used by itself, causes all traffic that will be encrypted/encapsulated to match the rule.

MARK - [!]value[/mask][:C]

Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field.

!

Inverts the test (not equal)

value

Value of the packet or connection mark.

mask

A mask to be applied to the mark before testing.

:C

Designates a connection mark. If omitted, the packet mark's value is tested.

USER (Optional) - [!][user-name-or-number][:group-name-or-number][+program-name]

This column was formerly labelled USER/GROUP. Only locally-generated connections will match if this column is non-empty.

When this column is non-empty, the rule matches only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given).

Examples:

joe

program must be run by joe

:kids

program must be run by a member of the 'kids' group

!:kids

program must not be run by a member of the 'kids' group

+upnpd

\#program named upnpd

Important

The ability to specify a program name was removed from Netfilter in kernel version 2.6.14.

SWITCH - [!]switch-name[={0|1}]

Added in Shorewall 4.5.1 and allows enabling and disabling the rule without requiring shorewall restart. The rule is enabled if the value stored in /proc/net/nf_condition/switch-name is 1. The rule is disabled if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0.

Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '@...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length.

Switches are normally off. To turn a switch on:

echo 1 >

/proc/net/nf_condition/switch-name

To turn it off again: echo 0 >

/proc/net/nf_condition/switch-name

Switch settings are retained over shorewall restart. Beginning with Shorewall 4.5.10, when the switch-name is followed by =0 or =1, then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting.

ORIGDEST - [-|address[,address]...[exclusion]|exclusion]

(Optional) Added in Shorewall 4.5.6. This column may be included and may contain one or more addresses (host or network) separated by commas. Address ranges are not allowed. When this column is supplied, rules are generated that require that the original destination address matches one of the listed addresses. It is useful for specifying that SNAT should occur only for connections that were acted on by a DNAT when they entered the firewall. This column was formerly labelled ORIGINAL DEST.

PROBABILITY - [probability]

Added in Shorewall 5.0.0. When non-empty, requires the Statistics Match capability in your kernel and ip6tables and causes the rule to match randomly but with the given probability. The probability is a number 0 < probability <= 1 and may be expressed at up to 8 decimal points of precision.

## EXAMPLES
IPv4 Example 1:

You have a simple masquerading setup where eth0 connects to a DSL or cable modem and eth1 connects to your local network with subnet 192.168.0.0/24. Your entry in the file will be:

```
        #ACTION    SOURCE              DEST

        MASQUERADE 192.168.0.0/24      eth0
```

IPv4 Example 2:

You add a router to your local network to connect subnet 192.168.1.0/24 which you also want to masquerade. You then add a second entry for eth0 to this file:

```
        #ACTION    SOURCE              DEST

        MASQUERADE 192.168.0.0/24      eth0

        MASQUERADE 192.168.1.0/24      eth0
```

IPv4 Example 3:

You want all outgoing traffic from 192.168.1.0/24 through eth0 to use source address 206.124.146.176 which is NOT the primary address of eth0. You want 206.124.146.176 to be added to eth0 with name eth0:0.

```
        #ACTION                 SOURCE          DEST

        SNAT(206.124.146.176)   192.168.1.0/24  eth0:0
```

IPv4 Example 4:

You want all outgoing SMTP traffic entering the firewall from 172.20.1.0/29 to be sent from eth0 with source IP address 206.124.146.177. You want all other outgoing traffic from 172.20.1.0/29 to be sent from eth0 with source IP address 206.124.146.176.

```
        #INTERFACE   SOURCE           ADDRESS         PROTO   DPORT

        eth0         172.20.1.0/29    206.124.146.177 tcp     smtp

        eth0         172.20.1.0/29    206.124.146.176
```

```
        #ACTION                 SOURCE          DEST        PROTO     PORT

        SNAT(206.124.146.177)   172.20.1.0/29   eth0        tcp       smtp

        SNAT(206.124.146.176)   172.20.1.0/29   eth0
```

Warning

The order of the above two rules is significant!

IPv4 Example 5:

Connections leaving on eth0 and destined to any host defined in the ipset myset should have the source IP address changed to 206.124.146.177.

```
        #ACTION                 SOURCE          DEST

        SNAT(206.124.146.177)   -               eth0:+myset[dst]
```

IPv4 Example 6:

SNAT outgoing connections on eth0 from 192.168.1.0/24 randomly to addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9 (Shorewall 5.0.0 and later).

```
/etc/shorewall/snat:

       #ACTION                 SOURCE          DEST

       SNAT(1.1.1.1)           192.168.1.0/24  eth0  { probability=0.33 }

       SNAT(1.1.1.3)           192.168.1.0/24  eth0  { probability=0.50 }

       SNAT(1.1.1.9)           192.168.1.0/24  eth0
```

IPv6 Example 1:

You have a simple 'masquerading' setup where eth0 connects to a DSL or cable modem and eth1 connects to your local network with subnet 2001:470:b:787::0/64 Your entry in the file will be:

```
        #ACTION      SOURCE                  DEST

        MASQUERADE   2001:470:b:787::0/64    eth0
```

IPv6 Example 2:

Your sit1 interface has two public IP addresses: 2001:470:a:227::1 and 2001:470:b:227::1. You want to use the iptables statistics match to masquerade outgoing connections evenly between these two addresses.

```
/etc/shorewall/snat:

       #ACTION                      SOURCE     DEST

       SNAT(2001:470:a:227::1)      ::/0       sit1              { probability=0.50 }

       SNAT(2001:470:a:227::2)      ::/0       sit
```

## FILES
/etc/shorewall/snat

/etc/shorewall6/snat

## SEE ALSO
https://shorewall.org/configuration_file_basics.htm#Pairs[13]

shorewall(8)

## NOTES
1.

shorewall-masq

https://shorewall.org/manpages/shorewall-masq.html

2.

shorewall-rtrules

https://shorewall.org/manpages/shorewall-rtrules.html

3.

shorewall-mangle

https://shorewall.org/manpages/shorewall-mangle.html

4.

shorewall-logging(5)

https://shorewall.org/manpages/shorewall-logging.html

5.

shorewall-actions(5)

https://shorewall.org/manpages/shorewall-actions.html

6.

https://shorewall.org/Actions.html

https://shorewall.org/Actions.html

7.

shorewall.conf

https://shorewall.org/manpages/shorewall.conf.html

8.

shorewall-nat

https://shorewall.org/manpages/shorewall-nat.html

9.

shorewall-interfaces

https://shorewall.org/manpages/shorewall-interfaces.html

10.

more that one internet provider share a single interface

https://shorewall.org/4.4/MultiISP.html#Shared

11.

shorewall-exclusion

https://shorewall.org/manpages/shorewall-exclusion.html

12.

shorewall-rules(5)

https://shorewall.org/manpages/shorewall-rules.html

13.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-stoppedrules

title: shorewall-stoppedrules(5)

summary: The Shorewall file that governs what traffic flows through the firewall while it is in the \*(Aqstopped\*(Aq state.

text:
# shorewall-stoppedrules(5)

## NAME
stoppedrules - The Shorewall file that governs what traffic flows through the firewall while it is in the 'stopped' state.

## SYNOPSIS
/etc/shorewall[6]/stoppedrules

## DESCRIPTION
This file is used to define the hosts that are accessible when the firewall is stopped or is being stopped.

Warning

Changes to this file do not take effect until after the next shorewall start, shorewall reload, shorewall restart, or shorewall compile command.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

ACTION - ACCEPT|NOTRACK|DROP

Determines the disposition of the packet. ACCEPT means that the packet will be accepted.

NOTRACK indicates that no conntrack entry should be created for the packet. NOTRACK does not imply ACCEPT.

DROP was added in Shorewall 4.6.0 and causes the packet to be dropped in the raw table's PREROUTING chain.

SOURCE - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...]

$FW matches packets originating on the firewall itself, while interface specifies packets arriving on the named interface. This column may also include a comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. Ipsets and exclusion are also supported. When $FW or interface are specified, the list must be preceded by a colon (":").

If left empty or supplied as "-", 0.0.0.0/0 is assumed.

DEST - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...]

$FW matches packets addressed the firewall itself, while interface specifies packets arriving on the named interface. Neither may be specified if the target is NOTRACK or DROP. This column may also include a comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. Ipsets and exclusion are also supported. When $FW or interface are specified, the list must be preceded by a colon (":").

If left empty or supplied as "-", 0.0.0.0/0 is assumed.

PROTO (Optional) – protocol-name-or-number[,...]

Protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

DPORT – service-name/port-number-list

Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. This column was formerly labelled DEST PORT(S).

SPORT – service-name/port-number-list

Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DPORT column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel.

This column was formerly labelled SOURCE PORT(S).

## FILES
/etc/shorewall/stoppedrules

/etc/shorewall6/stoppedrules

## SEE ALSO
https://shorewall.org/starting_and_stopping_shorewall.htm[1]

https://shorewall.org/configuration_file_basics.htm#Pairs[2]

shorewall(8)

## NOTES
1.

https://shorewall.org/starting_and_stopping_shorewall.htm

https://shorewall.org/starting_and_stopping_shorewall.htm

2.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-tcclasses

title: shorewall-tcclasses(5)

text:
# shorewall-tcclasses(5)

## NAME
tcclasses - Shorewall file to define HTB and HFSC classes

## SYNOPSIS
/etc/shorewall[6]/tcclasses

## DESCRIPTION
A note on the rate/bandwidth definitions used in this file:

•don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is NOT.

•you can use one of the following units: kpbs

Kilobytes per second.

mbps

Megabytes per second.

kbit

Kilobits per second.

mbit

Megabits per second.

bps or number

Bytes per second.

•if you want the values to be calculated for you depending on the output bandwidth setting defined for an interface in tcdevices, you can use expressions like the following: full/3

causes the bandwidth to be calculated as 1/3 of the full outgoing speed that is defined.

full*9/10

will set this bandwidth to 9/10 of the full bandwidth

Note that in a sub-class (a class that has a specified parent class), full refers to the RATE or CEIL of the parent class rather than to the OUT-BANDWIDTH of the device.

DO NOT add a unit to the rate if it is calculated !

The columns in the file are as follows.

INTERFACE - interface[[:parent]:class]

Name of interface. You may specify the interface number rather than the interface name. If the classify option is given for the interface in shorewall-tcdevices[1](5), then you must also specify an interface class (an integer that must be unique within classes associated with this interface). If the classify option is not given, you may still specify a class or you may have Shorewall generate a class number from the MARK value. Interface numbers and class numbers are always assumed to be specified in hex and class number 1 is reserved as the root class of the queuing discipline.

You may NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here!

Please note that you can only use interface names in here that have a bandwidth defined in the shorewall-tcdevices[1](5) file.

Normally, all classes defined here are sub-classes of a root class that is implicitly defined from the entry in shorewall-tcdevices[1](5). You can establish a class hierarchy by specifying a parent class -- the number of a class that you have previously defined. The sub-class may borrow unused bandwidth from its parent.

MARK - {-|value[:priority]}

The mark value which is an integer in the range 1-255. You set mark values in the shorewall-mangle[2](5) file, marking the traffic you want to fit in the classes defined in here. You can use the same marks for different interfaces. The priority, if specified, is an integer in the range 1-65535 and determines the relative order in which the tc mark classification filter for this class is to be applied to packets being sent on the interface. Filters are applied in ascending numerical order. If not supplied, the value is derived from the class priority (PRIORITY column value below): (class priority << 8) | 20.

RATE - {-|rate[:dmax[:umax]]}

The minimum bandwidth this class should get, when the traffic load rises. If the sum of the rates in this column exceeds the INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be honored. Similarly, if the sum of the rates of sub-classes of a class exceed the CEIL of the parent class, things don't work well. When using the HFSC queuing discipline, this column specify the real-time (RT) service curve. leaf classes may specify dmax, the maximum delay in milliseconds that the first queued packet for this class should experience. May be expressed as an integer, optionally followed by 'ms' with no intervening white-space (e.g., 10ms).

HFSC leaf classes may also specify umax, the largest packet expected in this class. May be expressed as an integer. The unit of measure is bytes and the integer may be optionally followed by 'b' with no intervening white-space (e.g., 800b). umax may only be given if dmax is also given.

Beginning with Shorewall 4.5.6, HFSC classes may omit this column (e.g, '-' in the column), provided that an lsrate is specified (see CEIL below). These rates are used to arbitrate between classes of the same priority.

CEIL - [lsrate:]rate

The maximum bandwidth this class is allowed to use when the link is idle. Useful if you have traffic which can get full speed when more needed services (e.g. ssh) are not used. You can use the value full in here for setting the maximum bandwidth to the RATE of the parent class, or the OUT-BANDWIDTH of the device if there is no parent class.

Beginning with Shorewall 4.5.6, you can also specify an lsrate (link sharing rate).

PRIORITY - priority

For HTB: The priority in which classes will be serviced by the packet shaping scheduler and also the priority in which bandwidth in excess of the rate will be given to each class. Higher priority classes will experience less delay since they are serviced first. Priority values are serviced in ascending order (e.g. 0 is higher priority than 1).

Classes may be set to the same priority, in which case they will be serviced as equals. For both HTB and HFSC, the priority is used to calculate the priority of following Shorewall-generated classification filters that refer to the class:

•Packet MARK

•tcp-ack and the tos options (see below)

The rules for classes with lower numeric priorities will appear before those with higher numeric priorities.

Beginning with Shorewall 4.5.8, the PRIORITY may be omitted from an HFSC class if you do not use the MARK column or the tcp-ack or tos options. If you use any of those features and omit the PRIORITY, then you must specify a priority along with the MARK or option.

OPTIONS (Optional) - [option[,option]...]

A comma-separated list of options including the following: default

This is the default class for that interface where all traffic should go, that is not classified otherwise.

Note

You must define default for exactly one class per interface.

tos=0xvalue[/0xmask][:priority] (mask defaults to 0xff)

This lets you define a classifier for the given value/mask combination of the IP packet's TOS/Precedence/DiffSrv octet (aka the TOS byte). Beginning with Shorewall 4.5.8, the value/mask may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 15) is used.

tos-tosname[:priority]

Aliases for the following TOS octet value and mask encodings. TOS encodings of the "TOS byte" have been deprecated in favor of diffserve classes, but programs like ssh, rlogin, and ftp still use them. Beginning with Shorewall 4.5.8, the tos-name may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 15) is used.

```
        tos-minimize-delay       0x10/0x10

        tos-maximize-throughput  0x08/0x08

        tos-maximize-reliability 0x04/0x04

        tos-minimize-cost        0x02/0x02

        tos-normal-service       0x00/0x1e
```

Note

Each of these options is only valid for ONE class per interface.

tcp-ack[:priority]

If defined, causes a tc filter to be created that puts all tcp ack packets on that interface that have a size of <=64 Bytes to go in this class. This is useful for speeding up downloads. Please note that the size of the ack packets is limited to 64 bytes because we want only packets WITHOUT payload to match. Beginning with Shorewall 4.5.8, the tcp-ack may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 10) is used.

Note

This option is only valid for ONE class per interface.

occurs=number

Typically used with an IPMARK entry in tcrules. Causes the rule to be replicated for a total of number rules. Each rule has a successively class number and mark value. When 'occurs' is used:

•The associated device may not have the 'classify' option.

•The class may not be the default class.

•The class may not have any 'tos=' options (including 'tcp-ack').

•The class should not specify a MARK value. If one is specified, it will be ignored with a warning message.

The 'RATE' and 'CEIL' parameters apply to each instance of the class. So the total RATE represented by an entry with 'occurs' will be the listed RATE multiplied by number. For additional information, see shorewall-tcrules[3] (5).

flow=keys

Shorewall attaches an SFQ queuing discipline to each leaf HTB class. SFQ ensures that each flow gets equal access to the interface. The default definition of a flow corresponds roughly to a Netfilter connection. So if one internal system is running BitTorrent, for example, it can have lots of 'flows' and can thus take up a larger share of the bandwidth than a system having only a single active connection. The flow classifier (module cls_flow) works around this by letting you define what a 'flow' is. The classifier must be used carefully or it can block off all traffic on an interface! The flow option can be specified for an HTB leaf class (one that has no sub-classes). We recommend that you use the following: Shaping internet-bound traffic:

flow=nfct-src

Shaping traffic bound for your local net:

flow=dst

These will cause a 'flow' to consists of the traffic to/from each internal system. When more than one key is give, they must be enclosed in parenthesis and separated by commas.

To see a list of the possible flow keys, run this command: tc filter add flow help Those that begin with "nfct-" are Netfilter connection tracking fields. As shown above, we recommend flow=nfct-src; that means that we want to use the source IP address before NAT as the key.

pfifo

When specified for a leaf class, the pfifo queuing discipline is applied to the class rather than the sfq queuing discipline.

limit=number

Added in Shorewall 4.4.3. When specified for a leaf class, determines the maximum number of packets that may be queued within the class. The number must be > 2 and <=128. If not specified, the value 127 is assumed.

red=(redoption=value, ...)

Added in Shorewall 4.5.6. When specified on a leaf class, causes the class to use the RED (Random Early Detection) queuing discipline rather than SFQ. See tc-red (8) for additional information. Allowable redoptions are:

min min

Average queue size at which marking becomes a possibility.

max max

At this average queue size, the marking probability is maximal. Must be at least twice min to prevent synchronous retransmits, higher for low min.

probability probability

Maximum probability for marking, specified as a floating point number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%, respectively).

limit limit

Hard limit on the real (not average) queue size in bytes. Further packets are dropped. Should be set higher than max+burst. It is advised to set this a few times higher than max. Shorewall requires that limit be at least twice min.

burst burst

Used for determining how fast the average queue size is influenced by the real queue size. Larger values make the calculation more sluggish, allowing longer bursts of traffic before marking starts. Real life experiments support the following guide‐line: (min+min+max)/(3*avpkt).

avpkt avpkt

Optional. Specified in bytes. Used with burst to determine the time constant for average queue size calculations. 1000 is a good value and is the Shorewall default.

bandwidth bandwidth

Optional. This rate is used for calculating the average queue size after some idle time. Should be set to the bandwidth of your interface. Does not mean that RED will shape for you!

ecn

RED can either 'mark' or 'drop'. Explicit Congestion Notification allows RED to notify remote hosts that their rate exceeds the amount of bandwidth available. Non-ECN capable hosts can only be notified by dropping a packet. If this parameter is specified, packets which indicate that their hosts honor ECN will only be marked and not dropped, unless the queue size hits limit bytes. Recommended.

fq_codel[=(codeloption=value, ...)]

Added in Shorewall 4.5.12. When specified for a leaf class, causes the class to use the FQ_CODEL (Fair-queuing Controlled Delay) queuing discipline rather than SFQ. See tc-fq_codel (8) for additional information. Allowable codeloptions are:

limit

hard limit on the real queue size. When this limit is reached, incoming packets are dropped. If the value is lowered, packets are dropped so that the new limit is met. Default is 1000 packets.

flows

is the number of flows into which the incoming packets are classified. Due to the stochastic nature of hashing, multiple flows may end up being hashed into the same slot. Newer flows have priority over older ones. This parameter can be set only at load time since memory has to be allocated for the hash table. Default value is 1024.

target

is the acceptable minimum standing/persistent queue delay. This minimum delay is identified by tracking the local minimum queue delay that packets experience. Default and recommended value is 5ms.

interval

is used to ensure that the measured minimum delay does not become too stale. The minimum delay must be experienced in the last epoch of length interval. It should be set on the order of the worst-case RTT through the bottleneck to give endpoints sufficient time to react. Default value is 100ms.

quantum

is the number of bytes used as 'deficit' in the fair queuing algorithm. Default is set to 1514 bytes which corresponds to the Ethernet MTU plus the hardware header length of 14 bytes.

ecn | noecn

can be used to mark packets instead of dropping them. If ecn has been enabled, noecn can be used to turn it off and vice-versa. By default, ecn is enabled.

## EXAMPLES
Example 1:

Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. You have 4 classes here, the first you can use for voice over IP traffic, the second interactive traffic (e.g. ssh/telnet but not scp), the third will be for all unclassified traffic, and the forth is for low priority traffic (e.g. peer-to-peer). The voice traffic in the first class will be guaranteed a minimum of 100kbps and always be serviced first (because of the low priority number, giving less delay) and will be granted excess bandwidth (up to 180kbps, the class ceiling) first, before any other traffic. A single VoIP stream, depending upon codecs, after encapsulation, can take up to 80kbps on a PPPoE/DSL link, so we pad a little bit just in case. (TOS byte values 0xb8 and 0x68 are DiffServ classes EF and AFF3-1 respectively and are often used by VOIP devices).

Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP echo traffic if you use the example in tcrules) and any packet with a mark of 2 will be guaranteed 1/4 of the link bandwidth, and may extend up to full speed of the link.

Unclassified traffic and packets marked as 3 will be guaranteed 1/4th of the link bandwidth, and may extend to the full speed of the link.

Packets marked with 4 will be treated as low priority packets. (The tcrules example marks p2p traffic as such.) If the link is congested, they're only guaranteed 1/8th of the speed, and even if the link is empty, can only expand to 80% of link bandwidth just as a precaution in case there are upstream queues we didn't account for. This is the last class to get additional bandwidth and the last to get serviced by the scheduler because of the low priority.

```
        #INTERFACE  MARK  RATE    CEIL      PRIORITY    OPTIONS

        ppp0        1     100kbit 180kbit   1           tos=0x68/0xfc,tos=0xb8/0xfc

        ppp0        2     full/4  full      2           tcp-ack,tos-minimize-delay

        ppp0        3     full/4  full      3           default

        ppp0        4     full/8  full*8/10 4
```

## FILES
/etc/shorewall/tcclasses

/etc/shorewall6/tcclasses

## SEE ALSO
https://shorewall.org/traffic_shaping.htm[4]

https://shorewall.org/configuration_file_basics.htm#Pairs[5]

tc-hfsc(7)

tc-red(8)

shorewall(8)

## NOTES
1.

shorewall-tcdevices

https://shorewall.org/manpages/shorewall-tcdevices.html

2.

shorewall-mangle

https://shorewall.org/manpages/shorewall-mangle.html

3.

shorewall-tcrules

https://shorewall.org/manpages/shorewall-tcrules.html

4.

https://shorewall.org/traffic_shaping.htm

https://shorewall.org/traffic_shaping.htm

5.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-tcdevices

title: shorewall-tcdevices(5)

summary: Shorewall Traffic Shaping Devices file

text:
# shorewall-tcdevices(5)

## NAME
tcdevices - Shorewall Traffic Shaping Devices file

## SYNOPSIS
/etc/shorewall[6]/tcdevices

## DESCRIPTION
Entries in this file define the bandwidth for interfaces on which you want traffic shaping to be enabled.

If you do not plan to use traffic shaping for a device, don't put it in here as it limits the throughput of that device to the limits you set here.

A note on the bandwidth definitions used in this file:

•don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is not.

•you can use one of the following units: kbps

Kilobytes per second.

mbps

Megabytes per second.

kbit

Kilobits per second.

mbit

Megabits per second.

bps or number

Bytes per second.

•Only whole integers are allowed.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

INTERFACE - [number:]interface

Name of interface. Each interface may be listed only once in this file. You may NOT specify the name of an alias (e.g., eth0:0) here; see https://shorewall.org/FAQ.htm#faq18[1] You may NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here!

If the device doesn't exist, a warning message will be issued during "shorewall [re]start" and "shorewall reload" and traffic shaping configuration will be skipped for that device.

Shorewall assigns a sequential interface number to each interface (the first entry in the file is interface 1, the second is interface 2 and so on) You can explicitly specify the interface number by prefixing the interface name with the number and a colon (":"). Example: 1:eth0.

IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]}

The incoming bandwidth of that interface. Please note that you are not able to do traffic shaping on incoming traffic, as the traffic is already received before you could do so. But this allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the packets are dropped. You want this mainly if you have a DSL or Cable connection to avoid queuing at your providers side. If you don't want any traffic to be dropped, set this to a value to zero in which case Shorewall will not create an ingress qdisc.Must be set to zero if the REDIRECTED INTERFACES column is non-empty.

The optional burst option was added in Shorewall 4.4.18. The default burst is 10kb. A larger burst can help make the bandwidth more accurate; often for fast lines, the enforced rate is well below the specified bandwidth.

What is described above creates a rate/burst policing filter. Beginning with Shorewall 4.4.25, a rate-estimated policing filter may be configured instead. Rate-estimated filters should be used with Ethernet adapters that have Generic Receive Offload enabled by default. See Shorewall FAQ 97a[2].

To create a rate-estimated filter, precede the bandwidth with a tilde ("~"). The optional interval and decay_interval determine how often the rate is estimated and how many samples are retained for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt for details. If not specified, the default interval is 250ms and the default decay_interval is 4sec.

OUT-BANDWIDTH (out_bandwidth) - bandwidth

The outgoing bandwidth of that interface. This is the maximum speed your connection can handle. It is also the speed you can refer as "full" if you define the tc classes in shorewall-tcclasses[3](5). Outgoing traffic above this rate will be dropped.

OPTIONS - {-|{classify|htb|hfsc|linklayer={ethernet|atm|adsl}|tsize=tsize|mtu=mtu|mpu=mpu|overhead=overhead} ,...}

classify — When specified, Shorewall will not generate tc or Netfilter rules to classify traffic based on packet marks. You must do all classification using CLASSIFY rules in shorewall-mangle[4](5). connmark -- Added in Shorewall 5.2.7. May only be specified if the REDIRECTED_INTERFACES column is non-empty. It allows packet marks to be used to classify traffic for these interfaces.

htb - Use the Hierarchical Token Bucket queuing discipline. This is the default.

hfsc - Shorewall normally uses the Hierarchical Token Bucket queuing discipline. When hfsc is specified, the Hierarchical Fair Service Curves discipline is used instead (see tc-hfsc (7)).

linklayer - Added in Shorewall 4.5.6. Type of link (ethernet, atm, adsl). When specified, causes scheduler packet size manipulation as described in tc-stab (8). When this option is given, the following options may also be given after it: mtu=mtu - The device MTU; default 2048 (will be rounded up to a power of two)

mpu=mpubytes - Minimum packet size used in calculations. Smaller packets will be rounded up to this size

tsize=tablesize - Size table entries; default is 512

overhead=overheadbytes - Number of overhead bytes per packet.

REDIRECTED INTERFACES (redirect)- [interface[,interface]...]

May only be specified if the interface in the INTERFACE column is an Intermediate Frame Block (IFB) device. Causes packets that enter each listed interface to be passed through the egress filters defined for this device, thus providing a form of incoming traffic shaping. When this column is non-empty, the classify option is assumed unless the connmark option is specified.

## EXAMPLES
Example 1:

Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. The device has an outgoing bandwidth of 500kbit and an incoming bandwidth of 6000kbit

```
        #INTERFACE   IN-BANDWIDTH    OUT-BANDWIDTH         OPTIONS         REDIRECTED

        #                                                                  INTERFACES

        1:ppp0         6000kbit        500kbit
```

## FILES
/etc/shorewall/tcdevices

/etc/shorewall6/tcdevices

## SEE ALSO
tc-hfsc (7)

https://shorewall.org/traffic_shaping.htm[5]

https://shorewall.org/configuration_file_basics.htm#Pairs[6]

http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt

shorewall(8)

## NOTES
1.

https://shorewall.org/FAQ.htm#faq18

https://shorewall.org/FAQ.htm#faq18

2.

Shorewall FAQ 97a

https://shorewall.org/FAQ.htm#faq97a

3.

shorewall-tcclasses

https://shorewall.org/manpages/shorewall-tcclasses.html

4.

shorewall-mangle

https://shorewall.org/manpages/shorewall-mangle.html

5.

https://shorewall.org/traffic_shaping.htm

https://shorewall.org/traffic_shaping.htm

6.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-tcfilters

title: shorewall-tcfilters(5)

text:
# shorewall-tcfilters(5)

## NAME
tcfilters - Shorewall u32/basic classifier rules file

## SYNOPSIS
/etc/shorewall[6]/tcfilters

## DESCRIPTION
Entries in this file cause packets to be classified for traffic shaping.

Beginning with Shorewall 4.4.15, the file may contain entries for both IPv4 and IPv6. By default, all rules apply to IPv4 but that can be changed by inserting a line as follows:

IPV4

Following entries apply to IPv4.

IPV6

Following entries apply to IPv6

ALL

Following entries apply to both IPv4 and IPv6. Each entry is processed twice; once for IPv4 and once for IPv6.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

CLASS - interface:class

The name or number of an interface defined in shorewall-tcdevices[1](5) followed by a class number defined for that interface in shorewall-tcclasses[2](5).

SOURCE - {-|address|+ipset}

Source of the packet. May be a host or network address. DNS names are not allowed. Beginning with Shorewall 4.6.0, an ipset name (prefixed with '+') may be used if your kernel and ip6tables have the Basic Ematch capability and you set BASIC_FILTERS=Yes in shorewall.conf (5)[3]. The ipset name may optionally be followed by a number or a comma separated list of src and/or dst enclosed in square brackets ([...]). See shorewall-ipsets(5)[4] for details.

DEST - {-|address|+ipset}

Destination of the packet. May be a host or network address. DNS names are not allowed. Beginning with Shorewall 4.6.0, an ipset name (prefixed with '+') may be used if your kernel and ip6tables have the Basic Ematch capability and you set BASIC_FILTERS=Yes in shorewall.conf (5)[3]. The ipset name may optionally be followed by a number or a comma separated list of src and/or dst enclosed in square brackets ([...]). See shorewall-ipsets(5)[4] for details. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion[5](5)).

PROTO - {-|{protocol-number|protocol-name|all}[,...]}

Protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

DPORT - [-|port-name-or-number]

Optional destination Ports. A Port name (from services(5)) or a port number; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). This column was previously labelled DEST PORT(S).

SPORT - [-|port-name-or-number]

Optional source port. This column was previously labelled SOURCE PORT(S).

TOS (Optional) - [-|tos]

Specifies the value of the TOS field. The tos value can be any of the following:

•tos-minimize-delay

•tos-maximize-throughput

•tos-maximize-reliability

•tos-minimize-cost

•tos-normal-service

•hex-number

•hex-number/hex-number

The hex-numbers must be exactly two digits (e.g., 0x04)x.

LENGTH - [-|number]

Optional - Must be a power of 2 between 32 and 8192 inclusive. Packets with a total length that is strictly less than the specified number will match the rule.

PRIORITY - [-|priority]

Added in Shorewall 4.5.8. Specifies the rule priority. The priority value must be > 0 and <= 65535. When a priority is not given:

•For Shorewall versions prior to 4.5.8 - all filters have priority 10.

•For Shorewall 4.5.8 and later - for each device, the compiler maintains a high-water priority with an initial value of 0. When a filter has no priority, the high-water priority is incremented by 1 and assigned to the filter. When a priority greater than the high-water priority is entered in this column, the high-water priority is set to the specified priority. An attempt to assign a priority value greater than 65535 (explicitly or implicitly) raises an error.

The default priority values used by other Shorewall-generated filters are as follows:

•Classify by packet mark - ( class priority << 8 ) | 20.

•Ingress policing - 10

•Simple TC ACK packets - 1

•Complex TC ACK packets - ( class priority << 8 ) | 10.

•Classify by TOS - ( class priority << 8 ) | 15.

•Class with 'occurs' - 65535

## EXAMPLE
IPv4 Example 1:

Place all 'ping' traffic on interface 1 in class 10. Note that ALL cannot be used because IPv4 ICMP and IPv6 ICMP are two different protocols.

```
       #CLASS    SOURCE    DEST         PROTO   DPORT

       IPV4

       1:10      0.0.0.0/0 0.0.0.0/0    icmp    echo-request

       1:10      0.0.0.0/0 0.0.0.0/0    icmp    echo-reply

       IPV6

       1:10      ::/0      ::/0         icmp6   echo-request

       1:10      ::/0      ::/0         icmp6   echo-reply
```

IPv4 Example 2:

Add two filters with priority 10 (Shorewall 4.5.8 or later).

```
       #CLASS    SOURCE    DEST         PROTO   DPORT           PRIORITY

       IPV4

       1:10      0.0.0.0/0 0.0.0.0/0    icmp    echo-request    10

       1:10      0.0.0.0/0 0.0.0.0/0    icmp    echo-reply      10
```

IPv6 Example 1:

Add two filters with priority 10 (Shorewall 4.5.8 or later).

```
       #CLASS    SOURCE    DEST         PROTO   DPORT           PRIORITY

       IPV6

       1:10      ::/0      ::/0         icmp    echo-request    10

       1:10      ::/0      ::/0         icmp    echo-reply      10
```

## FILES
/etc/shorewall/tcfilters

/etc/shorewall6/tcfilters

## SEE ALSO
https://shorewall.org/traffic_shaping.htm[6]

https://shorewall.org/MultiISP.html[7]

https://shorewall.org/PacketMarking.html[8]

https://shorewall.org/configuration_file_basics.htm#Pairs[9]

shorewall(8)

## NOTES
1.

shorewall-tcdevices

https://shorewall.org/manpages/shorewall-tcdevices.html

2.

shorewall-tcclasses

https://shorewall.org/manpages/shorewall-tcclasses.html

3.

shorewall.conf (5)

https://shorewall.org/manpages/shorewall.conf.html

4.

shorewall-ipsets(5)

https://shorewall.org/manpages/shorewall-ipsets.html

5.

shorewall-exclusion

https://shorewall.org/manpages/shorewall-exclusion.html

6.

https://shorewall.org/traffic_shaping.htm

https://shorewall.org/traffic_shaping.htm

7.

https://shorewall.org/MultiISP.html

https://shorewall.org/MultiISP.html

8.

https://shorewall.org/PacketMarking.html

https://shorewall.org/PacketMarking.html

9.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-tcinterfaces

title: shorewall-tcinterfaces(5)

summary: Shorewall file

text:
# shorewall-tcinterfaces(5)

## NAME
tcinterfaces - Shorewall file

## SYNOPSIS
/etc/shorewall[6]/tcinterfaces

## DESCRIPTION
This file lists the interfaces that are subject to simple traffic shaping. Simple traffic shaping is enabled by setting TC_ENABLED=Simple in shorewall.conf[1](5).

A note on the bandwidth definition used in this file:

•don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is not.

•you can use one of the following units: kbps

Kilobytes per second.

mbps

Megabytes per second.

kbit

Kilobits per second.

mbit

Megabits per second.

bps or number

Bytes per second.

k or kb

Kilo bytes.

m or mb

Megabytes.

•Only whole integers are allowed.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

INTERFACE

The logical name of an interface. If you run both IPv4 and IPv6 Shorewall firewalls, a given interface should only be listed in one of the two configurations.

TYPE - [external|internal]

Optional. If given specifies whether the interface is external (facing toward the Internet) or internal (facing toward a local network) and enables SFQ flow classification.

IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]}

The incoming bandwidth of that interface. Please note that you are not able to do traffic shaping on incoming traffic, as the traffic is already received before you could do so. But this allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the packets are dropped. You want this mainly if you have a DSL or Cable connection to avoid queuing at your providers side. If you don't want any traffic to be dropped, set this to a value to zero in which case Shorewall will not create an ingress qdisc.Must be set to zero if the REDIRECTED INTERFACES column is non-empty.

The optional burst option was added in Shorewall 4.4.18. The default burst is 10kb. A larger burst can help make the bandwidth more accurate; often for fast lines, the enforced rate is well below the specified bandwidth.

What is described above creates a rate/burst policing filter. Beginning with Shorewall 4.4.25, a rate-estimated policing filter may be configured instead. Rate-estimated filters should be used with Ethernet adapters that have Generic Receive Offload enabled by default. See Shorewall FAQ 97a[2].

To create a rate-estimated filter, precede the bandwidth with a tilde ("~"). The optional interval and decay_interval determine how often the rate is estimated and how many samples are retained for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt for details. If not specified, the default interval is 250ms and the default decay_interval is 4sec.

OUT-BANDWIDTH (out_bandwidth) - [rate[:[burst][:[latency][:[peek][:[minburst]]]]]]

Added in Shorewall 4.4.13. The terms are defined in tc-tbf(8). Shorewall provides defaults as follows:

burst - 10kb

latency - 200ms

The remaining options are defaulted by tc(8).

## FILES
/etc/shorewall/tcinterfaces

/etc/shorewall6/tcinterfaces

## SEE ALSO
http://ace-host.stuart.id.au/russell/files/tc/doc/sch_tbf.txt

http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt

shorewall(8)

## NOTES
1.

shorewall.conf

https://shorewall.org/manpages/shorewall.conf.html

2.

Shorewall FAQ 97a

https://shorewall.org/FAQ.htm#faq97a


shorewall-tcpri

title: shorewall-tcpri(5)

summary: Shorewall file

text:
# shorewall-tcpri(5)

## NAME
tcpri - Shorewall file

## SYNOPSIS
/etc/shorewall[6]/tcpri

## DESCRIPTION
This file is used to specify the priority of traffic for simple traffic shaping (TC_ENABLED=Simple in shorewall.conf[1](5)). Beginning with Shorewall 5.2.7, the file allows ?FORMAT 2 which inserts a SPORT column immediately to the right of the DPORT column.

The priority band of each packet is determined by the last entry that the packet matches. If a packet doesn't match any entry in this file, then its priority will be determined by its TOS field. The default mapping is as follows but can be changed by setting the TC_PRIOMAP option in shorewall.conf[1](5).

```
TOS     Bits  Means                    Linux Priority    BAND
------------------------------------------------------------
0x0     0     Normal Service           0 Best Effort     2
0x2     1     Minimize Monetary Cost   1 Filler          3
0x4     2     Maximize Reliability     0 Best Effort     2
0x6     3     mmc+mr                   0 Best Effort     2
0x8     4     Maximize Throughput      2 Bulk            3
0xa     5     mmc+mt                   2 Bulk            3
0xc     6     mr+mt                    2 Bulk            3
0xe     7     mmc+mr+mt                2 Bulk            3
0x10    8     Minimize Delay           6 Interactive     1
0x12    9     mmc+md                   6 Interactive     1
0x14    10    mr+md                    6 Interactive     1
0x16    11    mmc+mr+md                6 Interactive     1
0x18    12    mt+md                    4 Int. Bulk       2
0x1a    13    mmc+mt+md                4 Int. Bulk       2
0x1c    14    mr+mt+md                 4 Int. Bulk       2
0x1e    15    mmc+mr+mt+md             4 Int. Bulk       2
```

The columns in the file are as follows.

BAND - {1|2|3}

Classifies matching traffic as High Priority (1), Medium Priority (2) or Low Priority (3). For those interfaces listed in shorewall-tcinterfaces[2](5), Priority 2 traffic will be deferred so long and there is Priority 1 traffic queued and Priority 3 traffic will be deferred so long as there is Priority 1 or Priority 2 traffic to send.

PROTO - protocol[,...]

Optional. The name or number of an IPv4 protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

DPORT - port [,...]

This column was named PORT prior to Shorewall 5.2.7. Both 'port' and 'dport' may be used in the alternate input format[3]. Optional. May only be given if the the PROTO is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). A list of one or more port numbers or service names from /etc/services. Port ranges of the form lowport:highport may also be included. In format 1, packets whose source or destination port matches the specified port(s) are assigned to the band given in the BAND column.

SPORT - port [,...]

Only present in file format 2. Optional. May only be given if the the PROTO is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). A list of one or more port numbers or service names from /etc/services. Port ranges of the form lowport:highport may also be included.

ADDRESS - [address]

Optional. The IP or MAC address that the traffic originated from. MAC addresses must be given in Shorewall format. If this column contains an address, then the PROTO, PORT(S) and INTERFACE column must be empty ("-").

INTERFACE - [interface]

Optional. The logical name of an interface that traffic arrives from. If given, the PROTO, PORT(S) and ADDRESS columns must be empty ("-").

Note

INTERFACE classification of packets occurs before classification by PROTO/PORT(S)/ADDRESS. So it is highly recommended to place entries that specify INTERFACE at the top of the file so that the rule about last entry matches is preserved.

HELPER - [helper]

Optional. Names a Netfilter protocol helper module such as ftp, sip, amanda, etc. A packet will match if it was accepted by the named helper module. You can also append "-" and a port number to the helper module name (e.g., ftp-21) to specify the port number that the original connection was made on.

## FILES
/etc/shorewall/tcpri

/etc/shorewall6/tcpri

## SEE ALSO
https://shorewall.org/configuration_file_basics.htm#Pairs[3]

prio(8), shorewall(8)

## NOTES
1.

shorewall.conf

https://shorewall.org/manpages/shorewall.conf.html

2.

shorewall-tcinterfaces

https://shorewall.org/manpages/shorewall-tcinterfaces.html

3.

alternate input format

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-tunnels

title: shorewall-tunnels(5)

summary: Shorewall VPN definition file

text:
# shorewall-tunnels(5)

## NAME
tunnels - Shorewall VPN definition file

## SYNOPSIS
/etc/shorewall[6]/tunnels

## DESCRIPTION
The tunnels file is used to define rules for encapsulated (usually encrypted) traffic to pass between the Shorewall system and a remote gateway. Traffic flowing through the tunnel is handled using the normal zone/policy/rule mechanism. See https://shorewall.org/VPNBasics.html[1] for details.

The columns in the file are as follows.

TYPE - {ipsec[:{noah|ah}]|ipsecnat|ipip|gre|l2tp|pptpclient|pptpserver|?COMMENT|{openvpn|openvpnclient|openvpnserver}[:{tcp|udp}][:port]|generic:protocol[:port]}

Types are as follows:

```
        6to4 or 6in4  - 6to4 or 6in4 tunnel. The 6in4 synonym was added in 4.4.24.

        ipsec         - IPv4 IPSEC

        ipsecnat      - IPv4 IPSEC with NAT Traversal (UDP port 4500 encapsulation)

        ipip          - IPv4 encapsulated in IPv4 (Protocol 4)

        gre           - Generalized Routing Encapsulation (Protocol 47)

        l2tp          - Layer 2 Tunneling Protocol (UDP port 1701)

        pptpclient    - PPTP Client runs on the firewall

        pptpserver    - PPTP Server runs on the firewall

        openvpn       - OpenVPN in point-to-point mode

        openvpnclient - OpenVPN client runs on the firewall

        openvpnserver - OpenVPN server runs on the firewall

        generic       - Other tunnel type

        tinc          - TINC (added in Shorewall 4.6.6)
```

If the type is ipsec, it may be followed by :ah to indicate that the Authentication Headers protocol (51) is used by the tunnel (the default is :noah which means that protocol 51 is not used). NAT traversal is only supported with ESP (protocol 50) so ipsecnat tunnels don't allow the ah option (ipsecnat:noah may be specified but is redundant).

If type is openvpn, openvpnclient or openvpnserver it may optionally be followed by ":" and tcp or udp to specify the protocol to be used. If not specified, udp is assumed.

If type is openvpn, openvpnclient or openvpnserver it may optionally be followed by ":" and the port number used by the tunnel. if no ":" and port number are included, then the default port of 1194 will be used. . Where both the protocol and port are specified, the protocol must be given first (e.g., openvpn:tcp:4444).

If type is generic, it must be followed by ":" and a protocol name (from /etc/protocols) or a protocol number. If the protocol is tcp or udp (6 or 17), then it may optionally be followed by ":" and a port number.

Comments may be attached to Netfilter rules generated from entries in this file through the use of /COMMENT lines. These lines begin with ?COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another ?COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line containing only ?COMMENT.

Note

Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred.

ZONE - zone

The zone of the physical interface through which tunnel traffic passes. This is normally your internet zone.

GATEWAY(S) (gateway or gateways) - address-or-range [ , ... ]

The IP address of the remote tunnel gateway. If the remote gateway has no fixed address (Road Warrior) then specify the gateway as 0.0.0.0/0. May be specified as a network address and if your kernel and iptables include iprange match support then IP address ranges are also allowed. Beginning with Shorewall 4.5.3, a list of addresses or ranges may be given. Exclusion (shorewall-exclusion[2] (5) ) is not supported.

GATEWAY ZONES (gateway_zone or gateway_zones) - [zone[,zone]...]

Optional. If the gateway system specified in the third column is a standalone host then this column should contain a comma-separated list of the names of the zones that the host might be in. This column only applies to IPSEC tunnels where it enables ISAKMP traffic to flow through the tunnel to the remote gateway(s).

## EXAMPLE
IPv4 Example 1:

IPSec tunnel. The remote gateway is 4.33.99.124 and the remote subnet is 192.168.9.0/24. The tunnel does not use the AH protocol

```
        #TYPE           ZONE    GATEWAY

        ipsec:noah      net     4.33.99.124
```

IPv4 Example 2:

Road Warrior (LapTop that may connect from anywhere) where the "gw" zone is used to represent the remote LapTop

```
        #TYPE           ZONE    GATEWAY         GATEWAY ZONES

        ipsec           net     0.0.0.0/0       gw
```

IPv4 Example 3:

Host 4.33.99.124 is a standalone system connected via an ipsec tunnel to the firewall system. The host is in zone gw.

```
        #TYPE           ZONE    GATEWAY         GATEWAY ZONES

        ipsec           net     4.33.99.124     gw
```

IPv4 Example 4:

Road Warriors that may belong to zones vpn1, vpn2 or vpn3. The FreeS/Wan _updown script will add the host to the appropriate zone using the shorewall add command on connect and will remove the host from the zone at disconnect time.

```
        #TYPE           ZONE    GATEWAY         GATEWAY ZONES

        ipsec           net     0.0.0.0/0       vpn1,vpn2,vpn3
```

IPv4 Example 5:

You run the Linux PPTP client on your firewall and connect to server 192.0.2.221.

```
        #TYPE           ZONE    GATEWAY         GATEWAY ZONES

        pptpclient      net     192.0.2.221
```

IPv4 Example 6:

You run a PPTP server on your firewall.

```
        #TYPE           ZONE    GATEWAY         GATEWAY ZONES

        pptpserver      net     0.0.0.0/0
```

Example 7:

OPENVPN tunnel. The remote gateway is 4.33.99.124 and openvpn uses port 7777.

```
        #TYPE           ZONE    GATEWAY         GATEWAY ZONES

        openvpn:7777    net     4.33.99.124
```

IPv4 Example 8:

You have a tunnel that is not one of the supported types. Your tunnel uses UDP port 4444. The other end of the tunnel is 4.3.99.124.

```
        #TYPE            ZONE    GATEWAY         GATEWAY ZONES

        generic:udp:4444 net     4.3.99.124
```

IPv4 Example 9:

TINC tunnel where the remote gateways are not specified. If you wish to specify a list of gateways, you can do so in the GATEWAY column.

```
        #TYPE            ZONE    GATEWAY          GATEWAY ZONES

        tinc             net     0.0.0.0/0
```

IPv6 Example 1:

IPSec tunnel. The remote gateway is 2001:cec792b4:1::44. The tunnel does not use the AH protocol

```
        #TYPE           ZONE    GATEWAY

        ipsec:noah      net     2002:cec792b4:1::44
```

IPv6 Example 2:

Road Warrior (LapTop that may connect from anywhere) where the "gw" zone is used to represent the remote LapTop

```
        #TYPE           ZONE    GATEWAY                 GATEWAY ZONES

        ipsec           net     ::/0                    gw
```

IPv6 Example 3:

Host 2001:cec792b4:1::44 is a standalone system connected via an ipsec tunnel to the firewall system. The host is in zone gw.

```
        #TYPE           ZONE    GATEWAY                 GATEWAY ZONES

        ipsec           net     2001:cec792b4:1::44     gw
```

IPv6 Example 4:

OPENVPN tunnel. The remote gateway is 2001:cec792b4:1::44 and openvpn uses port 7777.

```
        #TYPE           ZONE    GATEWAY                 GATEWAY ZONES

        openvpn:7777    net     2001:cec792b4:1::44
```

IPv6 Example 8:

You have a tunnel that is not one of the supported types. Your tunnel uses UDP port 4444. The other end of the tunnel is 2001:cec792b4:1::44.

```
        #TYPE            ZONE    GATEWAY                GATEWAY ZONES

        generic:udp:4444 net     2001:cec792b4:1::44
```

IPv6 Example 9:

TINC tunnel where the remote gateways are not specified. If you wish to specify a list of gateways, you can do so in the GATEWAY column.

```
        #TYPE            ZONE    GATEWAY          GATEWAY ZONES

        tinc             net     ::/0
```

## FILES
/etc/shorewall/tunnels

/etc/shorewall6/tunnels

## SEE ALSO
https://shorewall.org/configuration_file_basics.htm#Pairs[3]

shorewall(8)

## NOTES
1.

https://shorewall.org/VPNBasics.html

https://shorewall.org/VPNBasics.html

2.

shorewall-exclusion

https://shorewall.org/manpages/shorewall-exclusion.html

3.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-vardir

title: shorewall-vardir(5)

summary: Shorewall file

text:
# shorewall-vardir(5)

## NAME
vardir - Shorewall file

## SYNOPSIS
/etc/shorewall[6]/vardir

## DESCRIPTION
This file does not exist by default. You may create the file if you want to change the directory used by Shorewall to store state information, including compiled firewall scripts. By default, the directory used is /var/lib/shorewall/ for IPv4 and /var/lib/shorewall6/ for IPv6

The file contains a single variable assignment:

VARDIR=directory

where directory is the name of a directory. If you add this file, you should copy the files from /var/lib/shorewall to the new directory before performing a shorewall restart.

## EXAMPLE
VARDIR=/root/shorewall

## FILES
/etc/shorewall/vardir

/etc/shorewall6/vardir

## SEE ALSO
shorewall(8)


shorewall-zones

title: shorewall-zones(5)

summary: Shorewall zone declaration file

text:
# shorewall-zones(5)

## NAME
zones - Shorewall zone declaration file

## SYNOPSIS
/etc/shorewall/zones

## DESCRIPTION
The /etc/shorewall/zones file declares your network zones. You specify the hosts in each zone through entries in /etc/shorewall/interfaces or /etc/shorewall/hosts.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

ZONE - zone[:parent-zone[,parent-zone]...]

Name of the zone. Must start with a letter and consist of letters, digits or '_'. The names "all", "none", "any", "SOURCE" and "DEST" are reserved and may not be used as zone names. The maximum length of a zone name is determined by the setting of the LOGFORMAT option in shorewall.conf[1](5). With the default LOGFORMAT, zone names can be at most 5 characters long. The maximum length of an iptables log prefix is 29 bytes. As explained in shorewall.conf[1] (5), the legacy default LOGPREFIX formatting string is “Shorewall:%s:%s:” where the first %s is replaced by the chain name and the second is replaced by the disposition.

•The "Shorewall:%s:%s:" formatting string has 12 fixed characters ("Shorewall" and three colons).

•The longest of the standard dispositions are ACCEPT and REJECT which have 6 characters each.

•The canonical name for the chain containing the rules for traffic going from zone 1 to zone 2 is "<zone 1>2<zone 2>" or "<zone 1>-<zone 2>".

•So if M is the maximum zone name length, such chains can have length 2*M + 1. 12 + 6 + 2*M + 1 = 29 which reduces to

2*M = 29 - 12 - 6 - 1 = 10 or

M = 5

In Shorewall 5.1.0, the LOGFORMAT in the default and sample shorewall.conf files was changed to "%s:%s ".

•That formatting string has 2 fixed characters (":" and a space).

•So the maximum zone name length M is calculated as: 2 + 6 + 2*M + 1 = 29

2M = 29 - 2 - 6 - 1 = 20

M = 10

The order in which Shorewall matches addresses from packets to zones is determined by the order of zone declarations. Where a zone is nested in one or more other zones, you may either ensure that the nested zone precedes its parents in this file, or you may follow the (sub)zone name by ":" and a comma-separated list of the parent zones. The parent zones must have been declared in earlier records in this file. See shorewall-nesting[2](5) for additional information. Example:

```
#ZONE     TYPE     OPTIONS         IN OPTIONS        OUT OPTIONS
a         ip
b         ip
c:a,b     ip
```

Currently, Shorewall uses this information to reorder the zone list so that parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE option in shorewall.conf[1](5) can also create implicit CONTINUE policies to/from the subzone.

Where an ipsec zone is explicitly included as a child of an ip zone, the ruleset allows CONTINUE policies (explicit or implicit) to work as expected.

In the future, Shorewall may make additional use of nesting information.

TYPE

ip

This is the standard Shorewall zone type and is the default if you leave this column empty or if you enter "-" in the column. Communication with some zone hosts may be encrypted. Encrypted hosts are designated using the 'ipsec' option in shorewall-hosts[3](5). For clarity, this zone type may be specified as ipv4 in IPv4 configurations and ipv6 in IPv6 configurations.

ipsec

Communication with all zone hosts is encrypted. Your kernel and iptables must include policy match support. For clarity, this zone type may be specified as ipsec4 in IPv4 configurations and ipsec6 in IPv6 configurations.

firewall

Designates the firewall itself. You must have exactly one 'firewall' zone. No options are permitted with a 'firewall' zone. The name that you enter in the ZONE column will be stored in the shell variable $FW which you may use in other configuration files to designate the firewall zone.

bport

The zone is associated with one or more ports on a single bridge. For clarity, this zone type may be specified as bport4 in IPv4 configurations and bport6 in IPv6 configurations.

vserver

Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver guests. The zone contents must be defined in shorewall-hosts[3] (5). Vserver zones are implicitly handled as subzones of the firewall zone.

loopback

Added in Shorewall 4.5.17. Normally, Shorewall treats the loopback interface (lo) in the following way:

•By default, all traffic through the interface is ACCEPTed.

•If a $FW -> $FW policy is defined or $FW -> $FW rules are defined, they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g., 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in shorewall.conf[1](5).

•$FW -> $FW traffic is only filtered in the OUTPUT chain.

By defining a loopback zone and associating it with the loopback interface in shorewall-interfaces(5), you can effect a slightly different model. Suppose that the loopback zone name is 'local'; then:

•Both $FW -> local and local -> $FW chains are created.

•The $FW -> local and local -> $FW policies may be different.

•Both $FW -> local and local -> $FW rules may be specified.

Rules to/from the loopback zone and any zone other than the firewall zone are ignored with a warning.

loopback zones may be nested within other loopback zones.

local

Added in Shorewall 4.5.17. local is the same as ipv4 with the exception that the zone is only accessible from the firewall and vserver zones.

OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [option[,option]...]

A comma-separated list of options. With the exception of the mss and blacklist options, these only apply to TYPE ipsec zones. dynamic_shared

Added in Shorewall 4.5.9. May only be specified in the OPTIONS column and indicates that only a single ipset should be created for this zone if it has multiple dynamic entries in shorewall-hosts[3](5). Without this option, a separate ipset is created for each interface.

reqid=number

where number is specified using setkey(8) using the 'unique:number option for the SPD level.

spi=<number>

where number is the SPI of the SA used to encrypt/decrypt packets.

proto=ah|esp|ipcomp

IPSEC Encapsulation Protocol

mss=number

sets the MSS field in TCP packets. If you supply this option, you should also set FASTACCEPT=No in shorewall.conf[1](5) to insure that both the SYN and SYN,ACK packets have their MSS field adjusted.

mode=transport|tunnel

IPSEC mode

tunnel-src=address[/mask]

only available with mode=tunnel

tunnel-dst=address[/mask]

only available with mode=tunnel

strict

Means that packets must match all rules.

next

Separates rules; can only be used with strict

The options in the OPTIONS column are applied to both incoming and outgoing traffic. The IN OPTIONS are applied to incoming traffic (in addition to OPTIONS) and the OUT OPTIONS are applied to outgoing traffic.

If you wish to leave a column empty but need to make an entry in a following column, use "-".

## FILES
/etc/shorewall/zones

/etc/shorewall6/zones

## SEE ALSO
https://shorewall.org/Multiple_Zones.html[4].

https://shorewall.org/configuration_file_basics.htm#Pairs[5]

shorewall(8)

## NOTES
1.

shorewall.conf

https://shorewall.org/manpages/shorewall.conf.html

2.

shorewall-nesting

https://shorewall.org/manpages/shorewall-nesting.html

3.

shorewall-hosts

https://shorewall.org/manpages/shorewall-hosts.html

4.

https://shorewall.org/Multiple_Zones.html

https://shorewall.org/Multiple_Zones.html

5.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs