shorewall.conf

       7       debug
       6       info
       5       notice
       4       warning
       3       err
       2       crit
       1       alert
       0       emerg

If you want to specify parameters to ULOG or NFLOG (e.g., NFLOG(1,0,1)), then you must either quote the setting or you must escape the parentheses.

Examples:

MACLIST_LOG_LEVEL="NFLOG(1,0,1)"

or

MACLIST_LOG_LEVEL=NFLOG\(1,0,1\)

In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT, QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added.

DROP_DEFAULT describes the rules to be applied before a connection request is dropped by a DROP policy; REJECT_DEFAULT describes the rules to be applied if a connection request is rejected by a REJECT policy. The other three are similar for ACCEPT, QUEUE and NFQUEUE policies.

The value applied to these may be:

The default values are:

You can pass parameters to the specified action (e.g., myaction(audit,DROP)).

Beginning with Shorewall 4.5.10, the action name can be followed optionally by a colon and a log level. The level will be applied to each rule in the action or body that does not already have a log level.

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

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

Regardless of how the arptables utility is located (specified via arptables= or located via PATH), Shorewall uses the arptables-restore and arptables-save utilities from that same directory.

The setting of the AUTOMAKE option is ignored if the start or restart command includes a directory name (e.g., shorewall restart /etc/shorewall.new).

Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option below. Specifies the connection tracking states that are to be subject to blacklist screening. If neither BLACKLIST nor BLACKLISTNEWONLY are specified then the states subject to blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.

ALL sends all packets through the blacklist chains.

Note: The ESTABLISHED state may not be specified if FASTACCEPT is specified.

A_DROP and A_REJECT are audited versions of DROP and REJECT respectively and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel and iptables.

The BLACKLIST_DISPOSITION setting has no effect on entries in the BLACKLIST section of shorewall-rules[7] (5). It determines the disposition of packets sent to the blacklog target of shorewall-blrules[8](5).

When set to Yes or yes, blacklists are only consulted for new connections and for packets in the INVALID connection state (such as TCP SYN,ACK when there has been no corresponding SYN). That includes entries in the shorewall-blrules[9] (5) file and in the BLACKLIST section of shorewall-rules[7] (5).

When set to No or no, blacklists are consulted for every packet (will slow down your firewall noticeably if you have large blacklists). If the BLACKLISTNEWONLY option is not set or is set to the empty value then BLACKLISTNEWONLY=No is assumed.

Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.

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

It is important to note that changing DISABLE_IPV6=Yes to DISABLE_IPV6=No does not enable IPV6. The recommended approach for enabling IPv6 on your system is:

#SOURCE DEST POLICY LOG
#                   LEVEL
net     all  DROP   info

then the chain name is 'net2all' which is also the chain named in Shorewall log messages generated as a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain for each pair of zones covered by the policy. This makes the resulting log messages easier to interpret since the chain in the messages will have a name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST zone.

When compiling for direct use by Shorewall, causes the contents of the local module or helpers file to be copied into the compiled script. When set to No or not set, the compiled script reads the file itself.

Beginning with Shorewall 4.4.17, the variables set in the 'params' file at compile time are available at run time with EXPORTPARAMS=No. As a consequence, beginning with that version the recommended setting is EXPORTPARAMS=No.

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 is the recommended setting unless you are using Shorewall Lite.

If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED 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 shorewall-rules[7](5).

Possible values for helper are:

When HELPERS is specified on a system running Kernel 3.5.0 or later, automatic association of helpers to connections is disabled.

Prior to version 3.2.0, it was not possible to use connection marking in shorewall-tcrules[10](5) if you had a multi-ISP configuration that uses the track option.

You may set HIGH_ROUTE_MARKS=Yes in to effectively divide the packet mark and connection mark into two mark fields.

The width of the fields are determined by the setting of WIDE_TC_MARKS. If WIDE_TC_MARKS=No (the default):

When WIDE_TC_MARKS=Yes:

Regardless of the setting of WIDE_TC_MARKS, when you SAVE or RESTORE in tcrules, only the TC mark value is saved or restored. Shorewall handles saving and restoring the routing (provider) marks.

Subzones are defined by following their name with ":" and a list of parent zones (in shorewall-zones[12](5)). 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; see shorewall-nesting[13](5). 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).

On or on

Off or off

Keep or keep

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

Regardless of how the iptables utility is located (specified via IPTABLES= or located via PATH), Shorewall uses the iptables-restore and iptables-save utilities from that same directory.

The default is KEEP_RT_TABLES=No.

The value Keep causes Shorewall to ignore the option. If the option is set to Yes, then martians are logged on all interfaces. If the option is set to No, then martian logging is disabled on all interfaces except those specified in shorewall-interfaces[15](5).

Values are:

For example, using the default LOGFORMAT, the log prefix for logging from the nat table's PREROUTING chain is:

    Shorewall:nat:PREROUTING
 

    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.

If the value starts with 's:' then logging is limited per source IP. If the value starts with 'd:', then logging is limited per destination IP. Otherwise, the overall logging rate is limited.

If burst is not specified, then a value of 5 is assumed.

These parameters set the match rate and initial burst size for logged packets. Please see iptables(8) 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. If you supply one of these, then you should also supply the other.

Example:

    LOGRATE=10/minute
    LOGBURST=5

For each logging rule, the first time the rule is reached, the packet will be logged; in fact, since the burst is 5, the first five packets will be logged. After this, it will be 6 seconds (1 minute divided by the rate of 10) before a message will be logged from the rule, regardless of how many packets reach it. Also, every 6 seconds, one of the bursts will be regained; if no packets hit the rule for 30 seconds, the burst will be fully recharged; back where we started.

Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more control over the generated log prefix. Beginning with that release, the tag is interpreted as a chain name and a disposition separated by a comma. So this rule:

#ACTION                                SOURCE         DEST
LOG:info:foo,bar                 net                   fw

would generate the following log prefix when using the default LOGFORMAT setting:

#ACTION                               SOURCE            DEST
LOG:info:,bar                        net                    fw

would generate

A_DROP and A_REJECT are audited versions of DROP and REJECT respectively and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel and iptables.

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 or MACLIST_DISPOSITION=A_REJECT with MACLIST_TABLE=mangle.

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 shorewall-maclist[16](5). 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).

Table 1. Default Packet Mark Layout

In such cases, you will configure a destonly network on each zone receiving multicasts.

If not set or set to the empty value, a value of 60 (60 seconds) is assumed.

An appropriate value for this parameter would be twice the length of time that it takes your firewall system to process a shorewall restart command.

When combined with route filtering (ROUTE_FILTER=Yes or routefilter in shorewall-interfaces[15](5)), this option ensures that packets with an RFC1918 source address are only accepted from interfaces having known routes to networks using such addresses.

Beginning with Shorewall 4.5.15, you may specify blackhole, unreachable or prohibit to set the type of route to be created. See http://www.shorewall.net/MultiISP.html#null_routing.

Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all optimization categories, and you may also specify OPTIMIZE=None to disable optimization.

	-A fw-net -p udp --dport 67:68 -j ACCEPT
	-A fw-net -p udp --sport 1194 -j ACCEPT
	-A fw-net -p 41 -j ACCEPT
	-A fw-net -j ACCEPT

The default value is zero which disables all optimizations.

You can modify this behavior by implementing your own action that handles REJECT and specifying it's name in this option. The nolog and inline options will automatically be assumed for the specified action.

The following action implements the standard behavior:

?format 2
#TARGET         SOURCE  DEST    PROTO
Broadcast(DROP) -       -       -
DROP            -       -       2
INLINE          -       -       6       ; -j REJECT --reject-with tcp-reset
?if __ENHANCED_REJECT
INLINE          -       -       17      ; -j REJECT
?if __IPV4
INLINE          -       -       1       ; -j REJECT --reject-with icmp-host-unreachable
INLINE          -       -       -       ; -j REJECT --reject-with icmp-host-prohibited
?else
INLINE          -       -       58      ; -j REJECT --reject-with icmp6-addr-unreachable
INLINE          -       -       -       ; -j REJECT --reject-with icmp6-adm-prohibited
?endif
?else
INLINE          -       -       -       ; -j REJECT
?endif

The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6 behavior.

RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route in the main table (USE_DEFAULT_RT=No) or in the default table (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant table to be deleted.

The value Keep causes Shorewall to ignore the option. If the option is set to Yes, then route filtering occurs on all interfaces. If the option is set to No, then route filtering is disabled on all interfaces except those specified in shorewall-interfaces[15](5).

If you say No or no then traffic shaping is not enabled.

If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic shaping using shorewall-tcinterfaces[22](5) and shorewall-tcpri[23](5) is enabled.

If you set TC_ENABLED=Internal or internal or leave the option empty then Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne Bernin.

Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows you to configure the tcdevices and tcclasses in your Shorewall6 configuration yet make them available to the compiler when compiling your Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need to create symbolic links from your Shorewall configuration directory (normally /etc/shorewall/) to the tcdevices and tcclasses files in your Shorewall6 configuration directory (normally /etc/shorewall6/).

If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall will not include these cautionary checks.

The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2".

A_DROP and A_REJECT are audited versions of DROP and REJECT respectively and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel and iptables.

Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies PREROUTING rules in shorewall-tcrules[10](5). Previously, when TC_EXPERT=No, packets arriving through 'tracked' provider interfaces were unconditionally passed to the PREROUTING tcrules. This was done so that tcrules could reset the packet mark to zero, thus allowing the packet to be routed using the 'main' routing table. Using the main table allowed dynamic routes (such as those added for VPNs) to be effective. The rtrules file was created to provide a better alternative to clearing the packet mark. As a consequence, passing these packets to PREROUTING complicates things without providing any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in 4.4.3, this change should be transparent to most, if not all, users.

Setting this option to Yes requires the Comments capability in iptables and kernel.

When USE_DEFAULT_RT=Yes:

If USE_DEFAULT_RT is not set or if it is set to the empty string then USE_DEFAULT_RT=No is assumed.

Values are:

When set to No (the default), traffic shaping marks are 8 bytes wide (possible values are 1-255). When WIDE_TC_MARKS=Yes, traffic shaping marks are 14 bytes wide (values 1-16383). The setting of WIDE_TC_MARKS also has an effect on the HIGH_ROUTE_MARKS option (see above).