shorewall-hosts

title: shorewall-hosts(5)

summary: Shorewall file

text:
# shorewall-hosts(5)

## NAME
hosts - Shorewall file

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

## DESCRIPTION
This file is used to define zones in terms of subnets and/or individual IP addresses. Most simple setups don't need to (should not) place anything in this file.

The order of entries in this file is not significant in determining zone composition. Rather, the order that the zones are declared in shorewall-zones[1](5) determines the order in which the records in this file are interpreted.

Warning

The only time that you need this file is when you have more than one zone connected through a single interface.

Warning

If you have an entry for a zone and interface in shorewall-interfaces[2](5) then do not include any entries in this file for that same (zone, interface) pair.

The columns in the file are as follows.

ZONE - zone-name

The name of a zone declared in shorewall-zones[1](5). You may not list the firewall zone in this column.

HOST(S) - interface:{[{address-or-range[,address-or-range]...|+ipset|dynamic}[exclusion]

The name of an interface defined in the shorewall-interfaces[2](5) file followed by a colon (":") and a comma-separated list whose elements are either:

1.The IP address of a host.

2.A network in CIDR format.

3.An IP address range of the form low.address-high.address. Your kernel and iptables must have iprange match support.

4.The name of an ipset.

5.The word dynamic which makes the zone dynamic in that you can use the shorewall add and shorewall delete commands to change to composition of the zone.

You may also exclude certain hosts through use of an exclusion (see shorewall-exclusion[3](5).

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

A comma-separated list of options from the following list. The order in which you list the options is not significant but the list must have no embedded white-space. blacklist

Check packets arriving on this port against the shorewall-blacklist[4](5) file.

broadcast

Used when you want to include limited broadcasts (destination IP address 255.255.255.255) from the firewall to this zone. Only necessary when:

1.The network specified in the HOST(S) column does not include 255.255.255.255.

2.The zone does not have an entry for this interface in shorewall-interfaces[2](5).

destonly

Normally used with the Multi-cast IP address range (224.0.0.0/4). Specifies that traffic will be sent to the specified net(s) but that no traffic will be received from the net(s).

ipsec

The zone is accessed via a kernel 2.6 ipsec SA. Note that if the zone named in the ZONE column is specified as an IPSEC zone in the shorewall-zones[1](5) file then you do NOT need to specify the 'ipsec' option here.

maclist

Connection requests from these hosts are compared against the contents of shorewall-maclist[5](5). If this option is specified, the interface must be an Ethernet NIC or equivalent and must be up before Shorewall is started.

mss=mss

Added in Shorewall 4.5.2. When present, causes the TCP mss for new connections to/from the hosts given in the HOST(S) column to be clamped at the specified mss.

nosmurfs

This option only makes sense for ports on a bridge. Filter packets for smurfs (packets with a broadcast address as the source).

Smurfs will be optionally logged based on the setting of SMURF_LOG_LEVEL in shorewall.conf[6](5). After logging, the packets are dropped.

routeback

Shorewall should set up the infrastructure to pass packets from this/these address(es) back to themselves. This is necessary if hosts in this group use the services of a transparent proxy that is a member of the group or if DNAT is used to send requests originating from this group to a server in the group.

tcpflags

Packets arriving from these hosts are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL.

## EXAMPLES
Example 1

The firewall runs a PPTP server which creates a ppp interface for each remote client. The clients are assigned IP addresses in the network 192.168.3.0/24 and in a zone named 'vpn'.

```
#ZONE       HOST(S)               OPTIONS
vpn         ppp+:192.168.3.0/24
```

## FILES
/etc/shorewall/hosts

/etc/shorewall6/hosts

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

shorewall(8)

## NOTES
1.

shorewall-zones

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

2.

shorewall-interfaces

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

3.

shorewall-exclusion

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

4.

shorewall-blacklist

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

5.

shorewall-maclist

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

6.

shorewall.conf

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

7.

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

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


shorewall-interfaces

package: shorewall

title: shorewall-interfaces(5)

summary: Shorewall interfaces file

text:
# shorewall-interfaces(5)

## NAME
interfaces - Shorewall interfaces file

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

## DESCRIPTION
The interfaces file serves to define the firewall's network interfaces to Shorewall. The order of entries in this file is not significant in determining zone composition.

Beginning with Shorewall 4.5.3, the interfaces file supports two different formats:

FORMAT 1 (default - deprecated)

There is a BROADCAST column which can be used to specify the broadcast address associated with the interface.

FORMAT 2

The BROADCAST column is omitted.

The format is specified by a line as follows:

?FORMAT {1|2}

The columns in the file are as follows.

ZONE - zone-name

Zone for this interface. Must match the name of a zone declared in /etc/shorewall/zones. You may not list the firewall zone in this column. If the interface serves multiple zones that will be defined in the shorewall-hosts[1](5) file, you should place "-" in this column.

If there are multiple interfaces to the same zone, you must list them in separate entries.

Example:

```
#ZONE   INTERFACE       BROADCAST
loc     eth1            -
loc     eth2            -
```

INTERFACE - interface[:port]

Logical name of interface. Each interface may be listed only once in this file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0) here; see https://shorewall.org/FAQ.htm#faq18[2]. If the physical option is not specified, then the logical name is also the name of the actual interface. You may use wildcards here by specifying a prefix followed by the plus sign ("+"). For example, if you want to make an entry that applies to all PPP interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, ...

When using Shorewall versions before 4.1.4, care must be exercised when using wildcards where there is another zone that uses a matching specific interface. See shorewall-nesting[3](5) for a discussion of this problem.

Shorewall allows '+' as an interface name, but that usage is deprecated. A better approach is to specify 'physical=+' in the OPTIONS column (see below).

There is no need to define the loopback interface (lo) in this file.

If a port is given, then the interface must have been defined previously with the bridge option. The OPTIONS column may not contain the following options when a port is given.

arp_filter

arp_ignore

bridge

log_martians

mss

optional

proxyarp

required

routefilter

sourceroute

upnp

wait

Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo' interface, then that zone must be defined as type local in shorewall6-zones[4](5).

BROADCAST (Optional) - {-|detect|address[,address]...}

Only available if FORMAT 1. If you use the special value detect, Shorewall will detect the broadcast address(es) for you if your iptables and kernel include Address Type Match support.

If your iptables and/or kernel lack Address Type Match support then you may list the broadcast address(es) for the network(s) to which the interface belongs. For P-T-P interfaces, this column is left blank. If the interface has multiple addresses on multiple subnets then list the broadcast addresses as a comma-separated list.

If you don't want to give a value for this column but you want to enter a value in the OPTIONS column, enter - in this column.

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

A comma-separated list of options from the following list. The order in which you list the options is not significant but the list should have no embedded white-space. accept_ra[={0|1|2}]

IPv6 only; added in Shorewall 4.5.16. Values are: 0

Do not accept Router Advertisements.

1

Accept Route Advertisements if forwarding is disabled.

2

Overrule forwarding behavior. Accept Route Advertisements even if forwarding is enabled.

If the option is specified without a value, then the value 1 is assumed.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

arp_filter[={0|1}]

IPv4 only. If specified, this interface will only respond to ARP who-has requests for IP addresses configured on the interface. If not specified, the interface can respond to ARP who-has requests for IP addresses on any of the firewall's interface. The interface must be up when Shorewall is started. Only those interfaces with the arp_filter option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

arp_ignore[=number]

IPv4 only. If specified, this interface will respond to arp requests based on the value of number (defaults to 1). 1 - reply only if the target IP address is local address configured on the incoming interface

2 - reply only if the target IP address is local address configured on the incoming interface and the sender's IP address is part from same subnet on this interface's address

3 - do not reply for local addresses configured with scope host, only resolutions for global and link

4-7 - reserved

8 - do not reply for all local addresses

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

Warning

Do not specify arp_ignore for any interface involved in Proxy ARP[5].

blacklist

Checks packets arriving on this interface against the shorewall-blacklist[6](5) file. Beginning with Shorewall 4.4.13:

•If a zone is given in the ZONES column, then the behavior is as if blacklist had been specified in the IN_OPTIONS column of shorewall-zones[4](5).

•Otherwise, the option is ignored with a warning: WARNING: The 'blacklist' option is ignored on multi-zone interfaces

bridge

Designates the interface as a bridge. Beginning with Shorewall 4.4.7, setting this option also sets routeback.

Note

If you have a bridge that you don't intend to define bport zones on, then it is best to omit this option and simply specify routeback.

dbl={none|src|dst|src-dst}

Added in Shorewall 5.0.10. This option defined whether or not dynamic blacklisting is applied to packets entering the firewall through this interface and whether the source address and/or destination address is to be compared against the ipset-based dynamic blacklist (DYNAMIC_BLACKLIST=ipset... in shorewall.conf(5)[7]). The default is determine by the setting of DYNAMIC_BLACKLIST: DYNAMIC_BLACKLIST=No

Default is none (e.g., no dynamic blacklist checking).

DYNAMIC_BLACKLIST=Yes

Default is src (e.g., the source IP address is checked).

DYNAMIC_BLACKLIST=ipset[-only]

Default is src.

DYNAMIC_BLACKLIST=ipset[-only],src-dst...

Default is src-dst (e.g., the source IP addresses in checked against the ipset on input and the destination IP address is checked against the ipset on packets originating from the firewall and leaving through this interface).

The normal setting for this option will be dst or none for internal interfaces and src or src-dst for Internet-facing interfaces.

destonly

Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle traffic from this interface.

dhcp

Specify this option when any of the following are true:

1.the interface gets its IP address via DHCP

2.the interface is used by a DHCP server running on the firewall

3.the interface has a static IP but is on a LAN segment with lots of DHCP clients.

4.the interface is a simple bridge[8] with a DHCP server on one port and DHCP clients on another port.

Note

If you use Shorewall-perl for firewall/bridging[9], then you need to include DHCP-specific rules in shorewall-rules[10](5). DHCP uses UDP ports 67 and 68.

This option allows DHCP datagrams to enter and leave the interface.

forward[={0|1}]

IPv6 only Sets the /proc/sys/net/ipv6/conf/interface/forwarding option to the specified value. If no value is supplied, then 1 is assumed.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

ignore[=1]

When specified, causes the generated script to ignore up/down events from Shorewall-init for this device. Additionally, the option exempts the interface from hairpin filtering. When '=1' is omitted, the ZONE column must contain '-' and ignore must be the only OPTION. Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which only causes the generated script to ignore up/down events from Shorewall-init; hairpin filtering is still applied. In this case, the above restrictions on the ZONE and OPTIONS columns are lifted.

loopback

Added in Shorewall 4.6.6. Designates the interface as the loopback interface. This option is assumed if the interface's physical name is 'lo'. Only one interface man have the loopback option specified.

logmartians[={0|1}]

IPv4 only. Turn on kernel martian logging (logging of packets with impossible source addresses. It is strongly suggested that if you set routefilter on an interface that you also set logmartians. Even if you do not specify the routefilter option, it is a good idea to specify logmartians because your distribution may have enabled route filtering without you knowing it. Only those interfaces with the logmartians option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

To find out if route filtering is set on a given interface, check the contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero value indicates that route filtering is enabled.

Example:

```
        teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter

        1

        teastep@lists:~$
```

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

This option may also be enabled globally in the shorewall.conf[7](5) file.

maclist

Connection requests from this interface are compared against the contents of shorewall-maclist[11](5). If this option is specified, the interface must be an Ethernet NIC and must be up before Shorewall is started.

mss=number

Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or leaving on this interface to have their MSS field set to the specified number.

nets=(net[,...])

Limit the zone named in the ZONE column to only the listed networks. The parentheses may be omitted if only a single net is given (e.g., nets=192.168.1.0/24). Limited broadcast to the zone is supported. Beginning with Shorewall 4.4.1, multicast traffic to the zone is also supported.

nets=dynamic

Defines the zone as dynamic. Requires ipset match support in your iptables and kernel. See https://shorewall.org/Dynamic.html[12] for further information.

nodbl

Added in Shorewall 5.0.8. When specified, dynamic blacklisting is disabled on the interface. Beginning with Shorewall 5.0.10, nodbl is equivalent to dbl=none.

nosmurfs

IPv4 only. Filter packets for smurfs (packets with a broadcast address as the source). Smurfs will be optionally logged based on the setting of SMURF_LOG_LEVEL in shorewall.conf[7](5). After logging, the packets are dropped.

omitanycast

IPv6 only. Added in Shorewall 5.2.8. Shorewall6 has traditionally generated rules for IPv6 anycast addresses. These rules include:

1.Packets with these destination IP addresses are dropped by REJECT rules.

2.Packets with these source IP addresses are dropped by the 'nosmurfs' interface option and by the 'dropSmurfs' action.

3.Packets with these destination IP addresses are not logged during policy enforcement.

4.Packets with these destination IP addresses are processes by the 'Broadcast' action.

This can be inhibited for individual interfaces by specifying noanycast for those interfaces.

Note

RFC 2526 describes IPv6 subnet anycast addresses. The RFC makes a distinction between subnets with "IPv6 address types required to have 64-bit interface identifiers in EUI-64 format" and all other subnets. When generating these anycast addresses, the Shorewall compiler does not make this distinction and unconditionally assumes that the last 128 addresses in the subnet are reserved as anycast addresses.

optional

This option indicates that the firewall should be able to start, even if the interface is not usable for handling traffic. It allows use of the enable and disable commands on the interface. When optional is specified for an interface, Shorewall will be silent when:

•a /proc/sys/net/ipv[46]/conf/ entry for the interface cannot be modified (including for proxy ARP or proxy NDP).

•The first address of the interface cannot be obtained.

•The gateway of the interface can not be obtained (provider interface).

•The interface has been disabled using the disable command.

May not be specified with required.

physical=name

Added in Shorewall 4.4.4. When specified, the interface or port name in the INTERFACE column is a logical name that refers to the name given in this option. It is useful when you want to specify the same wildcard port name on two or more bridges. See https://shorewall.org/bridge-Shorewall-perl.html#Multiple[13]. If the interface name is a wildcard name (ends with '+'), then the physical name must also end in '+'. The physical name may end in '+' (or be exactly '+') when the interface name is not a wildcard name.

If physical is not specified, then it's value defaults to the interface name.

proxyarp[={0|1}]

IPv4 only. Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use this option if you are employing Proxy ARP through entries in shorewall-proxyarp[14](5). This option is intended solely for use with Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html.[15]

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

Only those interfaces with the proxyarp option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

proxyndp[={0|1}]

IPv6 only. Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

Only those interfaces with the proxyndp option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

required

Added in Shorewall 4.4.10. If this option is set, the firewall will fail to start if the interface is not usable. May not be specified together with optional.

routeback[={0|1}]

If specified, indicates that Shorewall should include rules that allow traffic arriving on this interface to be routed back out that same interface. This option is also required when you have used a wildcard in the INTERFACE column if you want to allow traffic between the interfaces that match the wildcard. Beginning with Shorewall 4.4.20, if you specify this option, then you should also specify either sfilter (see below) or routefilter on all interfaces (see below).

Beginning with Shorewall 4.5.18, you may specify this option to explicitly reset (e.g., routeback=0). This can be used to override Shorewall's default setting for bridge devices which is routeback=1.

routefilter[={0|1|2}]

IPv4 only. Turn on kernel route filtering for this interface (anti-spoofing measure). Only those interfaces with the routefilter option will have their setting changes; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

The value 2 is only available with Shorewall 4.4.5.1 and later when the kernel version is 2.6.31 or later. It specifies a loose form of reverse path filtering.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

This option can also be enabled globally via the ROUTE_FILTER option in the shorewall.conf[7](5) file.

Important

If ROUTE_FILTER=Yes in shorewall.conf[7](5), or if your distribution sets net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting routefilter=0 in an interface entry will not disable route filtering on that interface! The effective setting for an interface is the maximum of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the routefilter setting specified in this file (/proc/sys/net/ipv4/conf/interface/rp_filter).

Note

There are certain cases where routefilter cannot be used on an interface:

•If USE_DEFAULT_RT=Yes in shorewall.conf[7](5) and the interface is listed in shorewall-providers[16](5).

•If there is an entry for the interface in shorewall-providers[16](5) that doesn't specify the balance option.

•If IPSEC is used to allow a road-warrior to have a local address, then any interface through which the road-warrior might connect cannot specify routefilter.

Beginning with Shorewall 5.1.1, when routefilter is set to a non-zero value, the logmartians option is also implicitly set. If you actually want route filtering without logging, then you must also specify logmartians=0 after routefilter.

rpfilter

Added in Shorewall 4.5.7. This is an anti-spoofing measure that requires the 'RPFilter Match' capability in your iptables and kernel. It provides a more efficient alternative to the sfilter option below. It performs a function similar to routefilter (see above) but works with Multi-ISP configurations that do not use balanced routes.

sfilter=(net[,...])

Added in Shorewall 4.4.20. This option provides an anti-spoofing alternative to routefilter on interfaces where that option cannot be used, but where the routeback option is required (on a bridge, for example). On these interfaces, sfilter should list those local networks that are connected to the firewall through other interfaces.

sourceroute[={0|1}]

If this option is not specified for an interface, then source-routed packets will not be accepted from that interface unless it has been explicitly enabled via sysconf. Only set this option to 1 (enable source routing) if you know what you are doing. This might represent a security risk and is usually unneeded. Only those interfaces with the sourceroute option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

tcpflags[={0|1}]

Packets arriving on this interface are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL. Beginning with Shorewall 4.6.0, tcpflags=1 is the default. To disable this option, specify tcpflags=0.

unmanaged

Added in Shorewall 4.5.18. Causes all traffic between the firewall and hosts on the interface to be accepted. When this option is given:

•The ZONE column must contain '-'.

•Only the following other options are allowed with unmanaged: arp_filter

arp_ignore

ignore

routefilter

optional

physical

routefilter

proxyarp

proxyudp

sourceroute

upnp

Incoming requests from this interface may be remapped via UPNP (upnpd). See https://shorewall.org/UPnP.html[17]. Supported in IPv4 and in IPv6 in Shorewall 5.1.4 and later.

upnpclient

This option is intended for laptop users who always run Shorewall on their system yet need to run UPnP-enabled client apps such as Transmission (BitTorrent client). The option causes Shorewall to detect the default gateway through the interface and to accept UDP packets from that gateway. Note that, like all aspects of UPnP, this is a security hole so use this option at your own risk. Supported in IPv4 and in IPv6 in Shorewall 5.1.4 and later.

wait=seconds

Added in Shorewall 4.4.10. Causes the generated script to wait up to seconds seconds for the interface to become usable before applying the required or optional options.

## EXAMPLE
IPv4 Example 1:

Suppose you have eth0 connected to a DSL modem and eth1 connected to your local network and that your local subnet is 192.168.1.0/24. The interface gets its IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ with subnet 192.168.2.0/24 using eth2. Your iptables and/or kernel do not support "Address Type Match" and you prefer to specify broadcast addresses explicitly rather than having Shorewall detect them. Your entries for this setup would look like:

```
?FORMAT 1
#ZONE   INTERFACE BROADCAST        OPTIONS
net     eth0      206.191.149.223  dhcp
loc     eth1      192.168.1.255
dmz     eth2      192.168.2.255
```

Example 2:

The same configuration without specifying broadcast addresses is:

```
?FORMAT 2
#ZONE   INTERFACE OPTIONS
net     eth0      dhcp
loc     eth1
dmz     eth2
```

Example 3:

You have a simple dial-in system with no Ethernet connections.

```
?FORMAT 2
#ZONE   INTERFACE OPTIONS
net     ppp0      -
```

Example 4 (Shorewall 4.4.9 and later):

You have a bridge with no IP address and you want to allow traffic through the bridge.

```
?FORMAT 2
#ZONE   INTERFACE OPTIONS
-       br0       bridge
```

## FILES
/etc/shorewall/interfaces

/etc/shorewall6/interfaces

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

shorewall(8)

## NOTES
1.

shorewall-hosts

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

2.

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

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

3.

shorewall-nesting

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

4.

shorewall6-zones

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

5.

Proxy ARP

https://shorewall.org/ProxyARP.htm

6.

shorewall-blacklist

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

7.

shorewall.conf(5)

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

8.

simple bridge

https://shorewall.org/SimpleBridge.html

9.

Shorewall-perl for firewall/bridging

https://shorewall.org/bridge-Shorewall-perl.html

10.

shorewall-rules

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

11.

shorewall-maclist

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

12.

https://shorewall.org/Dynamic.html

https://shorewall.org/Dynamic.html

13.

https://shorewall.org/bridge-Shorewall-perl.html#Multiple

https://shorewall.org/bridge-Shorewall-perl.html#Multiple

14.

shorewall-proxyarp

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

15.

http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html.

http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html

16.

shorewall-providers

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

17.

https://shorewall.org/UPnP.html

https://shorewall.org/UPnP.html

18.

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

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


shorewall-ipsets

title: shorewall-ipsets(5)

text:
# shorewall-ipsets(5)

## NAME
ipsets - Specifying the name if an ipset in Shorewall configuration files

## SYNOPSIS
+ipsetname

+ipsetname[flag,...]

+[ipsetname,...]

## DESCRIPTION
Note: In the above syntax descriptions, the square brackets ("[]") are to be taken literally rather than as meta-characters.

In most places where a network address may be entered, an ipset may be substituted. Set names must be prefixed by the character "+", must start with a letter and may be composed of alphanumeric characters, "-" and "_".

Whether the set is matched against the packet source or destination is determined by which column the set name appears (SOURCE or DEST). For those set types that specify a tuple, two alternative syntaxes are available:

[number] - Indicates that 'src' or

'dst' should be repeated number times.

Example: myset[2].

[flag,...] where

flag is src or

dst. Example: myset[src,dst].

In a SOURCE or SPORT column, the following pairs are equivalent:

•+myset[2] and +myset[src,src]

In a DEST or DPORT column, the following pairs are equivalent:

•+myset[2] and +myset[dst,dst]

Beginning with Shorewall 4.4.14, multiple source or destination matches may be specified by enclosing the set names within +[...]. The set names need not be prefixed with '+'. When such a list of sets is specified, matching packets must match all of the listed sets.

For information about set lists and exclusion, see shorewall-exclusion[1] (5).

Beginning with Shorewall 4.5.16, you can increment one or more nfacct objects each time a packet matches an ipset. You do that by listing the objects separated by commas within parentheses.

Example:

+myset[src](myobject)

In that example, when the source address of a packet matches the myset ipset, the myobject nfacct counter will be incremented.

Beginning with Shorewall 4.6.0, an ipset name (and src/dst list, if any) can be immediately be followed by a list of match options.

Important

These additional match options are not available in shorewall-tcfilters(5)[2].

Available options are:

nomatch

If the set type supports the nomatch flag, then the matching is reversed: a match with an element flagged with nomatch returns true, while a match with a plain element returns false. This option requires the 'Ipset Match nomatch' capability in your kernel and ip[6]tables.

no-update-counters

The packet and byte counters of the matching element in the set won't be updated. By default, the packet and byte counters are updated. This option and those that follow require the 'Ipset Match counters' capability in your kernel and ip[6]tables.

no-update-subcounters

The packet and byte counters of the matching element in the member set of a list type of set won't be updated. Default the packet and byte counters are updated.

packets=value

If the packet is matched an element in the set, match only if the packet counter of the element matches the given value also.

packets<value

If the packet is matched an element in the set, match only if the packet counter of the element is less than the given value as well.

packets>value

If the packet is matched an element in the set, match only if the packet counter of the element is greater than the given value as well.

packets!=value

If the packet is matched an element in the set, match only if the packet counter of the element does not match the given value also.

bytes=value

If the packet is matched an element in the set, match only if the byte counter of the element matches the given value also.

bytes<value

If the packet is matched an element in the set, match only if the byte counter of the element is less than the given value as well.

bytes>value

If the packet is matched an element in the set, match only if the byte counter of the element is greater than the given value as well.

bytes<>value

If the packet is matched an element in the set, match only if the byte counter of the element does not match the given value also.

## EXAMPLES
In the examples that follow, myset, myset1 and myset2 are ipsets and myObject is an NFacct object name.

+myset

+myset[src]

+myset[2]

+[myset1,myset2[dst]]

+myset[src](myObject)

+myset[src,nomatch,packets>100]

+myset[nomatch,no-update-counters](myObject)

## FILES
/etc/shorewall/accounting

/etc/shorewall6/accounting

/etc/shorewall/blrules

/etc/shorewall6/blrules

/etc/shorewall/hosts -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall6/hosts -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall/maclist -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall6/maclist -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall/rules

/etc/shorewall6/rules

/etc/shorewall/secmarks

/etc/shorewall6/secmarks

/etc/shorewall/mangle

/etc/shorewall6/mangle

/etc/shorewall/snat

/etc/shorewall6/snat

## SEE ALSO
shorewall(8)

## NOTES
1.

shorewall-exclusion

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

2.

shorewall-tcfilters(5)

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


shorewall-logging

title: shorewall-logging(5)

summary: Shorewall logging

text:
# shorewall-logging(5)

## NAME
logging - Shorewall logging

## SYNOPSIS
action:level

NFLOG(nflog-parameters)

ULOG(ulog-parameters)

## DESCRIPTION
The disposition of packets entering a Shorewall firewall is determined by one of a number of Shorewall facilities. Only some of these facilities permit logging.

1.The packet is part of an established connection. While the packet can be logged using LOG rules in the ESTABLISHED section of /etc/shorewall/rules[1], that is not recommended because of the large amount of information that may be logged.

2.The packet represents a connection request that is related to an established connection (such as a data connection associated with an FTP control connection[2]). These packets may be logged using LOG rules in the RELATED section of shorewall-rules(5)[1].

3.The packet is rejected because of an option in shorewall.conf[3](5) or shorewall-interfaces(5)[4]. These packets can be logged by setting the appropriate logging-related option in /etc/shorewall/shorewall.conf[3].

4.The packet matches a rule in shorewall-rules[1](5). By including a syslog level (see below) in the ACTION column of a rule (e.g., “ACCEPT:info net $FW tcp 22”), the connection attempt will be logged at that level.

5.The packet doesn't match a rule so it is handled by a policy defined in shorewall-policy(5)[5]. These may be logged by specifying a syslog level in the LOG LEVEL column of the policy's entry (e.g., “loc net ACCEPT info”).

## DEFAULT LOGGING
By default, Shorewall directs Netfilter to log using syslog (8). Syslog classifies log messages by a facility and a priority (using the notation facility.priority).

The facilities defined by syslog are auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, uucp and local0 through local7.

Throughout the Shorewall documentation, the term level rather than priority is used, since level is the term used by Netfilter. The syslog documentation uses the term priority.

## SYSLOG LEVELS
Syslog levels are a method of describing to syslog (8) the importance of a message. A number of Shorewall parameters have a syslog level as their value.

Valid levels are:

7 - debug (Debug-level

messages)

6 - info

(Informational)

5 - notice (Normal but

significant Condition)

4 - warning (Warning

Condition)

3 - err (Error

Condition)

2 - crit (Critical

Conditions)

1 - alert (must be handled

immediately)

0 - emerg (System is

unusable)

For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall log messages are generated by Netfilter and are logged using the kern facility and the level that you specify. If you are unsure of the level to choose, 6 (info) is a safe bet. You may specify levels by name or by number.

Beginning with Shorewall 4.5.5, the level name or number may be optionally followed by a comma-separated list of one or more log options. The list is enclosed in parentheses. Log options cause additional information to be included in each log message.

Valid log options are:

ip_options

Log messages will include the option settings from the IP header.

macdecode

Decode the MAC address and protocol.

tcp_sequence

Include TCP sequence numbers.

tcp_options

Include options from the TCP header.

uid

Include the UID of the sending program; only valid for packets originating on the firewall itself.

Example: info(tcp_options,tcp_sequence)

Syslogd writes log messages to files (typically in /var/log/*) based on their facility and level. The mapping of these facility/level pairs to log files is done in /etc/syslog.conf (5). If you make changes to this file, you must restart syslogd before the changes can take effect.

Syslog may also write to your system console. See Shorewall FAQ 16[6] for ways to avoid having Shorewall messages written to the console.

## CONFIGURING A SEPARATE LOG FOR SHOREWALL MESSAGES (ULOGD)
There are a couple of limitations to syslogd-based logging:

1.If you give, for example, kern.info its own log destination then that destination will also receive all kernel messages of levels 5 (notice) through 0 (emerg).

2.All kernel.info messages will go to that destination and not just those from Netfilter.

3.Netfilter (Shorewall) messages show up in dmesg.

If your kernel has NFLOG target support (and most vendor-supplied kernels do), you may also specify a log level of NFLOG (must be all caps). When NFLOG is used, Shorewall will direct Netfilter to log the related messages via the NFLOG target which will send them to a process called “ulogd”. The ulogd program is included in most distributions.

Note

The NFLOG logging mechanism is completely separate from syslog. Once you switch to NFLOG, the settings in /etc/syslog.conf have absolutely no effect on your Shorewall logging (except for Shorewall status messages which still go to syslog).

You will need to change all instances of log levels (usually “info”) in your Shorewall configuration files to “NFLOG” - this includes entries in the policy, rules and shorewall.conf files. If you initially installed using Shorewall 5.1.2 or later, you can simply change the setting of LOG_LEVEL in shorewall.conf.

## UNDERSTANDING THE CONTENTS OF SHOREWALL LOG MESSAGES
For general information on the contents of Netfilter log messages, see http://logi.cc/en/2010/07/netfilter-log-format/.

For Shorewall-specific information, see FAQ #17[7].

## CUSTOMIZING THE CONTENT OF SHOREWALL LOG MESSAGES
In a Shorewall logging rule, the log level can be followed by a log tag as in "DROP:NFLOG:junk". The generated log message will include "chain-name junk DROP".

By setting the LOGTAGONLY option to Yes in shorewall.conf(5)[8] or shorewall6.conf(5)[8], the disposition ('DROP' in the above example) will be omitted. Consider the following rule:

```
#ACTION                                    SOURCE          DEST           PROTO
REJECT(icmp-proto-unreachable):notice:IPv6 loc             net            41      # who's using IPv6 tunneling
```

This rule generates the following warning at compile time:

WARNING: Log Prefix shortened to "Shorewall:IPv6:REJECT(icmp-p "

/etc/shorewall/rules (line 212)

and produces the rather ugly prefix "Shorewall:IPv6:REJECT(icmp-p ".

Now consider this similar rule:

```
#ACTION                                              SOURCE          DEST           PROTO
REJECT(icmp-proto-unreachable):notice:IPv6,tunneling loc             net            41      # who's using IPv6 tunneling
```

With LOGTAGONLY=Yes, no warning is generated and the prefix becomes "Shorewall:IPv6:tunneling:"

See the shorewall[6].conf man page[8] for further information about how LOGTAGONLY=Yes can be used.

## LOG BACKENDS
Netfilter logging allows configuration of multiple backends. Logging backends provide the The low-level forward of log messages. There are currently three backends:

LOG (ipt_LOG and ip6t_LOG).

Normal kernel-based logging to a syslog daemon.

ULOG (ipt_ULOG)

ULOG logging as described ablve. Only available for IPv4.

netlink (nfnetlink_log)

The logging backend behind NFLOG, defined above.

The currently-available and currently-selected IPv4 and IPv6 backends are shown in /proc/sys/net/netfilter/nf_log:

```
cat /proc/net/netfilter/nf_log

 0 NONE (nfnetlink_log)

 1 NONE (nfnetlink_log)

 2 ipt_ULOG (ipt_ULOG,ipt_LOG,nfnetlink_log)

 3 NONE (nfnetlink_log)

 4 NONE (nfnetlink_log)

 5 NONE (nfnetlink_log)

 6 NONE (nfnetlink_log)

 7 NONE (nfnetlink_log)

 8 NONE (nfnetlink_log)

 9 NONE (nfnetlink_log)
10 ip6t_LOG (ip6t_LOG,nfnetlink_log)
11 NONE (nfnetlink_log)
12 NONE (nfnetlink_log)
```

The magic numbers (0-12) are Linux address family numbers (AF_INET is 2 and AF_INET6 is 10).

The name immediately following the number is the currently-selected backend, and the ones in parentheses are the ones that are available. You can change the currently selected backend by echoing it's name into /proc/net/netfilter/nf_log.number.

Example - change the IPv4 backend to LOG:

```
sysctl net.netfilter.nf_log.2=ipt_LOG
```

Beginning with Shorewall 4.6.4, you can configure the backend using the LOG_BACKEND option in shorewall.conf(5)[3] and shorewall6.conf(5)[3].

## SEE ALSO
https://shorewall.org/shorewall_logging.html[9]

## NOTES
1.

/etc/shorewall/rules

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

2.

data connection associated with an FTP control connection

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

3.

shorewall.conf

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

4.

shorewall-interfaces(5)

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

5.

shorewall-policy(5)

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

6.

Shorewall FAQ 16

https://shorewall.org/manpages/FAQ.htm#faq16

7.

FAQ #17

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

8.

shorewall.conf(5)

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

9.

https://shorewall.org/shorewall_logging.html

https://shorewall.org/shorewall_logging.htm


shorewall-maclist

title: shorewall-maclist(5)

summary: Shorewall MAC Verification file

text:
# shorewall-maclist(5)

## NAME
maclist - Shorewall MAC Verification file

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

## DESCRIPTION
This file is used to define the MAC addresses and optionally their associated IP addresses to be allowed to use the specified interface. The feature is enabled by using the maclist option in the shorewall-interfaces[1](5) or shorewall-hosts[2](5) configuration file.

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

DISPOSITION - {ACCEPT|DROP|REJECT}[:log-level]

ACCEPT or DROP (if MACLIST_TABLE=filter in shorewall.conf[3](5), then REJECT is also allowed). If specified, the log-level causes packets matching the rule to be logged at that level.

INTERFACE - interface

Network interface to a host.

MAC - address

MAC address of the host -- you do not need to use the Shorewall format for MAC addresses here. If IP ADDRESSES is supplied then MAC can be supplied as a dash (-)

IP ADDRESSES (addresses) - [address[,address]...]

Optional - if specified, both the MAC and IP address must match. This column can contain a comma-separated list of host and/or subnet addresses. If your kernel and iptables have iprange match support then IP address ranges are also allowed. Similarly, if your kernel and iptables include ipset support than set names (prefixed by "+") are also allowed.

## FILES
/etc/shorewall/maclist

/etc/shorewall6/maclist

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

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

shorewall(8)

## NOTES
1.

shorewall-interfaces

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

2.

shorewall-hosts

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

3.

shorewall.conf

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

4.

https://shorewall.org/MAC_Validation.html

https://shorewall.org/MAC_Validation.html

5.

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

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


shorewall-mangle

title: shorewall-mangle(5)

text:
# shorewall-mangle(5)

## NAME
mangle - Shorewall Packet marking/mangling rules file

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

## DESCRIPTION
This file was introduced in Shorewall 4.6.0 and replaces shorewall-tcrules(5)[1]. This file is only processed by the compiler if:

Entries in this file cause packets to be marked as a means of classifying them for traffic control or policy routing.

Important

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

If you use multiple internet providers with the 'track' option, in /etc/shorewall/providers be sure to read the restrictions at https://shorewall.org/MultiISP.html[3].

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 - command[(parameters)][:chain-designator]

The chain-designator indicates the Netfilter chain that the entry applies to and may be one of the following: P

PREROUTING chain.

F

FORWARD chain.

T

POSTROUTING chain.

I

INPUT chain.

NP

PREROUTING chain in the nat table.

NI

INPUT chain in the nat table.

NO

OUTPUT chain in the nat table.

NT

POSTROUTING chain in the nat table.

The nat table designators were added in Shorewall 5.2.1. When a nat table designator is given, only the CONNMARK, MARK, SAVE and RESTORE commands may be used.

Unless otherwise specified for the particular command, the default chain is PREROUTING when MARK_IN_FORWARD_CHAIN=No in shorewall.conf(5)[4], and FORWARD when MARK_IN_FORWARD_CHAIN=Yes.

A chain-designator may not be specified if the SOURCE or DEST columns begin with '$FW'. When the SOURCE is $FW, the generated rule is always placed in the OUTPUT chain. If DEST is '$FW', then the rule is placed in the INPUT chain. Additionally, a chain-designator may not be specified in an action body.

Where a command takes parameters, those parameters are enclosed in parentheses ("(....)") and separated by commas.

The command may be one of the following.

action[([param[,...])]

Added in Shorewall 5.0.7. action must be an action declared with the mangle option in shorewall-actions(5)[5]. If the action accepts parameters, they are specified as a comma-separated list within parentheses following the action name.

ADD(ipset:flags)

Added in Shorewall 4.6.7. Causes addresses and/or port numbers to be added to the named ipset. The flags specify the address or tuple to be added to the set and must match the type of ipset involved. For example, for an iphash ipset, either the SOURCE or DESTINATION address can be added using flags src or dst respectively (see the -A command in ipset (8)). ADD is non-terminating. Even if a packet matches the rule, it is passed on to the next rule.

CHECKSUM

Compute and fill in the checksum in a packet that lacks a checksum. This is particularly useful if you need to work around old applications, such as dhcp clients, that do not work well with checksum offloads, but you don't want to disable checksum offload in your device. Requires 'Checksum Target' support in your kernel and iptables.

CLASSIFY(classid)

A classification Id (classid) is of the form major:minor where major and minor are integers. Corresponds to the 'class' specification in these traffic shaping modules:

```
       atm

       cbq

       dsmark

       pfifo_fast

       htb

       prio
```

Classification occurs in the POSTROUTING chain except when the SOURCE is $FW[:address] in which case classification occurs in the OUTPUT chain.

When using Shorewall's built-in traffic shaping tool, the major class is the device number (the first device in shorewall-tcdevices[6](5) is major class 1, the second device is major class 2, and so on) and the minor class is the class's MARK value in shorewall-tcclasses[7](5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.).

?COMMENT

The rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of shorewall show mangle To stop the comment from being attached to further rules, simply include ?COMMENT on a line by itself.

CONMARK({mark|range})

Identical to MARK with the exception that the mark is assigned to connection to which the packet belongs is marked rather than to the packet itself.

CONTINUE

Don't process any more marking rules in the table. Currently, CONTINUE may not be used with exclusion (see the SOURCE and DEST columns below); that restriction will be removed when iptables/Netfilter provides the necessary support.

DEL(ipset:flags)

Added in Shorewall 4.6.7. Causes an entry to be deleted from the named ipset. The flags specify the address or tuple to be deleted from the set and must match the type of ipset involved. For example, for an iphash ipset, either the SOURCE or DESTINATION address can be deleted using flags src or dst respectively (see the -D command in ipset (8)). DEL is non-terminating. Even if a packet matches the rule, it is passed on to the next rule.

DIVERT

Two DIVERT rule should precede the TPROXY rule and should select DEST PORT tcp 80 and SOURCE PORT tcp 80 respectively (assuming that tcp port 80 is being proxied). DIVERT avoids sending packets to the TPROXY target once a socket connection to Squid3 has been established by TPROXY. DIVERT marks the packet with a unique mark and exempts it from any rules that follow.

DIVERTHA

Added in Shorewall 5.0.4. To setup the HAProxy configuration described at http://www.loadbalancer.org/blog/setting-up-haproxy-with-transparent-mode-on-centos-6-x, place this entry in shorewall-providers(5)[8]:

```
#NAME    NUMBER   MARK    DUPLICATE  INTERFACE GATEWAY         OPTIONS               COPY
TProxy   1        -       -          lo        -               tproxy
```

and use this DIVERTHA entry:

```
#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT   USER    TEST    LENGTH  TOS   CONNBYTES         HELPER    PROBABILITY DSCP
DIVERTHA        -               -               tcp
```

DROP

Causes matching packets to be discarded.

DSCP(dscp)

Sets the Differentiated Services Code Point field in the IP header. The dscp value may be given as an even number (hex or decimal) or as the name of a DSCP class. Valid class names and their associated hex numeric values are:

```
    CS0  => 0x00

    CS1  => 0x08

    CS2  => 0x10

    CS3  => 0x18

    CS4  => 0x20

    CS5  => 0x28

    CS6  => 0x30

    CS7  => 0x38

    BE   => 0x00

    AF11 => 0x0a

    AF12 => 0x0c

    AF13 => 0x0e

    AF21 => 0x12

    AF22 => 0x14

    AF23 => 0x16

    AF31 => 0x1a

    AF32 => 0x1c

    AF33 => 0x1e

    AF41 => 0x22

    AF42 => 0x24

    AF43 => 0x26

    EF   => 0x2e
```

To indicate more than one class, add their hex values together and specify the result. By default, DSCP rules are placed in the POSTROUTING chain.

ECN

Added in Shorewall 5.0.6 as an alternative to entries in shorewall-ecn(5)[9]. If a PROTO is specified, it must be 'tcp' (6). If no PROTO is supplied, TCP is assumed. This action causes all ECN bits in the TCP header to be cleared.

IMQ(number)

Specifies that the packet should be passed to the IMQ identified by number. Requires IMQ Target support in your kernel and iptables.

INLINE[(action)]

Allows you to place your own ip[6]tables matches at the end of the line following a semicolon (";") (deprecated) or two semicolons (";;") (preferred since Shoreall 5.0.0). If an action is specified, the compiler proceeds as if that action had been specified in this column. If no action is specified, then you may include your own jump ("-j target [option] ...") after any matches specified at the end of the rule. If the target is not one known to Shorewall, then it must be defined as a builtin action in shorewall-actions[10] (5). The following rules are equivalent:

```
2:P                   eth0              -         tcp 22
INLINE(MARK(2)):P     eth0              -         tcp 22
INLINE(MARK(2)):P     eth0              -                 ;; -p tcp
INLINE                eth0              -         tcp 22  ;; -j MARK --set-mark 2
INLINE                eth0              -                 ;; -p tcp -j MARK --set-mark 2
```

IPMARK

Assigns a mark to each matching packet based on the either the source or destination IP address. By default, it assigns a mark value equal to the low-order 8 bits of the source address. Default values are: src

mask1 = 0xFF

mask2 = 0x00

shift = 0

'src' and 'dst' specify whether the mark is to be based on the source or destination address respectively. The selected address is first shifted to the right by shift bits. The result is then LANDed with mask1 then LORed with mask2. In a sense, the IPMARK target is more like an IPCLASSIFY target in that the mark value is later interpreted as a class ID. A packet mark is 32 bits wide; so is a class ID. The <major> class occupies the high-order 16 bits and the <minor> class occupies the low-order 16 bits. So the class ID 1:4ff (remember that class IDs are always in hex) is equivalent to a mark value of 0x104ff. Remember that Shorewall uses the interface number as the <major> number where the first interface in tcdevices has <major> number 1, the second has <major> number 2, and so on.

The IPMARK target assigns a mark to each matching packet based on the either the source or destination IP address. By default, it assigns a mark value equal to the low-order 8 bits of the source address. The syntax is as follows: IPMARK[([{src|dst}][,[mask1][,[mask2][,[shift]]]])] Default values are:

src

mask1 = 0xFF

mask2 = 0x00

shift = 0

src and dst specify whether the mark is to be based on the source or destination address respectively. The selected address is first shifted right by shift, then LANDed with mask1 and then LORed with mask2. The shift argument is intended to be used primarily with IPv6 addresses. Example: IPMARK(src,0xff,0x10100)

Suppose that the source IP address is 192.168.4.3

= 0xc0a80403; then

0xc0a80403 >> 0 = 0xc0a80403

0xc0a80403 LAND 0xFF = 0x03

0x03 LOR 0x10100 = 0x10103 or class ID

1:103

It is important to realize that, while class IDs are composed of a major and a minor value, the set of values must be unique. That is, the same numeric value cannot be used as both a major and a minor number for the same interface unless class nesting occurs (which is not currently possible with Shorewall). You should keep this in mind when deciding how to map IP addresses to class IDs. For example, suppose that your internal network is 192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6). Your first notion might be to use IPMARK(src,0xFF,0x10000) so as to produce class IDs 1:1 through 1:6. But 1:1 is an invalid class ID since the major and minor classes are equal. So you might choose instead to use IPMARK(src,0xFF,0x10100) as in the example above so that all of your minor classes will have a value > 256.

IP6TABLES({target [option ...])

IPv6 only. This action allows you to specify an iptables target with options (e.g., 'IP6TABLES(MARK --set-xmark 0x01/0xff)'. If the target is not one recognized by Shorewall, the following error message will be issued:

ERROR: Unknown target

(target)

This error message may be eliminated by adding the target as a builtin action in shorewall-actions(5)[10].

IPTABLES({target [option ...])

IPv4 only. This action allows you to specify an iptables target with options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the target is not one recognized by Shorewall, the following error message will be issued:

ERROR: Unknown target

(target)

This error message may be eliminated by adding the target as a builtin action in shorewall-actions(5)[10].

MARK({mark|range})

where mark is a packet mark value. Normally will set the mark value. If preceded by a vertical bar ("|"), the mark value will be logically ORed with the current mark value to produce a new mark value. If preceded by an ampersand ("&"), will be logically ANDed with the current mark value to produce a new mark value.

Both "|" and "&" require Extended MARK Target support in your kernel and iptables.

The mark value may be optionally followed by "/" and a mask value (used to determine those bits of the connection mark to actually be set). When a mask is specified, the result of logically ANDing the mark value with the mask must be the same as the mark value.

A mark range is a pair of integers separated by a dash ("-").

May be optionally followed by a slash ("/") and a mask and requires the Statistics Match capability in iptables and kernel. Marks in the specified range are assigned to packets on a round-robin fashion.

When a mask is specified, the result of logically ANDing each mark value with the mask must be the same as the mark value. The least significant bit in the mask is used as an increment. For example, if '0x200-0x400/0xff00' is specified, then the assigned mark values are 0x200, 0x300 and 0x400 in equal proportions. If no mask is specified, then ( 2 ** MASK_BITS ) - 1 is assumed (MASK_BITS is set in shorewall.conf[4](5)).

NFLOG[(nflog-parameters)]

Added in Shorewall 5.0.9. Logs matching packets using NFLOG. 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.

RESTORE[(mask)]

Restore the packet's mark from the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support.

SAME[(timeout)]

Some websites run applications that require multiple connections from a client browser. Where multiple 'balanced' providers are configured, this can lead to problems when some of the connections are routed through one provider and some through another. The SAME target allows you to work around that problem. SAME may be used in the PREROUTING and OUTPUT chains. When used in PREROUTING, it causes matching connections from an individual local system to all use the same provider. For example:

```
#ACTION           SOURCE         DEST         PROTO      DPORT
SAME:P            192.168.1.0/24 0.0.0.0/0    tcp        80,443
```

If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes then the new connection will use the same provider as the connection over which that last packet was sent.

When used in the OUTPUT chain, it causes all matching connections to an individual remote system to all use the same provider. For example:

```
#ACTION           SOURCE         DEST         PROTO      DPORT
SAME              $FW            0.0.0.0/0    tcp        80,443
```

The optional timeout parameter was added in Shorewall 4.6.7 and specifies a number of seconds . When not specified, a value of 300 seconds (5 minutes) is assumed. If the firewall attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last timeout seconds to the same remote system then the new connection will use the same provider as the connection over which that last packet was sent.

SAVE[(mask)]

Save the packet's mark to the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support.

TCPMSS([mss[,ipsec]])

Added in Shorewall 5.1.9. This target only applies to TCP traffic and alters the MSS value in SYN packets. It may be used in the FORWARD and POSTROUTING chains; the default is FORWARD. The mss parameter may be either pmtu or an integer in the range 500:65533. The value pmtu automatically clamps the MSS value to (path_MTU - 40 for IPv4; -60 for IPv6). This may not function as desired where asymmetric routes with differing path MTU exist — the kernel uses the path MTU which it would use to send packets from itself to the source and destination IP addresses. Prior to Linux 2.6.25, only the path MTU to the destination IP address was considered by this option; subsequent kernels also consider the path MTU to the source IP address. If an integer is given, the MSS option is set to the specified value. If the MSS of the packet is already lower than mss, it will not be increased (from Linux 2.6.25 onwards) to avoid more problems with hosts relying on a proper MSS. If mss is omitted, pmtu is assumed.

The ipsec parameter determines whether the rule applies to IPSEC traffic (ipsec is passed), non-IPSEC traffic (none is passed) or both (all is passed). If omitted, all is assumed.

TOS(tos[/mask])

Sets the Type of Service field in the IP header. The tos value may be given as an number (hex or decimal) or as the name of a TOS type. Valid type names and their associated hex numeric values are:

```
Minimize-Delay       => 0x10,
Maximize-Throughput  => 0x08,
Maximize-Reliability => 0x04,
Minimize-Cost        => 0x02,
Normal-Service       => 0x00
```

To indicate more than one class, add their hex values together and specify the result.

When tos is given as a number, it may be optionally followed by '/' and a mask. When no mask is given, the value 0xff is assumed. When tos is given as a type name, the mask 0x3f is assumed.

The action performed is to zero out the bits specified by the mask, then set the bits specified by tos.

TPROXY([port[,address]])

Transparently redirects a packet without altering the IP header. Requires a tproxy provider to be defined in shorewall-providers[8](5). There are three parameters to TPROXY - neither is required:

•port - the port on which the proxy server is listening. If omitted, the original destination port.

•address - a local (to the firewall) IP address on which the proxy server is listening. If omitted, the IP address of the interface on which the request arrives.

TTL([-|+]number)

If + is included, packets matching the rule will have their TTL incremented by number. Similarly, if - is included, matching packets have their TTL decremented by number. If neither + nor - is given, the TTL of matching packets is set to number. The valid range of values for number is 1-255.

SOURCE - {-|source-spec[,...]}

where source-spec is one of: [!]interface

where interface is the logical name of an interface defined in shorewall-interfaces[11](5). Matches packets entering the firewall from the named interface. May not be used in CLASSIFY rules or in rules using the :T chain qualifier. Beginning with Shorweall 5.2.1, the interface may be preceded with '!' which matches all interfaces except the one specified.

address[,...][exclusion]

where address is: A host or network IP address. The name of an ipset preceded by a plus sign ("+").

A MAC address in Shorewall format (preceded by a tilde ("~") and using dash ("-") as a separator (e.g., ~00-A0-C9-15-39-78). Matches traffic whose source IP address matches one of the listed addresses and that does not match an address listed in the exclusion (see shorewall-exclusion[12](5)).

This form will not match traffic that originates on the firewall itself unless either <major><minor> or the :T chain qualifier is used in the ACTION column.

[!]interface:address,[...][exclusion]

This form combines the preceding two forms and matches when both the incoming interface and source IP address match. Beginning with Shorweall 5.2.1, the interface may be preceded with '!' which matches all interfaces except the one specified.

[!]interface:exclusion

This form matches packets arriving through the named interface and whose source IP address does not match any of the addresses in the exclusion. Beginning with Shorweall 5.2.1, the interface may be preceded with '!' which matches all interfaces except the one specified.

$FW

Matches packets originating on the firewall system. May not be used with a chain qualifier (:P, :F, etc.) in the ACTION column.

$FW:address[,...][exclusion]

where address is as above (MAC addresses are not permitted). Matches packets originating on the firewall and whose source IP address matches one of the listed addresses and does not match any address listed in the exclusion. May not be used with a chain qualifier (:P, :F, etc.) in the ACTION column.

$FW:exclusion

Matches traffic originating on the firewall, provided that the source IP address does not match any address listed in the exclusion.

Beginning with Shorewall 5.1.0, multiple source_specs, separated by commas, may be given provided that the following alternative forms are used: (address[,...][exclusion])

interface:(address[,...][exclusion])

interface:(exclusion)

$FW:(address[,...][exclusion])

$FW:(exclusion)

DEST - {-|dest-spec[,...]}

where dest-spec is one of: interface

where interface is the logical name of an interface defined in shorewall-interfaces[11](5). Matches packets leaving the firewall through the named interface. May not be used in the PREROUTING chain (:P in the mark column or no chain qualifier and MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)).

address[,...][exclusion]

where address is: A host or network IP address. The name of an ipset preceded by a plus sign ("+").

A MAC address in Shorewall format (preceded by a tilde ("~") and using dash ("-") as a separator (e.g., ~00-A0-C9-15-39-78). Matches traffic whose destination IP address matches one of the listed addresses and that does not match an address listed in the exclusion (see shorewall-exclusion[12](5)).

interface:address,[...][exclusion]

This form combines the preceding two forms and matches when both the outgoing interface and destination IP address match. May not be used in the PREROUTING chain (:P in the mark column or no chain qualifier and MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)).

interface:exclusion

This form matches packets leaving through the named interface and whose destination IP address does not match any of the addresses in the exclusion. May not be used in the PREROUTING chain (:P in the mark column or no chain qualifier and MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)).

$FW

Matches packets originating on the firewall system. May not be used with a chain qualifier (:P, :F, etc.) in the ACTION column.

$FW:address[,...][exclusion]

where address is as above (MAC addresses are not permitted). Matches packets destined for the firewall and whose destination IP address matches one of the listed addresses and does not match any address listed in the exclusion. May not be used with a chain qualifier (:P, :F, etc.) in the ACTION column.

$FW:exclusion

Matches traffic destined for the firewall, provided that the destination IP address does not match any address listed in the exclusion.

Beginning with Shorewall 5.1.0, multiple dest_specs, separated by commas, may be given provided that the following alternative forms are used: (address[,...][exclusion])

interface:(address[,...][exclusion])

interface:(exclusion)

$FW:(address[,...][exclusion])

$FW:(exclusion)

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

See shorewall-rules(5)[2] 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]...|+ipset}

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[13]. 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.

An entry in this field requires that the PROTO column specify icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following field is supplied.

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.

This column was formerly named DEST PORT(S).

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

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. An entry in this field requires that the PROTO column specify tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following fields is supplied.

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.

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.

This column was formerly labelled SOURCE PORT(S).

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

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

+upnpd

\#program named upnpd

Important

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

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

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

LENGTH - [length|[min]:[max]]

Optional - packet payload length. This field, if present allow you to match the length of a packet payload (Layer 4 data ) against a specific value or range of values. You must have iptables length support for this to work. A range is specified in the form min:max where either min or max (but not both) may be omitted. If min is omitted, then 0 is assumed; if max is omitted, than any packet that is min or longer will match.

TOS - tos

Type of service. Either a standard name, or a numeric value to match.

```
         Minimize-Delay (16)

         Maximize-Throughput (8)

         Maximize-Reliability (4)

         Minimize-Cost (2)

         Normal-Service (0)
```

CONNBYTES - [!]min:[max[:{O|R|B}[:{B|P|A}]]]

Optional connection Bytes; defines a byte or packet range that the connection must fall within in order for the rule to match. A packet matches if the the packet/byte count is within the range defined by min and max (unless ! is given in which case, a packet matches if the packet/byte count is not within the range). min is an integer which defines the beginning of the byte/packet range. max is an integer which defines the end of the byte/packet range; if omitted, only the beginning of the range is checked. The first letter gives the direction which the range refers to:O - The original direction of the connection. .sp - The opposite direction from the original connection. .sp B - The total of both directions.

If omitted, B is assumed.

The second letter determines what the range refers to.B - Bytes .sp P - Packets .sp A - Average packet size.If omitted, B is assumed.

HELPER - helper

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. Example: Mark all FTP data connections with mark 4:

```
#ACTION   SOURCE    DEST      PROTO   DPORT      SPORT   USER TEST LENGTH TOS CONNBYTES HELPER
4:T       0.0.0.0/0 0.0.0.0/0 TCP     -          -       -    -    -      -   -         ftp
```

PROBABILITY - [probability]

Added in Shorewall 4.5.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.

DSCP - [[!]dscp]

Added in Shorewall 4.5.1. When non-empty, match packets whose Differentiated Service Code Point field matches the supplied value (when '!' is given, the rule matches packets whose DSCP field does not match the supplied value). The dscp value may be given as an even number (hex or decimal) or as the name of a DSCP class. Valid class names and their associated hex numeric values are:

```
    CS0  => 0x00

    CS1  => 0x08

    CS2  => 0x10

    CS3  => 0x18

    CS4  => 0x20

    CS5  => 0x28

    CS6  => 0x30

    CS7  => 0x38

    BE   => 0x00

    AF11 => 0x0a

    AF12 => 0x0c

    AF13 => 0x0e

    AF21 => 0x12

    AF22 => 0x14

    AF23 => 0x16

    AF31 => 0x1a

    AF32 => 0x1c

    AF33 => 0x1e

    AF41 => 0x22

    AF42 => 0x24

    AF43 => 0x26

    EF   => 0x2e
```

STATE -- {NEW|RELATED|ESTABLISHED|INVALID} [,...]

The rule will only match if the packet's connection is in one of the listed states.

TIME - timeelement[&timeelement...]

Added in Shorewall 4.6.2. May be used to limit the rule to a particular time period each day, to particular days of the week or month, or to a range defined by dates and times. Requires time match support in your kernel and ip6tables.

timeelement may be:

timestart=hh:mm[:ss]

Defines the starting time of day.

timestop=hh:mm[:ss]

Defines the ending time of day.

contiguous

Added in Shoreawll 5.0.12. When timestop is smaller than timestart value, match this as a single time period instead of distinct intervals.

utc

Times are expressed in Greenwich Mean Time.

localtz

Deprecated by the Netfilter team in favor of kerneltz. Times are expressed in Local Civil Time (default).

kerneltz

Added in Shorewall 4.5.2. Times are expressed in Local Kernel Time (requires iptables 1.4.12 or later).

weekdays=ddd[,ddd]...

where ddd is one of Mon, Tue, Wed, Thu, Fri, Sat or Sun

monthdays=dd[,dd],...

where dd is an ordinal day of the month

datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]

Defines the starting date and time.

datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]

Defines the ending date and time.

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

Added in Shorewall 5.1.0 and allows enabling and disabling the rule without requiring shorewall reload. 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 reload. 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.

## EXAMPLE
IPv4 Example 1:

Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer traffic with packet mark 4. This is a little more complex than otherwise expected. Since the ipp2p module is unable to determine all packets in a connection are P2P packets, we mark the entire connection as P2P if any of the packets are determined to match.

We assume packet/connection mark 0 means unclassified.

```
       #ACTION    SOURCE    DEST         PROTO   DPORT         SPORT   USER    TEST

       MARK(1):T  0.0.0.0/0 0.0.0.0/0    icmp    echo-request

       MARK(1):T  0.0.0.0/0 0.0.0.0/0    icmp    echo-reply

       RESTORE:T  0.0.0.0/0 0.0.0.0/0    all     -             -       -       0

       CONTINUE:T 0.0.0.0/0 0.0.0.0/0    all     -             -       -       !0

       MARK(4):T  0.0.0.0/0 0.0.0.0/0   ipp2p:all

       SAVE:T     0.0.0.0/0 0.0.0.0/0   all     -             -       -       !0
```

If a packet hasn't been classified (packet mark is 0), copy the connection mark to the packet mark. If the packet mark is set, we're done. If the packet is P2P, set the packet mark to 4. If the packet mark has been set, save it to the connection mark.

IPv4 Example 2:

SNAT outgoing connections on eth0 from 192.168.1.0/24 in round-robin fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9 (Shorewall 4.5.9 and later).

```
/etc/shorewall/mangle:

       #ACTION            SOURCE         DEST         PROTO   DPORT         SPORT   USER    TEST

       CONNMARK(1-3):F    192.168.1.0/24 eth0 ; state=NEW
/etc/shorewall/snat:

       #ACTION          SOURCE              DEST     ...

       SNAT(1.1.1.1)    eth0:192.168.1.0/24 - { mark=1:C }

       SNAT(1.1.1.3)    eth0:192.168.1.0/24 - { mark=2:C }

       SNAT(1.1.1.4)    eth0:192.168.1.0/24 - { mark=3:C }
```

IPv6 Example 1:

Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer traffic with packet mark 4. This is a little more complex than otherwise expected. Since the ipp2p module is unable to determine all packets in a connection are P2P packets, we mark the entire connection as P2P if any of the packets are determined to match.

We assume packet/connection mark 0 means unclassified.

```
       #ACTION    SOURCE    DEST         PROTO   DPORT         SPORT   USER    TEST

       MARK(1):T  ::/0      ::/0         icmp    echo-request

       MARK(1):T  ::/0      ::/0         icmp    echo-reply

       RESTORE:T  ::/0      ::/0         all     -             -       -       0

       CONTINUE:T ::/0      ::/0         all     -             -       -       !0

       MARK(4):T  ::/0      ::/0         ipp2p:all

       SAVE:T     ::/0      ::/0         all     -             -       -       !0
```

If a packet hasn't been classified (packet mark is 0), copy the connection mark to the packet mark. If the packet mark is set, we're done. If the packet is P2P, set the packet mark to 4. If the packet mark has been set, save it to the connection mark.

## FILES
/etc/shorewall/mangle

/etc/shorewall6/mangle

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

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

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

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

shorewall(8)

## NOTES
1.

shorewall-tcrules(5)

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

2.

shorewall-rules

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

3.

https://shorewall.org/MultiISP.html

https://shorewall.org/MultiISP.html

4.

shorewall.conf(5)

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

5.

shorewall-actions(5)

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

6.

shorewall-tcdevices

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

7.

shorewall-tcclasses

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

8.

shorewall-providers(5)

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

9.

shorewall-ecn(5)

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

10.

shorewall-actions

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

11.

shorewall-interfaces

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

12.

shorewall-exclusion

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

13.

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

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

14.

https://shorewall.org/traffic_shaping.htm

https://shorewall.org/traffic_shaping.htm

15.

https://shorewall.org/PacketMarking.html

https://shorewall.org/PacketMarking.html

16.

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

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


shorewall-modules

title: shorewall-modules(5)

summary: Shorewall file

text:
# shorewall-modules(5)

## NAME
modules - Shorewall file

## SYNOPSIS
/usr/share/shorewall[6]/modules

/usr/share/shorewall[6]/helpers

## DESCRIPTION
These files specify which kernel modules Shorewall will load before trying to determine your iptables/kernel's capabilities.

The modules file is used when LOAD_HELPERS_ONLY=No in shorewall.conf[1](8); the helpers file is used when LOAD_HELPERS_ONLY=Yes

Important

Beginning with Shorewall 5.2.3, the LOAD_HELPERS_ONLY option has been removed and the behavior is the same as if LOAD_HELPERS_ONLY=Yes was specified.

Each record in the files has the following format:

loadmodule modulename [moduleoption...]

The modulename names a kernel module (without suffix). Shorewall will search for modules based on your MODULESDIR setting in shorewall.conf[1](8). The moduleoptions are passed to modprobe (if installed) or to insmod.

The /usr/share/shorewall/modules file contains a large number of modules. Users are encouraged to copy the file to /etc/shorewall/modules and modify the copy to load only the modules required or to use LOAD_HELPERS_ONLY=Yes..if n .sp

Note

If you build monolithic kernels and have not installed module-init-tools, then create an empty /etc/shorewall/modules file; that will prevent Shorewall from trying to load modules at all.

## EXAMPLE
loadmodule ip_conntrack_ftp ports=21,221

## FILES
/usr/share/shorewall/modules

/usr/share/shorewall/helpers

/etc/shorewall/modules

/etc/shorewall/helpers

/usr/share/shorewall6/modules

/usr/share/shorewall6/helpers

/etc/shorewall6/modules

/etc/shorewall6/helpers

## SEE ALSO
shorewall(8)

## NOTES
1.

shorewall.conf

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


shorewall-names

title: shorewall-names(5)

summary: Shorewall object names

text:
# shorewall-names(5)

## NAME
names - Shorewall object names

## DESCRIPTION
When you define an object in Shorewall (Zone[1], Logical Interface, ipsets[2], Actions[3], etc., you give it a name. Shorewall names start with a letter and consist of letters, digits or underscores ("_"). Except for Zone names, Shorewall does not impose a limit on name length.

When an ipset is referenced, the name must be preceded by a plus sign ("+").

The last character of an interface may also be a plus sign to indicate a wildcard name.

Physical interface names match names shown by 'ip link ls'; if the name includes an at sign ("@"), do not include that character or any character that follows. For example, "sit1@NONE" is referred to as simply 'sit1".

## ZONE AND CHAIN NAMES
For a pair of zones, Shorewall creates two Netfilter chains; one for connections in each direction. The names of these chains are formed by separating the names of the two zones by either "2" or "-".

Example: Traffic from zone A to zone B would go through chain A2B (think "A to B") or "A-B".

In Shorewall 4.6, the default separator is "-" but you can override that by setting ZONE_SEPARATOR="2" in shorewall.conf[4] (5).

Note

Prior to Shorewall 4.6, the default separator was "2".

Zones themselves have names that begin with a letter and are composed of letters, numerals, and "_". The maximum length of a name is dependent on the setting of LOGFORMAT in shorewall.conf[4] (5). See shorewall-zones[1] (5) for details.

## USING DNS NAMES

Caution

I personally recommend strongly against using DNS names in Shorewall configuration files. If you use DNS names and you are called out of bed at 2:00AM because Shorewall won't start as a result of DNS problems then don't say that you were not forewarned.

Host addresses in Shorewall configuration files may be specified as either IP addresses or DNS Names.

DNS names in iptables rules aren't nearly as useful as they first appear. When a DNS name appears in a rule, the iptables utility resolves the name to one or more IP addresses and inserts those addresses into the rule. So changes in the DNS->IP address relationship that occur after the firewall has started have absolutely no effect on the firewall's rule set.

For some sites, using DNS names is very risky. Here's an example:

```
teastep@ursa:~$ dig pop.gmail.com
; <<>> DiG 9.4.2-P1 <<>> pop.gmail.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1774
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 7, ADDITIONAL: 0
;; QUESTION SECTION:
;pop.gmail.com.               IN A
;; ANSWER SECTION:
pop.gmail.com.          300   IN CNAME gmail-pop.l.google.com.
gmail-pop.l.google.com. 300   IN A     209.85.201.109
gmail-pop.l.google.com. 300   IN A     209.85.201.111
```

Note that the TTL is 300 -- 300 seconds is only 5 minutes. So five minutes later, the answer may change!

So this rule may work for five minutes then suddently stop working:

```
#ACTION        SOURCE               DEST              PROTO             DPORT
POP(ACCEPT)    loc                  net:pop.gmail.com
```

There are two options in shorewall[6].conf(5)[4] that affect the use of DNS names in Shorewall[6] config files:

•DEFER_DNS_RESOLUTION - When set to No, DNS names are resolved at compile time; when set to Yes, DNS Names are resolved at runtime.

•AUTOMAKE - When set to Yes, start, restart and reload only result in compilation if one of the files on the CONFIG_PATH has changed since the the last compilation.

So by setting AUTOMAKE=Yes, and DEFER_DNS_RESOLUTION=No, compilation will only take place at boot time if a change had been make to the config but no restart or reload had taken place. This is clearly spelled out in the shorewall.conf manpage. So with these settings, so long as a 'reload' or 'restart' takes place after the Shorewall configuration is changes, there should be no DNS-related problems at boot time.

Important

When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it necessary to recompile an existing firewall script, the -c option must be used with the reload or restart command to force recompilation.

If your firewall rules include DNS names then, even if DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes:

•If your /etc/resolv.confis wrong then your firewall may not start.

•If your /etc/nsswitch.conf is wrong then your firewall may not start.

•If your Name Server(s) is(are) down then your firewall may not start.

•If your startup scripts try to start your firewall before starting your DNS server then your firewall may not start.

•Factors totally outside your control (your ISP's router is down for example), can prevent your firewall from starting.

•You must bring up your network interfaces prior to starting your firewall, or the firewall may not start.

Each DNS name must be fully qualified and include a minimum of two periods (although one may be trailing). This restriction is imposed by Shorewall to insure backward compatibility with existing configuration files.

Example 1. Valid DNS Names

•mail.shorewall.net

•shorewall.net. (note the trailing period).

Example 2. Invalid DNS Names

•mail (not fully qualified)

•shorewall.net (only one period)

DNS names may not be used as:

•The server address in a DNAT rule (/etc/shorewall/rules file)

•In the ADDRESS column of an entry in /etc/shorewall/masq.

•

•In the /etc/shorewall/nat file.

These restrictions are imposed by Netfilter and not by Shorewall.

## LOGICAL INTERFACE NAMES
When dealing with a complex configuration, it is often awkward to use physical interface names in the Shorewall configuration.

•You need to remember which interface is which.

•If you move the configuration to another firewall, the interface names might not be the same.

Beginning with Shorewall 4.4.4, you can use logical interface names which are mapped to the actual interface using the physical option in shorewall-interfaces[5] (5).

Here is an example:

```
#ZONE  INTERFACE  OPTIONS
net    COM_IF     dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nosmurfs,logmartians=0,physical=eth0
net    EXT_IF     dhcp,blacklist,tcpflags,optional,routefilter=0,nosmurfs,logmartians=0,proxyarp=1,physical=eth2
loc    INT_IF     dhcp,logmartians=1,routefilter=1,tcpflags,nets=172.20.1.0/24,physical=eth1
dmz    VPS_IF     logmartians=1,routefilter=0,routeback,physical=venet0
loc    TUN_IF     physical=tun+
```

In this example, COM_IF is a logical interface name that refers to Ethernet interface eth0, EXT_IF is a logical interface name that refers to Ethernet interface eth2, and so on.

Here are a couple of more files from the same configuration:

shorewall-masq[6] (5):

```
#INTERFACE SOURCE                    ADDRESS
COMMENT Masquerade Local Network
COM_IF     0.0.0.0/0
EXT_IF     !206.124.146.0/24         206.124.146.179:persistent
```

shorewall-providers[7] (5)

```
#NAME   NUMBER   MARK    DUPLICATE  INTERFACE  GATEWAY         OPTIONS               COPY
Avvanta 1        0x10000 main       EXT_IF     206.124.146.254 loose,fallback        INT_IF,VPS_IF,TUN_IF
Comcast 2        0x20000 main       COM_IF     detect          balance               INT_IF,VPS_IF,TUN_IF
```

Note in particular that Shorewall translates TUN_IF to tun* in the COPY column.

## NOTES
1.

Zone

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

2.

ipsets

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

3.

Actions

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

4.

shorewall.conf

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

5.

shorewall-interfaces

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

6.

shorewall-masq

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

7.

shorewall-providers

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


shorewall-nat

title: shorewall-nat(5)

summary: Shorewall one\-to\-one NAT file

text:
# shorewall-nat(5)

## NAME
nat - Shorewall one-to-one NAT file

## SYNOPSIS
/etc/shorewall/nat

## DESCRIPTION
This file is used to define one-to-one Network Address Translation (NAT).

Warning

If all you want to do is simple port forwarding, do NOT use this file. See https://shorewall.org/FAQ.htm#faq1[1]. Also, in many cases, Proxy ARP (shorewall-proxyarp[2](5)) or Proxy-NDP(shorewall6-proxyndp[3](5)) is a better solution that one-to-one NAT.

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

EXTERNAL - {address|?COMMENT}

External IP Address - this should NOT be the primary IP address of the interface named in the next column and must not be a DNS Name. If you put ?COMMENT in this column, the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries in the file. The comment will appear delimited by "/* ... */" in the output of "shorewall show nat"

To stop the comment from being attached to further rules, simply include ?COMMENT on a line by itself.

INTERFACE - interfacelist[:[digit]]

Interfaces that have the EXTERNAL address. If ADD_IP_ALIASES=Yes in shorewall.conf[4](5), Shorewall will automatically add the EXTERNAL address to this interface. Also if ADD_IP_ALIASES=Yes, you may follow the interface name with ":" and a digit to indicate that you want Shorewall to add the alias with this name (e.g., "eth0:0"). That allows you to see the alias with ifconfig. That is the only thing that this name is good for -- you cannot use it anywhere else in your Shorewall configuration. Each interface must match an entry in shorewall-interfaces[5](5). Shorewall allows loose matches to wildcard entries in shorewall-interfaces[5](5). For example, ppp0 in this file will match a shorewall-interfaces[5](5) entry that defines ppp+.

If you want to override ADD_IP_ALIASES=Yes for a particular entry, follow the interface name with ":" and no digit (e.g., "eth0:").

INTERNAL - address

Internal Address (must not be a DNS Name).

ALLINTS - [Yes|No]

If Yes or yes, NAT will be effective from all hosts. If No or no (or left empty) then NAT will be effective only through the interface named in the INTERFACE column. This column was formerly labelled ALL INTERFACES.

LOCAL - [Yes|No]

If Yes or yes, NAT will be effective from the firewall system

## RESTRICTIONS
DNAT rules always preempt one-to-one NAT rules. This has subtile consequences when there are sub-zones on an interface. Consider the following:

/etc/shorewall/zones:

```
#ZONE   TYPE    OPTIONS                 IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
net     ipv4
loc     ipv4
smc:net ipv4
```

/etc/shorewall/interfaces:

```
#ZONE   INTERFACE       OPTIONS
net     eth0            dhcp,tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0
loc     eth1            tcpflags,nosmurfs,routefilter,logmartians
```

/etc/shorewall/hosts:

```
#ZONE   HOST(S)                                 OPTIONS
smc     eth0:10.1.10.0/24
```

/etc/shorewall/nat:

```
#EXTERNAL       INTERFACE       INTERNAL        ALLINTS         LOCAL
10.1.10.100     eth0            172.20.1.100
```

Note that the EXTERNAL address is in the smc zone.

/etc/shorewall/rules:

```
#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT           ORIGDEST        RATE            USER    MARK    CONNLIMIT       TIME            HEADERS     SWITCH           HELPER
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW
...
DNAT            net             loc:172.20.1.4  tcp     80
```

For the one-to-one NAT to work correctly in this configuration, one of two approaches can be taken:

1.Define a CONTINUE policy with smc as the SOURCE zone (preferred):

```
#SOURCE		DEST		POLICY		LOG LEVEL	LIMIT:BURST
smc		$FW		CONTINUE
loc		net		ACCEPT
net		all		DROP		info
# THE FOLLOWING POLICY MUST BE LAST
all		all		REJECT		info
```

2.Set IMPLICIT_CONTINUE=Yes in shorewall.conf(5)[4].

## FILES
/etc/shorewall/nat

/etc/shorewall6/nat

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

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

shorewall(8)

## NOTES
1.

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

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

2.

shorewall-proxyarp

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

3.

shorewall6-proxyndp

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

4.

shorewall.conf

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

5.

shorewall-interfaces

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

6.

https://shorewall.org/NAT.htm

https://shorewall.org/NAT.htm

7.

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

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