shorewall_code/Shorewall2/releasenotes.txt

Shorewall 2.1.5

----------------------------------------------------------------------
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.

-----------------------------------------------------------------------
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

-----------------------------------------------------------------------
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, specifying 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 invoke '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
    a /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 from Patch-0-Matic-ng. That 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 column specifies 

    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.

	 proto=ah|esp|ipcomp 

	 mode=transport|tunnel

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

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

    Examples:

	#ZONE	IPSEC	OPTIONS
	#	ONLY
	vpn	Yes	mode=tunnel,proto=esp
	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.

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