Shorewall 3.x Reference

a parameter file installed in /etc/shorewall that can be used to establish the values of shell variables for use in other files.

a parameter file installed in /etc/shorewall that is used to set several firewall parameters.

a parameter file installed in /etc/shorewall that defines a network partitioning into “zones”

a parameter file installed in /etc/shorewall that establishes overall firewall policy.

a parameter file installed in /etc/shorewall and used to express firewall rules that are exceptions to the high-level policies established in /etc/shorewall/policy.

a parameter file installed in /etc/shorewall and used to list blacklisted IP/subnet/MAC addresses.

a parameter file installed in /etc/shorewall and used to selectively disable Explicit Congestion Notification (ECN - RFC 3168).

a set of shell functions used by both the firewall and shorewall shell programs. Installed in /usr/share/shorewall.

a parameter file installed in /etc/shorewall and that specifies kernel modules and their parameters. Shorewall will automatically load the modules specified in this file.

a parameter file installed in /etc/shorewall that is used to specify how the Type of Service (TOS) field in packets is to be set.

a shell script installed in /etc/init.d to automatically start Shorewall during boot. The particular script installed depends on which distribution you are running.

a parameter file installed in /etc/shorewall and used to describe the interfaces on the firewall system.

a parameter file installed in /etc/shorewall and used to describe individual hosts or subnetworks in zones.

a parameter file installed in /etc/shorewall and used to verify the MAC address (and possibly also the IP address(es)) of devices.

This file also describes IP masquerading under Shorewall and is installed in /etc/shorewall.

a shell program that reads the configuration files in /etc/shorewall and configures your firewall. This file is installed in /usr/share/shorewall.

a parameter file in /etc/shorewall used to define one-to-one NAT.

a parameter file in /etc/shorewall used to define Proxy Arp.

a parameter file in /usr/share/shorewall used to define the treatment of packets under the norfc1918 interface option.

a parameter file in /etc/shorewall used to define those hosts that can access the firewall when Shorewall is stopped.

a parameter file in /etc/shorewall used to define rules for classifying packets for Traffic Shaping/Control.

a parameter file in /etc/shorewall used to define the bandwidth for interfaces on which you want traffic shaping to be enabled.

a parameter file in /etc/shorewall used to define classes for traffic shaping.

a set of shell functions used by Shorewall to setup traffic shaping.This file is installed in /usr/share/shorewall.

a parameter file in /etc/shorewall used to define IPSec tunnels.

a shell program (requiring a Bourne shell or derivative) used to control and monitor the firewall. This should be placed in /sbin or in /usr/sbin (the install.sh script and the rpm install this file in /sbin).

a parameter file in /etc/shorewall used to define traffic accounting rules.

a file created in /usr/share/shorewall that describes the version of Shorewall installed on your system.

files in /etc/shorewall and /usr/share/shorewall respectively that allow you to define your own actions for rules in /etc/shorewall/rules.

files in /usr/share/shorewall that define the actions included as a standard part of Shorewall.

file in /etc/shorewall that is used to define multiple Internet Service Providers and load-balancing.

file in /etc/shorewall that is used to define the iptables/kernel capabilities of a remote system. The file allows firewall scripts compiled on one system to be tailored for a remote system where the script will ultimately run under Shorewall Lite.

short name for the zone. The name should be 5 characters or less in length and consist of lower-case letters or numbers. Short names must begin with a letter and the name assigned to the firewall is reserved for use by Shorewall itself. Note that the output produced by iptables is much easier to read if you select short names that are three characters or less in length. The name “all” may not be used as a zone name nor may the zone name assigned to the firewall itself via the FW variable in /etc/shorewall/shorewall.conf.

The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow you to define nested or overlapping zones. Such overlapping/nested zones are allowed and Shorewall normally processes zones in the order that they appear in the /etc/shorewall/zones file. So if you have nested zones, you want the sub-zone to appear before the super-zone and in the case of overlapping zones, the rules that will apply to hosts that belong to both zones is determined by which zone appears first in /etc/shorewall/zones.

Hosts that belong to more than one zone may be managed by the rules of all of those zones. This is done through use of the special CONTINUE policy described below.

Beginning with Shorewall 3.0, you can adjust the order in which Shorewall generates its rules by using special syntax in the ZONE column of /etc/shorewall/zones. Where a zone is nested in one or more other zones, you may follow the (sub)zone name by ":" and a comma-separated list of the parent zones. The parent zones must have been declared in earlier records in this file.

Example:

Even though zones parnt1 and parnt2 are declared before zone child, Shorewall will generate the rules for child before either of the parent zones.

Optional parameters that identify the security policy and security associations used in communication with hosts in this zone. A comma-separated list of the following:

A zone defined in the /etc/shorewall/zones file or “-”. If you specify “-”, you must use the /etc/shorewall/hosts file to define the zones accessed via this interface.

the name of the interface (examples: eth0, ppp0, ipsec+). Each interface can be listed on only one record in this file.

the broadcast address(es) for the sub-network(s) attached to the interface. This should be left empty for P-T-P interfaces (ppp*, ippp*); if you need to specify options for such an interface, enter “-” in this column. If you supply the special value “detect” in this column, the firewall will automatically determine the broadcast address. In order to use “detect”:

a comma-separated list of options. Possible options include:

My recommendations concerning options:

A zone defined in the /etc/shorewall/zones file.

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

A comma-separated list of option

The connection is allowed.

The connection request is ignored.

The connection request is rejected with an RST (TCP) or an ICMP destination-unreachable packet being returned to the client.

Send the connection request to a user-space process via the iptables QUEUE target (useful when you are using Snort-inline).

The connection is neither ACCEPTed, DROPped nor REJECTed. CONTINUE may be used when one or both of the zones named in the entry are sub-zones of or intersect with another zone. For more information, see below.

Shorewall should not set up any infrastructure for handling traffic from the SOURCE zone to the DEST zone. When this policy is specified, the LOG LEVEL and BURST:LIMIT columns must be left blank.

The name of a client zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or “all”).

The name of a destination zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or “all”). Shorewall automatically allows all traffic from the firewall to itself so the name of the firewall zone cannot appear in both the SOURCE and DEST columns.

The default policy for connection requests from the SOURCE zone to the DESTINATION zone. Beginning with Shorewall version 3.4.0, the policy may be optionally followed by a colon (":") and the default action or default macro to be used before the policy is applied. Default actions or macros specified here override any such default specified using the policy_DEFAULT options in /etc/shorewall/shorewall.conf.

Optional. If left empty, no log message is generated when the policy is applied. Otherwise, this column should contain an integer or name indicating a syslog level.

If left empty, TCP connection requests from the SOURCE zone to the DEST zone will not be rate-limited. Otherwise, this column specifies the maximum rate at which TCP connection requests will be accepted followed by a colon (“:”) followed by the maximum burst size that will be tolerated. Example: 10/sec:40 specifies that the maximum rate of TCP connection requests allowed will be 10 per second and a burst of 40 connections will be tolerated. Connection requests in excess of these limits will be dropped. See the rules file documentation for an explanation of how rate limiting works.

Rules in this section apply to packets in the ESTABLISHED state.

Rules in this section apply to packets in the RELATED state.

Rules in this section apply to packets in the NEW and INVALID states.

The ACTION may optionally be followed by “:” and a syslog level (example: REJECT:info or ACCEPT:debug). This causes the packet to be logged at the specified level prior to being processed according to the specified ACTION. Note: if the ACTION is LOG then you MUST specify a syslog level. The log level may be optionally followed by a log tag. A log tag is a string of alphanumeric characters and is specified by following the log level with ":" and the log tag. Example:

ACCEPT:info:ftp	net	dmz	tcp	21

The log tag is appended to the log prefix generated by the LOGPREFIX variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate "Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum length of a log prefix supported by iptables is 29 characters; if a larger prefix is generated, Shorewall will issue a warning message and will truncate the prefix to 29 characters.

Specifying a log level for a <defined action> will log all invocations of the action. For example:

AllowFTP:info          net        dmz

will log all net->dmz traffic that has not been handled by earlier rules. That's probably not what you want. If you want to log the FTP connections that are actually accepted, you need to log within the action itself. One way to do that would be to copy /usr/share/shorewall/action.AllowFTP to /etc/shorewall and modify the copy as follows:

#TARGET       SOURCE         DEST            PROTO   DEST    SOURCE          RATE    USER/
#                                                    PORT    PORT(S)         LIMIT   GROUP
ACCEPT:info   -              -               tcp     21
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

The use of DNAT or REDIRECT requires that you have NAT enabled in your kernel configuration.

Describes the source hosts to which the rule applies.. The contents of this field must begin with the name of a zone defined in /etc/shorewall/zones, $FW, “all” or "none".

If the source is "none" then the rule is ignored. This is most commonly used with Shell Variables where a shell variable is set to "none" if a rule is to be omitted.

"all" means "All Zones", including the firewall itself. "all-" means "All Zones, except the firewall itself". When "all[-]" is used either in the SOURCE or DEST column intra-zone traffic is not affected. When "all+[-]" is used, intra-zone traffic is affected. "all-" and "all+-" were introduced in Shorewall version 3.2.0 Beta 8.

If the source is not one of the variants of “all” then the source may be further restricted by adding a colon (“:”) followed by a comma-separated list of qualifiers. Qualifiers are may include:

Describes the destination host(s) to which the rule applies. May take most of the forms described above for SOURCE plus the following two additional forms:

Restrictions:

Like in the SOURCE column, a range of IP addresses may be specified in the DEST column as <first address>-<last address>. When the ACTION is DNAT or DNAT-, connections will be assigned to the addresses in the range in a round-robin fashion (load-balancing).

Protocol. Must be a protocol name from /etc/protocols, a number, or “all”. Specifies the protocol of the connection request.

In the ESTABLISHED and RELATED sections, may also be "ipp2p", "ipp2p:udp", "ipp2p:all"; requires ipp2p match support in your kernel and iptables.

Beginning with Shorewall 3.1, you may also specify "tcp:syn" in this column. This is equivalent to "tcp" but also requires that the SYN flag be set and the FIN, ACK and RST flags be reset.

Port or port range (<low port>:<high port>) being connected to. May only be specified if the protocol is tcp, udp or icmp. For icmp, this column's contents are interpreted as an icmp type. If you don't want to specify DEST PORT(S) but need to include information in one of the columns to the right, enter “-” in this column. You may give a list of ports and/or port ranges separated by commas. Port numbers may be either integers or service names from /etc/services.

May be used to restrict the rule to a particular client port or port range (a port range is specified as <low port number>:<high port number>). If you don't want to restrict client ports but want to specify something in the next column, enter “-” in this column. If you wish to specify a list of port number or ranges, separate the list elements with commas (with no embedded white space). Port numbers may be either integers or service names from /etc/services.

This column may only be non-empty if the ACTION is DNAT or REDIRECT.

If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column is left empty, any connection request arriving at the firewall from the SOURCE that matches the rule will be forwarded or redirected. This works fine for connection requests arriving from the internet where the firewall has only a single external IP address. When the firewall has multiple external IP addresses or when the SOURCE is other than the internet, there will usually be a desire for the rule to only apply to those connection requests directed to particular IP addresses (see Example 2 below for another usage). Those IP addresses are specified in the ORIGINAL DEST column as a comma-separated list.

If this list begins with “!” then the rule will only apply if the original destination address matches none of the addresses listed.

You may rate-limit ACCEPT, DNAT[-], REDIRECT[-] or LOG rules with an entry in this column. Entries have the form

<rate>/<interval>[:<burst>]

where <rate> is the number of connections per <interval> (“sec” or “min”) and <burst> is the largest burst permitted. If no burst value is given, a value of 5 is assumed.

There may be no whitespace embedded in the specification.

ACCEPT net dmz tcp 80 - - 2/sec:4

If you want to specify any following columns but no rate limit, place “-” in this column.

Output rules from the firewall itself may be restricted to a particular user or group.

The column may contain:

       [!][<user name or number>][:<group name or number>][+<program name>]

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 (This feature was removed from Netfilter in kernel version 2.6.14).

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.

The interface that will masquerade the subnet; this is normally your internet interface. This interface name can be optionally qualified by adding “:” and a subnet or host IP. When this qualification is added, only packets addressed to that host or subnet will be masqueraded. The interface name can be qualified with ":" followed by a comma separated list of hosts and/or subnets. If this list begins with “!” (e.g., “eth0:!192.0.2.8/29,192.0.2.32/29”) then only packets addressed to destinations not listed will be masqueraded; otherwise (e.g., “eth0:192.0.2.8/29,192.0.2.32/29”), traffic will be masqueraded if it does match one of the listed addresses.

If you have set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf, you can cause Shorewall to create an alias label of the form interfacename:digit (e.g., eth0:0) by placing that label in this column. See example 5 below. Alias labels created in this way allow the alias to be visible to the ipconfig utility. THAT IS THE ONLY THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.

Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules defined in the /etc/shorewall/nat file. If you preceed the interface name with a plus sign ("+") then the rule will be evaluated before one-to-one NAT.

Examples:

+eth0
+eth1:192.0.2.32/27

The effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by following the interface name by ":" but no digit.

Examples:

eth0:
eth1::192.0.2.32/27
+eth3

The subnet that you want to have masqueraded through the INTERFACE. This may be expressed as a single IP address, a subnet or an interface name. In the latter instance, the interface must be configured and started before Shorewall is started as Shorewall will determine the subnet based on information obtained from the “ip” utility.

The subnet may be optionally followed by “!” and a comma-separated list of addresses and/or subnets that are to be excluded from masquerading.

The source address to be used for outgoing packets. This column is optional and if left blank, the current primary IP address of the interface in the first column is used. If you have a static IP on that interface, listing it here makes processing of output packets a little less expensive for the firewall. If you specify an address in this column, it must be an IP address configured on the INTERFACE or you must have ADD_SNAT_ALIASES enabled in /etc/shorewall/shorewall.conf. You may include a range of IP addresses in this column to indicate that Netfilter should use the addresses in the range in round-robin fashion. Beginning with Shorewall version 1.4.7, you may include a list of ranges and/or addresses in this column; again, Netfilter will use all listed ranges/addresses in rounded-robin fashion.

You may also specify the source port range to be used (the PROTO column must specify tcp or udp) by following the address or address range if any with ":" and the port range (in the format <low port>-<high port>).

Examples:

#INTERFACE SUBNET          ADDRESS                PROTO
eth0       10.0.0.0/8      192.0.2.44:7000-8000   udp

#INTERFACE SUBNET          ADDRESS                PROTO
eth0       192.168.1.0/24  :4000-5000             tcp

Some internet application that establish multiple connections from a client assume that when SNAT is being used that all connections between the client and a particular client and a remote server will appear to the server to come from the same external IP address. You can ensure that this is the case by preceding the ADDRESS range by "SAME:".

Example:

#INTERFACE SUBNET          ADDRESS               
eth0       10.0.0.0/8      SAME:192.0.2.44-192.168.2.50

If you want all connections from an internal system to use the same external IP address regardless of the remote server that they are connecting to then precede the ADDRESS range by "SAME:nodst:".

Example:

#INTERFACE SUBNET          ADDRESS               
eth0       10.0.0.0/8      SAME:nodst:192.0.2.44-192.168.2.50

If specified, must be a protocol number of a protocol name from /etc/protocols. Restricts the SNAT or Masquerade to that protocol.

If the PROTO column specifies TCP (6) or UDP (17) then this column may be used to restrict to SNAT or Masquerade to traffic with a certain destination port or a set of destination ports. The column may contain:

If you specify a value other than "-" in this column, you must be running kernel 2.6 and your kernel and iptables must include policy match support.

The value in this column is a comma-separated list of options from the following. Only packets that will be encrypted via an SA that matches these options will have their source address changed.

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.

address of the system.

the interface that connects to the system. If the interface is obvious from the subnetting, you may enter “-” in this column.

the external interface that you want to honor ARP requests for the ADDRESS specified in the first column.

If you already have a route through INTERFACE to ADDRESS, this column should contain “Yes” or “yes”. If you want Shorewall to add the route, the column should contain “No” or “no”.

If you specify "No" or "no" in the HAVEROUTE column, Shorewall will automatically add a route to the host in the ADDRESS column through the interface in the INTERFACE column. If you enter “No” or “no” in the PERSISTENT column or if you leave the column empty, that route will be deleted if you issue a shorewall stop or shorewall clear command. If you place “Yes” or “yes” in the PERSISTENT column, then those commands will not cause the route to be deleted.

External IP address

Interface that you want the EXTERNAL IP address to appear on. If you have set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf, you can specify an alias label of the form interfacename:digit (e.g., eth0:0) and Shorewall will create the alias with that label. Alias labels created in this way allow the alias to be visible to the ipconfig utility. THAT IS THE ONLY THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.

The effect of ADD_IP_ALIASES=Yes can be negated for an entry by following the interface name by ":" but no digit.

Example:

eth0:

Internal IP address.

If “Yes” or “yes”, NAT will be effective from all hosts. If “No” or “no” (or if left empty) then NAT will be effective only through the interface named in the INTERFACE column.

If Yes or yes, NAT will be effective from the firewall system. Note that with Shorewall 2.0.1 and earlier versions, this column was ignored if the ALL INTERFACES column did not contain "Yes" or "yes". This column's contents are independent of the value in ALL INTERFACES.

These options specify the default action or default macro for ACCEPT, DROP, QUEUE and REJECT policies respectively. If not specified, the following defaults are used:

The special value "none" is used to indicate that no default action/default macro should be used.

For more information on this topic, see the /etc/shorewall/policy section above.

This parameter determines whether Shorewall automatically adds the external address(es) in /etc/shorewall/nat. If the variable is set to “Yes” or “yes” then Shorewall automatically adds these aliases. If it is set to “No” or “no”, you must add these aliases yourself using your distribution's network configuration tools.

If this variable is not set or is given an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.

This parameter determines whether Shorewall automatically adds the SNAT ADDRESS in /etc/shorewall/masq. If the variable is set to “Yes” or “yes” then Shorewall automatically adds these addresses. If it is set to “No” or “no”, you must add these addresses yourself using your distribution's network configuration tools.

If this variable is not set or is given an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.

The value of this variable affects Shorewall's stopped state. When ADMINISABSENTMINDES=No, only traffic to/from those addresses listed in /etc/shorewall/routestopped is accepted when Shorewall is stopped. When ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in /etc/shorewall/routestopped, connections that were active when Shorewall stopped continue to work and all new connections from the firewall system itself are allowed. If this variable is not set or is given the empty value then ADMINISABSENTMINDED=No is assumed.

This parameter determines the disposition of packets from blacklisted hosts. It may have the value DROP if the packets are to be dropped or REJECT if the packets are to be replied with an ICMP port unreachable reply or a TCP RST (tcp only). If you do not assign a value or if you assign an empty value then DROP is assumed.

This parameter determines if packets from blacklisted hosts are logged and it determines the syslog level that they are to be logged at. Its value is a syslog level (Example: BLACKLIST_LOGLEVEL=debug). If you do not assign a value or if you assign an empty value then packets from blacklisted hosts are not logged.

When set to Yes or yes, enables Shorewall Bridging support.

This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and is usually required when your internet connection is through PPPoE or PPTP. If set to “Yes” or “yes”, the feature is enabled. If left blank or set to “No” or “no”, the feature is not enabled.

You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This will set the MSS field in TCP SYN packets going through the firewall to the value that you specify.

If this option is set to “No” then Shorewall won't clear the current traffic control rules during [re]start. This setting is intended for use by people that prefer to configure traffic shaping when the network interfaces come up rather than when the firewall is started. If that is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That way, your traffic shaping rules can still use the “fwmark” classifier based on packet marking defined in /etc/shorewall/tcrules. If not specified, CLEAR_TC=Yes is assumed.

Specifies where configuration files other than shorewall.conf may be found. CONFIG_PATH is specifies as a list of directory names separated by colons (":"). When looking for a configuration file other than shorewall.conf:

If CONFIG_PATH is not given or if it is set to the empty value then the contents of /usr/share/shorewall/configpath are used. As released from shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/shorewall but your particular distribution may set it differently. See the output of shorewall show config for the default on your system.

Note that the setting in /usr/share/shorewall/configpath is always used to locate shorewall.conf.

Users with a large static black list (/etc/shorewall/blacklist) may want to set the DELAYBLACKLISTLOAD option to Yes. When DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before loading the blacklist rules. While this may allow connections from blacklisted hosts to slip by during construction of the blacklist, it can substantially reduce the time that all new connections are disabled during shorewall [re]start.

If set to “Yes” or “yes”, Shorewall will detect the first IP address of the interface to the source zone and will include this address in DNAT rules as the original destination IP address. If set to “No” or “no”, Shorewall will not detect this address and any destination IP address will match the DNAT rule. If not specified or empty, “DETECT_DNAT_ADDRS=Yes” is assumed.

When set to Yes or yes, enables dynamic zones. DYNAMIC_ZONES=Yes is not allowed in configurations that will run under Shorewall Lite.

It is quite difficult to code a 'params' file that assigns other than constant values such that it works correctly with Shorewall Lite. The EXPORTPARAMS option works around this problem. When EXPORTPARAMS=No, the 'params' file is not copied to the compiler output.

With EXPORTPARAMS=No, if you need to set environmental variables on the firewall system for use by your extension scripts, then do so in the init extension script.

The default is EXPORTPARAMS=Yes which causes the 'params' file to be copied to the compiler output and to be executed at run-time.

Normally, Shorewall accepting ESTABLISHED/RELATED packets until these packets reach the chain in which the original connection was accepted. So for packets going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net' chain.

If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are accepted early in the INPUT, FORWARD and OUTPUT chains. If you set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or RELATED sections of /etc/shorewall/rules.

Prior to version 3.2.0, it was not possible to use connection marking in /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the track option.

Beginning with release 3.2.0, you may now set HIGH_ROUTE_MARKS=Yes in to effectively divide the packet mark and connection mark into two 8-byte mark fields.

When you do this:

When this option is set to "Yes", it causes subzones to be treated differently with respect to policies.

Subzones are defined by following their name with ":" and a list of parent zones (in /etc/shorewall/zones). Normally, you want to have a set of special rules for the subzone and if a connection doesn't match any of those subzone-specific rules then you want the parent zone rules and policies to be applied. With IMPLICIT_CONTINUE=Yes, that happens automatically.

If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden by including an explicit policy (one that does not specify "all" in either the SOURCE or the DEST columns).

Example:

This parameter determines whether Shorewall enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values are:

If this variable is not set or is given an empty value (IP_FORWARD="") then IP_FORWARD=On is assumed.

This parameter names the iptables executable to be used by Shorewall. If not specified or if specified as a null value, then the iptables executable located using the PATH option is used.

If set to Yes or yes, sets /proc/sys/net/ipv4/conf/all/log_martians and /proc/sys/net/ipv4/conf/default/log_martians to 1. Default is which sets both of the above to zero. If you do not enable martian logging for all interfaces, you may still enable it for individual interfaces using the logmartians interface option in /etc/shorewall/interfaces.

When set to a log level, this option causes Shorewall to generate a logging rule as the first rule in each builtin chain.

Example: Using the default LOGFORMAT, the log prefix for logging from the nat table's PREROUTING chain is:

Shorewall:nat:PREROUTING

This parameter tells the /sbin/shorewall program where to look for Shorewall messages when processing the “show log”, “monitor”, “status” and “hits” commands. If not assigned or if assigned an empty value, /var/log/messages is assumed.

The value of this variable generate the --log-prefix setting for Shorewall logging rules. It contains a “printf” formatting template which accepts three arguments (the chain name, logging rule number (optional) and the disposition). To use LOGFORMAT with fireparse, set it as:

LOGFORMAT="fp=%s:%d a=%s "

If the LOGFORMAT value contains the substring “%d” then the logging rule number is calculated and formatted in that position; if that substring is not included then the rule number is not included. If not supplied or supplied as empty (LOGFORMAT="") then “Shorewall:%s:%s:” is assumed.

These parameters set the match rate and initial burst size for logged packets. Please see the iptables man page for a description of the behavior of these parameters (the iptables option --limit is set by LOGRATE and --limit-burst is set by LOGBURST). If both parameters are set empty, no rate-limiting will occur.

LOGRATE=10/minute
LOGBURST=5

Determines the disposition of connections requests that fail MAC Verification and must have the value ACCEPT (accept the connection request anyway), REJECT (reject the connection request) or DROP (ignore the connection request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.

Determines the syslog level for logging connection requests that fail MAC Verification. The value must be a valid syslogd log level. If you don't want to log these connection requests, set to the empty value (e.g., MACLIST_LOG_LEVEL="").

Normally, MAC verification occurs in the filter table (INPUT and FORWARD) chains. When forwarding a packet from an interface with MAC verification to a bridge interface, that doesn't work.

This problem can be worked around by setting MACLIST_TABLE=mangle which will cause Mac verification to occur out of the PREROUTING chain. Because REJECT isn't available in that environment, you may not specify MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle.

The performance of configurations with a large numbers of entries in /etc/shorewall/maclist can be improved by setting the MACLIST_TTL variable in /etc/shorewall/shorewall.conf.

If your iptables and kernel support the "Recent Match" (see the output of "shorewall check" near the top), you can cache the results of a 'maclist' file lookup and thus reduce the overhead associated with MAC Verification.

When a new connection arrives from a 'maclist' interface, the packet passes through then list of entries for that interface in /etc/shorewall/maclist. If there is a match then the source IP address is added to the 'Recent' set for that interface. Subsequent connection attempts from that IP address occurring within $MACLIST_TTL seconds will be accepted without having to scan all of the entries. After $MACLIST_TTL from the first accepted connection request from an IP address, the next connection request from that IP address will be checked against the entire list.

If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not be cached).

If your kernel has a FORWARD chain in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules file to occur in that chain rather than in the PREROUTING chain. This permits you to mark inbound traffic based on its destination address when SNAT or Masquerading are in use. To determine if your kernel has a FORWARD chain in the mangle table, use the “/sbin/shorewall show mangle” command; if a FORWARD chain is displayed then your kernel will support this option. If this option is not specified or if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.

The value of this variable determines the possible file extensions of kernel modules. The default value is "o gz ko and o.gz". See /etc/shorewall/modules for more details.

This parameter specifies the directory/directories where your kernel netfilter modules may be found. If you leave the variable empty, Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter" in versions of Shorewall prior to 3.2.4 and "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter:/lib/modules/`uname -r`/kernel/net/ipv4/netfilter" in later versions.

In Shorewall versions prior to 3.3.2, multiple jumps to a '2all' chain could be generated in succession.

Example from an earlier shorewall version:

gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.3.2 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006

Counters reset Thu Oct 19 08:34:47 PDT 2006

Chain eth2_fwd (1 references)
 pkts bytes target     prot opt in     out     source            destination
    0     0 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW
    0     0 wifi2all   all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
    0     0 wifi2all   all  --  *      br0     0.0.0.0/0            0.0.0.0/0
    0     0 wifi2all   all  --  *      eth3    0.0.0.0/0            0.0.0.0/0
    0     0 wifi2all   all  --  *      tun+    0.0.0.0/0            0.0.0.0/0
gateway:~ #

This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.

gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.3.3 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006

Counters reset Thu Oct 19 09:15:19 PDT 2006

Chain eth2_fwd (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW
    0     0 wifi2all   all  --  *      *       0.0.0.0/0            0.0.0.0/0
gateway:~ #

Note that with OPTIMIZE=1, traffic destined for an interface/Address that falls outside of all defined zones may now be logged out of a '2all' chain rather than out of the FORWARD chain.

The OPTIMIZE setting also controls the suppression of redundant wildcard rules (those specifying "all" in the SOURCE or DEST column). A wildcard rule is considered to be redundant when it has the same ACTION and Log Level as the applicable policy.

Example:

/etc/shorewall/policy

#SOURCE         DEST            POLICY          LEVEL
loc             net             ACCEPT

/etc/shorewall/rules

#ACTION         SOURCE          DEST    PROTO   DEST
#                                               PORT(S)
...
ACCEPT          all             all     icmp    8

With OPTIMIZE=0

gateway:~ # shorewall show loc2net
Shorewall Lite 3.3.3 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006

Counters reset Thu Oct 26 07:54:58 PDT 2006

Chain loc2net (1 references)
 pkts bytes target     prot opt in     out     source               destination
    ...
    0     0 DROP       all  --  *      *      !192.168.0.0/22       0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

gateway:~

With OPTIMIZE=1

gateway:~ # shorewall show loc2net
Shorewall Lite 3.3.3 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006

Counters reset Thu Oct 26 07:56:38 PDT 2006

Chain loc2net (1 references)
 pkts bytes target     prot opt in     out     source               destination
  ...
    0     0 DROP       all  --  *      *      !192.168.0.0/22       0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

gateway:~

If you really want a rule that duplicates the policy, follow the action with "!":

#ACTION         SOURCE          DEST    PROTO   DEST
#                                               PORT(S)
  ...
ACCEPT!         all             all     icmp    8

Normally Shorewall attempts to use the iptables packet type match extension to determine broadcast and multicast packets.

If you are experiencing either of these problems, setting PKTTYPE=No will prevent Shorewall from trying to use the packet type match extension and to use IP address matching to determine which packets are broadcasts or multicasts.

The simple name of a file in /var/lib/shorewall to be used as the default restore script in the shorewall save, shorewall restore, shorewall forget and shorewall -f start commands. See the Saved Configuration documentation for details.

During "shorewall start", IP addresses to be added as a consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed then are re-added later. This is done to help ensure that the addresses can be added with the specified labels but can have the undesirable side effect of causing routes to be quietly deleted. When RETAIN_ALIASES is set to Yes, existing addresses will not be deleted. Regardless of the setting of RETAIN_ALIASES, addresses added during "shorewall start" are still deleted at a subsequent "shorewall stop" or "shorewall restart".

This parameter determines the level at which packets logged under the “norfc1918” mechanism are logged. The value must be a valid syslog level and if no level is given, then info is assumed.

Traditionally, the RETURN target in the 'rfc1918' file has caused norfc1918 processing to cease for a packet if the packet's source IP address matches the rule. Thus, if you have this entry in /etc/shorewall/rfc1918:

#SUBNETS                 TARGET
192.168.1.0/24           RETURN

then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you also have:

#SUBNETS                 TARGET
10.0.0.0/8               logdrop

Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to be logged and dropped since while the packet's source matches the RETURN rule, the packet's destination matches the 'logdrop' rule.

If not specified or specified as empty (e.g., RFC1918_STRICT="") then RFC1918_STRICT=No is assumed.

If this parameter is given the value “Yes” or “yes” then route filtering (anti-spoofing) is enabled on all network interfaces which are brought up while Shorewall is in the started state. The default value is “no”.

This parameter is used to specify the shell program to be used to interpret the firewall script (/usr/share/shorewall/firewall). If not specified or specified as a null value, /bin/sh is assumed.

Specifies the logging level for smurf packets (see the nosmurfs option in /etc/shorewall/interfaces). If set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not logged.

When set to Yes or yes, Shorewall may be started. Used as guard against Shorewall being accidentally started before it has been configured.

This parameter should be set to the name of a file that the firewall should create if it starts successfully and remove when it stops. Creating and removing this file allows Shorewall to work with your distribution's initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall. For Debian, the value is /var/state/shorewall and in LEAF it is /var/run/shorwall. Example: SUBSYSLOCK=/var/lock/subsys/shorewall.

Determines the disposition of TCP packets that fail the checks enabled by the tcpflags interface option and must have a value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP (ignore the packet). If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.

Determines the syslog level for logging packets that fail the checks enabled by the tcpflags interface option. The value must be a valid syslogd log level. If you don't want to log these packets, set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").

If set to 'Yes' (the default) then user-defined and standard actions may be used. If set to 'No', only built-in actions may be used. See the action documentation for additional information.

If this option is not set, or if it is set to the empty value, then USE_ACTIONS=Yes is assumed.

Shorewall has traditionally been very noisy (produced lots of output). You may now set the default level of verbosity using the VERBOSITY OPTION.

Values are:

If not specified, then 2 is assumed.

is the name of the modules without the trailing “.o” (example ip_conntrack).

Optional parameters to the insmod utility.

The source zone. May be qualified by following the zone name with a colon (“:”) and either an IP address, an IP subnet, a MAC address in Shorewall Format or the name of an interface. This column may also contain the name of the firewall zone to indicate packets originating on the firewall itself or “all” to indicate any source.

The destination zone. May be qualified by following the zone name with a colon (“:”) and either an IP address or an IP subnet. This column may also contain “all” to indicate any destination.

The name of a protocol in /etc/protocols or the protocol's number.

The source port or a port range. For all ports, place a hyphen (“-”) in this column.

The destination port or a port range. To indicate all ports, place a hyphen (“-”) in this column.

The type of service. Must be one of the following:

As described above.

Optional. If specified, only packets specifying this protocol will be blocked.

Optional; may only be given if PROTOCOL is tcp or udp. Expressed as a comma-separated list of destination port numbers or service names (from /etc/services). If present, only packets matching the specified protocol and one of the listed destination ports are blocked.

The subnet using VLSM notation (e.g., 192.168.0.0/16).

What to do with packets to/from the SUBNET:

Must be DNAT or SNAT.

If DNAT, traffic entering INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2.

If SNAT, traffic leaving INTERFACE with a source address in NET1 has its source address rewritten to the corresponding address in NET2.

Must be expressed in CIDR format (e.g., 192.168.1.0/24).

A firewall interface. This interface must have been defined in /etc/shorewall/interfaces.

A second network expressed in CIDR format.

The firewall interface through which the host(s) communicate with the firewall.

A comma-separated list of IP/Subnet addresses. If not supplied or supplied as “-” then 0.0.0.0/0 is assumed.

A comma-separated list of options. The currently-supported options are: