forked from extern/shorewall_code
More 3.0 Documentation Updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2598 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
988afa6bf5
commit
1a82d27d15
@ -411,8 +411,7 @@ NET_OPTIONS=blacklist,norfc1918</programlisting>
|
||||
|
||||
<listitem>
|
||||
<para>short name for the zone. The name should be 5 characters or
|
||||
less in length (4 characters or less if you are running Shorewall
|
||||
1.4.4 or later) and consist of lower-case letters or numbers. Short
|
||||
less in length and consist of lower-case letters or numbers. Short
|
||||
names must begin with a letter and the name assigned to the firewall
|
||||
is reserved for use by Shorewall itself. Note that the output
|
||||
produced by iptables is much easier to read if you select short
|
||||
@ -596,11 +595,11 @@ NET_OPTIONS=blacklist,norfc1918</programlisting>
|
||||
<para>respond to arp requests based on the value of
|
||||
<<emphasis>number</emphasis>>.</para>
|
||||
|
||||
<para> 1 - reply only if the target IP address is local
|
||||
address configured on the incoming interface</para>
|
||||
<para>1 - reply only if the target IP address is local address
|
||||
configured on the incoming interface</para>
|
||||
|
||||
<para> 2 - reply only if the target IP address is local
|
||||
address configured on the incoming interface and both with the
|
||||
<para>2 - reply only if the target IP address is local address
|
||||
configured on the incoming interface and both with the
|
||||
sender's IP address are part from same subnet on this
|
||||
interface</para>
|
||||
|
||||
@ -1056,13 +1055,6 @@ net eth0 detect dhcp,norfc1918
|
||||
|
||||
<para>Your /etc/shorewall/hosts file might look like:</para>
|
||||
|
||||
<programlisting>#ZONE HOST(S) OPTIONS
|
||||
loc eth1:192.168.1.0/24
|
||||
loc eth1:192.168.12.0/24</programlisting>
|
||||
|
||||
<para>If you are running Shorewall 1.4.6 or later, your hosts file may
|
||||
look like:</para>
|
||||
|
||||
<programlisting>#ZONE HOST(S) OPTIONS
|
||||
loc eth1:192.168.1.0/24,192.168.12.0/24</programlisting>
|
||||
</example>
|
||||
@ -2005,7 +1997,7 @@ ACCEPT<emphasis role="bold">:info</emphasis> - - tc
|
||||
<example>
|
||||
<title>You wish to forward all ssh connection requests from the internet
|
||||
to local system 192.168.1.3. You wish to limit the number of connections
|
||||
to 4/minute with a burst of 8 (Shorewall 1.4.7 and later only):</title>
|
||||
to 4/minute with a burst of 8:</title>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
DNAT<4/min:8> net loc:192.168.1.3 tcp ssh</programlisting>
|
||||
@ -2109,11 +2101,10 @@ ACCEPT net fw:206.124.146.176 tcp 22</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>(For advanced users running Shorewall version 1.3.13 or later).
|
||||
From the internet, you with to forward tcp port 25 directed to
|
||||
192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your DMZ. You also
|
||||
want to allow access from the internet directly to tcp port 25 on
|
||||
192.0.2.177.</title>
|
||||
<title>(For advanced users). From the internet, you with to forward tcp
|
||||
port 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in
|
||||
your DMZ. You also want to allow access from the internet directly to
|
||||
tcp port 25 on 192.0.2.177.</title>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
@ -2126,20 +2117,18 @@ ACCEPT net dmz:192.0.2.177 tcp 25</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>(Shorewall version 1.4.6 or later). You have 9 http servers
|
||||
behind a Shorewall firewall and you want connection requests to be
|
||||
distributed among your servers. The servers are
|
||||
192.168.1.101-192.168.1.109.</title>
|
||||
<title>You have 9 http servers behind a Shorewall firewall and you want
|
||||
connection requests to be distributed among your servers. The servers
|
||||
are 192.168.1.101-192.168.1.109.</title>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
DNAT net loc:192.168.1.101-192.168.1.109 tcp 80</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>(Shorewall 2.0.2 Beta 2 and Later). You want to redirect all
|
||||
local www connection requests EXCEPT those from 192.168.1.4 and
|
||||
192.168.1.199 to a Squid transparent proxy running on the firewall and
|
||||
listening on port 3128.</title>
|
||||
<title>You want to redirect all local www connection requests EXCEPT
|
||||
those from 192.168.1.4 and 192.168.1.199 to a Squid transparent proxy
|
||||
running on the firewall and listening on port 3128.</title>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||||
# PORT(S) DEST
|
||||
@ -2444,9 +2433,9 @@ eth0:0 192.168.12.0/24 206.124.146.177</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title> You want to use both 206.124.146.177 and 206.124.146.179 for
|
||||
SNAT of the subnet 192.168.12.0/24. Each address will be used on
|
||||
alternate outbound connections.</title>
|
||||
<title>You want to use both 206.124.146.177 and 206.124.146.179 for SNAT
|
||||
of the subnet 192.168.12.0/24. Each address will be used on alternate
|
||||
outbound connections.</title>
|
||||
|
||||
<programlisting>#INTERFACE SUBNET ADDRESS
|
||||
eth0 192.168.12.0/24 206.124.146.177,206.124.146.179</programlisting>
|
||||
@ -3074,8 +3063,7 @@ eth0 eth1 206.124.146.176</programlisting>
|
||||
under the <link linkend="rfc1918"><quote>norfc1918</quote>
|
||||
mechanism</link> are logged. The value must be a valid <ulink
|
||||
url="shorewall_logging.html">syslog level</ulink> and if no level is
|
||||
given, then info is assumed. Prior to Shorewall version 1.3.12,
|
||||
these packets are always logged at the info level.</para>
|
||||
given, then info is assumed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -3633,8 +3621,7 @@ LOGBURST=5</programlisting>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para><filename>/etc/shorewall/tos</filename> file that is included with
|
||||
Shorewall</para>
|
||||
<para>Here's a sample <filename>/etc/shorewall/tos</filename> file:</para>
|
||||
|
||||
<programlisting>#SOURCE DEST PROTOCOL SOURCE PORTS(S) DEST PORTS(S) TOS
|
||||
all all tcp - ssh 16
|
||||
|
@ -17,7 +17,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-08-24</pubdate>
|
||||
<pubdate>2005-08-30</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2005</year>
|
||||
@ -36,6 +36,13 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<caution>
|
||||
<para><emphasis role="bold">This article applies to Shorewall 3.0 and
|
||||
later. If you are running a version of Shorewall earlier than Shorewall
|
||||
3.0.0 then please see the documentation for that
|
||||
release.</emphasis></para>
|
||||
</caution>
|
||||
|
||||
<section>
|
||||
<title>Installing Shorewall</title>
|
||||
|
||||
@ -90,9 +97,9 @@
|
||||
message "warning: user teastep does not exist - using root"</title>
|
||||
|
||||
<para><emphasis role="bold">Answer:</emphasis> You may safely ignore
|
||||
this warning message. It was caused by a minor packaging error
|
||||
that has since been corrected. It makes no difference to
|
||||
Shorewall's operation.</para>
|
||||
this warning message. It was caused by a minor packaging error that has
|
||||
since been corrected. It makes no difference to Shorewall's
|
||||
operation.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@ -373,15 +380,9 @@ DNAT net fw:192.168.1.1:22 tcp 4104</programlisting>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>If you insist on a stupid IP solution to the accessibility problem
|
||||
rather than a more efficient DNS solution, then if you are running
|
||||
Shorewall 2.0.0 or 2.0.1 then please see the <ulink
|
||||
url="http://www.shorewall.net/1.4/FAQ.htm#faq2">Shorewall 1.4
|
||||
FAQ</ulink>.</para>
|
||||
|
||||
<para>Otherwise, assuming that your external interface is eth0 and your
|
||||
internal interface is eth1 and that eth1 has IP address 192.168.1.254
|
||||
with subnet 192.168.1.0/24, then:<warning>
|
||||
<para>Assuming that your external interface is eth0 and your internal
|
||||
interface is eth1 and that eth1 has IP address 192.168.1.254 with subnet
|
||||
192.168.1.0/24, then:<warning>
|
||||
<para>All traffic redirected through use of this hack will look to
|
||||
the server as if it came from the firewall (192.168.1.254) rather
|
||||
than from the original client!</para>
|
||||
@ -410,14 +411,9 @@ eth1:192.168.1.5 eth1 192.168.1.254 tcp www</programlist
|
||||
DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69</programlisting>
|
||||
|
||||
<para>That rule only works of course if you have a static external
|
||||
IP address. If you have a dynamic IP address and are running
|
||||
Shorewall 1.3.4 through Shorewall 2.0.* then include this in
|
||||
IP address. If you have a dynamic IP address then include this in
|
||||
<filename>/etc/shorewall/init</filename>:</para>
|
||||
|
||||
<programlisting><command>ETH0_IP=`find_interface_address eth0`</command> </programlisting>
|
||||
|
||||
<para>For users of Shorewall 2.1.0 and later:</para>
|
||||
|
||||
<programlisting><command>ETH0_IP=`find_first_interface_address eth0`</command> </programlisting>
|
||||
|
||||
<para>and make your DNAT rule:</para>
|
||||
@ -530,10 +526,6 @@ DNAT loc dmz:192.168.2.4 tcp 80 - 206
|
||||
|
||||
<para>In <filename>/etc/shorewall/init</filename>:</para>
|
||||
|
||||
<programlisting><command>ETH0_IP=`find_interface_address eth0`</command></programlisting>
|
||||
|
||||
<para>For users of Shorewall 2.1.0 and later:</para>
|
||||
|
||||
<programlisting><command>ETH0_IP=`find_first_interface_address eth0`</command> </programlisting>
|
||||
|
||||
<para>and make your DNAT rule:</para>
|
||||
@ -587,40 +579,10 @@ to debug/develop the newnat interface.</programlisting></para>
|
||||
and it shows some ports as <quote>closed</quote> rather than
|
||||
<quote>blocked</quote>. Why?</title>
|
||||
|
||||
<para><emphasis role="bold">Answer:</emphasis> (Shorewall versions prior
|
||||
to 2.0.0 only). The common.def included with version 1.3.x always
|
||||
rejects connection requests on TCP port 113 rather than dropping them.
|
||||
This is necessary to prevent outgoing connection problems to services
|
||||
that use the <quote>Auth</quote> mechanism for identifying requesting
|
||||
users. Shorewall also rejects TCP ports 135, 137, 139 and 445 as well as
|
||||
UDP ports 137-139. These are ports that are used by Windows (Windows
|
||||
<emphasis>can</emphasis> be configured to use the DCE cell locator on
|
||||
port 135). Rejecting these connection requests rather than dropping them
|
||||
cuts down slightly on the amount of Windows chatter on LAN segments
|
||||
connected to the Firewall.</para>
|
||||
|
||||
<para>If you are seeing port 80 being <quote>closed</quote>, that's
|
||||
probably your ISP preventing you from running a web server in violation
|
||||
of your Service Agreement.</para>
|
||||
|
||||
<tip>
|
||||
<para>You can change the default behavior of Shorewall through use of
|
||||
an /etc/shorewall/common file. See the <ulink
|
||||
url="shorewall_extension_scripts.htm">Extension Script
|
||||
Section</ulink>.</para>
|
||||
</tip>
|
||||
|
||||
<tip>
|
||||
<para>Beginning with Shorewall 1.4.9, Shorewall no longer rejects the
|
||||
Windows SMB ports (135-139 and 445) by default and silently drops them
|
||||
instead.</para>
|
||||
</tip>
|
||||
|
||||
<para><emphasis role="bold">Answer:</emphasis> (Shorewall versions 2.0.0
|
||||
and later). The default Shorewall setup invokes the <emphasis
|
||||
role="bold">Drop</emphasis> action prior to enforcing a DROP policy and
|
||||
the default policy to all zone from the internet is DROP. The Drop
|
||||
action is defined in
|
||||
<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 zone from the
|
||||
internet is DROP. The Drop action is defined in
|
||||
<filename>/usr/share/shorewall/action.Drop</filename> which in turn
|
||||
invokes the <emphasis role="bold">RejectAuth</emphasis> action (defined
|
||||
in <filename>/usr/share/shorewall/action.RejectAuth</filename>). This is
|
||||
@ -744,63 +706,6 @@ to debug/develop the newnat interface.</programlisting></para>
|
||||
url="SimpleBridge.html">Shorewall Simple Bridge
|
||||
documentation</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section id="faq40">
|
||||
<title>(FAQ 40) Shorewall is Blocking my OpenVPN Tunnel</title>
|
||||
|
||||
<para>I have this entry in <ulink
|
||||
url="Documentation.htm#Tunnels">/etc/shorewall/tunnels</ulink>:</para>
|
||||
|
||||
<programlisting># TYPE ZONE GATEWAY GATEWAY
|
||||
# ZONE
|
||||
openvpn:5000 net 69.145.71.133</programlisting>
|
||||
|
||||
<para>Yet I am seeing this log message:</para>
|
||||
|
||||
<programlisting>Oct 12 13:41:03 localhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT=
|
||||
MAC=00:04:5a:7f:92:9f:00:b0:c2:89:68:e4:08:00 SRC=69.145.71.133
|
||||
DST=216.187.138.18 LEN=42 TOS=0x00 PREC=0x00 TTL=46 ID=11 DF PROTO=UDP
|
||||
SPT=33120 DPT=5000 LEN=22</programlisting>
|
||||
|
||||
<para><emphasis role="bold">Answer</emphasis>: Shorewall's <emphasis
|
||||
role="bold">openvpn</emphasis> tunnel type assumes that OpenVPN will be
|
||||
using the same port (default 5000) for both the source and destination
|
||||
port. From the above message, it is clear that the remote client is
|
||||
using source port 33120. The solution is to replace your <ulink
|
||||
url="Documentation.htm#Tunnels">/etc/shorewall/tunnels</ulink> entry
|
||||
with this one:</para>
|
||||
|
||||
<programlisting># TYPE ZONE GATEWAY GATEWAY
|
||||
# ZONE
|
||||
generic:udp:5000 net 69.145.71.133</programlisting>
|
||||
</section>
|
||||
|
||||
<section id="faq47">
|
||||
<title>(FAQ 47) This Rule Doesn't Work as Documented</title>
|
||||
|
||||
<para>I want to allow access from the local zone to the net except for
|
||||
two systems (192.168.100.101 and 192.168.100.115). I use the following
|
||||
rule but find that 192.168.100.115 can still access the net. Is this a
|
||||
bug?</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO
|
||||
ACCEPT loc:!192.168.100.101,192.168.100.115 net</programlisting>
|
||||
|
||||
<para><emphasis role="bold">Answer</emphasis>: Shorewall is currently
|
||||
inconsistent as to where it correctly supports the "!" before a list of
|
||||
addresses. In some places, it works as you would expect and in other
|
||||
cases such as this one it does not. You will need to take a different
|
||||
approach to accomplish what you want. I recommend that you change your
|
||||
loc->net policy to ACCEPT and then use this rule:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO
|
||||
REJECT loc:192.168.100.101,192.168.100.115 net</programlisting>
|
||||
|
||||
<para><emphasis role="bold">Author's Note</emphasis>: I have looked
|
||||
several times at correcting this problem but it really isn't feasible
|
||||
until I muster the energy to rewrite the Shorewall rules parser.
|
||||
Sorry.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -831,9 +736,8 @@ REJECT loc:192.168.100.101,192.168.100.115 net</programlisting>
|
||||
<programlisting>LOGLIMIT=""
|
||||
LOGBURST=""</programlisting>
|
||||
|
||||
<para>Beginning with Shorewall version 1.3.12, you can <ulink
|
||||
url="shorewall_logging.html">set up Shorewall to log all of its messages
|
||||
to a separate file</ulink>.</para>
|
||||
<para>It is also possible to <ulink url="shorewall_logging.html">set up
|
||||
Shorewall to log all of its messages to a separate file</ulink>.</para>
|
||||
|
||||
<section id="faq6a">
|
||||
<title>(FAQ 6a) Are there any log parsers that work with
|
||||
@ -912,9 +816,7 @@ LOGBURST=""</programlisting>
|
||||
<title>(FAQ 16) Shorewall is writing log messages all over my console
|
||||
making it unusable!</title>
|
||||
|
||||
<para><emphasis role="bold">Answer:</emphasis> If you are running
|
||||
Shorewall version 1.4.4 or 1.4.4a then check the <ulink
|
||||
url="errata.htm">errata</ulink>. Otherwise:</para>
|
||||
<para><emphasis role="bold">Answer:</emphasis> </para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -1279,240 +1181,8 @@ LOGBURST=""</programlisting>
|
||||
<title>(FAQ 32) My firewall has two connections to the internet from two
|
||||
different ISPs. How do I set this up in Shorewall?</title>
|
||||
|
||||
<important>
|
||||
<para>Anyone with two Internet connections MUST read and understand
|
||||
<ulink url="Shorewall_and_Routing.html">this article on Shorewall and
|
||||
Routing</ulink>. If you don't, you will be completely lost trying to
|
||||
make this work. And <emphasis role="bold">that article should be all
|
||||
that you need if you are running Shorewall 2.3.2 or
|
||||
later</emphasis>.</para>
|
||||
</important>
|
||||
|
||||
<para>Setting this up in Shorewall is easy; setting up the routing is a
|
||||
bit harder.</para>
|
||||
|
||||
<para>Assuming that <filename class="devicefile">eth0</filename> and
|
||||
<filename class="devicefile">eth1</filename> are the interfaces to the
|
||||
two ISPs then:</para>
|
||||
|
||||
<para><filename>/etc/shorewall/interfaces</filename>:</para>
|
||||
|
||||
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||||
net eth0 detect
|
||||
net eth1 detect</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/policy</filename>:</para>
|
||||
|
||||
<programlisting>#SOURCE DESTINATION POLICY LIMIT:BURST
|
||||
net net DROP</programlisting>
|
||||
|
||||
<para>If you have masqueraded hosts, be sure to update
|
||||
<filename>/etc/shorewall/masq</filename> to masquerade to both ISPs. For
|
||||
example, if you masquerade all hosts connected to <filename
|
||||
class="devicefile">eth2</filename> then:</para>
|
||||
|
||||
<programlisting>#INTERFACE SUBNET ADDRESS
|
||||
eth0 eth2
|
||||
eth1 eth2</programlisting>
|
||||
|
||||
<para>Again, if you are running Shorewall 2.3.2 or later, please see
|
||||
<ulink url="Shorewall_and_Routing.html">this article</ulink> for
|
||||
instructions for setting up the routing. Otherwise, follow the
|
||||
instructions that follow.</para>
|
||||
|
||||
<para>There was an article in SysAdmin covering the topic of setting up
|
||||
routing for this configuration. It may be found at <ulink
|
||||
url="http://www.samag.com/documents/s=1824/sam0201h/">http://www.samag.com/documents/s=1824/sam0201h/</ulink>.</para>
|
||||
|
||||
<para>Stephen Carville has put together a Shorewall-specific writeup
|
||||
that covers this subject at <ulink
|
||||
url="http://www.heronforge.net/redhat/node17.html">http://www.heronforge.net/redhat/node17.html</ulink>.</para>
|
||||
|
||||
<para><citetitle>The following information regarding setting up routing
|
||||
for this configuration is reproduced from the <ulink
|
||||
url="http://www.lartc.org">LARTC HOWTO</ulink> and has not been verified
|
||||
by the author. If you have questions or problems with the instructions
|
||||
given below, please post to the <ulink
|
||||
url="http://www.lartc.org/#mailinglist">LARTC mailing
|
||||
list</ulink>.</citetitle></para>
|
||||
|
||||
<sidebar>
|
||||
<para>A common configuration is the following, in which there are two
|
||||
providers that connect a local network (or even a single machine) to
|
||||
the big Internet.</para>
|
||||
|
||||
<programlisting> ________
|
||||
+------------+ /
|
||||
| | |
|
||||
+-------------+ Provider 1 +-------
|
||||
__ | | | /
|
||||
___/ \_ +------+-------+ +------------+ |
|
||||
_/ \__ | if1 | /
|
||||
/ \ | | |
|
||||
| Local network -----+ Linux router | | Internet
|
||||
\_ __/ | | |
|
||||
\__ __/ | if2 | \
|
||||
\___/ +------+-------+ +------------+ |
|
||||
| | | \
|
||||
+-------------+ Provider 2 +-------
|
||||
| | |
|
||||
+------------+ \________
|
||||
</programlisting>
|
||||
|
||||
<para>There are usually two questions given this setup.</para>
|
||||
|
||||
<para><emphasis role="bold">Split access</emphasis></para>
|
||||
|
||||
<para>The first is how to route answers to packets coming in over a
|
||||
particular provider, say Provider 1, back out again over that same
|
||||
provider.</para>
|
||||
|
||||
<para>Let us first set some symbolical names. Let <emphasis
|
||||
role="bold">$IF1</emphasis> be the name of the first interface (if1 in
|
||||
the picture above) and <emphasis role="bold">$IF2</emphasis> the name
|
||||
of the second interface. Then let <emphasis
|
||||
role="bold">$IP1</emphasis> be the IP address associated with
|
||||
<emphasis role="bold">$IF1</emphasis> and <emphasis
|
||||
role="bold">$IP2</emphasis> the IP address associated with <emphasis
|
||||
role="bold">$IF2</emphasis>. Next, let <emphasis
|
||||
role="bold">$P1</emphasis> be the IP address of the gateway at
|
||||
Provider 1, and <emphasis role="bold">$P2</emphasis> the IP address of
|
||||
the gateway at provider 2. Finally, let <emphasis
|
||||
role="bold">$P1_NET</emphasis> be the IP network <emphasis
|
||||
role="bold">$P1</emphasis> is in, and <emphasis
|
||||
role="bold">$P2_NET</emphasis> the IP network <emphasis
|
||||
role="bold">$P2</emphasis> is in.</para>
|
||||
|
||||
<para>One creates two additional routing tables, say <emphasis
|
||||
role="bold">T1</emphasis> and <emphasis role="bold">T2</emphasis>.
|
||||
These are added in /etc/iproute2/rt_tables. Then you set up routing in
|
||||
these tables as follows:</para>
|
||||
|
||||
<programlisting>ip route add $P1_NET dev $IF1 src $IP1 table T1
|
||||
ip route add default via $P1 table T1
|
||||
ip route add $P2_NET dev $IF2 src $IP2 table T2
|
||||
ip route add default via $P2 table T2</programlisting>
|
||||
|
||||
<para>Nothing spectacular, just build a route to the gateway and build
|
||||
a default route via that gateway, as you would do in the case of a
|
||||
single upstream provider, but put the routes in a separate table per
|
||||
provider. Note that the network route suffices, as it tells you how to
|
||||
find any host in that network, which includes the gateway, as
|
||||
specified above.</para>
|
||||
|
||||
<para>Next you set up the main routing table. It is a good idea to
|
||||
route things to the direct neighbour through the interface connected
|
||||
to that neighbour. Note the `src' arguments, they make sure the right
|
||||
outgoing IP address is chosen.</para>
|
||||
|
||||
<programlisting>ip route add $P1_NET dev $IF1 src $IP1
|
||||
ip route add $P2_NET dev $IF2 src $IP2</programlisting>
|
||||
|
||||
<para>Then, your preference for default route:</para>
|
||||
|
||||
<programlisting>ip route add default via $P1</programlisting>
|
||||
|
||||
<para>Next, you set up the routing rules. These actually choose what
|
||||
routing table to route with. You want to make sure that you route out
|
||||
a given interface if you already have the corresponding source
|
||||
address:</para>
|
||||
|
||||
<programlisting>ip rule add from $IP1 table T1
|
||||
ip rule add from $IP2 table T2</programlisting>
|
||||
|
||||
<para>This set of commands makes sure all answers to traffic coming in
|
||||
on a particular interface get answered from that interface.</para>
|
||||
|
||||
<note>
|
||||
<para>'If $P0_NET is the local network and $IF0 is its interface,
|
||||
the following additional entries are desirable:</para>
|
||||
|
||||
<programlisting format="linespecific">ip route add $P0_NET dev $IF0 table T1
|
||||
ip route add $P2_NET dev $IF2 table T1
|
||||
ip route add 127.0.0.0/8 dev lo table T1
|
||||
ip route add $P0_NET dev $IF0 table T2
|
||||
ip route add $P1_NET dev $IF1 table T2
|
||||
ip route add 127.0.0.0/8 dev lo table T2</programlisting>
|
||||
</note>
|
||||
|
||||
<para>Now, this is just the very basic setup. It will work for all
|
||||
processes running on the router itself, and for the local network, if
|
||||
it is masqueraded. If it is not, then you either have IP space from
|
||||
both providers or you are going to want to masquerade to one of the
|
||||
two providers. In both cases you will want to add rules selecting
|
||||
which provider to route out from based on the IP address of the
|
||||
machine in the local network.</para>
|
||||
|
||||
<para><emphasis role="bold">Load balancing</emphasis></para>
|
||||
|
||||
<para>The second question is how to balance traffic going out over the
|
||||
two providers. This is actually not hard if you already have set up
|
||||
split access as above.</para>
|
||||
|
||||
<para>Instead of choosing one of the two providers as your default
|
||||
route, you now set up the default route to be a multipath route. In
|
||||
the default kernel this will balance routes over the two providers. It
|
||||
is done as follows (once more building on the example in the section
|
||||
on split-access):</para>
|
||||
|
||||
<programlisting>ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
|
||||
nexthop via $P2 dev $IF2 weight 1</programlisting>
|
||||
|
||||
<para>This will balance the routes over both providers. The <emphasis
|
||||
role="bold">weight</emphasis> parameters can be tweaked to favor one
|
||||
provider over the other.</para>
|
||||
|
||||
<note>
|
||||
<para>balancing will not be perfect, as it is route based, and
|
||||
routes are cached. This means that routes to often-used sites will
|
||||
always be over the same provider.</para>
|
||||
</note>
|
||||
|
||||
<para>Furthermore, if you really want to do this, you probably also
|
||||
want to look at Julian Anastasov's patches at <ulink
|
||||
url="http://www.ssi.bg/%7Eja/#routes">http://www.ssi.bg/~ja/#routes</ulink>
|
||||
, Julian's route patch page. They will make things nicer to work
|
||||
with.</para>
|
||||
</sidebar>
|
||||
|
||||
<para>The following was contributed by Martin Brown and is an excerpt
|
||||
from <citetitle> <ulink
|
||||
url="http://www.docum.org/stef.coene/qos/faq/cache/44.html">http://www.docum.org/stef.coene/qos/faq/cache/44.html</ulink>
|
||||
</citetitle>.</para>
|
||||
|
||||
<sidebar>
|
||||
<para>There are two issues requiring different handling when dealing
|
||||
with multiple Internet providers on a given network. The below assumes
|
||||
that the host which has multiple Internet connections is a
|
||||
masquerading (or NATting) host and is at the chokepoint between the
|
||||
internal and external networks. For the use of multiple inbound
|
||||
connections to the same internal server (public IP A from ISP A and
|
||||
public IP B from ISP B both get redirected to the same internal
|
||||
server), the ideal solution involves using two private IP addresses on
|
||||
the internal server. This leads to an end-to-end uniqueness of public
|
||||
IP to private IP and can be easily accomplished by following the
|
||||
directions here:</para>
|
||||
|
||||
<para><ulink
|
||||
url="http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-inbound">
|
||||
<citetitle>http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-inbound</citetitle>
|
||||
</ulink></para>
|
||||
|
||||
<para>For the use of multiple outbound links to the Internet, there
|
||||
are a number of different techniques. The simplest is identified
|
||||
here:</para>
|
||||
|
||||
<para><citetitle> <ulink
|
||||
url="http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-outbound">http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-outbound</ulink>
|
||||
</citetitle></para>
|
||||
|
||||
<para>Better (and more robust) techniques are available after a kernel
|
||||
routing patch by Julian Anastasov. See the famous nano-howto.</para>
|
||||
|
||||
<para><citetitle> <ulink
|
||||
url="http://www.ssi.bg/~ja/">http://www.ssi.bg/~ja/</ulink>
|
||||
</citetitle></para>
|
||||
</sidebar>
|
||||
<para>Answer: See <ulink url="Shorewall_and_Routing.html">this article
|
||||
on Shorewall and Routing</ulink>. </para>
|
||||
</section>
|
||||
|
||||
<section id="faq49">
|
||||
@ -1664,8 +1334,8 @@ Creating input Chains...
|
||||
output to a file as in <command>shorewall restart >
|
||||
/dev/null</command>).</para>
|
||||
|
||||
<para>Beginning with Shorewall version 2.0.2 Beta 1, Shorewall supports
|
||||
a fast start capability. To use this capability:</para>
|
||||
<para>Shorewall also supports a fast start capability. To use this
|
||||
capability:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
@ -1712,66 +1382,6 @@ Creating input Chains...
|
||||
<command>shorewall save</command>. Otherwise at the next reboot, you
|
||||
will revert to the old configuration stored in
|
||||
<filename>/var/lib/shorewall/restore</filename>.</para>
|
||||
|
||||
<section id="faq34a">
|
||||
<title>(FAQ 34a) I get errors about a host or network not found when I
|
||||
run<filename>/var/lib/shorewall/restore</filename>. The
|
||||
<command>shorewall restore</command> and <command>shorewall -f
|
||||
start</command> commands gives the same result.</title>
|
||||
|
||||
<para>Answer: iptables 1.2.9 is broken with respect to iptables-save
|
||||
and the connection tracking match extension. You must patch your
|
||||
iptables using the patch available from the <ulink
|
||||
url="errata.htm">Shorewall errata page</ulink>.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="faq41">
|
||||
<title>(FAQ 41) Why do I get modprobe failure messages when I start
|
||||
Shorewall?</title>
|
||||
|
||||
<para>When I start shorewall I got the following errors.</para>
|
||||
|
||||
<programlisting>Oct 30 11:13:12 fwr modprobe: modprobe: Can't locate module ipt_conntrack
|
||||
Oct 30 11:13:17 fwr modprobe: modprobe: Can't locate module ipt_pkttype
|
||||
Oct 30 11:13:18 fwr modprobe: modprobe: Can't locate module ipt_pkttype
|
||||
Oct 30 11:13:57 fwr last message repeated 2 times
|
||||
Oct 30 11:14:06 fwr root: Shorewall Restarted</programlisting>
|
||||
|
||||
<para>The "shorewall status" output seems complying with my rules set.
|
||||
Should I worry ? and is there any way to get rid of these errors
|
||||
?</para>
|
||||
|
||||
<para><emphasis role="bold">Answer</emphasis>: You are seeing two
|
||||
different things:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The normal checking that Shorewall does when it starts.
|
||||
Shorewall tries to determine the the capabilities of your 'iptables'
|
||||
and kernel and then taylors the ruleset accordingly.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A problem in Shorewall 2.0.3a through 2.0.5 whereby Shorewall
|
||||
tried to use the <emphasis>pkttype match</emphasis> feature each
|
||||
time that it wanted to generate a rule involving broadcast or
|
||||
multicast packets.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>You can suppress the messages by aliasing the modules mentioned in
|
||||
the error messages to off in /etc/modules.conf. Just be sure to review
|
||||
these aliases each time that you do a kernel upgrade to be sure that you
|
||||
are not disabling a feature in your new kernel that you want to
|
||||
use.</para>
|
||||
|
||||
<programlisting>alias ipt_conntrack off
|
||||
alias ipt_pkttype off</programlisting>
|
||||
|
||||
<para>For users who don't have the pkttype match feature in their
|
||||
kernel, I also recommend upgrading to Shorewall 2.0.6 or later and then
|
||||
setting PKTTYPE=No in shorewall.conf.</para>
|
||||
</section>
|
||||
|
||||
<section id="faq43">
|
||||
@ -1940,18 +1550,6 @@ iptables: Invalid argument
|
||||
</variablelist>
|
||||
</section>
|
||||
|
||||
<section id="faq46">
|
||||
<title>(FAQ 46) Given that the Debian Stable Release includes Shorewall
|
||||
1.2.12, how can you not support that version?</title>
|
||||
|
||||
<para>The first release of Shorewall was in March of 2001. Shorewall
|
||||
1.2.12 was released in May of 2002. It is now the year 2005 and
|
||||
Shorewall 2.2 is available. Shorewall 1.2.12 is poorly documented and is
|
||||
missing many of the features that Shorewall users find essential today
|
||||
and it is silly to continue to run it simply because it is bundled with
|
||||
an ancient Debian release.</para>
|
||||
</section>
|
||||
|
||||
<section id="faq36">
|
||||
<title>(FAQ 36) Does Shorewall Work with the 2.6 Linux Kernel?</title>
|
||||
|
||||
@ -2153,21 +1751,6 @@ eth0 eth1 # eth1 = interface to local netwo
|
||||
<para>Edit /etc/shorewall/shorewall.conf and change
|
||||
<quote>NEWNOTSYN=No</quote> to <quote>NEWNOTSYN=Yes</quote> then restart
|
||||
Shorewall.</para>
|
||||
|
||||
<section id="faq26a">
|
||||
<title>(FAQ 26a) When I try to use the <quote>-O</quote> option of
|
||||
nmap from the firewall system, I get <quote>operation not
|
||||
permitted</quote>. How do I allow this option?</title>
|
||||
|
||||
<para>If you are running Shorewall 2.2.0 or later, set DROPINVALID=No
|
||||
in <ulink
|
||||
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.</para>
|
||||
|
||||
<para>Otherwise, add this command to your /etc/shorewall/start
|
||||
file:</para>
|
||||
|
||||
<programlisting><command>run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP</command> </programlisting>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="faq27">
|
||||
@ -2278,36 +1861,33 @@ REJECT fw net:216.239.39.99 all</programlisting>Given that
|
||||
<title>(FAQ 42) How can I tell which features my kernel and iptables
|
||||
support?</title>
|
||||
|
||||
<para>Answer: Users running Shorewall 2.2.4 or later can simply use the
|
||||
<command>shorewall show capabilities</command> command at a root
|
||||
prompt.</para>
|
||||
<para>Answer: Use the <command>shorewall show capabilities</command>
|
||||
command at a root prompt.</para>
|
||||
|
||||
<para>For those running older versions, at a root prompt, enter the
|
||||
command <command>shorewall check</command>. There is a section near the
|
||||
top of the resulting output that gives you a synopsis of your
|
||||
kernel/iptables capabilities.</para>
|
||||
|
||||
<programlisting>gateway:/etc/shorewall # shorewall check
|
||||
<programlisting>gateway:~# shorewall show capabilities
|
||||
Loading /usr/share/shorewall/functions...
|
||||
Processing /etc/shorewall/params ...
|
||||
Processing /etc/shorewall/shorewall.conf...
|
||||
Loading Modules...
|
||||
|
||||
Notice: The 'check' command is unsupported and problem
|
||||
reports complaining about errors that it didn't catch
|
||||
will not be accepted
|
||||
|
||||
Shorewall has detected the following iptables/netfilter capabilities:
|
||||
NAT: Available
|
||||
Packet Mangling: Available
|
||||
Multi-port Match: Available
|
||||
Extended Multi-port Match: Available
|
||||
Connection Tracking Match: Available
|
||||
Packet Type Match: Not available
|
||||
Packet Type Match: Available
|
||||
Policy Match: Available
|
||||
Physdev Match: Available
|
||||
IP range Match: Available
|
||||
Verifying Configuration...
|
||||
...</programlisting>
|
||||
Recent Match: Available
|
||||
Owner Match: Available
|
||||
Ipset Match: Available
|
||||
ROUTE Target: Available
|
||||
Extended MARK Target: Available
|
||||
CONNMARK Target: Available
|
||||
Connmark Match: Available
|
||||
Raw Table: Available
|
||||
gateway:~#</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
</article>
|
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-08-20</pubdate>
|
||||
<pubdate>2005-08-30</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
@ -36,6 +36,13 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<caution>
|
||||
<para><emphasis role="bold">This article applies to Shorewall 3.0 and
|
||||
later. If you are running a version of Shorewall earlier than Shorewall
|
||||
3.0.0 then please see the documentation for that
|
||||
release.</emphasis></para>
|
||||
</caution>
|
||||
|
||||
<important>
|
||||
<para>The information in this article is only applicable if you plan to
|
||||
have IPSEC end-points on the same system where Shorewall is used.</para>
|
||||
@ -43,12 +50,10 @@
|
||||
|
||||
<warning>
|
||||
<para>To use the features described in this article, your kernel and
|
||||
iptables must include the Netfilter+ipsec patches and policy match support
|
||||
and you must be running Shorewall 2.1.5 or later (with Shorewall 2.2.0
|
||||
Beta 1 or later recommended). The Netfilter patches are available from
|
||||
Netfilter Patch-O-Matic-NG and are also included in some commercial
|
||||
distributions (most notably <trademark>SuSE</trademark> 9.1 and
|
||||
9.2).</para>
|
||||
iptables must include the Netfilter+ipsec patches and policy match
|
||||
support. The Netfilter patches are available from Netfilter
|
||||
Patch-O-Matic-NG and are also included in some commercial distributions
|
||||
(most notably <trademark>SuSE</trademark> 9.1 through 9.3).</para>
|
||||
</warning>
|
||||
|
||||
<important>
|
||||
@ -106,7 +111,7 @@
|
||||
</warning>
|
||||
|
||||
<section>
|
||||
<title>Shorewall 2.2 and Kernel 2.6 IPSEC</title>
|
||||
<title>Shorewall 3.0 and Kernel 2.6 IPSEC</title>
|
||||
|
||||
<para>This is <emphasis role="bold">not</emphasis> a HOWTO for Kernel 2.6
|
||||
IPSEC -- for that, please see <ulink
|
||||
@ -181,8 +186,8 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A <filename>new </filename><ulink
|
||||
url="Documentation.htm#Ipsec"><filename>/etc/shorewall/ipsec</filename></ulink>
|
||||
<para>The<filename> </filename><ulink
|
||||
url="Documentation.htm#Zones"><filename>/etc/shorewall/zones</filename></ulink>
|
||||
file allows you to associate zones with traffic that will be encrypted
|
||||
or that has been decrypted.</para>
|
||||
</listitem>
|
||||
@ -195,9 +200,8 @@
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>In summary, Shorewall 2.1.5 and later versions provide the
|
||||
facilities to replace the use of ipsec pseudo-interfaces in zone and
|
||||
MASQUERADE/SNAT definition.</para>
|
||||
<para>In summary, Shorewall provides the facilities to replace the use of
|
||||
ipsec pseudo-interfaces in zone and MASQUERADE/SNAT definition.</para>
|
||||
|
||||
<para>There are two cases to consider:</para>
|
||||
|
||||
@ -250,7 +254,9 @@
|
||||
|
||||
<para>For more information on IPSEC, Kernel 2.6 and Shorewall see <ulink
|
||||
url="LinuxFest.pdf">my presentation on the subject given at LinuxFest NW
|
||||
2005</ulink>.</para>
|
||||
2005</ulink>. Be warned though that the presentation is based on Shorewall
|
||||
2.2 and there are some differences in the details of how IPSEC is
|
||||
configured.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -313,18 +319,13 @@ ipsec net 206.162.148.9
|
||||
<para><filename>/etc/shorewall/zones</filename> — Systems A and
|
||||
B:</para>
|
||||
|
||||
<programlisting>#ZONE DISPLAY COMMENTS
|
||||
<programlisting>#ZONE IPSEC OPTIONS IN OUT
|
||||
# ONLY OPTIONS OPTIONS#ZONE DISPLAY COMMENTS
|
||||
vpn VPN Virtual Private Network
|
||||
net Internet The big bad internet
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<important>
|
||||
<para>Note that the <quote>vpn</quote> zone is defined before the
|
||||
<quote>net</quote> zone. This is necessary if you are using a Shorewall
|
||||
version earlier than 2.1.11.</para>
|
||||
</important>
|
||||
|
||||
<para>Remember the assumption that both systems A and B have eth0 as their
|
||||
internet interface.</para>
|
||||
|
||||
@ -466,7 +467,7 @@ sainfo address 192.168.1.0/24 any address 134.28.54.2/32 any
|
||||
<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/ipsec</filename> file. For example, if hosts
|
||||
<filename>/etc/shorewall/zones</filename> file. For example, if hosts
|
||||
in the <emphasis role="bold">sec</emphasis> zone access the internet
|
||||
through an ESP tunnel then the following entry would be
|
||||
appropriate:</para>
|
||||
@ -507,12 +508,6 @@ vpn VPN Road Warriors
|
||||
net Internet The big bad internet
|
||||
loc local Local Network (192.168.1.0/24)
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
|
||||
|
||||
<important>
|
||||
<para>Note that the <quote>vpn</quote> zone is defined before the
|
||||
<quote>net</quote> zone. This is necessary if you are using a
|
||||
Shorewall version earlier than 2.1.11.</para>
|
||||
</important>
|
||||
</blockquote>
|
||||
|
||||
<para>In this instance, the mobile system (B) has IP address 134.28.54.2
|
||||
@ -748,19 +743,6 @@ spdadd 192.168.20.40/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.
|
||||
<para>Shorewall configuration goes as follows:</para>
|
||||
|
||||
<blockquote>
|
||||
<para><filename>/etc/shorewall/zones</filename>:</para>
|
||||
|
||||
<programlisting>#ZONE DISPLAY COMMENTS
|
||||
net Net Internet
|
||||
loc Local Local Network
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
|
||||
|
||||
<important>
|
||||
<para>Note that the <quote>vpn</quote> zone is defined before the
|
||||
<quote>net</quote> zone. This is advised if you are using a Shorewall
|
||||
version earlier than 2.1.11.</para>
|
||||
</important>
|
||||
|
||||
<para><filename>/etc/shorewall/interfaces</filename>:</para>
|
||||
|
||||
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||||
@ -773,11 +755,12 @@ net eth0 detect routefilter,dhcp,tcpflags
|
||||
# ZONE
|
||||
ipsec:noah net 192.168.20.0/24 loc</programlisting>
|
||||
|
||||
<para>/etc/shorewall/ipsec:</para>
|
||||
<para>/etc/shorewall/zones:</para>
|
||||
|
||||
<programlisting>#ZONE IPSEC OPTIONS IN OUT
|
||||
# ONLY OPTIONS OPTIONS
|
||||
loc Yes mode=transport</programlisting>
|
||||
loc Yes mode=transport
|
||||
net</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/hosts</filename>:</para>
|
||||
|
||||
|
@ -36,6 +36,13 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<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
|
||||
earlier than Shorewall 3.0.0 then please see the documentation for that
|
||||
release.</emphasis></para>
|
||||
</caution>
|
||||
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
@ -158,39 +165,11 @@
|
||||
|
||||
<listitem>
|
||||
<para>cd to the shorewall directory (the version is encoded in the
|
||||
directory name as in <quote>shorewall-1.1.10</quote>).</para>
|
||||
directory name as in <quote>shorewall-3.0.0</quote>).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you are running <ulink
|
||||
url="http://www.slackware.com">Slackware</ulink>, you need Shorewall
|
||||
2.0.2 RC1 or later. If you are installing a Shorewall version earlier
|
||||
than 2.0.3 Beta 1 then you must also edit the install.sh file and
|
||||
change the lines</para>
|
||||
|
||||
<programlisting>DEST="/etc/init.d"
|
||||
INIT="shorewall"</programlisting>
|
||||
|
||||
<para>to</para>
|
||||
|
||||
<programlisting>DEST="/etc/rc.d"
|
||||
INIT="rc.firewall"</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you are running Slackware and are installing Shorewall 2.0.3
|
||||
Beta 1 to Shorewall 2.2.3, then type:</para>
|
||||
|
||||
<programlisting><emphasis role="bold">DEST=/etc/rc.d INIT=rc.firewall ./install.sh</emphasis></programlisting>
|
||||
|
||||
<para>If you are running Slackware and are installing Shorewall 2.2.4
|
||||
or later, then type:</para>
|
||||
|
||||
<programlisting><command>./install.sh</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Otherwise, type:</para>
|
||||
<para>Type:</para>
|
||||
|
||||
<programlisting><command>./install.sh</command></programlisting>
|
||||
</listitem>
|
||||
@ -201,28 +180,11 @@ INIT="rc.firewall"</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Enable Startup:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Users running Shorewall 2.1.3 or later, edit
|
||||
<para>Enable Startup by editing
|
||||
<filename>/etc/shorewall/shorewall.conf</filename> and set
|
||||
STARTUP_ENABLED=Yes.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Users running Shorewall 2.1.2 or earlier and using the .deb
|
||||
should edit <filename>/etc/default/shorewall</filename> and set
|
||||
startup=1.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>All other users, remove the file
|
||||
<filename>/etc/shorewall/startup_disabled</filename></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Start the firewall by typing</para>
|
||||
|
||||
@ -273,9 +235,9 @@ INIT="rc.firewall"</programlisting>
|
||||
described <ulink
|
||||
url="http://idea.sec.dico.unimi.it/%7Elorenzo/index.html#Debian">here</ulink>.</para>
|
||||
|
||||
<para>Once you have completed configuring Shorewall, you can enable
|
||||
startup at boot time by setting startup=1 in
|
||||
<filename>/etc/default/shorewall</filename>.</para>
|
||||
<para><emphasis role="bold">Once you have completed configuring Shorewall,
|
||||
you can enable startup at boot time by setting startup=1 in
|
||||
<filename>/etc/default/shorewall</filename>.</emphasis></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -395,35 +357,7 @@ INIT="rc.firewall"</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you are running <ulink
|
||||
url="http://www.slackware.com">Slackware</ulink>, you should use
|
||||
Shorewall 2.0.2 RC1 or later. If you are installing a Shorewall
|
||||
version earlier than 2.0.3 Beta 1 then you must also edit the
|
||||
install.sh file and change the lines</para>
|
||||
|
||||
<programlisting>DEST="/etc/init.d"
|
||||
INIT="shorewall"</programlisting>
|
||||
|
||||
<para>to</para>
|
||||
|
||||
<programlisting>DEST="/etc/rc.d"
|
||||
INIT="rc.firewall"</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you are running Slackware and are installing Shorewall 2.0.3
|
||||
Beta 1 through Shorewall 2.2.3, then type:</para>
|
||||
|
||||
<programlisting><emphasis role="bold">DEST=/etc/rc.d INIT=rc.firewall ./install.sh</emphasis></programlisting>
|
||||
|
||||
<para>If you are running Slackware and are installing Shorewall 2.2.4
|
||||
or later, then type:</para>
|
||||
|
||||
<programlisting><command>./install.sh</command></programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Otherwise, type:</para>
|
||||
<para>Type:</para>
|
||||
|
||||
<programlisting><command>./install.sh</command></programlisting>
|
||||
</listitem>
|
||||
|
@ -13,7 +13,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2005-08-11</pubdate>
|
||||
<pubdate>2005-08-30</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003-2005</year>
|
||||
@ -35,7 +35,7 @@
|
||||
<section>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>The information in this document applies only to 2.x releases of
|
||||
<para>The information in this document applies only to 3.x releases of
|
||||
Shorewall.</para>
|
||||
|
||||
<section>
|
||||
@ -133,7 +133,9 @@ dmz Demilitarized Zone</programlisting>
|
||||
|
||||
<para>Shorewall also recognizes the firewall system as its own zone - by
|
||||
default, the firewall itself is known as <emphasis
|
||||
role="bold"><varname>fw</varname></emphasis>.</para>
|
||||
role="bold"><varname>fw</varname></emphasis> but that may be changed by
|
||||
setting the FW option in <ulink
|
||||
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.</para>
|
||||
|
||||
<para>Rules about what traffic to allow and what traffic to deny are
|
||||
expressed in terms of zones. <itemizedlist spacing="compact">
|
||||
|
Binary file not shown.
Binary file not shown.
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-05-23</pubdate>
|
||||
<pubdate>2005-08-30</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
@ -36,6 +36,12 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<caution>
|
||||
<para>This article applies to Shorewall 3.0 and later. If you are running
|
||||
a version of Shorewall earlier than Shorewall 3.0.0 then please see the
|
||||
documentation for that release.</para>
|
||||
</caution>
|
||||
|
||||
<section>
|
||||
<title>Operational Components</title>
|
||||
|
||||
@ -213,14 +219,11 @@
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Shorewall startup is disabled by default. Once you have
|
||||
configured your firewall, you can enable startup by removing the
|
||||
file <filename>/etc/shorewall/startup_disabled</filename>. Note:
|
||||
Users of the .deb package must edit
|
||||
<filename>/etc/default/shorewall</filename> and set
|
||||
<quote>startup=1</quote> while users who are running Shorewall
|
||||
2.1.3 or later must edit
|
||||
<filename>/etc/shorewall/shorewall.conf</filename> and set
|
||||
STARTUP_ENABLED=Yes.</para>
|
||||
configured your firewall, you can enable startup by editing
|
||||
<filename>/etc/shorewall/shorewall.conf</filename> and setting
|
||||
STARTUP_ENABLED=Yes.. Note: Users of the .deb package must also
|
||||
edit <filename>/etc/default/shorewall</filename> and set
|
||||
<quote>startup=1</quote>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -357,14 +360,6 @@
|
||||
Shorewall to check before looking in the directories listed in
|
||||
CONFIG_PATH.</para>
|
||||
|
||||
<para>Shorewall versions before Shorewall 2.2.0:</para>
|
||||
|
||||
<programlisting> <command>shorewall [ -c <configuration-directory> ] {start|restart|check}</command>
|
||||
<command>shorewall try <configuration-directory> [ <timeout> ]</command></programlisting>
|
||||
|
||||
<para>Shorewall versions 2.2.0 and later the -c option is
|
||||
deprecated:</para>
|
||||
|
||||
<programlisting> <command>shorewall {start|restart|check} <configuration-directory></command>
|
||||
<command>shorewall try <configuration-directory> [ <timeout> ]</command></programlisting>
|
||||
|
||||
@ -468,12 +463,6 @@
|
||||
<para>Adds an interface (and list of hosts if included) to a dynamic
|
||||
zone usually used with VPN's.</para>
|
||||
|
||||
<para>Note that there was no provision in the syntax for specifying
|
||||
a <ulink url="bridge.html">bridge</ulink> port prior to Shorewall
|
||||
versions 2.0.12 and 2.2.0 Beta 7 and that the "shorewall add"
|
||||
command was not supported for hosts connected to the firewall
|
||||
through a bridge port prior to those releases.</para>
|
||||
|
||||
<para>Example: <command>shorewall add ipsec0:192.0.2.24
|
||||
vpn1</command></para>
|
||||
|
||||
@ -497,32 +486,17 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>check (Shorewall versions prior to 2.2.0)</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -c <configuration-directory> ]
|
||||
check</command></para>
|
||||
|
||||
<para>Performs a cursory validation of the zones, interfaces, hosts,
|
||||
rules and policy files. Use this if you are unsure of any edits you
|
||||
have made to the shorewall configuration. See <link
|
||||
linkend="AltConfig">above</link> for a recommended way to make
|
||||
changes.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>check (Shorewall 2.2.0 and later)</term>
|
||||
<term>check</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [-q] check [
|
||||
<configuration-directory> ]</command></para>
|
||||
|
||||
<para>Performs a cursory validation of the zones, interfaces, hosts,
|
||||
rules and policy files. Use this if you are unsure of any edits you
|
||||
have made to the shorewall configuration. See <link
|
||||
linkend="AltConfig">above</link> for a recommended way to make
|
||||
changes.</para>
|
||||
rules, policy, masq, blacklist, proxyarp, nat and provider files.
|
||||
Use this if you are unsure of any edits you have made to the
|
||||
shorewall configuration. See <link linkend="AltConfig">above</link>
|
||||
for a recommended way to make changes.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -568,12 +542,6 @@
|
||||
<para>Deletes the specified interface (and host list if included)
|
||||
from the specified zone.</para>
|
||||
|
||||
<para>Note that there was no provision in the syntax for specifying
|
||||
a <ulink url="bridge.html">bridge</ulink> port prior to Shorewall
|
||||
versions 2.0.12 and 2.2.0 Beta 7 and that the "shorewall delete"
|
||||
command was not supported for hosts connected to the firewall
|
||||
through a bridge port prior to those releases.</para>
|
||||
|
||||
<para>Example:</para>
|
||||
|
||||
<para><command>shorewall delete ipsec0:192.0.2.24
|
||||
@ -595,6 +563,19 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>dump</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -x ] dump</command></para>
|
||||
|
||||
<para>Produce a verbose report about the firewall.</para>
|
||||
|
||||
<para>When -x is given, that option is also passed to iptables to
|
||||
display actual packet and byte counts.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>forget</term>
|
||||
|
||||
@ -679,22 +660,6 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>monitor</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [-x] monitor
|
||||
[<refresh_interval>]</command></para>
|
||||
|
||||
<para>Continuously display the firewall status, last 20 log entries
|
||||
and nat. When the log entry display changes, an audible alarm is
|
||||
sounded.</para>
|
||||
|
||||
<para>When -x is given, that option is also passed to iptables to
|
||||
display actual packet and byte counts.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>refresh</term>
|
||||
|
||||
@ -733,21 +698,7 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>restart (Prior to Shorewall version 2.2.0)</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -q ] [ -c <configuration-directory>
|
||||
] restart</command></para>
|
||||
|
||||
<para>Restart is similar to <command>shorewall stop</command>
|
||||
followed by <command>shorewall start</command>. Existing connections
|
||||
are maintained. If -q is specified, less detail is displayed making
|
||||
it easier to spot warnings</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>restart (Shorewall version 2.2.0 and later)</term>
|
||||
<term>restart</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -q ] restart
|
||||
@ -781,7 +732,7 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>safe-restart (Shorewall version 2.4.0 and later)</term>
|
||||
<term>safe-restart</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -q ] safe-restart [ <filename>
|
||||
@ -800,7 +751,7 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>safe-start (Shorewall version 2.4.0 and later)</term>
|
||||
<term>safe-start</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -q ] safe-start [ <filename>
|
||||
@ -853,9 +804,8 @@
|
||||
<para><command>shorewall show log</command> - display the last 20
|
||||
packet log entries.</para>
|
||||
|
||||
<para><command>shorewall show capabilities</command> - Added in
|
||||
Shorewall version 2.2.4 and displays your kernel/iptables
|
||||
capabilities</para>
|
||||
<para><command>shorewall show capabilities</command> - Displays your
|
||||
kernel/iptables capabilities</para>
|
||||
|
||||
<para><command>shorewall show connections</command> - displays the
|
||||
IP connections currently being tracked by the firewall.</para>
|
||||
@ -866,11 +816,8 @@
|
||||
<para><command>shorewall show tc</command> - displays information
|
||||
about the traffic control/shaping configuration.</para>
|
||||
|
||||
<para><command>shorewall show zones</command> — Added in Shorewall
|
||||
version 2.2.0 Beta 7. Enabled when Shorewall is [re]started with
|
||||
DYNAMIC_ZONES=Yes in <ulink
|
||||
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.
|
||||
Displays the composition of each zone.</para>
|
||||
<para><command>shorewall show zones</command> — Displays the
|
||||
composition of each zone.</para>
|
||||
|
||||
<para>When -x is given, that option is also passed to iptables to
|
||||
display actual packet and byte counts.</para>
|
||||
@ -878,25 +825,7 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>start (Shorewall versions prior to 2.2.0)</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -q ] [ -f ] [ -c
|
||||
<configuration-directory> ] start</command></para>
|
||||
|
||||
<para>Start shorewall. Existing connections through shorewall
|
||||
managed interfaces are untouched. New connections will be allowed
|
||||
only if they are allowed by the firewall rules or policies. If -q is
|
||||
specified, less detail is displayed making it easier to spot
|
||||
warnings If -f is specified, the saved configuration specified by
|
||||
the RESTOREFILE option in <ulink
|
||||
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>
|
||||
will be restored if that saved configuration exists</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>start (Shorewall 2.2.0 and later)</term>
|
||||
<term>start</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -q ] [ -f ] start [
|
||||
@ -935,12 +864,10 @@
|
||||
<term>status</term>
|
||||
|
||||
<listitem>
|
||||
<para><command>shorewall [ -x ] status</command></para>
|
||||
<para><command>shorewall status</command></para>
|
||||
|
||||
<para>Produce a verbose report about the firewall.</para>
|
||||
|
||||
<para>When -x is given, that option is also passed to iptables to
|
||||
display actual packet and byte counts.</para>
|
||||
<para>Produce a short report about the firewall's status and state
|
||||
relative to <link linkend="State">the diagram below</link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -1020,9 +947,8 @@
|
||||
<entry>firewall stop</entry>
|
||||
|
||||
<entry>Only traffic to/from hosts listed in /etc/shorewall/hosts
|
||||
is passed to/from/through the firewall. For Shorewall versions
|
||||
beginning with 1.4.7, if ADMINISABSENTMINDED=Yes in
|
||||
/etc/shorewall/shorewall.conf then in addition, all existing
|
||||
is passed to/from/through the firewall. If ADMINISABSENTMINDED=Yes
|
||||
in /etc/shorewall/shorewall.conf then in addition, all existing
|
||||
connections are retained and all connection requests from the
|
||||
firewall are accepted.</entry>
|
||||
</row>
|
||||
|
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-07-19</pubdate>
|
||||
<pubdate>2005-08-30</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2005</year>
|
||||
@ -41,6 +41,13 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<caution>
|
||||
<para><emphasis role="bold">This article applies to Shorewall 3.0 and
|
||||
later. If you are running a version of Shorewall earlier than Shorewall
|
||||
3.0.0 then please see the documentation for that
|
||||
release.</emphasis></para>
|
||||
</caution>
|
||||
|
||||
<section>
|
||||
<title>Before Reporting a Problem or Asking a Question</title>
|
||||
|
||||
@ -49,14 +56,14 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The two currently-supported Shorewall <ulink
|
||||
url="ReleaseModel.html">major releases</ulink> are 2.4 and 2.2.
|
||||
<para>The three currently-supported Shorewall <ulink
|
||||
url="ReleaseModel.html">major releases</ulink> are 3.0, 2.4 and 2.2.
|
||||
Because of the short time between the releases of 2.2.0 and 2.4.0,
|
||||
Shorewall 2.0 will be supported until 1 December 2005 or until the
|
||||
release of 2.6.0, whichever comes first.</para>
|
||||
Shorewall 2.2 will be supported until 1 December 2006 or until the
|
||||
release of 3.1.0, whichever comes first.</para>
|
||||
|
||||
<note>
|
||||
<para>Shorewall versions earlier than 2.0.0 are no longer supported;
|
||||
<para>Shorewall versions earlier than 2.2.0 are no longer supported;
|
||||
we will only answer your question if it deals with upgrading from
|
||||
these old releases to a current one.</para>
|
||||
</note>
|
||||
@ -134,32 +141,32 @@ gateway:~#</programlisting>
|
||||
the following command:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting><command>/sbin/shorewall show shorewall</command></programlisting>
|
||||
<programlisting><command>/sbin/shorewall status shorewall</command></programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>If Shorewall has started successfully, you will see output
|
||||
similar to this:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>Shorewall-2.2.3 Chain shorewall at gateway - Wed Apr 20 14:41:53 PDT 2005
|
||||
<programlisting>Shorewall-2.5.4 Status at gateway - Tue Aug 30 14:07:29 PDT 2005
|
||||
|
||||
Counters reset Sat Apr 16 17:35:06 PDT 2005
|
||||
|
||||
<emphasis role="bold">Chain shorewall (0 references)
|
||||
pkts bytes target prot opt in out source destination</emphasis></programlisting>
|
||||
Shorewall is running
|
||||
State:Started (Tue Aug 30 07:18:07 PDT 2005)</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>If Shorewall has not started properly, you will see output
|
||||
similar to this:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>Shorewall-2.2.3 Chain shorewall at gateway - Wed Apr 20 14:43:13 PDT 2005
|
||||
<programlisting>Shorewall-2.5.4 Status at gateway - Tue Aug 30 14:08:11 PDT 2005
|
||||
|
||||
Counters reset Sat Apr 16 17:35:06 PDT 2005
|
||||
|
||||
<emphasis role="bold">iptables: No chain/target/match by that name</emphasis>
|
||||
</programlisting>
|
||||
Shorewall is stopped
|
||||
State:Stopped (Tue Aug 30 14:08:11 PDT 2005)</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>The "State:" refers to the <ulink
|
||||
url="starting_and_stopping_shorewall.htm%23State">Shorewall State
|
||||
Diagram</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -182,7 +189,7 @@ Counters reset Sat Apr 16 17:35:06 PDT 2005
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><command>/sbin/shorewall status >
|
||||
<para><command>/sbin/shorewall dump >
|
||||
/tmp/status.txt</command></para>
|
||||
</listitem>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user