Shorewall 4.4.1 ---------------------------------------------------------------------------- R E L E A S E 4 . 4 H I G H L I G H T S ---------------------------------------------------------------------------- 1) Support for Shorewall-shell has been discontinued. Shorewall-perl has been combined with Shorewall-common to produce a single Shorewall package. 2) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing discipline has been added. HFSC is superior to the "Hierarchical Token Bucket" queuing discipline where realtime traffic such as VOIP is being used. HTB remains the default queuing discipline. 3) Support for the "flow" traffic classifier has been added. This classifier can help prevent multi-connection applications such as BitTorrent from using an unfair amount of bandwidth. 4) The Shorewall documentation and man pages have been purged of information about earlier Shorewall releases. The documentation describes only the behavior of Shorewall 4.4 and later versions. 5) The interfaces file OPTIONs have been extended to largely remove the need for the hosts file. 6) It is now possible to define PREROUTING and OUTPUT marking rules that cause new connections to use the same provider as an existing connection of the same kind. 7) Dynamic Zone support is once again available for IPv4; ipset support is required in your kernel and in iptables. 8) A new AUTOMAKE option has been added to shorewall.conf and shorewall6.conf. Setting this option will allow Shorewall to skip the compilation phase during start/restart if no configuration changes have occurred since the last start/restart. 9) The LIMIT:BURST column in /etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT column in /etc/shorewall/rules (/etc/shorewall6/rules) may now be used to limit on a per source IP or per destination IP basis. 10) Support for per-IP traffic shaping classes has been added. 11) Support for netfilter's TRACE facility has been added. TRACE allows you to trace selected packets through Netfilter, including marking by tcrules. ---------------------------------------------------------------------------- M I G R A T I O N I S S U E S ---------------------------------------------------------------------------- 1) If you are currently using Shorewall-shell: a) In shorewall.conf, if you have specified "SHOREWALL_COMPILER=shell" then you must either: - change that specification to "SHOREWALL_COMPILER=perl"; or - change that specification to "SHOREWALL_COMPILER="; or - delete the specification altogether. Failure to do so will result in the following warning: WARNING: SHOREWALL_COMPILER=shell ignored. Shorewall-shell support has been removed in this release. b) Review the incompatibilities between Shorewall-shell and Shorewall-perl at http://www.shorewall.net/Shorewall-perl.html#Incompatibilities and make changes to your configuration as necessary. We strongly recommend that you migrate to Shorewall-perl on your current Shorewall version before upgrading to Shorewall 4.4.0. That way, you can have both Shorewall-shell and Shorewall-perl available until you are certain that Shorewall-perl is working correctly for you. 2) The 'shorewall stop', 'shorewall clear', 'shorewall6 stop' and 'shorewall6 clear' commands no longer read the 'routestopped' file. The 'routestopped' file used is the one that was present at the last 'start', 'restart' or 'restore' command. IMPORTANT: If you modify the routestopped file, you must refresh or restart Shorewall before the changes to that file take effect. 3) The old macro parameter syntax (e.g., SSH/ACCEPT) is now deprecated in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.4 documentation uses the new syntax exclusively, although the old syntax continues to be supported. The sample configurations also use the new syntax. 4) Support for the SAME target in /etc/shorewall/masq and /etc/shorewall/rules has been removed, following the removal of the underlying support in the Linux kernel. 5) Supplying an interface name in the SOURCE column of /etc/shorewall/masq is now deprecated. Entering the name of an interface there will result in a compile-time warning: WARNING: Using an interface as the masq SOURCE requires the interface to be up and configured when Shorewall starts/restarts To avoid this warning, replace interface names by the corresponding network addresses (e.g., 192.168.144.0/24). 6) Previously, Shorewall has treated traffic shaping class IDs as decimal numbers (or pairs of decimal numbers). That worked fine until IPMARK was implemented. IPMARK requires Shorewall to generate class Ids in numeric sequence. In 4.3.9, that didn't work correctly because Shorewall was generating the sequence "..8,9,10,11..." when the correct sequence was "...8,9,a,b,...". Shorewall now treats class IDs as hex, as do 'tc' and 'iptables'. This should only be an issue if you have more than 9 interfaces defined in /etc/shorewall/tcdevices and if you use class IDs in /etc/shorewall/tcrules or /etc/shorewall/tcfilters. You will need to renumber the class IDs for devices 10 and greater. 7) Support for the 'norfc1918' interface and host option has been removed. If 'norfc1918' is specified for an entry in either the interfaces or the hosts file, a warning is issued and the option is ignored. Simply remove the option to avoid the warning. Similarly, if RFC1918_STRICT=Yes or a non-empty RFC1918_LOG_LEVEL is given in shorewall.conf, a warning will be issued and the option will be ignored. You may simply delete the RFC1918-related options from your shorewall.conf file if you are seeing warnings regarding them. Users who currently use 'norfc1918' are encouraged to consider using NULL_ROUTE_RFC1918=Yes instead. 8) The install.sh scripts in the Shorewall and Shorewall6 packages no longer create a backup copy of the existing configuration. If you want your configuration backed up prior to upgrading, you will need to do that yourself. As part of this change, the fallback.sh scripts are no longer released. 9) In earlier releases, if an ipsec zone was defined as a sub-zone of an ipv4 or ipv6 zone using the special :,... syntax, CONTINUE policies for the sub-zone did not work as expected. Traffic that was not matched by a sub-zone rule was not compared against the parent zone(s) rules. In 4.4.0, such traffic IS compared against the parent zone rules. 10) The name 'any' is now reserved and may not be used as a zone name. 11) Perl module initialization has changed in Shorewall 4.4.1. Previously, each Shorewall Perl package would initialize its global variables for IPv4 in an INIT block. Then, if the compilation turned out to be for IPv6, Shorewall::Compiler::compiler() would reinitialize them for IPv6. Beginning in Shorewall 4.4.1, the modules do not initialize themselves in an INIT block. So if you use Shorewall modules outside of the Shorewall compilation environment, then you must explicitly call the module's 'initialize' function after the module has been loaded. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 4 . 4 . 1 ---------------------------------------------------------------------------- 1) If ULOG was specified as the LOG LEVEL in the all->all policy, the rules at the end of the INPUT and OUTPUT chains would still use the LOG target rather than ULOG. 2) Using CONTINUE policies with a nested IPSEC zone was still broken in some cases. 3) The setting of IP_FORWARDING has been change to Off in the one-interface sample configuration since forwarding is typically not required with only a single interface. 4) If MULTICAST=Yes in shorewall.conf, multicast traffic was incorrectly exempted from ACCEPT policies. 5) Previously, the definition of a zone that specified "nets=" in /etc/shorewall/interfaces could not be extended by entries in /etc/shorewall/hosts. 6) Previously, "nets=" could be specified in a multi-zone interface definition ("-" in the ZONES column) in /etc/shorewall/zones. This now raises a fatal compilation error. 7) MULTICAST=Yes generates an incorrect rule that limits its effectiveness to a small part of the multicast address space. ---------------------------------------------------------------------------- K N O W N P R O B L E M S R E M A I N I N G ---------------------------------------------------------------------------- None. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 4 . 4 . 1 ---------------------------------------------------------------------------- 1) To replace the SAME keyword in /etc/shorewall/masq, support has been added for 'persistent' SNAT. Persistent SNAT is required when an address range is specified in the ADDRESS column and when you want a client to always receive the same source/destination IP pair. It replaces SAME: which was removed in Shorewall 4.4.0. To specify persistence, follow the address range with ":persistent". Example: #INTERFACE SOURCE ADDRESS eth0 0.0.0.0/0 206.124.146.177-206.124.146.179:persistent This feature requires Persistent SNAT support in your kernel and iptables. If you use a capabilities file, you will need to create a new one as a result of this feature. WARNING: Linux kernels beginning with 2.6.29 include persistent SNAT support. If your iptables supports persistent SNAT but your kernel does not, there is no way for Shorewall to determine that persistent SNAT isn't going to work. The kernel SNAT code blindly accepts all SNAT flags without verifying them and returns them to iptables when asked. 2) A 'clean' target has been added to the Makefiles. It removes backup files (*~ and .*~). 3) The meaning of 'full' has been redefined when used in the context of a traffic shaping sub-class. Previously, 'full' always meant the OUT-BANDWIDTH of the device. In the case of a sub-class, however, that definition is awkward to use because the sub-class is limited by the parent class. Beginning with this release, 'full' in a sub-class definition refers to the specified rate defined for the parent class. So 'full' used in the RATE column refers to the parent class's RATE; when used in the CEIL column, 'full' refers to the parent class's CEIL. As part of this change, the compiler now issues a warning if the sum of the top-level classes' RATEs exceeds the OUT-BANDWIDTH of the device. Similarly, a warning is issued if the sum of the RATEs of a class's sub-classes exceeds the rate of the CLASS. 4) When 'nets=' or 'nets=(,,...) is specified in /etc/shorewall/interfaces, multicast traffic will now be sent to the zone along with limited broadcasts. 5) A flaw in the parsing logic for the zones file allowed most zone types containing the character string 'ip' to be accepted as a synonym for 'ipv4' (or ipv6 if compiling an IPv6 configuration). ---------------------------------------------------------------------------- N E W F E A T U R E S I N 4 . 4 ---------------------------------------------------------------------------- 1) The Shorewall packaging has been completely revamped in Shorewall 4.4. The new packages are: - Shorewall. Includes the former Shorewall-common and Shorewall-perl packages. Has everything needed to create an IPv4 firewall. Shorewall-shell is no longer available. - Shorewall6. Requires Shorewall. Adds the components necessary to create an IPv6 firewall. - Shorewall-lite May be installed on a firewall system to run IPv4 firewall scripts generated by Shorewall. - Shorewall6-lite May be installed on a firewall system to run IPv6 firewall scripts generated by Shorewall6. 2) The interfaces file supports a new 'nets=' option. This option allows you to restrict a zone's definition to particular networks through an interface without having to use the hosts file. Example interfaces file: #ZONE INTERFACE BROADCAST OPTIONS loc eth3 detect dhcp,logmartians=1,routefilter=1,nets=172.20.1.0/24 dmz eth4 detect logmartians=1,routefilter=1,nets=206.124.146.177 net eth0 detect dhcp,blacklist,tcpflags,optional,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177) net eth2 detect dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177) loc tun+ detect nets=172.20.0.0/24 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Note that when more than one network address is listed, the list must be enclosed in parentheses. Notice also that exclusion may be used. The first entry in the above interfaces file is equivalent to the following: interfaces: #ZONE INTERFACE BROADCAST OPTIONS - eth0 detect dhcp,logmartians=1,routefilter=1 hosts: #ZONE HOST(S) OPTIONS loc $INT_IF:192.20.1.0/24 broadcast Note that the 'broadcast' option is automatically assumed and need not be explicitly specified. 3) Some websites run applications that require multiple connections from a client browser. Where multiple 'balanced' providers are configured, this can lead to problems when some of the connections are routed through one provider and some through another. To work around this issue, the SAME target has been added to /etc/shorewall/tcrules. SAME may be used in the PREROUTING and OUTPUT chains. When used in PREROUTING, it causes matching connections from an individual local system to all use the same provider. For example: SAME:P 192.168.1.0/24 - tcp 80,443 If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes then the new connection will use the same provider as the connection over which that last packet was sent. When used in the OUTPUT chain, it causes all matching connections to an individual remote system to use the same provider. For example: SAME $FW - tcp 80,443 If the firewall attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes to the same remote system then the new connection will use the same provider as the connection over which that last packet was sent. Important note: SAME only works with providers that have the 'track' option specified in /etc/shorewall/providers. 4) The file /var/lib/shorewall/.restore has been renamed to /var/lib/shorewall/firewall. A similar change has been made in Shorewall6. When a successful start or restart is completed, the script that executed the command copies itself to /var/lib/shorewall[6]/firewall. As always, /var/lib/shorewall[6] is the default directory which may be overridden using the /etc/shorewall[6]/vardir file. 5) Dynamic zone support is once again available for IPv4. This support is built on top of ipsets so you must have the xtables-addons installed on the firewall system. See http://www.shorewall.net/Dynamic.html for information about this feature and for instructions for installing xtables-addons on your firewall. Dynamic zones are available when Shorewall-lite is used as well. You define a zone as having dynamic content in one of two ways: - By specifying nets=dynamic in the OPTIONS column of an entry for the zone in /etc/shorewall/interfaces; or - By specifying :dynamic in the HOST(S) column of an entry for the zone in /etc/shorewall/hosts. When there are any dynamic zones present in your configuration, Shorewall (Shorewall-lite) will: a) Execute the following commands during 'shorewall start' or 'shorewall-lite start'. ipset -U :all: :all: ipset -U :all: :default: ipset -F ipset -X ipset -R < ${VARDIR}/ipsets.save where $VARDIR normally contains /var/lib/shorewall (/var/lib/shorewall-lite) but may be modified by /etc/shorewall/vardir (/etc/shorewall-lite/vardir). b) During 'start', 'restart' and 'restore' processing, Shorewall will attempt to create an ipset named _ for each zone/interface pair that has been specified as dynamic. The type of ipset created is 'iphash' so that only individual IPv4 addresses may be added to the set. c) Execute the following commands during 'shorewall stop' or 'shorewall-lite stop': if ipset -S > ${VARDIR}/ipsets.tmp; then mv -f ${VARDIR}/ipsets.tmp ${VARDIR}/ipsets.save fi The 'shorewall add' and 'shorewall delete' commands are supported with their original syntax: add [:] ... delete [:] ... In addition, the 'show dynamic' command is added that lists the dynamic content of a zone. show dynamic These commands are supported by shorewall-lite as well. 6) The generated program now attempts to detect all dynamic information when it first starts. Dynamic information includes IP addresses, default gateways, networks routed through an interface, etc. If any of those steps fail, an error message is generated and the state of the firewall is not changed. 7) To improve the readability of configuration files, Shorewall now allows leading white space in continuation lines when the continued line ends in ":" or ",". Example (/etc/shorewall/rules): #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net:\ 206.124.146.177,\ 206.124.146.178,\ 206.124.146.180\ dmz tcp 873 The leading white space on the lines that contain just an IP address is ignored so the SOURCE column effectively contains "net:206.124.146.177,206.124.147.178,206.124.146.180". 8) The generated script now uses iptables[6]-restore to instantiate the Netfilter ruleset during processing of the 'stop' command. As a consequence, the 'critical' option in /etc/shorewall/route_stopped is no longer needed and will result in a warning. 9) A new AUTOMAKE option has been added to shorewall.conf and shorewall6.conf. When set to 'Yes', this option causes new behavior during processing of the 'start' and 'restart' commands; if no files in /etc/shorewall/ (/etc/shorewall6) have changed since the last 'start' or 'restart', then the compilation step is skipped and the script used during the last 'start' or 'restart' is used to start/restart the firewall. Note that if a is specified in the start/restart command (e.g., "shorewall restart /etc/shorewall.new") then the setting of AUTOMAKE is ignored. Note that the 'make' utility must be installed on the firewall system in order for AUTOMAKE=Yes to work correctly. 10) The 'compile' command now allows you to omit the . When you do that, the defaults to /var/lib/shorewall/firewall (/var/lib/shorewall6/firewall) unless you have overridden VARDIR using /etc/shorewall/vardir (/etc/shorewall6/vardir). When combined with AUTOMAKE=Yes, it allows the following: gateway:~ # shorewall compile Compiling... Shorewall configuration compiled to /root/shorewall/firewall gateway:~ # ... gateway:~ # shorewall restart Restarting Shorewall.... done. gateway:~ # In other words, you can compile the current configuration then install it at a later time. 11) Thanks to I. Buijs, it is now possible to rate-limit connections by source IP or destination IP. The LIMIT:BURST column in /etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT column /etc/shorewall/rules (/etc/shorewall6/rules) have been extended as follows: [{s|d}:[[]:]]/{sec|min}[:] When s: is specified, the rate is per source IP address. When d: is specified, the rate is per destination IP address. The specifies the name of a hash table -- you get to choose the name. If you don't specify a name, the name 'shorewall' is assumed. Rules with the same name have their connection counts aggregated and the individual rates are applied to the aggregate. Example: ACCEPT net fw tcp 22 - - s:ssh:3/min This will limit SSH connections from net->fw to 3 per minute. ACCEPT net fw tcp 25 - - s:mail:3/min ACCEPT net fw tcp 587 - - s:mail:3/min Since the same hash table name is used in both rules, the above is equivalent to this single rule: ACCEPT net fw tcp 25,587 - - s:mail:3/min 12) Rules that specify a log level with a target other than LOG or NFLOG are now implemented through a separate chain. While this may increase the processing cost slightly for packets that match these rules, it is expected to reduce the overall cost of such rules because each packet that doesn't match the rules only has to be processed once per rule rather than twice. Example: /etc/shorewall/rules: REJECT:info loc net tcp 25 This previously generated these two rules (long rules folded): -A loc2net -p 6 --dport 25 -j LOG --log-level 6 --log-prefix "Shorewall:loc2net:reject:" -A loc2net -p 6 --dport 25 -j reject It now generates these rules: :log0 - [0:0] ... -A loc2net -p 6 --dport 25 -g log0 ... -A log0 -j LOG --log-level 6 --log-prefix "Shorewall:loc2net:REJECT:" -A log0 -j reject Notice that now there is only a single rule generated in the 'loc2net' chain where before there were two. Packets for other than TCP port 25 had to be processed by both rules. Notice also that the new LOG rule reflects the original action ("REJECT") rather than what Shorewall maps that to ("reject"). 13) Shorewall6 has now been tested on kernel 2.6.24 (Ubuntu Hardy) and hence will now start successfully when running on that kernel. 14) Three new options (IP, TC and IPSET) have been added to shorewall.conf and shorwall6.conf. These options specify the name of the executable for the 'ip', 'tc' and 'ipset' utilities respectively. If not specified, the default values are: IP=ip TC=tc IPSET=ipset In other words, the utilities will be located via the current PATH setting. 15) There has been a desire in the user community to limit traffic by IP address using Shorewall traffic shaping. Heretofore, that has required a very inefficient process: a) Define a tcclass for each internal host (two, if shaping both in and out). b) Define a tcrule for each host to mark to classify the packets accordingly. Beginning with Shorewall 4.4, this process is made easier IF YOU ARE WILLING TO INSTALL xtables-addons. The feature requires IPMARK support in iptables[6] and your kernel. That support is available in xtables-addons. Instructions for installing xtables-addons may be found at http://www.shorewall.net/Dynamic.html#xtables-addons. The new facility has two components: a) A new IPMARK MARKing command in /etc/shorewall/tcrules. b) A new 'occurs' OPTION in /etc/shorewall/tcclasses. The facility is currently only available with IPv4. In a sense, the IPMARK target is more like an IPCLASSIFY target in that the mark value is later interpreted as a class ID. A packet mark is 32 bits wide; so is a class ID. The class occupies the high-order 16 bits and the class occupies the low-order 16 bits. So the class ID 1:4ff (remember that class IDs are always in hex) is equivalent to a mark value of 0x104ff. Remember that Shorewall uses the interface number as the number where the first interface in tcdevices has number 1, the second has number 2, and so on. The IPMARK target assigns a mark to each matching packet based on the either the source or destination IP address. By default, it assigns a mark value equal to the low-order 8 bits of the source address. The syntax is as follows: IPMARK[([{src|dst}][,[][,[][,[]]]])] Default values are: src = 0xFF = 0x00 = 0 'src' and 'dst' specify whether the mark is to be based on the source or destination address respectively. The selected address is first shifted right by , then LANDed with and then LORed with . The argument is intended to be used primarily with IPv6 addresses. Example: IPMARK(src,0xff,0x10100) Destination IP address is 192.168.4.3 = 0xc0a80403 0xc0a80403 >> 0 = 0xc0a80403 0xc0a80403 LAND 0xFF = 0x03 0x03 LOR 0x10100 = 0x10103 So the mark value is 0x10103 which corresponds to class id 1:103. It is important to realize that, while class IDs are composed of a and a value, the set of values must be unique. You must keep this in mind when deciding how to map IP addresses to class IDs. For example, suppose that your internal network is 192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6). Your first notion might be to use IPMARK(src,0xFF,0x10000) so as to produce class IDs 1:1 through 1:6. But 1:1 is the class ID of the base HTB class on interface 1. So you might chose instead to use IPMARK(src,0xFF,0x10100) as shown in the example above so as to avoid minor class 1. The 'occurs' option in /etc/shorewall/tcclasses causes the class definition to be replicated many times. The synax is: occurs= When 'occurs' is used: a) The associated device may not have the 'classify' option. b) The class may not be the default class. c) The class may not have any 'tos=' options (including 'tcp-ack'). d) The class should not specify a MARK value. Any MARK value given is ignored with a warning. The 'RATE' and 'CEIL' parameters apply to each instance of the class. So the total RATE represented by an entry with 'occurs' will be the listed RATE multiplied by the 'occurs' number. Example: /etc/shorewall/tcdevices: #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH eth0 100mbit 100mbit /etc/shorewall/tcclasses: #DEVICE MARK RATE CEIL PRIORITY OPTIONS eth0:101 - 1kbit 230kbit 4 occurs=6 The above defines 6 classes with class IDs 0x101-0x106. Each class has a guaranteed rate of 1kbit/second and a ceiling of 230kbit. /etc/shoreall/tcrules: #MARK SOURCE DEST IPMARK(src,0xff,0x10100):F 192.168.1.0/29 eth0 This change also altered the way in which Shorewall generates a class number when none is given. - Prior to this change, the class number was constructed by concatinating the mark value with the either '1' or '10'. '10' was used when there were more than 10 devices defined in /etc/shorewall/tcdevices. - Beginning with this change, a new method is added; class numbers are assigned sequentially beginning with 2. The WIDE_TC_MARKS option in shorewall.conf selects which construction to use. WIDE_TC_MARKS=No (the default) produces pre-4.4 behavior. WIDE_TC_MARKS=Yes produces the new behavior. In addition to determining the method of constructing class Ids, WIDE_TC_MARKS=Yes provides for larger mark values for traffic shaping. Traffic shaping marks may have values up to 16383 (0x3fff) with WIDE_TC_MARKS=Yes. This means that when both WIDE_TC_MARKS=Yes and HIGH_ROUTE_MARKS=Yes, routing marks (/etc/shorewall/providers MARK column) must be >= 65536 (0x10000) and must be a multiple of 65536 (0x1000, 0x20000, 0x30000, ...). 16) In the 'shorewall compile' and 'shorewall6 compile' commands, the filename '-' now causes the compiled script to be written to Standard Out. As a side effect, the effective VERBOSITY is set to -1 (silent). Examples: shorewall compile -- - # Compile the configuration in # /etc/shorewall and send the # output to STDOUT shorewall compile . - # Compile the configuration in the # current working directory # and send the output to STDOUT 17) Supplying an interface name in the SOURCE column of /etc/shorewall/masq is now deprecated. Entering the name of an interface there will result in a compile-time warning (see the Migration Considerations above). 18) Shorewall now supports nested HTB traffic shaping classes. The nested classes within a class can borrow from their parent class in the same way as the first level classes can borrow from the root class. To use nested classes, you must explicitly number your classes. That does not imply that you must use the 'classify' option. Example: /etc/shorewall/tcdevices #INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS eth2 - 100mbps classify /etc/shorewall/tcclasses #INTERFACE MARK RATE CEIL PRIORITY OPTIONS 1:10 - full/2 full 1 1:100 - 16mbit 20mbit 2 1:100:101 - 8mbit 20mbit 3 default 1:100:102 - 8mbit 20mbit 3 /etc/shorewall/tcrules #MARK SOURCE DEST 1:102 0.0.0.0/0 eth2:172.20.1.107 1:10 206.124.146.177 eth2 1:10 172.20.1.254 eth2 The above controls download for internal interface eth2. The external interface has a download rate of 20mbit so we guarantee that to class 1:100. 1:100 has two subclasses, each of which is guaranteed half of their parent's bandwidth. Local traffic (that coming from the firewall and from the DMZ server) is placed in the effectively unrestricted class 1:10. The default class is guaranteed half of the download capacity and my work system (172.20.1.107) is guarandeed the other half. 19) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing discipline has been added. HFSC is claimed to be superior to the "Hierarchical Token Bucket" queuing discipline where realtime traffic such as VOIP is being used. An excellent overview of HFSC on Linux may be found at http://linux-ip.net/articles/hfsc.en/. To use HFSC, several changes need to be made to your traffic shaping configuration: - To use HFSC on an interface rather than HTB, specify the 'hfsc' option in the OPTIONS column in the interfaces's entry in /etc/shorewall/tcdevices. - Modify the RATE colum for each 'leaf' class (class with no parent class specified) defined for the interface. When using HFSC, the RATE column may specify 1, 2 or 3 pieces of information separated by colons (":"). 1. The Guaranteed bandwidth (as always). 2. The Maximum delay (DMAX) that the first queued packet in the class should experience. The delay is expressed in milliseconds and may be followed by 'ms' (e.g., 10ms. Note that there may be no white space between the number and 'ms'). 3. The maximum transmission unit (UMAX) for this class of traffic. If not specified, the MTU of the interface is used. The length is specified in bytes and may be followed by 'b' (e.g., 800b. Note that there may be no white space between the number and 'b'). DMAX should be specified for each leaf class. The Shorewall compiler will issue a warning if DMAX is omitted. Example: full/2:10ms:1500b Guaranteed bandwidth is 1/2 of the devices OUT-BANDWIDTH. Maximum delay is 10ms. Maximum packet size is 1500 bytes. 20) Optional TOS and LENGTH fields have been added to the tcfilters file. The TOS field may contain any of the following: tos-minimize-delay tos-maximuze-throughput tos-maximize-reliability tos-minimize-cost tos-normal-service Hex-number Hex-number/Hex-number The hex numbers must have exactly two digits. The LENGTH value must be a numeric power of two between 32 and 8192 inclusive. Packets with a total length that is strictly less that the specified value will match the rule. 21) Support for 'norfc1918' has been removed. See the Migration Considerations above. 22) A 'upnpclient' option has been added to /etc/shorewall/interfaces. This option is intended for laptop users who always run Shorewall on their system yet need to run UPnP-enabled client apps such as Transmission (BitTorrent client). The option causes Shorewall to detect the default gateway through the interface and to accept UDP packets from that gateway. Note that, like all aspects of UPnP, this is a security hole so use this option at your own risk. 23) 'iptrace' and 'noiptrace' commands have been added to both /sbin/shorewall and /sbin/shorewall6. These are low-level debugging commands that cause iptables/ip6tables TRACE log messages to be generated. See 'man iptables' and 'man ip6tables' for details. The syntax for the commands is: iptrace noiptrace iptrace starts the trace; noiptrace turns it off. The match expression must be an expression that is legal in both the raw table OUTPUT and PREROUTING chains. Examaple: To trace all packets destinted for IP address 206.124.146.176: shorewall iptrace -d 206.124.146.176 To turn that trace off: shorewall noiptrace -d 206.124.146.176 24) A USER/GROUP column has been added to /etc/shorewall/masq. The column works similarly to USER/GROUP columns in other Shorewall configuration files. Only locally-generated traffic is matched. 25) A new extension script, 'lib.private' has been added. This file is intended to include declarations of shell functions that will be called by the other run-time extension scripts. 26) Paul Gear has contributed the following macros: macro.Webcache (originally named macro.DG) macro.IPPbrd macro.NTPbi macro.RIPbi macro.mDNS 27) The default value of DISABLE_IPV6 has been changed from 'Yes' to 'No' in all sample shorewall.conf files. Shorewall6 should be installed to restrict IPv6 traffic. As part of this change, the ip6tables program in the directory specified by the IPTABLES setting will be used to disable IPv6. If the iptables utility is discovered using the PATH setting, then ip6tables in the same directory as the discovered iptables will be used.