shorewall_code/Shorewall2/releasenotes.txt

Shorewall 2.4.0-RC1

-----------------------------------------------------------------------
Problems Corrected since 2.3.2

1) The /etc/shorewall/providers file is now installed correctly.

2) "shorewall restart" now works correctly when multiple providers 
   with load-balancing were specified when Shorewall was originally 
   started.

3) Routes created by entries in /etc/shorewall/proxyarp are now
   copied to new routing tables created by entries in
   /etc/shorewall/providers.

4) Where multiple internet providers were configured, traffic from the
   firewall itself was mishandled.

-----------------------------------------------------------------------
Upgrade Issues when moving to 2.4.0

1) Shorewall now enforces the restriction that mark values used in 
   /etc/shorewall/tcrules are less than 256. If you are using mark
   values >= 256, you must change your configuration before you 
   upgrade.
-----------------------------------------------------------------------
New Features in version 2.4.0

1) Shorewall 2.4.0 includes support for multiple internet interfaces to
   different ISPs. 

   The file /etc/shorewall/providers may be used to define the
   different providers. It can actually be used to define alternate
   routing tables so uses like transparent proxy can use the file as
   well.

   Columns are:

       NAME            The provider name.

       NUMBER          The provider number -- a number between 1 and 15

       MARK            A FWMARK value used in your
		       /etc/shorewall/tcrules file to direct packets to
		       this provider.

       DUPLICATE       The name of an existing table to duplicate. May
		       be 'main' or the name of a previous provider.

       INTERFACE       The name of the network interface to the
		       provider. Must be listed in
		       /etc/shorewall/interfaces.

       GATEWAY         The IP address of the provider's gateway router.

       OPTIONS         A comma-separated list selected from the
		       following:

               track   If specified, connections FROM this interface are
                       to be tracked so that responses may be routed
                       back out this same interface.

                       You want specify 'track' if internet hosts will be
                       connecting to local servers through this
                       provider.

		       Because of limitations in the 'ip' utility and
		       policy routing, you may not use the SAVE or
		       RESTORE tcrules options or use connection
		       marking on any traffic to or from this
		       interface. For traffic control purposes, you
		       must mark packets in the FORWARD chain (or
		       better yet, use the CLASSIFY target).

               balance The providers that have 'balance' specified will
                       get outbound traffic load-balanced among them.

       Example:  You run squid in your DMZ on IP address
		 192.168.2.99. Your DMZ interface is eth2

       #NAME   NUMBER  MARK DUPLICATE  INTERFACE GATEWAY       OPTIONS
       Squid   1       1    -          eth2      192.168.2.99  -

   Use of this feature requires that your kernel and iptables 
   support CONNMARK target and conntrack match support. It does NOT
   require the ROUTE target extension.

   WARNING: The current version of iptables (1.3.1) is broken with
   respect to CONNMARK and iptables-save/iptables-restore. This means
   that if you configure multiple ISPs, "shorewall restore" will
   fail. You must patch your iptables using the patch at
   http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff.

2) Shorewall 2.3.0 supports the 'cmd-owner' option of the owner match
   facility in Netfilter. Like all owner match options, 'cmd-owner' may
   only be applied to traffic that originates on the firewall.

   The syntax of the USER/GROUP column in the following files has been
   extended:

	/etc/shorewall/accounting
	/etc/shorewall/rules
	/etc/shorewall/tcrules
	/usr/share/shorewall/action.template

   To specify a command, prefix the command name with "+".

   Examples:

	+mozilla-bin		#The program is named "mozilla-bin"
	joe+mozilla-bin		#The program is named "mozilla-bin" and
				#is being run by user "joe"
	joe:users+mozilla-bin	#The program is named "mozilla-bin" and
				#is being run by user "joe" with 
				#effective group "users".

   Note that this is not a particularly robust feature and I would
   never advertise it as a "Personal Firewall" equivalent. Using
   symbolic links, it's easy to alias command names to be anything you
   want.

3) Support has been added for ipsets
   (see http://people.netfilter.org/kadlec/ipset/).

   In most places where a host or network address may be used, you may
   also use the name of an ipset prefaced by "+". 

	Example: "+Mirrors"

   The name of the set may be optionally followed by: 
   
   a) a number from 1 to 6 enclosed in square brackets ([]) -- this
   number indicates the maximum number of ipset binding levels that 
   are to be matched. Depending on the context where the ipset name 
   is used, either all "src" or all "dst" matches will be used.
   
	Example: "+Mirrors[4]"

   b) a series of "src" and "dst" options separated by commas and
   inclosed in square brackets ([]). These will be passed directly
   to iptables in the generated --set clause. See the ipset
   documentation for details. 

	Example: "+Mirrors[src,dst,src]"
   
   Note that "+Mirrors[4]" used in the SOURCE column of the rules 
   file is equivalent to "+Mirrors[src,src,src,src]".

   To generate a negative match, prefix the "+" with "!" as in
   "!+Mirrors".

   Example 1: Blacklist all hosts in an ipset named "blacklist"

	   /etc/shorewall/blacklist

	   #ADDRESS/SUBNET         PROTOCOL        PORT
	   +blacklist

   Example 2: Allow SSH from all hosts in an ipset named "sshok:

	   /etc/shorewall/rules

	   #ACTION      SOURCE      DEST     PROTO    DEST PORT(S)
           ACCEPT	+sshok      fw	     tcp      22

   Shorewall can automatically capture the contents of your ipsets for
   you. If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf
   then "shorewall save" will save the contents of your ipsets. The file
   where the sets are saved is formed by taking the name where the
   Shorewall configuration is stored and appending "-ipsets". So if you
   enter the command "shorewall save standard" then your Shorewall
   configuration will be saved in /var/lib/shorewall/standard and your
   ipset contents will be saved in /var/lib/shorewall/standard-ipsets.
   Assuming the default RESTOREFILE setting, if you just enter
   "shorewall save" then your Shorewall configuration will be saved in
   /var/lib/shorewall/restore and your ipset contents will be saved in
   /var/lib/shorewall/restore-ipsets.

   Regardless of the setting of SAVE_IPSETS, the "shorewall -f start"
   and "shorewall restore" commands will restore the ipset contents
   corresponding to the Shorewall configuration restored provided that
   the saved Shorewall configuration specified exists.

   For example, "shorewall restore standard" would restore the ipset
   contents from /var/lib/shorewall/standard-ipsets provided that
   /var/lib/shorewall/standard exists and is executable and that
   /var/lib/shorewall/standard-ipsets exists and is executable.

   Also regardless of the setting of SAVE_IPSETS, the "shorewall forget"
   command will purge the saved ipset information (if any) associated
   with the saved shorewall configuration being removed.

   You can also associate ipset contents with Shorewall configuration
   directories using the following command:

       ipset -S > <config directory>/ipsets

   Example:

       ipset -S > /etc/shorewall/ipsets

   When you start or restart Shorewall (including using the 'try'
   command) from the configuration directory, your ipsets will be
   configured from the saved ipsets file. Once again, this behavior is
   independent of the setting of SAVE_IPSETS.

   Ipsets are well suited for large blacklists. You can maintain your
   blacklist using the 'ipset' utility without ever having to restart
   or refresh Shorewall. If you use the SAVE_IPSETS=Yes feature just be
   sure to "shorewall save" after altering the blacklist ipset(s). 

   Example /etc/shorewall/blacklist:

   #ADDRESS/SUBNET         PROTOCOL        PORT
   +Blacklist[src,dst]
   +Blacklistnets[src,dst]

   Create the blacklist ipsets using:

	  ipset -N Blacklist iphash
	  ipset -N Blacklistnets nethash

   Add entries

       ipset -A Blacklist 206.124.146.177
       ipset -A Blacklistnets 206.124.146.0/24

   To allow entries for individual ports

       ipset -N SMTP portmap --from 1 --to 31
       ipset -A SMTP 25

       ipset -A Blacklist 206.124.146.177
       ipset -B Blacklist 206.124.146.177 -b SMTP

   Now only port 25 will be blocked from 206.124.146.177. 

4) Shorewall 2.4.0 can now configure routing if your kernel and
   iptables support the ROUTE target extension. This extension is
   available in Patch-O-Matic-ng. This feature is *EXPERIMENTAL* since
   the Netfilter team have no intention of ever releasing the ROUTE
   target extension to kernel.org.

   Routing is configured using the /etc/shorewall/routes file. Columns
   in the file are as follows:

      SOURCE 		Source of the packet. May be any of the
			following:


			- A host or network address
			- A network interface name.
			- The name of an ipset prefaced with "+"
			- $FW (for packets originating on the firewall)
			- A MAC address in Shorewall format
			- A range of IP addresses (assuming that your
			  kernel and iptables support range match)
			- A network interface name followed by ":"
			  and an address or address range.

	DEST		Destination of the packet. May be any of the
			following:

			- A host or network address
			- A network interface name (determined from
			  routing table(s))
			- The name of an ipset prefaced with "+"
			- A network interface name followed by ":"
			  and an address or address range. 

	PROTO		Protocol - Must be "tcp", "udp", "icmp",
			"ipp2p", a number, or "all". "ipp2p" requires
			ipp2p match support in your kernel and
			iptables.

	PORT(S)		Destination Ports. A comma-separated list of
			Port names (from /etc/services), port numbers
			or port ranges; if the protocol is "icmp", this
			column is interpreted as the destination
			icmp-type(s).

			If the protocol is ipp2p, this column is
			interpreted as an ipp2p option without the
			leading "--" (example "bit" for bit-torrent).
			If no PORT is given, "ipp2p" is assumed.

			This column is ignored if PROTOCOL = all but
			must be entered if any of the following field
			is supplied. In that case, it is suggested that
			this field contain "-"

	SOURCE PORT(S)	(Optional) Source port(s). If omitted,
			any source port is acceptable. Specified as a
			comma-separated list of port names, port
			numbers or port ranges.

	TEST		Defines a test on the existing packet or
			connection mark. 

			The rule will match only if the test returns
			true. Tests have the format
			[!]<value>[/<mask>][:C]

			Where:

				!	Inverts the test (not equal)
				<value> Value of the packet or
					connection mark.

				<mask>  A mask to be applied to the
					mark before testing 
				:C	Designates a connection
					mark. If omitted, the packet
					mark's value is tested.

	INTERFACE	The interface that the packet is to be routed
			out of. If you do not specify this field then
			you must place "-" in this column and enter an
			IP address in the GATEWAY column.

	GATEWAY		The gateway that the packet is to be forewarded
			through.

5) Crossbeam Support (Thanks to Juan Jesús Prieto and the folks at
   eneotecnologia.com)

   If Shorewall is running in a Crossbeam System
   (www.crossbeamsystems.com) you need to activate this directive if
   you don't want the CPM to think the system is down and send a reset
   signal. Also Crossbeam has a backplane chassis that needs to be
   configured in such a way that it accepts all traffic.

   This change adds two new options in /etc/shorewall/shorewall.conf:
   CROSSBEAM and CROSSBEAM_BACKBONE.

   If CROSSBEAM=Yes, then during a Shorewall start, restart or clear
   instead of setting the default policies to DROP and then activating
   established connections, Shorewall will first set the default
   policies to ACCEPT, activate established connections and then set
   the default policies to DROP. After that, Shorewall starts
   generating the rules as usual.

   If CROSSBEAM=No, CROSSBEAM_BACKBONE is not used. If CROSSBEAM is set
   to Yes, CROSSBEAM_BACKBONE indicates the device used by the
   backbone. If not specified or if specified as empty (e.g.,
   CROSSBEAM="") then CROSSBEAM=No is assumed.

6) Normally when Shorewall is stopped, starting or restarting then 
   connections are allowed from hosts listed in
   /etc/shorewall/routestopped to the firewall and to other hosts
   listed in /etc/shorewall/routestopped. 

   A new 'source' option is added for entries in that file which will
   cause Shorewall to allow traffic from the host listed in the entry
   to ANY other host. When 'source' is specified in an entry, it is
   unnecessary to also specify 'routeback'.

   Similarly, a new 'dest' option is added which will cause Shorewall
   to allow traffic to the host listed in the entry from ANY other
   host. When 'source' is specified in an entry, it is unnecessary to
   also specify 'routeback'.