###############################################################################
#
# Shorewall Version 5 -- /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 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=Yes
#
# 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_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=
#
# 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='
#
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.
#
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:
#
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/shorewall6-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
###############################################################################
CONFIG_PATH=":${CONFDIR}/shorewall6:${SHAREDIR}/shorewall6:${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 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]
#
# IPv6 only.
#
# 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 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="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
#
# BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
#
DROP_DEFAULT="AllowICMPs,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="AllowICMPs,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).
#
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=No
#
# 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=Yes
#
# 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.
#
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.
#
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
#
# When ipset-based dynamic blacklisting is enabled, the contents of the
# blacklist will be preserved over stop/reboot/start sequences if SAVE_IPSETS
# =Yes, SAVE_IPSETS=ipv4 or if setname is included in the list of sets to be
# saved in SAVE_IPSETS.
#
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=Yes
#
# 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=Keep
#
# 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=Yes
#
# 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.
#
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.
#
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.
#
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.
#
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=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.
#
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.
#
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=Shared
#
# 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.
#
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]
#
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.
#
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.
#
distrib
>
Mageia
>
7
>
armv7hl
>
media
>
core-release
>
by-pkgid
>
9914dbbc7412ec6b67f2b5dc90568c19
>
files
>
61
