shorewall_code/Shorewall2/releasenotes.txt

Shorewall 2.2.0-Beta7

----------------------------------------------------------------------
Problems Corrected since 2.0.3

1)  A non-empty DEST entry in /etc/shorewall/tcrules will generate an
    error and Shorewall fails to start.

2)  A potential security vulnerablilty in the way that Shorewall
    handles temporary files and directories has been corrected.

3)  Two problems with logging NAT rules (DNAT and REDIRECT) could cause
    startup failures.

4)  Some users have reported the pkttype match option in iptables/
    Netfilter failing to match certain broadcast packets. The result 
    is that the firewall log shows a lot of broadcast packets.

    Users experiencing this problem can use PKTTYPE=No in
    shorewall.conf to cause Shorewall to use IP address filtering of 
    broadcasts rather than packet type.

Problems Corrected since 2.1.0

1)  The "check" command fails with the following message:

	iptables: No chain/target/match by that name

Problems Corrected since 2.1.4

1)  Per-interface options like 'norfc1918' are not applied to requests
    that have been unencrypted as a result of an entry in the SPD.

Problems corrected since 2.1.6

1)  Dynamic zones marked as 'ipsec' in /etc/shorewall/ipsec now work
    correctly.

Problems corrected since 2.1.7

1)  Fix parsing of ACTION with ":" but no log level (Richard Musil).

2)  Fix parsing of PROTO column in /etc/shorewall/tcrules.

3)  Packets that will be encrypted or that have been decrypted by IPSEC
    are now exempted from the rules established by one-to-one NAT. This
    allows tunnel mode IPSEC to work for local networks where some of
    the systems use one-to-one NAT.

4)  The shorewall.spec file now directs rpm to cause Shorewall to start
    automatically at boot. This feature was inadvertently removed in
    Shorewall 2.1.3.

Problems corrected since 2.1.8

1)  IP ranges in the routestopped and tunnels files now work.

2)  Rules where an IP range appears in both the source and destination
    now work correctly.

3)  With complex proxy arp configurations involving two or more 
    ordered pairs of interfaces, the /proc/sys/net/ipv4/conf/*/proxy_arp
    flags were sometimes set incorrectly. This has been fixed.

Problems corrected since 2.1.9

1)  With DELAYBLACKLISTLOAD=No, the blacklist was previously not
    loaded.

Problems corrected since 2.1.10

1)  If TC_ENABLED=Yes but you have no /etc/shorewall/tcstart file then
    "shorewall restore" will no longer attempt to run the tcstart file.

2)  Previously it was necessary to define ipsec zones (those with 
    "Yes" in the IPSEC column in /etc/shorewall/ipsec or those having
    an entry in /etc/shorewall/hosts having the "ipsec" option) before
    other zones using the same interface. This has been corrected.

3)  A typo has been corrected that prevented the 'logmartians' interface
    option from working correctly.

4)  A typo has been corrected in and a clarification added to the
    /etc/shorewall/blacklist file.

Problems corrected since 2.1.11

1)  If a zone name appears more than once in /etc/shorewall/zones,
    Shorewall will now issue an error message and terminate during
    "shorewall [re]start" or "shorewall check".

2)  If a configuration has two or more "complex" zones (zones having
    IPSEC hosts or zones having more than one subnet on an interface)
    then an incorrect ruleset is generated. This problem was introduced
    in 2.1.11. 

Problems corrected since 2.2.0 Beta 1.

1)  The "shorewall check" command results in the (harmless) error
    message:

	/usr/share/shorewall/firewall: line 2753: 
           check_dupliate_zones: command not found
	   
2)  The AllowNTP standard action now allows outgoing responses to 
    broadcasts.
    
3)  A clarification has been added to the hosts file's description of
    the 'ipsec' option pointing out that the option is redundent if the
    zone named in the ZONE column has been designated an IPSEC zone in
    the /etc/shorewall/ipsec file.

Problems corrected since 2.2.0 Beta 2.

1)  Missing '#' in the rfc1918 file.

2) The INSTALL file now includes special instructions for Slackware
   users.

Problems corrected since 2.2.0 Beta 3.

1) A cut and paste error resulted in some nonsense in the description
   of the IPSEC column in /etc/shorewall/masq.

2) A typo in /etc/shorewall/rules has been corrected.

3) The bogons file has been updated.

4) The "shorewall add" command previously reported success but did 
   nothing -- now it works.

Problems corrected since 2.2.0 Beta 4:

1) A typo in shorewall.conf (NETNOTSYN) has been corrected.

Problems corrected since 2.2.0 Beta 5:

1) Many problems associated with an empty IPTABLES variable have been
   corrected.

2) A 'chain already exists' error occurs on "shorewall add" if you are
   using the 'mss' option in the ipsec file.

Problems corrected since 2.2.0 Beta 6:

1) The "shorewall add" and "shorewall delete" commands now work in a
   bridged environment. The syntax is:

	   shorewall add <interface>[:<port>]:<address> <zone>
	   shorewall delete <interface>[:<port>]:<address> <zone>

   Examples:

	   shorewall add br0:eth2:192.168.1.3 OK
	   shorewall delete br0:eth2:192.168.1.3 OK

2) Previously, "shorewall save" created an out-of-sequence restore
   script. The commands saved in the user's /etc/shorewall/start script
   were executed prior to the Netfilter configuration being
   restored. This has been corrected so that "shorewall save" now
   places those commands at the end of the script. 

   To accomplish this change, the "restore base" file
   (/var/lib/shorewall/restore-base) has been split into two files:

   /var/lib/shorewall/restore-base -- commands to be executed before
   Netfilter the configuration is restored.

   /var/lib/shorewall/restore-tail -- commands to be executed after the
   Netfilter configuration is restored.

3) Previously, traffic from the firewall to a dynamic zone member host
   did not need to match the interface specified when the host was
   added to the zone. For example, if eth0:1.2.3.4 is added to dynamic
   zone Z then traffic out of any firewall interface to 1.2.3.4 will
   obey the fw->Z policies and rules. This has been corrected.

4) Shorewall uses the temporary chain 'fooX1234' to probe iptables for
   detrmining which features are supported. Previously, if that chain
   happened to exist when Shorewall was run, capabilities were
   mis-detected.

Problems corrected since 2.2.0 Beta 7:

1) A typo in the /etc/shorewall/interfaces file has been corrected.

2) The "add" and "delete" commands were generating incorrect policy 
   matches when policy match support was available.

-----------------------------------------------------------------------
Issues when migrating from Shorewall 2.0 to Shorewall 2.1:

1)  Shorewall configuration files except shorewall.conf are now empty
    (they contain only comments). If you wish to retain the defaults
    in any of the following files, you should copy these files before
    upgrading them then restore them after the upgrade:

    /etc/shorewall/zones
    /etc/shorewall/policy
    /etc/shorewall/tos

2)  The following builtin actions have been removed and have been
    replaced by the new action logging implementation described in the
    new features below.

	logNotSyn
	rLogNotSyn
	dLogNotSyn

3)  If shorewall.conf is upgraded to the latest version, it needs to be
    modified to set STARTUP_ENABLED=Yes

4)  The Leaf/Bering version of Shorewall was previously named:

	shorwall-<version>.lrp

    Beginning with 2.1, that file will now be named:

	shorewall-lrp-<version>.tgz

    Simply rename that file to 'shorwall.lrp' when installing it on your
    LEAF/Bering system.

5)  The ORIGINAL DEST column of the /etc/shorewall/rules file may no
    longer contain a second (SNAT) address. You must use an entry in
    /etc/shorewall/masq instead.

    Example from Shorewall FAQ #1:

    Prior to Shorewall 2.1:

	  /etc/shorewall/interfaces

		loc	eth1	detect	routeback,...

	  /etc/shorewall/rules

		DNAT	loc	loc:192.168.1.12	tcp	80 \
			-	130.252.100.69:192.168.1.254

    Shorewall 2.1 and Later:

	  /etc/shorewall/interfaces

		loc	eth1	detect	routeback,...

	  /etc/shorewall/masq:

		eth1	eth1	192.168.1.254	tcp	80	

		
	  /etc/shorewall/rules:

		DNAT	loc	loc:192.168.1.12	tcp	80 \
			-	130.252.100.69

6)  The 'logunclean' and 'dropunclean' options that were deprecated in
    Shorewall 2.0 have now been removed completely.

7)  A new IPTABLES variable has been added to shorewall.conf. This
    variable names the iptables executable that Shorewall will use. The
    variable is set to "/sbin/iptables". If you use the new
    shorewall.conf, you may need to change this setting to maintain
    compabibility with your current setup (if you use your existing
    shorewall.conf that does not set IPTABLES then you should
    experience no change in behavior).

-----------------------------------------------------------------------
New Features:

1)  ICMP packets that are in the INVALID state are now dropped by the
    Reject and Drop default actions. They do so using the new 
    'dropInvalid' builtin action.

2)  The /etc/shorewall/masq file INTERFACE column now allows additional
    options.

    Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT 
    rules defined in the /etc/shorewall/nat file. If you preceed the
    interface name with a plus sign ("+") then the rule will be
    evaluated before one-to-one NAT.

    Examples:

	+eth0
	+eth1:192.0.2.32/27

    Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an
    entry by following the interface name by ":" but no digit. 

    Examples:

	eth0:
	eth1::192.0.2.32/27
	+eth3:

3)  Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
    you to override the setting of ADD_IP_ALIASES=Yes by following the
    interface name with ":" but no digit.

4)  All configuration files in the Shorewall distribution with the
    exception of shorewall.conf are now empty. In particular, the
    /etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
    files now have no active entries. Hopefully this will stop the
    questions on the support and development lists regarding why the
    default entries are the way they are.

5)  Previously, including a log level (and optionally a log tag) on a
    rule that specified a user-defined (or Shorewall-defined) action
    would log all traffic passed to the action. Beginning with this
    release, specifying a log level in a rule that specifies a user-
    or Shorewall-defined action will cause each rule in the action to
    be logged with the specified level (and tag).

    The extent to which logging of action rules occurs is goverend by
    the following:

    a) When you invoke an action and specify a log level, only those
    rules in the action that have no log level will be changed to log
    at the level specified at the action invocation.

    Example:

	/etc/shorewall/action.foo:

		ACCEPT	-	-	tcp	22
		bar:info	

	/etc/shorewall/rules:

		foo:debug	fw	net

	Logging in the invoked 'foo' action will be:

		ACCEPT:debug	-	-	tcp	22
		bar:info	

    b) If you follow the log level with "!" then logging will
    be at that level for all rules recursively invoked by the action

    Example:

	/etc/shorewall/action.foo:

		ACCEPT	-	-	tcp	22
		bar:info	

	/etc/shorewall/rules:

		foo:debug!	fw	net

	Logging in the invoke 'foo' action will be:

		ACCEPT:debug	-	-	tcp	22
		bar:debug!
	
    This change has an effect on extension scripts used with
    user-defined actions. If you define an action 'acton' and you have
    an /etc/shorewall/acton script then when that script is invoked,
    the following three variables will be set for use by the script:

	$CHAIN = the name of the chain where your rules are to be
	placed. When logging is used on an action invocation,
	Shorewall creates a chain with a slightly different name from
	the action itself.

	$LEVEL = Log level. If empty, no logging was specified.

	$TAG   = Log Tag.

    Example:

    /etc/shorewall/rules:

	acton:info:test

    Your /etc/shorewall/acton file will be run with:

	 $CHAIN="%acton1"
	 $LEVEL="info"
	 $TAG="test"

6)  The /etc/shorewall/startup_disabled file is no longer created when 
    Shorewall is first installed. Rather, the variable STARTUP_ENABLED
    is set to 'No' in /etc/shorewall/shorewall.conf. In order to get 
    Shorewall to start, that variable's value must be set to
    'Yes'. This change accomplishes two things:

    a) It prevents Shorewall from being started prematurely by the
    user's initialization scripts.

    b) It causes /etc/shorewall/shorewall.conf to be modified so that
    it won't be replaced by upgrades using RPM.

7)  Some additional support has been added for the 2.6 Kernel IPSEC
    implementation. To use this support, you must have installed the
    IPSEC policy match patch and the four IPSEC/Netfilter patches
    from Patch-0-Matic-ng. The policy match patch affects both your
    kernel and iptables.

    There are two ways to specify that IPSEC is to be used when
    communicating with a set of hosts; both methods involve the new
    /etc/shorewall/ipsec file:

    a) If encrypted communication is used with all hosts in a zone,
    then you can designate the zone as an "ipsec" zone by placing
    'Yes" in the IPSEC ONLY column in the /etc/shorewall/ipsec:

	#ZONE		IPSEC	OPTIONS ...
	#		ONLY
	vpn		Yes

    The hosts in the zone (if any) must be specified in
    /etc/shorewall/hosts but you do not need to specify the 'ipsec'
    option on the entries in that file (see below).

    Dynamic zones involving IPSEC must use that technique.

    Example:

    Under 2.4 Kernel FreeS/Wan:

	  /etc/shorewall/zones:

	  net	Net	The big bad Internet
	  vpn	VPN	Remote Network

	  /etc/shorewall/interfaces:

	  net	eth0	...
	  vpn	ipsec0	...

    Under 2.6 Kernel with this new support:
    
	/etc/shorewall/zones:

	net		Net	The big bad Internet
	vpn		VPN	Remote Network

	/etc/shorewall/interfaces:

	net	eth0	...
    
	/etc/shorewall/hosts:

	vpn	eth0:0.0.0.0/0

	/etc/shorewall/ipsec

	vpn	Yes

    b) If only part of the hosts in a zone require encrypted
    communication, you may use of the new 'ipsec' option in
    /etc/shorewall/hosts to designate those hosts.

    Example:

    Under 2.4 Kernel FreeS/Wan:

	  /etc/shorewall/zones:

	  net	Net	The big bad Internet
	  loc	Local	Extended local zone

	  /etc/shorewall/interfaces:

	  net	eth0	...
	  loc	eth1	...
	  loc	ipsec0	...

    Under 2.6 Kernel with this new support:
    
	/etc/shorewall/zones:

	net		Net	The big bad Internet
	vpn      	VPN	Remote Network

	/etc/shorewall/interfaces:

	net	eth0	...
	loc	eth1	...
    
	/etc/shorewall/hosts:

	vpn	eth0:0.0.0.0/0	ipsec,...

    Regardless of which technique you choose, you can specify
    additional SA options for the zone in the /etc/shorewall/ipsec
    entry.

    The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
    input-output, input and output characteristics of the security
    policies to be used to decrypt (input) or encrypt (output) traffic
    to/from the zone.

    The available options are:

	reqid[!]=<number> where <number> is specified using setkey(8) using
	the 'unique:<number>' option for the SPD level.

	 spi[!]=<number> where <number> is the SPI of the SA. Since
	 different SAs are used to encrypt and decrypt traffic, this
	 option should only be listed in the IN OPTIONS and OUT OPTIONS
	 columns.

	 proto[!]=ah|esp|ipcomp

	 mss=<number> (sets the MSS value in TCP SYN packets and is not
                       related to policy matching) 

	 mode[!]=transport|tunnel

	 tunnel-src[!]=<address>[/<mask>] (only available with mode=tunnel)

	 tunnel-dst[!]=<address>[/<mask>] (only available with
	 mode=tunnel). Because tunnel source and destination are
	 dependent on the direction of the traffic, these options
	 should only appear in the IN OPTIONS and OUT OPTIONS columns.

	 strict  (if specified, packets must match all policies;
	 policies are delimited by 'next').

	 next    (only available with strict)

    Examples:

	#ZONE	IPSEC	OPTIONS			IN		OUT...
	#	ONLY				OPTIONS		OPTIONS
	vpn	Yes	mode=tunnel,proto=esp	spi=1000	spi=1001
	loc	No	reqid=44,mode=transport

    The /etc/shorewall/masq file has a new IPSEC column added. If you
    specify Yes or yes in that column then the unencrypted packets will
    have their source address changed. Otherwise, the unencrypted
    packets will not have their source addresses changed. This column
    may also contain a comma-separated list of the options specified
    above in which case only those packets that will be encrypted
    by an SA matching the given options will have their source address
    changed.

8)  To improve interoperability, tunnels of type 'ipsec' no longer
    enforce the use of source port 500 for ISAKMP and OpenVPN 
    tunnels no longer enforce use of the specified port as both the
    source and destination ports.

9)  A new 'allowBcast' builtin action has been added -- it silently
    allows broadcasts and multicasts.

10) The -c option in /sbin/shorewall commands is now deprecated. The
    commands where -c was previously allowed now permit you to specify
    a configuration directory after the command:

      shorewall check   [ <configuration-directory> ]
      shorewall restart [ <configuration-directory> ]
      shorewall start   [ <configuration-directory> ]

11) Normally, when SNAT or MASQUERADE is applied to a tcp or udp 
    connection, Netfilter attempts to retain the source port 
    number. If it has to change to port number to avoid 
    <source address>,<source port> conflicts, it tries to do so
    within port ranges ( < 512, 512-1023, and > 1023). You may
    now specify an explicit range of source ports to be used 
    by following the address or address range (if any) in the
    ADDRESS column with ":" and a port range in the format
    <low-port>-<high-port>. You must specify either "tcp" or
    "udp" in the PROTO column.

    Examples 1 -- MASQUERADE with tcp source ports 4000-5000:

    #INTERFACE SUBNET		  ADDRESS		PROTO
    eth0       192.168.1.0/24	  :4000-5000		tcp

    Example 2 -- SNAT with udp source ports 7000-8000:

    #INTERFACE SUBNET		  ADDRESS		PROTO
    eth0       10.0.0.0/8	  192.0.2.44:7000-8000	udp

12) You may now account by user/group ID for outbound traffic from the
    firewall itself with entries in /etc/shorewall/accounting. Such
    accounting rules must be placed in the OUTPUT chain.

    See the comments at the top of /etc/shorewall/accounting for
    details.

13) Shorewall now verifies that your kernel and iptables have physdev
    match support if BRIDGING=Yes in shorewall.conf.

14) Beginning with this release, if your kernel and iptables have
    iprange match support (see the output from "shorewall check"), then
    with the exception of the /etc/shorewall/netmap file, anywhere that
    a network address may appear an IP address range of the form <low
    address>-<high address> may also appear.

15) Support has been added for the iptables CLASSIFY target. That
    target allows you to classify packets for traffic shaping directly
    rather than indirectly through fwmark. Simply enter the
    <major>:<minor> classification in the first column of
    /etc/shorewall/tcrules:

    Example:

	#MARK/      SOURCE       DEST      PROTO     PORT(S)
	#CLASSIFY
	1:30	    -		 eth0	   tcp	     25

    Note that when using this form of rule, it is acceptable to include
    the name of an interface in the DEST column.

    Marking using the CLASSIFY target always occurs in the POSTROUTING
    chain of the mangle table and is not affected by the setting of
    MARK_IN_FORWARD_CHAIN in shorewall.conf.

16) During "shorewall start", IP addresses to be added as a consequence
    of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted
    when /etc/shorewall/nat and /etc/shorewall/masq are processed then
    the are re-added later. This is done to help ensure that the
    addresses can be added with the specified labels but can have
    the undesirable side effect of causing routes to be quietly
    deleted. A new RETAIN_ALIASES option has been added to
    shorewall.conf; when this option is set to Yes, existing addresses
    will not be deleted. Regardless of the setting of RETAIN_ALIASES,
    addresses added during "shorewall start" are still deleted at a
    subsequent "shorewall stop" or "shorewall restart".

17) Users with a large black list (from /etc/shorewall/blacklist) may 
    want to set the new DELAYBLACKLISTLOAD option in
    shorewall.conf. When DELAYBLACKLISTLOAD=Yes, Shorewall will
    enable new connections before loading the blacklist rules. While
    this may allow connections from blacklisted hosts to slip by during
    construction of the blacklist, it can substantially reduce the time
    that all new connections are disabled during "shorewall [re]start".

18) Using the default LOGFORMAT, chain names longer than 11 characters 
    (such as in user-defined actions) may result in log prefix
    truncation. A new shorewall.conf action  LOGTAGONLY has been added
    to deal with this problem. When LOGTAGONLY=Yes, logging rules that
    specify a log tag will substitute the tag for the chain name in the
    log prefix.

    Example -- file /etc/shorewall/action.thisisaverylogactionname:

    Rule:

	DROP:info:ftp	0.0.0.0/0	0.0.0.0/0	tcp	    21
	
    Log prefix with LOGTAGONLY=No:

	Shorewall:thisisaverylongacti

    Log prefix with LOGTAGONLY=Yes:

	Shorewall:ftp:DROP

19) Shorewall now resets the 'accept_source_route' flag for all
    interfaces. If you wish to accept source routing on an interface,
    you must specify the new 'sourceroute' interface option in
    /etc/shorewall/interfaces.

20) The default Drop and Reject actions now invoke the new standard
    action 'AllowICMPs'. This new action accepts critical ICMP types:
    
	Type 3 code 4 (fragmentation needed)
	Type 11       (TTL exceeded)

21) Explicit control over the kernel's Martian logging is now provided
    using the new 'logmartians' interface option. If you include
    'logmartians' in the interface option list then logging of Martian
    packets on will be enabled on the specified interface.
    If you wish to globally enable martian logging, you can set
    LOG_MARTIANS=Yes in shorewall.conf.

22) You may now cause Shorewall to use the '--set-mss' option of the
    TCPMSS target. In other words, you can cause Shorewall to set the
    MSS field of SYN packets passing through the firewall to the value
    you specify. This feature extends the existing CLAMPMSS option in
    /etc/shorewall/shorewall.conf by allowing that option to have a
    numeric value as well as the values "Yes" and "No".

    Example:

	CLAMPMSS=1400 

23) Shorewall now includes support for the ipp2p match facility. This
    is a departure from my usual policy in that the ipp2p match
    facility is included in Patch-O-Matic-NG and is unlikely to ever be
    included in the kernel.org source tree. Questions about how to
    install the patch or how to build your kernel and/or iptables
    should not be posted on the Shorewall mailing lists.

    In the following files, the "PROTO" or "PROTOCOL" column may
    contain "ipp2p":

       /etc/shorewall/rules
       /etc/shorewall/tcrules
       /etc/shorewall/accounting

    When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
    PORT(S) or PORT(S) column may contain a recognized ipp2p option;
    for a list of the options and their meaning, at a root prompt:

	iptables -m ipp2p --help

    You must not include the leading "--" on the option; Shorewall will
    supply those characters for you. If you do not include an option
    then "ipp2p" is assumed (Shorewall will generate "-m ipp2p
    --ipp2p").

24) Shorewall now has support for the CONNMARK target from iptables.
    See the /etc/shorewall/tcrules file for details.
    
25) A new debugging option LOGALLNEW has been added to
    shorewall.conf. When set to a log level, this option causes
    Shorewall to generaate 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.

    Example: Using the default LOGFORMAT, the log prefix for logging
    from the nat table's PREROUTING chain is:

	 Shorewall:nat:PREROUTING

    IMPORTANT: There is no rate limiting on these logging rules so
    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.

    DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL
    BE SENT TO ANOTHER SYSTEM.

26) The SUBNET column in /etc/shorewall/rfc1918 has been renamed
    SUBNETS and it is now possible to specify a list of addresses in
    that column.

27) The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).

28) For consistency, the CLIENT PORT(S) column in the tcrules file has
    been renamed SOURCE PORT(S).

29) The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown
    in the output of "shorewall status".

30) A new IPTABLES option has been added to shorewall.conf. IPTABLES
    can be used to designate the iptables executable to be used by
    Shorewall. If not specified, the iptables executable determined by
    the PATH setting is used.

31) You can now use the "shorewall show zones" command to display the
    current contents of the zones. This is particularly useful if you
    use dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).

    Example:

	ursa:/etc/shorewall # shorewall show zones
	Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004
 
	loc
	   eth0:192.168.1.0/24
	   eth1:1.2.3.4
	net	   
	   eth0:0.0.0.0/0
	WiFi
	   eth1:0.0.0.0/0
	sec
	   eth1:0.0.0.0/0
 
	ursa:/etc/shorewall #

32) Variable expansion may now be used with the INCLUDE directive.

    Example:

	/etc/shorewall/params

	    FILE=/etc/foo/bar

        Any other config file:

	    INCLUDE $FILE

33) The output of "shorewall status" now includes the results of "ip
    -stat link ls". This helps diagnose performance problems caused by
    link errors.

34) Previously, when rate-limiting was specified in
    /etc/shorewall/policy (LIMIT:BURST column), any traffic which
    exceeded the specified rate was silently dropped. Now, if a log
    level is given in the entry (LEVEL column) then drops are logged at
    that level at a rate of 5/min with a burst of 5.

35) Recent 2.6 kernels include code that evaluates TCP packets based on
    TCP Window analysis. This can cause packets that were previously
    classified as NEW or ESTABLISHED to be classified as INVALID.

    The new kernel code can be disabled by including this command in
    your /etc/shorewall/init file:

    echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

    Additional kernel logging about INVALID TCP packets may be
    obtained by adding this command to /etc/shorewall/init:

    echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

    Traditionally, Shorewall has dropped INVALID TCP packets early. The
    new DROPINVALID option allows INVALID packets to be passed through
    the normal rules chains by setting DROPINVALID=No.

    If not specified or if specified as empty (e.g., DROPINVALID="")
    then DROPINVALID=Yes is assumed.

36) The "shorewall add" and "shorewall delete" commands now accept a
    list of hosts to add or delete.

    Examples:

    shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12
    shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12