Shorewall 3.2.3 	 
	  	 
 Note to users upgrading from Shorewall 2.x or 3.0 	 
  	 
    Most problems associated with upgrades come from two causes: 	 
	  	 
    - The user didn't read and follow the migration considerations in these 	 
      release notes. 	 
	  	 
    - The user mis-handled the /etc/shorewall/shorewall.conf file during 	 
      upgrade. Shorewall is designed to allow the default behavior of 	 
      the product to evolve over time. To make this possible, the design 	 
      assumes that you will not replace your current shorewall.conf file 	 
      during upgrades. If you feel absolutely compelled to have the latest 	 
      comments and options in your shorewall.conf then you must proceed 	 
      carefully. 	 
	  	 
    While you are at it, if you have a file named /etc/shorewall/rfc1918 then 	 
    please check that file. If it has addresses listed that are NOT in one of 	 
    these three ranges, then please rename the file to 	 
    /etc/shorewall/rfc1918.old. 	 
  	 
         10.0.0.0 - 10.255.255.255 	 
         172.16.0.0 - 172.31.255.255 	 
         192.168.0.0 - 192.168.255.255 	 
  	 
    If you have a file named /etc/shorewall/modules, please remove 	 
    it. The default modules file is now located in /usr/share/shorewall/ 	 
    (see the "Migration Considerations" below). 	 
  	 
    Please see the "Migration Considerations" below for additional upgrade 	 
    information. 	 
  	 
 Problems Corrected in 3.2.3 	 
  	 
 1)  A problem in 'install.sh' resulted in sandbox violations on 	 
     Gentoo and, when Shorewall is installed using an RPM, the problem 	 
     caused an incorrect copy of shorewall.conf to be installed in 	 
     /usr/share/shorewall/configfiles/. 	 
  	 
 2)  A typo in the functions file caused startup errors when the user's 	 
     distribution did not support a true mktemp program (such as 	 
     Bering Uclibc). Patch courtesy of Cédric Schieli. 	 
  	 
 3)  Several erroneous references to ip_addr_del() were made in 	 
     /var/lib/shorewall/compiler and in the code that it generates. 	 
  	 
     a) These should have been references to del_ip_addr() 	 
     b) One of the calls also had an incorrect parameter list. 	 
	  	 
 4)  Previously, "shorewall check -e" would erroneously attempt to 	 
     detect interfaces configured for traffic shaping. 	 
  	 
 5)  SUBSYSLOCK functionality has been restored. 	 
  	 
 6)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not 	 
     affect traffic to/from the firewall zone. That has been corrected. 	 
	  	 
 7)  When /sbin/shorewall was run under BusyBox ash, shell errors would 	 
     occur if certain command options were given. 	 
	  	 
 8)  Previously, the 'optional' provider option did not detect the case 	 
     where the interface was DOWN but still had a configured IP 	 
     address. Shorewall was detecting such interfaces as UP and later 	 
     'ip replace route' commands would fail. 	 
  	 
     It should also be clarified that the 'optional' option is intended 	 
     to detect cases where a provider interface is in a state that would 	 
     cause 'shorewall [re]start' to fail; it is not intended to 	 
     determine whether communication is possible using the interface. 	 
  	 
 9)  Previously, the "shorewall add" command would fail with error 	 
     messages indicating that the commands "chain_exists" and 	 
     "verify_hosts_file" could not be found. 	 
  	 
 10) Using earlier Shorewall versions, the following sequence of 	 
     commands produced inconsistant results: 	 
  	 
     a) shorewall [re] start 	 
     b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses 	 
     c) shorewall refresh 	 
     d) shorewall save 	 
     e) shorewall restore (or reboot and shorewall start -f during boot 	 
        up) 	 
	  	 
     After that series of commands, the state of traffic shaping was as 	 
     it was after step a) rather than as it was after step c). The fix 	 
     involved re-implementing 'shorewall refresh' as a compile/execute 	 
     procedure similar to [re]start. While the entire configuration is 	 
     recompiled, only ecn, blacklisting, tcrules and traffic control 	 
     will be updated in the running configuration. 	 
  	 
 11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been 	 
     incorrect with the result that the rules didn't work at all. 	 
	  	 
 Other changes in 3.2.3 	 
	  	 
 1)  A 'shorewall export' command has been added. 	 
  	 
     shorewall export [ <directory1> ] [user@]<system>:[<directory2>] 	 
  	 
     If <directory1> is omitted, then the current working directory is 	 
     assumed. 	 
  	 
     Causes the shorewall configuration in <directory1> to be compiled 	 
     into a program called '<directory1>/firewall'. If compilation is 	 
     successful, the '<directory1>/firewall' script is copied via scp 	 
     to the specified <system>. 	 
  	 
     Example: 	 
  	 
         shorewall export admin@gateway: 	 
  	 
     This command would compile the configuration in the current working 	 
     directory then copy the 'firewall' (and 'firewall.conf') files to 	 
     admin's home directory on system 'gateway'. 	 
  	 
 2)  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 really know what you are doing and understand packet marking 	 
     thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and 	 
     Shorewall will not include these cautionary checks. 	 
  	 
 3)  Previously, CLASSIFY tcrules were always processed out of the 	 
     POSTROUTING chain. Beginning with this release, they are processed 	 
     out of the POSTROUTING chain *except* when the SOURCE is 	 
     $FW[:<address>] in which case the rule is processed out of the 	 
     OUTPUT chain. 	 
  	 
     See the Migration Considerations section for further information. 	 
	  	 
 4)  Previously, if you specified 'detectnets' on an interface with a 	 
     default route, Shorewall would ignore the default route with a 	 
     warning message. This could lead to systems that were inaccessible 	 
     from the net, even from systems listed in the 'routestopped' file. 	 
  	 
     Specifying 'detectnets' on an interface with a default route now 	 
     generates a fatal error. 	 
  	 
 Migration Considerations: 	 
  	 
 1)  If you are upgrading from Shorewall 2.x, it is essential that you read 	 
     the Shorewall 3.0.8 (or later) release notes: 	 
  	 
     http://www.shorewall.net/pub/shorewall/3.0/shorewall-3.0.8/releasenotes.txt 	 
  	 
 2)  A number of macros have been split into two.  The macros affected are: 	 
  	 
         IMAP LDAP NNTP POP3 SMTP 	 
  	 
     Each of these macros now handles only traffic on the native (plaintext) 	 
     port.  There is a corresponding macro with S added to the end of the 	 
     name for the SSL version of the same protocol.  Thus each macro results 	 
     in the insertion of only one port per invocation. 	 
  	 
     The Web macro has not been split, but two new macros, HTTP and HTTPS have 	 
     been created.  The Web macro is deprecated in favour of these new macros, 	 
     and may be removed from future Shorewall releases. 	 
  	 
     These changes have been made to ensure no unexpected ports are opened due 	 
     to the use of macros. 	 
  	 
 3)  In previous Shorewall releases, DNAT and REDIRECT rules supported a 	 
     special syntax for exclusion of a sub-zone from the effect of the rule. 	 
  	 
     Example: 	 
  	 
         Z2 is a subzone of Z1: 	 
  	 
         DNAT     Z1!Z2        loc:192.168.1.4        ... 	 
  	 
     That feature has never worked correctly when Z2 is a dynamic zone. 	 
     Furthermore, now that Shorewall supports exclusion lists, the capability 	 
     is redundant since the above rule can now be written in the form: 	 
  	 
         DNAT     Z1:!<list of exclusions>   loc:192.168.1.4   ... 	 
  	 
     Beginning with Shorewall 3.2.0, the special exclusion syntax will no 	 
     longer be supported. 	 
  	 
 4)  Important if you use the QUEUE target. 	 
  	 
     In the /etc/shorewall/rules file and in actions, you may now specify 	 
     'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also 	 
     requires that the SYN flag is set and the RST, FIN and ACK flags be 	 
     off ("--syn" is added to the iptables rule). 	 
  	 
     As part of this change, Shorewall no longer adds the "--syn" option 	 
     to TCP rules that specify QUEUE as their target. 	 
  	 
 5)  Extension Scripts may require change 	 
  	 
     In previous releases, extension scripts were executed during [re]start 	 
     by using the Bourne Shell "." operator. In addition to executing commands 	 
     during [re]start, these scripts had to "save" the commands to be executed 	 
     during "shorewall restore". 	 
  	 
     This clumsiness has been eliminated in Shorewall 3.2. In Shorewall 3.2, 	 
     extension scripts are copied in-line into the compiled program and are 	 
     executed in-line during "start", "restart" and "restore". This 	 
     applies to all extension scripts except those associated with a 	 
     chain or action -- those extension scripts continue to be processed 	 
     at compile time. 	 
  	 
     This new approach has two implications for existing scripts. 	 
  	 
     a)  It is no longer necessary to save the commands; so functions like 	 
         'save_command', 'run_and_save_command' and 'ensure_and_save_command' 	 
         need no longer be called. For convenience, the generated program will 	 
         supply functions with these names: 	 
  	 
             save_command() - does nothing 	 
             run_and_save_command() - runs the passed command 	 
             ensure_and_save_command() - runs the passed command and 	 
                                         stops/restores the firewall if the 	 
                                         command fails. 	 
  	 
         These functions should provide for transparent migration of 	 
         scripts that use them until you can get around to eliminating 	 
         their use completely. 	 
  	 
     b)  When the extension script is copied into the compiled program, it 	 
         is indented to line up with the surrounding code. If you have 'awk' 	 
         installed on your system, the Shorewall compiler will correctly handle 	 
         line continuation (last character on the line = "\"). If you do not 	 
         have awk, it will not be possible to use line-continuation in your 	 
         extension scripts. 	 
  	 
         In no case is it possible to continue a quoted string over multiple lines 	 
         without having additional whitespace inserted into the string. 	 
  	 
 6)  Beginning with this release, the way in which packet marking in the 	 
     PREROUTING chain interracts with the 'track' option in /etc/shorewall/providers 	 
     has changed in two ways: 	 
  	 
     a)  Packets arriving on a tracked interface are now passed to the PREROUTING 	 
         marking chain so that they may be marked with a mark other than the 	 
         'track' mark (the connection still retains the 'track' mark). 	 
  	 
     b)  When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets 	 
         in the PREROUTING chain (i.e., you can specify a mark value of zero). 	 
  	 
 7)  Kernel version 2.6.16 introduces 'xtables', a new common packet 	 
     filtering and connection tracking facility that supports both IPv4 	 
     and IPv6. Because a different set of kernel modules must be loaded 	 
     for xtables, Shorewall now includes two 'modules' files: 	 
  	 
     a) /usr/share/shorewall/modules -- the former 	 
     /etc/shorewall/modules 	 
  	 
     b) /usr/share/shorewall/xmodules -- a new file that support 	 
     xtables. 	 
  	 
     If you wish to use the new file, then simply execute this command: 	 
  	 
     cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules 	 
  	 
 8)  Previously, CLASSIFY tcrules were always processed out of the 	 
     POSTROUTING chain. Beginning with this release, they are processed 	 
     out of the POSTROUTING chain *except* when the SOURCE is 	 
     $FW[:<address>] in which case the rule is processed out of the 	 
     OUTPUT chain. 	 
  	 
     With correctly-coded rulesets, this change should have no 	 
     effect. Users having incorrectly-coded tcrules may need to change 	 
     them. 	 
  	 
     Example: 	 
  	 
         #MARK/          SOURCE  DEST    PROTO   DEST            SOURCE 	 
         #CLASSIFY                               PORTS(S)        PORT(S) 	 
         1:110           $FW     eth3    tcp     -               22 	 
  	 
     While the user may have expected this rule to only affect traffic 	 
     from the firewall itself, the rule was really equivalent to this one: 	 
  	 
         #MARK/    SOURCE        DEST    PROTO   DEST            SOURCE 	 
         #CLASSIFY                               PORTS(S)        PORT(S) 	 
         1:110     0.0.0.0/0     eth3    tcp     -               22 	 
  	 
     So after this change, the second rule will be required rather than 	 
     the first if that is what was really wanted. 	 
  	 
 New Features: 	 
  	 
 1)  Shorewall has always been very noisy (lots of messages). No longer. 	 
  	 
     You set the default level of verbosity using the VERBOSITY option in 	 
     shorewall.conf. If you don't set it (as would be the case if you use your 	 
     old shorewall.conf file) then VERBOSITY defaults to a value of 2 which 	 
	     results in behavior compatible with previous Shorewall versions. 	 
     A value of 1 suppresses some of the output (like the old -q option did) 	 
     while a value of 0 makes Shorewall almost silent. A value of -1 	 
     suppresses all output except warning and error messages. 	 
  	 
     The value specified in the 3.2 shorewall.conf is 1. So you can make 	 
     Shorewall as verbose as previously using a single -v and you can make it 	 
     almost silent by using a single -q. 	 
  	 
     If VERBOSITY is set at 2, you can still make a command nearly 	 
     silent by using two "q"s (e.g., shorewall -qq restart). 	 
  	 
     In summary, each "q" subtracts one from VERBOSITY while each "v" adds one 	 
     to VERBOSITY. 	 
  	 
     The "shorewall show log", "shorewall logwatch" and "shorewall dump" 	 
     commands require VERBOSITY to be greater than or equal to 3 to 	 
     display MAC addresses.This is consistent with the previous 	 
     implementation which required a single -v to enable MAC display but 	 
     means that if you set VERBOSITY=0 in shorewall.conf, then you will 	 
     need to include -vvv in commands that display log records in order 	 
     to have MACs displayed. 	 
  	 
     To make the display of MAC addresses less cumbersome, a '-m' option has 	 
     been added to the "show" and logwatch commands: 	 
  	 
         shorewall show -m log 	 
         shorewall logwatch -m 	 
  	 
 2)  A new 'shorewall compile' command has been added. 	 
  	 
      shorewall compile [ -e ] [ <config directory> ] <script file> 	 
  	 
     where: 	 
  	 
         -e                    Allows the generated script to run 	 
                               on a system with Shorewall Lite installed. 	 
                               Generates an error if the configuration uses 	 
                               an option that would prevent the generated 	 
                               script from running on a system other than 	 
                               where the 'compile' command is running (see 	 
                               additional consideration a) below). 	 
  	 
         <config directory>    Is an optional directory to be searched for 	 
                               configuration files prior to those listed 	 
                               in CONFIG_PATH in 	 
                               /etc/shorewall/shorewall.conf. 	 
         <script file>         Is the name of the output file. 	 
  	 
     The 'compile' command processes the configuration and generates a 	 
     script file which may then be executed to configure the firewall. 	 
  	 
     The generated script supports the following commands: 	 
  	 
         start -   starts the firewall 	 
         stop  -   stops the firewall 	 
         clear -   clears the firewall (removes all iptables rules) 	 
         restart - restarts the firewall 	 
         status  - displays the firewall status 	 
         version - displays the version of shorewall used to create the 	 
                   script 	 
  	 
     The generated script contains error checking and will terminate if an 	 
     important command fails. Before terminating: 	 
	  	 
    a) The script will check for the existence of the restore script 	 
       specified by the RESTOREFILE variable in shorewall.conf. If that 	 
       restore script exists, it is executed. 	 
 	 
    b) If the restore script doesn't exist but Shorewall appears to be 	 
       installed on the system, the equivalent of an 	 
       "/sbin/shorewall stop" command is executed. 	 
 	 
    Some additional considerations: 	 
 	 
    a) When you run 'compile' on one system and then run the generated script 	 
       on another system under Shorewall Lite, there are certain limitations. 	 
 	 
       1) A compatible version of Shorewall Lite must be running on the remote 	 
          system. Going forward, the goal is that any minor version of 	 
          the current major version will be compatible. So if the 	 
          program is compiled using Shorewall 3.2.x, any 3.2.y version 	 
          or 3.p.q version (where p > 2) of Shorewall Lite will be compatible. 	 
       2) The 'detectnets' interface option is not allowed. 	 
       3) DYNAMIC_ZONES=Yes is not allowed. 	 
       4) You must supply the file /etc/shorewall/capabilities to provide 	 
          the compiler with knowledge of the capabilities of the system 	 
          where the script is to be run. See below. 	 
       5) If your /etc/shorewall/params file contains code other than simple 	 
          assignment statements with contant values, then you should move 	 
          that code to /etc/shorewall/init. That way, the code will be 	 
          executed on the target system when the compiled script is run and 	 
          not on the local system at compile time. 	 
 	 
    b) If you run the "shorewall compile" or "shorewall check" commands under 	 
       a user other than 'root', then you must supply 	 
       /etc/shorewall/capabilities. 	 
 	 
    c) To aid in building /etc/shorewall/capabilities, a 'shorecap' program 	 
       is provided in the Shorewall Lite package and is installed in 	 
       /usr/share/shorewall-lite/shorecap when you install Shorewall Lite. 	 
 	 
       For instructions about running shorecap, see the comments at the 	 
       top of the program file (it's a simple shell script). 	 
 	 
    The "shorewall start" and "shorewall restart" commands have been 	 
    rewritten to use compilation. They both compile a temporary program 	 
    then run it. This results in a slightly longer elapsed time than the 	 
    similar commands required under earlier versions of Shorewall but new 	 
    connections are blocked for a much smaller percentage of that time. 	 
 	 
    If an error is found during the compilation phase, /sbin/shorewall 	 
    terminates and the Shorewall state is unchanged. 	 
 	 
    Under Shorewall 3.1.5, "shorewall restart" takes roughly 16.5 seconds 	 
    on my firewall: 	 
 	 
        real    0m16.599s 	 
        user    0m6.292s 	 
        sys     0m9.885s 	 
 	 
    Of the elapsed 16.5 seconds, new connections are disabled less than 	 
    3.5 seconds. Here are some numbers for comparison: 	 
 	 
    A) shorewall restart (Shorewall 3.0.4) 	 
 	 
        real    0m17.540s 	 
        user    0m5.956s 	 
        sys     0m10.737s 	 
 	 
    B) ./foo restart # foo created using "shorewall compile" 	 
 	 
        real    0m3.297s 	 
        user    0m1.444s 	 
        sys     0m1.728s 	 
 	 
    C) shorewall restore (Shorewall 3.0.4) # Restores from file generated by 	 
                                           # "shorewall save" 	 
 	 
        real    0m1.164s 	 
        user    0m0.556s 	 
        sys     0m0.608s 	 
 	 
    D) shorewall restore (shorewall 3.1.5) 	 
 	 
        real    0m1.637s 	 
        user    0m0.728s 	 
        sys     0m0.584s 	 
 	 
    The time difference between B and C reflects the difference between 	 
    "iptables-restore" and multiple executions of "iptables". The time 	 
    difference between C and D results from the fact that the "restore" 	 
    command in Shorewall 3.1 runs the compiled program in a way that 	 
    turns all iptables commands into no-ops then invokes 	 
    iptables-restore. The system is a 1.4Ghz Celeron with 512MB RAM. 	 
 	 
    As a final part of this change, the "check" command now compiles the 	 
    current configuration and writes the compiled output to /dev/null. So 	 
    "check" performs all of the same validation that compile does. Note that 	 
    there is still no guarantee that the generated script won't encounter 	 
    run-time errors. 	 
 	 
2)  The /etc/shorewall/maclist file has a new column layout. The first column 	 
    is now DISPOSITION. This column determines what to do with matching 	 
    packets and can have the value ACCEPT or DROP (if MACLIST_TABLE=filter, it 	 
    can also contain REJECT). This change is upward compatible so your existing 	 
    maclist file can still be used. 	 
 	 
    ACCEPT, DROP and REJECT may be optionally followed by a log level to 	 
    cause the packet to be logged. 	 
 	 
4)  In macro files, you can now use the reserved words SOURCE and DEST 	 
    in the columns of the same names. When Shorewall expands the 	 
    macro, it will substitute the SOURCE from the macro invocation for 	 
    SOURCE and the DEST from the invocation for DEST. This allows you 	 
    to write macros that act in both directions (from source to destination 	 
    and from destination to source). 	 
 	 
    Example: 	 
 	 
        macro.FOO: 	 
 	 
            PARAM      SOURCE        DEST      udp     500 	 
            PARAM      DEST          SOURCE    udp     500 	 
 	 
        /etc/shorewall/rules: 	 
 	 
            FOO/ACCEPT    fw         net 	 
 	 
        Resulting rules: 	 
 	 
            ACCEPT        fw         net        udp     500 	 
            ACCEPT        net        fw         udp     500 	 
 	 
    This new feature has been used to implement the SMBBI macro. 	 
    SMBBI is the same as the SMB macro with the exception that 	 
    it passes SMB traffic in both directions whereas SMB only 	 
    passes that traffic in one direction. 	 
 	 
5)  In the /etc/shorewall/rules file and in actions, you may now specify 	 
    'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also 	 
    requires that the SYN flag is set and the RST, FIN and ACK flags be 	 
    off ("--syn" is added to the iptables rule). 	 
 	 
    As part of this change, Shorewall no longer adds the "--syn" option 	 
    to TCP rules that specify QUEUE as their target. 	 
 	 
6)  /sbin/shorewall now supports a "-t" option that causes all progress 	 
    messages to be timestamped. 	 
 	 
    Example (VERBOSITY=0 in shorewall.conf): 	 
 	 
    gateway:/etc/shorewall # shorewall -t restart 	 
    07:08:51 Compiling... 	 
    07:09:05 Shorewall configuration compiled to /var/lib/shorewall/.restart 	 
    07:09:05 Restarting Shorewall.... 	 
    07:09:08 done. 	 
    gateway:/etc/shorewall # 	 
 	 
7)  A 'refreshed' extension script has been added -- it is executed after 	 
    "shorewall refresh" has finished. 	 
 	 
8)  Two new dynamic blacklisting commands have been added: 	 
 	 
        logdrop -- like 'drop' but causes the dropped packets to be logged. 	 
 	 
        logreject -- like 'reject' but causes the rejected packets to be 	 
                     logged. 	 
 	 
    Packets are logged at the BLACKLIST_LOGLEVEL if one was specified at the 	 
    last "shorewall [re]start"; otherwise, they are logged at the 'info' 	 
    log level. 	 
 	 
9)  A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When 	 
    this option is set to "Yes", it causes subzones to be treated differently 	 
    with respect to policies. 	 
 	 
    Subzones are defined by following their name with ":" and a list of parent 	 
    zones (in /etc/shorewall/zones). Normally, you want to have a set of 	 
    special rules for the subzone and if a connection doesn't match any of 	 
    those subzone-specific rules then you want the parent zone rules and 	 
    policies to be applied. With IMPLICIT_CONTINUE=Yes, that happens 	 
    automatically. 	 
 	 
    If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then 	 
    subzones are not subject to this special treatment. 	 
 	 
    With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden 	 
    by including an explicit policy (one that does not specify "all" in either 	 
    the SOURCE or the DEST columns). 	 
 	 
    Example: 	 
 	 
    /etc/shorewall/zones: 	 
 	 
        prnt       ipv4 	 
        chld:prnt  ipv4 	 
 	 
    Traffic to/from the 'chld' zone will first pass through the applicable 	 
    'chld' rules and if none of those rules match then it will be passed through 	 
    the appropriate 'prnt' rules. If the connection request does not match 	 
    any of the 'prnt' rules then the relevant 'prnt' policy is applied. 	 
 	 
    If you want the fw->chld policy to be ACCEPT, simply add this entry to 	 
    /etc/shorewall/policy: 	 
 	 
        $FW      chld        ACCEPT 	 
 	 
    Traffic from all other zones to 'chld' will be subject to the implicit 	 
    CONTINUE policy. 	 
 	 
10) Shorewall now includes support for explicit routing rules when the 	 
    /etc/shorewall/providers file is used. A new file, 	 
    /etc/shorewall/route_rules can be used to add routing rules based on 	 
    packet source and/or destination. 	 
 	 
    The file has the following columns: 	 
 	 
                SOURCE(optonal) An ip address (network or host) that 	 
                                matches the source IP address in a packet. 	 
                                May also be specified as an interface 	 
                                name optionally followed by ":" and an 	 
                                address. If the define 'lo' is specified, 	 
                                the packet must originate from the firewall 	 
                                itself. 	 
 	 
                DEST(optional)  An ip address (network or host) that 	 
                                matches the destination IP address in a packet. 	 
 	 
                                If you choose to omit either SOURCE or DEST, 	 
                                place "-" in the column. Note that you 	 
                                may not omit both SOURCE and DEST. 	 
 	 
                PROVIDER        The provider to route the traffic through. 	 
                                May be expressed either as the provider name 	 
                                or the provider number. You may also specify 	 
                                the 'main' routing table here, either by 	 
                                name or by number (254). 	 
 	 
                PRIORITY 	 
                                The rule's priority which determines the order 	 
                                in which the rules are processed. 	 
 	 
                                1000-1999   Before Shorewall-generated 	 
                                            'MARK' rules 	 
 	 
                                11000- 11999 After 'MARK' rules but before 	 
                                            Shorewall-generated rules for 	 
                                            provider interfaces. 	 
 	 
                                26000-26999 After provider interface rules but 	 
                                            before 'default' rule. 	 
 	 
                                Rules with equal priority are applied in 	 
                                the order in which they appear in the file. 	 
 	 
    Example 1: You want all traffic coming in on eth1 to be routed to the ISP1 	 
             provider: 	 
 	 
            #PROVIDER   PRIORITY        SOURCE                  DEST 	 
            ISP1        1000            eth1 	 
 	 
    Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple 	 
               providers. In this case you have to set up a rule to ensure that 	 
               the OpenVPN traffic is routed back through the tunX interface(s) 	 
               rather than through any of the providers. 10.8.0.0/24 is the 	 
               subnet choosen in your OpenVPN configuration (server 10.8.0.0 	 
               255.255.255.0) 	 
 	 
        #SOURCE                 DEST            PROVIDER        PRIORITY 	 
        -                       10.8.0.0/24     main            1000 	 
 	 
11) Prior to now, it has not been possible to use connection marking in 	 
    /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the 	 
    'track' option. 	 
 	 
    Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in 	 
    shorewall.conf to effectively divide the packet mark and connection mark 	 
    into two 8-bit mark fields. 	 
 	 
    When you do this: 	 
 	 
        a) The MARK field in the providers file must have a value that is 	 
           less than 65536 and that is a multiple of 256 (using hex 	 
           representation, the values are 0x0100-0xFF00 with the low-order 	 
           8 bits being zero). 	 
 	 
        b) You may only set those mark values in the PREROUTING chain. 	 
 	 
        c) Marks used for traffic shaping must still be in the range of 1-255 	 
           and may still not be set in the PREROUTING chain. 	 
 	 
        d) When you SAVE or RESTORE in tcrules, only the TC mark value is 	 
           saved or restored. Shorewall handles saving and restoring the 	 
           routing (provider) marks. 	 
 	 
12) A TOS column has been added to /etc/shorewall/tcrules. This allows marking 	 
    based on the contents of the TOS field in the packet header. 	 
 	 
13) Beginning with this release, the way in which packet marking in the 	 
    PREROUTING chain interracts with the 'track' option in /etc/shorewall/providers 	 
    has changed in two ways: 	 
 	 
    a)  Packets *arriving* on a tracked interface are now passed to the PREROUTING 	 
        marking chain so that they may be marked with a mark other than the 	 
        'track' mark (the connection still retains the 'track' mark). 	 
 	 
    b)  When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets 	 
        in the PREROUTING chain (i.e., you can specify a mark value of zero). 	 
 	 
14) Shorewall will now attempt to detect the MTU of devices listed in 	 
    /etc/shorewall/tcdevices and will use the detected MTU in setting 	 
    up traffic shaping. 	 
 	 
15) In /etc/shorewall/rules, the values "all-" and "all+-" may now be 	 
    used for zone names. "all-" means "All zones except the firewall"; 	 
    "all+-" means "All zones except the firewall" and intra-zone 	 
    traffic is included. 	 
 	 
16) Kernel version 2.6.16 introduces 'xtables', a new common packet 	 
    filtering and connection tracking facility that supports both IPv4 	 
    and IPv6. Because a different set of kernel modules must be loaded 	 
    for xtables, Shorewall now includes two 'modules' files: 	 
 	 
    a) /usr/share/shorewall/modules -- the former 	 
    /etc/shorewall/modules 	 
 	 
    b) /usr/share/shorewall/xmodules -- a new file that support 	 
    xtables. 	 
 	 
    If you wish to use the new file, then simply execute this command: 	 
 	 
    cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules 	 
 	 
17) Shorewall now checks to see if devices in /etc/shorewall/tcdevices 	 
    exist. If a device does not exist, a warning message is issued and 	 
    that device's entries in /etc/shorewall/tcclasses are ignored. This 	 
    applies to "shorewall start", "shorewall restart" and "shorewall 	 
    refresh". 	 
 	 
18) "load" and "reload" commands have been added. These commands allow 	 
    a non-root user with ssh access to a remote system running 	 
    Shorewall Lite to compile a firewall script on the local system and 	 
    to install that script on the remote system. 	 
 	 
    Syntax is: 	 
 	 
           shorewall [re]load [ <directory> ] <system> 	 
 	 
    If <directory> is omitted, the current working directory is 	 
    assumed. 	 
 	 
    The command is equivalent to: 	 
 	 
    /sbin/shorewall compile -e <directory> firewall &&\ 	 
    scp firewall root@<system>:/var/lib/shorewall-lite/ &&\ 	 
    ssh root@<system> '/sbin/shorewall-lite [re]start' # Note 1 	 
 	 
    In other words, the configuration in the specified (or defaulted) 	 
    directory is compiled to a file called firewall in that 	 
    directory. If compilation succeeds, then 'firewall' is copied to the 	 
    (usually remote) <system> using scp. If the copy succeeds, 	 
    Shorewall Lite on <system> is started or restarted via ssh ( 	 
    load causes Shorewall Lite to be started and 'reload' causes 	 
    Shorewall Lite to be re-started) 	 
 	 
    Note 1: In Shorewall Lite 3.2.0 RC4, the 'firewall' script has moved 	 
    from /usr/share/shorewall-lite/ to /var/lib/shorewall-lite in 	 
    packages from shorewall.net. The package maintainers for the 	 
    various distributions are free to choose the directory where the 	 
    script will be stored under their distribution by altering the 	 
    value of LITEDIR in /usr/share/shorewall/configpath. You can run the 	 
    "shorewall show config" command to see how your distribution 	 
    defines LITEDIR. 	 
 	 
Problems corrected in 3.2.1 	 
 	 
1)  The output formatting of the 'hits' command under BusyBox 1.2.0 has 	 
    been corrected. 	 
 	 
2)  Shorewall no longer requires extended MARK support to use the 'track' 	 
    provider option when HIGH_ROUTE_MARKS=No. 	 
 	 
3)  The output of the 'hits' command was previously scrambled if 	 
    /etc/services contained spaces as column delimiters rather than 	 
    tabs. 	 
 	 
4)  The /usr/share/shorewall/xmodules file was previously just a copy 	 
    of /usr/share/shorewall/modules. 	 
 	 
5)  The version number in the comments at the top of shorewall.conf has 	 
    been corrected. 	 
 	 
6)  The script generated when the -e option is given to the 'compile' 	 
    command is  setting CONFIG_PATH to the value given in the remote 	 
    firewall's shorewall.conf processed at compile time. This is 	 
    generally incorrect and results in the inability to load any kernel 	 
    modules on the firewall during 'shorewall-lite [re]start'. 	 
 	 
Problems Corrected in 3.2.2 	 
 	 
1)  Previously, the "shorewall stop" command would create empty files 	 
    named /nat and /proxyarp. 	 
 	 
2)  Scripts compiled for export did not support the 'reset' command. As 	 
    a result, on firewall systems running Shorewall Lite the command 	 
    "shorewall-lite reset" failed. 	 
 	 
Other changes in 3.2.2 	 
 	 
1)  The way in which options in /etc/shorewall-lite/shorewall.conf are 	 
    handled has been changed. Previously, problems would occur if 	 
    options were set differently in the shorewall.conf file located in 	 
    a firewall's export directory on the administrative system and in 	 
    /etc/shorewall-lite/shorewall.conf on the firewall system. 	 
 	 
    To eliminate those problems, both Shorewall and Shorewall Lite have 	 
    been modified. Now, settings in /etc/shorewall-lite/shorewall.conf 	 
    override settings from the export directory. Any variable not set 	 
    (or set to the empty value) in /etc/shorewall-lite/shorewall.conf 	 
    will get its value from the shorewall.conf file in the firewall's 	 
    export directory (see 	 
    http://www.shorewall.conf/CompiledPrograms.html for a description 	 
    of "export directories"). 	 
 	 
    The "shorewall compile -e" and "shorewall [re]load" commands now 	 
    create two files -- the script file and an auxiliary configuration 	 
    file. The name of the auxiliary configuration file is formed by 	 
    appending ".conf" to the name of the firewall script. So, the 	 
    "[re]load" command now creates both 'firewall' and 'firewall.conf' 	 
    and the command copies both files to /var/lib/shorewall-lite/ on 	 
    the firewall system. 	 
 	 
    The shorewall.conf file released with Shorewall Lite now sets no 	 
    option values. So by default, the options that the firewall 	 
    system will use are determined entirely by the shorewall.conf file 	 
    in the export directory. 	 
 	 
    If you are upgrading from an earlier 3.2 release, I recommend that 	 
    you modify your /etc/shorewall-lite/shorewall.conf file(s) to set 	 
    all variables to the empty value (e.g., IPTABLES= ). This will 	 
    allow your Shorewall Lite installation(s) to conform to the new 	 
    option convention. Both the administrative system and the firewalls 	 
    must be running 3.2.2 or later and each firewall's configuration 	 
    must be recompiled and re-exported for changes to take effect. 	 
 	 
2)  The 'shorewall show capabilites' command now accepts a '-f' (file) 	 
    option (e.g., shorewall show -f capabilities). When '-f' is given, 	 
    the output is the same as the output from the 'shorecap' program 	 
    that is included in Shorewall Lite and can be used to generate a 	 
    capabilities file for use during compilation. 	 
 	 
    WARNING: The output is only meaningful when the command is run by 	 
    root. 	 
 	 
3)  The manner in which Shorewall determines the presence of the 	 
    'physdev match' capability has been modified to accomodate the 	 
    upcoming kernel change that will remove much of the functionality 	 
    of the match. 	 
 	 
4)  The install.sh script now supports a -n option: 	 
 	 
        ./install.sh -n 	 
 	 
    When -n is given, no backup of the current configuration is 	 
    performed. This is used primarily by Shorewall developers as it 	 
    allows repeated installs of the same version without destroying 	 
    the backup of the prior version. 	 
 	 
5)  The "shorewall [re]load" command(s) now support a -s option: 	 
 	 
    Example: 	 
 	 
        shorewall reload -s gateway 	 
 	 
    The option causes the configuration on the firewall to be saved if 	 
    [re]start is successfull. 	 
 	 
6)  A new 'optional' option has been added to 	 
    /etc/shorewall/providers. If this option is specified, if the 	 
    interface specified in the INTERFACES column isn't up and 	 
    configured with an IPv4 address then a warning message is issued 	 
    and the provider is not configured.
