- Issue with Ubuntu 14.04 LTS
- End of Support Life for Shorewall 4.4
- Nasty Bug in Shorewall 4.4.13-4.4.22
- End of Support Life for Shorewall 4.0 and 4.2
- Blacklisting Broken in Shorewall 4.4.13
- Attention Shorwall-shell Users
- Attention Users of BRIDGING=Yes
- Attention Kernel 2.4 Users
We have had a number of reports of system crashes when starting Shorewall after upgrading to Ubuntu 14.04 LTS. The problem is with the xtables-addons-dkms - removing that package eliminates the problem.
All future releases of Shorewall will be licensed under GPLv2 or (at your option) any later version
With the release of Debian Wheezy, support for Shorewall 4.4 has ended. Users are encouraged to upgrade to Shorewall 4.5 or 4.6 at the earliest opportunity.
A bug in recent versions of Shorewall can result in rules that are wider in scope than intended.
If a zone name begins with 'all', then rules referring to that zone are incorrectly handled as if the keyword 'all' had been entered rather than the zone name.
Users who are running one of these versions of Shorewall and who have zone names beginning with 'all' are urged to either:
- Rename the zone(s) to not begin with 'all'; or
- Upgrade to Shorewall 188.8.131.52 or later.
With the release of Debian Squeeze, support for Shorewall 4.0 and Shorewall 4.2 has ended. Users are encouraged to upgrade to Shorewall 4.4 at the earliest opportunity.
Prior to Shorewall 4.4.13, blacklisting was associated with an interface or host group by using the 'blacklist' option in /etc/shorewall/interfaces or /etc/shorewall/hosts. Beginning with Shorewall 4.4.13, Shorewall associates blacklisting with zones by accepting the 'blacklist' option in the OPTIONS, IN_OPTIONS and OUT_OPTIONS column of /etc/shorewall/zones. To maintain compatibility with earlier releases, setting 'blacklist' in /etc/shorewall/interfaces or /etc/shorewall/hosts is treated as if the option had been entered under IN_OPTIONS in the associated zone entry in /etc/shorewall/zones.
Unfortunately, a defect in this implementation causes blacklisting to be disabled in some simple existing configurations. If you use blacklisting and have installed Shorewall 4.4.13, you are urged to upgrade to 184.108.40.206 as soon as possible.
If you cannot upgrade immediately, you can work around the problem by including 'blacklist' in the IN_OPTIONS of any zones on which you want incoming blacklisting to occur.
Shorewall 4.4, released in August 2009, does not include Shorewall-shell. Because Shorewall 4.0 is included in Debian Lenny, Shorewall-shell will continue to be supported until Debian Squeeze is released.
Shorewall-shell users concerned about upgrading are encouraged to migrate to Shorewall-perl before upgrading to Shorewall 4.4. By migrating before upgrading, you will be able to have both Shorewall-shell and Shorewall-perl installed at the same time; that way, you can quickly fall back to Shorewall-shell if you have problems.
Users who run Shorewall-shell on an embedded system that is too small to support Perl should consider switching to Shorewall-lite with Shorewall-perl installed on an administrative system (may be a Windows[tm] system running Cygwin[tm] or a Mac running OS X).
For those of you who may have already upgraded and are having issues, this article should help.
Shorewall-perl 4.2.6 and Earlier
On February 28, 2008, Klemens Rutz reported a problem that affects all Shorewall-perl 4.2 versions prior to 220.127.116.11.
- Only occurs when there are multiple non-firewall zones.
- Results in the following interface options not being applied
to forwarded traffic.
- maclist (when MACLIST_TABLE=filter)
User are encouraged to either:
- Upgrade to Shorewall-perl-18.104.22.168 or later; or
- Apply the patch found at:
To apply the patch, execute this command:
patch /usr/share/shorewall-perl/Shorewall/Rules.pm < forward.patch
The patch may apply with fuzz and/or an offset, depending on your particular version.
In Linux Kernel version 2.6.20, the Netfilter team changed Physdev Match so that it is no longer capable of supporting BRIDGING=Yes. The solutions available to users are to either:
- Switch to using the technique described at http://www.shorewall.net/3.0/NewBridge.html;
- Upgrade to Shorewall 4.0 or later, migrate to using Shorewall-perl, and follow the instructions at http://www1.shorewall.net/bridge-Shorewall-perl.html.
The first approach allows you to switch back and forth between kernels older and newer than 2.6.20. The second approach is a better long-term solution.
The Shorewall developers do not test Shorewall running on Kernel 2.4 and we make no representation about the functionality of Shorewall on that Kernel. Any failure of Shorewall on Kernel 2.4 will not be investigated by the Shorewall team.