mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-27 01:53:27 +01:00
723d0823be
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2002 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
1044 lines
45 KiB
HTML
1044 lines
45 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
|
|
<title>Shoreline Firewall (Shorewall) 2.0</title>
|
|
<base target="_self">
|
|
<meta name="GENERATOR" content="OpenOffice.org 1.1.1 (Linux)">
|
|
<meta name="CREATED" content="20040920;15031500">
|
|
<meta name="CHANGED" content="20040920;15183300">
|
|
</head>
|
|
<body dir="ltr" lang="en-US">
|
|
<h1>Shorewall 2.x</h1>
|
|
<p><b>Tom Eastep</b><br>
|
|
<br>
|
|
The information on this site applies only
|
|
to 2.x releases of Shorewall. For older versions:</p>
|
|
<ul>
|
|
<li>
|
|
<p style="margin-bottom: 0in;">The 1.4 site is <a
|
|
href="http://www.shorewall.net/1.4" target="_top">here.</a></p>
|
|
</li>
|
|
<li>
|
|
<p style="margin-bottom: 0in;">The 1.3 site is <a
|
|
href="http://www.shorewall.net/1.3" target="_top">here.</a> </p>
|
|
</li>
|
|
<li>
|
|
<p>The 1.2 site is <a href="http://shorewall.net/1.2/"
|
|
target="_top">here</a>. </p>
|
|
</li>
|
|
</ul>
|
|
<p>The current 2.2 Stable Release is 2.2.2 -- Here are the <a
|
|
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/releasenotes.txt">release
|
|
notes</a> and here are the <a
|
|
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/known_problems.txt">known
|
|
problems</a> and <a
|
|
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/errata/">updates</a>.<br>
|
|
</p>
|
|
<p><a
|
|
href="http://lists.shorewall.net/pipermail/shorewall-announce/2004-December/000451.html"><span
|
|
style="font-weight: bold;">End of
|
|
support life for Shorewall 1.4 -- Upgrading to Shorewall 2.2</span></a><br>
|
|
<br>
|
|
Copyright © 2001-2005 Thomas M. Eastep</p>
|
|
<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 “<a href="GnuCopyright.htm" target="_self">GNU
|
|
Free Documentation License</a>”.</p>
|
|
<p>2005-03-12</p>
|
|
<hr>
|
|
<h3>Table of Contents</h3>
|
|
<p style="margin-left: 0.42in; margin-bottom: 0in;"><a href="#Intro">Introduction
|
|
to Shorewall</a></p>
|
|
<p style="margin-left: 0.83in; margin-bottom: 0in;"><a href="#Glossary">Glossary</a><br>
|
|
<a href="#WhatIs">What
|
|
is Shorewall?</a><br>
|
|
<a href="#GettingStarted">Getting Started with
|
|
Shorewall</a><br>
|
|
<a href="#Info">Looking for Information?</a><br>
|
|
<a href="#Mandrake">Running
|
|
Shorewall on Mandrake® with a two-interface setup?</a><br>
|
|
<a href="#License">License</a></p>
|
|
<p style="margin-bottom: 0in; margin-left: 40px;"><a href="#2_0_10">News</a></p>
|
|
<p style="margin-left: 0.83in; margin-bottom: 0in;"><span
|
|
style="text-decoration: underline;"></span><a href="#2_2_2">Shorewall
|
|
2.2.2</a><br>
|
|
<a href="#2_2_1">Shorewall
|
|
2.2.1</a><a href="#End_of_Support"><br>
|
|
</a><a href="#End_of_Support">End of Support for Shorewall 1.4</a><br>
|
|
<a href="#2_0_16">Shorewall
|
|
2.0.16</a><br>
|
|
<a href="#2_2_0">Shorewall
|
|
2.2.0</a><br>
|
|
<br>
|
|
</p>
|
|
<div style="margin-left: 40px;"><a href="#Leaf">Leaf</a><br>
|
|
<br>
|
|
<a href="#OpenWRT">OpenWRT</a><br>
|
|
</div>
|
|
<p style="margin-left: 40px;"><a href="#Donations">Donations</a></p>
|
|
<h2><a name="Intro"></a>Introduction to Shorewall</h2>
|
|
<h3><a name="Glossary"></a>Glossary</h3>
|
|
<ul>
|
|
<li>
|
|
<p style="margin-bottom: 0in;"><a href="http://www.netfilter.org/"
|
|
target="_top">Netfilter</a> - the packet filter facility built into
|
|
the 2.4 and later Linux kernels. </p>
|
|
</li>
|
|
<li>
|
|
<p style="margin-bottom: 0in;">ipchains - the packet filter
|
|
facility built into the 2.2 Linux kernels. Also the name of the utility
|
|
program used to configure and control that facility. Netfilter can be
|
|
used in ipchains compatibility mode. </p>
|
|
</li>
|
|
<li>
|
|
<p>iptables - the utility program used to configure and control
|
|
Netfilter. The term 'iptables' is often used to refer to the
|
|
combination of iptables+Netfilter (with Netfilter not in ipchains
|
|
compatibility mode). </p>
|
|
</li>
|
|
</ul>
|
|
<h3><a name="WhatIs"></a>What is Shorewall?</h3>
|
|
<p style="margin-left: 0.42in;">The Shoreline Firewall, more commonly
|
|
known as "Shorewall", is a high-level tool for configuring
|
|
Netfilter. You describe your firewall/gateway requirements using
|
|
entries in a set of configuration files. Shorewall reads those
|
|
configuration files and with the help of the iptables utility,
|
|
Shorewall configures Netfilter to match your requirements. Shorewall
|
|
can be used on a dedicated firewall system, a multi-function
|
|
gateway/router/server or on a standalone GNU/Linux system. Shorewall
|
|
does not use Netfilter's ipchains compatibility mode and can thus
|
|
take advantage of Netfilter's <a
|
|
href="http://www.cs.princeton.edu/%7Ejns/security/iptables/iptables_conntrack.html"
|
|
target="_top">connection
|
|
state tracking capabilities</a>.<br>
|
|
<br>
|
|
Shorewall is <u>not</u> a
|
|
daemon. Once Shorewall has configured Netfilter, it's job is
|
|
complete. After that, there is no Shorewall code running although the
|
|
<a href="starting_and_stopping_shorewall.htm">/sbin/shorewall program
|
|
can be used at any time to monitor the Netfilter firewall</a>.</p>
|
|
<h3><a name="GettingStarted"></a>Getting Started with Shorewall</h3>
|
|
<p style="margin-left: 0.42in;">New to Shorewall? Start by selecting
|
|
the <a href="shorewall_quickstart_guide.htm">QuickStart Guide</a>
|
|
that most closely matches your environment and follow the step by
|
|
step instructions.</p>
|
|
<h3><a name="Info"></a>Looking for Information?</h3>
|
|
<p style="margin-left: 0.42in;">The <a href="Documentation_Index.html">Documentation
|
|
Index</a> is a good place to start as is the Site Search in the
|
|
frame above. </p>
|
|
<h3><a name="Mandrake"></a>Running Shorewall on Mandrake® with a
|
|
two-interface setup?</h3>
|
|
<p style="margin-left: 0.42in;">If so, the documentation on this site
|
|
will not apply directly to your setup. If you want to use the
|
|
documentation that you find here, you will want to consider
|
|
uninstalling what you have and installing a setup that matches the
|
|
documentation on this site. See the <a href="two-interface.htm">Two-interface
|
|
QuickStart Guide</a> for details.<br>
|
|
<br>
|
|
<b>Update: </b>I have been
|
|
informed by Mandrake Development that this problem has been corrected
|
|
in Mandrake 10.0 Final (the problem still exists in the 10.0
|
|
Community release).</p>
|
|
<h3><a name="License"></a>License</h3>
|
|
<p style="margin-left: 0.42in;">This program is free software; you can
|
|
redistribute it and/or modify it under the terms of <a
|
|
href="http://www.gnu.org/licenses/gpl.html">Version
|
|
2 of the GNU General Public License</a> as published by the Free
|
|
Software Foundation.</p>
|
|
<p style="margin-left: 0.42in;">This program is distributed in the
|
|
hope that it will be useful, but WITHOUT ANY WARRANTY; without even
|
|
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
|
|
PURPOSE. See the GNU General Public License for more detail.</p>
|
|
<p style="margin-left: 0.42in;">You should have received a copy of the
|
|
GNU General Public License along with this program; if not, write to
|
|
the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
|
|
02139, USA</p>
|
|
<p style="margin-left: 0.42in;">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 "GNU Free
|
|
Documentation License". </p>
|
|
<hr>
|
|
<h2><a name="News"></a>News</h2>
|
|
<span style="font-weight: bold;"><a name="2_2_2"></a>03/12/2005
|
|
Shorewall 2.2.2<br>
|
|
</span><br>
|
|
Problems Corrected:<br>
|
|
<ol>
|
|
<li>The SOURCE column in the /etc/shorewall/tcrules file now
|
|
correctly allows IP ranges (assuming that your iptables and kernel
|
|
support ranges).<br>
|
|
</li>
|
|
<li>If A is a user-defined action and you have file /etc/shorewall/A
|
|
then when that file is invoked by Shorewall during [re]start, the $TAG
|
|
value may be incorrect.</li>
|
|
<li>Previously, if an iptables command generating a logging rule
|
|
failed, the Shorewall [re]start was still successful. This error is now
|
|
considered fatal and Shorewall will be either restored from the last
|
|
save (if any) or it will be stopped.</li>
|
|
<li>The port numbers for UDP and TCP were previously reversed in the
|
|
/usr/share/shorewall/action.AllowPCA file.</li>
|
|
<li>Previously, the 'install.sh' script did not update the
|
|
/usr/share/shorewall/action.* files.</li>
|
|
<li>Previously, when an interface name appeared in the DEST column of
|
|
/etc/shorewall/tcrules, the name was not validated against the set of
|
|
defined interfaces and bridge ports.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
<ol>
|
|
<li>The SOURCE column in the /etc/shorewall/tcrules file now allows
|
|
$FW to be optionally followed by ":" and a host/network address or
|
|
address range.</li>
|
|
<li>Shorewall now clears the output device only if it is a terminal.
|
|
This avoids ugly control sequences being placed in files when
|
|
/sbin/shorewall output is redirected.</li>
|
|
<li>The output from 'arp -na' has been added to the 'shorewall
|
|
status' display.</li>
|
|
<li>The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges
|
|
to appear in port lists handled by "multiport match". If Shorewall
|
|
detects this capability, it will use "multiport match" for port lists
|
|
containing port ranges. Be cautioned that each port range counts for
|
|
TWO ports and a port list handled with "multiport match" can still
|
|
specify a maximum of 15 ports.<br>
|
|
<br>
|
|
As always, if a port list in /etc/shorewall/rules is incompatible with
|
|
"multiport match", a separate iptables rule will be generated for each
|
|
element in the list.</li>
|
|
<li>Traditionally, the RETURN target in the 'rfc1918' file has caused
|
|
'norfc1918' processing to cease for a packet if the packet's source IP
|
|
address matches the rule. Thus, if you have:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">
|
|
SUBNETS TARGET</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
192.168.1.0/24 RETURN</span><br>
|
|
<br>
|
|
then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though
|
|
you also have:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">
|
|
SUBNETS TARGET</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
10.0.0.0/8 logdrop</span><br>
|
|
<br>
|
|
Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to
|
|
be logged and dropped since while the packet's source matches the
|
|
RETURN rule, the packet's destination matches the 'logdrop' rule.<br>
|
|
<br>
|
|
If not specified or specified as empty (e.g., RFC1918_STRICT="") then
|
|
RFC1918_STRICT=No is assumed.<br>
|
|
<br>
|
|
WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
|
|
support 'Connection Tracking' match.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_1"></a>02/15/2005
|
|
Shorewall 2.2.1<br>
|
|
<br>
|
|
</span>This release rolls up the fixes for bugs found in the first 2-3
|
|
weeks of deployment of Shorewall 2.2.<br>
|
|
<ol>
|
|
<li>The /etc/shorewall/policy file contained a misleading comment and
|
|
both that file and the /etc/shorewall/zones file lacked examples.</li>
|
|
<li>Shorewall previously used root's default umask which could cause
|
|
files in /var/lib/shorewall to be world-readable. Shorewall now uses
|
|
umask 0177.</li>
|
|
<li>In log messages produced by logging a built-in action, the packet
|
|
disposition was displayed incorrectly.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
|
|
rejNotSyn:ULOG
|
|
all
|
|
all
|
|
tcp<br>
|
|
<br>
|
|
produces the log message:<br>
|
|
<br>
|
|
Feb
|
|
12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
|
|
<br>
|
|
rather than<br>
|
|
<br>
|
|
Feb
|
|
12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
|
|
<br>
|
|
</li>
|
|
<li>The comments regarding built-in actions in
|
|
/usr/share/shorewall/actions.std have been corrected.</li>
|
|
<li>The /etc/shorewall/policy file in the LRP package was missing the
|
|
'all->all' policy.<br>
|
|
</li>
|
|
</ol>
|
|
<a name="End_of_Support"><span style="font-weight: bold;">02/05/2005
|
|
End of Support for Shorewall 1.4<br>
|
|
<br>
|
|
</span>Effective today, support for Shorewall 1.4 has been
|
|
discontinued. See the link at the top of this article for upgrade
|
|
information.<br>
|
|
<br>
|
|
</a><span style="font-weight: bold;"><a name="2_0_16"></a>02/01/2005
|
|
Shorewall 2.0.16<br>
|
|
</span><br>
|
|
This release back-ports the DROPINVALID shorewall.conf option from
|
|
2.2.0.<br>
|
|
<ol>
|
|
<li>Recent 2.6 kernels include code that evaluates TCP packets based
|
|
on TCP Window analysis. This can cause packets that were previously
|
|
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
|
|
<br>
|
|
The new kernel code can be disabled by including this command in your
|
|
/etc/shorewall/init file:<br>
|
|
<br>
|
|
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
|
|
<br>
|
|
Additional kernel logging about INVALID TCP packets may be obtained by
|
|
adding this command to /etc/shorewall/init:<br>
|
|
<br>
|
|
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
|
|
<br>
|
|
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
|
DROPINVALID option allows INVALID packets to be passed through the
|
|
normal rules chains by setting DROPINVALID=No.<br>
|
|
<br>
|
|
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
|
DROPINVALID=Yes is assumed.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0"></a>02/01/2005
|
|
Shorewall 2.2.0<br>
|
|
<br>
|
|
</span>New Features:<br>
|
|
<ol>
|
|
<li>ICMP packets that are in the INVALID state are now dropped by the
|
|
Reject and Drop default actions. They do so using the new 'dropInvalid'
|
|
builtin action. An 'allowInvalid' builtin action is also provided which
|
|
accepts packets in that state.</li>
|
|
<li>The /etc/shorewall/masq file INTERFACE column now allows
|
|
additional options.<br>
|
|
<br>
|
|
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
|
|
defined in the /etc/shorewall/nat file. If you preceed the interface
|
|
name with a plus sign ("+") then the rule will be evaluated before
|
|
one-to-one NAT.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
+eth0<br>
|
|
+eth1:192.0.2.32/27<br>
|
|
<br>
|
|
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
|
|
following the interface name by ":" but no digit. <br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
eth0:<br>
|
|
eth1::192.0.2.32/27<br>
|
|
+eth3:<br>
|
|
<br>
|
|
</li>
|
|
<li>Similar to 2), the /etc/shorewall/nat file INTERFACE column now
|
|
allows you to override the setting of ADD_IP_ALIASES=Yes by following
|
|
the interface name with ":" but no digit.</li>
|
|
<li>All configuration files in the Shorewall distribution with the
|
|
exception of shorewall.conf are now empty. In particular, the
|
|
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
|
|
files now have no active entries. Hopefully this will stop the
|
|
questions on the support and development lists regarding why the
|
|
default entries are the way they are.</li>
|
|
<li>Previously, including a log level (and optionally a log tag) on a
|
|
rule that specified a user-defined (or Shorewall-defined) action would
|
|
log all traffic passed to the action. Beginning with this release,
|
|
specifying a log level in a rule that specifies a user- or
|
|
Shorewall-defined action will cause each rule in the action to be
|
|
logged with the specified level (and tag).<br>
|
|
<br>
|
|
The extent to which logging of action rules occurs is goverend by the
|
|
following:</li>
|
|
<ul>
|
|
<li>When you invoke an action and specify a log level, only those
|
|
rules in the action that have no log level will be changed to log at
|
|
the level specified at the action invocation.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/action.foo:<br>
|
|
<br>
|
|
ACCEPT - -
|
|
tcp 22<br>
|
|
bar:info<br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
foo:debug fw net<br>
|
|
<br>
|
|
Logging in the invoked 'foo' action will be:<br>
|
|
<br>
|
|
ACCEPT:debug - -
|
|
tcp 22<br>
|
|
bar:info<br>
|
|
<br>
|
|
</li>
|
|
<li>If you follow the log level with "!" then logging will be at
|
|
that level for all rules recursively invoked by the action<br>
|
|
<br>
|
|
Example: /etc/shorewall/action.foo:<br>
|
|
<br>
|
|
<b>Update: </b>I've been
|
|
informed by Mandrake Development that this problem has been corrected
|
|
in Mandrake 10.0 Final (the problem still exists in the 10.0
|
|
Community release).<br>
|
|
ACCEPT - -
|
|
tcp 22<br>
|
|
bar:info<br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
foo:debug! fw net<br>
|
|
<br>
|
|
Logging in the invoke 'foo' action will be:<br>
|
|
<br>
|
|
ACCEPT:debug - -
|
|
tcp 22<br>
|
|
bar:debug!<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</ol>
|
|
<div style="margin-left: 40px;">This change has an effect on extension
|
|
scripts used with user-defined actions. If you define an action 'acton'
|
|
and you have an /etc/shorewall/acton script then when that script is
|
|
invoked, the following three variables will be set for use by the
|
|
script:<br>
|
|
<br>
|
|
<div style="margin-left: 40px;">$CHAIN = the name of the chain where
|
|
your rules are to be placed. When logging is used on an action
|
|
invocation, Shorewall creates a chain with a slightly different name
|
|
from the action itself.<br>
|
|
$LEVEL = Log level. If empty, no logging was specified.<br>
|
|
$TAG = Log Tag.<br>
|
|
<br>
|
|
</div>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
acton:info:test<br>
|
|
<br>
|
|
Your /etc/shorewall/acton file will be run with:<br>
|
|
<br>
|
|
<div style="margin-left: 40px;">$CHAIN="%acton1<br>
|
|
$LEVEL="info"<br>
|
|
$TAG="test"<br>
|
|
</div>
|
|
</div>
|
|
<br>
|
|
<ol start="6">
|
|
<li>The /etc/shorewall/startup_disabled file is no longer created
|
|
when
|
|
Shorewall is first installed. Rather, the variable STARTUP_ENABLED is
|
|
set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall
|
|
to start, that variable's value must be set to 'Yes'. This change
|
|
accomplishes two things:</li>
|
|
<ul>
|
|
<li>It prevents Shorewall from being started prematurely by the
|
|
user's initialization scripts.</li>
|
|
<li>It causes /etc/shorewall/shorewall.conf to be modified so that
|
|
it won't be replaced by upgrades using RPM.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
<li>Support has been added for the 2.6 Kernel IPSEC implementation.
|
|
To use this support, you must have installed the IPSEC policy match
|
|
patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The
|
|
policy match patch affects both your kernel and iptables. There are two
|
|
ways to specify that IPSEC is to be used when communicating with a set
|
|
of hosts; both methods involve the new /etc/shorewall/ipsec file:</li>
|
|
<ol style="list-style-type: lower-alpha;">
|
|
<li>If encrypted communication is used with all hosts in a zone,
|
|
then you can designate the zone as an "ipsec" zone by placing 'Yes" in
|
|
the IPSEC ONLY column in /etc/shorewall/ipsec:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">#ZONE
|
|
IPSEC OPTIONS ...</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">#
|
|
ONLY</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
Yes</span><span
|
|
style="font-family: sans-serif;"></span><br>
|
|
<br>
|
|
The hosts in the zone (if any) must be specified in
|
|
/etc/shorewall/hosts but you do not need to specify the 'ipsec' option
|
|
on the entries in that file (see below). Dynamic zones involving IPSEC
|
|
must use that technique.<br>
|
|
<br>
|
|
Example:Under 2.4 Kernel FreeS/Wan:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
Net The big bad Internet</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
VPN Remote Network</span><br>
|
|
<br>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
ipsec0 ...</span><br>
|
|
<br>
|
|
Under 2.6 Kernel with this new support:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
Net The big bad Internet</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
VPN Remote Network</span><br>
|
|
<br>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br>
|
|
<br>
|
|
/etc/shorewall/hosts:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">vpn
|
|
eth0:0.0.0.0/0</span><br>
|
|
<br>
|
|
/etc/shorewall/ipsec<br>
|
|
<br>
|
|
<span style="font-family: monospace;">vpn Yes<br>
|
|
<br>
|
|
</span> </li>
|
|
<li>If only part of the hosts in a zone require encrypted
|
|
communication, you may use of the new 'ipsec' option in
|
|
/etc/shorewall/hosts to designate those hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
Under 2.4 Kernel FreeS/Wan:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
<pre>net Net The big bad Internet<br>loc Local Extended local zone</pre>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
eth1 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
ipsec0 ...</span><br>
|
|
<br>
|
|
Under 2.6 Kernel with this new support:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
Net The big bad Internet</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
VPN Remote Network</span><br>
|
|
<br>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
eth1 ...</span><br>
|
|
<br>
|
|
/etc/shorewall/hosts:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">vpn
|
|
eth0:0.0.0.0/0 ipsec,...</span></li>
|
|
</ol>
|
|
</ol>
|
|
<div style="margin-left: 40px;">Regardless of which technique you
|
|
choose, you can specify additional SA options for the zone in the
|
|
/etc/shorewall/ipsec entry.<br>
|
|
<br>
|
|
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
|
|
input-output, input and output characteristics of the security
|
|
associations to be used to decrypt (input) or encrypt (output) traffic
|
|
to/from the zone.<br>
|
|
<br>
|
|
The available options are:<br>
|
|
</div>
|
|
<ul>
|
|
<ul>
|
|
<li>reqid[!]=<number> where <number> is specified using
|
|
setkey(8) using the 'unique:<number>' option for the SPD level.</li>
|
|
<li>spi[!]=<number> where <number> is the SPI of the
|
|
SA. Since different SAs are used to encrypt and decrypt traffic, this
|
|
option should only be listed in the IN OPTIONS and OUT OPTIONS columns.</li>
|
|
<li>proto[!]=ah|esp|ipcomp</li>
|
|
<li>mss=<number> (sets the MSS value in TCP SYN packets and
|
|
is not related to policy matching)</li>
|
|
<li>mode[!]=transport|tunnel</li>
|
|
<li>tunnel-src[!]=<address>[/<mask>] (only available
|
|
with mode=tunnel)</li>
|
|
<li>tunnel-dst[!]=<address>[/<mask>] (only available
|
|
with mode=tunnel). Because tunnel source and destination are dependent
|
|
on the direction of the traffic, these options should only appear in
|
|
the IN OPTIONS and OUT OPTIONS columns.</li>
|
|
<li>strict (if specified, packets must match all policies;
|
|
policies are delimited by 'next').</li>
|
|
<li>next (only available with strict)</li>
|
|
</ul>
|
|
</ul>
|
|
<div style="margin-left: 40px;">Examples:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">#ZONE
|
|
IPSEC OPTIONS
|
|
|
|
IN
|
|
OUT</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">#
|
|
ONLY
|
|
|
|
OPTIONS OPTIONS</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
Yes mode=tunnel,proto=esp
|
|
spi=1000 spi=1001</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
No reqid=44,mode=transport</span><br>
|
|
<br>
|
|
The /etc/shorewall/masq file has a new IPSEC column added. If you
|
|
specify Yes or yes in that column then the unencrypted packets will
|
|
have their source address changed. Otherwise, the unencrypted packets
|
|
will not have their source addresses changed. This column may also
|
|
contain a comma-separated list of the options specified above in which
|
|
case only those packets that will be encrypted by an SA matching the
|
|
given options will have their source address changed.<br>
|
|
</div>
|
|
<ol start="8">
|
|
<li>To improve interoperability, tunnels of type 'ipsec' no longer
|
|
enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no
|
|
longer enforce use of the specified port as both the source and
|
|
destination ports.</li>
|
|
<li>A new 'allowBcast' builtin action has been added -- it silently
|
|
allows broadcasts and multicasts.</li>
|
|
<li>The -c option in /sbin/shorewall commands is now deprecated. The
|
|
commands where -c was previously allowed now permit you to specify a
|
|
configuration directory after the command:<br>
|
|
<br>
|
|
shorewall check [
|
|
<configuration-directory> ]<br>
|
|
shorewall restart [
|
|
<configuration-directory> ]<br>
|
|
shorewall start [
|
|
<configuration-directory> ]<br>
|
|
<br>
|
|
</li>
|
|
<li>Normally, when SNAT or MASQUERADE is applied to a tcp or udp
|
|
connection, Netfilter attempts to retain the source port number. If it
|
|
has to change to port number to avoid <source
|
|
address>,<source port> conflicts, it tries to do so within
|
|
port ranges ( < 512, 512-1023, and > 1023). You may now specify
|
|
an explicit range of source ports to be used by following the address
|
|
or address range (if any) in the ADDRESS column with ":" and a port
|
|
range in the format <low-port>-<high-port>. You must
|
|
specify either "tcp" or "udp" in the PROTO column.<br>
|
|
<br>
|
|
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
|
|
<br>
|
|
<span style="font-family: monospace;"> #INTERFACE
|
|
SUBNET
|
|
ADDRESS PROTO</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0 192.168.1.0/24
|
|
:4000-5000 tcp</span><br
|
|
style="font-family: monospace;">
|
|
<br>
|
|
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">#INTERFACE
|
|
SUBNET
|
|
ADDRESS
|
|
|
|
PROTO</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0
|
|
10.0.0.0/8
|
|
192.0.2.44:7000-8000 udp<br>
|
|
<br>
|
|
</span></li>
|
|
<li>You may now account by user/group ID for outbound traffic from
|
|
the firewall itself with entries in /etc/shorewall/accounting. Such
|
|
accounting rules must be placed in the OUTPUT chain. See the comments
|
|
at the top of /etc/shorewall/accounting for details.</li>
|
|
<li>Shorewall now verifies that your kernel and iptables have physdev
|
|
match support if BRIDGING=Yes in shorewall.conf.</li>
|
|
<li>Beginning with this release, if your kernel and iptables have
|
|
iprange match support (see the output from "shorewall check"), then
|
|
with the exception of the /etc/shorewall/netmap file, anywhere that a
|
|
network address may appear an IP address range of the form <low
|
|
address>-<high address> may also appear.</li>
|
|
<li>Support has been added for the iptables CLASSIFY target. That
|
|
target allows you to classify packets for traffic shaping directly
|
|
rather than indirectly through fwmark. Simply enter the
|
|
<major>:<minor> classification in the first column of
|
|
/etc/shorewall/tcrules:<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">#MARK/
|
|
SOURCE
|
|
DEST PROTO PORT(S)</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">#CLASSIFY</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">1:30
|
|
-
|
|
eth0 tcp
|
|
25</span><br>
|
|
<br>
|
|
Note that when using this form of rule, it is acceptable to include the
|
|
name of an interface in the DEST column.<br>
|
|
<br>
|
|
Marking using the CLASSIFY target always occurs in the POSTROUTING
|
|
chain of the mangle table and is not affected by the setting of
|
|
MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
|
|
<li>During "shorewall start", IP addresses to be added as a
|
|
consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly
|
|
deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed
|
|
then they are re-added later. This is done to help ensure that the
|
|
addresses can be added with the specified labels but can have the
|
|
undesirable side effect of causing routes to be quietly deleted. A new
|
|
RETAIN_ALIASES option has been added to shorewall.conf; when this
|
|
option is set to Yes, existing addresses will not be deleted.
|
|
Regardless of the setting of RETAIN_ALIASES, addresses added during
|
|
"shorewall start" are still deleted at a subsequent "shorewall stop" or
|
|
"shorewall restart".</li>
|
|
<li>Users with a large black list (from /etc/shorewall/blacklist) may
|
|
want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When
|
|
DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before
|
|
loading the blacklist rules. While this may allow connections from
|
|
blacklisted hosts to slip by during construction of the blacklist, it
|
|
can substantially reduce the time that all new connections are disabled
|
|
during "shorewall [re]start".</li>
|
|
<li>Using the default LOGFORMAT, chain names longer than 11
|
|
characters (such as in user-defined actions) may result in log prefix
|
|
truncation. A new shorewall.conf action LOGTAGONLY has been added
|
|
to deal with this problem. When LOGTAGONLY=Yes, logging rules that
|
|
specify a log tag will substitute the tag for the chain name in the log
|
|
prefix.<br>
|
|
<br>
|
|
Example -- file /etc/shorewall/action.thisisaverylogactionname:<br>
|
|
<br>
|
|
Rule:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">DROP:info:ftp
|
|
0.0.0.0/0 0.0.0.0/0
|
|
tcp 21</span><br>
|
|
<br>
|
|
Log prefix with LOGTAGONLY=No:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
|
|
<br>
|
|
Log prefix with LOGTAGONLY=Yes:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now resets the 'accept_source_route' flag for all
|
|
interfaces. If you wish to accept source routing on an interface, you
|
|
must specify the new 'sourceroute' interface option in
|
|
/etc/shorewall/interfaces.</li>
|
|
<li>The default Drop and Reject actions now invoke the new standard
|
|
action 'AllowICMPs'. This new action accepts critical ICMP types:<br>
|
|
<br>
|
|
Type 3 code 4 (fragmentation needed)<br>
|
|
Type 11 (TTL
|
|
exceeded)<br>
|
|
<br>
|
|
</li>
|
|
<li>Explicit control over the kernel's Martian logging is now
|
|
provided using the new 'logmartians' interface option. If you include
|
|
'logmartians' in the interface option list then logging of Martian
|
|
packets on will be enabled on the specified interface. If you wish to
|
|
globally enable martian logging, you can set LOG_MARTIANS=Yes in
|
|
shorewall.conf.</li>
|
|
<li>You may now cause Shorewall to use the '--set-mss' option of the
|
|
TCPMSS target. In other words, you can cause Shorewall to set the MSS
|
|
field of SYN packets passing through the firewall to the value you
|
|
specify. This feature extends the existing CLAMPMSS option in
|
|
/etc/shorewall/shorewall.conf by allowing that option to have a numeric
|
|
value as well as the values "Yes" and "No".<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
CLAMPMSS=1400<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now includes support for the ipp2p match facility. This
|
|
is a departure from my usual policy in that the ipp2p match facility is
|
|
included in Patch-O-Matic-NG and is unlikely to ever be included in the
|
|
kernel.org source tree. Questions about how to install the patch or how
|
|
to build your kernel and/or iptables should not be posted on the
|
|
Shorewall mailing lists.<br>
|
|
<br>
|
|
In the following files, the "PROTO" or "PROTOCOL" column may contain
|
|
"ipp2p":<br>
|
|
<br>
|
|
/etc/shorewall/rules<br>
|
|
/etc/shorewall/tcrules<br>
|
|
/etc/shorewall/accounting<br>
|
|
<br>
|
|
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
|
|
PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a
|
|
list of the options and their meaning, at a root prompt:<br>
|
|
<br>
|
|
iptables -m ipp2p --help<br>
|
|
<br>
|
|
You must not include the leading "--" on the option; Shorewall will
|
|
supply those characters for you. If you do not include an option then
|
|
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</li>
|
|
<li>Shorewall now has support for the CONNMARK target from iptables.
|
|
See the /etc/shorewall/tcrules file for details.</li>
|
|
<li>A new debugging option LOGALLNEW has been added to
|
|
shorewall.conf. When set to a log level, this option causes Shorewall
|
|
to generaate a logging rule as the first rule in each builtin chain.<br>
|
|
<br>
|
|
- The table name is used as the chain name in the
|
|
log prefix.<br>
|
|
- The chain name is used as the target in the log
|
|
prefix.<br>
|
|
<br>
|
|
Example: Using the default LOGFORMAT, the log prefix for logging from
|
|
the nat table's PREROUTING chain is:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
|
|
<br>
|
|
IMPORTANT: There is no rate limiting on these logging rules so use
|
|
LOGALLNEW at your own risk; it may cause high CPU and disk utilization
|
|
and you may not be able to control your firewall after you enable this
|
|
option.<br>
|
|
<br>
|
|
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE
|
|
SENT TO ANOTHER SYSTEM.<br>
|
|
<br>
|
|
</li>
|
|
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed
|
|
SUBNETS and it is now possible to specify a list of addresses in that
|
|
column.</li>
|
|
<li>The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).</li>
|
|
<li>For consistency, the CLIENT PORT(S) column in the tcrules file
|
|
has been renamed SOURCE PORT(S).</li>
|
|
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now
|
|
shown in the output of "shorewall status".</li>
|
|
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES
|
|
can be used to designate the iptables executable to be used by
|
|
Shorewall. If not specified, the iptables executable determined by the
|
|
PATH setting is used.</li>
|
|
<li>You can now use the "shorewall show zones" command to display the
|
|
current contents of the zones. This is particularly useful if you use
|
|
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">ursa:/etc/shorewall
|
|
# shorewall show zones</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> </span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> loc</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0:192.168.1.0/24</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth1:1.2.3.4</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
net </span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> WiFi</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> sec</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> </span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
ursa:/etc/shorewall #</span><br>
|
|
<br>
|
|
</li>
|
|
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/params<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
|
|
<br>
|
|
Any other config file:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">INCLUDE $FILE</span><br>
|
|
<br>
|
|
</li>
|
|
<li>The output of "shorewall status" now includes the results of "ip
|
|
-stat link ls". This helps diagnose performance problems caused by link
|
|
errors.</li>
|
|
<li>Previously, when rate-limiting was specified in
|
|
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
|
|
the specified rate was silently dropped. Now, if a log level is given
|
|
in the entry (LEVEL column) then drops are logged at that level at a
|
|
rate of 5/min with a burst of 5.</li>
|
|
<li>Recent 2.6 kernels include code that evaluates TCP packets based
|
|
on TCP Window analysis. This can cause packets that were previously
|
|
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
|
|
<br>
|
|
The new kernel code can be disabled by including this command in your
|
|
/etc/shorewall/init file:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">echo 1 >
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
|
|
<br>
|
|
Additional kernel logging about INVALID TCP packets may be obtained by
|
|
adding this command to /etc/shorewall/init:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">echo 1 >
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
|
|
<br>
|
|
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
|
DROPINVALID option allows INVALID packets to be passed through the
|
|
normal rules chains by setting DROPINVALID=No.<br>
|
|
<br>
|
|
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
|
DROPINVALID=Yes is assumed.<br>
|
|
<br>
|
|
</li>
|
|
<li>The "shorewall add" and "shorewall delete" commands now accept a
|
|
list of hosts to add or delete.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
<span style="font-family: monospace;"> shorewall add
|
|
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> shorewall delete
|
|
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
|
|
<br>
|
|
The above commands may also be written:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">shorewall add
|
|
eth1:1.2.3.4,2.3.4.5 z12</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> shorewall delete
|
|
eth1:1.2.3.4,2.3.4.5 z12</span><br>
|
|
<br>
|
|
</li>
|
|
<li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
|
|
type. OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">openvpn[:{tcp|udp}][:<port>]
|
|
<zone> <gateway></span><br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">openvpn:tcp
|
|
net
|
|
1.2.3.4 # TCP tunnel on port 1194</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
openvpn:3344 net
|
|
1.2.3.4 # UDP on port 3344</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
openvpn:tcp:4455 net
|
|
1.2.3.4 # TCP on port 4455</span><br>
|
|
<br>
|
|
</li>
|
|
<li>A new 'ipsecvpn' script is included in the tarball and in the
|
|
RPM. The RPM installs the file in the Documentation directory
|
|
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
|
|
<br>
|
|
This script is intended for use on Roadwarrior laptops for establishing
|
|
an IPSEC SA to/from remote networks. The script has some limitations:</li>
|
|
</ol>
|
|
<ul>
|
|
<ul>
|
|
<li>Only one instance of the script may be used at a time.</li>
|
|
<li>Only the first SPD accessed will be instantiated at the remote
|
|
gateway. So while the script creates SPDs to/from the remote gateway
|
|
and each network listed in the NETWORKS setting at the front of the
|
|
script, only one of these may be used at a time.</li>
|
|
</ul>
|
|
</ul>
|
|
<ol start="39">
|
|
<li>The output of "shorewall status" now lists the loaded netfilter
|
|
kernel modules.</li>
|
|
<li>The range of UDP ports opened by the AllowTrcrt action has been
|
|
increased to 33434:33524.</li>
|
|
<li>The IANA has recently registered port 1194 for use by OpenVPN. In
|
|
previous versions of Shorewall (and OpenVPN), the default port was 5000
|
|
but has been changed to 1194 to conform to the new OpenVPN default.<br>
|
|
</li>
|
|
</ol>
|
|
<p><a href="News.htm">More News</a></p>
|
|
<hr>
|
|
<h2><a name="Leaf"></a>Leaf</h2>
|
|
<p><a href="http://leaf.sourceforge.net/" target="_top"><font
|
|
color="#000000"><img src="images/leaflogo.gif" name="Graphic1"
|
|
alt="(Leaf Logo)" align="bottom" border="1" height="39" width="52"></font></a>
|
|
LEAF is an open source project which provides a Firewall/router on a
|
|
floppy, CD or CF. Several LEAF distributions including Bering and
|
|
Bering-uClibc use Shorewall as their Netfilter configuration tool.</p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<h2><a name="OpenWRT"></a>OpenWRT</h2>
|
|
<a href="http://openwrt.org"><img alt="(OpenWRT Logo)"
|
|
src="images/openwrt.png"
|
|
style="border: 0px solid ; width: 88px; height: 31px;" hspace="4"></a>OpenWRT
|
|
is a project which provides open source firmware for Linksys WRT54G
|
|
wireless routers. Two different Shorewall packages are available for
|
|
OpenWRT.<br>
|
|
<hr>
|
|
<h2><a name="Donations"></a>Donations</h2>
|
|
<p align="left"><a href="http://www.alz.org/" target="_top"><font
|
|
color="#000000"><img src="images/alz_logo2.gif" name="Graphic2"
|
|
alt="(Alzheimer's Association Logo)" align="right" border="1"
|
|
height="63" width="303"></font></a><a href="http://www.starlight.org/"
|
|
target="_top"><font color="#000000"><img src="images/newlog.gif"
|
|
name="Graphic3" alt="(Starlight Foundation Logo)" align="right"
|
|
border="1" height="105" width="62"></font></a><font size="4">Shorewall
|
|
is free but if you try it and find it useful, please consider making
|
|
a donation to the <a href="http://www.alz.org/" target="_top">Alzheimer's
|
|
Association</a> or to the <a href="http://www.starlight.org/"
|
|
target="_top">Starlight
|
|
Children's Foundation</a>.</font></p>
|
|
<p align="left"><font size="4">Thank You<br>
|
|
</font></p>
|
|
<p align="left"><br>
|
|
<br>
|
|
</p>
|
|
</body>
|
|
</html>
|