CATEGORIES
Net Servers Services
Firewall & Proxy Servers
Current Highlights
Follow us on Facebook
 
5 stars award

Shorewall 4.4.27.3

Advertisements

Shorewall is a gateway/firewall configuration tool for GNU/Linux.
The Shoreline Firewall, more commonly known as “Shorewall”, is high-level tool for configuring Netfilter.
Shorewall is not a daemon.
Shorewall is not the easiest to use of the available iptables configuration tools but I believe that it is the most flexible and powerful.

User's rating:

  • Currently 2.64/5
  • 1
  • 2
  • 3
  • 4
  • 5

Download alternate Shorewall solution

Look at the free or trial alternatives and similar apps to Shorewall software by the tags. It's possible also to find substitutes for the most popular titles in the Net Servers Services category.

| Shorewall | Shoreline Firewall | Configuration Tool |

History updates (Complete changelogs since the listing on this site)

4.4.27.3 [01-25-12]

1) Up to this point, Shorewall has had a lot of very similar files in multiple products. Beginning with this release, the following files are identical. - /sbin/shorewall - /sbin/shorewall6 - /sbin/shorewall-lite - /sbin/shorewall6-lite The program uses it's own file name to determine which role it is to assume. It does that by initializing variables that are later used within the various libraries. Shorewall and Shorewall6 share use of /usr/share/shorewall/lib.base /usr/share/shorewall/lib.cli, and /usr/share/shorewall/lib.common. /usr/share/shorewall6/lib.base is a small file that sets variables and then sources /usr/share/shorewall/lib.base. As before, shorewall and shorewall-lite share the same libraries as do shorewall6 and shorwall6-lite. Shorewall includes a new library: /usr/share/shorewall/lib.cli-std. /usr/share/shorewall[6]/lib.cli contains everything needed by the Lite products. 2) Shorewall now supports the CT target in the Netfilter 'raw' table. See 'man shorewall-notrack' for details. The main use of this target is described in this paper: http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf. The paper a product of the vulnerability described in the 4.4.20 release note which introduced the 'sfilter' facility. In the paper, rules such as the following are recommended: iptables -A PREROUTING -t raw -p tcp --dport 2121 -d 1.2.3.4 -j CT --helper ftp The equivalent entry in /etc/shorewall/notrack would be: #ACTION SOURCE DEST PROTO DEST # PORT(S) CT:helper:ftp 1.2.3.4 - tcp 2121 As part of this change, Shorewall now verifies the helper name in the HELPER column of the tcrules and tcpri files. 3) The above-referenced paper also advocates careful control of RELATED rules. To allow such control, two new options have been introduced in shorewall[6].conf: - RELATED_DISPOSITION May be ACCEPT, A_ACCEPT, A_DROP, A_REJECT, DROP or REJECT. For compatibility with earlier releases, the default is ACCEPT. match any rule in the RELATED section of the rules file. - RELATED_LOG_LEVEL Specifies a level for logging related packets. Default is empty which means that no logging occurs. 4) The options in shorewall.conf (shorewall6.conf) may now be used as shell variables in other configuration files. 5) A new option, USE_PHYSICAL_NAMES, has been added to shorewall.conf and shorewall6.conf. Normally, when the rules compiler creates a Netfilter chain that relates to an interface, the logical name of the interface is used as the base for the chain name. For example, if an interface has logical name OAKLAND and physical name eth0, then the primary chain for input arriving on that interface is normally 'OAKLAND_in'. When USE_PHYSICAL_NAMES=Yes, the name would be 'eth0_in'. 6) CLASSIFY entries in tcrules may now be placed in the FORWARD or PREROUTING chain by following the class Id with :F or :P respectively.

Other versions : 4.4.27 4.4.26.1 4.4.25.2 4.4.25.1 4.4.24 4.4.23.1 4.4.23 4.4.22.3 4.4.22 4.4.21 4.4.20.3 4.4.19.4 4.4.19.1 4.4.19 4.4.18.2

v4.4.27 [01-03-12]

1) Up to this point, Shorewall has had a lot of very similar files in multiple products. Beginning with this release, the following files are identical. - /sbin/shorewall - /sbin/shorewall6 - /sbin/shorewall-lite - /sbin/shorewall6-lite The program uses it's own file name to determine which role it is to assume. It does that by initializing variables that are later used within the various libraries. Shorewall and Shorewall6 share use of /usr/share/shorewall/lib.base /usr/share/shorewall/lib.cli, and /usr/share/shorewall/lib.common. /usr/share/shorewall6/lib.base is a small file that sets variables and then sources /usr/share/shorewall/lib.base. As before, shorewall and shorewall-lite share the same libraries as do shorewall6 and shorwall6-lite. Shorewall includes a new library: /usr/share/shorewall/lib.cli-std. /usr/share/shorewall[6]/lib.cli contains everything needed by the Lite products. 2) Shorewall now supports the CT target in the Netfilter 'raw' table. See 'man shorewall-notrack' for details. The main use of this target is described in this paper: http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf. The paper a product of the vulnerability described in the 4.4.20 release note which introduced the 'sfilter' facility. In the paper, rules such as the following are recommended: iptables -A PREROUTING -t raw -p tcp --dport 2121 -d 1.2.3.4 -j CT --helper ftp The equivalent entry in /etc/shorewall/notrack would be: #ACTION SOURCE DEST PROTO DEST # PORT(S) CT:helper:ftp 1.2.3.4 - tcp 2121 As part of this change, Shorewall now verifies the helper name in the HELPER column of the tcrules and tcpri files. 3) The above-referenced paper also advocates careful control of RELATED rules. To allow such control, two new options have been introduced in shorewall[6].conf: - RELATED_DISPOSITION May be ACCEPT, A_ACCEPT, A_DROP, A_REJECT, DROP or REJECT. For compatibility with earlier releases, the default is ACCEPT. match any rule in the RELATED section of the rules file. - RELATED_LOG_LEVEL Specifies a level for logging related packets. Default is empty which means that no logging occurs. 4) The options in shorewall.conf (shorewall6.conf) may now be used as shell variables in other configuration files. 5) A new option, USE_PHYSICAL_NAMES, has been added to shorewall.conf and shorewall6.conf. Normally, when the rules compiler creates a Netfilter chain that relates to an interface, the logical name of the interface is used as the base for the chain name. For example, if an interface has logical name OAKLAND and physical name eth0, then the primary chain for input arriving on that interface is normally 'OAKLAND_in'. When USE_PHYSICAL_NAMES=Yes, the name would be 'eth0_in'. 6) CLASSIFY entries in tcrules may now be placed in the FORWARD or PREROUTING chain by following the class Id with :F or :P respectively.

v4.4.26.1 [12-23-11]

1) A new 'blrules' file has been added as an alternative to rules in the BLACKLIST section of the rules file. When rules are present in both the blrules file and in the BLACKLIST section, those in blrules are processed first. 2) A '-b' option has been added to the 'update' command. In addition to updating the shorewall.conf file (shorewall6.conf), this option causes the compiler to convert your current legacy blacklist configuration to use the new blrules file. Changes include: a) blrules is populated with entries equivalent to your existing blacklist file. b) Your existing blacklist file is renamed blacklist.bak. c) The 'blacklist' keyword is removed from your zones, interfaces and hosts files. When one of these files is modified, the unmodified original is saved in a .bak file. As part of this change, the 'blacklog' target is permitted in the blrules file when BLACKLIST_LOG_LEVEL is specified in shorewall.conf (shorewall6.conf). It logs the packet at the specified level, then disposes of it based on the setting of BLACKLIST_DISPOSITION. 3) The Debian init files (with the exception of Shorewall-init) now support the 'status' command. 4) This release formalizes the feature that has long been documented at http://www.shorewall.net/PacketMarking.html#Values. The WIDE_TC_MARKS and HIGH_ROUTE_MARKS options have traditionally been used to define the various fields in a packet/connection mark. But more flexible control is provided using these options. TC_BITS The number of bits at the least-significant end of the mark to be used for traffic shaping marking. May be zero. PROVIDER_BITS The number of bits in the mark to be used for provider marks. May be zero. PROVIDER_OFFSET The offset from the right (low-order end) of the provider number field. If non-zero, must be >= TC_BITS. Shorewall automatically adjusts PROVIDER OFFSETs value to inforce this restriction. May be zero, in which case the TC mark field and Provider mark field overlay. MASK_BITS The number of low-order bits to be masked when clearing the traffic shaping mark. Must be >= TC_BITS and 0). Beginning with Shorewall 4.4.12, the field between MASK_BITS and PROVIDER_OFFSET can be used for any purpose you want. Beginning with Shorewall 4.4.13, the first unused bit from the right is used by Shorewall as an 'exclusion mark' which allows exclusion in CONTINUE, NONAT and ACCEPT+ rules. It is actually the values of the above four options that determine how Packet/Connection Marks are layed out. Their default values are derived from the settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS as shown in the table at http://www.shorewall.net/PacketMarking.html#Values. The 'shorewall update' ('shorewall6 update') command will supply values for these options based on the settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS. The 'shorewall show marks' ('shorewall6 show marks') command shows the range of each field in both decimal and hex. Example (TC_BITS=0, MASK_BITS=0, PROVIDER_BITS=2, PROVIDER_OFFSET=16, ZONE_BITS=4): Shorewall 4.4.26 - Mark Layout at gw - Sun Nov 20 2:08:23 PST 2011 Traffic Shaping: Not Enabled User:1-65535 (0x1-0xffff) mask 0xffff Provider:65536-196608 (0x10000-0x30000) mask 0x30000 Zone:262144-3932160 (0x40000-0x3c0000) mask 0x3c0000 Exclusion:4194304 mask 0x400000 As of this release WIDE_TC_MARKS and HIGH_ROUTE_MARKS are deprecated. 5) This release introduces limited support for using back-to-back veth devices to access a bridge. Consider this setup: -- eth1 (zone1) / WAN ---- eth0 veth0 veth1-- br0 --- eth2 (zone2) -- eth3 (zone3) In this configuration, it is veth0 that has an IP address; the bridge does not. Because veth1 is a port on br0, Netfilter allows filtering between that interface and each of the other ports. All connections from the firewall (fw) and the WAN ((net) enter the bridge through veth1. All traffic from zone1-zone3 enter the routing firewall through veth0. Note that, in this configuration, packets between zones1-zone3 and the rest of the world go through Netfilter twice. Assume that we associate veth0 with an ip zone called 'bridge' and veth1 with a bport zone called 'portal'. Then the two traversals of Netfilter are: a) Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the destination zone is 'portal'. b) Between veth0 and the final destination. The source zone is bridge and the destination zone is either fw or net. A similar scenario occurs with traffic originating in the net or firewall zones and destined for zone1-zone3. As you can see, the problem here is that in the first traversal, we know the real source zone but not the real destination zone; and in the second traversal, we know the real destination zone but not the real source zone. The solution allows us to know the real source zone during the second traversal. A new ZONE_BITS option is added to shorewall.conf (shorewall6.conf). Its value determines the number of bits of the packet mark to use for zone marks. When ZONE_BITS is non-zero, Shorewall automatically assigns a mark value to each zone (the firewall zone always has value 0). Zone marks are assigned to all zones except those that specify 'nomark' in the OPTION column of their zones file entry. In the above example, the bridge and portal zones would have 'nomark' specified. With ZONE_BITS and 'nomark' specified appropriately, now each packet from the 'bridge' zone has a packet mark that lets us know which of the three bport zones (zone1-zone3) the packet originated on. Similarly, packets entering the bridge through veth1 have a mark value that records whether the packet is from the net zone or the fw zone. As part of these changes, the compiler now accepts a zone name in the MARK column of the rules file, when ZONE_BITS is non-zero. This permits rules of this type: ACCEPT bridge net ... ; mark=zone2 to control connections from zone2 to the net, and rules such as ACCEPT portal zone1 ...; mark=net to control connections from the net to zone1. One final note; DNAT rules should be placed in the first traversal (net->bridge on input). See http://www.shorewall.net/bridge-Shorewall-perl for a fuller example. 6) This release introduces optimization category 16. When this category is enabled, sequences of 'compatible' rules are combined into a single rule. A sequence of rules is considered compatible if the rules differ only in their destination ports and comments. A sequence of combatible rules is often generated when macros are invoked in sequence. The ability to combine adjacent rules is limited by two factors: - Destination port lists may only be combined up to a maximum of 15 ports, where a port-pair counts as two ports. - Rules may only be combined until the length of their concatinated comments reach 255 characters. When either of these limits would be exceeded, the current combined rule is emitted and the compiler attemts to combine rules beginning with the one that would have exceeded the limit. Adjacent combined comments are separated by ', '. Empty comments at the front of a group of combined comments are replaced by 'Others and'. Empty comments at the end of a group of combined comments are replaced by 'and others'. Example 1: Rules with comments "FOO", and "BAR" would result in the combined comment "FOO and others, BAR". Example 2: Rules with comments , "FOO" and "BAR" would reult in the combined comment "Others and FOO, BAR". Note: Optimize level 16 requires "Extended Multi-port Match" in your iptables and kernel. 7) The 'enable' and 'disable' commands, previously supported only by the compiled firewall script, are now supported by the CLI programs (/sbin/shorewall, /sbin/shorewall-lite, etc.) as well. In earlier releases, these commands only allowed the provider to be specified by its physical interface name, thus making it impossible to enable/disable individual providers sharing a single interface. The commands now accept a provider name for all optional providers. For those that share an interface, only the provider name is accepted.

v4.4.25.2 [11-11-11]

1) The original static blacklisting implementation was interface-oriented and only handled blacklisting by source address. In Shorewall 4.4.12, the ability to blacklist by destination address was added and blacklisting could be specified as a ZONE option. This change, plus additional changes in subsequent releases has lead to an implementation that is complex and hard to extend. In this release, a new static blacklisting facility has been implemented. This facility is separate from the legacy facility, so existing configurations will continue to work without change. A BLACKLIST section has been added to the rules file. This section is now the first section, having been added ahead of the ALL section. The set of packets that are subject to blacklisting is still governed by the setting of BLACKLISTNEWONLY in shorewall.conf. The settings of BLACKLIST_LOGLEVEL and BLACKLIST_DISPOSITION are not relevant to the new implementation. Most of the actions available in other sections of the rules file are available in the BLACKLIST section and logging is specified on a rule-by-rule basis in the normal way. In addition to the other actions available, a WHITELIST action has been added which exempts matching packets from being passed to the remaining rules in the section. Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has a companion blacklisting chain. The name of the blacklisting chain is formed by appending "~" to the zone2zone chain. For example, 'net2fw' blacklist rules appear in the chain net2fw~. There is a likelihood that multiple blacklisting chains will have exactly the same rules. This is especially true when 'all' is used as the zone name in the SOURCE and/or DEST columns. When optimization level 8 is used, these identical chains are combined into a single chain with the name ~blacklistN, where N is a number (possibly with multiple digits). The 'nosurfs' and 'tcpflags' interface options generate rules that will be traversed prior to those in the BLACKLIST section. If you want similar rules to be travered on packets that were not dropped or rejected in the BLACKLIST chain, you can use the new 'DropSmurfs' and/or 'TCPFlags' standard actions. The DropSmurfs action has a single parameter whose default value is '-'. The action silently drops smurfs without auditing. If you want to audit these drops, use DropSmurfs(audit). Logging can be specified in the normal way (e.g., DropSmurfs:info). The TCPFlags action has two parameters whose default values are DROP and -. The first action determines what is to be done with matching packets and can have the values DROP, REJECT or ACCEPT. If you want the action to be audited, pass 'audit' in the second parameter. Example: TCPFlags(REJECT,audit) Again, logging is specified in the normal way. The 'maclist' interface option can also generate rules that are traversed prior to those in the BLACKLIST section. If you want them to come after the the blacklist rules, simply recode your maclist rules in the NEW section of the rules file. The 'macipmap' ipset type is ideally suited for this task. Example: assumes the ipset name is macipmap and that the zone to be verified is named wlan /etc/shorewall/rules: SECTION NEW DROP:info wlan:!+macipmap all 2) '6in4' has been added as a synonum for '6to4' in the TYPE column of the tunnels file. 3) The handling of IN_BANDWIDTH in both /etc/shorewall/tcdevices and /etc/shorewall/tcinterfaces has been changed. Previously: a) Simple rate/burst policing was applied using the value(s) supplied. b) IPv4 and IPv6 were policed separately. Beginning with this release, you have the option of configuring a rate estimated policing filter. This type of filter is discussed at http://ace-host.stuart.id.au/russell/files/tc/doc/extimators.txt. You specify an estimeting filter by preceding the IN-BANDWIDTH with a tilde ('~'). Example: ~40mbit This example limits incoming traffic to an *average* rate of 40mbit. There are two other other parameters that can be specified, in addition to the average rate - and . There is an excellent description of these parameters in the document referenced above. Example: ~40mbit:1sec:8sec In that example, the is 1 second and the is 8 seconds. If not given, the default values are 250ms and 4 seconds. Both parameters must be supplied if either is supplied. Also in this release, the policing of IPv4 and IPv6 has been combined so a single filter is applied to all traffic on a configured interface. 4) Shorewall6 now supports the 'balance' and 'fallback' provider options. These options are restricted to one interface per configuration for each option. 5) The scripts generated by Shorewall6 now support the 'enable' and 'disable' commands. 6) A 'MARK' column has been added to the route_rules file. See shorewall-route_rules (5) and shorewall6-route_rules (5) for details.

v4.4.25.1 [11-09-11]

1) The original static blacklisting implementation was interface-oriented and only handled blacklisting by source address. In Shorewall 4.4.12, the ability to blacklist by destination address was added and blacklisting could be specified as a ZONE option. This change, plus additional changes in subsequent releases has lead to an implementation that is complex and hard to extend. In this release, a new static blacklisting facility has been implemented. This facility is separate from the legacy facility, so existing configurations will continue to work without change. A BLACKLIST section has been added to the rules file. This section is now the first section, having been added ahead of the ALL section. The set of packets that are subject to blacklisting is still governed by the setting of BLACKLISTNEWONLY in shorewall.conf. The settings of BLACKLIST_LOGLEVEL and BLACKLIST_DISPOSITION are not relevant to the new implementation. Most of the actions available in other sections of the rules file are available in the BLACKLIST section and logging is specified on a rule-by-rule basis in the normal way. In addition to the other actions available, a WHITELIST action has been added which exempts matching packets from being passed to the remaining rules in the section. Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has a companion blacklisting chain. The name of the blacklisting chain is formed by appending "~" to the zone2zone chain. For example, 'net2fw' blacklist rules appear in the chain net2fw~. There is a likelihood that multiple blacklisting chains will have exactly the same rules. This is especially true when 'all' is used as the zone name in the SOURCE and/or DEST columns. When optimization level 8 is used, these identical chains are combined into a single chain with the name ~blacklistN, where N is a number (possibly with multiple digits). The 'nosurfs' and 'tcpflags' interface options generate rules that will be traversed prior to those in the BLACKLIST section. If you want similar rules to be travered on packets that were not dropped or rejected in the BLACKLIST chain, you can use the new 'DropSmurfs' and/or 'TCPFlags' standard actions. The DropSmurfs action has a single parameter whose default value is '-'. The action silently drops smurfs without auditing. If you want to audit these drops, use DropSmurfs(audit). Logging can be specified in the normal way (e.g., DropSmurfs:info). The TCPFlags action has two parameters whose default values are DROP and -. The first action determines what is to be done with matching packets and can have the values DROP, REJECT or ACCEPT. If you want the action to be audited, pass 'audit' in the second parameter. Example: TCPFlags(REJECT,audit) Again, logging is specified in the normal way. The 'maclist' interface option can also generate rules that are traversed prior to those in the BLACKLIST section. If you want them to come after the the blacklist rules, simply recode your maclist rules in the NEW section of the rules file. The 'macipmap' ipset type is ideally suited for this task. Example: assumes the ipset name is macipmap and that the zone to be verified is named wlan /etc/shorewall/rules: SECTION NEW DROP:info wlan:!+macipmap all 2) '6in4' has been added as a synonum for '6to4' in the TYPE column of the tunnels file. 3) The handling of IN_BANDWIDTH in both /etc/shorewall/tcdevices and /etc/shorewall/tcinterfaces has been changed. Previously: a) Simple rate/burst policing was applied using the value(s) supplied. b) IPv4 and IPv6 were policed separately. Beginning with this release, you have the option of configuring a rate estimated policing filter. This type of filter is discussed at http://ace-host.stuart.id.au/russell/files/tc/doc/extimators.txt. You specify an estimeting filter by preceding the IN-BANDWIDTH with a tilde ('~'). Example: ~40mbit This example limits incoming traffic to an *average* rate of 40mbit. There are two other other parameters that can be specified, in addition to the average rate - and . There is an excellent description of these parameters in the document referenced above. Example: ~40mbit:1sec:8sec In that example, the is 1 second and the is 8 seconds. If not given, the default values are 250ms and 4 seconds. Both parameters must be supplied if either is supplied. Also in this release, the policing of IPv4 and IPv6 has been combined so a single filter is applied to all traffic on a configured interface. 4) Shorewall6 now supports the 'balance' and 'fallback' provider options. These options are restricted to one interface per configuration for each option. 5) The scripts generated by Shorewall6 now support the 'enable' and 'disable' commands. 6) A 'MARK' column has been added to the route_rules file. See shorewall-route_rules (5) and shorewall6-route_rules (5) for details.

v4.4.24 [10-10-11]

1) Stateless NAT is now available in Shorewall6. See shorewall6-netmap(5) for details. Beta 2 added the ability to use exclusion in the NET1 column. 2) /sbin/shorewall6 now supports the 'show rawpost' command. 3) This release includes support for 'Condition Match' which is included in xtables-addons. Condition match allows rules to be predicated on the setting of a named switch in /proc/net/nf_condition/. See http://www.shorewall.net/configuration_file_basics.htm#Switches for details. 4) With the preceding change, the rules file now has 14 columns. That makes it awkward to specify the last column as you have to insert the correct number of '-' to get the right column. To make that easier, Shorewall now allows you to specify columns using several (column-name,value) formats. See http://www.shorewall.net/configuration_file_basics.htm#Pairs for details. 5) The generated script will now use the iptables/ip6tables -S command if available. 6) The implementation of USE_DEFAULT_RT=Yes has been changed significantly. These changes include: a) A new BALANCE routing table with number 250 has been added. b) Routes to providers with the 'balance' option are added to the BALANCE table rather than the default table. c) This allows 'fallback' to work with USE_DEFAULT_RT. d) For optional interfaces, the 'fallback' option without a value now works the same as if 'fallback=1' had been specified. This change also corrected several problems with 'fallback' and enable/disable. 7) Support has been added for TTL manipulation (HL in Shorewall6). See shorewall-tcrules(5) or shorewall6-tcrules(5) for details.

v4.4.23.1 [09-15-11]

1) The leading '#!/bin/sh' line has been deleted from non-executable shell modules. 2) When 'shorewall update' or 'shorewall6 update' results in no change to the .conf file, a message is issued, the .bak file is removed and the command terminates without error. Note: This change was also included in Shorewall 4.4.22.3. 3) Support has been added for 'stateless NAT'. Stateless NAT is very simmilar to NATMAP but differs from it in a couple of ways: a. It does not rely on connection tracking, but is rather implemented in the Netfilter raw table. b. Both the source and destination address can be rewritten in all three raw table chains: PREROUTING, OUTPUT and POSTROUTING. When used together with stateful NAT, it allows a single router to handle a duplicate network address situation. Suppose that a VPN using interface tun0 is used to connect to another organization, and that both intranets have network 192.168.1.0/24. To allow the two organizations to communicate, they decide to use 172.20.1.0/24 to address the other's 192.168.1.0/24. The following four entries are required in /etc/shorewall/netmap: #TYPE NET1 INTERFACE NET2 SNAT 192.168.1.0/24 tun0 172.20.1.0/24 DNAT 172.20.1.0/24 tun0 192.168.1.0/24 DNAT:T 172.20.1.0/24 tun0 192.168.1.0.24 SNAT:P 192.168.1.0/24 tun0 172.20.1.0/24 Stateless NAT entries differ from NETMAP entries in the TYPE column. For stateless entries, both the type of address translation (DNAT or SNAT) and the chain (O for OUTPUT, P for PREROUTING and T for POSTROUTING) are given. In 4.4.23.2, the feature was extended to add PROTO, DEST PORT(S) and SOURCE PORT(S) columns. 4) A new section (ALL) has been added to /etc/shorewall/rules and to /etc/shorwall6/rules. When present, the NEW section must be the first section in the file and contains rules that are applied to packets regardless of their connection tracking state. 5) The generated script now detects and removes stale lock files. 6) Jonathan Underwood has contributed Fedora/Redhat init script and .service files. The .service files are used with systemd which manages the startup sequence in Fedora 16. When installing using the install scripts: a) If /lib/systemd/system exists, the .service files are installed there and are activated using /sbin/systemctl. When installing into a directory, setting the SYSTEMD environmental variable to a non-empty value will also trigger this behavior. b) If /etc/redhat-release exists, the Fedora/Redhat init script will be installed in /etc/init.d. When installing into a directory, setting the FEDORA environmental variable to a non-empty value will also trigger this behavior. 7) Previously, when a provider interface went 'soft down' (UP and configured but not usable) or came back up from being 'soft down', the firewall had to be reloaded ('/var/lib/shorewall/firewall restart') to disable or enable the interface. Beginning with this release, the compiled IPv4 script supports two new commands: - disable - enable The 'disable' command removes all policy routing added as a result of the interface's entry in /etc/shorewall/providers and and any traffic shaping configuration on the interface. The 'enable' command restores policy routing and traffic shaping and refreshes the interfaces's entries in /proc. 8) Shorewall now uses /sys/module/ to determine which modules are loaded, thus speeding up start/restart.

v4.4.23 [09-07-11]

1) The leading '#!/bin/sh' line has been deleted from non-executable shell modules. 2) When 'shorewall update' or 'shorewall6 update' results in no change to the .conf file, a message is issued, the .bak file is removed and the command terminates without error. Note: This change was also included in Shorewall 4.4.22.3. 3) Support has been added for 'stateless NAT'. Stateless NAT is very simmilar to NATMAP but differs from it in a couple of ways: a. It does not rely on connection tracking, but is rather implemented in the Netfilter raw table. b. Both the source and destination address can be rewritten in all three raw table chains: PREROUTING, OUTPUT and POSTROUTING. When used together with stateful NAT, it allows a single router to handle a duplicate network address situation. Suppose that a VPN using interface tun0 is used to connect to another organization, and that both intranets have network 192.168.1.0/24. To allow the two organizations to communicate, they decide to use 172.20.1.0/24 to address the other's 192.168.1.0/24. The following four entries are required in /etc/shorewall/netmap: #TYPE NET1 INTERFACE NET2 SNAT 192.168.1.0/24 tun0 172.20.1.0/24 DNAT 172.20.1.0/24 tun0 192.168.1.0/24 DNAT:T 172.20.1.0/24 tun0 192.168.1.0.24 SNAT:P 192.168.1.0/24 tun0 172.20.1.0/24 Stateless NAT entries differ from NETMAP entries in the TYPE column. For stateless entries, both the type of address translation (DNAT or SNAT) and the chain (O for OUTPUT, P for PREROUTING and T for POSTROUTING) are given. 4) A new section (ALL) has been added to /etc/shorewall/rules and to /etc/shorwall6/rules. When present, the NEW section must be the first section in the file and contains rules that are applied to packets regardless of their connection tracking state. 5) The generated script now detects and removes stale lock files. 6) Jonathan Underwood has contributed Fedora/Redhat init script and .service files. The .service files are used with systemd which manages the startup sequence in Fedora 16. When installing using the install scripts: a) If /lib/systemd/system exists, the .service files are installed there and are activated using /sbin/systemctl. When installing into a directory, setting the SYSTEMD environmental variable to a non-empty value will also trigger this behavior. b) If /etc/redhat-release exists, the Fedora/Redhat init script will be installed in /etc/init.d. When installing into a directory, setting the FEDORA environmental variable to a non-empty value will also trigger this behavior. 7) Previously, when a provider interface went 'soft down' (UP and configured but not usable) or came back up from being 'soft down', the firewall had to be reloaded ('/var/lib/shorewall/firewall restart') to disable or enable the interface. Beginning with this release, the compiled IPv4 script supports two new commands: - disable - enable The 'disable' command removes all policy routing added as a result of the interface's entry in /etc/shorewall/providers and and any traffic shaping configuration on the interface. The 'enable' command restores policy routing and traffic shaping and refreshes the interfaces's entries in /proc. 8) Shorewall now uses /sys/module/ to determine which modules are loaded, thus speeding up start/restart.

v4.4.22.3 [09-01-11]

1) When 'shorewall update' or 'shorewall6 update' results in no change to the .conf file, a message is issued, the .bak file is removed and the command terminates without error. 4.4.22 1) Three new parameterized standard actions are included in this release. Invalid - Packets in the INVALID connection tracking state Broadcast - Broadcast and Multicast Packets NotSyn - TCP packets that have the SYN flag set and all other flags reset. The standard default Drop and Reject actions have been modified to use these new actions. Each accepts two parameters: a) Action to perform on matching packets. Must be ACCEPT, DROP or REJECT. Default is DROP. b) 'audit' flag. If 'audit', then the action will be audited. The new actions deprecate the following built-in actions: allowBcast - use Broadcast(ACCEPT) allowInvalid - use Invalid(ACCEPT) dropInvalid - use Invalid(DROP) dropBroadcast - use Broadcast(DROP) dropNotSyn - use NotSyn(DROP) rejNotSyn - use NotSyn(REJECT) 2) Up to this point, the Perl-based compiler has stored rules internally in iptables/ip6tables command strings. This has made the optimizing the ruleset difficult and has made the optimizer the most defect-dense part of the code. This release marks to first step toward converting the compiler to use an internal rule representation that is easier to optimize and that is easy to convert to iptables/ip6tables commands effeciently. The parser still generates iptables/ip6table rules which are then converted into the internal form. 3) Optimize level 8 causes chains that are identical to another chain to be deleted, and their references are replace by references to the other chain. This can lead to confusion when looking at the generated ruleset. For example, traffic going from the 'loc' zone to the 'dmz' zone may now be passing through a chain named 'wan2dmz'! To eliminate this confusion, the compiler now generates a synthetic name for the combined chains, consisting of "~comb" followed by an integer (e.g., "~comb1", "~comb2", etc.).

v4.4.22 [08-02-11]

1) AUTOMAKE=Yes now causes all directories on the CONFIG_PATH to be searched for files newer than the script that last started/restarted the firewall. Previously, only /etc/shorewall (/etc/shorewall6) was searched. 2) FORMAT-2 actions may now specify default parameter values using the DEFAULTS directive. DEFAULTS ,,... Where is the default value for the first parameter, is the default value for the second parameter and so on. To specify an empty default, use '-'. Note that the corresponding parameter variable ($n) will still expand to '-' but will be treated as empty by the builtin actions such as dropInvalid. The DEFAULTS directive also determines the maximum number of parameters that an action may have. If more parameters are passed than have default values, an error message is issued. 3) Parameterized macros may now specify a default parameter value using the DEFAULT directive. DEFAULT Example macro.Foo -- by default, accepts connections on ficticous tcp port 'foo'. DEFAULT ACCEPT PARAM - - tcp foo 4) The standard Drop and Reject actions are now parameterized. Each has 5 parameters: 1) Pass 'audit' if you want all ACCEPTs, DROPs and REJECTs audited. Pass '-' otherwise. 2) The action to be applied to Auth requests: FIRST PARAMETER DEFAULT - REJECT audit A_REJECT 3) The action to be applied to SMB traffic. The default depends on the action and its first parameter: ACTION FIRST PARAMETER DEFAULT Reject - REJECT Drop - DROP Reject audit A_REJECT Drop audit A_DROP 4) The action to be applied to accepted ICMP packets. FIRST PARAMETER DEFAULT - ACCEPT audit A_ACCEPT 5) The action to be applied to UPnP (udp port 1900) and late DNS replies (udp source port 53) FIRST PARAMETER DEFAULT - DROP audit A_DROP The parameters can be passed in the POLICY column of the policy file. Examples: SOURCE DEST POLICY net all DROP:Drop(audit):audit #Same as #DROP:A_DROP:audit SOURCE DEST POLICY net all DROP:Drop(-,DROP) #DROP rather than REJECT Auth The parameters can also be specified in shorewall.conf: Example: DROP_DEFAULT=Drop(-,DROP) 5) An 'update' command has been added to /sbin/shorewall and /sbin/shorewall6. The command updates the shorewall.conf (shorewall6.conf) file then validates the configuration. The updated file will set any options not specified in the old file with their default values, and will move any deprecated options with non-default values to a 'deprecated options' section at the end of the file. Each such deprecated option will generate a warning message. Your original shorewall.conf (shorewall6.conf) file will be saved as shorewall.conf.bak (shorewall6.conf.bak). The 'update' command accepts the same options as the 'check' command plus a '-a' option that causes the updated file to be annotated with manpage documentation. 6) Shorewall6 now supports ipsets. Unlike iptables, which has separate configurations for IPv4 and IPv6, ipset has a single configuration that handles both. This means the SAVE_IPSETS=Yes in shorewall.conf or shorewall6.conf won't work correctly. To work around this issue, Shorewall-init is now capable restoring ipset contents during 'start' and saving them during 'stop'. To direct Shorewall-init to save/restore ipset contents, set the SAVE_IPSETS option in /etc/sysconfig/shorewall-init (/etc/default/shorewall-init on Debian and derivatives). The value of the option is a file name where the contents of the ipsets will be saved to and restored from. Shorewall-init will create any parent directories during the first 'save' operation. If you configure Shorewall-init to save/restore ipsets, be sure to set SAVE_IPSETS=No in shorewall.conf and shorewall6.conf. As part of this change, Shorewall and Shorewall6 will only restore saved ipsets if SAVE_IPSETS=Yes in shorewall.conf (shorewall6.conf). 7) Shorewall6 now supports dynamic zones: 1) The nets=dynamic option is allowed in /etc/shorewall6/interfaces 2) The HOSTS column of /etc/shorewall6/hosts may now contain :dynamic. 3) /sbin/shorewall6 now supports the 'add' and 'delete' commands.

v4.4.21 [07-15-11]

1) AUTOMAKE=Yes now causes all directories on the CONFIG_PATH to be searched for files newer than the script that last started/restarted the firewall. Previously, only /etc/shorewall (/etc/shorewall6) was searched. 2) FORMAT-2 actions may now specify default parameter values using the DEFAULTS directive. DEFAULTS ,,... Where is the default value for the first parameter, is the default value for the second parameter and so on. To specify an empty default, use '-'. Note that the corresponding parameter variable ($n) will still expand to '-' but will be treated as empty by the builtin actions such as dropInvalid. The DEFAULTS directive also determines the maximum number of parameters that an action may have. If more parameters are passed than have default values, an error message is issued. 3) Parameterized macros may now specify a default parameter value using the DEFAULT directive. DEFAULT Example macro.Foo -- by default, accepts connections on ficticous tcp port 'foo'. DEFAULT ACCEPT PARAM - - tcp foo 4) The standard Drop and Reject actions are now parameterized. Each has 5 parameters: 1) Pass 'audit' if you want all ACCEPTs, DROPs and REJECTs audited. Pass '-' otherwise. 2) The action to be applied to Auth requests: FIRST PARAMETER DEFAULT - REJECT audit A_REJECT 3) The action to be applied to SMB traffic. The default depends on the action and its first parameter: ACTION FIRST PARAMETER DEFAULT Reject - REJECT Drop - DROP Reject audit A_REJECT Drop audit A_DROP 4) The action to be applied to accepted ICMP packets. FIRST PARAMETER DEFAULT - ACCEPT audit A_ACCEPT 5) The action to be applied to UPnP (udp port 1900) and late DNS replies (udp source port 53) FIRST PARAMETER DEFAULT - DROP audit A_DROP The parameters can be passed in the POLICY column of the policy file. Examples: SOURCE DEST POLICY net all DROP:Drop(audit):audit #Same as #DROP:A_DROP:audit SOURCE DEST POLICY net all DROP:Drop(-,DROP) #DROP rather than REJECT Auth The parameters can also be specified in shorewall.conf: Example: DROP_DEFAULT=Drop(-,DROP) 5) An 'update' command has been added to /sbin/shorewall and /sbin/shorewall6. The command updates the shorewall.conf (shorewall6.conf) file then validates the configuration. The updated file will set any options not specified in the old file with their default values, and will move any deprecated options with non-default values to a 'deprecated options' section at the end of the file. Each such deprecated option will generate a warning message. Your original shorewall.conf (shorewall6.conf) file will be saved as shorewall.conf.bak (shorewall6.conf.bak). The 'update' command accepts the same options as the 'check' command plus a '-a' option that causes the updated file to be annotated with manpage documentation. 6) Shorewall6 now supports ipsets. Unlike iptables, which has separate configurations for IPv4 and IPv6, ipset has a single configuration that handles both. This means the SAVE_IPSETS=Yes in shorewall.conf or shorewall6.conf won't work correctly. To work around this issue, Shorewall-init is now capable restoring ipset contents during 'start' and saving them during 'stop'. To direct Shorewall-init to save/restore ipset contents, set the SAVE_IPSETS option in /etc/sysconfig/shorewall-init (/etc/default/shorewall-init on Debian and derivatives). The value of the option is a file name where the contents of the ipsets will be saved to and restored from. Shorewall-init will create any parent directories during the first 'save' operation. If you configure Shorewall-init to save/restore ipsets, be sure to set SAVE_IPSETS=No in shorewall.conf and shorewall6.conf. As part of this change, Shorewall and Shorewall6 will only restore saved ipsets if SAVE_IPSETS=Yes in shorewall.conf (shorewall6.conf). 7) Shorewall6 now supports dynamic zones: 1) The nets=dynamic option is allowed in /etc/shorewall6/interfaces 2) The HOSTS column of /etc/shorewall6/hosts may now contain :dynamic. 3) /sbin/shorewall6 now supports the 'add' and 'delete' commands.

v4.4.20.3 [06-19-11]

1) The implementation of the environmental variables LIBEXEC and PERLLIB that was introduced in 4.4.19 has been changed slightly. The installers now allow absolute path names to be supplied in these variables so that the executables and/or Perl modules may be installed under a top-level directory other than /usr. The change is compatible with 4.4.19 in that if a relative path name is supplied, then '/usr/' is prepended to the supplied name. 2) A new ACCOUNTING_TABLE option has been added to shorewall.conf and shorewall6.conf. The setting determines the Netfilter table (filter or mangle) where accounting rules are created. When ACCOUNTING_TABLE=mangle, the allowable accounting file sections are: PREROUTING INPUT OUTPUT FORWARD POSTROUTING Present sections must appear in that order. 3) An NFLOG 'ACTION' has been added to the accounting file to allow sending matching packets (or the leading part of them) to backend accounting daemons via a netlink socket. 4) A 'whitelist' option has been added to the blacklist file. When 'whitelist' is specified, packets/connections matching the entry are not matched against the entries which follow. No logging of whitelisted packets/connections is performed. 5) Support for the AUDIT target has been added. AUDIT is a feature of the 2.6.39 kernel and iptables 1.4.10 that allows security auditing of access decisions. The support involves the following: a) A new "AUDIT Target" capability is added and is required for auditing support. To use AUDIT support with a capabilities file, that file must be generated using this or a later release. Use 'shorewall show capabilities' after installing this release to see if your kernel and iptables support the AUDIT target. b) In /etc/shorewall/policy's POLICY column, the policy (and default action, if any) may be followed by ':audit' to cause applications of the policy to be audited. This means that any NEW connection that does not match any rule in the rules file or in the applicable 'default action' will be audited. Only ACCEPT, DROP and REJECT policies may be audited. Example: #SOURCE DEST POLICY LOG # LEVEL net fw DROP:audit It is allowed to also specify a log level on audited policies resulting in both auditing and logging. c) Three new builtin actions that may be used in the rules file, in macros and in other actions. A_ACCEPT - Audits and accepts the connection request A_DROP - Audits and drops the connection request A_REJECT - Audits and rejects A log level may be supplied with these actions to provide both auditing and logging. Example: A_ACCEPT:info loc net ... d) The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION and TCP_FLAGS_DISPOSITION options may be set as follows: BLACKLIST_DISPOSITION A_DROP or A_REJECT MACLIST_DISPOSITION A_DROP A_REJECT, unless MACLIST_TABLE=mangle TCP_FLAGS_DISPOSITION A_DROP or A_REJECT e) A SMURF_DISPOSITION option has been added to shorewall.conf. The default value is DROP; if the option is set to A_DROP, then dropped smurfs are audited. f) An 'audit' option has been added to the /etc/shorewall/blacklist file which causes the packets matching the entry to be audited. 'audit' may not be specified together with 'whitelist'. g) The builtin actions (dropBroadcast, rejNonSyn, etc.) now support an 'audit' parameter which causes all ACCEPT, DROP and REJECTs performed by the action to be audited. Note: The builtin actions are those actions listed in the output of 'shorewall show actions' with names that begin with a lower-case letter. Example: #ACTION SOURCE DEST rejNonSyn(audit) net all h) There are audited versions of the standard Default Actions named A_Drop and A_Reject. Note that these audit everything that they do so you will probably want to make your own copies and modify them to only audit the packets that you care about. 6) Up to this release, the behaviors of 'start -f' and 'restart -f' has been inconsistent. The 'start -f' command compares the modification times of /etc/shorewall[6] with /var/lib/shorewall[6]/restore while 'restart -f' compares with /var/lib/shorewall[6]/firewall. To make the two consistent, a new LEGACY_FASTSTART option has been added. The default value when the option isn't specified is LEGACY_FASTSTART=Yes which preserves the old behavior. When LEGACY_FASTSTART=No, 'start -f' and 'restart -f' both compare with /var/lib/shorewall[6]/firewall. 7) A '-c' (compile) option has been added to the 'start' and 'restart' commands in both Shorewall and Shorewall6. It overrides the setting of AUTOMAKE and unconditionally forces a recompilation of the configuration. When both -c and -f are specified, the result is determined by the option that appears last. 8) Shorewall and Shorewall6 no longer depend on 'make'. 9) A '-T' (trace) option has been added to the 'check' and 'compile' commands. When a warning or error message is generated, a Perl stack trace is included to aid in isolating the source of the message. 10) The Shorewall and Shorewall6 configuration files (including the samples) may now be annotated with documentation from the associated manpage. The installers for these two packages support a -a (annotated) option that installs annotated versions of the packages. Both versions are available in the configfiles directory within the tarball and in the Sample directories. 11) The STATE subcolumn of the secmarks file now allows the values 'I' which will match packets in the INVALID state, and 'NI' which will match packets in either NEW or INVALID state. 12) Certain attacks can be best defended through use of one of these two measures. a) rt_filter (Shorewall's routefilter). Only applicable to IPv4 and can't be used with some multi-ISP configurations. b) Insert a DROP rule that prevents hairpinning (routeback). The rule must be inserted before any ESTABLISHED,RELATED firewall rules. This approach is not appropriate for bridges and other cases, where the 'routeback' option is specified or implied. For non-routeback interfaces, Shorewall and Shorewall6 will now insert a hairpin rule, provided that the routefilter option is not specified. The rule will dispose of hairpins according to the setting of two new options in shorewall.conf and shorewall6.conf: SFILTER_LOG_LEVEL Specifies the logging level; default is 'info'. To omit logging, specify FILTER_LOG_LEVEL=none. SFILTER_DISPOSITION Specifies the disposition. Default is DROP and the possible values are DROP, A_DROP, REJECT and A_REJECT. To deal with bridges and other routeback interfaces , there is now an 'sfilter' option in /shorewall/interfaces and /etc/shorewall6/interfaces. The value of the 'sfilter' option is a list of network addresses enclosed in in parentheses. Where only a single address is listed, the parentheses may be omitted. When a packet from a source-filtered address is received on the interface, it is disposed of based on the new SFILTER_ options described above. For a bridge or other routeback interface, you should list all of your other local networks (those networks not attached to the bridge) in the bridge's sfilter list. Example: My DMZ is 2001:470:b:227::40/124 My local interface (br1) is a bridge. In /etc/shorewall6/interfaces, I have: #ZONE INTERFACE BROADCAST OPTIONS loc br1 - sfilter=2001:470:b:227::40/124

v4.4.19.4 [05-20-11]

1) When TC_ENABLED=Simple, ACK packets are now placed in the highest priority class. An ACK packet is a TCP packet with the ACK flag set and no data payload. Rationale: Entries in /etc/shorewall[6]/tcpri affect both incoming and outgoing connections. If a particular application, SMTP for example, is placed in priority class 3, then outgoing ACK packets for incoming email were previously placed in priority class 3 as well. This could have the effect of slowing down incoming mail when the goal was to give outgoing mail a lower priority. By unconditionally placing ACK packets in priority class 1, this issue is avoided. 2) Up to this point, the Perl-based rules compiler has not accepted ICMP type lists. This is in contrast to the shell-based compiler which did support such lists. Support for ICMP (and ICMPv6) type lists has now been restored. 3) Distributions have different philosophies about the proper file hierarchy. Two issures are particularly contentious: - Executable files in /usr/share/shorewall*. These include; getparams compiler.pl wait4ifup shorecap ifupdown - Perl Modules in /usr/share/shorewall/Shorewall. To allow distributions to designate alternate locations for these files, the installers (install.sh) now support the following environmental variables: LIBEXEC -- determines where in /usr getparams, compiler.pl, wait4ifup, shorecap and ifupdown are installed. Shorewall and Shorewall6 must be installed with the same value of LIBEXEC. The listed executables are installed in /usr/${LIBEXEC}/shorewall*. The default value of LIBEXEC is 'share'. LIBEXEC is recognized by all installers and uninstallers. PERLLIB -- determines where in /usr the Shorewall perl modules are installed. Shorewall and Shorewall6 must be installed with the same value of PERLLIB. The modules are installed in /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is 'share/shorewall'. PERLLIB is only recognized by the Shorewall and Shorewall6 installers and the same value must be passed to both installers. 4) Bridge/ports handling has been significantly improved, resulting in packets to/from bridges traversing fewer rules. 5) A list of protocols is now permitted in the PROTO column of the rules file. 6) The contents of the Netfilter mangle table are now included in the output from 'shorewall show tc'. 7) Simple traffic shaping can now have a common configuration between IPv4 and IPv6. To do that: - Set TC_ENABLED=Simple in both /etc/shorewall/shorewall.conf and /etc/shorewall6/shorewall6.conf - Configure /etc/shorewall/tcinterfaces. - Leave /etc/shorewall6/tcinterfaces empty. - Configure /etc/shorewall/tcpri (if desired) - Configure /etc/shorewall6/tcpri (if desired) It should be noted that when IPv6 packets are encapsulated for transmission by 6to4/6in4, they retain their marks.

v4.4.19.1 [05-03-11]

1) When TC_ENABLED=Simple, ACK packets are now placed in the highest priority class. An ACK packet is a TCP packet with the ACK flag set and no data payload. Rationale: Entries in /etc/shorewall[6]/tcpri affect both incoming and outgoing connections. If a particular application, SMTP for example, is placed in priority class 3, then outgoing ACK packets for incoming email were previously placed in priority class 3 as well. This could have the effect of slowing down incoming mail when the goal was to give outgoing mail a lower priority. By unconditionally placing ACK packets in priority class 1, this issue is avoided. 2) Up to this point, the Perl-based rules compiler has not accepted ICMP type lists. This is in contrast to the shell-based compiler which did support such lists. Support for ICMP (and ICMPv6) type lists has now been restored. 3) Distributions have different philosophies about the proper file hierarchy. Two issures are particularly contentious: - Executable files in /usr/share/shorewall*. These include; getparams compiler.pl wait4ifup shorecap ifupdown - Perl Modules in /usr/share/shorewall/Shorewall. To allow distributions to designate alternate locations for these files, the installers (install.sh) now support the following environmental variables: LIBEXEC -- determines where in /usr getparams, compiler.pl, wait4ifup, shorecap and ifupdown are installed. Shorewall and Shorewall6 must be installed with the same value of LIBEXEC. The listed executables are installed in /usr/${LIBEXEC}/shorewall*. The default value of LIBEXEC is 'share'. LIBEXEC is recognized by all installers and uninstallers. PERLLIB -- determines where in /usr the Shorewall perl modules are installed. Shorewall and Shorewall6 must be installed with the same value of PERLLIB. The modules are installed in /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is 'share/shorewall'. PERLLIB is only recognized by the Shorewall and Shorewall6 installers and the same value must be passed to both installers. 4) Bridge/ports handling has been significantly improved, resulting in packets to/from bridges traversing fewer rules. 5) A list of protocols is now permitted in the PROTO column of the rules file. 6) The contents of the Netfilter mangle table are now included in the output from 'shorewall show tc'. 7) Simple traffic shaping can now have a common configuration between IPv4 and IPv6. To do that: - Set TC_ENABLED=Simple in both /etc/shorewall/shorewall.conf and /etc/shorewall6/shorewall6.conf - Configure /etc/shorewall/tcinterfaces. - Leave /etc/shorewall6/tcinterfaces empty. - Configure /etc/shorewall/tcpri (if desired) - Configure /etc/shorewall6/tcpri (if desired) It should be noted that when IPv6 packets are encapsulated for transmission by 6to4/6in4, they retain their marks.

v4.4.19 [04-13-11]

1) When TC_ENABLED=Simple, ACK packets are now placed in the highest priority class. An ACK packet is a TCP packet with the ACK flag set and no data payload. Rationale: Entries in /etc/shorewall[6]/tcpri affect both incoming and outgoing connections. If a particular application, SMTP for example, is placed in priority class 3, then outgoing ACK packets for incoming email were previously placed in priority class 3 as well. This could have the effect of slowing down incoming mail when the goal was to give outgoing mail a lower priority. By unconditionally placing ACK packets in priority class 1, this issue is avoided. 2) Up to this point, the Perl-based rules compiler has not accepted ICMP type lists. This is in contrast to the shell-based compiler which did support such lists. Support for ICMP (and ICMPv6) type lists has now been restored. 3) Distributions have different philosophies about the proper file hierarchy. Two issures are particularly contentious: - Executable files in /usr/share/shorewall*. These include; getparams compiler.pl wait4ifup shorecap ifupdown - Perl Modules in /usr/share/shorewall/Shorewall. To allow distributions to designate alternate locations for these files, the installers (install.sh) now support the following environmental variables: LIBEXEC -- determines where in /usr getparams, compiler.pl, wait4ifup, shorecap and ifupdown are installed. Shorewall and Shorewall6 must be installed with the same value of LIBEXEC. The listed executables are installed in /usr/${LIBEXEC}/shorewall*. The default value of LIBEXEC is 'share'. LIBEXEC is recognized by all installers and uninstallers. PERLLIB -- determines where in /usr the Shorewall perl modules are installed. Shorewall and Shorewall6 must be installed with the same value of PERLLIB. The modules are installed in /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is 'share/shorewall'. PERLLIB is only recognized by the Shorewall and Shorewall6 installers and the same value must be passed to both installers. 4) Bridge/ports handling has been significantly improved, resulting in packets to/from bridges traversing fewer rules. 5) A list of protocols is now permitted in the PROTO column of the rules file. 6) The contents of the Netfilter mangle table are now included in the output from 'shorewall show tc'. 7) Simple traffic shaping can now have a common configuration between IPv4 and IPv6. To do that: - Set TC_ENABLED=Simple in both /etc/shorewall/shorewall.conf and /etc/shorewall6/shorewall6.conf - Configure /etc/shorewall/tcinterfaces. - Leave /etc/shorewall6/tcinterfaces empty. - Configure /etc/shorewall/tcpri (if desired) - Configure /etc/shorewall6/tcpri (if desired) It should be noted that when IPv6 packets are encapsulated for transmission by 6to4/6in4, they retain their marks.

v4.4.18.2 [04-11-11]

1) The modules files are now just a driver that INCLUDEs several new files and one old file: - /usr/share/shorewall[6]/modules.essential # Essential modules - /usr/share/shorewall[6]/modules.xtables # xt_ modules - /usr/share/shorewall[6]/helpers # Existing file - /usr/share/shorewall/ipset # ipset modules - /usr/share/shorewall[6]/modules.tc # Traffic Shaping - /usr/share/shorewall[6]/modules.extensions # Other extensions This should make it easier to configure your own /etc/shorewall[6]/modules file that won't be obsolete when you upgrade your Shorewall/Shorewall6 installation. For example, if you don't use traffic shaping or ipsets, you can remove those from your copy of the modules file (copy in /etc/shorewall/). 2) Traditionally, the root of the Shorewall accounting rules has been the 'accounting' chain. Having a single root chain has drawbacks: - Many rules are traversed needlessly (they could not possibly match traffic). - At any time, the Netfilter team could begin generating errors when loading those same rules. - MAC addresses may not be used in the accounting rules. - The 'accounting' chain cannot be optimized when OPTIMIZE_ACCOUNTING=Yes. In addition, currently the rules may be defined in any order so the rules compiler must post-process the ruleset to alert the user to unreferenced chains. Beginning with Shorewall 4.4.18, the accounting structure can be created with three root chains: - accountin: Rules that are valid in the INPUT chain (may not specify an output interface). - accountout: Rules that are valid in the OUTPUT chain (may not specify an input interface or a MAC address). - accountfwd: Other rules. The new structure is enabled by sectioning the accounting file in a manner similar to the rules file. The sections are INPUT, OUTPUT and FORWARD and must appear in that order (although any of them may be omitted). The first non-commentary record in the accounting file must be a section header when sectioning is used. When sections are enabled: - You must jump to a user-defined accounting chain before you can add rules to that chain. This eliminates the possibility of unreferenced chains. - You may not specify an output interface in the INPUT section. - In the OUTPUT section: - You may not specify an input interface - You may not jump to a chain defined in the INPUT section that specifies an input interface - You may not specify a MAC address - You may not jump to a chain defined in the INPUT section that specifies specifies a MAC address. - The default value of the CHAIN column is: - 'accountin' in the INPUT section - 'accountout' in the OUTPUT section - 'accountfwd' in the FORWARD section - Traffic addressed to the firewall goes through the rules defined in the INPUT section. - Traffic originating on the firewall goes through the rules defined in the OUTPUT section. - Traffic being forwarded through the firewall goes through the rules defined in the FORWARD section. As part of this change, the USER/GROUP column must now be empty except in the OUTPUT section. This is consistent with recent Netfilter releases which disallow the owner match in rules reachable from the INPUT and FORWARD hooks. 3) Internals Change: The Policy.pm module has been merged into the Rules.pm module.

Average review rating :

Useful independent reviews and opinions of the users

Review ShorewallWrite a review « Be the first to post a review for Shorewall download!

Predicted future versions and notices:

The doDownload.com constantly monitors the update of all programs, including information from the Shorewall 4.4.28.0 changelog file, however sometimes it can happen that data are not complete or are outdated.We assume that author continue's to develop 4.5.0.0 version with further advanced features, and soon you will be informed. Equally important 5.0.0.0 upgrades of the program we will continue to monitor. Full Shorewall description has been compared with the overall software database and our algorithm has found the following applications (are showed below).

Download 0.3MB Shorewall

Download Direct

(0.3MB, Extension: TGZ)