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

package: shorewall

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

branch: sisyphus


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