shorewall_code/web/News.htm
2006-02-23 20:43:53 +00:00

349 lines
32 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="revised" content="$Id$" />
<title>Shorewall News</title>
</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-2006 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 moving to Subversion -->
<span style="font-weight: bold;">2006-02-22 Shorewall moved to Subversion <br/> </span>
<pre> Effectively today, Shorewall source code repository was migrated to Subversion SCM.
Please read <a href="https://sourceforge.net/svn/?group_id=22587">https://sourceforge.net/svn/?group_id=22587 </a>
and <a href="http://www.shorewall.net/download.htm#SVN"> http://www.shorewall.net/download.htm#SVN </a>
for more information.
</pre>
<!-- Moving to Subversion ENDS -->
<!-- Shorewall Release 3.0.5 -->
<span style="font-weight: bold;">2006-02-10 Shorewall 3.0.5<br>
</span>
<pre>Problems corrected in Shorewall 3.0.5
1) Previously, if /etc/shorewall/ipsets existed, it was run when Shorewall starts
but not when Shorewall was restored.
2) When using the NETKEY IPSEC implementation in kernel 2.6 but without the
policy match patch and the Netfilter/IPSEC patches, previously an
entry in /etc/shorewall/tunnels was not sufficient in cases where:
a) gw&lt;-&gt;gw traffic was encrypted
b) The gw&lt;-&gt;gw policy through the tunnel was not ACCEPT
Thanks to Tuomo Soini, this has been corrected. By simply including the
remote VPN zone in the GATEWAY ZONE column for the tunnel's entry, no
additional rules are required.
3) Extra blank output lines are no longer produced by install.sh (patch
courtesy of Tuomo Soini).
4) TCP packets sent to QUEUE by rules in the ESTABLISHED section of the
rules file previously didn't work (they had the "--syn" parameter
added to them which resulted in a rule that no traffic would match).
WARNING: If you use the QUEUE target from an action, Shorewall will
still insert --syn if the protocol is tcp. So you don't want to
invoke such an action from the ESTABLISHED section of the rules
file.
5) The description of the SOURCE column in /etc/shorewall/rules has been
improved (patch courtesy of Ed Suominen).
6) The 'allow', 'drop' and 'reject' commands no longer produce iptables
errors when executed while Shorewall is not started.
7) The spelling of "maximize-throughput" has been corrected in the code
that implements tcclasses parsing. Patch courtesy of Paul Traina.
8) Shorewall now generates the correct match for devices in
/etc/shorewall/tcdevices that are actually bridge ports.
New Features in Shorewall 3.0.5
1) The facilities available for dealing with the TOS field in
/etc/shorewall/tcclasses has been expended. The OPTIONS field is now may
contain a comma-separates list of the following:
tos=0x&lt;value&gt;[/0x&lt;mask&gt;] (mask defaults to 0xff)
- this lets you define a classifier
for the given &lt;value&gt;/&lt;mask&gt; combination
of the IP packet's TOS/Precedence/DiffSrv
octet (aka the TOS byte). Please note,
classifiers override all mark settings,
so if you define a classifer for a class,
all traffic having that mark will go in it
regardless of any mark set on the packet
by a firewall/mangle filter.
NOTE: multiple tos= statements may be
applied per class and per interface, but
a given value/mask pair is valid for only
ONE class per interface.
tos-&lt;tosname&gt; - aliases for the following TOS octet
value and mask encodings. TOS encodings
of the "TOS byte" have been deprecated in
favor of diffserve classes, but programs
like ssh, rlogin, and ftp still use them.
tos-minimize-delay 0x10/0x10
tos-maximize-throughput 0x08/0x08
tos-maximize-reliability 0x04/0x04
tos-minimize-cost 0x02/0x02
tos-normal-service 0x00/0x1e
tcp-ack - defined causes an tc filter to
be created that puts all tcp ack
packets on that interface that have
an size of &lt;=64 Bytes to go in this
class. This is useful for speeding up
downloads. Please note that the size
of the ack packets is limited to 64
bytes as some applications (p2p for
example) use to make every packet an
ack packet which would cause them
all into here. We want only packets
WITHOUT payload to match, so the size
limit.
NOTE: This option is only valid for
ONE class per interface.
Note that the semantics of 'tos-&lt;tosname&gt;' have changed slightly. Previously,
these were tested using a mask of 0xff (example: tos-minimize-delay was
equivalent to 0x10/0xff). Now each bit is tested individually.
This enhancement is courtesy of Paul Traina.
</pre>
<span style="font-weight: bold;">2006-01-05 Shorewall 3.0.4<br>
</span>
<pre>Problems Corrected in 3.0.4<br><br>1) &nbsp;The shorewall.conf file is once again "console friendly". Patch is<br>&nbsp; &nbsp; courtesy of Tuomo Soini.<br><br>2) &nbsp;A potential security hole has been closed. Previously, Shorewall ACCEPTed<br>&nbsp; &nbsp; all traffic from a bridge port that was sent back out on the same port. If<br>&nbsp; &nbsp; the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,<br>&nbsp; &nbsp; xenbr0:vif+), this could lead to traffic being passed in variance with the<br>&nbsp; &nbsp; supplied policies and rules.<br><br>3) &nbsp;Previously, an intra-zone policy of NONE would cause a startup error. That<br>&nbsp; &nbsp; problem has been corrected.<br><br>4) &nbsp;When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not<br>&nbsp; &nbsp; add the retained aliases. This means that the following sequence of<br>&nbsp; &nbsp; events resulted in missing aliases:<br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall start<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall restart<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall save<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; reboot<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall -f start (which is the default during boot up)<br><br>5) &nbsp;When a 2.x standard action is invoked with a log level (example<br>&nbsp; &nbsp; "AllowPing:info"), logging does not occur.<br><br>New Features in 3.0.4<br><br>1) &nbsp;By popular demand, the 'Limit' action described at<br>&nbsp; &nbsp; http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard<br>&nbsp; &nbsp; action. Limit requires 'recent match' support in your kernel and iptables.<br><br>2) &nbsp;DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This<br>&nbsp; &nbsp; change is reported to improve Java startup time on some distributions.<br><br>3) &nbsp;Shorewall now contains support for wildcard ports. In<br>&nbsp; &nbsp; /etc/shorewall/hosts, you may specify the port name with trailing "+" then <br>&nbsp; &nbsp; use specific port names in rules.<br><br>&nbsp; &nbsp; Example:<br><br>&nbsp; &nbsp; /etc/shorewall/hosts<br><br>&nbsp; &nbsp; &nbsp; &nbsp; vpn &nbsp; &nbsp; &nbsp;br0:tap+<br><br>&nbsp; &nbsp; /etc/shorewall/rules<br><br>&nbsp; &nbsp; &nbsp; &nbsp; DROP &nbsp; &nbsp; &nbsp;vpn:tap0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vpn:tap1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;udp &nbsp; &nbsp;9999<br><br>4) &nbsp;For the benefit of those who run Shorewall on distributions that don't <br>&nbsp; &nbsp; autoload kernel modules, /etc/shorewall/modules now contains load commands <br>&nbsp; &nbsp; for a wide range of Netfilter modules.<br></pre>
<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) &nbsp;When MACLIST_TABLE=mangle and an interface is enabled for DHCP
(the<br>
&nbsp; &nbsp; 'dhcp' option is specified in /etc/shorewall/interfaces)
then broadcasts<br>
&nbsp; &nbsp; on UDP port 67 to address 255.255.255.255 from address
0.0.0.0 were being<br>
&nbsp; &nbsp; dropped and logged. While this did not prevent the client
from acquiring<br>
&nbsp; &nbsp; an IP address, it could result in lots of log messages.<br>
<br>
2) &nbsp;Entries for openvpn tunnels (including openvpnclient and<br>
&nbsp; &nbsp; openvpnserver) that specify a port but no protocol cause
startup<br>
&nbsp; &nbsp; errors as follows:<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;iptables v1.3.3: unknown
protocol `1194' specified<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Try `iptables -h' or 'iptables
--help' for more information.<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ERROR: Command
"/usr/sbin/iptables -A net2fw -p 1194 -s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0.0.0.0/0 --sport 1194 -j
ACCEPT" Failed<br>
<br>
&nbsp; &nbsp; The problem may be worked around by specifying the
protocol as well<br>
&nbsp; &nbsp; (e.g., "openvpn:udp:3455).<br>
<br>
3) &nbsp;If the previous firewall configuration included a policy other
than<br>
&nbsp; &nbsp; ACCEPT in the nat, mangle or raw tables then Shorewall
would not set<br>
&nbsp; &nbsp; the policy to ACCEPT. This could result in a ruleset that
rejected or<br>
&nbsp; &nbsp; dropped all traffic.<br>
<br>
4) &nbsp;Specifying an interface name in the SOURCE column <br>
&nbsp; &nbsp; 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/&lt;interface&gt;/arp_ignore. By default, the<br> option sets the value to 1. You can also write arp_ignore=&lt;value&gt;<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-&gt;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-&gt;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-&gt;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-&gt;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-&gt;loc traffic will still be accepted. If you want to<br> also log that other loc-&gt;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>