Shorewall 4.1 Patch Release 8. ---------------------------------------------------------------------------- R E L E A S E 4 . 1 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. 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.1: 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. Problems Corrected in Shorewall 4.1.8 1) Changes to your configuration made by NULL_ROUTE_RFC1918=Yes are now reversed during 'shorewall stop' and 'shoreawll restart'. 2) The init script on Debian now reads and utilizes the value of the OPTIONS variable from /etc/default/shorewall[-lite]. Previously, the value of that variable was not passed to the shorewall[-lite] command. 3) With both Shorewall and Shorewall Lite, the 'start' and 'restart' commands now support a '-p' option. This option causes the Netfilter connection tracking table to be flushed (purged) as part of the operation. The 'conntrack' utility must be installed to use this option. Other Changes in Shoreall 4.1.8. 1) When using Shorewall-perl, the CEIL and RATE columns must now contain arithmetic expressions consisting of: a) Numeric digits (Hex numbers not allowed). b) Parentheses. c) The arithmetic operators +-* and /. d) The word 'full'. 2) The installers (install.sh) now auto-detect a Cygwin environment and install under the current user's ID if OWNER and GROUP are not given. 3) The 'start' and 'restart' commands now support a '-p' (purge) option which cause all entries to be removed from the Netfilter conntrack table. In order to use this option, the 'conntrack' utility must be installed on your system. Although it is generally not installed by default, Most distributions have this utility in their repositories. New Features in Shorewall 4.1. 1) Shorewall 4.1 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.1 or Shorewall-lite 4.1. 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 table to be reloaded. Example: shorewall refresh nat: 3) When no chain name is given to the 'shorewall refresh' command, the mangle table is refreshed along with the blacklist chain (if any). This allows you to modify /etc/shorewall/tcrules and install the changes using 'shorewall refresh'. 4) Support for the NFLOG log target has been added. NFLOG is a successor to ULOG. In addition, both ULOG and NFLOG may be followed by a list of up to three numbers in parentheses. The first number specifies the netlink group (1-32). If omitted (e.g., NFLOG(,0,10)) then a value of 1 is assumed. The second number specifies the maximum number of bytes to copy. If omitted, 0 (no limit) is assumed. The third number specifies the number of log messages that should be buffered in the kernel before they are sent to user space. The default is 1. Examples: /etc/shorewall/shorewall.conf: MACLIST_LOG_LEVEL=NFLOG(1,0,1) /etc/shorewall/rules: ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080 5) Shorewall-perl 4.1 implements an alternative syntax for macro parameters and for the NFQUEUE queue number. Rather than following the macro name (or NFQUEUE) with a slash ("/") and the parameter, the parameter may be enclosed in parentheses. Examples -- each pair shown below are equivalent: DNS/ACCEPT DNS(ACCEPT) NFQUEUE/3 NFQUEUE(3) The old syntax will still be accepted but will cease to be documented in some future Shorewall release. 6) Shorewall 4.1 contains enhanced operational logging capabilities through a set of related enhancements to Shorewall-common and Shorewall-perl. The enhancements are not supported by Shorewall-shell nor are they supported by Shorewall-lite except when the script is compiled using Shorewall-perl. a) The STARTUP_LOG option in /etc/shorewall/shorewall.conf gives the name of the Shorewall operational log. The log will be created if it does not exist. b) The LOG_VERBOSITY option in /etc/shorewall/shorewall.conf gives the verbosity at which logging will occur. It uses the same value range as VERBOSITY: -1 Do not log 0 Almost quiet 1 Only major steps 2 Verbose c) An absolute VERBOSITY may be specified on the command line using the -v option followed by -1,0,1 or 2. Example: shorewall -v2 check d) The /etc/init.d/shorewall script supplied with the shorewall.net packages sets '-v0' as the default. This may be overridden with the OPTIONS setting in /etc/defaults/shorewall or /etc/sysconfig/shorewall. Logging occurs on both Shorewall-perl and the generated script when the following commands are issued: start restart refresh Messages in the log are always timestamped. This change implemented two new options to the Shorewall-perl compiler (/usr/share/shorewall-perl/compiler.pl). --log= --log_verbosity={-1|0-2} The --log option is ignored when --log_verbosity is not supplied or is supplied with value -1. To avoid a proliferation of parameters to Shorewall::Compiler::compile(), that function has been changed to use named parameters. Parameter names are: object Object file. If omitted or '', the configuration is syntax checked. directory Directory. If omitted or '', configuration files are located using CONFIG_PATH. Otherwise, the directory named by this parameter is searched first. verbosity Verbosity; range -1 to 2 timestamp 0|1 -- timestamp messages. debug 0|1 -- include stack trace in warning/error messages. export 0|1 -- compile for export. chains List of chains to be reloaded by 'refresh'. log File to log compiler messages to. log_verbosity Log Verbosity; range -1 to 2. Those parameters that are supplied must have defined values. Defaults are: object '' ('check' command) directory '' verbosity 1 timestamp 0 debug 0 export 0 chains '' log '' log_verbosity -1 Example: use lib '/usr/share/shorewall-perl/'; use Shorewall::Compiler; compiler( object => '/root/firewall', log => '/root/compile.log', log_verbosity => 2 ); 7) 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 chain. 8) Previously, Shorewall did not range-check the value of the VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.1: 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. 9) The tcdevices file has been extended to include an OPTIONS column. Currently only a single option is defined. classify When specified, you must use explicit CLASSIFY tcrules to classify traffic by class. Shorewall will not create any CLASSIFY rules to classify traffic by mark value. See http://www.shorewall.net/traffic_shaping.htm for further information. 10) COMMENT lines are now supported in macro bodies by Shorewall-perl and are ignored by the Shorewall-shell compiler. COMMENT lines in macros work slightly differently from COMMENT lines in other files. COMMENT lines in macros are ignored if COMMENT support is not available or if there was a COMMENT in use when the top-level macro was invoked. This allows the following: /etc/shorewall/macro.SSH: #ACTION SOURCE PROTO DEST SOURCE RATE USER/ # PORT(S) PORT(S) LIMIT GROUP COMMENT My SSH Macro PARAM - - tcp 22 /etc/shorewall/rules: COMMENT Allow SSH from home SSH/ALLOW net:$MYIP $FW COMMENT The comment line in macro.SSH will not override the COMMENT line in the rules file and the generated rule will show /* Allow SSH from home */ when displayed through the Shorewall show and dump commands. If a macro is invoked and there is no current comment, then the name of the macro automatically becomes the current comment. This makes macros self-commenting. 11) If the program named in SHOREWALL_SHELL doesn't exist or is not executable, Shorewall and Shorewall-lite now both fall back to /bin/sh after issuing a warning message. Previously, both terminated with a fatal error. 12) Shorewall-perl now generates fatal error conditions if there are no IPv4 zones defined or there are no interfaces defined. 13) Shorewall now unconditionally uses tc filter rules to classify traffic by MARK value. Previously, Shorewall used the CLASSIFY target in the POSTROUTING chain if it was available. 14) The Shorewall installers (install.sh) now work on Windows under Cygwin. By default, they install under the user id and group of the person doing the install. This can be overridden by specifying OWNER and GROUP explicitly. Example: OWNER=foo GROUP=bar ./install.sh To install Shorewall-perl under Cygwin: $ tar -zxf shorewall-perl-4.x.y.tar.bz2 $ tar -zxf shorewall-common-4.x.y.tar.bz2 $ cd shorewall-perl-4.x.y $ ./install.sh $ cd ../shorewall-common-4.x.y $ ./install.sh The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/). 15) When installing on Cygwin, /etc/shorewall is no longer fully populated. Rather, only the shorewall.conf and params files are installed. As always, the full configuration file set is installed in /usr/share/shorewall/configfiles. 16) 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- 17) The /etc/shorewall/masq and /etc/shorewall/nat file now accept a comma-separated list of interface names where before only a single interface name could be listed (Shorewall-perl only). This feature is not for beginners. It iterates over the list of interfaces, substituting each interface in place of the list and processing the resulting entry according to the semantics of earlier Shorewall versions. If you don't know where to use this, don't try. Example 1: /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS eth0,eth1 eth2 1.2.3.4 equivalent to: #INTERFACE SOURCE ADDRESS eth0 eth2 1.2.3.4 eth1 eth2 1.2.3.4 Example 2: /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS eth0,eth1::192.168.1.0/24 eth2 1.2.3.4 equivalent to: #INTERFACE SOURCE ADDRESS eth0::192.168.1.0/24 eth2 1.2.3.4 eth1::192.168.1.0/24 eth2 1.2.3.4 Example 3: /etc/shorewall/nat: #EXTERNAL INTERFACE INTERNAL 206.124.146.178 eth0,wlan0 192.168.1.3 equivalent to: #EXTERNAL INTERFACE INTERNAL 206.124.146.178 eth0 192.168.1.3 206.124.146.178 wlan0 192.168.1.3 18) Previously, the INTERFACE name used in the masq, nat and netmap files had to exactly match the name of an interface from the interfaces file. Beginning with Shorewall-perl 4.1.4, the interface may loosely match a wildcard entry in the interfaces file. Example: /etc/shorewall/interfaces: vpn tun+ /etc/shorewall/masq: tun1 192.168.4.0/24 19) Previously, Shorewall classified non-firewall zones as either 'simple' or 'complex'. Attributes of a zone which made it 'complex' included: - The zone was of type 'ipsec' or 'ipsec4' or it had a hosts entry with the 'ipsec' options. - The zone had OPTIONS, IN OPTIONS or OUT OPTIONS - The zone had more than one network on a given interface - The zone had a hosts file entry with an exclusion. - The zone had a hosts file entry specifying an ipset. The handling of 'simple' and 'complex' zones was different. - complex zones had their own 'forward' chain (named '_frwd'). - complex zones with exclusions had their own 'input' and 'output' chains. Beginning with Shorewall-perl 4.1, all non-firewall zones will be treated as 'complex'. This will have the effect of one additional filter chain per zone but in most cases, the average number of filter rules traversed by a connection request will be reduced. 20) The need for interface-specific chains (such as eth0_in, eth4_fwd, etc.) in the filter table has been drastically reduced. This has the effect of reducing the average number of rules that each packet must traverse. 21) The default value for LOG_MARTIANS is now 'Yes' ('On' in Shorewall-perl). Previously, the default value was 'No' ('Off' in Shorewall-perl). The shorewall.conf file has also been updated to specify a value of 'Yes' (which is interpreted as 'On' by Shorewall-perl). 22) Shorewall-perl now generates an error when a MAC address appears in a traffic shaping rule in the OUTPUT or POSTROUTING chains. 23) Macros are now self-commenting under control of a new AUTO_COMMENT option in shorewall.conf. When this option is set, if there is not a current comment when a macro is invoked, the behavior under Shorewall-perl is as if the first line of the macro file was "COMMENT ". So, if you have this rule: SSH/ACCEPT loc fw then the generated netfilter rule will include "/* SSH */" when viewed with 'iptables -L' or 'shorewall show loc2fw' or 'shorewall dump'. The AUTO_COMMENT option has a default value of 'Yes' and is only available under Shorewall-perl. The option is ignored by Shorewall-shell. 24) The default value for the IMPLICIT_CONTINUE option has been changed to 'No'. 25) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP port 1701 in both directions and assumes that the source port will also be 1701. Some implementations (particularly OS X) use a different source port. In that case, you should use 'generic:udp:1701' rather than 'l2tp'. 26) The /etc/shorewall/tcdevices and /etc/shorewall/tcclasses files have undergone some changes, especially when the 'classify' option has been specified. Normally Shorewall assigns interface numbers sequentially to devices listed in /etc/shorewall/tcdevices. Beginning with Shorewall 4.1.6, you can explicitly specify inteface numbers by prefixing the interface name with the interface number and a colon: Example: #INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS 1:eth0 1300kbit 384kbit classify 2:eth1 5600kbit 1000kbit In /etc/shorewall/tcclasses: a) You can specify the INTERFACE using either the interface name or interface number. b) classes associated with devices which have the 'classify' option _must_ specify a class number by following the interface name/number with a colon (":") and the class number. The same class number may be used for classes defined on different interfaces but a class number may not be the same as any interface number. A class number may be specified when 'classify' has not been specified for the associated device. When a class number has not been given, the default class number remains the mark value prefixed by "1". 27) Shorewall now supports Intermediate Functional Block (IFB) devices. These devices allow shaping of incoming traffic. The 'ifb' module is available in the kernels included with today's distributions. You must load the module manually: If your distribution has modprobe: modprobe ifb [ numifbs= ] Otherwise: insmod /ifb.ko [ numifbs= ] By default, the module automatically creates two IFB devices (ifb0 and ifb1). To create only one, specify 'numifbs=1'. Example: ursa:~ # modprobe ifb numifbs=1 ursa:~ # ip link ls 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether cc:2b:cb:24:1b:00 brd ff:ff:ff:ff:ff:ff 3: wlan0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:1a:73:db:8c:35 brd ff:ff:ff:ff:ff:ff 4: ifb0: mtu 1500 qdisc noop qlen 32 link/ether 26:99:d8:7d:32:26 brd ff:ff:ff:ff:ff:ff ursa:~ # After you have created the IFB(s), you must bring it(them) up: ip link set dev ifb0 up You can place all of this in /etc/shorewall/init as follows: modprobe ifb numifbs=1 ip link set dev ifb0 up The /etc/shorewall/tcdevices file has been extended to include an additional REDIRECTED DEVICES column. To convert your configuration to use an IFB: a) Look at your current /etc/shorewall/tcdevices file. Suppose you have: #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS eth0 1300kbit 384kbit - Change it as follows: #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED # DEVICES eth0 - 384kkbit - ifb0 - 1300kbit - eth0 Note that the old IN-BANDWIDTH for eth0 has become the OUT-BANDWIDTH for ifb0 and that neither device has an IN-BANDWIDTH in the new configuration. Finally note that eth0 has been specified as a REDIRECTED device for the IFB. b) There are no Netfilter hooks between the real device (eth0) and the IFB (ifb0). So tcrules cannot be used to specify shaping of traffic leaving the IFB. To allow that traffic to be classified, a new /etc/shorewall/tcfilters file has been added. /etc/shorewall/tcfilters can be used for classifying traffic on any interface. When using entries in that file, it is important to realize that those entries act on packets as they appear 'on the wire'. That means that on output, SNAT/MASQUERADE has been applied and on input (output to an IFB), DNAT has not yet been applied. Columns in the file are: INTERFACE:CLASS The interface name or number followed by a colon (":") and the class number. SOURCE Source IP address. May be a host or network address. Specify "-" if any SOURCE address should match. DEST Destination IP address. May be a host or network address. Specify "-" if any DEST address should match. PROTO Protocol Name/Number. Specify "-" if any PROTO should match. DEST PORT(S) A comma-separated list of destination ports. May only be given if the PROTO is tcp, udp, icmp or sctp. Port ranges may be used, except when the PROTO is icmp. Specify "-" if any PORT should match. SOURCE PORT(S) A comma-separated list of source port. May only be given if the PROTO is tcp, udp or sctp. Port ranges may be used unless the protocol is icmp. Specify "-" if any PORT should match. Entries in /etc/shorewall/tcfilters generate U32 tc filters which may be displayed using the "shorewall show filters" ("shorewall-lite show filters") command. Note: The 'show filters' command is an alias for the existing 'show classifiers' command. Note that /etc/shorewall/tcfilters provides a usable alternative to HIGH_ROUTE_MARKS=Yes. You can use marks to select between providers and use entries in /etc/shorewall/tcfilters (or CLASSIFY tcrules) for traffic shaping. 28) If an interface fails when using balanced multi-ISP routing, the default route is lost. If there are remaining working interfaces with dynamic gateway addresses, Shorewall will be unable to determine those gateways. Beginning with Shorewall (Shorewall-lite) 4.1.7, the 'init' script may participate in gateway detection by setting variables with pre-determined names as follows: _GATEWAY where is the interface name: - in upper case - with any characters not allowed in shell variable names replaced by '_'. Example (from OpenWRT): Interface: eth0.1 Variable: ETH0_1_GATEWAY /etc/shorewall/init: ETH0_1_GATEWAY=$(uci get /var/state/network.wan0.gateway) 29) A new CONNBYTES column has been added to the tcrules file. The column defines a byte or packet range that the connection must fall within in order for the rule to match. The contents are: [!]:[[:{O|R|B}[:{B|P|A}]]] ! matches if the the packet/byte count is not within the range defined by and . is an integer which defines the beginning of the byte/packet range. is an integer which defines the end of the byte/packet range. If omitted, only the beginning of the range is checked. The first letter gives the direction which the range refers to: O - The original direction of the connection. R - The opposite direction from the original connection. B - The total of both directions. If omitted, 'B' is assumed. The second letter determins what the range refers to. B - Bytes P - Packets A - Average packet size. If omitted, 'B' is assumed. Examples: 1000000: - Connection has transferred a total of at least 1,000,000 bytes. 1000000::R - Connection has transferred at least 1,000,000 bytes in the direction opposite of the original direction (typical of a large download). 1000000::O:P - Connection has sent at least 1,000,000 packets in the direction of the original connection. 30) A new MANGLE_ENABLED option is added to shorewall.conf. The default setting is 'Yes' which causes Shorewall to assume responsibility for the Netfilter mangle table. When MANGLE_ENABLED is set to 'No', Shorewall assumes no responsibility for that table. In this setting: a) Shorewall doesn't alter the mangle table. b) You may not use Shorewall Traffic Shaping (TC_ENABLED must be set to 'No'. c) The tcrules file is ignored. d) The providers file must be empty. e) All entries in tcdevices must specify the 'classify' option and traffic classification may only occur using the tcfilters file. This allows for another application running on your firewall to take over the mangle table and use it for it's own purposes. 31) Shorewall-perl now supports an ORIGINAL DEST column in macro files. The column must be left empty if the macro is to be used in the body of an action. The new column is placed between the SOURCE PORT(S) and RATE LIMIT columns. So that Shorewall-perl can determine which column layout each macro has, a new FORMAT directive is added: FORMAT {1|2} The default is FORMAT 1 which is the old format. FORMAT 2 specifies that the macro is in the new format. 32) Shorewall-perl implements a new Rfc1918 macro that deals with RFC 1918 addresses. This macro should be used in place of the 'norfc1918' interface option which is deprecated. The macro body is: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT(S) PORT(S) DEST LIMIT GROUP FORMAT 2 PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \ DEST - - - - - - PARAM SOURCE DEST - - - 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE The 'norfc1918' option on the interface associated with zone 'z' and with RFC1018_STRICT=Yes is equivalent to: Rfc1918(DROP) z all 33) A better way to perform RFC 1918 filtration is to null-route the address ranges reserved by RFC 1918. You can do that by setting the new NULL_ROUTE_RFC1918 option to 'Yes' in shorewall.conf. It is highly recommended that you also set ROUTE_FILTER=Yes to get Martian messages. These will help diagnose problems where you need to be able to access hosts with RFC 1918 addresses that are outside of your local networks. Sometimes, these can be subtle such as the case where your ISP is using RFC 1918 addresses on their DHCP servers. NULL_ROUTE_RFC1918 defaults to 'No' and is only supported by Shorewall-perl; Shorewall-shell ignores the option. 34) There is now a macro.SANE which supports network-attached scanners. Shorewall now automatically loads the sane connection tracking helper module. Thanks for this feature go to Tuomo Soini. 35) Previously, when IP_FORWARDING=Yes in shorewall.conf, Shorewall would enable ip forwarding before instantiating the rules. This could lead to incorrect connection tracking entries being created between the time that forwarding was enabled and when the nat table rules were instantiated. Beginning with Shorewall 4.0.11 and 4.1.7, enabling of forwarding is deferred until after the rules are in place.