extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-25 00:53:49 +01:00
Code Issues Packages Projects Releases Wiki Activity

Third batch of mindless ID changes

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6696 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2007-06-28 20:20:16 +00:00
parent 3eda07bab4
commit d6f388a755
16 changed files with 96 additions and 1799 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/IPIP.xml
View File

@ -57,7 +57,7 @@
the RPM, the tunnel script may be found in the Shorewall documentation
directory (usually /usr/share/doc/shorewall-&lt;version&gt;/).</para>
<section>
<section id="Bridged">
<title>Bridging two Masqueraded Networks</title>
<para>Suppose that we have the following situation:</para>
@ -80,7 +80,7 @@
<quote>tunnel_type</quote> parameter to the type of tunnel that you want
to create.</para>
<example>
<example id="Tunnel">
<title>/etc/shorewall/tunnel</title>
<programlisting>tunnel_type=gre</programlisting>
@ -117,7 +117,7 @@ ipip net 134.28.54.2</programlisting>
<para>In the tunnel script on system A:</para>
<example>
<example id="TunnelA">
<title>tunnel script on system A</title>
<programlisting>tunnel=tosysb
@ -143,7 +143,7 @@ ipip net 206.191.148.9</programlisting>
<para>And in the tunnel script on system B:</para>
<example>
<example id="TunnelB">
<title>tunnel script on system B</title>
<programlisting>tunnel=tosysa

6
docs/IPP2P.xml
View File

@ -45,7 +45,7 @@
release.</emphasis></para>
</caution>
<section>
<section id="Intro">
<title>Introduction</title>
<para>Shorewall verions 2.2.0 and later include support for the ipp2p
@ -57,7 +57,7 @@
Mailing List.</para>
</section>
<section>
<section id="Scope">
<title>Scope</title>
<para>In the following files, the "PROTO" or "PROTOCOL" column may contain
@ -87,7 +87,7 @@
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</para>
</section>
<section>
<section id="Example">
<title>Example:</title>
<para>Example 2 in the ipp2p documentation recommends the following

14
docs/IPSEC-2.6.xml
View File

@ -69,7 +69,7 @@
using physdev match support</emphasis>"</ulink> article.</para>
</warning>
<section>
<section id="Overview">
<title>Shorewall 3.0 and Kernel 2.6 IPSEC</title>
<para>This is <emphasis role="bold">not</emphasis> a HOWTO for Kernel 2.6
@ -218,7 +218,7 @@
configured.</para>
</section>
<section>
<section id="GwFw">
<title>IPSec Gateway on the Firewall System</title>
<para>Suppose that we have the following sutuation:</para>
@ -455,7 +455,7 @@ sec ipsec mode=tunnel <emphasis role="bold">mss=1400</emphasis
</blockquote>
</section>
<section>
<section id="RoadWarrior">
<title>Mobile System (Road Warrior)</title>
<para>Suppose that you have a laptop system (B) that you take with you
@ -464,7 +464,7 @@ sec ipsec mode=tunnel <emphasis role="bold">mss=1400</emphasis
<graphic fileref="images/Mobile.png" />
<example>
<example id="roadWarrior">
<title>Road Warrior VPN</title>
<para>You need to define a zone for the laptop or include it in your
@ -648,7 +648,7 @@ RACOON=/usr/sbin/racoon</programlisting>
</warning>
</section>
<section>
<section id="Transport">
<title>Transport Mode</title>
<para>In today's wireless world, it is often the case that individual
@ -764,7 +764,7 @@ all all REJECT info
</blockquote>
</section>
<section>
<section id="XP">
<title>IPSEC and <trademark>Windows</trademark> XP</title>
<para>I have successfully configured my work laptop to use IPSEC with
@ -825,7 +825,7 @@ all all REJECT info
</warning>
</section>
<section>
<section id="More">
<title>Source of Additional Samples</title>
<para>Be sure to check out the <filename

31
docs/IPSEC.xml
View File

@ -59,14 +59,14 @@
Shorewall.</para>
</warning>
<section>
<section id="Prelim">
<title>Preliminary Reading</title>
<para>I recommend reading the <ulink url="VPNBasics.html">VPN
Basics</ulink> article if you plan to implement any type of VPN.</para>
</section>
<section>
<section id="Swans">
<title>Configuring FreeS/Wan and Derivatives Such as OpenS/Wan</title>
<para>There is an excellent guide to configuring IPSEC tunnels at <ulink
@ -102,7 +102,7 @@ conn packetdefault
</important>
</section>
<section>
<section id="GwFw">
<title>IPSec Gateway on the Firewall System</title>
<para>Suppose that we have the following sutuation:</para>
@ -224,7 +224,7 @@ vpn loc ACCEPT</programlisting>
url="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</ulink>.</para>
</section>
<section>
<section id="Hub">
<title>VPN Hub using Kernel 2.4</title>
<para>Shorewall can be used in a VPN Hub environment where multiple remote
@ -355,7 +355,7 @@ vpn2 vpn1 ACCEPT</programlisting>
</note>
</section>
<section>
<section id="RoadWarrior">
<title>Mobile System (Road Warrior) Using Kernel 2.4</title>
<para>Suppose that you have a laptop system (B) that you take with you
@ -364,7 +364,7 @@ vpn2 vpn1 ACCEPT</programlisting>
<graphic fileref="images/Mobile.png" />
<example>
<example id="roadWarrior">
<title>Road Warrior VPN</title>
<para>You need to define a zone for the laptop or include it in your
@ -396,7 +396,7 @@ ipsec net 0.0.0.0/0</programlisting>
</example>
</section>
<section>
<section id="Dynamic">
<title>Dynamic RoadWarrior Zones</title>
<para>Beginning with Shorewall release 1.3.10, you can define multiple VPN
@ -433,22 +433,5 @@ ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3</programlisting>
<para>and the <quote>down</quote> part will:</para>
<programlisting>/sbin/shorewall delete ipsec0:134.28.54.2 vpn2</programlisting>
<section>
<title>Limitations of Dynamic Zones</title>
<para>If you include a dynamic zone in the exclude list of a DNAT rule,
the dynamically-added hosts are not excluded from the rule.</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT z!dyn loc:192.168.1.3 tcp 80</programlisting>
<example>
<title>dyn=dynamic zone</title>
<para>Dynamic changes to the zone <emphasis role="bold">dyn</emphasis>
will have no effect on the above rule.</para>
</example>
</section>
</section>
</article>

78
docs/Kernel2.6.xml
View File

@ -1,78 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>Shorewall and the 2.6 Linux Kernel</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
<copyright>
<year>2003</year>
<year>2004</year>
<year>2005</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>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
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>General</title>
<para>Shorewall is compatible with the Linux 2.6 kernel series and
contains support for the following features that are added in that
series:</para>
<orderedlist>
<listitem>
<para><ulink url="netmap.html">NETMAP</ulink> Target Support.</para>
</listitem>
<listitem>
<para><ulink url="bridge.html">Bridge/Firewall</ulink> Support
(physdev match support).</para>
</listitem>
<listitem>
<para><ulink url="traffic_shaping.htm">CLASSIFY</ulink> Target
Support.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>IPSEC</title>
<para>The 2.6 Linux kernel introduces a new implementation of IPSEC which
eliminates the <filename class="devicefile">ipsecN</filename> device
names. Netfilter/iptables support for this new implementation is
incomplete unless your kernel has been patched. For unpatched kernels, see
the <ulink url="IPSEC.htm">Shorewall IPSEC documentation</ulink>
(Shorewall support for IPSEC with unpatched 2.6 kernels is very limited).
For patched 2.6 kernels (including those supplied with
<trademark>SUSE</trademark> 9.2) see the <ulink
url="IPSEC-2.6.html">Kernel 2.6 IPSEC documentation</ulink>.</para>
</section>
</article>

15
docs/MAC_Validation.xml
View File

@ -70,7 +70,7 @@
<ulink url="OPENVPN.html">OpenVPN</ulink>.</emphasis></para>
</important>
<section>
<section id="Components">
<title>Components</title>
<para>There are six components to this facility.</para>
@ -154,7 +154,7 @@
</orderedlist>
</section>
<section>
<section id="maclist">
<title>/etc/shorewall/maclist</title>
<para>The columns in /etc/shorewall/maclist are:</para>
@ -203,12 +203,11 @@
</variablelist>
</section>
<section>
<section id="Examples">
<title>Examples</title>
<example>
<title>Here are my files (look <ulink url="myfiles.htm">here</ulink> for
details about my setup)</title>
<example id="Example1">
<title>Here are my files</title>
<para>/etc/shorewall/shorewall.conf:</para>
@ -245,7 +244,7 @@ $WIFI_IF 00:1f:79:cd:fe:2e 192.168.3.6 #Work Laptop
</note></para>
</example>
<example>
<example id="Example2">
<title>Router in Wireless Zone</title>
<para>Suppose now that I add a second wireless segment to my wireless
@ -264,4 +263,4 @@ $WIFI_IF 00:1f:79:cd:fe:2e 192.168.3.6 #Work Laptop
of the host sending the traffic.</para>
</example>
</section>
</article>
</article>

10
docs/Macros.xml
View File

@ -47,7 +47,7 @@
release.</emphasis></para>
</caution>
<section>
<section id="Overview">
<title>Overview of Shorewall Macros?</title>
<para>Shorewall macros allow a symbolic name to be associated with a
@ -266,9 +266,11 @@ ACCEPT fw loc tcp 135,139,445</programlisting>
<para>Shorewall versions 3.4 and later include standard 'Reject' and
'Drop' macros that are equivalent to the 'Reject' and 'Drop'
actions.</para>
<para>Default Macros are not supported by Shorewall-perl.</para>
</section>
<section>
<section id="Defining">
<title>Defining your own Macros</title>
<para>To define a new macro:</para>
@ -572,7 +574,7 @@ bar:debug</programlisting>
</orderedlist>
</section>
<section>
<section id="ActionOrMacro">
<title>How do I know if I should create an Action or a Macro?</title>
<para>While actions and macros perform similar functions, in any given
@ -597,4 +599,4 @@ bar:debug</programlisting>
</listitem>
</orderedlist>
</section>
</article>
</article>

10
docs/Modularization.xml
View File

@ -34,7 +34,7 @@
</legalnotice>
</articleinfo>
<section>
<section id="Intro">
<title>Introduction</title>
<para>One of the major changes in Shorewall version 3.4 involved breaking
@ -46,9 +46,9 @@
nothing but function declarations. Shorewall libraries may be loaded into
a running shell program using the shell's "." operator. The library files
have names which begin with "lib." and are installed in <filename
class="directory">/usr/share/shorewall/</filename>. </para>
class="directory">/usr/share/shorewall/</filename>.</para>
<para> Individual libraries are of one of two classes. The first class of
<para>Individual libraries are of one of two classes. The first class of
libraries are <firstterm>required libraries</firstterm> which, as their
name implies, must be included in any Shorewall installation. The other
libraries are <firstterm>optional libraries</firstterm> that implement a
@ -56,7 +56,7 @@
based on the requirements of the individual installation.</para>
</section>
<section>
<section id="Required">
<title>Required Libraries</title>
<para>Shorewall 3.4 includes the following required libraries.</para>
@ -84,7 +84,7 @@
Shorewall Lite systems.</para>
</section>
<section>
<section id="Optional">
<title>Optional Libraries</title>
<para>Optional libraries are loaded upon demand based on the user's

22
docs/MultiISP.xml
View File

@ -73,7 +73,7 @@
</itemizedlist>
</warning>
<section>
<section id="Support">
<title>Multiple Internet Connection Support</title>
<para>Beginning with Shorewall 2.3.2, limited support is included for
@ -102,7 +102,7 @@
</listitem>
</itemizedlist>
<section>
<section id="Overview">
<title>Overview</title>
<para>Let's assume that a firewall is connected via two separate
@ -182,7 +182,7 @@
example.</para>
</section>
<section>
<section id="providers">
<title>/etc/shorewall/providers File</title>
<para>Entries in this file have the following columns. As in all
@ -444,7 +444,7 @@
</variablelist>
</section>
<section>
<section id="Providers">
<title>What an entry in the Providers File Does</title>
<para>Adding another entry in the providers file simply creates an
@ -595,7 +595,7 @@ done</programlisting>
</warning>
</section>
<section>
<section id="Provider_Doesnt">
<title>What an entry in the Providers File Does NOT Do</title>
<para>Given that Shorewall is simply a tool to configure Netfilter and
@ -670,8 +670,8 @@ DROP:info net:192.168.1.0/24 all</programlisting>
<emphasis>net</emphasis> in the SOURCE column.</para>
</section>
<section>
<title>Example</title>
<section id="Example1">
<title id="Example">Example</title>
<para>The configuration in the figure at the top of this section would
be specified in <filename>/etc/shorewall/providers</filename> as
@ -784,7 +784,7 @@ eth1 eth2 130.252.99.27</programlisting>
</itemizedlist>
</section>
<section>
<section id="route_rules">
<title>/etc/shorewall/route_rules</title>
<para>The <filename>/etc/shorewall/route_rules</filename> file was added
@ -810,7 +810,7 @@ eth1 eth2 130.252.99.27</programlisting>
Does</emphasis></link>.</para>
</warning>
<section>
<section id="Routing_rules">
<title>Routing Rules</title>
<para>Routing rules are maintained by the Linux kernel and can be
@ -832,7 +832,7 @@ gateway:~ #</programlisting>
with MARK 1 going to Blarg and mark 2 going to Comcast.</para>
</section>
<section>
<section id="route_rules_columns">
<title>Columns in the route_rules file</title>
<para>Columns in the file are:</para>
@ -928,4 +928,4 @@ gateway:~ #</programlisting>Note that because we used a priority of 1000, the
</section>
</section>
</section>
</article>
</article>

16
docs/Multiple_Zones.xml
View File

@ -41,7 +41,7 @@
release.</emphasis></para>
</caution>
<section>
<section id="Intro">
<title>Introduction</title>
<para>While most configurations can be handled with each of the firewall's
@ -103,7 +103,7 @@
be used in exactly the same way.</para>
</section>
<section>
<section id="Router">
<title>Router in the Local Zone</title>
<para>Here is an example of a router in the local zone.</para>
@ -116,7 +116,7 @@
<graphic fileref="images/MultiZone1.png" />
<section>
<section id="Standard">
<title>Can You Use the Standard Configuration?</title>
<para>In many cases, the <ulink url="two-interface.htm">standard
@ -141,7 +141,7 @@
restart Shorewall.</para>
</section>
<section>
<section id="Enough">
<title>Will One Zone be Enough?</title>
<para>If the firewalling requirements for the two local networks is the
@ -170,13 +170,13 @@
</orderedlist>
</section>
<section>
<section id="Separate">
<title>I Need Separate Zones</title>
<para>If you need to make 192.168.2.0/24 into its own zone, you can do
it one of two ways; Nested Zones or Parallel Zones.</para>
<section>
<section id="Nested">
<title>Nested Zones</title>
<para>You can define one zone (called it <quote>loc</quote>) as being
@ -225,7 +225,7 @@ loc loc1 NONE
loc1 loc NONE</programlisting>
</section>
<section>
<section id="Parallel">
<title>Parallel Zones</title>
<para>You define both zones in the /etc/shorewall/hosts file to create
@ -265,7 +265,7 @@ loc2 loc1 NONE</programlisting>
</section>
</section>
<section>
<section id="Special">
<title>Some Hosts have Special Firewalling Requirements</title>
<para>There are cases where a subset of the addresses associated with an

4
docs/NAT.xml
View File

@ -41,7 +41,7 @@
release.</emphasis></para>
</caution>
<section>
<section id="One-to-one">
<title>One-to-one NAT</title>
<important>
@ -130,7 +130,7 @@
ACCEPT net loc:10.1.1.2 tcp 80 - 130.252.100.18</programlisting>
</section>
<section>
<section id="ARP">
<title>ARP cache</title>
<para>A word of warning is in order here. ISPs typically configure their

37
docs/OPENVPN.xml
View File

@ -85,14 +85,14 @@
</listitem>
</orderedlist>
<section>
<section id="Prelim">
<title>Preliminary Reading</title>
<para>I recommend reading the <ulink url="VPNBasics.html">VPN
Basics</ulink> article if you plan to implement any type of VPN.</para>
</section>
<section>
<section id="Routed">
<title>Bridging two Masqueraded Networks</title>
<para>Suppose that we have the following situation:</para>
@ -243,7 +243,7 @@ vpn loc ACCEPT</programlisting>
the two masqueraded subnetworks can now talk to each other.</para>
</section>
<section>
<section id="RoadWarrior">
<title>Roadwarrior</title>
<para>OpenVPN 2.0 provides excellent support for roadwarriors. Consider
@ -466,7 +466,7 @@ verb 3</programlisting>
have the IP address 192.168.1.8 regardless.</para>
</note>
<section>
<section id="bridge">
<title>Configuring the Bridge</title>
<para>The firewall ran Debian Sarge so the bridge was defined in
@ -495,20 +495,19 @@ iface br0 inet static
zone.</para>
</section>
<section>
<section id="openvpn">
<title>Configuring OpenVPN</title>
<para>We used X.509 certificates for authentication.</para>
<section>
<section id="server">
<title>Firewall (Server) configuration.</title>
<para>/etc/openvpn/server-bridge.conf defined a bridge and reserved IP
addresses 192.168.1.64-192.168.1.71 for VPN clients. Note that the
bridge server only used local IP address 192.168.3.254. We ran two
instances of OpenVPN; this one and a second tunnel-mode instance for
remote access (see <ulink url="myfiles.htm">this
article</ulink>).</para>
remote access.</para>
<para></para>
@ -553,7 +552,7 @@ verb 3</programlisting>
<programlisting>ifconfig-push 192.168.1.8 255.255.255.0</programlisting>
</section>
<section>
<section id="tipper">
<title>Tipper Configuration</title>
<para>/etc/openvpn/wireless.conf:</para>
@ -587,7 +586,7 @@ mute-replay-warnings
verb 3</programlisting>
</section>
<section>
<section id="XP">
<title>Eastepnc6000 (Windows XP) Configuration</title>
<para>C:\Program Files\Openvpn\config\homewireless.ovpn:</para>
@ -619,7 +618,7 @@ persist-key
verb 3</programlisting>
</section>
<section>
<section id="Linux">
<title>Eastepnc6000 (SUSE 10.0) Configuration</title>
<para>The configuration was the same as shown above only with
@ -628,7 +627,7 @@ verb 3</programlisting>
</section>
</section>
<section>
<section id="Shorewall">
<title>Configuring Shorewall</title>
<para>In this configuration, we didn't need any firewalling between the
@ -639,10 +638,10 @@ verb 3</programlisting>
to configure Shorewall as shown in the <ulink
url="bridge.html">Bridge/Firewall documentation</ulink>.</para>
<section>
<section id="FW">
<title>Firewall</title>
<section>
<section id="interfaces">
<title>/etc/shorewall/interfaces</title>
<para>Note that the bridge (br0) is defined as the interface to the
@ -657,7 +656,7 @@ Wifi eth0 192.168.3.255 dhcp,maclist
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</section>
<section>
<section id="tunnels">
<title>/etc/shorewall/tunnels</title>
<programlisting>#TYPE ZONE GATEWAY GATEWAY
@ -667,7 +666,7 @@ openvpnserver:1194 Wifi 192.168.3.0/24
</section>
</section>
<section>
<section id="Tipper">
<title>Tipper</title>
<para>Wireless networks pose a threat to all systems that are
@ -675,7 +674,7 @@ openvpnserver:1194 Wifi 192.168.3.0/24
Eastepnc6000 ran <trademark>Sygate</trademark> Security Agent and
Tipper ran a Shorewall-based Netfilter firewall.</para>
<section>
<section id="zones">
<title>/etc/shorewall/zones</title>
<programlisting>#ZONE TYPE OPTIONS IN OUT
@ -686,7 +685,7 @@ net ipv4
</programlisting>
</section>
<section>
<section id="interfaces1">
<title>/etc/shorewall/interfaces</title>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
@ -696,7 +695,7 @@ net eth0 detect routefilter,dhcp,tcpflags
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</section>
<section>
<section id="policy">
<title>/etc/shorewall/policy</title>
<para>Since we didn't expect any traffic between the <emphasis

12
docs/ipsets.xml
View File

@ -34,7 +34,7 @@
</legalnotice>
</articleinfo>
<section>
<section id="Ipsets">
<title>What are Ipsets?</title>
<para>Ipsets are an extention to Netfilter/iptables that are currently
@ -67,7 +67,7 @@
ipsets.</para>
</section>
<section>
<section id="Support">
<title>Shorewall Support for Ipsets</title>
<para>Support for ipsets was introduced in Shorewall version 2.3.0. In
@ -119,8 +119,8 @@ ACCEPT +sshok $FW tcp 22</programlisting></para>
"shorewall save" will save the contents of your ipsets. The file where the
sets are saved is formed by taking the name where the Shorewall
configuration is stored and appending "-ipsets". So if you enter the
command "shorewall save standard" then Shorewall will save the file as
/var/lib/shorewall/standard-ipsets</para>
command "shorewall save standard" then Shorewall will save the file as
/var/lib/shorewall/standard-ipsets</para>
<para>Regardless of the setting of SAVE_IPSETS, the <command>shorewall -f
start</command> and <command>shorewall restore</command> commands will
@ -187,7 +187,7 @@ ipset -B Blacklist 206.124.146.177 -b SMTP</command></programlisting>
<para>Now only port 25 will be blocked from 206.124.146.177.</para>
</section>
<section>
<section id="Dynamic">
<title>Defining Dynamic Zones using Ipsets</title>
<para>The use of ipsets provides a much better way to define dynamic zones
@ -214,4 +214,4 @@ dyn eth3:+Dyn</programlisting>
you're all set. You can add and delete addresses from Dyn without having
to touch Shorewall.</para>
</section>
</article>
</article>

8
docs/kernel.xml
View File

@ -40,7 +40,7 @@
url="http://www.kernelnewbies.org">http://www.kernelnewbies.org</ulink>.</para>
</note>
<section>
<section id="Network">
<title>Network Options Configuration</title>
<para>Here's a screen shot of my Network Options Configuration:<graphic
@ -83,7 +83,7 @@
</blockquote>
</section>
<section>
<section id="Netfilter">
<title>Netfilter Configuration</title>
<para>Here's a screen shot of my Netfilter configuration:<graphic
@ -151,7 +151,7 @@ CONFIG_IP_NF_ARPFILTER=m
</blockquote>
</section>
<section>
<section id="Netfilter-2.6">
<title>Kernel 2.6 Netfilter Options</title>
<para>Here's a screenshot of my modularized 2.6 Kernel config (Navigation:
@ -244,7 +244,7 @@ CONFIG_BRIDGE_NF_EBTABLES=m
</blockquote>
</section>
<section>
<section id="Kernel-2.6.16">
<title>Kernel 2.6.16 and Later Netfilter Options</title>
<para>Here's a screenshot of my modularized 2.6.16 Kernel config

936
docs/myfiles.xml
View File

@ -1,936 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>About My Network</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
<copyright>
<year>2001-2006</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>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
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>My Current Network</title>
<caution>
<para>I use a combination of One-to-one NAT and Xen paravirtualization,
neither of which are relevant to a simple configuration with a single
public IP address. If you have just a single public IP address, most of
what you see here won't apply to your setup so beware of copying parts
of this configuration and expecting them to work for you. What you copy
may or may not work in your environment.</para>
</caution>
<caution>
<para>The configuration shown here corresponds to Shorewall version
3.0.3. My configuration uses features not available in earlier Shorewall
releases.</para>
</caution>
<para>I have DSL service with 5 static IP addresses (206.124.146.176-180).
My DSL <quote>modem</quote> (<ulink
url="http://www.westell.com/pages/index.jsp">Westell</ulink> 2200) is
connected to eth2 and has IP address 192.168.1.1 (factory default). The
modem is configured in <quote>bridge</quote> mode so PPPoE is not
involved. I have a local network connected to eth1 which is bridged to
interface tun0 via bridge br0 (subnet 192.168.1.0/24) and a wireless
network (192.168.3.0/24) connected to eth0.</para>
<para>In this configuration:</para>
<itemizedlist>
<listitem>
<para>I use one-to-one NAT for <emphasis>"Ursa"</emphasis> (my
personal system that run SUSE 10.0) - Internal address 192.168.1.5 and
external address 206.124.146.178.</para>
</listitem>
<listitem>
<para>I use one-to-one NAT for "<emphasis>lists</emphasis>" (My server
system that runs SUSE 10.0 in a Xen virtual system on
<emphasis>ursa</emphasis>) - Internal address 192.168.1.7 and external
address 206.124.146.177.</para>
</listitem>
<listitem>
<para>I use one-to-one NAT for <emphasis>"Eastepnc6000</emphasis>" (My
work system -- Windows XP SP1/SUSE 10.0). Internal address 192.168.1.6
and external address 206.124.146.180.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para>use SNAT through 206.124.146.179 for&nbsp;my Wife's Windows XP
system <quote><emphasis>Tarry</emphasis></quote> and our SUSE 10.0
laptop <quote><emphasis>Tipper</emphasis></quote> which connects
through the Wireless Access Point (wap).</para>
</listitem>
</itemizedlist>
<para>The firewall runs on a Celeron 1.4Ghz under SUSE 10.0.</para>
<para><emphasis>Ursa</emphasis> runs Samba for file sharing with the
Windows systems and is configured as a Wins server.</para>
<para>The wireless network connects to the firewall's eth0 via a LinkSys
WAP11.&nbsp; In additional to using the rather weak WEP 40-bit encryption
(64-bit with the 24-bit preamble), I use <ulink
url="MAC_Validation.html">MAC verification</ulink> and <ulink
url="OPENVPN.html#Bridge">OpenVPN in bridge mode</ulink>.</para>
<para>The server in runs <ulink
url="http://www.postfix.org">Postfix</ulink>, <ulink
url="http://www.courier-mta.org/imap/">Courier IMAP</ulink> (imap and
imaps), <ulink url="http://www.isc.org/sw/bind/">DNS (Bind 9)</ulink>, a
<ulink url="http://www.apache.org">Web server (Apache)</ulink> and an
<ulink url="http://www.pureftpd.org/">FTP server
(Pure-ftpd)</ulink>.</para>
<para>The firewall system itself runs a <ulink
url="http://www.isc.org/sw/dhcp/">DHCP server</ulink> that serves the
local and wireless networks.</para>
<para>All administration and publishing is done using ssh/scp. I have a
desktop environment installed on the firewall but I usually don't start
it. X applications tunnel through SSH to <emphasis>Ursa</emphasis> or one
of the laptops. The server also has a desktop environment installed but it
is never started. For the most part, X tunneled through SSH is used for
server administration and the server runs at run level 3 (multi-user
console mode on SUSE).</para>
<para>In addition to the OpenVPN bridge, the firewall hosts an OpenVPN
Tunnel server for VPN access from our second home in <ulink
url="http://www.omakchamber.com/">Omak, Washington</ulink> or when we are
otherwise out of town.</para>
<para><graphic align="center" fileref="images/network.png" /><note>
<para><emphasis>Eastepnc6000</emphasis> is shown in both the local LAN
and in the Wifi zone with IP address 192.168.1.6 -- clearly, the
computer can only be in one place or the other.
<emphasis>Tipper</emphasis> can also be in either place and will have
the IP address 192.168.1.8 regardless.</para>
</note></para>
</section>
<section>
<title>Ursa (Xen) Configuration</title>
<para>Ursa runs two domains. Domain 0 is my personal Linux desktop
environment. The other domains comprise my DMZ. There is currently only
one system (lists) in the DMZ.</para>
<graphic align="center" fileref="images/Xen3.png" />
<para>Ursa's Shorewall configuration is described in <ulink
url="Xen.html">the article about Xen and Shorewall</ulink>.</para>
<para>About the only thing that is unique about the configuration of
Domain 1 (lists) is that its (virtualized) eth0 has two addresses:</para>
<itemizedlist>
<listitem>
<para>192.168.1.7/24</para>
</listitem>
<listitem>
<para>206.124.146.177/32</para>
</listitem>
</itemizedlist>
<para>This prevents the DNS server from getting confused due to the fact
that the two different views have a different IP addresses for the primary
name server for the domain shorewall.net.</para>
</section>
<section>
<title>Firewall Configuration</title>
<section>
<title>Shorewall.conf</title>
<blockquote>
<programlisting>STARTUP_ENABLED=Yes
LOGFILE=/var/log/messages
LOGFORMAT="Shorewall:%s:%s:"
LOGTAGONLY=No
LOGRATE=
LOGBURST=
LOGALLNEW=
BLACKLIST_LOGLEVEL=
MACLIST_LOG_LEVEL=$LOG
TCP_FLAGS_LOG_LEVEL=$LOG
RFC1918_LOG_LEVEL=$LOG
SMURF_LOG_LEVEL=$LOG
LOG_MARTIANS=No
IPTABLES=
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SHOREWALL_SHELL=/bin/dash
SUBSYSLOCK=
MODULESDIR=
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
RESTOREFILE=standard
IPSECFILE=zones
FW=
IP_FORWARDING=On
ADD_IP_ALIASES=No
ADD_SNAT_ALIASES=No
RETAIN_ALIASES=Yes
TC_ENABLED=Internal
CLEAR_TC=Yes
MARK_IN_FORWARD_CHAIN=Yes
CLAMPMSS=Yes
ROUTE_FILTER=No
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
ADMINISABSENTMINDED=Yes
BLACKLISTNEWONLY=Yes
DELAYBLACKLISTLOAD=No
MODULE_SUFFIX=
DISABLE_IPV6=Yes
BRIDGING=No
DYNAMIC_ZONES=No
PKTTYPE=No
RFC1918_STRICT=Yes
MACLIST_TTL=60
SAVE_IPSETS=No
MAPOLDACTIONS=No
FASTACCEPT=No
BLACKLIST_DISPOSITION=DROP
MACLIST_TABLE=mangle
MACLIST_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP</programlisting>
</blockquote>
</section>
<section>
<title>Params File (Edited)</title>
<blockquote>
<para><programlisting>NTPSERVERS=&lt;list of NTP server IP addresses&gt;
POPSERVERS=&lt;list of external POP3 servers accessed by fetchmail running on the DMZ server&gt;
LOG=info
WIFI_IF=eth0
EXT_IF=eth2
INT_IF=br0
OMAK=&lt;ip address of the gateway at our second home&gt;
MIRRORS=&lt;list IP addresses of Shorewall mirrors&gt;</programlisting></para>
</blockquote>
</section>
<section>
<title>Zones File</title>
<blockquote>
<programlisting>#ZONE TYPE OPTTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
loc ipv4
dmz:loc ipv4
vpn ipv4
Wifi ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>Interfaces File</title>
<blockquote>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
net $EXT_IF 206.124.146.255 dhcp,norfc1918,logmartians,blacklist,tcpflags,nosmurfs
loc $INT_IF detect dhcp,routeback
vpn tun+ -
Wifi $WIFI_IF - dhcp,maclist
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>Hosts File</title>
<para>This file is used to define the dmz zone -- the single (virtual)
system with internal IP address 192.168.1.7.</para>
<blockquote>
<programlisting>#ZONE HOST(S) OPTIONS
dmz $INT_IF:192.168.1.7
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>Routestopped File</title>
<blockquote>
<programlisting>#INTERFACE HOST(S) OPTIONS
$INT_IF - source,dest
$WIFI_IF - source,dest
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>Providers File</title>
<blockquote>
<para>This entry isn't necessary but it allows me to smoke test
parsing of the providers file.</para>
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
Blarg 1 1 main $EXT_IF 206.124.146.254 track,balance=1 $INT_IF,$WIFI_IF,tun0
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>Blacklist File (Edited)</title>
<blockquote>
<para>I blacklist a number of ports globally to cut down on the amount
of noise in my firewall log. Note that the syntax shown below was
introduced in Shorewall 3.0.3 ("-" in the ADDRESS/SUBNET column);
earlier versions must use "0.0.0.0/0".</para>
<programlisting>#ADDRESS/SUBNET PROTOCOL PORT
- udp 1024:1033
- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>RFC1918 File</title>
<blockquote>
<para>Because my DSL modem has an RFC 1918 address (192.168.1.1) and
is connected to eth0, I need to make an exception for that address in
my rfc1918 file. I copied /usr/share/shorewall/rfc1918 to
/etc/shorewall/rfc1918 and changed it as follows:</para>
<programlisting>#SUBNET TARGET
<emphasis role="bold">192.168.1.1 RETURN</emphasis>
172.16.0.0/12 logdrop # RFC 1918
192.168.0.0/16 logdrop # RFC 1918
10.0.0.0/8 logdrop # RFC 1918
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>Policy File</title>
<blockquote>
<programlisting>#SOURCE DESTINATION POLICY LOG LEVEL BURST:LIMIT
$FW $FW ACCEPT
loc net ACCEPT
$FW vpn ACCEPT
vpn net ACCEPT
vpn loc ACCEPT
fw Wifi ACCEPT
loc vpn ACCEPT
$FW loc ACCEPT #Firewall to Local
loc $FW REJECT $LOG
net all DROP $LOG 10/sec:40
all all REJECT $LOG
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>Masq File</title>
<blockquote>
<para>Although most of our internal systems use one-to-one NAT, my
wife's system (192.168.1.4) uses IP Masquerading (actually SNAT) as do
our wireless network systems and visitors with laptops.</para>
<para>The first entry allows access to the DSL modem and uses features
introduced in Shorewall 2.1.1. The leading plus sign ("+_") causes the
rule to be placed before rules generated by the /etc/shorewall/nat
file below.</para>
<programlisting>#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
+$EXT_IF:192.168.1.1 0.0.0.0/0 192.168.1.254
$EXT_IF 192.168.0.0/22 206.124.146.179
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>NAT File</title>
<blockquote>
<programlisting>#EXTERNAL INTERFACE INTERNAL ALL LOCAL
# INTERFACES
206.124.146.177 $EXT_IF 192.168.1.7 No No
206.124.146.178 $EXT_IF 192.168.1.5 No No
206.124.146.180 $EXT_IF 192.168.1.6 No No
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>Tunnels</title>
<blockquote>
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE PORT
openvpnserver:1194 net 0.0.0.0/0
openvpnserver:1194 Wifi 192.168.3.0/24
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section id="Actions">
<title>Actions File</title>
<blockquote>
<para>The Limit action is described in a <ulink
url="PortKnocking.html#Limit">separate article</ulink>.</para>
<programlisting>#ACTION
Mirrors #Accept traffic from the Shorewall Mirror sites
Limit #Limit connection rate from each individual Host
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>action.Mirrors File</title>
<blockquote>
<para>$MIRRORS is set in <filename>/etc/shorewall/params</filename>
above.</para>
<programlisting>#TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT PORT(S) DEST LIMIT
ACCEPT $MIRRORS
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>Accounting File</title>
<blockquote>
<programlisting>#ACTION CHAIN SOURCE DESTINATION PROTO DEST SOURCE USER/
# PORT(S) PORT(S) GROUP
hp:COUNT accounting $EXT_IF $INT_IF:192.168.1.6 UDP
hp:COUNT accounting $INT_IF:192.168.1.6 $EXT_IF UDP
DONE hp
mail:COUNT - $EXT_IF $INT_IF:192.168.1.7 tcp 25
mail:COUNT - $INT_IF:192.168.1.7 $EXT_IF tcp 25
DONE mail
web - $EXT_IF $INT_IF:192.168.1.7 tcp 80
web - $EXT_IF $INT_IF:192.168.1.7 tcp 443
web - $INT_IF:192.168.1.7 $EXT_IF tcp 80
web - $INT_IF:192.168.1.7 $EXT_IF tcp 443
COUNT web $EXT_IF $INT_IF:192.168.1.7
COUNT web $INT_IF:192.168.1.7 $EXT_IF
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>Rules File (The shell variables are set in
/etc/shorewall/params)</title>
<blockquote>
<programlisting>SECTION NEW
###############################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT PORT(S) DEST LIMIT GROUP
###############################################################################################################################################################################
REJECT:$LOG loc net tcp 25
REJECT:$LOG loc net udp 1025:1031
#
# Stop NETBIOS crap
#
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
#
# Stop my idiotic work laptop from sending to the net with an HP source/dest IP address
#
DROP loc:!192.168.0.0/22 net
DROP Wifi net:15.0.0.0/8
DROP Wifi net:16.0.0.0/8
###############################################################################################################################################################################
# Local Network to Firewall
#
DROP loc:!192.168.0.0/22 fw # Silently drop traffic with an HP source IP from my XP box
Limit:$LOG:SSHA,3,60\
loc fw tcp 22
ACCEPT loc fw tcp time,631,8080
ACCEPT loc fw udp 161,ntp,631
ACCEPT loc:192.168.1.5 fw udp 111
DROP loc fw tcp 3185 #SUSE Meta pppd
Ping/ACCEPT loc fw
###############################################################################################################################################################################
# Local Network to Wireless
#
Ping/ACCEPT loc Wifi
###############################################################################################################################################################################
# Insecure Wireless to DMZ
#
ACCEPT Wifi dmz udp domain
ACCEPT Wifi dmz tcp domain
###############################################################################################################################################################################
# Insecure Wireless to Internet
#
ACCEPT Wifi net udp 500
ACCEPT Wifi net udp 4500
ACCEPT Wifi:192.168.3.9 net all
Ping/ACCEPT Wifi net
###############################################################################################################################################################################
# Insecure Wireless to Firewall
#
SSH/ACCEPT Wifi fw
###############################################################################################################################################################################
# Road Warriors to Firewall
#
ACCEPT vpn fw tcp ssh,time,631,8080
ACCEPT vpn fw udp 161,ntp,631
Ping/ACCEPT vpn fw
###############################################################################################################################################################################
# Road Warriors to DMZ
#
ACCEPT vpn dmz udp domain
ACCEPT vpn dmz tcp www,smtp,smtps,domain,ssh,imap,https,imaps,ftp,10023,pop3 -
Ping/ACCEPT vpn dmz
###############################################################################################################################################################################
# Local network to DMZ
#
ACCEPT loc dmz udp domain
ACCEPT loc dmz tcp ssh,smtps,www,ftp,imaps,domain,https -
ACCEPT loc dmz tcp smtp
ACCEPT loc dmz udp 33434:33454
###############################################################################################################################################################################
# Internet to ALL -- drop NewNotSyn packets
#
dropNotSyn net fw tcp
dropNotSyn net loc tcp
dropNotSyn net dmz tcp
###############################################################################################################################################################################
# Internet to DMZ
#
ACCEPT net dmz udp domain
LOG:$LOG net:64.126.128.0/18 dmz tcp smtp
ACCEPT net dmz tcp smtps,www,ftp,imaps,domain,https -
ACCEPT net dmz tcp smtp - 206.124.146.177,206.124.146.178
ACCEPT net dmz udp 33434:33454
Mirrors net dmz tcp rsync
Limit:$LOG:SSHA,3,60\
net dmz tcp 22
Ping/ACCEPT net dmz
###############################################################################################################################################################################
#
# Net to Local
#
##########################################################################################
# Test Server
#
ACCEPT net loc:192.168.1.9 tcp 80
ACCEPT net loc:192.168.1.9 tcp 443
ACCEPT net loc:192.168.1.9 tcp 21
Ping/ACCEPT net loc:192.168.1.9
#
# When I'm "on the road", the following two rules allow me VPN access back home using PPTP.
#
DNAT net loc:192.168.1.4 tcp 1729
DNAT net loc:192.168.1.4 gre
#
# Roadwarrior access to Ursa
#
ACCEPT net:$OMAK loc tcp 22
Limit:$LOG:SSHA,3,60\
net loc tcp 22
#
# ICQ
#
ACCEPT net loc:192.168.1.5 tcp 113,4000:4100
#
# Bittorrent
#
ACCEPT net loc:192.168.1.5 tcp 6881:6889,6969
ACCEPT net loc:192.168.1.5 udp 6881:6889,6969
#
# Real Audio
#
ACCEPT net loc:192.168.1.5 udp 6970:7170
#
# Overnet
#
#ACCEPT net loc:192.168.1.5 tcp 4662
#ACCEPT net loc:192.168.1.5 udp 12112
#
# OpenVPN
#
ACCEPT net loc:192.168.1.5 udp 1194
#
# Skype
#
ACCEPT net loc:192.168.1.6 tcp 1194
#
# Silently Handle common probes
#
REJECT net loc tcp www,ftp,https
DROP net loc icmp 8
###############################################################################################################################################################################
# DMZ to Internet
#
ACCEPT dmz net udp domain,ntp
ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,https,cvspserver,2702,2703,8080
ACCEPT dmz net:$POPSERVERS tcp pop3
Ping/ACCEPT dmz net
#
# Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking
# code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases
# but logs the connection so I can keep an eye on this potential security hole.
#
ACCEPT:$LOG dmz net tcp 1024: 20
###############################################################################################################################################################################
# DMZ to Firewall -- ntp &amp; snmp, Silently reject Auth
#
ACCEPT dmz fw udp ntp ntp
ACCEPT dmz fw tcp 161,ssh
ACCEPT dmz fw udp 161
REJECT dmz fw tcp auth
Ping/ACCEPT dmz fw
###############################################################################################################################################################################
# Internet to Firewall
#
REJECT net fw tcp www,ftp,https
DROP net fw icmp 8
ACCEPT net fw udp 33434:33454
ACCEPT net:$OMAK fw udp ntp
ACCEPT net fw tcp auth
ACCEPT net:$OMAK fw tcp 22
Limit:$LOG:SSHA,3,60\
net fw tcp 22
###############################################################################################################################################################################
# Firewall to Internet
#
ACCEPT fw net:$NTPSERVERS udp ntp ntp
#ACCEPT fw net:$POPSERVERS tcp pop3
ACCEPT fw net udp domain
ACCEPT fw net tcp domain,www,https,ssh,1723,whois,1863,ftp,2702,2703,7
ACCEPT fw net udp 33435:33535
ACCEPT fw net icmp
REJECT:$LOG fw net udp 1025:1031
DROP fw net udp ntp
Ping/ACCEPT fw net
###############################################################################################################################################################################
# Firewall to DMZ
#
ACCEPT fw dmz tcp domain,www,ftp,ssh,smtp,993,465
ACCEPT fw dmz udp domain
REJECT fw dmz udp 137:139
Ping/ACCEPT fw dmz
###############################################################################################################################################################################
# Firewall to Insecure Wireless
#
Ping/ACCEPT fw Wifi
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>/etc/shorewall/tcdevices</title>
<blockquote>
<programlisting>#INTERFACE IN-BANDWITH OUT-BANDWIDTH
$EXT_IF 1.5mbit 384kbit
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>/etc/shorewall/tcclasses</title>
<blockquote>
<para>My traffic shaping configuration is basically the "WonderShaper"
<ulink
url="http://www1.shorewall.net/pub/shorewall/Samples/tc4shorewall">example
from tc4shorewall</ulink> with a little tweaking.</para>
<programlisting>#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
$EXT_IF 10 full ful 1 tcp-ack,tos-minimize-delay
$EXT_IF 20 9*full/10 9*full/10 2 default
$EXT_IF 30 6*full/10 6*full/10 3
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>/etc/shorewall/tcrules</title>
<blockquote>
<para>I give full bandwidth to my local systems -- the server gets
throttled and rsync gets throttled even more.</para>
<note>
<para>The class id for tc4shorewall-generated classes is
&lt;<emphasis>device number</emphasis>&gt;:&lt;<emphasis>100 + mark
value</emphasis>&gt; where the first device in
<filename>/etc/shorewall/tcdevices</filename> is device number 1,
the second is device number 2 and so on. The rules below are using
the Netfilter CLASSIFY target to classify the traffic directly
without having to first mark then classify based on the
marks.</para>
</note>
<programlisting>#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST
# PORT(S)
1:110 192.168.0.0/22 $EXT_IF
1:130 206.124.146.177 $EXT_IF tcp - 873 #Rsync to the Mirrors
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para>Here is the output of <command>shorewall show tc</command> while
the Shorewall mirrors were receiving updates via rsync and the link
was otherwise idle. Note the rate limiting imposed by the 1:30
Class.</para>
<programlisting>Shorewall-3.0.0-RC2 Traffic Control at gateway - Sat Oct 22 09:11:26 PDT 2005
...
Device eth2:
qdisc htb 1: r2q 10 default 120 direct_packets_stat 2 ver 3.17
Sent 205450106 bytes 644093 pkts (dropped 0, overlimits 104779)
backlog 20p
qdisc ingress ffff: ----------------
Sent 160811382 bytes 498294 pkts (dropped 37, overlimits 0)
qdisc sfq 110: parent 1:110 limit 128p quantum 1514b flows 128/1024 perturb 10sec
Sent 81718034 bytes 417516 pkts (dropped 0, overlimits 0)
qdisc sfq 120: parent 1:120 limit 128p quantum 1514b flows 128/1024 perturb 10sec
Sent 61224535 bytes 177773 pkts (dropped 0, overlimits 0)
qdisc sfq 130: parent 1:130 limit 128p quantum 1514b flows 128/1024 perturb 10sec
Sent 62507157 bytes 48802 pkts (dropped 0, overlimits 0)
backlog 20p
class htb 1:110 parent 1:1 leaf 110: prio 1 quantum 4915 rate 384000bit ceil 384000bit burst 1791b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 0
Sent 81718034 bytes 417516 pkts (dropped 0, overlimits 0)
rate 424bit
lended: 417516 borrowed: 0 giants: 0
tokens: 36864 ctokens: 36864
class htb 1:1 root rate 384000bit ceil 384000bit burst 1791b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 7
Sent 205422474 bytes 644073 pkts (dropped 0, overlimits 0)
rate 231568bit 19pps
lended: 0 borrowed: 0 giants: 0
tokens: -26280 ctokens: -26280
class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 2944 rate 230000bit ceil 230000bit burst 1714b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0
Sent 62507157 bytes 48802 pkts (dropped 0, overlimits 0)
<emphasis role="bold">rate 230848bit 19pps backlog 18p</emphasis>
lended: 48784 borrowed: 0 giants: 0
tokens: -106401 ctokens: -106401
class htb 1:120 parent 1:1 leaf 120: prio 2 quantum 4416 rate 345000bit ceil 345000bit burst 1771b/8 mpu 0b overhead 0b cburst 1771b/8 mpu 0b overhead 0b level 0
Sent 61224535 bytes 177773 pkts (dropped 0, overlimits 0)
rate 1000bit
lended: 177773 borrowed: 0 giants: 0
tokens: 41126 ctokens: 41126
...</programlisting>
</blockquote>
</section>
<section>
<title>/etc/openvpn/server.conf</title>
<para>Only the tunnel-mode OpenVPN configuration is described here --
the bridge is described in the <ulink url="OPENVPN.html">OpenVPN
documentation</ulink>.</para>
<blockquote>
<programlisting>dev tun
local 206.124.146.176
server 192.168.2.0 255.255.255.0
dh dh1024.pem
ca /etc/certs/cacert.pem
crl-verify /etc/certs/crl.pem
cert /etc/certs/gateway.pem
key /etc/certs/gateway_key.pem
port 1194
comp-lzo
user nobody
group nogroup
keepalive 15 45
ping-timer-rem
persist-tun
persist-key
client-config-dir /etc/openvpn/clients
ccd-exclusive
client-to-client
verb 3</programlisting>
</blockquote>
</section>
</section>
<section>
<title>Tipper and Eastepnc6000 Configuration in the Wireless
Network</title>
<para>Please find this information in the <ulink
url="OPENVPN.html#Bridge">OpenVPN bridge mode</ulink>
documentation.</para>
</section>
<section>
<title>Tipper Configuration while on the Road</title>
<para>This laptop is either configured on our wireless network
(192.168.3.8) or as a standalone system on the road.</para>
<para><emphasis>Tipper</emphasis>'s view of the world is shown in the
following diagram:</para>
<graphic align="center" fileref="images/network2.png" valign="middle" />
<section>
<title>zones</title>
<blockquote>
<programlisting>#ZONE DISPLAY COMMENTS
home Home Shorewall Network
net Net Internet
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>policy</title>
<blockquote>
<programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
$FW net ACCEPT
$FW home ACCEPT
home $FW ACCEPT
net home NONE
home net NONE
net all DROP info
# The FOLLOWING POLICY MUST BE LAST
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>interfaces</title>
<blockquote>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,tcpflags
home tun0 -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>rules</title>
<blockquote>
<programlisting>#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT PORT(S) DEST LIMIT GROUP
ACCEPT net $FW icmp 8
ACCEPT net $FW tcp 22
ACCEPT net $FW tcp 4000:4100
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>/etc/openvpn/home.conf</title>
<blockquote>
<programlisting>dev tun
remote gateway.shorewall.net
up /etc/openvpn/home.up
tls-client
pull
ca /etc/certs/cacert.pem
cert /etc/certs/tipper.pem
key /etc/certs/tipper_key.pem
port 1194
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
verb 3</programlisting>
</blockquote>
</section>
<section>
<title>/etc/openvpn/home.up</title>
<blockquote>
<programlisting>#!/bin/bash
ip route add 192.168.1.0/24 via $5 #Access to Home Network
ip route add 206.124.146.177/32 via $5 #So that DNS names will resolve in my
#Internal Bind 9 view because the source IP will
#be in 192.168.2.0/24</programlisting>
</blockquote>
</section>
</section>
</article>

688
docs/upgrade_issues.xml
View File

@ -43,7 +43,7 @@
</legalnotice>
</articleinfo>
<section>
<section id="Important">
<title>Important</title>
<para>It is important that you read all of the sections on this page where
@ -69,12 +69,12 @@
command to see the groups associated with each of your zones.</para>
</section>
<section>
<section id="V4.0.0">
<title>Versions &gt;= 4.0.0-Beta1</title>
<orderedlist>
<listitem>
<para> This is the first Shorewall release that fully integrates the
<para>This is the first Shorewall release that fully integrates the
new Shorewall-perl compiler. You are now offered a choice as to which
compiler(s) you install. In Shorewall 4.0.0, there are the following
packages:<itemizedlist>
@ -123,12 +123,12 @@ rpm -U shorewall-4.0.0.noarch.rpm</programlisting>If you are upgrading using
caused the corresponding flag in /proc to be reset for all interfaces.
Beginning in Shorewall 4.0.0, leaving these options empty causes
Shorewall to leave the flags in /proc as they are. You must set the
option to 'No' in order to obtain the old behavior. </para>
option to 'No' in order to obtain the old behavior.</para>
</listitem>
</orderedlist>
</section>
<section>
<section id="V3.4.0">
<title>Versions &gt;= 3.4.0-Beta1</title>
<orderedlist>
@ -336,7 +336,7 @@ all all REJECT:MyReject info</programlisting>
</orderedlist>
</section>
<section>
<section id="V3.2.0">
<title>Version &gt;= 3.2.0</title>
<orderedlist>
@ -546,7 +546,7 @@ all all REJECT:MyReject info</programlisting>
</orderedlist>
</section>
<section>
<section id="V3.0.0">
<title>Version &gt;= 3.0.0</title>
<orderedlist>
@ -687,7 +687,7 @@ rejNotSyn:info net all tcp</programlisting>
</orderedlist>
</section>
<section>
<section id="V2.4.0">
<title>Version &gt;= 2.4.0</title>
<orderedlist>
@ -714,676 +714,4 @@ rejNotSyn:info net all tcp</programlisting>
</listitem>
</orderedlist>
</section>
<section>
<title>Version &gt;= 2.2.0</title>
<orderedlist>
<listitem>
<para>Shorewall configuration files except shorewall.conf are now
empty (they contain only comments). If you wish to retain the defaults
in any of the following files, you should copy these files before
upgrading them then restore them after the upgrade:</para>
<simplelist>
<member>/etc/shorewall/zones</member>
<member>/etc/shorewall/policy</member>
<member>/etc/shorewall/tos</member>
</simplelist>
</listitem>
<listitem>
<para>The following builtin actions have been removed and have been
replaced by the new action logging implementation described in the new
features below.</para>
<simplelist>
<member>logNotSyn</member>
<member>rLogNotSyn</member>
<member>dLogNotSyn</member>
</simplelist>
</listitem>
<listitem>
<para>If shorewall.conf is upgraded to the latest version, it needs to
be modified to set STARTUP_ENABLED=Yes.</para>
</listitem>
<listitem>
<para>The Leaf/Bering version of Shorewall was previously
named:</para>
<simplelist>
<member>shorwall-&lt;version&gt;.lrp</member>
</simplelist>
<para>Beginning with 2.1, that file will now be named:</para>
<simplelist>
<member>shorewall-lrp-&lt;version&gt;.tgz</member>
</simplelist>
<para>Simply rename that file to 'shorwall.lrp' when installing it on
your LEAF/Bering system.</para>
</listitem>
<listitem>
<para>The ORIGINAL DEST column of the /etc/shorewall/rules file may no
longer contain a second (SNAT) address. You must use an entry in
/etc/shorewall/masq instead.</para>
<para>Example from Shorewall FAQ #1:</para>
<blockquote>
<para>Prior to Shorewall 2.1:</para>
<para>/etc/shorewall/interfaces</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 detect routeback</programlisting>
<para>/etc/shorewall/rules</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST
DNAT loc loc:192.168.1.12 tcp 80 - 130.252.100.69:192.168.1.254 </programlisting>
<para>Shorewall 2.1 and Later:</para>
<para>/etc/shorewall/interfaces</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 detect routeback</programlisting>
<para>/etc/shorewall/masq:</para>
<programlisting>#INTERFACE SUBNETS ADDRESS PROTO PORT(S)
eth1 eth1 192.168.1.254 tcp 80</programlisting>
<para>/etc/shorewall/rules:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST
DNAT loc loc:192.168.1.12 tcp 80 - 130.252.100.69</programlisting>
</blockquote>
</listitem>
<listitem>
<para>The 'logunclean' and 'dropunclean' options that were deprecated
in Shorewall 2.0 have now been removed completely.</para>
</listitem>
<listitem>
<para>The default port for 'openvpn' tunnels (/etc/shorewall/tunnels)
has been changed to 1194 to match a similar change in the OpenVPN
product. The IANA has registered port 1194 for use by OpenVPN.</para>
</listitem>
<listitem>
<para>A new IPTABLES variable has been added to shorewall.conf. This
variable names the iptables executable that Shorewall will use. The
variable is set to "/sbin/iptables". If you use the new
shorewall.conf, you may need to change this setting to maintain
compatibility with your current setup (if you use your existing
shorewall.conf that does not set IPTABLES then you should experience
no change in behavior).</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Version &gt;= 2.0.2 RC1</title>
<itemizedlist>
<listitem>
<para>If you are upgrading from Shorewall 1.4.x and you have commands
in your <filename>/etc/shorewall/common</filename> file that are not
directly related to the <emphasis role="bold">common</emphasis> chain
then you will want to move those commands to
<filename>/etc/shorewall/initdone</filename>.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version &gt;= 2.0.2 Beta 1</title>
<itemizedlist>
<listitem>
<para>Extension Scripts - In order for extension scripts to work
properly with the new iptables-save/restore integration introduced in
Shorewall 2.0.2 Beta 1, some change may be required to your extension
scripts.</para>
<para>If your extension scripts are executing commands other than
<command>iptables</command> then those commands must also be written
to the restore file (a temporary file in <filename
class="directory">/var/lib/shorewall</filename> that is renamed
<filename>/var/lib/shorewall/restore-base</filename> at the completion
of the <filename>/sbin/shorewall</filename> command). The following
functions should be of help:</para>
<orderedlist>
<listitem>
<para>save_command() -- saves the passed command to the restore
file.</para>
<para>Example: <programlisting>save_command echo Operation Complete</programlisting></para>
<para>That command would simply write "echo Operation Complete" to
the restore file.</para>
</listitem>
<listitem>
<para>run_and_save_command() -- saves the passed command to the
restore file then executes it. The return value is the exit status
of the command. Example: <programlisting>run_and_save_command "echo 1 &gt; /proc/sys/net/ipv4/icmp_echo_ignore_all"</programlisting></para>
<para>Note that as in this example, when the command involves file
redirection then the entire command must be enclosed in quotes.
This applies to all of the functions described here.</para>
</listitem>
<listitem>
<para>ensure_and_save_command() -- runs the passed command. If the
command fails, the firewall is restored to its prior saved state
and the operation is terminated. If the command succeeds, the
command is written to the restore file</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>Dynamic Zone support. - If you don't need to use the
<command>shorewall add</command> and <command>shorewall
delete</command> commands, you should set DYNAMIC_ZONES=No in
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version &gt;= 2.0.1</title>
<itemizedlist>
<listitem>
<para>The function of 'norfc1918' is now split between that option and
a new 'nobogons' option. The rfc1918 file released with Shorewall now
contains entries for only those three address ranges reserved by RFC
1918. A 'nobogons' interface option has been added which handles bogon
source addresses (those which are reserved by the IANA, those reserved
for DHCP auto-configuration and the class C test-net reserved for
testing and documentation examples). This will allow users to perform
RFC 1918 filtering without having to deal with out of date data from
IANA. Those who are willing to update their
<filename>/usr/share/shorewall/bogons</filename> file regularly can
specify the 'nobogons' option in addition to 'norfc1918'. The level at
which bogon packets are logged is specified in the new BOGON_LOG_LEVEL
variable in shorewall.conf. If that option is not specified or is
specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon packets whose
TARGET is 'logdrop' in
<filename>/usr/share/shorewall/bogons</filename> are logged at the
'info' level.</para>
<warning>
<para>If you have a file named <filename>rfc1918</filename> in your
<filename class="directory">/etc/shorewall</filename> directory, you
must either remove that file or you must copy
<filename>/usr/share/shorewall/rfc1918</filename> to <filename
class="directory">/etc/shorewall</filename> and modify that file
appropriately. Do not leave the old <filename>rfc1918</filename>
file in <filename
class="directory">/etc/shorewall</filename>.</para>
</warning>
</listitem>
</itemizedlist>
</section>
<section>
<title>VERSION &gt;= 2.0.0-Beta1</title>
<itemizedlist>
<listitem>
<para>The 'dropunclean' and 'logunclean' interface options are no
longer supported. If either option is specified in
<filename>/etc/shorewall/interfaces</filename>, a threatening message
will be generated.</para>
</listitem>
<listitem>
<para>The NAT_BEFORE_RULES option has been removed from
<filename>shorewall.conf</filename>. The behavior of Shorewall 2.0 is
as if NAT_BEFORE_RULES=No had been specified. In other words, DNAT
rules now always take precedence over one-to-one NAT
specifications.</para>
</listitem>
<listitem>
<para>The default value for the ALL INTERFACES column in
<filename>/etc/shorewall/nat</filename> has changed. In Shorewall 1.*,
if the column was left empty, a value of "Yes" was assumed. This has
been changed so that a value of "No" is now assumed.</para>
</listitem>
<listitem>
<para>The following files don't exist in Shorewall 2.0:</para>
<simplelist>
<member><filename>/etc/shorewall/common.def</filename></member>
<member><filename>/etc/shorewall/common</filename></member>
<member><filename>/etc/shorewall/icmpdef</filename></member>
<member><filename>/etc/shorewall/action.template</filename> (moved
to
<filename>/usr/share/shorewall/action.template</filename>)</member>
</simplelist>
<para>The <filename>/etc/shorewall/action</filename> file now allows
an action to be designated as the "common" action for a particular
policy type by following the action name with ":" and the policy
(DROP, REJECT or ACCEPT).</para>
<para>The file /usr/share/shorewall/actions.std has been added to
define those actions that are released as part of Shorewall 2.0 In
that file are two actions as follows:</para>
<simplelist>
<member>Drop:DROP</member>
<member>Reject:REJECT</member>
</simplelist>
<para>The <quote>Drop</quote> action is the common action for DROP
policies while the <quote>Reject</quote> action is the default action
for REJECT policies. These actions will be performed on packets prior
to applying the DROP or REJECT policy respectively. In the first
release, the difference between "Reject" and "Drop" is that "Reject"
REJECTs SMB traffic while "Drop" silently drops such traffic.</para>
<para>As described above, Shorewall allows a common action for ACCEPT
policies but does not specify such an action in the default
configuration.</para>
<para>For more information see the <ulink
url="Actions.html">User-defined Action Page</ulink>.</para>
</listitem>
<listitem>
<para>The <filename>/etc/shorewall</filename> directory no longer
contains <filename>users</filename> file or a
<filename>usersets</filename> file. Similar functionality is now
available using user-defined actions.</para>
<para>Now, action files created by copying
<filename>/usr/share/shorewall/action.template</filename> may now
specify a USER and or GROUP name/id in the final column just like in
the rules file (see below). It is thus possible to create actions that
control traffic from a list of users and/or groups.</para>
</listitem>
<listitem>
<para>The last column in <filename>/etc/shorewall/rules</filename> is
now labeled USER/GROUP and may contain:</para>
<simplelist>
<member>[!]&lt;<emphasis>user number</emphasis>&gt;[:]</member>
<member>[!]&lt;<emphasis>user name</emphasis>&gt;[:]</member>
<member>[!]:&lt;<emphasis>group number</emphasis>&gt;</member>
<member>[!]:&lt;<emphasis>group name</emphasis>&gt;</member>
<member>[!]&lt;<emphasis>user
number</emphasis>&gt;:&lt;<emphasis>group
number</emphasis>&gt;</member>
<member>[!]&lt;<emphasis>user
name</emphasis>&gt;:&lt;<emphasis>group
number</emphasis>&gt;</member>
<member>[!]&lt;<emphasis>user
inumber</emphasis>&gt;:&lt;<emphasis>group
name</emphasis>&gt;</member>
<member>[!]&lt;<emphasis>user
name</emphasis>&gt;:&lt;<emphasis>group name</emphasis>&gt;</member>
</simplelist>
</listitem>
<listitem>
<para>If your kernel has IPV6 support (recent
<trademark>SUSE</trademark> for example), and you don't use IPV6 then
you will probably want to set DISABLE_IPV6=Yes in <ulink
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.
You must have ipv6tables installed.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version &gt;= 1.4.9</title>
<itemizedlist>
<listitem>
<para>The default value of NEWNOTSYN set in <ulink
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink> has
been changed from 'No' to 'Yes'. I find that NEWNOTSYN=No tends to
result in lots of "stuck" connections because any network timeout
during TCP session tear down results in retries being dropped
(Netfilter has removed the connection from the conntrack table but the
end-points haven't completed shutting down the connection). I
therefore have chosen NEWNOTSYN=Yes as the default value and I advise
caution in using NEWNOTSYN=Yes.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version &gt;= 1.4.8</title>
<itemizedlist mark="bullet">
<listitem>
<para>The meaning of <varname>ROUTE_FILTER=Yes</varname> has changed.
Previously this setting was documented as causing route filtering to
occur on all network interfaces; this didn't work. Beginning with this
release, <varname>ROUTE_FILTER=Yes</varname> causes route filtering to
occur on all interfaces brought up while Shorewall is running. This
means that it may be appropriate to set
<varname>ROUTE_FILTER=Yes</varname> and use the routefilter option in
<filename
class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
entries.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version &gt;= 1.4.6</title>
<itemizedlist mark="bullet">
<listitem>
<para>The <varname>NAT_ENABLED</varname>,
<varname>MANGLE_ENABLED</varname> and <varname>MULTIPORT</varname>
options have been removed from <filename>shorewall.conf</filename>.
These capabilities are now automatically detected by Shorewall.</para>
</listitem>
<listitem>
<para>An undocumented feature previously allowed entries in the host
file as follows: <synopsis>
zone eth1:192.168.1.0/24,eth2:192.168.2.0/24
</synopsis> This capability was never documented and has been removed in
1.4.6 to allow entries of the following format: <synopsis>
zone eth1:192.168.1.0/24,192.168.2.0/24
</synopsis></para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version &gt;= 1.4.4</title>
<para>If you are upgrading from 1.4.3 and have set the
<varname>LOGMARKER</varname> variable in <filename
class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>,
then you must set the new <varname>LOGFORMAT</varname> variable
appropriately and remove your setting of
<varname>LOGMARKER</varname>.</para>
</section>
<section>
<title>Version 1.4.4</title>
<para>If you have zone names that are 5 characters long, you may
experience problems starting Shorewall because the
<option>--log-prefix</option> in a logging rule is too long. Upgrade to
Version 1.4.4a to fix this problem.</para>
</section>
<section>
<title>Version &gt;= 1.4.2</title>
<para>There are some cases where you may want to handle traffic from a
particular group to itself. While I personally think that such a setups
are ridiculous, there are two cases covered in this documentation where it
can occur: <itemizedlist>
<listitem>
<para><ulink url="FAQ.htm#faq2">In FAQ #2</ulink></para>
</listitem>
<listitem>
<para><ulink url="Shorewall_Squid_Usage.html">When running
<application>Squid</application> as a transparent proxy in your
local zone.</ulink></para>
</listitem>
</itemizedlist> If you have either of these cases, you will want to
review the current documentation and change your configuration
accordingly.</para>
</section>
<section>
<title>Version &gt;= 1.4.1</title>
<itemizedlist mark="bullet">
<listitem>
<para>Beginning with Version 1.4.1, traffic between groups in the same
zone is accepted by default. Previously, traffic from a zone to itself
was treated just like any other traffic; any matching rules were
applied followed by enforcement of the appropriate policy. With 1.4.1
and later versions, unless you have explicit rules for traffic from Z
to Z or you have an explicit Z to Z policy (where "Z" is some zone)
then traffic between the groups in zone Z will be accepted. If you do
have one or more explicit rules for Z to Z or if you have an explicit
Z to Z policy then the behavior is as it was in prior versions.</para>
<orderedlist numeration="arabic">
<listitem>
<para>If you have a Z Z ACCEPT policy for a zone to allow traffic
between two interfaces to the same zone, that policy can be
removed and traffic between the interfaces will traverse fewer
rules than previously.</para>
</listitem>
<listitem>
<para>If you have a Z Z DROP or Z Z REJECT policy or you have
Z-&gt;Z rules then your configuration should not require any
change.</para>
</listitem>
<listitem>
<para>If you are currently relying on a implicit policy (one that
has "all" in either the SOURCE or DESTINATION column) to prevent
traffic between two interfaces to a zone Z and you have no rules
for Z-&gt;Z then you should add an explicit DROP or REJECT policy
for Z to Z.</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>Sometimes, you want two separate zones on one interface but you
don't want Shorewall to set up any infrastructure to handle traffic
between them. <example>
<title>The <filename>zones</filename>,
<filename>interfaces</filename> and, <filename>hosts</filename>
file contents</title>
<programlisting>
<filename class="directory">/etc/shorewall/</filename><filename>zones</filename>
z1 Zone1 The first Zone
z2 Zone2 The second Zone
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
z2 eth1 192.168.1.255
<filename class="directory">/etc/shorewall/</filename><filename>hosts</filename>
z1 eth1:192.168.1.3
</programlisting>
</example> Here, zone z1 is nested in zone z2 and the firewall is
not going to be involved in any traffic between these two zones.
Beginning with Shorewall 1.4.1, you can prevent Shorewall from setting
up any infrastructure to handle traffic between z1 and z2 by using the
new NONE policy: <example>
<title>The contents of <filename>policy</filename></title>
<programlisting>
<filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
z1 z2 NONE
z2 z1 NONE
</programlisting>
</example> Note that NONE policies are generally used in pairs
unless there is asymmetric routing where only the traffic on one
direction flows through the firewall and you are using a NONE policy
in the other direction.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version 1.4.1</title>
<itemizedlist mark="bullet">
<listitem>
<para>In Version 1.4.1, Shorewall will never create rules to deal with
traffic from a given group back to itself. The
<varname>multi</varname> interface option is no longer available so if
you want to route traffic between two subnetworks on the same
interface then I recommend that you upgrade to Version 1.4.2 and use
the <varname>routeback</varname> interface or host option.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Version &gt;= 1.4.0</title>
<important>
<para>Shorewall &gt;=1.4.0 requires the <command>iproute</command>
package ('<literal>ip</literal>' utility).</para>
</important>
<note>
<para>Unfortunately, some distributions call this package
<command>iproute2</command> which will cause the upgrade of Shorewall to
fail with the diagnostic: <synopsis>error: failed dependencies:iproute is needed by shorewall-1.4.0-1</synopsis>This
may be worked around by using the <option>--nodeps</option> option of
<command>rpm</command> (<command>rpm -Uvh --nodeps
<filename>your_shorewall_rpm.rpm</filename></command>).</para>
</note>
<para>If you are upgrading from a version &lt; 1.4.0, then: <itemizedlist
mark="bullet">
<listitem>
<para>The <varname>noping</varname> and
<varname>forwardping</varname> interface options are no longer
supported nor is the <varname>FORWARDPING</varname> option in
<filename>shorewall.conf</filename>. ICMP echo-request (ping)
packets are treated just like any other connection request and are
subject to rules and policies.</para>
</listitem>
<listitem>
<para>Interface names of the form
<varname>&lt;device&gt;:&lt;integer&gt;</varname> in <filename
class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
now generate a Shorewall error at startup (they always have produced
warnings in <application
class="software">iptables</application>).</para>
</listitem>
<listitem>
<para>The <varname>MERGE_HOSTS</varname> variable has been removed
from <filename>shorewall.conf</filename>. Shorewall 1.4 behaves like
1.3 did when <varname>MERGE_HOSTS=Yes</varname>; that is zone
contents are determined by <emphasis>BOTH</emphasis> the interfaces
and hosts files when there are entries for the zone in both
files.</para>
</listitem>
<listitem>
<para>The <varname>routestopped</varname> option in the interfaces
and hosts file has been eliminated; use entries in the
<filename>routestopped</filename> file instead.</para>
</listitem>
<listitem>
<para>The Shorewall 1.2 syntax for <varname>DNAT</varname> and
<varname>REDIRECT</varname> rules is no longer accepted; you must
convert to using the new syntax.</para>
</listitem>
<listitem>
<para>The <varname>ALLOWRELATED</varname> variable in
<filename>shorewall.conf</filename> is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with
<varname>ALLOWRELATED=Yes</varname>.</para>
</listitem>
<listitem>
<para>Late-arriving DNS replies are now dropped by default; there is
no need for your own <filename
class="directory">/etc/shorewall/</filename><filename>common</filename>
file simply to avoid logging these packets.</para>
</listitem>
<listitem>
<para>The <filename>firewall</filename>,
<filename>functions</filename> and <filename>version</filename>
files have been moved to <filename
class="directory">/usr/share/shorewall</filename>.</para>
</listitem>
<listitem>
<para>The <filename>icmp.def</filename> file has been removed. If
you include it from <filename
class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>,
you will need to modify that file.</para>
</listitem>
<listitem>
<para>If you followed the advice in FAQ #2 and call
<varname>find_interface_address</varname> in <filename
class="directory">/etc/shorewall/</filename><filename>params</filename>,
that code should be moved to <filename
class="directory">/etc/shorewall/</filename><filename>init</filename>.</para>
</listitem>
</itemizedlist></para>
</section>
<section>
<title>Version 1.4.0</title>
<itemizedlist mark="bullet">
<listitem>
<para>The <varname>multi</varname> interface option is no longer
supported. Shorewall will generate rules for sending packets back out
the same interface that they arrived on in two cases: <itemizedlist
mark="hollow">
<listitem>
<para>There is an <emphasis>explicit</emphasis> policy for the
source zone to or from the destination zone. An explicit policy
names both zones and does not use the <varname>all</varname>
reserved word.</para>
</listitem>
<listitem>
<para>There are one or more rules for traffic for the source
zone to or from the destination zone including rules that use
the <varname>all</varname> reserved word. Exception: if the
source zone and destination zone are the same then the rule must
be explicit - it must name the zone in both the
<varname>SOURCE</varname> and <varname>DESTINATION</varname>
columns.</para>
</listitem>
</itemizedlist></para>
</listitem>
</itemizedlist>
</section>
</article>