###############################################################################
#
#  Shorewall Version 4 -- /etc/shorewall6/shorewall6.conf
#
#  For information about the settings in this file, type "man shorewall6.conf"
#
#  Manpage also online at
#  http://www.shorewall.net/manpages6/shorewall6.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 Shorewall6
# 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 Shorewall6 logging, a level of 6 (info) is appropriate. Shorewall6 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 NFLOG target support, you may also specify a
# log level of NFLOG (must be all caps). Rather than log its messages to syslogd,
# Shorewall6 will direct netfilter to log the messages via the 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). Ulogd is also
# available from http://www.netfilter.org/projects/ulogd/index.html and can be
# configured to log all Shorewall6 message to their own log file
# 
# Note
# 
# 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:
# 
STARTUP_ENABLED=Yes
#
# STARTUP_ENABLED={Yes|No}
# 
#     Determines if Shorewall6 is allowed to start. As released from
#     shorewall.net, this option is set to No. When set to Yes or yes, Shorewall6
#     may be started. Used as a guard against Shorewall6 being accidentally
#     started before it has been configured.
# 
###############################################################################
#		              V E R B O S I T Y
###############################################################################
VERBOSITY=1
#
# VERBOSITY=[number]
# 
#     Shorewall6 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 Shorewall6-3.2.0 behavior)
# 
#     If not specified, then 2 is assumed.
# 
###############################################################################
#			       L O G G I N G
###############################################################################
BLACKLIST_LOG_LEVEL=
#
# BLACKLIST_LOG_LEVEL=[log-level]
# 
#     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
#     shorewall6-blrules(5).
# 
INVALID_LOG_LEVEL=
#
# INVALID_LOG_LEVEL=log-level
# 
#     Added in Shorewall 4.5.13. Packets in the INVALID state that do not match
#     any rule in the INVALID section of shorewall6-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 shorewall6(8)).
# 
#     backend is one of:
# 
#     LOG
# 
#         Use standard kernel logging.
# 
#     netlink
# 
#         Use netlink logging to ulogd version 2 or later.
# 
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.
# 
LOGALLNEW=
#
# LOGALLNEW=[log-level]
# 
#     This option is intended for use as a debugging aid. When set to a log
#     level, this option causes Shorewall6 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:
# 
#             Shorewall:nat:PREROUTING
# 
#         Important
# 
#         To help insure that all packets in the NEW state are logged, rate
#         limiting (LOGBURST and LOGRATE) 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=
#
# LOGFILE=[pathname]
# 
#     This parameter tells the /sbin/shorewall6 program where to look for
#     Shorewall6 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.
# 
LOGFORMAT="Shorewall:%s:%s:"
#
# LOGFORMAT=["formattemplate"]
# 
#     The value of this variable generate the --log-prefix setting for Shorewall6
#     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 “Shorewall6:%s:%s:” is assumed.
# 
#     Note
# 
#     The setting of LOGFORMAT has an effect of the permitted length of zone
#     names. See shorewall6-zones (5).
# 
LOGLIMIT=
#
# LOGLIMIT=[[{s|d}:]rate/{sec|min|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.
# 
LOGTAGONLY=No
#
# LOGTAGONLY=[Yes|No]
# 
#     Using the default LOGFORMAT, chain names may not exceed 11 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 the default LOGFORMAT
#     setting:
# 
#     Shorewall:foo:bar:
# 
#     Similarly,
# 
#     #ACTION                               SOURCE            DEST
#     LOG:info:,bar                        net                    fw
# 
#     would generate
# 
#     Shorewall:net2fw:bar:
# 
MACLIST_LOG_LEVEL=info
#
# MACLIST_LOG_LEVEL=[log-level]
# 
#     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
# 
#     Added in Shorewall 4.4.27. Packets in the related state that do not match
#     any rule in the RELATED section of shorewall6-rules (5) are logged at this
#     level. The default value is empty which means no logging is performed.
# 
RPFILTER_LOG_LEVEL=info
#
# RPFILTER_LOG_LEVEL=log-level
# 
#     Added in shorewall 4.5.7. Determines the logging of packets disposed via
#     the RPFILTER_DISPOSITION. The default value is info.
# 
SFILTER_LOG_LEVEL=info
#
# SFILTER_LOG_LEVEL=log-level
# 
#     Added on Shorewall 4.4.20. Determines the logging of packets matching the
#     sfilter option (see shorewall6-interfaces(5)) and of hairpin packets on
#     interfaces without the routeback option.^[2] interfaces without the
#     routeback option. The default is info. If you don't wish for these packets
#     to be logged, use SFILTER_LOG_LEVEL=none.
# 
SMURF_LOG_LEVEL=info
#
# SMURF_LOG_LEVEL=[log-level]
# 
#     Specifies the logging level for smurf packets (see the nosmurfs option in
#     shorewall6-interfaces(5)). If set to the empty value ( SMURF_LOG_LEVEL="" )
#     then smurfs are not logged.
# 
STARTUP_LOG=/var/log/shorewall6-init.log
#
# STARTUP_LOG=[pathname]
# 
#     If specified, determines where Shorewall6 will log the details of each 
#     start, restart and refresh command. Logging verbosity is determined by the
#     setting of LOG_VERBOSITY above.
# 
TCP_FLAGS_LOG_LEVEL=info
#
# TCP_FLAGS_LOG_LEVEL=[log-level]
# 
#     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
# 
#     Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do not match
#     any rule in the UNTRACKED section of shorewall6-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
###############################################################################
CONFIG_PATH=${CONFDIR}/shorewall6:${SHAREDIR}/shorewall6:${SHAREDIR}/shorewall
#
# CONFIG_PATH=[directory[:directory]...]
# 
#     Specifies where configuration files other than shorewall6.conf may be
#     found. CONFIG_PATH is specifies as a list of directory names separated by
#     colons (":"). When looking for a configuration file other than
#     shorewall6.conf:
# 
#       ● If the command is "try" or a "<configuration directory>" was specified
#         in the command (e.g., shorewall6 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/shorewall6/configpath are used. As released from
#     shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall6:/usr/share
#     /shorewall6:/usr/share/shorewall but your particular distribution may set
#     it differently. See the output of shorewall6 show config for the default on
#     your 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 http://www.shorewall.net/
#     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.
# 
IP6TABLES=
#
# IP6TABLES=[pathname]
# 
#     This parameter names the ip6tables executable to be used by Shorewall6. If
#     not specified or if specified as a null value, then the ip6tables
#     executable located using the PATH option is used.
# 
#     Regardless of how the ip6tables utility is located (specified via IP6TABLES
#     = or located via PATH), Shorewall6 uses the ip6tables-restore and
#     ip6tables-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 Shorewall6 lock file, used to prevent
#     simultaneous state-changing commands. If not specified, ${VARDIR}/
#     shorewall6/lock is assumed (${VARDIR} is normally /var/lib but can be
#     changed when Shorewall-core is installed -- see the output of shorewall6
#     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, Shorewall6
#     will supply "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter:/lib/modules
#     /`uname -r`/kernel/net/ipv4/netfilter".
# 
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 Shorewall6
#     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 Shorewall6 searches directories for
#     executable files.
# 
RESTOREFILE=
#
# RESTOREFILE=filename
# 
#     Specifies the simple name of a file in /var/lib/shorewall6 to be used as
#     the default restore script in the shorewall6 save, shorewall6 restore, 
#     shorewall6 forget and shorewall6 -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 Shorewall6 to work with your distribution's
#     initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall6.
#     For Debian, the value is /var/lock/shorewall6 and in LEAF it is /var/run/
#     shorewall.
# 
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}
# 
DROP_DEFAULT="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="Reject"
#
# REJECT_DEFAULT={action[(parameters)][:level]|none}
# 
#     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
# 
#     The default values are:
# 
#     DROP_DEFAULT="Drop"
#     REJECT_DEFAULT="Reject"
#     ACCEPT_DEFAULT="none"
#     QUEUE_DEFAULT="none"
#     NFQUEUE_DEFAULT="None"
# 
#     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
#     shorewall6-policy(5).
# 
#     You can pass parameters to the specified action or macro (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 macro body that does not already have a log level.
# 
###############################################################################
#                        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 Shorewall6 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
#     shorewall6.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, Shorewall6 accounting is enabled
#     (see shorewall6-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 shorewall6-accounting(5).
# 
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.
# 
#     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/
#         shorewall6/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.
# 
BASIC_FILTERS=No
#
# BASIC_FILTERS=[Yes|No]
# 
#     Added in Shorewall-4.6.0. When set to Yes, causes entries in
#     shorewall6-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 Shorewall6 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.
# 
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.
# 
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>". 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. Either:
# 
#          a. Modify shorewall6-conntrack (5) to only apply helpers where they
#             are required; or
# 
#          b. Specify the appropriate helper in the HELPER column in
#             shorewall6-rules (5).
# 
#             Note
# 
#             The macros for those applications requiring a helper automatically
#             specify the appropriate HELPER where required.
# 
AUTOMAKE=No
#
# AUTOMAKE=[Yes|No]
# 
#     If set, the behavior of the start and restart commands is changed; if no
#     files in /etc/shorewall have been changed since the last successful start
#     or restart command, then the compilation step is skipped and the compiled
#     script that executed the last start or restart command is used. The default
#     is AUTOMAKE=No.
# 
#     The setting of the AUTOMAKE option is ignored if the start or restart
#     command includes a directory name (e.g., shorewall6 restart /etc/
#     shorewall.new).
# 
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 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.
# 
#     Note: The ESTABLISHED state may not be specified if FASTACCEPT is
#     specified.
# 
CHAIN_SCRIPTS=No
#
# CHAIN_SCRIPTS={Yes|No}
# 
#     Added in Shorewall 4.5.16. Prior to the availability of BEGIN PERL....END
#     PERL in configuration files, the only way to execute a chain-specific
#     script was to create a script file with the same name as the chain and
#     place it in a directory on the CONFIG_PATH. That facility has the drawback
#     that the compiler will attempt to run a non-script file just because it has
#     the same name as a chain. To disable this facility, set CHAIN_SCRIPTS=No.
#     If not specified or specified as the empty value, CHAIN_SCRIPTS=Yes is
#     assumed.
# 
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 Shorewall6 won't clear the current traffic
#     control rules during [re]start. This setting is intended for use by people
#     that prefer to configure traffic shaping when the network interfaces come
#     up rather than when the firewall is started. If that is what you want to
#     do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall6
#     /tcstart file. That way, your traffic shaping rules can still use the
#     “fwmark” classifier based on packet marking defined in shorewall6-tcrules
#     (5). If not specified, CLEAR_TC=No is assumed.
# 
#     Warning
# 
#     If you also run Shorewall and if you have TC_ENABLED=Internal in your
#     shorewall-conf(5), then you will want CLEAR_TC=No in this file.
# 
COMPLETE=Yes
#
# COMPLETE=[Yes|No]
# 
#     Added in Shorewall6 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 Shorewall6 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 ip6tables-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 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).
# 
DELETE_THEN_ADD=Yes
#
# DELETE_THEN_ADD={Yes|No}
# 
#     If set to Yes (the default value), entries in the /etc/shorewall6/
#     route_stopped 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.
# 
DONT_LOAD=
#
# DONT_LOAD=[module[,module]...]
# 
#     Causes Shorewall6 to not load the listed kernel modules.
# 
DYNAMIC_BLACKLIST=Yes
#
# DYNAMIC_BLACKLIST={Yes|No}
# 
#     Added in Shorewall 4.4.7. When set to No or no, dynamic blacklisting using
#     the shorewall6 drop, shorewall6 reject, shorewall6 logdrop and shorewall6
#     logreject is disabled. Default is Yes.
# 
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 the 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
#     Shorewall6 Lite (shorewall6 load, shorewall6 reload or shorewall6 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/
#     shorewall6 but will copy the found in another location on the CONFIG_PATH.
# 
#     When compiling for direct use by Shorewall6, 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=Yes
#
# FASTACCEPT={Yes|No}
# 
#     Normally, Shorewall6 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 'loc2net' chain.
# 
#     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
#     shorewall6-rules(5).
# 
#     Note
# 
#     FASTACCEPT=Yes is incompatible with BLACKLISTNEWONLY=No.
# 
FORWARD_CLEAR_MARK=
#
# FORWARD_CLEAR_MARK={Yes|No}
# 
#     Added in Shorewall 4.4.11 Beta 3. 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 lists 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.
# 
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 shorewall6-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 shorewall6-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).
# 
INLINE_MATCHES=Yes
#
# INLINE_MATCHES={Yes|No}
# 
#     Added in Shorewall 4.6.0. Traditionally in shorewall6-rules(5), a semicolon
#     separates column-oriented specifications on the left from alternative
#     specificaitons on the right.. When INLINE_MATCHES=Yes is specified, the
#     specifications on the right are interpreted as if INLINE had been specified
#     in the ACTION column. If not specified or if specified as the empty value,
#     the value 'No' is assumed for backward compatibility.
# 
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 rather useless parameter determines whether Shorewall6 enables or
#     disables IPV6 Packet Forwarding on all interfaces (/proc/sys/net/ipv6/
#     config/all/forwarding). Possible values are:
# 
#     On or on
# 
#         packet forwarding will be enabled.
# 
#     Off or off
# 
#         packet forwarding will be disabled.
# 
#     Keep or keep
# 
#         Shorewall6 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=Yes
#
# KEEP_RT_TABLES={Yes|No}
# 
#     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, refresh, restore on restart command.
# 
#     The default is KEEP_RT_TABLES=No.
# 
LEGACY_FASTSTART=No
#
# LEGACY_FASTSTART={Yes|No}
# 
#     Added in Shorewall6 4.4.20. If not specified, the default is Yes which
#     preserves the legacy behavior of start -f (the modification times of the
#     files in /etc/shorewall6 are compared with that of /var/lib/shorewall6/
#     restore). If set to No, then the times are compared with that of /var/lib/
#     shorewall6/firewall, which is consistent with the way that restart -f
#     works.
# 
LOAD_HELPERS_ONLY=Yes
#
# LOAD_HELPERS_ONLY={Yes|No}
# 
#     Added in Shorewall 4.4.7. When set to Yes, restricts the set of modules
#     loaded by shorewall to those listed in /var/lib/shorewall6/helpers and
#     those that are actually used. When not set, or set to the empty value,
#     LOAD_HELPERS_ONLY=No is assumed.
# 
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 with MACLIST_TABLE=mangle.
# 
MACLIST_TTL=
#
# MACLIST_TTL=[number]
# 
#     The performance of configurations with a large numbers of entries in
#     shorewall6-maclist(5) can be improved by setting the MACLIST_TTL variable
#     in shorewall6.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 shorewall6-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.
# 
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 /sbin/shorewall6 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.
# 
MODULE_SUFFIX=ko
#
# MODULE_SUFFIX=["extension ..."]
# 
#     The value of this option determines the possible file extensions of kernel
#     modules. The default value is "ko ko.gz o o.gz gz".
# 
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 Shorewall6 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 shorewall6 restart command.
# 
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
# 
#         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.
# 
#       ● 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.
# 
#     The default value is zero which disables 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.
# 
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 (58) 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 (ICMP6).
# 
#       ● if the protocol is ICMP (1) then the packet is rejected with a
#         'addr-unreachable' ICMP.
# 
#       ● otherwise, the packet is rejected with a 'adm-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 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
# 
REQUIRE_INTERFACE=Yes
#
# 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.
# 
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 even when it is zero. If you have problems with IPSEC ESP
#     packets not being routed correctly on output, try setting this option to No
#     .
# 
SAVE_IPSETS=No
#
# SAVE_IPSETS={Yes|No|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 ipv6 ipset names).
# 
TC_ENABLED=No
#
# TC_ENABLED=[Yes|No|Internal|Shared]
# 
#     If you say Yes or yes here, Shorewall6 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=Internal or internal or leave the option empty then
#     Shorewall6 will use its builtin traffic shaper (tc4shorewall6 written by
#     Arne Bernin.
# 
#     Beginning with Shorewall 4.4.15, if you set TC_ENABLED=Shared or shared,
#     then you should create symbolic links from your Shorewall6 configuration
#     directory (normally /etc/shorewall6/) to your Shorewall tcdevices and
#     tcclasses files. This allows the compiler to have access to your Shorewall
#     traffic shaping configuration so that it can validate CLASSIFY rules in
#     shorewall6-tcrules (5).
# 
#     Warning
# 
#     If you also run Shorewall and if you have TC_ENABLED=Internal in your
#     shorewall-conf(5), then you will want TC_ENABLED=No or TC_ENABLED=Shared in
#     this file.
# 
TC_EXPERT=No
#
# TC_EXPERT={Yes|No}
# 
#     Normally, Shorewall6 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 shorewall6-providers(5).
# 
#     If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall6
#     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 shorewall6-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 shorewall6-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 shorewall6-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 shorewall6-rtrules(5) 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}
# 
#     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 ip6tables
#     and kernel.
# 
USE_DEFAULT_RT=Yes
#
# USE_DEFAULT_RT=[Yes|No]
# 
#     Added in Shorewall6 4.4.25. When set to 'Yes', this option causes the
#     Shorewall6 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
#     Shorewall6-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 shorewall6-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. balance is assumed unless loose is specified.
# 
#      4. Packets are sent through the main routing table by a rule with priority
#         999. In shorewall6-routing_rules(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.
# 
#      6. You should disable all default route management outside of Shorewall6.
#         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.
# 
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.
# 
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.
# 
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. The setting determines the disposition of
#     packets sent to the blacklog target of shorewall6-blrules(5).
# 
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 ip6tables.
# 
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
#     shorewall6-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.
# 
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 shorewall6-interfaces(5)) and of hairpin packets on
#     interfaces without the routeback option.^[1] interfaces without the
#     routeback option.
# 
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 with the rpfilter option (see shorewall6-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 shorewall6-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 ip6tables.
# 
TCP_FLAGS_DISPOSITION=DROP
#
# TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT]
# 
#     Determines the disposition of TCP packets that fail the checks enabled by
#     the tcpflags interface option (see shorewall6-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.
# 
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 shorewall6-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]
# 
#     Added in Shorewall 4.4.26. 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]
# 
#     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). 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
# 
# 
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.
# 
