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

Spell check pass through first half of docs.

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@8667 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
el_cubano 2008-08-15 01:26:15 +00:00
parent 6f231a7a43
commit aac55dbac4
21 changed files with 111 additions and 111 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/6to4.xml
View File

@ -26,7 +26,7 @@
<copyright>
<year>2003-2004</year>
<holder>Eric de Thoars and Tom Eastep</holder>
<holder>Eric de Thouars and Tom Eastep</holder>
</copyright>
<legalnotice>

2
docs/Accounting.xml
View File

@ -202,7 +202,7 @@
on outbound ones.</para>
<para>Accounting rules are not stateful -- each rule only handles traffic
in one direction. For example, if eth0 is your internet interface, and you
in one direction. For example, if eth0 is your Internet interface, and you
have a web server in your DMZ connected to eth1, then to count HTTP
traffic in both directions requires two rules:</para>

4
docs/Actions.xml
View File

@ -144,9 +144,9 @@ ACCEPT - - tcp 135,139,445
<para>Ensure correct operation. Default actions can also avoid common
pitfalls like dropping connection requests on port TCP port 113. If
these connections are dropped (rather than rejected) then you may
encounter problems connecting to internet services that utilize the
encounter problems connecting to Internet services that utilize the
AUTH protocol of client authentication<footnote>
<para>AUTH is actually pretty silly on today's internet but it's
<para>AUTH is actually pretty silly on today's Internet but it's
amazing how many servers still employ it.</para>
</footnote></para>
</listitem>

4
docs/Anatomy.xml
View File

@ -81,7 +81,7 @@
class="directory">/usr/share/shorewall</filename>, <filename
class="directory">/etc/shorewall</filename>,
<filename>/etc/init.d</filename> and <filename
class="directory">/var/lilb/shorewall/</filename>. These are described in
class="directory">/var/lib/shorewall/</filename>. These are described in
the sub-sections that follow.</para>
<section id="sbin">
@ -363,7 +363,7 @@
class="directory">/usr/share/shorewall-lite</filename>, /etc/<filename
class="directory">shorewall-lite</filename>,
<filename>/etc/init.d</filename> and <filename
class="directory">/var/lilb/shorewall/</filename>. These are described in
class="directory">/var/lib/shorewall/</filename>. These are described in
the sub-sections that follow.</para>
<section id="sbin-lite">

2
docs/CompiledPrograms.xml
View File

@ -226,7 +226,7 @@
<note>
<para>The firewall systems do <emphasis role="bold">NOT</emphasis>
need to have the full Shorewall product installed but rather only
the Shorewall Lite product. Shorewall and Shorewall LIte may be
the Shorewall Lite product. Shorewall and Shorewall Lite may be
installed on the same system but that isn't encouraged.</para>
</note>
</listitem>

2
docs/ECN.xml
View File

@ -50,7 +50,7 @@
<title>Explicit Congestion Notification (ECN)</title>
<para>Explicit Congestion Notification (ECN) is described in RFC 3168 and
is a proposed internet standard. Unfortunately, not all sites support ECN
is a proposed Internet standard. Unfortunately, not all sites support ECN
and when a TCP connection offering ECN is sent to sites that don't support
it, the result is often that the connection request is ignored.</para>

74
docs/FAQ.xml
View File

@ -135,7 +135,7 @@
<section id="faq76">
<title>(FAQ 76) I just upgraded my Debian system and now masquerading
doesn work? What happened?</title>
doesn't work? What happened?</title>
<para><emphasis role="bold">Answer:</emphasis> This happens to people
who ignore <ulink url="Install.htm#Upgrade_Deb">our advice</ulink> and
@ -149,7 +149,7 @@
<section id="faq76a">
<title>(FAQ 76a) I just upgraded my Ubuntu system and now masquerading
doesn work? What happened?</title>
doesn't work? What happened?</title>
<para><emphasis role="bold">Answer:</emphasis> See <link
linkend="faq76">above</link>.</para>
@ -157,7 +157,7 @@
<section id="faq76b">
<title>(FAQ 76b) I just upgraded my Kubuntu system and now
masquerading doesn work? What happened?</title>
masquerading doesn't work? What happened?</title>
<para><emphasis role="bold">Answer:</emphasis> See <link
linkend="faq76">above</link>.</para>
@ -193,7 +193,7 @@ DNAT net loc:192.168.1.5 udp 7777</programlisting>
# PORT DEST.
DNAT net loc:<emphasis>local-IP-address</emphasis>&gt;[:<emphasis>local-port</emphasis>] <emphasis>protocol</emphasis> <emphasis>port-number</emphasis> - <emphasis>external-IP</emphasis></programlisting>
<para>If you want to forward requests from a particular internet address
<para>If you want to forward requests from a particular Internet address
( <emphasis>address</emphasis> ):</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
@ -253,7 +253,7 @@ DNAT net:<emphasis>address</emphasis> loc:<emphasis>local-IP-address</empha
<listitem>
<para>As root, type <quote> <command>shorewall reset</command>
</quote> ("<command>shorewall-lite reset</command>", if you are
running Shorewall Lite). This clears all NetFilter
running Shorewall Lite). This clears all Netfilter
counters.</para>
</listitem>
@ -315,7 +315,7 @@ DNAT net:<emphasis>address</emphasis> loc:<emphasis>local-IP-address</empha
the connection is being dropped or rejected. If it is, then you
may have a zone definition problem such that the server is in a
different zone than what is specified in the DEST column. At a
root promt, type "<command>shorewall show zones</command>"
root prompt, type "<command>shorewall show zones</command>"
("<command>shorewall-lite show zones</command>") then be sure that
in the DEST column you have specified the <emphasis
role="bold">first</emphasis> zone in the list that matches
@ -335,7 +335,7 @@ DNAT net:<emphasis>address</emphasis> loc:<emphasis>local-IP-address</empha
</section>
<section id="faq1c">
<title>(FAQ 1c) From the internet, I want to connect to port 1022 on
<title>(FAQ 1c) From the Internet, I want to connect to port 1022 on
my firewall and have the firewall forward the connection to port 22 on
local system 192.168.1.3. How do I do that?</title>
@ -462,7 +462,7 @@ eth1:192.168.1.4 0.0.0.0/0 192.168.1.1 tcp 21</
<section id="faq1g">
<title>(FAQ 1g) I would like to redirect port 80 on my public IP
address (206.124.146.176) to port 993 on internet host
address (206.124.146.176) to port 993 on Internet host
66.249.93.111</title>
<para><emphasis role="bold">Answer</emphasis>: This requires a vile
@ -497,8 +497,8 @@ eth0:66.249.93.111 0.0.0.0/0 206.124.146.176 tcp 993</programlistin
Guide</ulink> appropriate for your setup; the guides cover this topic in
a tutorial fashion. DNAT rules should be used for connections that need
to go the opposite direction from SNAT/MASQUERADE. So if you masquerade
or use SNAT from your local network to the internet then you will need
to use DNAT rules to allow connections from the internet to your local
or use SNAT from your local network to the Internet then you will need
to use DNAT rules to allow connections from the Internet to your local
network. You also want to use DNAT rules when you intentionally want to
rewrite the destination IP address or port number. In all other cases,
you use ACCEPT unless you need to hijack connections as they go through
@ -537,7 +537,7 @@ eth0:66.249.93.111 0.0.0.0/0 206.124.146.176 tcp 993</programlistin
<itemizedlist>
<listitem>
<para>Having an internet-accessible server in your local network is
<para>Having an Internet-accessible server in your local network is
like raising foxes in the corner of your hen house. If the server is
compromised, there's nothing between that server and your other
internal systems. For the cost of another NIC and a cross-over
@ -559,7 +559,7 @@ eth0:66.249.93.111 0.0.0.0/0 206.124.146.176 tcp 993</programlistin
</itemizedlist>
<para>So the best and most secure way to solve this problem is to move
your internet-accessible server(s) to a separate LAN segment with it's
your Internet-accessible server(s) to a separate LAN segment with it's
own interface to your firewall and follow <link linkend="faq2b">FAQ
2b</link>. That way, your local systems are still safe if your server
gets hacked and you don't have to run a split DNS configuration
@ -643,7 +643,7 @@ DNAT loc loc:192.168.1.5 tcp www - <emph
<para>If the ALL INTERFACES column in /etc/shorewall/nat is empty or
contains <quote>Yes</quote>, you will also see log messages like the
following when trying to access a host in Z from another host in Z
using the destination hosts's public address:</para>
using the destination host's public address:</para>
<programlisting>Oct 4 10:26:40 netgw kernel:
Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200
@ -685,7 +685,7 @@ DNAT loc loc:192.168.1.5 tcp www - <emph
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
dmz eth2 192.168.2.255 <emphasis role="bold">routeback</emphasis> </programlisting>
<para>In <filename>/etc/shorewall/na</filename>t, be sure that you
<para>In <filename>/etc/shorewall/nat</filename>, be sure that you
have <quote>Yes</quote> in the ALL INTERFACES column.</para>
<para>In /etc/shorewall/masq:</para>
@ -802,7 +802,7 @@ DNAT loc dmz:192.168.2.4 tcp 80 - <emph
<blockquote>
<para><programlisting>&gt; I know PoM -ng is going to address this issue, but till it is ready, and
&gt; all the extras are ported to it, is there any way to use the h.323
&gt; contrack module kernel patch with a 2.6 kernel?
&gt; conntrack module kernel patch with a 2.6 kernel?
&gt; Running 2.6.1 - no 2.4 kernel stuff on the system, so downgrade is not
&gt; an option... The module is not ported yet to 2.6, sorry.
&gt; Do I have any options besides a gatekeeper app (does not work in my
@ -831,7 +831,7 @@ to debug/develop the newnat interface.</programlisting></para>
url="shorewall_quickstart_guide.htm">Quick Start Guides</ulink> should
have to ask this question.</para>
<para>Regardless of which guide you used, all outbound communcation is
<para>Regardless of which guide you used, all outbound communication is
open by default. So you do not need to 'open ports' for output.</para>
<para>For input:</para>
@ -877,7 +877,7 @@ to debug/develop the newnat interface.</programlisting></para>
<para><emphasis role="bold">Answer:</emphasis> The default Shorewall
setup invokes the <emphasis role="bold">Drop</emphasis> action prior to
enforcing a DROP policy and the default policy to all zones from the
internet is DROP. The Drop action is defined in
Internet is DROP. The Drop action is defined in
<filename>/usr/share/shorewall/action.Drop</filename> which in turn
invokes the <emphasis role="bold">Auth</emphasis> macro (defined in
<filename>/usr/share/shorewall/macro.Auth</filename>) specifying the
@ -916,7 +916,7 @@ to debug/develop the newnat interface.</programlisting></para>
establishment of new connections. Once a connection is established
through the firewall it will be usable until disconnected (tcp) or
until it times out (other protocols). If you stop telnet and try to
establish a new session your firerwall will block that attempt.</para>
establish a new session your firewall will block that attempt.</para>
</section>
<section id="faq4c">
@ -973,7 +973,7 @@ to debug/develop the newnat interface.</programlisting></para>
<para>The DNS settings on the local systems are wrong or the user is
running a DNS server on the firewall and hasn't enabled UDP and TCP
port 53 from the local net to the firewall or from the firewall to
the internet.</para>
the Internet.</para>
</listitem>
<listitem>
@ -1042,7 +1042,7 @@ to debug/develop the newnat interface.</programlisting></para>
may no longer be defined in terms of bridge ports. See <ulink
url="bridge-Shorewall-perl.html">the new Shorewall-shell bridging
documentation</ulink> for information about configuring a
bridge/firewall under kernel 2.6.20 and later with Shoreawall shell or
bridge/firewall under kernel 2.6.20 and later with Shorewall shell or
the<ulink url="bridge-Shorewall-perl.html"> Shorewall-perl bridging
documentation</ulink> if you use Shorewall-perl
(highly-recommended).<note>
@ -1167,7 +1167,7 @@ DROP net fw udp 10619</programlisting>
</listitem>
<listitem>
<para>the ethernet frame type (2 bytes)</para>
<para>the Ethernet frame type (2 bytes)</para>
</listitem>
</itemizedlist>
@ -1216,7 +1216,7 @@ teastep@ursa:~$ </programlisting>The first number determines the maximum log
<emphasis role="bold">less than</emphasis> this number are sent to the
console. On the system shown in the example above, priorities 0-5 are
sent to the console. Since Shorewall defaults to using 'info' (6), the
Shorewall-generated Netfilter ruleset will generate log messages that
Shorewall-generated Netfilter rule set will generate log messages that
<emphasis role="bold">will not appear on the console.</emphasis></para>
<para>The second number is the default log level for kernel printk()
@ -1252,7 +1252,7 @@ teastep@ursa:~$ </programlisting>The first number determines the maximum log
messages or the content of the messages.</para>
<para>The actual log file where Netfilter messages are written is not
standardized and will vary by distribution and distribusion version.
standardized and will vary by distribution and distribution version.
But anytime you see no logging, it's time to look outside the
Shorewall configuration for the cause. As an example, recent
<trademark>SuSE</trademark> releases use syslog-ng by default and
@ -1376,7 +1376,7 @@ teastep@ursa:~$ </programlisting>The first number determines the maximum log
</varlistentry>
<varlistentry>
<term>blacklst</term>
<term>blacklist</term>
<listitem>
<para>The packet is being logged because the source IP is
@ -1634,7 +1634,7 @@ modprobe: Can't locate module iptable_raw</programlisting>
<title>Routing</title>
<section id="faq32">
<title>(FAQ 32) My firewall has two connections to the internet from two
<title>(FAQ 32) My firewall has two connections to the Internet from two
different ISPs. How do I set this up in Shorewall?</title>
<para><emphasis role="bold">Answer</emphasis>: See <ulink
@ -1933,7 +1933,7 @@ iptables: Invalid argument
of the control of the packaging system and provides consistent behavior
between the init scripts and <filename>/sbin/shorewall</filename> (and
<filename>/sbin/shorewall-lite</filename>). For more information on the
tradeoffs involved when deciding whether to use the Debian package, see
factors involved when deciding whether to use the Debian package, see
<ulink url="http://wiki.shorewall.net/wiki/ShorewallOnDebian">this
article</ulink>.</para>
</section>
@ -2004,7 +2004,7 @@ iptables: Invalid argument
<title>Traffic Shaping</title>
<section id="faq67">
<title>(FAQ 67) I just configured Shorewall's builtin traffic shaping
<title>(FAQ 67) I just configured Shorewall's built in traffic shaping
and now Shorewall fails to Start.</title>
<para>The error I receive is as follows:<programlisting>RTNETLINK answers: No such file or directory
@ -2086,7 +2086,7 @@ We have an error talking to the kernel
<section id="faq25a">
<title>(FAQ 25a) How do I tell which version of Shorewall-perl and
Shorewall-shell that I have intalled?</title>
Shorewall-shell that I have installed?</title>
<para><emphasis role="bold">Answer</emphasis>: At the shell prompt,
type:</para>
@ -2174,7 +2174,7 @@ We have an error talking to the kernel
<section id="faq14">
<title>(FAQ 14) I'm connected via a cable modem and it has an internal
web server that allows me to configure/monitor it but as expected if I
enable rfc1918 blocking for my eth0 interface (the internet one), it
enable rfc1918 blocking for my eth0 interface (the Internet one), it
also blocks the cable modems web server.</title>
<para>Is there any way it can add a rule before the rfc1918 blocking
@ -2217,7 +2217,7 @@ We have an error talking to the kernel
</section>
<section id="faq14b">
<title>(FAQ 14b) I connect to the internet with PPPoE. When I try to
<title>(FAQ 14b) I connect to the Internet with PPPoE. When I try to
access the built-in web server in my DSL Modem, I get connection
Refused.</title>
@ -2285,7 +2285,7 @@ eth0 eth1 # eth1 = interface to local netwo
<section id="faq18">
<title>(FAQ 18) Is there any way to use aliased ip addresses with
Shorewall, and maintain separate rulesets for different IPs?</title>
Shorewall, and maintain separate rule sets for different IPs?</title>
<para><emphasis role="bold">Answer:</emphasis> Yes. See <ulink
url="Shorewall_and_Aliased_Interfaces.html">Shorewall and Aliased
@ -2369,7 +2369,7 @@ eth0 eth1 # eth1 = interface to local netwo
<command>iptables-restore</command> to instantiate the Netfilter
configuration. So it runs much faster than the script generated by
the Shorewall-shell compiler and doesn't disable new connections
during ruleset installation.</para>
during rule set installation.</para>
</listitem>
<listitem>
@ -2432,7 +2432,7 @@ rmmod nf_conntrack_sip</programlisting>Then change the DONT_LOAD specification
<section id="faq20">
<title>(FAQ 20) I have just set up a server. Do I have to change
Shorewall to allow access to my server from the internet?</title>
Shorewall to allow access to my server from the Internet?</title>
<para><emphasis role="bold">Answer</emphasis>: Yes. Consult the <ulink
url="shorewall_quickstart_guide.htm">QuickStart guide</ulink> that you
@ -2441,8 +2441,8 @@ rmmod nf_conntrack_sip</programlisting>Then change the DONT_LOAD specification
</section>
<section id="faq24">
<title>(FAQ 24) How can I allow conections to let's say the ssh port
only from specific IP Addresses on the internet?</title>
<title>(FAQ 24) How can I allow connections to let's say the ssh port
only from specific IP Addresses on the Internet?</title>
<para><emphasis role="bold">Answer</emphasis>: In the SOURCE column of
the rule, follow <quote>net</quote> by a colon and a list of the
@ -2540,14 +2540,14 @@ REJECT fw net:pagead2.googlesyndication.com all</programlisting
headers at the front of each packet. Stateful packet filters (of which
Netfilter is an example) use a combination of header contents and state
created when the packet filter processed earlier packets. Netfilter (and
Shorewall's use of netfilter) also consider the network interface(s)
Shorewall's use of Netfilter) also consider the network interface(s)
where each packet entered and/or where the packet will leave the
firewall/router.</para>
<para>When you specify <ulink
url="configuration_file_basics.htm#dnsnames">a domain name in a
Shorewall rule</ulink>, the iptables program resolves that name to one
or more IP addresses and the actual netfilter rules that are created are
or more IP addresses and the actual Netfilter rules that are created are
expressed in terms of those IP addresses. So the rule that you entered
was equivalent to:</para>

4
docs/FTP.xml
View File

@ -319,7 +319,7 @@ xt_tcpudp 3328 0
<example id="Example2">
<title>if you run an FTP server that listens on port 49 or you need to
access a server on the internet that listens on that port then you would
access a server on the Internet that listens on that port then you would
have:</title>
<programlisting>loadmodule nf_conntrack_ftp ports=21,49
@ -414,7 +414,7 @@ FTP/ACCEPT dmz net</programlisting>
<para>Note that the FTP connection tracking in the kernel cannot handle
cases where a PORT command (or PASV reply) is broken across two packets or
is misssing the ending &lt;cr&gt;/&lt;lf&gt;. When such cases occur, you
is missing the ending &lt;cr&gt;/&lt;lf&gt;. When such cases occur, you
will see a console message similar to this one:</para>
<programlisting>Apr 28 23:55:09 gateway kernel: conntrack_ftp: partial PORT 715014972+1</programlisting>

2
docs/GenericTunnels.xml
View File

@ -54,7 +54,7 @@
<para>We want systems in the 192.168.1.0/24 subnetwork to be able to
communicate with the systems in the 10.0.0.0/8 network. This is
accomplished through use of the /etc/shorwall/tunnels file, the
accomplished through use of the /etc/shorewall/tunnels file, the
/etc/shorewall/policy file and the /etc/shorewall/tunnel script that is
included with Shorewall.</para>

2
docs/IPIP.xml
View File

@ -43,7 +43,7 @@
</articleinfo>
<warning>
<para>GRE and IPIP Tunnels are insecure when used over the internet; use
<para>GRE and IPIP Tunnels are insecure when used over the Internet; use
them at your own risk</para>
</warning>

4
docs/IPP2P.xml
View File

@ -48,9 +48,9 @@
<section id="Intro">
<title>Introduction</title>
<para>Shorewall verions 2.2.0 and later include support for the ipp2p
<para>Shorewall versions 2.2.0 and later include 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
match facility is included in Patch-O-Matic-ENG 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 but should rather be referred to the Netfilter

22
docs/IPSEC-2.6.xml
View File

@ -76,7 +76,7 @@
broken when used with a bridge device. The problem has been reported to
the responsible Netfilter developer who has confirmed the problem. The
problem was presumably corrected in Kernel 2.6.20 as a result of the
removal of defered FORWARD/OUTPUT processing of traffic destined for a
removal of deferred FORWARD/OUTPUT processing of traffic destined for a
bridge. See the <ulink
url="bridge-Shorewall-perl.html">"<emphasis>Shorewall-perl and Bridged
Firewalls</emphasis>"</ulink> article.</para>
@ -134,7 +134,7 @@
by normal rules and policies.</para>
<para>Under the 2.4 Linux Kernel, the association of unencrypted traffic
and zones was made easy by the presense of IPSEC pseudo-interfaces with
and zones was made easy by the presence of IPSEC pseudo-interfaces with
names of the form <filename class="devicefile">ipsecn</filename> (e.g.
<filename class="devicefile">ipsec0</filename>). Outgoing unencrypted
traffic (case 1.) was send through an <filename
@ -201,11 +201,11 @@
<note>
<para>For simple zones such as are shown in the following examples, the
two techniques are equivalent and are used interchangably.</para>
two techniques are equivalent and are used interchangeably.</para>
</note>
<note>
<para>It is redundent to have <emphasis role="bold">ipsec</emphasis> in
<para>It is redundant to have <emphasis role="bold">ipsec</emphasis> in
the TYPE column of the <filename>/etc/shorewall/zones</filename> entry
for a zone and to also have the <emphasis role="bold">ipsec</emphasis>
option in <filename>/etc/shorewall/hosts</filename> entries for that
@ -234,13 +234,13 @@
<section id="GwFw">
<title>IPSec Gateway on the Firewall System</title>
<para>Suppose that we have the following sutuation:</para>
<para>Suppose that we have the following situation:</para>
<graphic fileref="images/TwoNets1.png" />
<para>We want systems in the 192.168.1.0/24 sub-network to be able to
communicate with systems in the 10.0.0.0/8 network. We assume that on both
systems A and B, eth0 is the internet interface.</para>
systems A and B, eth0 is the Internet interface.</para>
<para>To make this work, we need to do two things:</para>
@ -301,7 +301,7 @@ net ipv4
</blockquote>
<para>Remember the assumption that both systems A and B have eth0 as their
internet interface.</para>
Internet interface.</para>
<para>You must define the vpn zone using the
<filename>/etc/shorewall/hosts</filename> file. The hosts file entries
@ -448,11 +448,11 @@ sainfo address 192.168.1.0/24 any address 134.28.54.2/32 any
}</programlisting>
<warning>
<para>If you have hosts that access the internet through an IPSEC
<para>If you have hosts that access the Internet through an IPSEC
tunnel, then it is a good idea to set the MSS value for traffic from
those hosts explicitly in the
<filename>/etc/shorewall/zones</filename> file. For example, if hosts
in the <emphasis role="bold">sec</emphasis> zone access the internet
in the <emphasis role="bold">sec</emphasis> zone access the Internet
through an ESP tunnel then the following entry would be
appropriate:</para>
@ -605,7 +605,7 @@ spdflush;</programlisting>
<para>On the mobile system (system B), it is not possible to create a
static IPSEC configuration because the IP address of the laptop's
internet connection isn't static. I have created an 'ipsecvpn' script
Internet connection isn't static. I have created an 'ipsecvpn' script
and included in the tarball and in the RPM's documentation directory;
this script can be used to start and stop the connection.</para>
@ -726,7 +726,7 @@ loc ipv4
<para>Since the L2TP will require the use of pppd, you will end up with
one or more ppp interfaces (each representing an individual road warrior
connection) for which you will need to account. This can be done by
modifying the inerfaces file. (Modify with additional options as
modifying the interfaces file. (Modify with additional options as
needed.)</para>
<blockquote>

12
docs/IPSEC.xml
View File

@ -105,13 +105,13 @@ conn packetdefault
<section id="GwFw">
<title>IPSec Gateway on the Firewall System</title>
<para>Suppose that we have the following sutuation:</para>
<para>Suppose that we have the following situation:</para>
<graphic fileref="images/TwoNets1.png" />
<para>We want systems in the 192.168.1.0/24 sub-network to be able to
communicate with systems in the 10.0.0.0/8 network. We assume that on both
systems A and B, eth0 is the internet interface.</para>
systems A and B, eth0 is the Internet interface.</para>
<para>To make this work, we need to do two things:</para>
@ -177,7 +177,7 @@ vpn ipsec0</programlisting>
<filename>/etc/shorewall/zones</filename>.</emphasis></para>
<para>Remember the assumption that both systems A and B have eth0 as
their internet interface.</para>
their Internet interface.</para>
<para>You must define the vpn zone using the /etc/shorewall/hosts
file.</para>
@ -193,7 +193,7 @@ vpn eth0:10.0.0.0/8</programlisting>
vpn eth0:192.168.1.0/24</programlisting>
<para>In addition, <emphasis role="bold">if you are using Masquerading
or SNAT</emphasis> on your firewalls, you need to elmiinate the remote
or SNAT</emphasis> on your firewalls, you need to eliminate the remote
network from Masquerade/SNAT. These entries <emphasis
role="bold">replace</emphasis> your current masquerade/SNAT entries for
the local networks.</para>
@ -229,7 +229,7 @@ vpn loc ACCEPT</programlisting>
<para>Shorewall can be used in a VPN Hub environment where multiple remote
networks are connected to a gateway running Shorewall. This environment is
shown in this diatram.</para>
shown in this diagram.</para>
<graphic fileref="images/ThreeNets.png" />
@ -425,7 +425,7 @@ ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3</programlisting>
Shorewall will issue warnings to that effect. These warnings may be safely
ignored. FreeS/Wan may now be configured to have three different Road
Warrior connections with the choice of connection being based on X-509
certificates or some other means. Each of these connectioins will utilize
certificates or some other means. Each of these connections will utilize
a different updown script that adds the remote station to the appropriate
zone when the connection comes up and that deletes the remote station when
the connection comes down. For example, when 134.28.54.2 connects for the

14
docs/Install.xml
View File

@ -38,7 +38,7 @@
<caution>
<para><emphasis role="bold">This article applies to Shorewall 3.0 and
later. If you are installing or upgradeing to a version of Shorewall
later. If you are installing or upgrading to a version of Shorewall
earlier than Shorewall 3.0.0 then please see the documentation for that
release.</emphasis></para>
</caution>
@ -490,12 +490,12 @@ tar -jxf shorewall-shell-4.0.0.tar.bz2</command> (if you use this compiler)</pro
<blockquote>
<para>It's *VERY* simple...just put in a new CD and reboot!  :-)
Actually, I'm only slightly kidding...that's exactly how I upgrade my
prodution firewalls.  The partial backup feature I added to Dachstein
allows configuration data to be stored seperately from the rest of the
production firewalls.  The partial backup feature I added to Dachstein
allows configuration data to be stored separately from the rest of the
package.</para>
<para>Once the config data is seperated from the rest of the package,
it's an easy matter to upgrade the pacakge while keeping your current
<para>Once the config data is separated from the rest of the package,
it's an easy matter to upgrade the package while keeping your current
configuration (in my case, just inserting a new CD and
re-booting).</para>
@ -521,7 +521,7 @@ tar -jxf shorewall-shell-4.0.0.tar.bz2</command> (if you use this compiler)</pro
<listitem>
<para>Make sure you have a working copy of your existing firewall
('OLD') in a safe place, that you *DO NOT* use durring this process.
('OLD') in a safe place, that you *DO NOT* use during this process.
That way, if anything goes wrong you can simply reboot off the OLD
disk to get back to a working configuration.</para>
</listitem>
@ -593,7 +593,7 @@ tar -xzvf /mnt/package2.lrp
&lt;package&gt;.list file that resides in /etc or /var/lib/lrpkg is
part of the configuration data and is used to create the partial
backup.  If shorewall puts anything in /etc that isn't a user modified
configuration file, a proper shorwall.local file should be created
configuration file, a proper shorewall.local file should be created
prior to making the partial backup [<emphasis role="bold">Editor's
note</emphasis>: Shorewall places only user-modifiable files in
/etc].</para>

22
docs/Introduction.xml
View File

@ -65,8 +65,8 @@
<listitem>
<para>iptables-restore - a program included with iptables that
allows for atomic installation of a set of Netfilter rules. This is
a much more efficient way to install a ruleset than running the
iptables utility once for each rule in the ruleset.</para>
a much more efficient way to install a rule set than running the
iptables utility once for each rule in the rule set.</para>
</listitem>
<listitem>
@ -269,17 +269,17 @@ loc net ACCEPT
net all DROP info
all all REJECT info</programlisting>In the three-interface
sample, the line below is included but commented out. If you want your
firewall system to have full access to servers on the internet, uncomment
firewall system to have full access to servers on the Internet, uncomment
that line. <programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
$FW net ACCEPT</programlisting> The above policy will:
<itemizedlist>
<listitem>
<para>Allow all connection requests from your local network to the
internet</para>
Internet</para>
</listitem>
<listitem>
<para>Drop (ignore) all connection requests from the internet to
<para>Drop (ignore) all connection requests from the Internet to
your firewall or local networks; these ignored connection requests
will be logged using the <emphasis>info</emphasis> syslog priority
(log level).</para>
@ -287,7 +287,7 @@ $FW net ACCEPT</programlisting> The above policy will:
<listitem>
<para>Optionally accept all connection requests from the firewall to
the internet (if you uncomment the additional policy)</para>
the Internet (if you uncomment the additional policy)</para>
</listitem>
<listitem>
@ -298,8 +298,8 @@ $FW net ACCEPT</programlisting> The above policy will:
</itemizedlist></para>
<para>To illustrate how rules provide exceptions to policies, suppose that
you have the polcies listed above but you want to be able to connect to
your firewall from the internet using Secure Shell (SSH). Recall that SSH
you have the polices listed above but you want to be able to connect to
your firewall from the Internet using Secure Shell (SSH). Recall that SSH
connects uses TCP port 22.</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST
@ -307,7 +307,7 @@ $FW net ACCEPT</programlisting> The above policy will:
ACCEPT net $FW tcp 22</programlisting>
<para>So although you have a policy of ignoring all connection attempts
from the net zone (from the internet), the above exception to that policy
from the net zone (from the Internet), the above exception to that policy
allows you to connect to the SSH server running on your firewall.</para>
<para>Because Shorewall makes no assumptions about what traffic you want
@ -317,7 +317,7 @@ ACCEPT net $FW tcp 22</programlisting>
<itemizedlist>
<listitem>
<para>The <ulink url="shorewall_quickstart_guide.htm">QuickStart
guildes</ulink> point to pre-populated files for use in common setups
guides</ulink> point to pre-populated files for use in common setups
and the <ulink url="shorewall_setup_guide.htm">Shorewall Setup
Guide</ulink> shows you examples for use with other more complex
setups.</para>
@ -377,7 +377,7 @@ ACCEPT net $FW tcp 22</programlisting>
highly portable to those Unix-like platforms that support Perl
(including Cygwin) and is the compiler of choice for new Shorewall
installations. Scripts created using Shorewall-perl use
iptables-restore to install the generated Netfilter ruleset.</para>
iptables-restore to install the generated Netfilter rule set.</para>
</listitem>
<listitem>

4
docs/KVM.xml
View File

@ -53,10 +53,10 @@
<graphic align="center" fileref="images/Network2008.png" />
<para>My personal laptop (Ursa) hosts the virtual machines. As shown in
the diagram, Ursa has routes to the internet through both the
the diagram, Ursa has routes to the Internet through both the
<trademark>Linksys</trademark> WRT300N and through my Shorewall firewall.
This allows me to test the <ulink url="MultiISP.html">Shorewall Multi-ISP
feature</ulink>, even though I only have a single internet
feature</ulink>, even though I only have a single Internet
connection</para>
<para>The Linux Bridges shown in the diagram are, of course, actually

6
docs/MAC_Validation.xml
View File

@ -41,7 +41,7 @@
<important>
<para><emphasis role="bold">MAC addresses are only visible within an
ethernet segment so all MAC addresses used in verification must belong to
Ethernet segment so all MAC addresses used in verification must belong to
devices physically connected to one of the LANs to which your firewall is
connected.</emphasis></para>
@ -175,7 +175,7 @@
<term>INTERFACE</term>
<listitem>
<para>The name of an ethernet interface on the Shorewall
<para>The name of an Ethernet interface on the Shorewall
system.</para>
</listitem>
</varlistentry>
@ -184,7 +184,7 @@
<term>MAC</term>
<listitem>
<para>The MAC address of a device on the ethernet segment connected
<para>The MAC address of a device on the Ethernet segment connected
by INTERFACE. It is not necessary to use the Shorewall MAC format in
this column although you may use that format if you so choose.
Beginning with Shorewall 3.1, you may specify "-" here if you enter

2
docs/Manpages.xml
View File

@ -105,7 +105,7 @@
<member><ulink
url="manpages/shorewall-providers.html">providers</ulink> - Define
routing tables, usually for mutliple internet links.</member>
routing tables, usually for multiple Internet links.</member>
<member><ulink url="manpages/shorewall-proxyarp.html">proxyarp</ulink>
- Define Proxy ARP.</member>

2
docs/Modularization.xml
View File

@ -90,7 +90,7 @@
<para>Optional libraries are loaded upon demand based on the user's
configuration.</para>
<para>In Shorewall 3.4, the optional librares are as follows.</para>
<para>In Shorewall 3.4, the optional libraries are as follows.</para>
<itemizedlist>
<listitem>

26
docs/MultiISP.xml
View File

@ -75,7 +75,7 @@
<title>Multiple Internet Connection Support</title>
<para>Beginning with Shorewall 2.3.2, limited support is included for
multiple internet connections. Limitations of this support are as
multiple Internet connections. Limitations of this support are as
follows:</para>
<itemizedlist>
@ -110,7 +110,7 @@
<title>Overview</title>
<para>Let's assume that a firewall is connected via two separate
ethernet interfaces to two different ISPs as in the following
Ethernet interfaces to two different ISPs as in the following
diagram.</para>
<graphic align="center" fileref="images/TwoISPs.png" valign="middle" />
@ -148,7 +148,7 @@
<para>When you use the <emphasis role="bold">track</emphasis> option in
<filename>/etc/shorewall/providers</filename>, connections from the
internet are automatically routed back out of the correct interface and
Internet are automatically routed back out of the correct interface and
through the correct ISP gateway. This works whether the connection is
handled by the firewall itself or if it is routed or port-forwarded to a
system behind the firewall.</para>
@ -304,7 +304,7 @@
be tracked so that responses may be routed back out this
same interface.</para>
<para>You want to specify 'track' if internet hosts will be
<para>You want to specify 'track' if Internet hosts will be
connecting to local servers through this provider. Any time
that you specify 'track', you will also want to specify
'balance' (see below).</para>
@ -338,7 +338,7 @@
<important>
<para>If you are using
<filename>/etc/shorewall/providers</filename> because you
have multiple internet connections, we recommend that you
have multiple Internet connections, we recommend that you
specify 'track' even if you don't need it. It helps
maintain long-term connections in which there are
significant periods with no traffic.</para>
@ -367,7 +367,7 @@
<important>
<para>If you are using
<filename>/etc/shorewall/providers</filename> because you
have multiple internet connections, we recommend that you
have multiple Internet connections, we recommend that you
specify 'balance' even if you don't need it. You can still
use entries in <filename>/etc/shorewall/tcrules</filename>
to force all traffic to one provider or another.<note>
@ -464,7 +464,7 @@
</varlistentry>
</variablelist>
<para>For those of you who are termnally confused between<emphasis
<para>For those of you who are terminally confused between<emphasis
role="bold"> track</emphasis> and <emphasis
role="bold">balance</emphasis>:</para>
@ -494,7 +494,7 @@
Shorewall copies all routes through the interface specified in the
INTERFACE column plus the interfaces listed in this column.
Normally, you will list all interfaces on your firewall in this
column except those internet interfaces specified in the INTERFACE
column except those Internet interfaces specified in the INTERFACE
column of entries in this file.</para>
</listitem>
</varlistentry>
@ -532,7 +532,7 @@
and any interfaces that do not have an IPv4 configuration. You should
also omit interfaces like <emphasis role="bold">tun</emphasis>
interfaces that are created dynamically. Traffic to networks handled by
those intefaces should be routed through the main table using entries in
those interfaces should be routed through the main table using entries in
<filename>/etc/shorewall/route_rules</filename> (see Example 2 <link
linkend="Examples">below</link>).</para>
@ -608,7 +608,7 @@
<title>Martians</title>
<para>One problem that often arises with Multi-ISP configuration is
'Martians'. If your internet interfaces are configured with the
'Martians'. If your Internet interfaces are configured with the
<emphasis role="bold">routefilter</emphasis> option in
<filename>/etc/shorewall/interfaces</filename> (remember that if you set
that option, you should also select <emphasis
@ -965,7 +965,7 @@ gateway:~ #</programlisting>Note that because we used a priority of 1000, the
OpenVPN (routed setup w/tunX) in combination with multiple providers.
In this case you have to set up a rule to ensure that the OpenVPN
traffic is routed back through the tunX interface(s) rather than
through any of the providers. 10.8.0.0/24 is the subnet choosen in
through any of the providers. 10.8.0.0/24 is the subnet chosen in
your OpenVPN configuration (server 10.8.0.0 255.255.255.0).</para>
<programlisting>#SOURCE DEST PROVIDER PRIORITY
@ -981,7 +981,7 @@ gateway:~ #</programlisting>Note that because we used a priority of 1000, the
<orderedlist numeration="loweralpha">
<listitem>
<para>Only ethernet (or ethernet-like) interfaces can be used. For
<para>Only Ethernet (or Ethernet-like) interfaces can be used. For
inbound traffic, the MAC addresses of the gateway routers are used
to determine which provider a packet was received through. Note that
only routed traffic can be categorized using this technique.</para>
@ -1129,4 +1129,4 @@ linksys 1 1 - wlan0 172.20.1.1 track,balance=1,optional
shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional</programlisting>/etc/shorewall/rules:<programlisting>#SOURCE DEST PROVIDER PRIORITY
- - shorewall 11999</programlisting></para>
</section>
</article>
</article>

10
docs/Multiple_Zones.xml
View File

@ -90,7 +90,7 @@
<listitem>
<para>The order of entries in /etc/shorewall/hosts is immaterial as
far as the generated ruleset is concerned.</para>
far as the generated rule set is concerned.</para>
</listitem>
</itemizedlist>
@ -125,7 +125,7 @@
<itemizedlist>
<listitem>
<para>The firewall requirements to/from the internet are the same
<para>The firewall requirements to/from the Internet are the same
for 192.168.1.0/24 and 192.168.2.0/24.</para>
</listitem>
@ -180,7 +180,7 @@
<title>Nested Zones</title>
<para>You can define one zone (called it <quote>loc</quote>) as being
all hosts connectied to eth1 and a second zone <quote>loc1</quote>
all hosts connected to eth1 and a second zone <quote>loc1</quote>
(192.168.2.0/24) as a sub-zone.</para>
<graphic fileref="images/MultiZone1A.png" />
@ -190,7 +190,7 @@
connection request doesn't match a <quote>loc1</quote> rule, it will
be matched against the <quote>loc</quote> rules. For example, if your
loc1-&gt;net policy is CONTINUE then if a connection request from loc1
to the internet doesn't match any rules for loc1-&gt;net then it will
to the Internet doesn't match any rules for loc1-&gt;net then it will
be checked against the loc-&gt;net rules.</para>
<para><filename>/etc/shorewall/zones</filename></para>
@ -302,7 +302,7 @@ loc1 loc NONE</programlisting>
<para>Nested zones may also be used to configure a
<quote>one-armed</quote> router (I don't call it a <quote>firewall</quote>
because it is very insecure. For example, if you connect to the internet
because it is very insecure. For example, if you connect to the Internet
via cable modem, your next door neighbor has full access to your local
systems as does everyone else connected to the same cable modem head-end
controller). Here eth0 is configured with both a public IP address and an