diff --git a/Samples/two-interfaces/interfaces b/Samples/two-interfaces/interfaces
index 696e09952..ea694e025 100644
--- a/Samples/two-interfaces/interfaces
+++ b/Samples/two-interfaces/interfaces
@@ -1,5 +1,5 @@
 #
-# Shorewall version 3.2 - Sample Interfaces File for two-interface configuration.
+# Shorewall version 3.4 - Sample Interfaces File for two-interface configuration.
 # Copyright (C) 2006 by the Shorewall Team
 #
 # This library is free software; you can redistribute it and/or
diff --git a/Samples/two-interfaces/masq b/Samples/two-interfaces/masq
index 6d7f649f5..45264039b 100644
--- a/Samples/two-interfaces/masq
+++ b/Samples/two-interfaces/masq
@@ -1,5 +1,5 @@
 #
-# Shorewall version 3.2 - Sample Masq file for two-interface configuration.
+# Shorewall version 3.4 - Sample Masq file for two-interface configuration.
 # Copyright (C) 2006 by the Shorewall Team
 #
 # This library is free software; you can redistribute it and/or
diff --git a/Samples/two-interfaces/policy b/Samples/two-interfaces/policy
index e1d8b7ca8..31927350c 100644
--- a/Samples/two-interfaces/policy
+++ b/Samples/two-interfaces/policy
@@ -1,5 +1,5 @@
 #
-# Shorewall version 3.2 - Sample Policy File for two-interface configuration.
+# Shorewall version 3.4 - Sample Policy File for two-interface configuration.
 # Copyright (C) 2006 by the Shorewall Team
 #
 # This library is free software; you can redistribute it and/or
diff --git a/Samples/two-interfaces/routestopped b/Samples/two-interfaces/routestopped
index b50b93e25..b20034dc3 100644
--- a/Samples/two-interfaces/routestopped
+++ b/Samples/two-interfaces/routestopped
@@ -1,5 +1,5 @@
 #
-# Shorewall version 3.2 - Sample Routestopped File for two-interface configuration.
+# Shorewall version 3.4 - Sample Routestopped File for two-interface configuration.
 # Copyright (C) 2006 by the Shorewall Team
 #
 # This library is free software; you can redistribute it and/or
diff --git a/Samples/two-interfaces/rules b/Samples/two-interfaces/rules
index 075989063..8861ffbeb 100644
--- a/Samples/two-interfaces/rules
+++ b/Samples/two-interfaces/rules
@@ -1,5 +1,5 @@
 #
-# Shorewall version 3.2 - Sample Rules File for two-interface configuration.
+# Shorewall version 3.4 - Sample Rules File for two-interface configuration.
 # Copyright (C) 2006 by the Shorewall Team
 #
 # This library is free software; you can redistribute it and/or
diff --git a/Samples/two-interfaces/shorewall.conf b/Samples/two-interfaces/shorewall.conf
new file mode 100644
index 000000000..ee260affc
--- /dev/null
+++ b/Samples/two-interfaces/shorewall.conf
@@ -0,0 +1,969 @@
+###############################################################################
+#
+# Shorewall version 3.4 - Sample shorewall.conf for two-interface configuration.
+# Copyright (C) 2006 by the Shorewall Team
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License, or (at your option) any later version.
+#
+# See the file README.txt for further details.
+###############################################################################
+#		       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=
+
+#
+# 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"
+ACCEPT_DEFAULT="none"
+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 and included
+# by setting OPTIMIZE=0
+#
+
+OPTIMIZE=1
+
+###############################################################################
+#			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
diff --git a/Samples/two-interfaces/zones b/Samples/two-interfaces/zones
index f8add5423..0e371a5a7 100644
--- a/Samples/two-interfaces/zones
+++ b/Samples/two-interfaces/zones
@@ -1,5 +1,5 @@
 #
-# Shorewall version 3.2 - Sample Zones File for two-interface configuration.
+# Shorewall version 3.4 - Sample Zones File for two-interface configuration.
 # Copyright (C) 2006 by the Shorewall Team
 #
 # This library is free software; you can redistribute it and/or