From 1368e5a30ea18d5d00c102723791e35570c47e64 Mon Sep 17 00:00:00 2001 From: teastep Date: Wed, 17 Dec 2008 21:06:30 +0000 Subject: [PATCH] Merge 4.3 and 4.2 changelog and release notes git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9100 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-common/changelog.txt | 94 ++- Shorewall-common/releasenotes.txt | 1228 +++++++++++++++++++++++++++-- 2 files changed, 1214 insertions(+), 108 deletions(-) diff --git a/Shorewall-common/changelog.txt b/Shorewall-common/changelog.txt index 0a4f8621f..64b750665 100644 --- a/Shorewall-common/changelog.txt +++ b/Shorewall-common/changelog.txt @@ -1,54 +1,8 @@ -Changes in Shorewall 4.3.4 +Changes in Shorewall 4.2.4-RC1 -1) Fix extra 'done'. +1) Merge changes from 4.3.3 -- IPv6 support. -2) Fix IPv6 range checking. - -3) Improve chain-combining optimizations. - -4) Make connection and log displays address family specific. - -Changes in Shorewall 4.3.3 - -1) Removed 'ecn'. - -2) Enabled 'maclist'. - -3) Enabled Traffic Shaping - -4) Convert AllowICMPs to a builtin action. - -5) Use <> rather than []. - -6) Remove duplicated macros. - -7) Add 'proxyndp' interface option. - -8) Add RFC 2526 anycast addresses to nosmurfs - -9) Add man pages for Shorewall6 and 6 Lite. - -10) Fix IP6TABLES when not specified. - -Changes in Shorewall 4.3.2 - -1) Added 'dhcp' option. - -2) Add 'allowBcast' and 'dropBcast' builtin actions to Shorewall6. - -3) Enable multi-ISP in Shorewall6. - -Changes in Shorewall 4.3.1 - -1) Allow addresses in rules to be enclosed in square brackets. - -2) Fix parsing of 6 hosts file. - -3) Don't require Socket6 unless doing IPv6 DNS name resolution. - -4) Add IP_FORWARDING to shorewall6.conf. - -Changes in Shorewall 4.3.0 +Changes in Shorewall 4.2.3 1) Verify User/Group names. @@ -69,5 +23,45 @@ Changes in Shorewall 4.3.0 9) Allow ressetting individual chains. -10) IPv6 Alpha release. +10) Correct faulty optimization. +Changes in Shorewall 4.2.2 + +1) Insure that lines copied from a user file are newline-terminated. + +2) Added macro.JAP. + +3) Added macro.DAAP. + +4) Added macro.DCC. + +5) Added macro.GNUnet. + +6) Prevent invalid rules when KLUDGEFREE is not set. + +7) Separated detection of old conntrack syntax from new conntrack + feature detection. + +8) Fix nonat rules with destination IP address. + +9) Correct NEW_CONNTRACK_MATCH with server port but no dest port. + +Changes in Shorewall 4.2.1 + +1) Added CONNBYTES to tcrules manpage. Flesh out description of HELPER. + +2) Fixed minor CONNBYTES editing issue. + +3) Add CONNLIMIT to policy and rules. + +4) Allow use of iptables-1.4.1. + +5) Add time match support. + +6) Applied Lennart Sorensen's patch for length match. + +7) Take advantage of --ctorigdstport + +8) Fix syntax error in 'export' + +Initial release of Shorewall 4.2.0. diff --git a/Shorewall-common/releasenotes.txt b/Shorewall-common/releasenotes.txt index 68bc0e1c6..fcff5feb2 100644 --- a/Shorewall-common/releasenotes.txt +++ b/Shorewall-common/releasenotes.txt @@ -1,22 +1,24 @@ -Shorewall 4.3.4 - -Notice: - -It was previously my intention to defer release of IPv6 support until -4.4. That plan was based on an architecture that supported a single -configuration for both IPv4 and IPv6. - -Splitting IPv6 support out into separate products has made adding that -support an order of magnitude easier and less invasive. So it is my -current plan to release IPv6 support in a future 4.2.x release. - -I am therefore opening the testing of the development branch to a wider -audience. +Shorewall 4.2.4-RC1 ---------------------------------------------------------------------------- - R E L E A S E 4 . 3 H I G H L I G H T S + R E L E A S E 4 . 2 H I G H L I G H T S ---------------------------------------------------------------------------- -1) Support is included for IPv6. +1) Support is included for multiple internet providers through the same + ethernet interface. + +2) Support for NFLOG has been added. + +3) Enhanced operational logging. + +4) The tarball installers now work under Cygwin. + +5) Shorewall-perl now supports IFB devices which allow traffic shaping of + incoming traffic. + +6) Shorewall-perl supports definition of u32 traffic classification + filters. + +7) Support for IPv6 is available beginning with Shorewall 4.2.4. Minimun system requirements: @@ -25,48 +27,7 @@ audience. - Perl 5.10 if you wish to use DNS names in your IPv6 config files. In that case you will also have to install Perl Socket6 support. -Problems Corrected in 4.3.4 - -1) Previously, an extra 'done' could be emitted in the generated shell - script resulting in a shell syntax error at run-time. - -2) In IPv6, ipranges were previously not supported even when the - kernel and ip6tables included support for them. - -3) An optimization in all Shorewall-perl 4.2 and 4.3 versions could - cause undesirable side effects. The optimization deleted the - _in and _fwd chains and moved their rules - to the appropriate rules chain (a 2 chain). - - This worked badly in cases where a zone was associated with more - than one interface. Rules could be duplicated or, worse, a rule - that was intended for only input from one of the zone's interfaces - would be applied to input from all of the zone's interfaces. - - This problem has been corrected so that an interface-related - chains is only deleted if: - - a) the chain has no rules in it; or - b) the interface is associated with only one zone and that zone is - associated with only that interface in which case it is safe to - move the rules. - -Other Changes in 4.3.4 - -1) Shorewall and Shorewall Lite now show only IPv4 connections in the - output of 'shorewall show connections', 'shorewall-lite show - connections', 'shorewall dump' and 'shorewall-lite dump'. - -2) The Shorewall and Shorewall lite commands that show log messages - ('shorewall show log', ...) now show only IPv4 messages. The - corresponding commands in Shorewall6 and Shorewall6 Lite only show - IPv6 messages. - -Migration Issues. - - None. - -New Features in Shorewall 4.3 +New Features in Shorewall 4.2.4. 1) Two new packages are included: @@ -84,6 +45,9 @@ New Features in Shorewall 4.3 way that Netfilter does). Starting/Stopping the firewall for one address family has no effect on the other address family. + For additional information, see + http://www.shorewall.net/IPV6Support.html. + Other features of Shorewall6 are: a) There is no NAT of any kind (most people see this as a giant step @@ -157,3 +121,1151 @@ New Features in Shorewall 4.3 Checking /etc/shorewall6/rules... Can't locate Socket6.pm in @INC (@INC contains: /root ... teastep@ursa:~/Configs/standalone6$ + +Migration Issues. + +1) Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero + mark values < 256 to be assigned in the OUTPUT chain. This has been + changed so that only high mark values may be assigned + there. Packet marking rules for traffic shaping of packets + originating on the firewall must be coded in the POSTROUTING table. + +2) Previously, Shorewall did not range-check the value of the + VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2: + + a) A VERBOSITY setting outside the range -1 through 2 is rejected. + b) After the -v and -q options are applied, the resulting value is + adjusted to fall within the range -1 through 2. + +3) Specifying a destination zone in a NAT-only rule now generates a + warning and the destination zone is ignored. NAT-only rules are: + + NONAT + REDIRECT- + DNAT- + +4) The default value for LOG_MARTIANS has been changed. Previously, + the defaults were: + + Shorewall-perl - 'Off' + Shorewall-shell - 'No' + + The new default values are: + + Shorewall-perl - 'On' + Shorewall-shell - 'Yes'. + + Shorewall-perl users may: + + a) Accept the new default -- martians will be logged from all + interfaces with route filtering except those with log_martians=0 + in /etc/shorewall/interfaces. + + b) Explicitly set LOG_MARTIANS=Off to maintain compatibility with + prior versions of Shorewall. + + Shorewall-shell users may: + + a) Accept the new default -- martians will be logged from all + interfaces with the route filtering enabled. + + b) Explicitly set LOG_MARTIONS=No to maintain compatibility with + prior versions of Shorewall. + +5) The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has + been changed from Yes to No. + +6) The 'norfc1918' option is deprecated. Use explicit rules instead. + Note that there is a new 'Rfc1918' macro that acts on addresses + reserved by RFC 1918. + +7) DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use + ipset-based zones instead. + +New Features in Shorewall 4.2 + +1) Shorewall 4.2 contains support for multiple Internet providers + through a single ethernet interface. Configuring two providers + through a single interface differs from two providers through two + interfaces in several ways. + + a) Only ethernet (or ethernet-like) interfaces can be used. For + inbound traffic, the MAC addresses of the gateway routers is used + to determine which provider a packet was received through. Note + that only routed traffic can be categorized using this technique. + + b) You must specify the address on the interface that corresponds to + a particular provider in the INTERFACE column by following the + interface name with a colon (":") and the address. + + c) Entries in /etc/shorewall/masq must be qualified by the provider + name (or number). + + d) This feature requires Realm Match support in your kernel and + iptables. If you use a capabilities file, you need to regenerate + the file with Shorewall 4.2 or Shorewall-lite 4.2. + + e) You must add route_rules entries for networks that are accessed + through a particular provider. + + f) If you have additional IP addresses through either provider, + you must add route_rules to direct traffic FROM each of those + addresses through the appropriate provider. + + g) You must add MARK rules for any traffic that you know originates + from a particular provider. + + Example: + + Providers Blarg (1) and Avvanta (2) are both connected to + eth0. The firewall's IP address with Blarg is 206.124.146.176/24 + (gateway 206.124.146.254) and the IP address from Avvanta is + 130.252.144.8/24 (gateway 130.252.144.254). We have a second IP + address (206.124.146.177) from Blarg. + + /etc/shorewall/providers: + + #PROVIDER NUMBER MARK DUPLICATE INTERFACE GATEWAY + Blarg 1 1 main eth0:206.124.146.176 206.124.146.254 ... + Avvanta 2 2 main eth0:130.252.144.8 130.252.144.254 ... + + /etc/shorewall/masq: + + #INTERFACE SOURCE ADDRESS + eth0(Blarg) 130.252.144.8 206.124.146.176 + eth0(Avvanta) 206.124.146.176 130.252.144.8 + eth0(Blarg) eth1 206.124.146.176 + eth0(Avvanta) eth1 130.252.144.8 + + /etc/shorewall/route_rules: + + #SOURCE DEST PROVIDER PRIORITY + - 206.124.146.0/24 Blarg 1000 + - 130.252.144.0/24 Avvanta 1000 + 206.124.146.177 - Blarg 26000 + + /etc/shorewall/tcrules + + #MARK/CLASSIFY SOURCE DEST + 1 eth0:206.124.146.0/24 0.0.0.0/0 + 2 eth0:130.242.144.0/24 0.0.0.0/0 + +2) You may now include the name of a table (nat, mangle or filter) in + a 'shorewall refresh' command by following the table name with a + colon (e.g., mangle:). This causes all non-builtin chains in the + 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.2 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.2 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.2: + + a) A VERBOSITY setting outside the range -1 through 2 is rejected. + b) After the -v and -q options are applied, the resulting value is + adjusted to fall within the range -1 through 2. + +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.2, 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. + +36) 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'. + +37) 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. + +38) 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. + +39) A 'save' extension script is added. The script is run after + iptables-save has completed successfully. + + The 'load' and 'reload' commands copy the save script (if any) to + /etc/shorewall-lite/ on the remove firewall system. The 'export' + command copies the file to the same directory as the 'firewall' and + 'firewall.conf' scripts. + + I have the following commands in my 'save' script: + + [ -s /root/ipsets.save ] && cp -a /root/ipsets.save /root/ipsets.save.backup + ipset -S > /root/ipsets.save + + These commands complement my 'init' script: + + qt modprobe ifb numifbs=1 + qt ip link set dev ifb0 up + + if [ "$COMMAND" = start ]; then + ipset -U :all: :all: + ipset -U :all: :default: + ipset -F + ipset -X + ipset -R < /root/ipsets.save + fi + + Those two scripts allow me to save and restore the contents of my + ipsets automatically under Shorewall-perl/Shorewall-lite (my + routestopped file does not use ipsets). + +40) A HELPER column is included in the tcrules file. The value in this + column names one of the Netfilter protocol 'helper' module sets + (ftp, sip, amanda, etc). + + See http://www.shorewall.net/traffic_shaping.htm for an example. + +41) DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. + +42) Farkas Levante has contributed a macro.Mail macro that covers SMTP, + SMTPS and submission. + +43) Beginning with Shorewall 4.0.0, the -f option was no longer the + default for '/etc/init.d/shorewall start'. Beginning with 4.0.13 + and 4.2.0-Beta3, this is also true for Shoreawall-lite. + +44) A new USE_DEFAULT_RT option has been added to shorewall.conf. When + set to 'Yes', it causes the Shorewall multi-ISP feature to create + a different set of routing rules which are resilient to changes in + the main routing table. Such changes can occur for a number of + reasons, VPNs going up and down being an example. + + The idea is to send packets through the main table prior to + applying any of the Shorewall-generated routing rules. So changes + to the main table will affect the routing of packets by default. + + When USE_DEFAULT_RT=Yes: + + a) Both the DUPLICATE and the COPY columns in the providers file + must remain empty (or contain "-"). + + b) The default route is added to the the 'default' table rather + than to the main table. + + c) 'balance' is assumed unless 'loose' is specified. + + d) Packets are sent through the main routing table by a rule with + priority 999. In /etc/shorewall/routing_rules, the range 1-998 + may be used for inserting rules that bypass the main table. + + e) All provider gateways must be specified explicitly in the + GATEWAY column. 'detect' may not be specified. + + f) You should disable all default route management outside of + Shorewall. If a default route is added to the main table while + Shorewall is started, then all policy routing will stop working + (except for those routing rules in the priority range 1-998). + +45) The 'shorewall restart' command now supports an -f option. When + this option is specified, no compilation occurs; rather, the script + which last started or restarted Shorewall is used. + +46) A macro supporting RNDC (BIND remote management protocol) traffic + has been added. It can be used as any other macro (e.g., RNDC/ACCEPT) + in the rules file. + +47) If 'NONAT' is specified in the ADDRESS column of an entry in + /etc/shorewall/masq, then traffic matching that entry is not + passed to the entries that follow. + +New Features added in Shorewall 4.2.1 + +1) With the recent renewed interest in DOS attacks, it seems + appropriate to have connection limiting support in Shorewall. To + that end, a CONNLIMIT column has been added to both the policy and + rules files. + + The content of these columns is of the format + + [!] [:] + + where + + is the limit on simultaneous TCP connections. + + specifies the size of the network to which + the limit applies and is specified as a + CIDR mask length. The default value for + is 32 which means that each remote + IP address can have TCP connections + active at once. + + ! Not allowed in the policy file. In the rules file, it + causes connections to match when the number of + current connections exceeds . + + When specified in the policy file, the limit is enforced on all + connections that are subject to the given policy (just like + LIMIT:BURST). The limit is checked on new connections before the + connection is passed through the rules in the NEW section of the + rules file. + + It is important to note that while the limit is only checked for + those destinations specified in the DEST column, the number of + current connections is calculated over all destinations and not + just the destination specified in the DEST column. + + Use of this feature requires the connlimit match capability in your + kernel and iptables. If you use a capabilities file when compiling + your Shorewall configuration(s), then you need to regenerate the + file using Shorewall or Shorewall-lite 4.2.1. + +2) Shorewall now supports time/date restrictions on entries in the + rules file via a new TIME column. + + The contents of this column is a series of one or more "time + elements" separated by apersands ("&"). Possible time elements are: + + utc Times are expressed in Greenwich Mean Time. + localtz Times are expressed in local civil time (default) + timestart=hh:mm[:ss] + timestop=hh:mm[:ss] Start and stop time of day for rule + weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or + Sun + monthdays=dd[,dd]... where dd is an ordinal day of the month. + datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]] + datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]] + where yyyy = Year + first mm = Month + dd = Day + hh = Hour + 2nd mm = Minute + ss = Second + + Examples: + + 1) utc×tart=10:00×top=12:00 + + Between 10am and 12 noon each day, GMT + + 2) datestart=2008-11-01T12:00 + + Beginning November 1, 2008 at noon LCT. + + Use of this feature requires the time match capability in your + kernel and iptables. If you use a capabilities file when compiling + your Shorewall configuration(s), then you need to regenerate the + file using Shorewall or Shorewall-lite 4.2.1. + +3) If your kernel and iptables support "-m conntrack --ctorigdstport" + then Shorewall will utilize that capability to ensure that when you + do port mapping (change the destination port but not the + destination IP address), the final destination port is not opened + as a side effect. + + Example: + + DNAT net loc:206.124.146.177:22 tcp 2222 - 206.124.146.177 + + That rule maps port 2222 -> 22 but without this new feature, it + also opens port 22 directly. + + To use this feature, you must be running Shorewall-perl and the + output of 'shorewall show capabilities' must show: + + Extended Connection Tracking Match Support: Available + +New Featurs in Shorewall 4.2.2 + +1) A macro supporting JAP (anonymization protocol) has been added. + It can be used as any other macro (e.g., JAP/ACCEPT) in the rules + file. + +2) A macro supporting DAAP (Digital Audio Access Protocol) has been added. + It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules + file. + +3) A macro supporting DCC (Distributed Checksum Clearinghouse) has been + added. It can be used as any other macro (e.g., DCCP/ACCEPT) in the + rules file. + +4) A macro supporting GNUnet (secure peer-to-peer networking) has been + added. It can be used as any other macro (e.g., GNUnet/ACCEPT) in the + rules file. + +5) In 4.2.1, a single capability ("Extended conntrack match support") + was used both to control the use of --ctorigport and to trigger use + of the new syntax for inversion of --ctorigdst (e.g., "! + --ctorigdst ..."). In 4.2.2, these are controlled by two separate + capabilities. If you use a capabilities file when compiling your + configuration, be sure to generate a new one after installing + 4.2.2. + +Problems corrected in Shorewall 4.2.1 + +1) A description of the CONNBYTES column has been added to + shorewall-tcrules(5). + +2) Previously, Shorewall-perl would accept zero as the value in + the CONNBYTES column of tcrules even when the field was + non-zero. A value of zero for was equivalent to omitting + . + +3) iptables 1.4.1 discontinued support of syntax generated by + shorewall in some cases. Shorewall now detects when the new syntax + is required and uses it instead. + +4) The Shorewall-perl implementation of the LENGTH column in + /etc/shorewall/tcrules was incomplete with the result that + all LENGTH rules matched. Thanks to Lennart Sorensen for the patch. + +5) The 'export' command no longer fails with the error: + + /sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi") + +Problems corrected in Shorewall 4.2.2 + +1) Shorewall-perl now insures that each line copied from a + configuration file or user exit is terminated with a newline + character. + +2) When ipranges were used to define zones, Shorewall-perl could + generate invalid iptables-restore input if 'Repeat Match' was not + available. Repeat Match is not a true match -- it rather is a + feature of recent iptables releases that allows a match to be + repeated within a rule. + +3) With Shorewall-perl, if a destination port list had exactly 16 + ports, where a port-range counts as two ports, then Shorewall-perl + would fail to split the rule into multiple rules and an + iptables-restore error would result. + +4) The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1 + compatibility contained a typo that prevented it from working + correctly. + +5) If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP + address and no zone name in the DEST column, Shorewall-perl would + reject the rule. If a zone name was specified, Shorewall-perl + would issue a Warning message. + +Problems corrected in Shorewall 4.2.3 + +1) Previously, Shorewall would allow compilation for export of a + script named 'shorewall' with the unfortunate side effect that + the 'shorewall.conf' file was overwritten. Scripts named + 'shorewall' now cause a fatal error to be raised. + +2) Previously, Shorewall-perl attempted to do Shell variable + substitution on the first line in /etc/shorewall/compile. + +3) Following the Netfilter tradition, the IPP2P maintainer has made an + incompatible syntax change (the --ipp2p option has been + removed). Shorewall has always used "-m ipp2p --ipp2p" when + detecting the presence of IPP2P support. + + Shorewall-common and Shorewall-perl have been modified to use + "-m ipp2p --edk" instead. + +4) When Extended Conntrack Match support was available, Shorewall-perl + would create invalid iptables-restore input for certain DNAT rules. + +5) An optimization in all Shorewall-perl 4.2 versions could cause + undesirable side effects. The optimization deleted the + _in and _fwd chains and moved their rules + to the appropriate rules chain (a 2 chain). + + This worked badly in cases where a zone was associated with more + than one interface. Rules could be duplicated or, worse, a rule + that was intended for only input from one of the interfaces would + be applied to input from all of the zone's interfaces. + + This problem has been corrected so that an interface-related + chains is only deleted if: + + a) the chain has no rules in it; or + b) the interface is associated with only one zone and that zone is + associated with only that interface in which case it is safe to + move the rules. + +Other changes in Shorewall 4.2.3 + +1) Except with the -e option is specified, the Shorewall-perl compiler + now verifies user/group names appearing in the USER/GROUP column of + the rules file. + +2) The output of 'shorewall dump' now includes the output from + 'netstat -tunap'. + +3) Shorewall-perl now accepts '+' as an interface name in + /etc/shorewall/interfaces. That name matches any interface and is + useful for defining a zone that will match any interface that might + be added after Shorewall is started. + + A couple of words of caution are in order. + + a) Because '+' matches any interface name, Shorewall cannot + verify interface names appearing in other files when '+' is + defined in /etc/shorewall/interfaces. + + b) The zone assigned to '+' must be the last one defined in + /etc/shorewall/zones. + +4) Shorewall-perl now uses the iptables --goto parameter in obvious + cases. + +5) The 'reset' command now allows you to reset the packet and byte + counter on individual chains: + + shorewall reset chain1 chain2 ... + shorewall-lite reset chain1 chain2 ...