releasenotes.txt

sharewall is very good

Shorewall 4.2.7

----------------------------------------------------------------------------
               R E L E A S E  4 . 2  H I G H L I G H T S
----------------------------------------------------------------------------
1) Support is included for multiple internet providers through the same
   ethernet interface.

2) Support for NFLOG has been added.

3) Enhanced operational logging.

4) The tarball installers now work under Cygwin.

5) Shorewall-perl now supports IFB devices which allow traffic shaping of
   incoming traffic.

6) Shorewall-perl supports definition of u32 traffic classification
   filters.

7) Support for IPv6 is available beginning with Shorewall 4.2.4.

   Minimun system requirements for IPv6 support:

   - Kernel 2.6.25 or later.
   - iptables 1.4.0 or later with 1.4.1 or later strongly recommended.
   - Perl 5.10 if you wish to use DNS names in your IPv6 config files. 
     In that case you will also have to install Perl Socket6 support.

Problems corrected in 4.2.7

1)  Previously, the 'start' command set the permission flags on
    /var/lib/shorewall*/state so that it could be read by
    non-root users while the 'stop' command set the permissions such
    that the file could not be read by those users.

    Beginning with 4.2.7, both commands will secure the file for
    root-only access. If you want the file to be world-readable, then
    add 

    	chmod 744 <file name>

    To your /etc/shorewall/started, /etc/shorewall/stopped and
    /etc/shorewall/restored files.

2)  The 'shorewall6 dump' command now correctly displays the installed
    version of Shorewall-perl. It also displays the IPv6 neighbor table
    contents rather than the ARP table contents.

3)  Under some circumstances, interface options like nosmurfs and
    tcpflags would not be applied to forwarded traffic when using
    Shorewall-perl.

4)  The following rule was badly mis-handled:

       DNAT-	loc	net:1.2.3.4:2525	tcp	25

    The result:

     WARNING: Destination zone (1.2.3.4) ignored : /etc/shorewall/rules (line 459)
     Can't call method "inet_htoa" without a package or object reference at
       /usr/share/shorewall-perl/Shorewall/IPAddrs.pm line 150,
      <$currentfile> line 459.

5)  Previously, OPTIONS were not allowed with a bridge port in
    /etc/shorewall/interfaces. That oversight has been corrected and
    now the following OPTIONS are allowed:

    	blacklist
	maclist
	norfc1918
	nosmurfs
	routeback
	tcpflags

6)  Tuomo Soini provided a workaround patch for a problem seen in some
    kernel's (see FAQ 82) that caused 'shorewall start' to fail when
    USE_DEFAULT_RT=Yes .

Known Problems Remaining:

1)  When exclusion is used in an entry in /etc/shorewall/hosts, then
    Shorewall-shell produces an invalid iptables rule if any of the 
    following OPTIONS are also specified in the entry:    

        blacklist
	maclist
	norfc1918
	tcpflags

New Features in Shorewall 4.2.7

1)  Prior to Shorewall version 3.0.0, rules generated by
    /etc/shorewall/tunnels were traversed before those generated by
    /etc/shorewall/rules. When SECTIONs were added to the rules file in
    3.0.0, traversal of the tunnel rules was deferred until after those
    generated by the NEW section of the rules file. 

    Beginning with Shorewall-perl 4.2.7, the tunnel rules are back
    where they started -- right before the first rule generated by the
    NEW section of /etc/shorewall/rules.

2)  To allow bypassing of connection tracking for certain traffic,
    /etc/shorewall/notrack and /etc/shorewall6/notrack files have been
    added.

    Columns in the file are:

        SOURCE - <zone>[:<interface>][:<address list>]

    	DEST - [<address list>]

    	PROTO - <protocol name or number>

    	DEST PORT(S) - <port number list>

    	SOURCE PORT(S) - <port number list>

    	USER/GROUP - [<user>][:<group>]

            May only be specified if the SOURCE <zone> is $FW.

    Traffic that matches all given criteria will not be subject to
    connection tracking. For such traffic, your policies and/or rules
    must deal with ALL of the packets involved, in both the original
    and the opposite directions. All untracked traffic is passed
    through the relevant rules in the NEW section of the rules
    file. Untracked encapsulated tunnel traffic can be handled by
    entries in /etc/shorewall/tunnels just like tracked traffic
    is. Because every packet of an untracked connection must pass
    through the NEW section rules, it is suggested that rules that deal
    with untracked traffic should appear at the top of the file.

    Example:

    /etc/shorewall/tunnels:

	#TYPE	ZONE	GATEWAY
	6to4	net

    /etc/shorewall/notrack

	#SOURCE		 DEST		PROTO	DEST	SOURCE	USER/
	#               			PORT(S)	PORT(S)	GROUP
	net:!192.88.99.1 -		41

    Given that 192.88.99.1 is an anycast address, many hosts can
    respond to outward traffic to that address. The entry in
    /etc/shorewall/tunnels allows protocol 41 net<->fw. The entry in
    /etc/shorewall/notrack prevents the inbound traffic from creating
    additional useless conntrack entries.

    As part of this change, the 'show' command is enhanced to support a 
    'show raw' command that is an alias for 'show -t raw'. The raw
    table is where NOTRACK rules are created. The dump command is also
    enhanced to display the contents of the raw table.

3)  Shorewall-perl supports three additional columns in the
    /etc/shorewall/routestopped file:

    PROTO          -- Protocol name or number

    DEST PORT(S)   -- comma-separated list of service names and/or port
                      numbers
 
    SOURCE PORT(S) -- comma-separated list of service names and/or port
                      numbers.

    These columns are only meaningful when the "-f" option to
    'shorewall stop' is used.

    As part of this change, the "-f" option to the 'stop' and 'clear'
    commands is now the default when FAST_STOP=Yes in shorewall.conf.
    To override this default, use the "-s" option:

	shorewall stop -s

    Note that if you have entries with one or more of the new columns,
    the -s option will result in warning messages.

    	gateway:~ # shorewall stop -s
	Stopping Shorewall...
   	  WARNING: Unknown routestopped option ignored: notrack
   	  WARNING: Unknown routestopped option ignored: 41
   	  WARNING: Unknown routestopped option ignored: notrack
   	  WARNING: Unknown routestopped option ignored: 41
	done.
	gateway:~ #

4)  Shorewall-perl now handles SOURCE PORT lists of more than 15
    entries by breaking the containing rule into multiple rules.

Migration Issues.

1)  Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
    mark values < 256 to be assigned in the OUTPUT chain. This has been
    changed so that only high mark values may be assigned
    there. Packet marking rules for traffic shaping of packets
    originating on the firewall must be coded in the POSTROUTING table.

2)  Previously, Shorewall did not range-check the value of the
    VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2:

    a) A VERBOSITY setting outside the range -1 through 2 is rejected.
    b) After the -v and -q options are applied, the resulting value is
       adjusted to fall within the range -1 through 2.

3)  Specifying a destination zone in a NAT-only rule now generates a
    warning and the destination zone is ignored. NAT-only rules are:

             NONAT
             REDIRECT-
             DNAT-

4)  The default value for LOG_MARTIANS has been changed. Previously,
    the defaults were:

        Shorewall-perl - 'Off'
        Shorewall-shell - 'No'

    The new default values are:

        Shorewall-perl - 'On'
        Shorewall-shell - 'Yes'.

    Shorewall-perl users may:

    a) Accept the new default -- martians will be logged from all
       interfaces with route filtering except those with log_martians=0
       in /etc/shorewall/interfaces.

    b) Explicitly set LOG_MARTIANS=Off to maintain compatibility with
       prior versions of Shorewall.

    Shorewall-shell users may:

    a) Accept the new default -- martians will be logged from all
       interfaces with the route filtering enabled.

    b) Explicitly set LOG_MARTIONS=No to maintain compatibility with 
       prior versions of Shorewall.

5)  The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has
    been changed from Yes to No.

6)  The 'norfc1918' option is deprecated. Use explicit rules instead.
    Note that there is a new 'Rfc1918' macro that acts on addresses
    reserved by RFC 1918.

7)  DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use
    ipset-based zones instead.

New Features in Shorewall 4.2

1)  Shorewall 4.2 contains support for multiple Internet providers
    through a single ethernet interface. Configuring two providers
    through a single interface differs from two providers through two
    interfaces in several ways.

    a) Only ethernet (or ethernet-like) interfaces can be used. For
       inbound traffic, the MAC addresses of the gateway routers is used
       to determine which provider a packet was received through. Note
       that only routed traffic can be categorized using this technique.

    b) You must specify the address on the interface that corresponds to
       a particular provider in the INTERFACE column by following the
       interface name with a colon (":") and the address.
 
    c) Entries in /etc/shorewall/masq must be qualified by the provider
       name (or number).

    d) This feature requires Realm Match support in your kernel and
       iptables. If you use a capabilities file, you need to regenerate
       the file with Shorewall 4.2 or Shorewall-lite 4.2.
 
    e) You must add route_rules entries for networks that are accessed
       through a particular provider.

    f) If you have additional IP addresses through either provider,
       you must add route_rules to direct traffic FROM each of those
       addresses through the appropriate provider.

    g) You must add MARK rules for any traffic that you know originates
       from a particular provider.

     Example:

     Providers Blarg (1) and Avvanta (2) are both connected to
     eth0. The firewall's IP address with Blarg is 206.124.146.176/24
     (gateway 206.124.146.254) and the IP address from Avvanta is
     130.252.144.8/24 (gateway 130.252.144.254). We have a second IP
     address (206.124.146.177) from Blarg.

     /etc/shorewall/providers:

       #PROVIDER   NUMBER  MARK    DUPLICATE INTERFACE            GATEWAY
       Blarg       1       1       main      eth0:206.124.146.176 206.124.146.254 ...
       Avvanta     2       2       main      eth0:130.252.144.8   130.252.144.254 ...

     /etc/shorewall/masq:

       #INTERFACE          SOURCE          ADDRESS
       eth0(Blarg)         130.252.144.8   206.124.146.176
       eth0(Avvanta)       206.124.146.176 130.252.144.8
       eth0(Blarg)         eth1            206.124.146.176
       eth0(Avvanta)       eth1            130.252.144.8

     /etc/shorewall/route_rules:

        #SOURCE            DEST                    PROVIDER        PRIORITY
        -                  206.124.146.0/24        Blarg           1000
        -                  130.252.144.0/24        Avvanta         1000
        206.124.146.177    -                       Blarg           26000

     /etc/shorewall/tcrules

        #MARK/CLASSIFY  SOURCE                       DEST
        1                eth0:206.124.146.0/24  0.0.0.0/0
        2                eth0:130.242.144.0/24  0.0.0.0/0

2)  You may now include the name of a table (nat, mangle or filter) in
    a 'shorewall refresh' command by following the table name with a
    colon (e.g., mangle:). This causes all non-builtin chains in the