extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2025-02-19 03:01:10 +01:00
Code Issues Packages Projects Releases Wiki Activity

Bring News.htm up to date

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@8250 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2008-03-01 17:34:43 +00:00
parent 74dedc8003
commit b31665d5e3
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
web/News.htm
View File

@ -26,9 +26,12 @@ license is included in the section entitled <span
href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>".
</p>
<p>January 25, 2008<br>
<p>February 23, 2008<br>
</p>
<hr style="width: 100%; height: 2px;">
<p><strong>2008-02-23 Shorewall 4.0.9</strong></p>
<p><strong></strong></p>
<pre>Problems corrected in Shorewall-perl 4.0.9.1<br><br>1) In 4.0.9, Shorewall-perl incorrectly generated the following error<br> message:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br>Problems corrected in Shorewall-perl 4.0.9<br><br>1) If a zone was defined with exclusion in /etc/shorewall/hosts, then<br> the rules generated for directing outgoing connections to the zone<br> were incorrect.<br><br> Example:<br><br> /etc/shorewall/zones:<br><br> z ipv4<br><br> /etc/shorewall/interfaces:<br><br> - eth2 <br><br> /etc/shorewall/hosts:<br><br> z eth2:192.168.1.0/24!192.168.1.5<br><br> Traffic from the firewall to 192.168.1.5 was incorrectly classified<br> as $FW-&gt;z.<br><br>2) Qualifying 'SOURCE' and 'DEST' with an IP address in a macro file<br> caused 'SOURCE' or 'DEST' to be interpreted incorrectly as the name<br> of an interface.<br><br> Example:<br><br> PARAM DEST SOURCE:224.0.0.22<br><br>3) Specifying '!&lt;user&gt;' in the USER/GROUP column of the files that<br> support it resulted in an invalid iptables rule under<br> Shorewall-perl.<br><br>4) Previously, Shorewall would accept both an interface and an IP<br> address in tcrules POSTROUTING entries (such as CLASSIFY).<br><br> Example:<br><br> 1:11 eth1:192.168.4.9 - tcp 22<br><br> It also allowed both a destination interface and address.<br><br> Example:<br><br> 1:P - eth1:192.168.4.9 tcp 22<br><br> Because Netfilter does not allow an input interface to be specified<br> in POSTROUTING or an output interface to be specified in<br> PREROUTING, Shorewall must use the routing table to generate a list<br> of networks accessed through any interface specified in these<br> cases. Given that a specific address (or set of addresses) has<br> already been specified, it makes no sense qualify it (them) by<br> another list of addresses.<br><br>5) Shorewall-perl incorrectly generated a fatal error when ':C', <br> ':T' or ':CT' was used in a tcrules entry that gave $FW as the<br> SOURCE.<br><br>6) Users have been confused about this error message:<br><br> ERROR: Bridge Ports require Repeat match in your kernel and iptables <br><br> The message has been replaced with:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br> The minimum version required is 1.3.8.<br><br>Problems corrected in Shorewall-shell 4.0.9.<br><br>1) An optimization added to Shorewall-shell in 4.0.0 has been backed<br> out to work around a limitation of Busybox 'sed'.<br><br>2) Previously, specifying both an interface and an address in the<br> tcrules DEST column would cause an incomplete rule to be generated.<br><br> Example:<br><br> 1 192.168.1.4 eth2:206.124.146.177 tcp 22<br><br> The resulting tcrule would be as if this had been specified:<br><br> 1 0.0.0.0/0 eth2:206.124.146.177 tcp 22<br><br>3) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match<br> fwmarks to routing tables previously overflowed the designated<br> range defined for such marks (10000 - 11000). <br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.9.<br><br>1) The Shorewall-perl now flags unprintable garbage characters in<br> configuration files with the message:<br><br> ERROR: Non-ASCII gunk in file <br><br>2) The /usr/share/shorewall/modules file has been updated to reflect<br> module renaming in kernel 2.6.25.<br><br>3) The 'ip route replace' command is broken in kernel 2.6.24. To work<br> around this problem, the undocumented option BROKEN_ROUTING has<br> been added to shorewall.conf. The default is BROKEN_ROUTING=No.<br><br> If you are experiencing 'File Exists' errors from 'ip route<br> replace' commands, then add the following line to your<br> shorewall.conf:<br><br> BROKEN_ROUTING=Yes<br><br> Note: This workaround is only available in Shorewall-perl.<br></pre>
<p><strong>2008-01-25 Shorewall 4.0.8</strong></p>
<p><strong></strong></p>
<pre>Problems corrected in Shorewall-perl 4.0.8.<br><br>1) Mark tests (such as in the TEST column of tcrules or the MARK<br> column of the rules file) were ignoring the value 0. As part of<br> this fix, the default mask generated by entries in these columns<br> has been changed from 0xFF to 0xFFFF for compatibility with<br> Shorewall-shell.<br><br>2) The compilation date recorded in the firewall.conf file produced by<br> Shorewall-perl was previously mangled.<br><br>3) The ability to specify a DEST IP range (round-robin) in a DNAT rule<br> has been restored. In versions 4.0.5 - 4.0.7, an IP range was<br> incorrectly flagged as an error.<br><br>Problems corrected in Shorewall-shell 4.0.8.<br><br>1) Shorewall-shell now properly parses comma separated SOURCE (formerly<br> SUBNET) values in the masq configuration file. Previously, the comma<br> separated list was not split up into its components, resulting in an<br> invalid address being passed to the iptables command.<br><br> Example:<br><br> # /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC<br> eth0 192.168.2.1,192.168.2.3<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.8.<br><br>None.<br></pre>