Remove /etc/shorewall/Documentation; strip documentation from shorewall.conf

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4957 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb

Shorewall/changelog.txt

@@ -1,5 +1,6 @@
 Changes in 3.3.6
 
+1)  Remove /etc/shorewall/Documentation.
 
 Changes in 3.3.5
 

Shorewall/releasenotes.txt

@@ -37,7 +37,8 @@ None.
 
 Other Changes in 3.3.6
 
-None.
+1)  Now that the manpages are in place, /etc/shorewall/Documentation
+    has been removed.
 
 Migration Considerations:
 
@@ -96,6 +97,14 @@ New Features:
     - lib.actions. Must be available if you do not specify
       USE_ACTIONS=No in /etc/shorewall/shorewall.conf.
 
+    - lib.base. The base Shorewall library required by all programs. 
+
+    - lib.cli. Library containing the code common to /sbin/shorewall,
+      /sbin/shorewall-lite, and /usr/share/shorewall/firewall.
+
+    - lib.config. Library containing the code that is common to
+      /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. 
+
     - lib.dynamiczones. Must be available if you specify
       DYNAMIC_ZONES=Yes in shorewall.conf.
 
@@ -126,8 +135,6 @@ New Features:
     footprint by:
 
     - Omitting the macro files.
-    - Only including the 'modules' file appropriate for the kernel in
-      use.
     - Omitting all unused extension scripts.
     - Stripping the comments (except for copyright) from the various
       files.
@@ -237,7 +244,7 @@ New Features:
     messages which must be 29 bytes or less in length. With the
     standard Shorewall LOGFORMAT, that leaves 11 characters for the
     chain name; given that many chain names are of the form
-    <zone1>2<zone2>, that gives a maximum zone name length of 11.
+    <zone1>2<zone2>, that gives a maximum zone name length of 5.
 
     Beginning with this release, the maximum length of a zone name is
     dependent on the LOGFORMAT (the maximum length may never be less
@@ -425,12 +432,7 @@ New Features:
 14) IP Address ranges are now allowed in the drop, reject, allow and
     logdrop shorewall[-lite] commands.
 
-15) The lib.cli library has been added. It is distributed with
+15) Previously, Shorewall has not attempted to undo the changes it has
-    both Shorewall and Shorewall Lite and contains the
-    command-processing code that is common to both /sbin/shorewall and
-    /sbin/shorewall-lite.
-
-16) Previously, Shorewall has not attempted to undo the changes it has
     made to the firewall's routing as a result of entries in
     /etc/shorewall/providers and /etc/shorewall/routes. Beginning with
     this release, Shorewall will attempt to undo these changes.
@@ -451,37 +453,12 @@ New Features:
     the saved copy so that it will once again be captured at the next
     shorewall start or shorewall restore.
 
-17) Shorewall no longer includes policy matches in its generated
+16) Shorewall no longer includes policy matches in its generated
     ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC
     networks are defined using the 'ipsec' option in
     /etc/shorewall/hosts).
 
-18) From the beginning, the Shorewall configuration files in
+17) The Makefile installed in /usr/share/shorewall/configfiles/ is now
-    /etc/shorewall/ have contained documentary comments. While these
-    comments are useful, they present an upgrade problem. Beginning
-    with this release, these comments are removed from the
-    configuration files themselves and are gathered together in a
-    single file /etc/shorewall/Documentation. The documentation is in
-    alphabetical order by file name.
-
-19) The "shorewall [re]load" command now supports a "-c" option.
-
-    Example:
-
-	shorewall reload -c gateway
-
-    When -c is given, Shorewall will capture the capabilities of the
-    remote system to a file named "capabilities" in the export
-    directory before compiling the configuration.
-
-    If the file "capabilities" does not currently exist in the 
-    export directory then "-c" is automatically assumed.
-
-20) If 0 (zero) is specified for the IN-BANDWIDTH in
-    /etc/shorewall/tcdevices then no ingress qdisc will be created for
-    the device.
-
-21) The Makefile installed in /usr/share/shorewall/configfiles/ is now
     the same one mentioned at
     http://www.shorewall.net/CompiledPrograms.html.
 
@@ -496,7 +473,7 @@ New Features:
     generate the "capabilities" file if that file doesn't exist. "make
     save" will save the running configuration on the remote firewall.
 
-22) Shorewall and Shorewall Lite now include the following manpages. 
+18) Shorewall and Shorewall Lite now include the following manpages. 
 
 	      shorewall-accounting(5)
 	      shorewall-actions(5)
@@ -524,3 +501,11 @@ New Features:
 	      shorewall-tunnels(5)
 	      shorewall(8)
 	      shorewall-zones(5)
+
+19) From the beginning, the Shorewall configuration files in
+    /etc/shorewall/ have contained documentary comments. While these
+    comments are useful, they present an upgrade problem. Beginning
+    with this release, these comments are removed from the
+    configuration files themselves and are replaced by the manpages
+    described in the preceding release note entry.
+

Shorewall/shorewall.conf

@@ -7,426 +7,69 @@
 #  This file should be placed in /etc/shorewall
 #
 #  (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net)
-#
-#      >>>>>>>>>>>>> NOTE TO USERS UPGRADING FROM 2.x <<<<<<<<<<<<<<<<<<
-#
-#  Most problems associated with upgrades come from two causes:
-#
-#   - The user didn't read and follow the migration considerations in the
-#     release notes.
-#
-#   - The user mis-handled the /etc/shorewall/shorewall.conf file during
-#     upgrade. Shorewall is designed to allow the default behavior of
-#     the product to evolve over time. To make this possible, the design
-#     assumes that you will not replace your current shorewall.conf file
-#     during upgrades. If you feel absolutely compelled to have the latest
-#     comments and options in your shorewall.conf then you must proceed
-#     carefully.
-#
-#     The new/changed options in shorewall 3.0 are listed below. If you don't
-#     want to convert to the new 3.0 format for /etc/shorewall/zones and you
-#     don't want to replace your current rules that use 2.x builtin actions,
-#     then if you plan to use this copy of shorewall.conf file then you must
-#     change it as follows:
-#
-#     - IPSECFILE
-#
-#	This file has IPSECFILE=zones. You want to set it to IPSECFILE=ipsec.
-#	This will indicate that your /etc/shorewall/zones file is in the
-#	pre-3.0 format.
-#
-#     - FW
-#
-#	This file has FW undefined. If you have named your firewall zone
-#	something other than 'fw' then you must set FW accordingly.
-#
-#     - MAPOLDACTIONS
-#
-#	This file has MAPOLDACTIONS=No. You want to set it to
-#       MAPOLDACTIONS=Yes in order to permit rules that use the 2.x builtin
-#       actions such as AllowPing to continue to work.
 ###############################################################################
 #		       S T A R T U P   E N A B L E D
 ###############################################################################
-#
-# Once you have configured Shorewall, you may change the setting of
-# this variable to 'Yes'
-#
 
 STARTUP_ENABLED=No
 
 ###############################################################################
 #		              V E R B O S I T Y
 ###############################################################################
-#
-# Shorewall has traditionally been very noisy. You may now set the default
-# level of verbosity here.
-#
-# Values are:
-#
-#         0 -- Silent. You may make it more verbose using the -v option
-#         1 -- Major progress messages displayed
-#         2 -- All progress messages displayed (old default behavior)
-#
-# If not specified, then 2 is assumed
 
 VERBOSITY=1
 
 ###############################################################################
 #			       L O G G I N G
 ###############################################################################
-#
-# General note about log levels. 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 specifify. 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 target support, you may also
-# specify a log level of ULOG (must be all caps). Rather than log its
-# messages to syslogd, Shorewall will direct netfilter to log the messages
-# via the ULOG 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.gnumonks.org/projects/ulogd and can be configured to log all
-# Shorewall message to their own log file
-###############################################################################
-#
-# LOG FILE LOCATION
-#
-# This variable tells the /sbin/shorewall program where to look for Shorewall
-# log messages. If not set or set to an empty string (e.g., LOGFILE="") then
-# /var/log/messages is assumed.
-#
-# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to
-#	   look for Shorewall messages.It does NOT control the destination for
-#	   these messages. For information about how to do that, see
-#
-#	       http://www.shorewall.net/shorewall_logging.html
-#
 
 LOGFILE=/var/log/messages
 
-#
-# LOG FORMAT
-#
-# Shell 'printf' Formatting template for the --log-prefix value in log messages
-# generated by Shorewall to identify Shorewall log messages. The supplied
-# template is expected to accept either two or three arguments; the first is
-# the chain name, the second (optional) is the logging rule number within that
-# chain and the third is the ACTION specifying the disposition of the packet
-# being logged. You must use the %d formatting type for the rule number; if
-# your template does not contain %d then the rule number will not be included.
-#
-# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
-#
-#	LOGFORMAT="fp=%s:%d a=%s "
-#
-# If not specified or specified as empty (LOGFORMAT="") then the value
-# "Shorewall:%s:%s:" is assumed.
-#
-# Beginning with Shorewall 3.3.3, The contents of LOGFORMAT determine the
-# maximum length of a Shorewall zone name. LOGFORMAT must produce a string no
-# longer than 29 bytes when passed the chain name, [rule number], and 'ACCEPT'.
-# Using the default LOGFORMAT, the name of a chain must be 11 characters or
-# less; since chain names are often of the form <zone1>2<zone2>, zone names are
-# limited to 5 characters using the default LOGFORMAT. In contrast, if
-# LOGFORMAT="FW:%s:%s:", then zone names can be as long as 8 characters.
-
 LOGFORMAT="Shorewall:%s:%s:"
 
-#
-# LOG FORMAT Continued
-#
-# 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.
-#
-
 LOGTAGONLY=No
 
-#
-# LOG RATE LIMITING
-#
-# The next two variables can be used to control the amount of log output
-# generated. LOGRATE is expressed as a number followed by an optional
-# `/second',  `/minute', `/hour', or `/day' suffix and specifies the maximum
-# rate at which a particular message will occur. LOGBURST determines the
-# maximum initial burst size that will be logged. If set empty, the default
-# value of 5 will be used.
-#
-# If BOTH variables are set empty then logging will not be rate-limited.
-#
-# Example:
-#
-#	LOGRATE=10/minute
-#	LOGBURST=5
-#
-# For each logging rule, the first time the rule is reached, the packet
-# will be logged; in fact, since the burst is 5, the first five packets
-# will be logged. After this, it will be 6 seconds (1 minute divided by
-# the rate of 10) before a message will be logged from the rule, regardless
-# of how many packets reach it. Also, every 6 seconds which passes without
-# matching a packet, one of the bursts will be regained; if no packets hit
-# the rule for 30 seconds, the burst will be fully recharged; back where
-# we started.
-#
-
 LOGRATE=
-LOGBURST=
 
-#
+LOGBURST=
-# LOG ALL NEW
-#
-# This option should only be used when you are trying to analyze a problem.
-# It causes all packets in the Netfilter NEW state to be logged as the
-# first rule in each builtin chain. To use this option, set LOGALLNEW to
-# the log level that you want these packets logged at (e.g.,
-# LOGALLNEW=debug).
-#
 
 LOGALLNEW=
 
-#
-# BLACKLIST LOG LEVEL
-#
-# Set this variable to the syslogd level that you want blacklist packets logged
-# (beware of DOS attacks resulting from such logging). If not set, no logging
-# of blacklist packets occurs.
-#
-# See the comment at the top of this section for a description of log levels
-#
-
 BLACKLIST_LOGLEVEL=
 
-#
-# MAC List Log Level
-#
-# Specifies the logging level for connection requests that fail MAC
-# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then
-# such connection requests will not be logged.
-#
-# See the comment at the top of this section for a description of log levels
-#
-# If you wish to filter messages logged under this option, then supply
-# the /etc/shorewall/maclog extension script (you will have to create the
-# file yourself). That script will be copied into the compiled firewall
-# script at a point just before logging  occurs. The shell variable CHAIN
-# will be set to the name of the chain where the logging rule will be
-# inserted.
-#
-# If you set MACLIST_TABLE=mangle later in this file, be sure that your
-# 'run_iptables' commands include '-t mangle'.
-#
-# See http://www.shorewall.net/shorewall_extension_scripts.htm for more
-# information about extension scripts.
-#
-
 MACLIST_LOG_LEVEL=info
 
-#
-# TCP FLAGS Log Level
-#
-# Specifies the logging level for packets that fail TCP Flags
-# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then
-# such packets will not be logged.
-#
-# See the comment at the top of this section for a description of log levels
-#
-
 TCP_FLAGS_LOG_LEVEL=info
 
-#
-# RFC1918 Log Level
-#
-# Specifies the logging level for packets that fail RFC 1918
-# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then
-# RFC1918_LOG_LEVEL=info is assumed.
-#
-# See the comment at the top of this section for a description of log levels
-#
-
 RFC1918_LOG_LEVEL=info
 
-#
-# SMURF Log Level
-#
-# Specifies the logging level for smurf packets dropped by the
-#'nosmurfs' interface option in /etc/shorewall/interfaces and in
-# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""
-# ) then dropped smurfs are not logged.
-#
-# See the comment at the top of this section for a description of log levels
-#
-
 SMURF_LOG_LEVEL=info
 
-#
-# MARTIAN LOGGING
-#
-# Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets
-# that have impossible source IP addresses. This logging may be enabled
-# on individual interfaces by using the 'logmartians' option in
-# /etc/shorewall/interfaces.
-#
-
 LOG_MARTIANS=No
 
 ###############################################################################
 #	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
 ###############################################################################
-#
-# IPTABLES
-#
-# Full path to iptables executable Shorewall uses to build the firewall. If
-# not specified or if specified with an empty value (e.g., IPTABLES="") then
-# the iptables executable located via the PATH setting below is used.
-#
 
 IPTABLES=
 
-#
-# PATH - Change this if you want to change the order in which Shorewall
-#	 searches directories for executable files.
-#
-
 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
 
-#
-# SHELL
-#
-# The firewall script is normally interpreted by /bin/sh. If you wish to change
-# the shell used to interpret that script, specify the shell here.
-#
-
 SHOREWALL_SHELL=/bin/sh
 
-# SUBSYSTEM LOCK FILE
-#
-# Set this to the name of the lock file expected by your init scripts. For
-# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't
-# use lock files, set this to "".
-#
-
 SUBSYSLOCK=/var/lock/subsys/shorewall
 
-#
-# KERNEL MODULE DIRECTORY
-#
-# If your netfilter kernel modules are in a directory other than
-# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that
-# directory in this variable. Example: MODULESDIR=/etc/modules.
-#
-
 MODULESDIR=
 
-#
-# CONFIGURATION SEARCH PATH
-#
-# This option holds a list of directory names separated by colons
-# (":"). Shorewall will search each directory in turn when looking for a
-# configuration file. When processing a 'try' command or a command
-# containing the "-c" option or that specifies a configuration directory,
-# Shorewall will automatically add the directory specified in the command
-# to the front of this list.
-#
-# If not specified or specified as null ("CONFIG_PATH=""),
-# the default is distribution-defined. See the output of "shorewall show
-# config" to find the default value on your distribution.
-#
-
 CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
 
-#
-# RESTORE SCRIPT
-#
-# This option determines the script to be run in the following cases:
-#
-#	shorewall -f start
-#	shorewall restore
-#	shorewall save
-#	shorewall forget
-#	Failure of shorewall start or shorewall restart
-#
-# The value of the option must be the name of an executable file in the
-# directory /var/lib/shorewall. If this option is not set or if it is
-# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is
-# assumed.
-#
-
 RESTOREFILE=
 
-#
-# OLD ZONE FILE FORMAT
-#
-# Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file.
-# Beginning with 2.5.0, those files were combined. For users who haven't
-# converted, we offer this variable that sets the name of the file for ipsec
-# information. This option must take the value "zones" or "ipsec". If the
-# option is not set or is set to the empty value (IPSECFILE="") then "ipsec"
-# is assumed.
-#
-
 IPSECFILE=zones
 
 ###############################################################################
 #		D E F A U L T   A C T I O N S / M A C R O S
 ###############################################################################
-#
-# In earlier Shorewall versions, a "default action" for DROP and REJECT
-# policies was specified in the file /usr/share/shorewall/actions.std.
-#
-# To allow for default rules to be applied when USE_ACTIONS=No, the
-# DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT options have
-# been 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 two are
-# similar for ACCEPT and QUEUE policies.
-#
-# The value applied to these may be:
-#
-#	a) The name of an action.
-#	b) The name of a macro
-#	c) 'None' or 'none'
-#
-# The default values are:
-#
-#	DROP_DEFAULT="Drop"
-#	REJECT_DEFAULT="Reject"
-#	ACCEPT_DEFAULT="none"
-#	QUEUE_DEFAULT="none"
-#
-# If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject
-# respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and
-# macro.Reject.
-#
-# 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
-# /etc/shorewall/policy
 
 DROP_DEFAULT="Drop"
 REJECT_DEFAULT="Reject"
@@ -436,569 +79,75 @@ QUEUE_DEFAULT="none"
 ###############################################################################
 #			F I R E W A L L	  O P T I O N S
 ###############################################################################
-#
-#  WARNING: THE 'FW' OPTION HAS BEEN REMOVED FROM THIS FILE -- The firewall
-#           zone is now declared in /etc/shorewall/zones.
-#
-
-#
-# ENABLE IP FORWARDING
-#
-# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you
-# say "Off" or "off", packet forwarding will be disabled. You would only want
-# to disable packet forwarding if you are installing Shorewall on a
-# standalone system or if you want all traffic through the Shorewall system
-# to be handled by proxies.
-#
-# If you set this variable to "Keep" or "keep", Shorewall will neither
-# enable nor disable packet forwarding.
-#
 
 IP_FORWARDING=On
 
-#
-# AUTOMATICALLY ADD NAT IP ADDRESSES
-#
-# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
-# for each NAT external address that you give in /etc/shorewall/nat. If you say
-# "No" or "no", you must add these aliases youself.
-#
-# WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
-# during processing of the "shorewall restart" command. As a consequence,
-# connections using those addresses may be severed.
-#
-
 ADD_IP_ALIASES=Yes
 
-#
-# AUTOMATICALLY ADD SNAT IP ADDRESSES
-#
-# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
-# for each SNAT external address that you give in /etc/shorewall/masq. If you
-# say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No"
-# unless you are sure that you need it -- most people don't!!!
-#
-# WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added
-# during processing of the "shorewall restart" command. As a consequence,
-# connections using those addresses may be severed.
-#
-
 ADD_SNAT_ALIASES=No
 
-#
-# RETAIN EXISTING ALIASES/IP ADDRESSES
-#
-# Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall
-# will first delete the address then re-add it. This is to ensure that the
-# address is added with the specified label. Unfortunately, this can cause
-# problems if it results in the deletion of the last IP address on an
-# interface because then all routes through the interface are automatically
-# removed.
-#
-# You can cause Shorewall to retain existing addresses by setting
-# RETAIN_ALIASES=Yes.
-#
-
 RETAIN_ALIASES=No
 
-#
-# ENABLE TRAFFIC SHAPING
-#
-# 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=Internal or internal or leave the option empty then
-# Shorewall will use its builtin traffic shaper (tc4shorewall written by
-# Arne Bernin).
-#
-# See http://shorewall.net/traffic_shaping.htm for more information.
-
 TC_ENABLED=Internal
 
-#
-# TRAFFIC SHAPING EXPERT
-#
-# 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 /etc/shorewall/providers.
-#
-# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
-# will not include these cautionary checks.
-
 TC_EXPERT=No
 
-#
-# Clear Traffic Shaping/Control
-#
-# If this option is set to 'No' then Shorewall won't clear the current
-# traffic control rules during [re]start. This setting is intended
-# for use by people that prefer to configure traffic shaping when
-# the network interfaces come up rather than when the firewall
-# is started. If that is what you want to do, set TC_ENABLED=No and
-# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
-# way, your traffic shaping rules can still use the 'fwmark'
-# classifier based on packet marking defined in /etc/shorewall/tcrules.
-#
-# If omitted, CLEAR_TC=Yes is assumed.
-#
-
 CLEAR_TC=Yes
 
-#
-# Mark Packets in the forward chain
-#
-# When processing the tcrules file, Shorewall normally marks packets in the
-# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
-# this to "Yes". If not specified or if set to the empty value (e.g.,
-# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
-#
-# Marking packets in the FORWARD chain has the advantage that inbound
-# packets destined for Masqueraded/SNATed local hosts have had their
-# destination address rewritten so they can be marked based on their
-# destination. When packets are marked in the PREROUTING chain, packets
-# destined for Masqueraded/SNATed local hosts still have a destination address
-# corresponding to the firewall's external interface.
-#
-# Note: Older kernels do not support marking packets in the FORWARD chain and
-#	setting this variable to Yes may cause startup problems.
-#
-
 MARK_IN_FORWARD_CHAIN=No
 
-#
-# MSS CLAMPING
-#
-# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"
-# option. This option is most commonly required when your internet
-# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
-# have CONFIG_IP_NF_TARGET_TCPMSS set.
-#
-# [From the kernel help:
-#
-#    This option adds a `TCPMSS' target, which allows you to alter the
-#    MSS value of TCP SYN packets, to control the maximum size for that
-#    connection (usually limiting it to your outgoing interface's MTU
-#    minus 40).
-#
-#    This is used to overcome criminally braindead ISPs or servers which
-#    block ICMP Fragmentation Needed packets.  The symptoms of this
-#    problem are that everything works fine from your Linux
-#    firewall/router, but machines behind it can never exchange large
-#    packets:
-#	 1) Web browsers connect, then hang with no data received.
-#	 2) Small mail works fine, but large emails hang.
-#	 3) ssh works fine, but scp hangs after initial handshaking.
-# ]
-#
-# If left blank, or set to "No" or "no", the option is not enabled.
-#
-# You may also set this option to a numeric value in which case Shorewall will
-# set up a rule to modify the MSS value in SYN packets to the value that
-# you specify.
-#
-# Example:
-#
-#	CLAMPMSS=1400
-#
-
 CLAMPMSS=No
 
-#
-# ROUTE FILTERING
-#
-# Set this variable to "Yes" or "yes" if you want kernel route filtering on all
-# interfaces started while Shorewall is started (anti-spoofing measure).
-#
-# If this variable is not set or is set to the empty value, "No" is assumed.
-# Regardless of the setting of ROUTE_FILTER, you can still enable route
-# filtering on individual interfaces using the 'routefilter' option in the
-# /etc/shorewall/interfaces file.
-#
-
 ROUTE_FILTER=No
 
-#
-# DNAT IP ADDRESS DETECTION
-#
-# Normally when Shorewall encounters the following rule:
-#
-#	DNAT	net	loc:192.168.1.3	tcp	80
-#
-# it will forward TCP port 80 connections from the net to 192.168.1.3
-# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
-# convenient for two reasons:
-#
-#	a) If the the network interface has a dynamic IP address, the
-#	   firewall configuration will work even when the address
-#	   changes.
-#
-#	b) It saves having to configure the IP address in the rule
-#	   while still allowing the firewall to be started before the
-#	   internet interface is brought up.
-#
-# This default behavior can also have a negative effect. If the
-# internet interface has more than one IP address then the above
-# rule will forward connection requests on all of these addresses;
-# that may not be what is desired.
-#
-# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
-# only if the original destination address is the primary IP address of
-# one of the interfaces associated with the source zone. Note that this
-# requires all interfaces to the source zone to be up when the firewall
-# is [re]started.
-#
-
 DETECT_DNAT_IPADDRS=No
 
-#
-# MUTEX TIMEOUT
-#
-# The value of this variable determines the number of seconds that programs
-# will wait for exclusive access to the Shorewall 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 restart" command.
-#
-
 MUTEX_TIMEOUT=60
 
-#
-# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT
-#
-# Normally, when a "shorewall stop" command is issued or an error occurs during
-# the execution of another shorewall command, Shorewall puts the firewall into
-# a state where only traffic to/from the hosts listed in
-# /etc/shorewall/routestopped is accepted.
-#
-# When performing remote administration on a Shorewall firewall, it is
-# therefore recommended that the IP address of the computer being used for
-# administration be added to the firewall's /etc/shorewall/routestopped file.
-#
-# Some administrators have a hard time remembering to do this with the result
-# that they get to drive across town in the middle of the night to restart
-# a remote firewall (or worse, they have to get someone out of bed to drive
-# across town to restart a very remote firewall).
-#
-# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this
-# setting, when the firewall enters the 'stopped' state:
-#
-# All traffic that is part of or related to established connections is still
-# allowed and all OUTPUT traffic is allowed. This is in addition to traffic
-# to and from hosts listed in /etc/shorewall/routestopped.
-#
-# If this variable is not set or it is set to the null value then
-# ADMINISABSENTMINDED=No is assumed.
-#
-
 ADMINISABSENTMINDED=Yes
 
-#
-# BLACKLIST Behavior
-#
-# Shorewall offers two types of blacklisting:
-#
-#	- static blacklisting through the /etc/shorewall/blacklist file
-#	  together with the 'blacklist' interface option.
-#	- dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.
-#
-# The following variable determines whether the blacklist is checked for each
-# packet or for each new connection.
-#
-#	BLACKLISTNEWONLY=Yes	Only consult blacklists for new connection
-#				requests
-#
-#	BLACKLISTNEWONLY=No	Consult blacklists for all packets.
-#
-# If the BLACKLISTNEWONLY option is not set or is set to the empty value then
-# BLACKLISTNEWONLY=No is assumed.
-#
-
 BLACKLISTNEWONLY=Yes
 
-#
-# Users with a large blacklist find that "shorwall [re]start" takes a long
-# time and that new connections are disabled during that time. By setting
-# DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections
-# before loading the blacklist.
-#
-
 DELAYBLACKLISTLOAD=No
 
-# MODULE NAME SUFFIX
-#
-# When loading a module named in /etc/shorewall/modules, Shorewall normally
-# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names
-# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a
-# different naming convention then you can specify the suffix (extension) for
-# module names in this variable.
-#
-# To see what suffix is used by your distribution:
-#
-#     ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
-#
-# All of the file names listed should have the same suffix (extension). Set
-# MODULE_SUFFIX to that suffix.
-#
-# Examples:
-#
-#	If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"
-#	If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"
-#
-
 MODULE_SUFFIX=
 
-#
-# DISABLE IPV6
-#
-# Distributions (notably SUSE) are beginning to ship with IPV6
-# enabled. If you are not using IPV6, you are at risk of being
-# exploited by users who do. Setting DISABLE_IPV6=Yes will cause
-# Shorewall to disable IPV6 traffic to/from and through your
-# firewall system. This requires that you have ip6tables installed.
-
 DISABLE_IPV6=Yes
 
-#
-# BRIDGING
-#
-# If you wish to restrict connections through a bridge
-# (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have
-# the physdev match option enabled; that option is available at the above URL
-# for 2.4 kernels and is included as a standard part of the 2.6 series
-# kernels. If not specified or specified as empty (BRIDGING="") then "No" is
-# assumed.
-#
-
 BRIDGING=No
 
-#
-# DYNAMIC ZONES
-#
-# If you need to be able to add and delete hosts from zones dynamically then
-# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.
-
 DYNAMIC_ZONES=No
 
-#
-# USE PKTTYPE MATCH
-#
-# Some users have reported problems with the PKTTYPE match extension not being
-# able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall
-# will use IP addresses to detect broadcasts rather than pkttype. If not given
-# or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed.
-#
-
 PKTTYPE=Yes
 
-#
-# RFC 1918 BEHAVIOR
-#
-# Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918'
-# processing to cease for a packet if the packet's source IP address matches
-# the rule. Thus, if you have:
-#
-#	SUBNETS			TARGET
-#	192.168.1.0/24		RETURN
-#
-# then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you
-# also have:
-#
-#	SUBNETS			TARGET
-#	10.0.0.0/8		logdrop
-#
-# Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped
-# since while the packet's source matches the RETURN rule, the packet's
-# destination matches the 'logdrop' rule.
-#
-# If not specified or specified as empty (e.g., RFC1918_STRICT="") then
-# RFC1918_STRICT=No is assumed.
-#
-# WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support
-#	   'conntrack state' match.
-#
-
 RFC1918_STRICT=No
 
-#
-# MAC List Table
-#
-# 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_TABLE=filter
 
-#
-# MACLIST caching
-#
-# 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
-# (/etc/shorewall/maclist).
-#
-# When a new connection arrives from a 'maclist' interface, the packet passes
-# through the list of entries for that interface in /etc/shorewall/maclist. If
-# there is a match then the source IP address is added to the 'Recent' set for
-# that interface. Subsequent connection attempts from that IP address occuring
-# within $MACLIST_TTL seconds will be accepted without having to scan all of
-# the entries. After $MACLIST_TTL from the first accepted connection request,
-# 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.
-#
-
 MACLIST_TTL=
 
-#
-# Save/Restore IPSETS
-#
-# If SAVE_IPSETS=Yes then Shorewall will:
-#
-#	Restore the last saved ipset contents during "shorewall [re]start"
-#	Save the current ipset contents during "shorewall save"
-#
-#	Regardless of the setting of SAVE_IPSETS, if ipset contents were
-#	saved during a "shorewall save" then they will be restored during
-#	a subsequent "shorewall restore".
-#
-
 SAVE_IPSETS=No
 
-#
-# Map Old Actions
-#
-# Previously, Shorewall included a large number of standard actions (AllowPing,
-# AllowFTP, ...). These have been replaced with parameterized macros. For
-# compatibility, Shorewall can map the old names into invocations of the new
-# macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to
-# the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed
-#
-
 MAPOLDACTIONS=No
 
-#
-# Fast ESTABLISHED/RELATED handling
-#
-# Normally, Shorewall delays 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 and
-# RELATED sections of the rules file.
-
 FASTACCEPT=No
 
-#
-# Implicit CONTINUE policy for sub-zones
-#
-# When a zone is declared to be a subzone of one or more other zones, it
-# is typically the case that you want the rules for the parent zone(s) to
-# be applied to connections to/from the subzone that don't match any
-# subzone specific rules. That way, you don't have to duplicate the parent
-# zone's rules in order for them to also apply to the subzone(s). That is
-# the behavior with IMPLICIT_CONTINUE=Yes. If you don't want that behavior
-# and want the policies for the sub-zone to be determined by the standard
-# policy processing, set IMPLICIT_CONTINUE=No or IMPLICIT_CONTINUE=.
-#
-# Note that even with IMPLICIT_CONTINUE=Yes, you can override the implicit
-# CONTINUE policy by adding an explicit policy (one that does not contain
-# "all" in either the SOURCE or DEST columns).
-
 IMPLICIT_CONTINUE=Yes
 
-#
-# Use high mark values for policy routing
-#
-# Normally, Shorewall restricts the set of mark values to 1-255. If you set
-# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of routing
-# mark values (those specified in the /etc/shorewall/providers file) to
-# a multiple of 256 (256 to 65280) or their hexadecimal equivalents
-# (0x0100 to 0xff00, with the low-order byte of the value being zero).
-# This allows connection marks to be shared between traffic shaping and
-# policy routing. Traffic shaping marks are always restricted to 1-255.
-#
-# Setting HIGH_ROUTE_MARKS=Yes requires that your kernel and iptables support
-# both the extended CONNMARK target and the extended connmark match
-# capabilities (see the output of "shorewall show capabilities").
-
 HIGH_ROUTE_MARKS=No
 
-#
-# Use Actions
-#
-# While Shorewall Actions can be very useful, they also require a sizable
-# amount of code to implement. By setting USE_ACTIONS=No, you can omit
-# /usr/share/shorewall/lib/actions from your configuration.
-
 USE_ACTIONS=Yes
 
-#
-# Optimize Ruleset
-#
-# Traditionally, Shorewall has created rules for the complete matrix of
-# Networks 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 changes. When the matrix is sparse, this results in lots of
-# largely useless rules.
-#
-# These extra rules can be eliminated by setting OPTIMIZE=1
-#
-
 OPTIMIZE=0
 
 ###############################################################################
 #			P A C K E T   D I S P O S I T I O N
 ###############################################################################
-#
-# BLACKLIST DISPOSITION
-#
-# Set this variable to the action that you want to perform on packets from
-# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
-# DROP is assumed.
-#
 
 BLACKLIST_DISPOSITION=DROP
 
-#
-# MAC List Disposition
-#
-# This variable determines the disposition of connection requests arriving
-# on interfaces that have the 'maclist' option and that are from a device
-# that is not listed for that interface in /etc/shorewall/maclist. Valid
-# values are ACCEPT, DROP and REJECT. If not specified or specified as
-# empty (MACLIST_DISPOSITION="") then REJECT is assumed
-#
-
 MACLIST_DISPOSITION=REJECT
 
-#
-# TCP FLAGS Disposition
-#
-# This variable determins the disposition of packets having an invalid
-# combination of TCP flags that are received on interfaces having the
-# 'tcpflags' option specified in /etc/shorewall/interfaces or in
-# /etc/shorewall/hosts. If not specified or specified as empty
-# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
-#
-
 TCP_FLAGS_DISPOSITION=DROP
 
 #LAST LINE -- DO NOT REMOVE