###############################################################################
#
# Shorewall - Sample shorewall.conf for one-interface
#                         configuration.
# Copyright (C) 2006-2015 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#
# For information about the settings in this file, type "man shorewall.conf"
#
# The manpage is also online at
# https://shorewall.org/manpages/shorewall.conf.html
#
###############################################################################
#		       S T A R T U P   E N A B L E D
###############################################################################
#
# OPTIONS
# 
# Many options have as their value a log-level. Log levels are a method of
# describing to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.
# 
# These levels are defined by syslog and are used to determine the destination of
# the messages through entries in /etc/syslog.conf (5). The syslog documentation
# refers to these as "priorities"; Netfilter calls them "levels" and Shorewall
# also uses that term.
# 
# Valid levels are:
# 
#        7       debug
#        6       info
#        5       notice
#        4       warning
#        3       err
#        2       crit
#        1       alert
#        0       emerg
# 
# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall log
# messages are generated by NetFilter and are logged using facility 'kern' 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.
# 
# If you have built your kernel with ULOG (IPv4 only) and/or NFLOG target
# support, you may also specify a log level of ULOG and/or NFLOG (must be all
# caps). Rather than log its messages to syslogd, Shorewall will direct netfilter
# to log the messages via the ULOG or NFLOG target which will send them to a
# process called 'ulogd'. ulogd is available with most Linux distributions
# (although it probably isn't installed by default).
# 
# Note
# 
# If you want to specify parameters to ULOG or NFLOG (e.g., NFLOG(1,0,1)), then
# you must quote the setting.
# 
# Example:
# 
STARTUP_ENABLED=No
#
# STARTUP_ENABLED={Yes|No}
# 
#     Determines if Shorewall is allowed to start. As released from
#     shorewall.net, this option is set to No. When set to Yes or yes, Shorewall
#     may be started. Used as a guard against Shorewall being accidentally
#     started before it has been configured.
# 
###############################################################################
#		              V E R B O S I T Y
###############################################################################
VERBOSITY=1
#
# VERBOSITY=[number]
# 
#     Shorewall has traditionally been very noisy (produced lots of output). You
#     may set the default level of verbosity using the VERBOSITY OPTION.
# 
#     Values are:
# 
#     0 - Silent. You may make it more verbose using the -v option
#     1 - Major progress messages displayed
#     2 - All progress messages displayed (pre Shorewall-3.2.0 behavior)
# 
#     If not specified, then 2 is assumed.
# 
###############################################################################
#			        P A G E R
###############################################################################
PAGER=
#
# PAGER=pathname
# 
#     Added in Shorewall 5.0.6. Specifies a path name of a pager program like 
#     less or more. When PAGER is given, the output of verbose status commands
#     and the dump command are piped through the named program when the output
#     file is a terminal.
# 
#     Beginning with Shorewall 5.0.12, the default value of this option is the
#     DEFAULT_PAGER setting in shorewallrc.
# 
###############################################################################
#			     F I R E W A L L
###############################################################################
FIREWALL=
#
# FIREWALL=[dnsname-or-ip-address]
# 
#     This option was added in Shorewall 5.0.13 and may be used on an
#     administrative system in directories containing the configurations of
#     remote firewalls. The contents of the variable are the default value for
#     the system parameter to the remote-start, remote-reload and remote-restart
#     commands.
# 
###############################################################################
#		                L O G G I N G
###############################################################################
LOG_LEVEL=info
#
# LOG_LEVEL=log-level[:log-tag]
# 
#     Added in Shorewall 5.1.2. Beginning with that release, the sample
#     configurations use this as the default log level and changing it will
#     change all packet logging done by the configuration. In any configuration
#     file (except shorewall-params(5)), $LOG_LEVEL will expand to this value.
# 
BLACKLIST_LOG_LEVEL=
#
# BLACKLIST_LOG_LEVEL=[log-level[:log-tag]]
# 
#     Formerly named BLACKLIST_LOGLEVEL. 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_LOG_LEVEL=debug). If you do not assign a value or if you assign
#     an empty value then packets from blacklisted hosts are not logged. The
#     setting determines the log level of packets sent to the blacklog target of
#     shorewall-blrules(5).
# 
INVALID_LOG_LEVEL=
#
# INVALID_LOG_LEVEL=log-level[:log-tag]
# 
#     Added in Shorewall 4.5.13. Packets in the INVALID state that do not match
#     any rule in the INVALID section of shorewall-rules (5) are logged at this
#     level. The default value is empty which means no logging is performed.
# 
LOG_BACKEND=
#
# LOG_BACKEND=[backend]
# 
#     Added in Shorewall 4.6.4. LOG_BACKEND determines the logging backend to be
#     used for the iptrace command (see shorewall(8)).
# 
#     backend is one of:
# 
#     LOG
# 
#         Use standard kernel logging.
# 
#     ULOG
# 
#         IPv4 only.
# 
#         Use ULOG logging to ulogd.
# 
#     netlink
# 
#         Use netlink logging to ulogd version 2 or later.
# 
LOG_MARTIANS=Yes
#
# LOG_MARTIANS=[Yes|No|Keep]
# 
#     IPv4 only.
# 
#     If set to Yes or yes, sets /proc/sys/net/ipv4/conf/*/log_martians to 1 with
#     the exception of /proc/sys/net/ipv4/conf/all/log_martians which is set to
#     0. The default value is Yes which sets both of the above to one. If you do
#     not enable martian logging for all interfaces, you may still enable it for
#     individual interfaces using the logmartians interface option in
#     shorewall-interfaces(5).
# 
#     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(5).
# 
LOG_VERBOSITY=2
#
# LOG_VERBOSITY=[number]
# 
#     This option controls the amount of information logged to the file specified
#     in the STARTUP_LOG option.
# 
#     Values are:
# 
#     -1 - Logging is disabled
#     0 - Silent. Only error messages are logged.
#     1 - Major progress messages logged.
#     2 - All progress messages logged
# 
#     If not specified, then -1 is assumed.
# 
LOG_ZONE=Both
#
# LOG_ZONE=[src|dst|both]
# 
#     Added in Shorewall 5.2.0. When a log message is issued from a chain that
#     relates to a pair of zones (e.g, 'fw-net'), the chain name normally appears
#     in the log message (unless LOGTAGONLY=Yes and a log tag is specified). This
#     can prevent OPTIMIZE category 8 from combining chains which are identical
#     except for the names of the zones involved. LOG_ZONE allows for only the
#     source or destination zone to appear in the messages by setting LOG_ZONE to
#     src or dest respectively. If LOG_ZONE=both (the default), then the full
#     chain name is included in log messages.
# 
LOGALLNEW=
#
# LOGALLNEW=[log-level]
# 
#     This option is intended for use as a debugging aid. When set to a log
#     level, this option causes Shorewall to generate a logging rule as the first
#     rule in each builtin chain.
# 
#       □ The table name is used as the chain name in the log prefix.
# 
#       □ The chain name is used as the target in the log prefix.
# 
#         For example, using the default LOGFORMAT, the log prefix for logging
#         from the nat table's PREROUTING chain is as follows in versions prior
#         to 5.1.0:
# 
#             Shorewall:nat:PREROUTING
# 
# 
#         In Shorewall 5.1.0 and later releases, the log prefix is:
# 
#             nat:PREROUTING
# 
# 
#         Important
# 
#         To help insure that all packets in the NEW state are logged, rate
#         limiting (LOGLIMIT) should be disabled when using LOGALLNEW. Use
#         LOGALLNEW at your own risk; it may cause high CPU and disk utilization
#         and you may not be able to control your firewall after you enable this
#         option.
# 
#         Caution
# 
#         Do not use this option if the resulting log messages will be sent to
#         another system.
# 
LOGFILE=/var/log/messages
#
# LOGFILE=[pathname|systemd]
# 
#     This parameter tells the /sbin/shorewall program where to look for
#     Shorewall messages when processing the dump, logwatch, show log, and hits
#     commands. If not assigned or if assigned an empty value, /var/log/messages
#     is assumed. For further information, see shorewall-logging(8). Beginning
#     with Shorewall 5.0.10.1, you may specify systemd to use journelctl -r to
#     read the log.
# 
LOGFORMAT="%s %s "
#
# LOGFORMAT=["formattemplate"]
# 
#     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.
# 
#     Note
# 
#     The setting of LOGFORMAT has an effect of the permitted length of zone
#     names. See shorewall-zones (5).
# 
#     Caution
# 
#     Beginning with Shorewall 5.1.0, the default and sample shorewall[6].conf
#     files set LOGFORMAT="%s %s ".
# 
#     Regardless of the LOGFORMAT setting, Shorewall IPv4 log messages that use
#     this LOGFORMAT can be uniquely identified using the following regular
#     expression:
# 
#     'IN=.* OUT=.* SRC=.*\..* DST='
# 
#     and Shorewall IPv6 log messages can be uniquely identified using the
#     following regular expression:
# 
#     'IN=.* OUT=.* SRC=.*:.* DST='
# 
#     To match all Netfilter log messages (Both IPv4 and IPv6 and regardless of
#     the LOGFORMAT setting), use:
# 
#     'IN=.* OUT=.* SRC=.* DST='
# 
LOGTAGONLY=No
#
# LOGTAGONLY=[Yes|No]
# 
#     Using LOGFORMAT=“Shorewall:%s:%s:”, chain names may not exceed 5 characters
#     or truncation of the log prefix may occur. Longer chain names may be used
#     with log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag
#     is specified then the tag is included in the log prefix in place of the
#     chain name.
# 
#     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 LOGFORMAT=
#     “Shorewall:%s:%s:”:
# 
#     Shorewall:foo:bar:
# 
#     Similarly,
# 
#     #ACTION                               SOURCE            DEST
#     LOG:info:,bar                        net                    fw
# 
#     would generate
# 
#     Shorewall:net2fw:bar:
# 
LOGLIMIT="s:1/sec:10"
#
# LOGLIMIT=[[{s|d}:]rate/{sec|second|min|minute|hour|day}[:burst]]
# 
#     Added in Shorewall 4.4.12. Limits the logging rate, either overall, or by
#     source or destination IP address.
# 
#     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.
# 
#     The keywords second and minute are accepted beginning with Shorewall
#     4.6.13.
# 
MACLIST_LOG_LEVEL="$LOG_LEVEL"
#
# MACLIST_LOG_LEVEL=[log-level[:log-tag]]
# 
#     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="").
# 
RELATED_LOG_LEVEL=
#
# RELATED_LOG_LEVEL=log-level[:log-tag]
# 
#     Added in Shorewall 4.4.27. Packets in the related state that do not match
#     any rule in the RELATED section of shorewall-rules (5) are logged at this
#     level. The default value is empty which means no logging is performed.
# 
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
#
# RPFILTER_LOG_LEVEL=log-level[:log-tag]
# 
#     Added in shorewall 4.5.7. Determines the logging of packets disposed via
#     the RPFILTER_DISPOSITION. The default value is info.
# 
SFILTER_LOG_LEVEL="$LOG_LEVEL"
#
# SFILTER_LOG_LEVEL=log-level[:log-tag]
# 
#     Added on Shorewall 4.4.20. Determines the logging of packets matching the
#     sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
#     interfaces without the routeback option.^[2] The default is info. If you
#     don't wish for these packets to be logged, use SFILTER_LOG_LEVEL=none.
# 
SMURF_LOG_LEVEL="$LOG_LEVEL"
#
# SMURF_LOG_LEVEL=[log-level[:log-tag]]
# 
#     Specifies the logging level for smurf packets (see the nosmurfs option in
#     shorewall-interfaces(5)). If set to the empty value ( SMURF_LOG_LEVEL="" )
#     then smurfs are not logged.
# 
STARTUP_LOG=/var/log/shorewall-init.log
#
# STARTUP_LOG=[pathname]
# 
#     If specified, determines where Shorewall will log the details of each start
#     , reload, restart, try, and safe-* command. Logging verbosity is determined
#     by the setting of LOG_VERBOSITY above.
# 
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
#
# TCP_FLAGS_LOG_LEVEL=[log-level[:log-tag]]
# 
#     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="").
# 
UNTRACKED_LOG_LEVEL=
#
# UNTRACKED_LOG_LEVEL=log-level[:log-tag]
# 
#     Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do not match
#     any rule in the UNTRACKED section of shorewall-rules (5) are logged at this
#     level. The default value is empty which means no logging is performed.
# 
###############################################################################
#	L O C A T I O N	  O F	F I L E S   A N D   D I R E C T O R I E S
###############################################################################
ARPTABLES=
#
# ARPTABLES=[pathname]
# 
#     Added in Shorewall 4.5.12 and available in IPv4 only. This parameter names
#     the arptables executable to be used by Shorewall. If not specified or if
#     specified as a null value, then the arptables executable located using the
#     PATH option is used.
# 
#     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.
# 
CONFIG_PATH=":${CONFDIR}/shorewall:${SHAREDIR}/shorewall"
#
# CONFIG_PATH=[[:]directory[:directory]...]
# 
#     Specifies where configuration files other than shorewall[6].conf may be
#     found. CONFIG_PATH is specifies as a list of directory names separated by
#     colons (":"). When looking for a configuration file:
# 
#       □ If the command is "try" or a "<configuration directory>" was specified
#         in the command (e.g., shorewall [-6] check ./gateway) then the
#         directory given in the command is searched first.
# 
#       □ Next, each directory in the CONFIG_PATH setting is searched in
#         sequence.
# 
#     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.
# 
#     Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin with a
#     colon (":"), to signal that the first directory listed will be skipped if
#     the user performing a compilation is not root or if the configuration is
#     being compiled for export (-e option specified or if running one of the
#     remote-* commands) . This prevents the compiler from looking in /etc/
#     shorewall[6]/ when compilation is being done by a non-root user or if the
#     generated script is to be sent to a remote firewall system.
# 
GEOIPDIR=/usr/share/xt_geoip/LE
#
# GEOIPDIR=[pathname]
# 
#     Added in Shorewall 4.5.4. Specifies the pathname of the directory
#     containing the GeoIP Match database. See https://shorewall.org/
#     ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/
#     LE which is the default location of the little-endian database.
# 
IPTABLES=
#
# IPTABLES=[pathname]
# 
#     IPv4 only.
# 
#     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.
# 
#     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.
# 
IP=
#
# IP=[pathname]
# 
#     If specified, gives the pathname of the 'ip' executable. If not specified,
#     'ip' is assumed and the utility will be located using the current PATH
#     setting.
# 
IPSET=
#
# IPSET=[pathname]
# 
#     If specified, gives the pathname of the 'ipset' executable. If not
#     specified, 'ipset' is assumed and the utility will be located using the
#     current PATH setting.
# 
LOCKFILE=
#
# LOCKFILE=[pathname]
# 
#     Specifies the name of the Shorewall[6] lock file, used to prevent
#     simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall
#     [6]/lock is assumed (${VARDIR} is normally /var/lib but can be changed when
#     Shorewall-core is installed -- see the output of shorewall show vardir).
# 
MODULESDIR=
#
# MODULESDIR=[[+]pathname[:pathname]...]
# 
#     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/kernel/net/ipv${g_family}/
#     netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/
#     kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
#     where uname holds the output of 'uname -r' and g_family holds '4' in IPv4
#     configurations and '6' in IPv6 configurations.
# 
#     The option plus sign ('+') was added in Shorewall 5.0.3 and causes the
#     listed pathnames to be appended to the default list above.
# 
NFACCT=
#
# NFACCT=[pathname]
# 
#     Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If
#     not specified, Shorewall will use the PATH setting to find the program.
# 
PERL=/usr/bin/perl
#
# PERL=pathname
# 
#     Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
#     executable. Default is /usr/bin/perl. If the pathname specified by this
#     option does not exist or the named file is not executable, then Shorewall
#     falls back to /usr/bin/perl
# 
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
#
# PATH=pathname[:pathname]...
# 
#     Determines the order in which Shorewall searches directories for executable
#     files.
# 
RESTOREFILE=restore
#
# RESTOREFILE=filename
# 
#     Specifies the simple name of a file in /var/lib/shorewall to be used as the
#     default restore script in the shorewall [-6] save, shorewall [-6] restore, 
#     shorewall [-6] forget and shorewall [6] -f start commands.
# 
SHOREWALL_SHELL=/bin/sh
#
# SHOREWALL_SHELL=[pathname]
# 
#     This option is used to specify the shell program to be used to interpret
#     the compiled script. If not specified or specified as a null value, /bin/sh
#     is assumed. Using a light-weight shell such as ash or dash can
#     significantly improve performance.
# 
SUBSYSLOCK=
#
# SUBSYSLOCK=[pathname]
# 
#     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 OpenSuSE, this should be set to /var/lock/subsys/shorewall
#     (var/lock/subsys/shorewall-lite if building for export). For Gentoo, it
#     should be set to /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat
#     and derivatives as well as Debian and derivatives, the pathname should be
#     omitted.
# 
#     Important
# 
#     Beginning with Shorewall 5.1.0, this setting is ignored when SERVICEDIR is
#     non-empty in ${SHAREDIR}/shorewall/shorewallrc (usually /usr/share/
#     shorewall/shorewallrc).
# 
TC=
#
# TC=[pathname]
# 
#     If specified, gives the pathname of the 'tc' executable. If not specified,
#     'tc' is assumed and the utility will be located using the current PATH
#     setting.
# 
###############################################################################
#		D E F A U L T   A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
#
# ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none}
# 
BLACKLIST_DEFAULT="Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
#
# BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
# 
DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)"
#
# DROP_DEFAULT={action[(parameters)][:level][,...]|none}
# 
NFQUEUE_DEFAULT="none"
#
# NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
# 
QUEUE_DEFAULT="none"
#
# QUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
# 
REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP)"
#
# REJECT_DEFAULT={action[(parameters)][:level][,...]|none}
# 
#     In earlier Shorewall versions, a "default action" for DROP and REJECT
#     policies was specified in the file /usr/share/shorewall/actions.std.
# 
#     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:
# 
#     a) The name of an action. The name may optionally be followed by a
#     comma-separated list of parameters enclosed in parentheses if the specified
#     action accepts parameters (e.g., 'Drop(audit)').
#     c) None or none
# 
#     Prior to Shorewall 5.1.2, the default values are:
# 
#     DROP_DEFAULT="Drop"
#     REJECT_DEFAULT="Reject"
#     BLACKLIST_DEFAULT="Drop" (added in Shorewall 5.1.1)
#     ACCEPT_DEFAULT="none"
#     QUEUE_DEFAULT="none"
#     NFQUEUE_DEFAULT="none"
# 
#     Beginning with Shorewall 5.1.2, the default value is 'none' for all of
#     these. Note that the sample configuration files do, however, provide
#     settings for DROP_DEFAULT, BLACKLIST_DEFAULT and REJECT_DEFAULT.
# 
#     If you set the value of either option to "None" then no default action will
#     be used and the default action or macro must be specified in
#     shorewall-policy(5).
# 
#     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.
# 
#     Beginning with Shorewall 5.1.2, multiple action[(parameters)][:level]
#     specifications may be listed, separated by commas.
# 
###############################################################################
#                        R S H / R C P  C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
#
# RCP_COMMAND="command"
# 
RSH_COMMAND='ssh ${root}@${system} ${command}'
#
# RSH_COMMAND="command"
# 
#     Earlier generations of Shorewall Lite required that remote root login via
#     ssh be enabled in order to use the load and reload commands. Beginning with
#     release 3.9.5, you may define an alternative means for accessing the remote
#     firewall system. In that release, two new options were added to
#     shorewall.conf:
# 
#     RSH_COMMAND
#     RCP_COMMAND
# 
#     The default values for these are as follows:
# 
#     RSH_COMMAND: ssh ${root}@${system} ${command}
#     RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
# 
#     Shell variables that will be set when the commands are invoked are as
#     follows:
# 
#     root        - root user. Normally root but may be overridden using the '-r' option.
#     system      - The name/IP address of the remote firewall system.
#     command     - For RSH_COMMAND, the command to be executed on the firewall system.
#     files       - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
#     destination - The directory on the remote system that the files are to be copied into.
# 
###############################################################################
#			F I R E W A L L	  O P T I O N S
###############################################################################
ACCOUNTING=Yes
#
# ACCOUNTING=[Yes|No]
# 
#     Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled
#     (see shorewall-accounting(5)). If not specified or set to the empty value,
#     ACCOUNTING=Yes is assumed.
# 
ACCOUNTING_TABLE=filter
#
# ACCOUNTING_TABLE=[filter|mangle]
# 
#     Added in Shorewall 4.4.20. This setting determines which Netfilter table
#     the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is
#     assumed. See also shorewall-accounting(5).
# 
ADD_IP_ALIASES=No
#
# ADD_IP_ALIASES=[Yes|No]
# 
#     This parameter determines whether Shorewall automatically adds the external
#     address(es) in shorewall-nat(5), and is only available in IPv4
#     configurations. 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.
# 
#     Warning
# 
#     Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added during 
#     shorewall reload and shorewall restart. As a consequence, connections using
#     those addresses may be severed.
# 
ADD_SNAT_ALIASES=No
#
# ADD_SNAT_ALIASES=[Yes|No]
# 
#     This parameter determines whether Shorewall automatically adds the SNAT
#     ADDRESS in shorewall-masq(5), and is only available in IPv4 configurations.
#     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.
# 
#     Warning
# 
#     Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added during 
#     shorewall reload and shorewall restart. As a consequence, connections using
#     those addresses may be severed.
# 
ADMINISABSENTMINDED=Yes
#
# ADMINISABSENTMINDED=[Yes|No]
# 
#     The value of this variable affects Shorewall's stopped state. The behavior
#     differs depending on whether shorewall-routestopped(5) or
#     shorewall-stoppedrules(5) is used:
# 
#     routestopped
# 
#         When ADMINISABSENTMINDED=No, only traffic to/from those addresses
#         listed in routestopped is accepted when Shorewall is stopped. When
#         ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
#         routestopped, connections that were active when Shorewall stopped
#         continue to work and all new connections from the firewall system
#         itself are allowed.
# 
#         Note that the routestopped file is not supported in Shorewall 5.0 and
#         later versions.
# 
#     stoppedrules
# 
#         All existing connections continue to work. To sever all existing
#         connections when the firewall is stopped, install the conntrack utility
#         and place the command conntrack -F in the stopped user exit (/etc/
#         shorewall/stopped).
# 
#         If ADMINISABSENTMINDED=No, only new connections matching entries in
#         stoppedrules are accepted when Shorewall is stopped. Response packets
#         and related connections are automatically accepted.
# 
#         If ADMINISABSENTMINDED=Yes, in addition to connections matching entries
#         in stoppedrules, all new connections from the firewall system itself
#         are allowed when the firewall is stopped. Response packets and related
#         connections are automatically accepted.
# 
#     If this variable is not set or is given the empty value then
#     ADMINISABSENTMINDED=No is assumed.
# 
AUTOCOMMENT=Yes
#
# AUTOCOMMENT=[Yes|No]
# 
#     Formerly named AUTO_COMMENT. If set, if there is not a current comment when
#     a macro is invoked, the behavior is as if the first line of the macro file
#     was "COMMENT <macro name>". If not specified, the AUTO_COMMENT option has a
#     default value of 'Yes'.
# 
AUTOHELPERS=Yes
#
# AUTOHELPERS=[Yes|No]
# 
#     Added in Shorewall 4.5.7. When set to Yes (the default), the generated
#     ruleset will automatically associate helpers with applications that require
#     them (FTP, IRC, etc.). When configuring your firewall on systems running
#     kernel 3.5 or later, it is recommended that you:
# 
#      1. Set AUTOHELPERS=No.
# 
#      2. Modify the HELPERS setting (see below) to list the helpers that you
#         need.
# 
#      3. Either:
# 
#          a. Modify shorewall-conntrack (5) to only apply helpers where they are
#             required; or
# 
#          b. Specify the appropriate helper in the HELPER column in
#             shorewall-rules (5).
# 
#             Note
# 
#             The macros for those applications requiring a helper automatically
#             specify the appropriate HELPER where required.
# 
AUTOMAKE=Yes
#
# AUTOMAKE=[Yes|No|recursive|depth]
# 
#     If set, the behavior of the start, reload and restart commands are changed;
#     if no files in CONFIG_PATH (see below) have been changed since the last
#     successful start, reload or restart command, then the compilation step is
#     skipped and the compiled script that executed the last start, reload or 
#     restart command is used. If not specified, the default is AUTOMAKE=No.
# 
#     The setting of the AUTOMAKE option is ignored if the start, reload or 
#     restart command includes a directory name (e.g., shorewall restart /etc/
#     shorewall.new).
# 
#     When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
#     searched recursively for files newer than the compiled script. That was
#     changed in Shorewall 5.1.10.2 such that only the listed directories
#     themselves were searched. That broke some configurations that played tricks
#     with embedded SHELL such as "SHELL cat /etc/shorewall/rules.d/loc/*.rules".
#     Prior to 5.1.10.2, a change to a file in or adding a file to /etc/shorewall
#     /rules.d/loc/ would trigger recompilation. Beginning with 5.1.10.2, such
#     changes would not trigger recompilation. Beginning with Shorewall 5.2.0,
#     the pre-5.1.10.2 behavior can be obtained by setting AUTOMAKE=recursive.
# 
#     Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a numeric depth
#     which specifies how deeply each listed directory is to be searched.
#     AUTOMAKE=1 only searches each directory itself and is equivalent to
#     AUTOMAKE=Yes. AUTOMAKE=2 will search each directory and its immediate
#     sub-directories; AUTOMAKE=3 will search each directory, each of its
#     immediate sub-directories, and each of their immediate sub-directories,
#     etc.
# 
BALANCE_PROVIDERS=No
#
# BALANCE_PROVIDERS=[Yes|No]
# 
#     Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option determines
#     whether the balance provider option (see shorewall-providers(5)) is the
#     default. When BALANCE_PROVIDERS=Yes, then the balance option is assumed
#     unless the fallback, loose, load or tproxy option is specified. If this
#     option is not set or is set to the empty value, then the default value is
#     the value of USE_DEFAULT_RT.
# 
BASIC_FILTERS=No
#
# BASIC_FILTERS=[Yes|No]
# 
#     Added in Shorewall-4.6.0. When set to Yes, causes entries in
#     shorewall-tcfilters(5) to generate a basic filter rather than a u32 filter.
#     This setting requires the Basic Ematch capability in your kernel and
#     iptables.
# 
#     Note
# 
#     One of the advantages of basic filters is that ipset matches are supported
#     in newer iproute2 and kernel versions. Because Shorewall cannot reliably
#     detect this capability, use of basic filters is controlled by this option.
# 
#     The default value is No which causes u32 filters to be generated.
# 
BLACKLIST="NEW,INVALID,UNTRACKED"
#
# BLACKLIST=[{ALL|state[,...]}]
# 
#     where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED.
# 
#     Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option. Specifies
#     the connection tracking states that are to be subject to blacklist
#     screening. If BLACKLIST is not 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=Yes is
#     specified.
# 
CLAMPMSS=No
#
# CLAMPMSS=[Yes|No|value]
# 
#     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.
# 
#     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.
# 
CLEAR_TC=Yes
#
# CLEAR_TC=[Yes|No]
# 
#     If this option is set to No then Shorewall won't clear the current traffic
#     control rules during [re]start or reload. This setting is intended for use
#     by people who 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
#     shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed.
# 
#     Warning
# 
#     When you specify TC_ENABLED=shared (see below), then you should also
#     specify CLEAR_TC=No.
# 
COMPLETE=No
#
# COMPLETE=[Yes|No]
# 
#     Added in Shorewall 4.4.12. When you set this option to Yes, you are
#     asserting that the configuration is complete so that your set of zones
#     encompasses any hosts that can send or receive traffic to/from/through the
#     firewall. This causes Shorewall to omit the rules that catch packets in
#     which the source or destination IP address is outside of any of your zones.
#     Default is No. It is recommended that this option only be set to Yes if:
# 
#       □ You have defined an interface whose effective physical setting is '+'.
# 
#       □ That interface is assigned to a zone.
# 
#       □ You have no CONTINUE policies or rules.
# 
DEFER_DNS_RESOLUTION=Yes
#
# DEFER_DNS_RESOLUTION=[Yes|No]
# 
#     Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are
#     validated in the compiler and then passed on to the generated script where
#     they are resolved by ip[6]tables-restore. This is an advantage if you use
#     AUTOMAKE=Yes and the IP address associated with the DNS name is subject to
#     change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP
#     addresses by the compiler. This has the advantage that when AUTOMAKE=Yes,
#     the start, reload and restart commands will succeed even if no DNS server
#     is reachable (assuming that the configuration hasn't changed since the
#     compiled script was last generated).
# 
#     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.
# 
DISABLE_IPV6=No
#
# DISABLE_IPV6=[Yes|No]
# 
#     IPv4 only.
# 
#     If set to Yes or yes, IPv6 traffic to, from and through the firewall system
#     is disabled. If set to No or no, Shorewall will take no action with respect
#     to allowing or disallowing IPv6 traffic. If not specified or empty,
#     “DISABLE_IPV6=No” is assumed.
# 
#     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:
# 
#       □ Install, configure and start Shorewall6.
# 
#       □ Change DISABLE_IPV6=Yes to DISABLE_IPV6=No in /etc/shorewall/
#         shorewall.conf.
# 
#       □ Reload Shorewall
# 
DOCKER=No
#
# DOCKER=[Yes|No]
# 
#     Added in Shorewall 5.0.6; IPv4 only. When set to Yes, the generated script
#     will save Docker-generated rules before and restore them after executing
#     the start, stop, reload and restart commands. If set to No (the default),
#     the generated script will delete any Docker-generated rules when executing
#     those commands. See https://shorewall.org/Docker.html for additional
#     information.
# 
DOCKER_BRIDGE=docker0
#
# DOCKER_BRIDGE=[bridgename]
# 
#     Added in Shorewall 5.2.4; IPv4 only. Specifies the name of the default
#     Docker bridge. If not specified, the value 'docker0' is assumed.
# 
DELETE_THEN_ADD=Yes
#
# DELETE_THEN_ADD={Yes|No}
# 
#     If set to Yes (the default value), entries in the /etc/shorewall[6]/rtrules
#     files cause an 'ip rule del' command to be generated in addition to an 'ip
#     rule add' command. Setting this option to No, causes the 'ip rule del'
#     command to be omitted.
# 
DETECT_DNAT_IPADDRS=No
#
# DETECT_DNAT_IPADDRS=[Yes|No]
# 
#     IPv4 only.
# 
#     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_IPADDRS=Yes” is assumed.
# 
DONT_LOAD=
#
# DONT_LOAD=[module[,module]...]
# 
#     Causes Shorewall to not load the listed kernel modules.
# 
DYNAMIC_BLACKLIST=Yes
#
# DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:l
#     og_tag]]]}
# 
#     Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
#     blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l] reject, 
#     shorewall logdrop and shorewall [-6] [-l] logreject is disabled. Default is
#     Yes. Beginning with Shorewall 5.0.8, ipset-based dynamic blacklisting using
#     the shorewall blacklist command is also supported. The name of the set (
#     setname) and the level (log_level), if any, at which blacklisted traffic is
#     to be logged may also be specified. The default IPv4 set name is SW_DBL4
#     and the default IPv6 set name is SW_DBL6. The default log level is none (no
#     logging). If ipset-only is given, then chain-based dynamic blacklisting is
#     disabled just as if DYNAMIC_BLACKLISTING=No had been specified.
# 
#     Possible options are:
# 
#     src-dst
# 
#         Normally, only packets whose source address matches an entry in the
#         ipset are dropped. If src-dst is included, then packets whose
#         destination address matches an entry in the ipset are also dropped.
# 
#     disconnect
# 
#         The disconnect option was added in Shorewall 5.0.13 and requires that
#         the conntrack utility be installed on the firewall system. When an
#         address is blacklisted using the blacklist command, all connections
#         originating from that address are disconnected. if the src-dst option
#         was also specified, then all connections to that address are also
#         disconnected.
# 
#     timeout=seconds
# 
#         Added in Shorewall 5.0.13. Normally, Shorewall creates the dynamic
#         blacklisting ipset with timeout 0 which means that entries are
#         permanent. If you want entries in the set that are not accessed for a
#         period of time to be deleted from the set, you may specify that period
#         using this option. Note that the blacklist command can override the
#         ipset's timeout setting.
# 
#         Important
# 
#         Once the dynamic blacklisting ipset has been created, changing this
#         option setting requires a complete restart of the firewall; shorewall
#         [-6] restart if RESTART=restart, otherwise shorewall [-6] [-l] stop &&
#         shorewall [-6] [-l] start
# 
#     log
# 
#         Added in Shorewall 5.2.5. When specified, successful 'blacklist' and
#         'allow' commands will log a message to the system log.
# 
#     noupdate
# 
#         Added in Shorewall 5.2.5. Normally, once an address has been
#         blacklisted, each time that a packet is received from the packet, the
#         ipset's entry for the address is updated to reset the timeout to the
#         value specifyed in the timeout option above. Setting the noupdate
#         option, inhibits this resetting of the entry's timeout. This option is
#         ignored when the timeout option is not specified.
# 
#     When ipset-based dynamic blacklisting is enabled, the contents of the
#     blacklist will be preserved over stop/reboot/start sequences.
# 
EXPAND_POLICIES=Yes
#
# EXPAND_POLICIES={Yes|No}
# 
#     Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains
#     'all', a single policy chain is created and thes policy is enforced in that
#     chain. For example, if the policy entry is
# 
#     #SOURCE DEST POLICY LOG
#     #                   LEVEL
#     net     all  DROP   info
# 
#     then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) 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.
# 
EXPORTMODULES=Yes
#
# EXPORTMODULES=[Yes|No]
# 
#     Added in Shorewall 4.4.17. When set to Yes when compiling for use by
#     Shorewall Lite (shorewall [-6] remote-start, shorewall [-6] remote-reload,
#     shorewall [-6] remote-restart or shorewall [-6] export commands), the
#     compiler will copy the modules or helpers file from the administrative
#     system into the script. When set to No or not specified, the compiler will
#     not copy the modules or helpers file from /usr/share/shorewall[6] but will
#     copy those found in another location on the CONFIG_PATH.
# 
#     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.
# 
FASTACCEPT=No
#
# FASTACCEPT={Yes|No}
# 
#     Normally, Shorewall defers 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 'loc-net' or 'loc2net'
#     chain, depending on the setting of ZONE2ZONE (see below).
# 
#     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(5).
# 
FORWARD_CLEAR_MARK=
#
# FORWARD_CLEAR_MARK={Yes|No}
# 
#     Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the packet
#     mark in the first rule in the mangle FORWARD chain. This behavior is
#     maintained with the default setting of this option (FORWARD_CLEAR_MARK=
#     Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle
#     PREROUTING chain are retained in the FORWARD chains.
# 
HELPERS=
#
# HELPERS=[helper[,helper...]]
# 
#     Added in Shorewall 4.5.7. This option specifies a comma-separated list
#     naming the Netfilter application helpers that are to be enabled. If not
#     specified, the default is to enable all helpers.
# 
#     Possible values for helper are:
# 
#       □ amanda
# 
#       □ ftp
# 
#       □ h323
# 
#       □ irc
# 
#       □ netbios-ns
# 
#       □ none - This special value was added in Shorewall 4.5.16 and indicates
#         that no helpers are to be enabled. It also prevents the compiler for
#         probing for helper support; such probing generates messages on the
#         system log of the form "xt_CT: No such helper XXX" where XXX is the
#         helper name. When used, none must be the only helper specified.
# 
#       □ pptp
# 
#       □ sane
# 
#       □ sip
# 
#       □ snmp
# 
#       □ tftp
# 
#     When HELPERS is specified on a system running Kernel 3.5.0 or later,
#     automatic association of helpers to connections is disabled.
# 
IGNOREUNKNOWNVARIABLES=No
#
# IGNOREUNKNOWNVARIABLES=[Yes|No]
# 
#     Added in Shorewall 4.5.11. Normally, if an unknown shell variable is
#     encountered in a configuration file (except in ?IF and ?ELSIF directives),
#     the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes,
#     then such variables simply expand to an empty string. Default is No.
# 
IMPLICIT_CONTINUE=No
#
# IMPLICIT_CONTINUE={Yes|No}
# 
#     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 shorewall-zones(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(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).
# 
IPSET_WARNINGS=Yes
#
# IPSET_WARNINGS={Yes|No}
# 
#     Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules
#     compiler to issue a warning when:
# 
#       □ The compiler is being run by root and an ipset specified in the
#         configuration does not exists. Only one warning is issued for each
#         missing ipset.
# 
#       □ When [src] is specified in a destination column and when [dst] is
#         specified in a source column.
# 
IP_FORWARDING=Off
#
# IP_FORWARDING=[On|Off|Keep]
# 
#     This IPv4 parameter determines whether Shorewall enables or disables IPv4
#     Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In an IPv6
#     configuration, this parameter determines the setting of /proc/sys/net/ipv6/
#     config/all/ip_forwarding.
# 
#     Possible values are:
# 
#     On or on
# 
#         packet forwarding will be enabled.
# 
#     Off or off
# 
#         packet forwarding will be disabled.
# 
#     Keep or keep
# 
#         Shorewall will neither enable nor disable packet forwarding.
# 
#     If this variable is not set or is given an empty value (IP_FORWARD="") then
#     IP_FORWARD=On is assumed.
# 
KEEP_RT_TABLES=No
#
# KEEP_RT_TABLES={Yes|No}
# 
#     IPv4:
# 
#         When set to Yes, this option prevents generated scripts from altering
#         the /etc/iproute2/rt_tables database when there are entries in /etc/
#         shorewall/providers. If you set this option to Yes while Shorewall
#         (Shorewall-lite) is running, you should remove the file /var/lib/
#         shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your
#         next stop, restore, reload or restart command.
# 
#     IPv6:
# 
#         When set to Yes, this option prevents scripts generated by Shorewall6
#         from altering the /etc/iproute2/rt_tables database when there are
#         entries in /etc/shorewall6/providers. If you set this option to Yes
#         while Shorewall6 (Shorewall6-lite) is running, you should remove the
#         file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
#         before your next stop, restore, reload or restart command.
# 
#     Important
# 
#     When both IPv4 and IPv6 Shorewall configurations are present,
#     KEEP_RT_TABLES=No should be specified in only one of the two configurations
#     unless the two provider configurations are identical with respect to
#     interface and provider names and numbers.
# 
#     The default is KEEP_RT_TABLES=No.
# 
MACLIST_TABLE=filter
#
# MACLIST_TABLE=[filter|mangle]
# 
#     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 or MACLIST_DISPOSITION=A_REJECT with
#     MACLIST_TABLE=mangle.
# 
MACLIST_TTL=
#
# MACLIST_TTL=[number]
# 
#     The performance of configurations with a large numbers of entries in
#     shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in
#     shorewall[6].conf(5).
# 
#     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(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).
# 
MANGLE_ENABLED=Yes
#
# MANGLE_ENABLED=[Yes|No]
# 
#     Determines whether Shorewall will generate rules in the Netfilter mangle
#     table. Setting MANGLE_ENABLED=No disables all Shorewall features that
#     require the mangle table. The default is MANGLE_ENABLED=Yes.
# 
MINIUPNPD=No
#
# MINIUPNPD=[Yes|No]
# 
#     Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a chain in
#     the nat table named MINIUPNPD-POSTROUTING and will add jumps from
#     POSTROUTING to that chain for each interface with the upnpd option
#     specified. Default is No.
# 
MARK_IN_FORWARD_CHAIN=No
#
# MARK_IN_FORWARD_CHAIN=[Yes|No]
# 
#     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
#     DNAT is in use. To determine if your kernel has a FORWARD chain in the
#     mangle table, use the shorewall [-6] 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.
# 
MULTICAST=No
#
# MULTICAST=[Yes|No]
# 
#     IPv4 only.
# 
#     This option will normally be set to 'No' (the default). It should be set to
#     'Yes' under the following circumstances:
# 
#      1. You have an interface that has parallel zones defined via /etc/
#         shorewall/hosts.
# 
#      2. You want to forward multicast packets to two or more of those parallel
#         zones.
# 
#     In such cases, you will configure a destonly network on each zone receiving
#     multicasts.
# 
MUTEX_TIMEOUT=60
#
# MUTEX_TIMEOUT=[seconds]
# 
#     The value of this variable determines the number of seconds that programs
#     will wait for exclusive access to the Shorewall[6] lock file. After the
#     number of seconds corresponding to the value of this variable, programs
#     will assume that the last program to hold the lock died without releasing
#     the lock.
# 
#     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 [-6] restart
#     command.
# 
NULL_ROUTE_RFC1918=No
#
# NULL_ROUTE_RFC1918=[Yes|No|blackhole|unreachable|prohibit]
# 
#     IPv4 only.
# 
#     When set to Yes, causes Shorewall to null-route the IPv4 address ranges
#     reserved by RFC1918. The default value is 'No'.
# 
#     When combined with route filtering (ROUTE_FILTER=Yes or routefilter in
#     shorewall-interfaces(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 https://shorewall.org/
#     MultiISP.html#null_routing.
# 
OPTIMIZE=All
#
# OPTIMIZE=[value]
# 
#     The specified value enables certain optimizations. Each optimization
#     category is associated with a power of two. To enable multiple optimization
#     categories, simply add their corresponding numbers together.
# 
#     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.
# 
#       □ Optimization category 1 - Traditionally, Shorewall has created rules
#         for the complete matrix of host groups defined by the zones, interfaces
#         and hosts files. Any traffic that didn't correspond to an element of
#         that matrix was rejected in one of the built-in chains. When the matrix
#         is sparse, this results in lots of largely useless rules.
# 
#         These extra rules can be eliminated by setting the 1 bit in OPTIMIZE.
# 
#         The 1 bit 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.
# 
#         Note
# 
#         Optimization level 1 is ignored when optimization level 4 is also
#         selected, since level 4 performs similar optimizations in a more robust
#         way.
# 
#       □ Optimization category 2 - Added in Shorewall 4.4.7. When set,
#         suppresses superfluous ACCEPT rules in a policy chain that implements
#         an ACCEPT policy. Any ACCEPT rules that immediately precede the final
#         blanket ACCEPT rule in the chain are now omitted.
# 
#       □ Optimization category 4 - Added in Shorewall 4.4.7. When set, causes
#         short chains (those with less than 2 rules) to be optimized away. The
#         following chains are excluded from optimization:
# 
#           ☆ accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
# 
#           ☆ action chains (user-defined)
# 
#           ☆ 'blacklst' chain
# 
#           ☆ dynamic
# 
#           ☆ forwardUPnP
# 
#           ☆ UPnP (nat table)
# 
#         Additionally:
# 
#           ☆ If a built-in chain has a single rule that branches to a second
#             chain, then the rules from the second chain are moved to the
#             built-in chain and the target chain is omitted.
# 
#           ☆ Chains with no references are deleted.
# 
#           ☆ Accounting chains are subject to optimization if the
#             OPTIMIZE_ACCOUNTING option is set to 'Yes'.
# 
#           ☆ If a chain ends with an unconditional branch to a second chain
#             (other than to 'reject'), then the branch is deleted from the first
#             chain and the rules from the second chain are appended to it.
# 
#         An additional optimization was added in Shorewall 4.5.4. If the last
#         rule in a chain is an unqualified jump to a simple target, then all
#         immediately preceding rules with the same simple target are omitted.
# 
#         For example, consider this chain:
# 
#                 -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
# 
#         Since all of the rules are jumps to the simple target ACCEPT, this
#         chain is totally optimized away and jumps to the chain are replace with
#         jumps to ACCEPT.
# 
#       □ Optimization category 8 - Added in Shorewall 4.4.9. When set, causes
#         chains with identical rules to be collapsed into a single chain.
# 
#         Warning
# 
#         While Optimization category 8 can significantly reduce the size of the
#         generated iptables ruleset, it can also take significant system
#         resources during compilation. If you find that compilation takes an
#         unreasonably long time, try disabling this category by setting OPTIMIZE
#         =23.
# 
#       □ Optimization category 16 - Added in Shorewall 4.4.26. When set, causes
#         sequences of compatible rules to be combined into a single rule. Rules
#         are considered compatible if they differ only in their destination
#         ports and comments.
# 
#         A sequence of compatible rules is often generated when macros are
#         invoked in sequence.
# 
#         The ability to combine adjacent rules is limited by two factors:
# 
#           ☆ Destination port lists may only be combined up to a maximum of 15
#             ports, where a port-pair counts as two ports.
# 
#           ☆ Rules may only be combined until the length of their concatenated
#             comment reaches 255 characters.
# 
#         When either of these limits would be exceeded, the current combined
#         rule is emitted and the compiler attempts to combine rules beginning
#         with the one that would have exceeded the limit. Adjacent combined
#         comments are separated by ', '. Empty comments at the front of a group
#         of combined comments are replaced by 'Others and'. Empty comments at
#         the end of a group of combined comments are replaced by 'and others'.
# 
#         Beginning in Shorewall 4.5.10, this option also suppresses duplicate
#         adjacent rules and duplicate non-adjacent rules that don't include mark
#         , connmark, dscp, ecn, set, tos or u32 matches.
# 
#         Example 1:
# 
#             Rules with comments "FOO", <empty> and "BAR" would result in the
#             combined comment "FOO and others, BAR".
# 
#         Example 2:
# 
#             Rules with comments <empty>, "FOO" and "BAR" would result in the
#             combined comment "Others and FOO, BAR". Note: Optimize level 16
#             requires "Extended Multi-port Match" in your iptables and kernel.
# 
#     In versions prior to 5.1.0, the default value is zero which disables all
#     optimizations. Beginning with Shorewall 5.1.0, the default value is All
#     which enables all optimizations.
# 
OPTIMIZE_ACCOUNTING=No
#
# OPTIMIZE_ACCOUNTING=[Yes|No]
# 
#     Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are
#     subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to
#     the empty value, OPTIMIZE_ACCOUNTING=No is assumed.
# 
PERL_HASH_SEED=0
#
# PERL_HASH_SEED=seed|random
# 
#     Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in the range
#     0-99999) when running the Shorewall rules compiler. If not specified, the
#     value 0 is assumed. If random is specified, a random seed will be chosed by
#     Perl. See perlsec(1) for additional information.
# 
REJECT_ACTION=
#
# REJECT_ACTION=action
# 
#     Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall
#     normally handles the response as follows:
# 
#       □ If the destination address of the packet is a broadcast or multicast
#         address, the packet is dropped.
# 
#       □ if the protocol is ICMP (2) then the packet is dropped.
# 
#       □ if the protocol is TCP (6) then the packet is rejected with an RST.
# 
#       □ if the protocol is UDP (17) then the packet is rejected with an
#         'port-unreachable' ICMP.
# 
#       □ if the protocol is ICMP (1) then the packet is rejected with a
#         'host-unreachable' ICMP.
# 
#       □ if the protocol is ICMP6 (1) then the packet is rejected with a
#         'icmp6-addr-unreachable' ICMP6.
# 
#       □ otherwise, the packet is rejected with a 'host-prohibited' ICMP.
# 
#     You can modify this behavior by implementing your own action that handles
#     REJECT and specifying it's name in this option. The nolog and noinline
#     options will automatically be assumed for the specified action.
# 
#     The following action implements the default reject action:
# 
#     ?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
# 
RENAME_COMBINED=Yes
#
# RENAME_COMBINED=[Yes|No]
# 
#     Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8 is
#     enabled, identical chains are combined under a name beginning with '~comb'
#     or '~blacklist'. This behavior is maintained under the default setting
#     RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the chains are combined under
#     the original name of one of the chains.
# 
REQUIRE_INTERFACE=No
#
# REQUIRE_INTERFACE=[Yes|No]
# 
#     Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one
#     optional interface must be up in order for the firewall to be in the
#     started state. Intended to be used with the Shorewall Init Package.
# 
RESTART=restart
#
# RESTART=[restart|reload]
# 
#     Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added in
#     Shorewall 5.0.0. In that release, the reload command was redefined to do
#     what restart had done in earlier releases and restart became a true restart
#     (equivalent to stop followed by start). When RESTART=reload, the restart
#     command performs the same operation as the reload command making it
#     compatible with earlier releases. If not specified, RESTART=reload is
#     assumed.
# 
RESTORE_DEFAULT_ROUTE=Yes
#
# RESTORE_DEFAULT_ROUTE=[Yes|No]
# 
#     This option determines whether to restore the default route saved when here
#     are 'balance' providers defined but all of them are down.
# 
#     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.
# 
RESTORE_ROUTEMARKS=Yes
#
# RESTORE_ROUTEMARKS=[Yes|No]
# 
#     Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
#     restored unconditionally at the top of the mangle OUTPUT and PREROUTING
#     chains, even if the saved mark is zero. When this option is set to No, the
#     mark is restored only if it is non-zero. If you have problems with IPSEC
#     ESP packets not being routed correctly on output, try setting this option
#     to No.
# 
RETAIN_ALIASES=No
#
# RETAIN_ALIASES={Yes|No}
# 
#     IPv4 only.
# 
#     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
#     shorewall-nat(5) and shorewall-masq(5) 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, shorewall reload or shorewall restart.
# 
ROUTE_FILTER=No
#
# ROUTE_FILTER=[Yes|No|Keep]
# 
#     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.
# 
#     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(5).
# 
#     Important
# 
#     If you need to disable route filtering on any interface, then you must set
#     ROUTE_FILTER=No then set routefilter=1 or routefilter=2 on those interfaces
#     where you want route filtering. See shorewall-interfaces(5) for additional
#     details.
# 
SAVE_ARPTABLES=No
#
# SAVE_ARPTABLES={Yes|No}
# 
#     Added in Shorewall 4.5.12. If SAVE_ARPTABLES=Yes, then the current
#     arptables contents will be saved by shorewall save command and restored by 
#     shorewall restore command. Default value is No.
# 
SAVE_IPSETS=No
#
# SAVE_IPSETS={Yes|No|ipv4|setlist}
# 
#     Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
#     contents of your ipsets will be saved by the shorewall stop and shorewall
#     save commands and restored by the shorewall start and shorewall restore
#     commands.
# 
#     Beginning with Shorewall 4.6.4, you can restrict the set of ipsets saved by
#     specifying a setlist (a comma-separated list of ipv4 ipset names). You may
#     also restrict the saved sets to just the ipv4 ones by specifying ipv4.
# 
TC_ENABLED=Internal
#
# TC_ENABLED=[Yes|No|Internal|Simple|Shared]
# 
#     If you say Yes or yes here, Shorewall will use a script that you supply to
#     configure traffic shaping. The script must be named 'tcstart' and must be
#     placed in a directory on your CONFIG_PATH.
# 
#     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(5) and shorewall-tcpri(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/).
# 
TC_EXPERT=No
#
# TC_EXPERT={Yes|No}
# 
#     Normally, Shorewall tries to protect users from themselves by preventing
#     PREROUTING and OUTPUT tcrules from being applied to packets that have been
#     marked by the 'track' option in shorewall-providers(5).
# 
#     If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
#     will not include these cautionary checks.
# 
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
#
# TC_PRIOMAP=map
# 
#     Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to
#     priority bands. See shorewall-tcpri(5). The map consists of 16
#     space-separated digits with values 1, 2 or 3. A value of 1 corresponds to
#     Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The
#     first entry gives the priority of TOS value 0, the second of TOS value 1,
#     and so on. See tc-prio(8) for additional information.
# 
#     The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2".
# 
TRACK_PROVIDERS=Yes
#
# TRACK_PROVIDERS={Yes|No}
# 
#     Added in Shorewall 4.4.3. When set to Yes, causes the track option to be
#     assumed on all providers defined in shorewall-providers(5). May be
#     overridden on an individual provider through use of the notrack option. The
#     default value is 'No'.
# 
#     Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies
#     PREROUTING rules in shorewall-tcrules(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.
# 
TRACK_RULES=No
#
# TRACK_RULES={Yes|No|File}
# 
#     Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a
#     comment to iptables rules to indicate the file name and line number of the
#     configuration entry that generated the rule. If set to No (the default),
#     then no such comments are added.
# 
#     Setting this option to Yes requires the Comments capability in iptables and
#     kernel.
# 
#     Beginning with Shorewall 5.0.5, the option may also be set to File. That
#     setting causes similar comments to be added to the .iptables-restore-input
#     file, which is normally created in /var/lib/shorewall.
# 
USE_DEFAULT_RT=Yes
#
# USE_DEFAULT_RT=[Yes|No]
# 
#     When set to 'Yes', this option causes the Shorewall multi-ISP feature to
#     create a set of routing rules which are resilient to changes in the main
#     routing table. Such changes can occur for a number of reasons, VPNs going
#     up and down being an example. The idea is to send packets through the main
#     table prior to applying any of the Shorewall-generated routing rules. So
#     changes to the main table will affect the routing of packets by default.
# 
#     When USE_DEFAULT_RT=Yes:
# 
#      1. Both the DUPLICATE and the COPY columns in providers(5) file must
#         remain empty (or contain "-").
# 
#      2. The default route is added to the the 'default' table rather than to
#         the main table.
# 
#      3. If running Shorewall 5.1.0 or earlier or if BALANCE_PROVIDERS=Yes
#         (Shorewall 5.1.1 or later), then the balance provider option is assumed
#         unless the fallback, loose, load or tproxy option is specified.
# 
#      4. Packets are sent through the main routing table by a rule with priority
#         999. In shorewall-rtrules(5), the range 1-998 may be used for inserting
#         rules that bypass the main table.
# 
#      5. All provider gateways must be specified explicitly in the GATEWAY
#         column. detect may not be specified.
# 
#         Note
# 
#         detect may be specified for interfaces whose configuration is managed
#         by dhcpcd. Shorewall will use dhcpcd's database to find the interface's
#         gateway.
# 
#      6. You should disable all default route management outside of Shorewall.
#         If a default route is added to the main table while Shorewall is
#         started, then all policy routing will stop working (except for those
#         routing rules in the priority range 1-998).
# 
#     Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it was set to
#     the empty string then USE_DEFAULT_RT=No was assumed. Beginning with
#     Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes and use of
#     USE_DEFAULT_RT=No is deprecated.
# 
#     Warning
# 
#     The enable, disable and reenable commands do not work correctly when
#     USE_DEFAULT_RT=No.
# 
USE_NFLOG_SIZE=No
#
# USE_NFLOG_SIZE=[Yes|No]
# 
#     Added in Shorewall 5.1.5. The second parameter to the NFLOG target
#     specifies how many bytes of the packet to copy to the log; if omitted or if
#     supplied as zero, the entire packet is copied. This feature has
#     traditionally been implemented using the --nflog-range option to the NFLOG
#     iptables target. Unfortuntely, the --nflog-range option never worked (the
#     entire packet was always copied). To deal with this issue, the Netfilter
#     team:
# 
#       □ Added a warning message when --nflog-range is used
# 
#       □ Added --nflog-size which works like --nflog-range was intended to work.
# 
#     When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new --nflog-size
#     feature. If that feature is not available in the running kernel and ip[6]
#     tables, an error is raised.
# 
#     When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed. When
#     USE_NFLOG_SIZE is added by shorewall update, it is added with setting No.
# 
USE_PHYSICAL_NAMES=No
#
# USE_PHYSICAL_NAMES=[Yes|No]
# 
#     Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter
#     chain that relates to an interface, it uses the interface's logical name as
#     the base of the chain name. For example, if the logical name for an
#     interface is OAKLAND, then the input chain for traffic arriving on that
#     interface would be 'OAKLAND_in'. If this option is set to Yes, then the
#     physical name of the interface will be used the base of the chain name.
# 
USE_RT_NAMES=No
#
# USE_RT_NAMES=[Yes|No]
# 
#     Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing
#     table (provider) names in the generated script rather than table numbers.
#     When set to 'No' (the default), routing table numbers will be used.
# 
#     Caution
# 
#     If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure
#     that all of your providers have entries in /etc/iproute2/rt_tables as well
#     as the following entries:
# 
#     255 local
#     254 main
#     253 default
#     250 balance
#     0 unspec
# 
#     Without these entries, the firewall will fail to start.
# 
VERBOSE_MESSAGES=Yes
#
# VERBOSE_MESSAGES=[Yes|No]
# 
#     Added in Shorewall 5.0.9. When Yes (the default), messages produced by the
#     ?INFO and ?WARNING directives include the filename and linenumber of the
#     directive. When set to No, that additional information is omitted. The
#     setting may be overridden on a directive by directive basis by following ?
#     INFO or ?WARNING with '!' (no intervening white space).
# 
WARNOLDCAPVERSION=Yes
#
# WARNOLDCAPVERSION=[Yes|No]
# 
#     Added in Shorewall 4.5.12. When set to Yes (the default), the compiler
#     issues a warning when it finds a capabilities file that doesn't specify all
#     of the capabilities supported by the compiler. When WARNOLDCAPVERSION is
#     set to No, no warning is issued.
# 
WORKAROUNDS=No
#
# WORKAROUNDS=[Yes|No]
# 
#     Added in Shorewall 4.6.11. Over time, there have been a number of changes
#     in Shorewall that work around defects in other products such as iptables
#     and ipset. When WORKAROUNDS=Yes, these workarounds are enabled; when
#     WORKAROUNDS=No, they are disabled. If not specified or if specified as
#     empty, WORKAROUNDS=Yes is assumed.
# 
#     Warning
# 
#     Do not set WORKAROUNDS=Yes if you need to be able to use
#     Shorewall-generated scripts (such as created by the save command) built by
#     Shorewall 4.4.7 or older.
# 
ZERO_MARKS=No
#
# ZERO_MARKS=[Yes|No]
# 
#     Added in Shorewall 5.0.12, this is a workaround for an issue where packet
#     marks are not zeroed by the kernel. It should be set to No (the default)
#     unless you find that incoming packets are being mis-routed for no apparent
#     reasons.
# 
#     Caution
# 
#     Do not set this option to Yes if you have IPSEC software running on the
#     firewall system.
# 
ZONE2ZONE=-
#
# ZONE2ZONE=[2|-]
# 
#     Added in Shorewall 4.4.4. This option determines how Shorewall constructs
#     chain names involving zone names and/or 'all'. Beginning with Shorewall
#     4.6.0, the default is '-' (e.g., fw-net); prior to that release, the
#     default was '2' (e.g., fw2net).
# 
###############################################################################
#			P A C K E T   D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
#
# BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
# 
#     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.
# 
#     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 determines the disposition of packets
#     sent to the blacklog target of shorewall-blrules (5), but otherwise does
#     not affect entries in that file.
# 
INVALID_DISPOSITION=CONTINUE
#
# INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
# 
#     Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID
#     packets through the NEW section of shorewall-rules (5). When a packet in
#     INVALID state fails to match any rule in the INVALID section, the packet is
#     disposed of based on this setting. The default value is CONTINUE for
#     compatibility with earlier versions.
# 
MACLIST_DISPOSITION=REJECT
#
# MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
# 
#     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.
# 
#     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 ip[6]tables.
# 
RELATED_DISPOSITION=ACCEPT
#
# RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
# 
#     Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED
#     packets that don't match any rule in the RELATED section of shorewall-rules
#     (5). Concern about the safety of this practice resulted in the addition of
#     this option. When a packet in RELATED state fails to match any rule in the
#     RELATED section, the packet is disposed of based on this setting. The
#     default value is ACCEPT for compatibility with earlier versions.
# 
RPFILTER_DISPOSITION=DROP
#
# RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
# 
#     Added in Shorewall 4.5.7. Determines the disposition of packets entering
#     from interfaces the rpfilter option (see shorewall-interfaces(5)). Packets
#     disposed of by this option are those whose response packets would not be
#     sent through the same interface receiving the packet.
# 
SMURF_DISPOSITION=DROP
#
# SMURF_DISPOSITION=[DROP|A_DROP]
# 
#     Added in Shorewall 4.4.20. The default setting is DROP which causes smurf
#     packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped.
#     A_DROP causes the packets to be audited prior to being dropped and requires
#     AUDIT_TARGET support in the kernel and iptables.
# 
SFILTER_DISPOSITION=DROP
#
# SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
# 
#     Added in Shorewall 4.4.20. Determines the disposition of packets matching
#     the sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
#     interfaces without the routeback option.^[1]
# 
TCP_FLAGS_DISPOSITION=DROP
#
# TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
# 
#     Determines the disposition of TCP packets that fail the checks enabled by
#     the tcpflags interface option (see shorewall-interfaces(5)) 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.
# 
#     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.
# 
UNTRACKED_DISPOSITION=CONTINUE
#
# UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
# 
#     Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED
#     packets through the NEW section of shorewall-rules (5). When a packet in
#     UNTRACKED state fails to match any rule in the UNTRACKED section, the
#     packet is disposed of based on this setting. The default value is CONTINUE
#     for compatibility with earlier versions.
# 
################################################################################
#			P A C K E T  M A R K  L A Y O U T
################################################################################
TC_BITS=
#
# TC_BITS=[number]
# 
#     The number of bits at the low end of the 32-bit packet mark to be used for
#     traffic shaping marking. May be zero. See MASK_BITS above for default
#     value.
# 
PROVIDER_BITS=
#
# PROVIDER_BITS=[number]
# 
#     Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to
#     be used for provider numbers. May be zero. See MASK_BITS above for default
#     value.
# 
PROVIDER_OFFSET=
#
# PROVIDER_OFFSET=[number]If
# 
#     Added in Shorewall 4.4.26. The offset from the right (low-order end) of the
#     provider number field in the 32-bit packet mark. If non-zero, must be >=
#     TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value).
#     PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS
#     above for default value.
# 
MASK_BITS=
#
# MASK_BITS=[number]
# 
#     Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet
#     mark to be masked when clearing the traffic shaping mark. Must be >=
#     TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Prior to Shorewall
#     5.0.0, default value and the default values of the other mark layout
#     options is determined as follows:
# 
#     Table 1. Default Packet Mark Layout
# 
#     WIDE_TC_MARKS=No,             TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
#     HIGH_ROUTE_MARKS=No           0, MASK_BITS=8
#     WIDE_TC_MARKS=No,             TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
#     HIGH_ROUTE_MARKS=Yes          8, MASK_BITS=8
#     WIDE_TC_MARKS=Yes,            TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
#     HIGH_ROUTE_MARKS=No           0, MASK_BITS=16
#     WIDE_TC_MARKS=Yes,            TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
#     HIGH_ROUTE_MARKS=Yes          16, MASK_BITS=16
# 
# 
#     From 5.0.0 onward, the default value of MASK_BITS is 8, the default value
#     of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is 8.
# 
ZONE_BITS=0
#
# ZONE_BITS=[number]
# 
#     Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking
#     by source zone and determines the number of bits in the 32-bit packet mark
#     to be used for the zone mark. Default value is 0.
# 
