forked from extern/shorewall_code
a5c0f03345
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3217 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
229 lines
25 KiB
HTML
229 lines
25 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator"
|
|
content="HTML Tidy for Linux (vers 1st April 2002), see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
<title>Shorewall News</title>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
<meta name="Generator" content="Kate, the KDE Advanced Text Editor">
|
|
</head>
|
|
<body>
|
|
<h1 style="text-align: left;">Shorewall News and Announcements<br>
|
|
</h1>
|
|
<span style="font-weight: bold;">Tom Eastep<br>
|
|
<br>
|
|
</span>Copyright © 2001-2005 Thomas M. Eastep<br>
|
|
<p>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation;
|
|
with no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled “<span
|
|
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
|
Documentation License</a></span>”.<br>
|
|
</p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<p></p>
|
|
<!-- Shorewall Release 3.0.3 -->
|
|
<span style="font-weight: bold;">2005-12-13
|
|
Shorewall 3.0.3<br>
|
|
</span>
|
|
<pre>Problems Corrected in 3.0.3<br><br>1) The comments in the /etc/shorewall/shorewall.conf and<br> /etc/shorewall/hosts files have been changed to clarify when<br> BRIDGING=Yes is required when dealing with bridges.<br><br>2) Thanks to Tuomo Soini, formatting of the comments in the tcdevices<br> and tcclasses files has been cleaned up.<br><br>3) Specifying 'trace' on the 'safe-start' and 'safe-restart' command no<br> longer fails.<br><br>4) The output of "shorewall help restore" has been corrected. It previously<br> printed incorrect syntax for that command.<br><br>5) The README.txt file in the tarball was stale and contained incorrect<br> information. It has been corrected.<br><br>6) The shorewall.conf default setting of CLEAR_TC was previously "No". Given<br> that the default setting of TC_ENABLED is "Internal", the setting of<br> CLEAR_TC has been changed to the more appropriate value of "Yes".<br><br>7) Specifying an interface name in the SOURCE column of /etc/shorewall/tcrules<br> resulted in a startup error.<br><br>8) When the 'install.sh' script is used on Debian, it now creates<br> /var/log/shorewall-init.log. And if perl is installed on the system then<br> STARTUP_ENABLED=Yes is specified in shorewall.conf (the user must still<br> set startup=1 in /etc/default/shorewall).<br><br>New Features in 3.0.3 <br>
|
|
|
|
1) A "shorewall show macros" command has been added. This command displays
|
|
a list of the standard macros along with a brief description of each.
|
|
|
|
2) The '-q' option is now supported with 'safe-start' and 'safe-restart'.
|
|
|
|
3) The value "-" is now allowed in the ADDRESS/SUBNET column of
|
|
/etc/shorewall/blacklist. That value is equivalent to specifying
|
|
0.0.0.0/0 in that column.
|
|
|
|
4) The output of "shorewall show tc" and "shorewall show classifiers" is
|
|
now included in the output from "shorewall dump". This will aid us in
|
|
analyzing traffic shaping problems.
|
|
|
|
5) You can now specify 'none' in the COPY column of /etc/shorewall/providers
|
|
to signal that you want Shorewall to only copy routes through the interface
|
|
listed in the INTERFACE column.
|
|
|
|
Note: This works on older versions of Shorewall as well. It is
|
|
now documented.
|
|
|
|
6) An 'ipdecimal' command has been added to /sbin/shorewall. This command
|
|
converts between dot-quad and decimal.
|
|
|
|
Example:
|
|
|
|
gateway:/etc/openvpn# shorewall ipdecimal 192.168.1.4
|
|
3232235780
|
|
gateway:/etc/openvpn# shorewall ipdecimal 3232235780
|
|
192.168.1.4
|
|
gateway:/etc/openvpn#
|
|
|
|
7) /etc/init.d/shorewall now supports a 'reload' command which is
|
|
synonymous with the 'restart' command.
|
|
</pre>
|
|
<p> 2005-12-12 </p>
|
|
<hr style="width: 100%; height: 2px;"> <span style="font-weight: bold;">2005-12-12
|
|
Shorewall 2.4.7</span><br>
|
|
<br>
|
|
Problems Corrected in 2.4.7<br>
|
|
<br>
|
|
1) When MACLIST_TABLE=mangle and an interface is enabled for DHCP
|
|
(the<br>
|
|
'dhcp' option is specified in /etc/shorewall/interfaces)
|
|
then broadcasts<br>
|
|
on UDP port 67 to address 255.255.255.255 from address
|
|
0.0.0.0 were being<br>
|
|
dropped and logged. While this did not prevent the client
|
|
from acquiring<br>
|
|
an IP address, it could result in lots of log messages.<br>
|
|
<br>
|
|
2) Entries for openvpn tunnels (including openvpnclient and<br>
|
|
openvpnserver) that specify a port but no protocol cause
|
|
startup<br>
|
|
errors as follows:<br>
|
|
<br>
|
|
iptables v1.3.3: unknown
|
|
protocol `1194' specified<br>
|
|
Try `iptables -h' or 'iptables
|
|
--help' for more information.<br>
|
|
ERROR: Command
|
|
"/usr/sbin/iptables -A net2fw -p 1194 -s<br>
|
|
0.0.0.0/0 --sport 1194 -j
|
|
ACCEPT" Failed<br>
|
|
<br>
|
|
The problem may be worked around by specifying the
|
|
protocol as well<br>
|
|
(e.g., "openvpn:udp:3455).<br>
|
|
<br>
|
|
3) If the previous firewall configuration included a policy other
|
|
than<br>
|
|
ACCEPT in the nat, mangle or raw tables then Shorewall
|
|
would not set<br>
|
|
the policy to ACCEPT. This could result in a ruleset that
|
|
rejected or<br>
|
|
dropped all traffic.<br>
|
|
<br>
|
|
4) Specifying an interface name in the SOURCE column <br>
|
|
of /etc/shorewall/tcrules resulted in a startup error.<br>
|
|
<span style="font-weight: bold;"><br>
|
|
</span><span style="font-weight: bold;">2005-12-01
|
|
End of Support for Shorewall versions 2.0 and 2.2<br>
|
|
<br>
|
|
</span>Effective today, versions 2.0 and 2.2 are no longer supported.
|
|
This means that if you find a bug in one of these releases, we won't
|
|
fix it and if you ask for help with one of these releases, we will not
|
|
spend much time trying to solve your issue.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">2005-11-25
|
|
Shorewall 3.0.2<br>
|
|
</span>
|
|
<pre>Problems Corrected in 3.0.2<br><br>1) A couple of typos in the one-interface sample configuration have<br> been corrected.<br><br>2) The 3.0.1 version of Shorewall was incompatible with old versions of<br> the Linux kernel (2.4.7 for example). The new code ignores errors<br> produced when Shorewall 3.x is run on these ancient kernels.<br><br>3) Arch Linux installation routines has been improved.<br><br>New Features in 3.0.2<br><br>1) A new Webmin macro has been added. This macro assumes that Webmin is<br> running on its default port (10000).<br></pre>
|
|
<span style="font-weight: bold;">2005-11-18
|
|
Shorewall 3.0.1</span><br>
|
|
<pre>Problems Corrected in 3.0.1 <br>
|
|
|
|
1) If the previous firewall configuration included a policy other than
|
|
ACCEPT in the nat, mangle or raw tables then Shorewall would not set
|
|
the policy to ACCEPT. This could result in a ruleset that rejected or
|
|
dropped all traffic.
|
|
|
|
2) The Makefile was broken such that 'make' didn't always work correctly.
|
|
|
|
3) If the SOURCE or DEST column in a macro body was non-empty and a dash
|
|
("-") appeared in the corresponding column of an invocation of that
|
|
macro, then an invalid rule was generated.
|
|
|
|
4) The comments in the /etc/shorewall/blacklist file have been updated to
|
|
clarify that the PORTS column refers to destination port number/service
|
|
names.
|
|
|
|
5) When CLAMPMSS is set to a value other than "No" and FASTACCEPT=Yes, the
|
|
order of the rules generated was incorrect causing RELATED TCP connections
|
|
to not have CLAMPMSS applied.
|
|
|
|
New Features in 3.0.1
|
|
|
|
1) To make the macro facility more flexible, Shorewall now examines the
|
|
contents of the SOURCE and DEST columns in both the macro body and in
|
|
the invocation and tries to create the intended rule. If the value in
|
|
the invocation appears to be an address (IP or MAC) or the name of an
|
|
ipset, then it is placed after the value in the macro body. Otherwise,
|
|
it is placed before the value in the macro body.
|
|
|
|
Example 1:
|
|
|
|
/etc/shorewall/macro.foo:
|
|
|
|
PARAM - 192.168.1.5 tcp http
|
|
|
|
/etc/shorewallrules:
|
|
|
|
foo/ACCEPT net loc
|
|
|
|
Effective rule:
|
|
|
|
ACCEPT net loc:192.168.1.5 tcp http
|
|
|
|
Example 2:
|
|
|
|
/etc/shorewall/macro.bar:
|
|
|
|
PARAM net loc tcp http
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
bar/ACCEPT - 192.168.1.5
|
|
|
|
Effective rule:
|
|
|
|
ACCEPT net loc:192.168.1.5 tcp http
|
|
</pre>
|
|
<p></p>
|
|
<hr style="width: 100%; height: 2px;"> <span style="font-weight: bold;">11/11/2005
|
|
Shorewall 3.0.0</span><br>
|
|
<pre>New Features in Shorewall 3.0.0<br><br>1) Error and warning messages are made easier to spot by using<br> capitalization (e.g., ERROR: and WARNING:).<br><br>2) A new option 'critical' has been added to<br> /etc/shorewall/routestopped. This option can be used to enable<br> communication with a host or set of hosts during the entire<br> "shorewall [re]start/stop" process. Listing a host with this option<br> differs from listing it without the option in several ways:<br><br> a) The option only affect traffic between the listed host(s) and the<br> firewall itself.<br><br> b) If there are any entries with 'critical', the firewall<br> will be completely opened briefly during start, restart and stop but<br> there will be no chance of any packets to/from the listed host(s)<br> being dropped or rejected.<br><br> Possible uses for this option are:<br><br> a) Root file system is NFS mounted. You will want to list the NFS server<br> in the 'critical' option.<br><br> b) You are running Shorewall in a Crossbeam environment<br> (www.crossbeam.com). You will want to list the Crossbeam interface<br> in this option<br><br>3) A new 'macro' feature has been added.<br><br> Macros are very similar to actions and can be used in similar<br> ways. The differences between actions and macros are as follows:<br><br> a) An action creates a separate chain with the same name as the<br> action (when logging is specified on the invocation of an action,<br> a chain beginning with "%" followed by the name of the action and<br> possibly followed by a number is created). When a macro is<br> invoked, it is expanded in-line and no new chain is created.<br><br> b) An action may be specified as the default action for a policy;<br> macros cannot be specified this way.<br><br> c) Actions must be listed in either /usr/share/shorewall/actions.std<br> or in /etc/shorewall/actions. Macros are defined simply by<br> placing their definition file in the CONFIG_PATH.<br><br> d) Actions are defined in a file with a name beginning with<br> "action." and followed by the name of the action. Macro files are<br> defined in a file with a name beginning with "macro.".<br><br> e) Actions may invoke other actions. Macros may not directly invoke<br> other macros although they may invoke other macros indirectly<br> through an action.<br><br> f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They<br> are allowed in a macro with the restriction that the a macro<br> containing one of these rules may not be invoked from an action.<br><br> g) The values specified in the various columns when you invoke a<br> macro are substituted in the corresponding column in each rule in<br> the macro. The first three columns get special treatment:<br><br> ACTION If you code PARAM as the action in a macro then<br> when you invoke the macro, you can include the<br> name of the macro followed by a slash ("/") and<br> an ACTION (either built-in or user-defined. All<br> instances of PARAM in the body of the macro will be<br> replaced with the ACTION.<br><br> Any logging applied when the macro is invoked is<br> applied following the same rules as for actions.<br><br> SOURCE and<br> DEST If the rule in the macro file specifies a value and<br> the invocation of the rule also specifies a value then<br> the value in the invocation is appended to the value<br> in the rule using ":" as a separator.<br><br> Example:<br><br> /etc/shorewall/macro.SMTP<br><br> PARAM - loc tcp 25<br><br> /etc/shorewall/rules:<br><br> SMTP/DNAT:info net 192.168.1.5<br><br> Would be equivalent to the following in the rules file:<br><br> DNAT:info net loc:192.168.1.5 tcp 25<br><br> Rest Any value in the invocation replaces the value in the<br> rule in the macro.<br><br> One additional restriction applies to the mixing of macros and<br> actions. Macros that are invoked from actions cannot themselves<br> invoke other actions.<br><br>4) If you have 'make' installed on your firewall, then when you use<br> the '-f' option to 'shorewall start' (as happens when you reboot),<br> if your /etc/shorewall/ directory contains files that were modified<br> after Shorewall was last restarted then Shorewall is started using<br> the config files rather than using the saved configuration.<br><br>5) The 'arp_ignore' option has been added to /etc/shorewall/interfaces<br> entries. This option sets<br> /proc/sys/net/ipv4/conf/<interface>/arp_ignore. By default, the<br> option sets the value to 1. You can also write arp_ignore=<value><br> where value is one of the following:<br><br> 1 - reply only if the target IP address is local address<br> configured on the incoming interface<br><br> 2 - reply only if the target IP address is local address<br> configured on the incoming interface and both with the sender's<br> IP address are part from same subnet on this interface<br><br> 3 - do not reply for local addresses configured with scope<br> host, only resolutions for global and link addresses are<br> replied<br><br> 4-7 - reserved<br><br> 8 - do not reply for all local addresses<br><br> WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN<br> PROXY ARP.<br><br>6) In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works<br> like "all" but also includes intrazone traffic. So the rule:<br><br> ACCEPT loc all+ tcp 22<br><br> would allow SSH traffic from loc->loc whereas<br><br> ACCEPT loc all tcp 22<br><br> does not.<br><br>7) A new FASTACCEPT option has been added to shorewall.conf.<br><br> Normally, Shorewall defers accepting ESTABLISHED/RELATED packets<br> until these packets reach the chain in which the original connection<br> was accepted. So for packets going from the 'loc' zone to the 'net'<br> zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'<br> chain.<br><br> If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are<br> accepted early in the INPUT, FORWARD and OUTPUT chains. If you set<br> FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or<br> RELATED sections of /etc/shorewall/rules.<br><br>8) Shorewall now generates an error if the 'norfc1918' option is<br> specified for an interface with an RFC 1918 address.<br><br>9) You may now specify "!" followed by a list of addresses in the<br> SOURCE and DEST columns of entries in /etc/shorewall/rules,<br> /etc/shorewall/tcrules and in action files and Shorewall will<br> generate the rule that you expect.<br><br> Example 1 (/etc/shorewall/rules):<br><br> #ACTION SOURCE DEST PROTO DEST PORT(S)<br> ACCEPT loc:!192.168.1.0/24,10.0.0.0/8 net tcp 80<br><br> That rule would allow loc->net HTTP access except for the local<br> networks 192.168.1.0/24 and 10.0.0.0/8.<br><br> Example 2 (/etc/shorewall/rules):<br><br> #ACTION SOURCE DEST PROTO DEST PORT(S)<br> ACCEPT loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \<br> net tcp 80<br><br> That rule would allow loc->net HTTP access from the local<br> network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.<br><br>10) Tunnel types "openvpnserver" and "openvpnclient" have been added<br> to reflect the introduction of client and server OpenVPN<br> configurations in OpenVPN 2.0.<br><br>11) The COMMAND variable is now set to 'restore' in restore<br> scripts. The value of this variable is sometimes of interest to<br> programmers providing custom /etc/shorewall/tcstart scripts.<br><br>12) Previously, if you defined any intra-zone rule(s) then any traffic<br> not matching the rule(s) was subject to normal policies (which<br> usually turned out to involve the all->all REJECT policy). Now, the<br> intra-zone ACCEPT policy will still be in effect in the presence of<br> intra-zone rules. That policy can still be overridden by an<br> explicit policy in your /etc/shorewall/policy file.<br><br> Example:<br><br> /etc/shorewall/rules:<br><br> DNAT loc:!192.168.1.4 loc:192.168.1.4:3128 tcp 80<br><br> Any other loc->loc traffic will still be accepted. If you want to<br> also log that other loc->loc traffic at the info log level then<br> insert this into /etc/shorewall/policy:<br><br> #SOURCE DEST POLICY LOG LEVEL<br> loc loc ACCEPT info<br><br>13) Prior to Shorewall 2.5.3, the rules file only controlled packets in<br> the Netfilter states NEW and INVALID. Beginning with this release,<br> the rules file can also deal with packets in the ESTABLISHED and<br> RELATED states.<br><br> The /etc/shorewall/rules file may now be divided into<br> "sections". Each section is introduced by a line that begins with<br> the keyword SECTION followed by the section name. Sections<br> are as listed below and must appear in the order shown.<br><br> ESTABLISHED<br><br> Rules in this section apply to packets in the ESTABLISHED<br> state.<br><br> RELATED<br><br> Rules in this section apply to packets in the RELATED state.<br><br> NEW<br><br> Rules in this section apply to packets in the NEW and INVALID<br> states.<br><br> Rules in the ESTABLISHED and RELATED sections are limited to the<br> following ACTIONs:<br><br> ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.<br><br> Macros may be used in these sections provided that they expand to<br> only these ACTIONs.<br><br> At the end of the ESTABLISHED and RELATED sections, there is an<br> implicit "ALLOW all all all" rule.<br><br> RESTRICTION: If you specify FASTACCEPT=Yes in<br> /etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED<br> sections must be empty.<br><br>14) The value 'ipp2p' is once again allowed in the PROTO column of<br> the rules file. It is recommended that rules specifying 'ipp2p'<br> only be included in the ESTABLISHED section of the file.<br><br><br>15) Shorewall actions lack a generalized way to pass parameters to an<br> extension script associated with an action. To work around this<br> lack, some users have used the log tag as a parameter. This works<br> but requires that a log level other than 'none' be specified when<br> the action is invoked. Beginning with this release, you can invoke<br> an action with 'none'.<br><br> Example:<br><br> #ACTION SOURCE DEST<br> A:none:these,are,parameters $FW net<br><br> When /etc/shorewall/A is invoked, the LEVEL variable will be empty<br> but the TAG variable will contain "these,are,parameters" which<br> can be easily parsed to isolate "these", "are" and "parameters":<br><br> ifs=$IFS<br> IFS=,<br> set -- $TAG<br> IFS=$ifs<br><br> Now, $1 = these, $2 = are and $3 = parameters<br><br>16) The "shorewall check" command now checks the /etc/shorewall/masq,<br> /etc/shorewall/blacklist, /etc/shorewall/proxyarp,<br> /etc/shorewall/nat and /etc/shorewall/providers files.<br><br>17) Arne Bernin's "tc4shorewall" package has been integrated into<br> Shorewall.<br><br> See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.<br><br> Thanks, Arne!<br><br>18) When /usr/share/shorewall/functions is loaded it now sets<br><br> SHOREWALL_LIBRARY=Loaded<br><br> Application code such as /etc/shorewall/tcstart may test that<br> variable to determine if the library has been loaded into the<br> current shell process.<br><br>19) The install.sh script now does a much cleaner job of backing up the<br> current installation. It copies the directories /etc/shorewall,<br> /usr/share/shorewall and /var/lib/shorewall to a directory of the<br> same name with "-$VERSION.bkout" appended. The init script and<br> /sbin/shorewall are backed up to the /usr/share/shorewall and<br> /var/lib/shorewall directories respectively. This makes it very<br> simple to remove the backups:<br><br> rm -rf /etc/shorewall-*.bkout<br> rm -rf /usr/share/shorewall-*.bkout<br> rm -rf /var/lib/shorewall-*.bkout<br><br>20) A new '-n' option has been added to the "start", "restart",<br> "restore", "stop" and "try" commands. This option instructs<br> Shorewall to not alter the routing in any way.<br><br> This option is useful when you have a multi-ISP environment because<br> it prevents the route cache from being flushed which preserves the<br> mapping of end-point address pairs to routes.<br><br>21) The output of "shorewall dump" now includes a capabilities report<br> such as the one produced by "shorewall show capabilities".<br><br>22) The "plain" zone type has been replaced by "ipv4". The types<br> "IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",<br> "ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".<br><br>23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been<br> removed as have the 'newnotsyn' options in /etc/shorewall/interfaces<br> and /etc/shorewall/hosts. See the Migration Considerations for<br> instructions if you wish to block "new-not-syn" TCP packets.<br><br>24) The "shorewall show zones" command now displays the zone type. You<br> must have restarted Shorewall using this release before this feature<br> will work correctly.<br><br>25) The multi-ISP code now requires that that you set MARK_IN_FORWARD_CHAIN=Yes<br> in shorewall.conf. This is done to ensure that "shorewall refresh" will<br> work correctly.<br><br>26) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"<br> keyword in the PROTOCOL column of the relevant files, the following<br> values may be specified:<br><br> ipp2p:tcp Equivalent to ipp2p and matches TCP traffic<br> only.<br> ipp2p:udp Matches UDP traffic.<br> ipp2p:all Matches both UDP and TCP traffic. You may<br> not specify a SOURCE PORT with this PROTOCOL.<br><br>27) Normally MAC verification triggered by the 'maclist' interface and host<br> options is done out of the INPUT and FORWARD chains of the filter table.<br> Users have reported that under some circumstances, MAC verification is<br> failing for forwarded packets when the packets are being forwarded out<br> of a bridge.<br><br> To work around this problem, a MACLIST_TABLE option has been added to<br> shorewall.conf. The default value is MACLIST_TABLE=filter which results<br> in the current behavior. If MACLIST_TABLE=mangle then filtering will<br> take place out of the PREROUTING chain of the mangle table. Because<br> the REJECT target may not be used in the PREROUTING chain, the settings<br> MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.<br><br>28) The sample configurations are now packaged with the product. They are<br> in the Samples directory on the tarball and are in the RPM they are<br> in the Samples sub-directory of the Shorewall documentation<br> directory.<br></pre>
|
|
<span style="font-weight: bold;">10/31/2005
|
|
Shorewall 2.4.6<br>
|
|
<br>
|
|
</span>Problems Corrected in 2.4.6<br>
|
|
<ol>
|
|
<li>"shorewall refresh" would fail if there were entries in
|
|
/etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.</li>
|
|
<li>An unprintable character in a comment caused /sbin/shorewall to
|
|
fail when used with a light-weight shell like 'dash'.</li>
|
|
<li>When using some flavors of 'ash', certain /sbin/shorewall
|
|
commands produced 'ipset: not found' messages.</li>
|
|
<li>Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0
|
|
but the implementation was incomplete. It has now been completed and is
|
|
documented in the /etc/shorewall/tunnels file.</li>
|
|
<li>The test that Shorewall uses to detect the availability of the
|
|
owner match capability has been changed to avoid the generation of
|
|
ipt_owner messages under kernel 2.6.14.</li>
|
|
</ol>
|
|
New Features in 2.4.6<br>
|
|
<ol>
|
|
<li>Normally MAC verification triggered by the 'maclist' interface
|
|
and host options is done out of the INPUT and FORWARD chains of the
|
|
filter table. Users have reported that under some circulstances, MAC
|
|
verification is failing for forwarded packets when the packets are
|
|
being forwarded out of a bridge.<br>
|
|
<br>
|
|
To work around this problem, a MACLIST_TABLE option has been added to
|
|
shorewall.conf. The default value is MACLIST_TABLE=filter which results
|
|
in the current behavior. If MACLIST_TABLE=mangle then filtering will
|
|
take place out of the PREROUTING chain of the mangle table. Because the
|
|
REJECT target may not be used in the PREROUTING chain, the settings
|
|
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.</li>
|
|
<li>A "dump" command has been added to /sbin/shorewall for
|
|
compatibility with Shorewall 3.0. In 2.4.6, the "dump" command provides
|
|
the same output as the "status".<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">Old News <a href="oldnews.html">here</a><br>
|
|
</span>
|
|
</body>
|
|
</html>
|