mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-27 01:53:27 +01:00
c5bb04dcb2
Signed-off-by: Tom Eastep <teastep@shorewall.net>
3348 lines
141 KiB
XML
3348 lines
141 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<article>
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Shorewall FAQs</title>
|
|
|
|
<authorgroup>
|
|
<corpauthor>Shorewall Community</corpauthor>
|
|
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2001-2016</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled <quote>
|
|
<ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink>
|
|
</quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<caution>
|
|
<para><emphasis role="bold">This article applies to Shorewall 4.4 and
|
|
later. If you are running a version of Shorewall earlier than Shorewall
|
|
4.4.0 then please see the documentation for that
|
|
release.</emphasis></para>
|
|
</caution>
|
|
|
|
<section id="Install">
|
|
<title>Installing Shorewall</title>
|
|
|
|
<section id="Howto">
|
|
<title>Where do I find Step by Step Installation and Configuration
|
|
Instructions?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Check out the <ulink
|
|
url="shorewall_quickstart_guide.htm">QuickStart Guides</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq92">
|
|
<title>(FAQ 92) There are lots of Shorewall packages; which one(s) do I
|
|
install?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: When first installing
|
|
Shorewall 4.4.0 or later, you must install the <emphasis
|
|
role="bold">shorewall</emphasis> package. If you want to configure an
|
|
IPv6 firewall, you must also install <emphasis
|
|
role="bold">shorewall6</emphasis>. Beginning with Shorewall 4.5, you
|
|
must first install the <emphasis role="bold">shorewall-core</emphasis>
|
|
package.</para>
|
|
|
|
<section id="faq92a">
|
|
<title>(FAQ 92a) Someone once told me to install shorewall-perl;
|
|
anything to that?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: That was good advice in
|
|
Shorewall 4.2 and earlier. In those releases, there were two packages
|
|
that provided the basic firewalling functionality: <emphasis
|
|
role="bold">shorewall-shell</emphasis> and <emphasis
|
|
role="bold">shorewall-perl</emphasis>. Beginning with Shorewall 4.4.0,
|
|
<emphasis role="bold">shorewall-shell</emphasis> is discontinued and
|
|
<emphasis role="bold">shorewall-perl</emphasis> is renamed <emphasis
|
|
role="bold">shorewall</emphasis>.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq37">
|
|
<title>(FAQ 37) I just installed Shorewall on Debian and the
|
|
/etc/shorewall directory is almost empty!!!</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis></para>
|
|
|
|
<important>
|
|
<para>Once you have installed the .deb package and before you attempt
|
|
to configure Shorewall, please heed the advice of Lorenzo Martignoni,
|
|
former Shorewall Debian Maintainer:</para>
|
|
|
|
<para><quote>For more information about Shorewall usage on Debian
|
|
system please look at /usr/share/doc/shorewall-common/README.Debian
|
|
provided by [the] shorewall-common Debian package.</quote></para>
|
|
</important>
|
|
|
|
<para>If you install using the .deb, you will find that your <filename
|
|
class="directory">/etc/shorewall</filename> directory is almost empty.
|
|
This is intentional. The released configuration file skeletons may be
|
|
found on your system in the directory <filename
|
|
class="directory">/usr/share/doc/shorewall-common/default-config</filename>.
|
|
Simply copy the files you need from that directory to <filename
|
|
class="directory">/etc/shorewall</filename> and modify the
|
|
copies.</para>
|
|
|
|
<section id="faq37a">
|
|
<title>(FAQ 37a) I just installed Shorewall on Debian and I can't find
|
|
the sample configurations.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Beginning with
|
|
Shorewall 4.4, the samples are in the shorewall package and are
|
|
installed in <filename
|
|
class="directory">/usr/share/doc/shorewall/examples/</filename>.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq14">
|
|
<title>(FAQ 14) I can't find the Shorewall 4.4 shorewall-common,
|
|
shorewall-shell and shorewall-perl packages? Where are they?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>:In Shorewall 4.4, the
|
|
<firstterm>shorewall-shell</firstterm> package was discontinued. The
|
|
<firstterm>shorewall-common</firstterm> and
|
|
<firstterm>shorewall-perl</firstterm> packages were combined to form a
|
|
single <firstterm>shorewall</firstterm> package. In Shorewall 4.5, the
|
|
<firstterm>shorewall-core</firstterm> package was added and all of the
|
|
other packages depend on shorewall-core.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Upgrading">
|
|
<title>Upgrading Shorewall</title>
|
|
|
|
<section id="faq66">
|
|
<title>(FAQ 66) I'm trying to upgrade to Shorewall 4.x; which of these
|
|
packages do I need to install?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Please see the <ulink
|
|
url="upgrade_issues.htm">upgrade issues.</ulink></para>
|
|
</section>
|
|
|
|
<section id="faq34">
|
|
<title>(FAQ 34) I am trying to upgrade to Shorewall 4.4 and I can't find
|
|
the shorewall-common, shorewall-shell and shorewall-perl packages? Where
|
|
are they?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>:In Shorewall 4.4, the
|
|
<firstterm>shorewall-shell</firstterm> package was discontinued. The
|
|
<firstterm>shorewall-common</firstterm> and
|
|
<firstterm>shorewall-perl</firstterm> packages were combined to form a
|
|
single <firstterm>shorewall</firstterm> package. For further
|
|
information, please see the <ulink url="upgrade_issues.htm">upgrade
|
|
issues.</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq34a">
|
|
<title>(FAQ 34a) I am trying to upgrade to Shorewall 4.4 and I'm getting
|
|
errors when I try to start Shorewall. Where can I find information about
|
|
these issues?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Please see the <ulink
|
|
url="upgrade_issues.htm">upgrade issues</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq34b">
|
|
<title>(FAQ 34b) I am trying to upgrade to Shorewall 4.4 and I'm seeing
|
|
warning messages when I try to start Shorewall. Where can I find
|
|
information about these issues?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Please see the <ulink
|
|
url="upgrade_issues.htm">upgrade issues.</ulink></para>
|
|
</section>
|
|
|
|
<section id="faq76">
|
|
<title>(FAQ 76) I just upgraded my Debian (Ubuntu, Kubuntu, ...) system
|
|
and now masquerading 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
|
|
allow the installer to replace their working
|
|
<filename>/etc/shorewall/shorewall.conf</filename> with one that has
|
|
default settings. Failure to forward traffic (such as during masqueraded
|
|
net access from a local network) usually means that <filename><ulink
|
|
url="manpages/shorewall.conf.html">/etc/shorewall/shorewall.conf</ulink></filename>
|
|
contains the Debian default setting IP_FORWARDING=Keep; it should be
|
|
IP_FORWARDING=On.</para>
|
|
|
|
<para><emphasis role="bold">Update</emphasis>: Beginning with Shorewall
|
|
4.4.21, there is a <emphasis role="bold">shorewall update</emphasis>
|
|
command that does a smart merge of your existing shorewall.conf and the
|
|
new one.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="PortForwarding">
|
|
<title>Port Forwarding (Port Redirection)</title>
|
|
|
|
<section id="faq1">
|
|
<title>(FAQ 1) I want to forward UDP port 7777 to my personal PC with IP
|
|
address 192.168.1.5. I've looked everywhere and can't find how to do
|
|
it.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> The format of a
|
|
port-forwarding rule <emphasis>from the net</emphasis> to a local system
|
|
is as follows:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
DNAT net loc:<emphasis>local-IP-address</emphasis>[:<emphasis>local-port</emphasis>] <emphasis>protocol</emphasis> <emphasis>port-number</emphasis></programlisting>
|
|
|
|
<para>So to forward UDP port 7777 to internal system 192.168.1.5, the
|
|
rule is:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
DNAT net loc:192.168.1.5 udp 7777</programlisting>
|
|
|
|
<para>If you want to forward requests directed to a particular address (
|
|
<emphasis>external-IP</emphasis> ) on your firewall to an internal
|
|
system:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
DNAT net loc:<emphasis>local-IP-address</emphasis>>[:<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
|
|
( <emphasis>address</emphasis> ):</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
DNAT net:<emphasis>address</emphasis> loc:<emphasis>local-IP-address</emphasis>[:<emphasis>local-port</emphasis>] <emphasis> protocol</emphasis> <emphasis>port-number</emphasis> -</programlisting>
|
|
|
|
<para>Finally, if you need to forward a range of ports, in the DEST PORT
|
|
column specify the range as
|
|
<emphasis>low-port:high-port</emphasis>.</para>
|
|
|
|
<important>
|
|
<para><emphasis role="bold">The above does not work for forwarding
|
|
from the local network. If you want to do that, see <link
|
|
linkend="faq2">FAQ 2</link>.</emphasis></para>
|
|
</important>
|
|
|
|
<section id="faq1a">
|
|
<title>(FAQ 1a) Okay -- I followed those instructions but it doesn't
|
|
work</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> That is usually the
|
|
result of one of four things:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>You are trying to test from inside your firewall (no, that
|
|
won't work -- see <xref linkend="faq2"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You have a more basic problem with your local system (the
|
|
one that you are trying to forward to) such as an incorrect
|
|
default gateway (it must be set to the IP address of your
|
|
firewall's internal interface; if that isn't possible for some
|
|
reason, see <link linkend="faq1f">FAQ 1f</link>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Your ISP is blocking that particular port inbound or, for
|
|
TCP, your ISP is dropping the outbound SYN,ACK response.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You are running Mandriva Linux prior to 10.0 final and have
|
|
configured Internet Connection Sharing. In that case, the name of
|
|
your local zone is 'masq' rather than 'loc' (change all instances
|
|
of 'loc' to 'masq' in your rules). You may want to consider
|
|
re-installing Shorewall in a configuration which matches the
|
|
Shorewall documentation. See the <ulink
|
|
url="two-interface.htm">two-interface QuickStart Guide</ulink> for
|
|
details.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section id="faq1b">
|
|
<title>(FAQ 1b) I'm still having problems with port forwarding</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> To further diagnose
|
|
this problem:</para>
|
|
|
|
<itemizedlist>
|
|
<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
|
|
counters.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Try to connect to the redirected port from an external
|
|
host.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>As root type <quote> <command>shorewall show nat</command>
|
|
</quote> ("<command>shorewall-lite show nat</command>", if you are
|
|
running Shorewall Lite).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Locate the appropriate DNAT rule. It will be in a chain
|
|
called <emphasis><source zone></emphasis>_dnat
|
|
(<quote>net_dnat</quote> in the above examples).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Is the packet count in the first column non-zero? If so, the
|
|
connection request is reaching the firewall and is being
|
|
redirected to the server. In this case, the problem is usually a
|
|
missing or incorrect default gateway setting on the local system
|
|
(the system you are trying to forward to -- its default gateway
|
|
must be the IP address of the firewall's interface to that system
|
|
unless you use the hack described in <link linkend="faq1f">FAQ
|
|
1f</link>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the packet count is zero:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>the connection request is not reaching your server
|
|
(possibly it is being blocked by your ISP); or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>you are trying to connect to a secondary IP address on
|
|
your firewall and your rule is only redirecting the primary IP
|
|
address (You need to specify the secondary IP address in the
|
|
<quote>ORIG. DEST.</quote> column in your DNAT rule);
|
|
or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>your DNAT rule doesn't match the connection request in
|
|
some other way. In that case, you may have to use a packet
|
|
sniffer such as tcpdump or Wireshark to further diagnose the
|
|
problem.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The traffic is entering your firewall on a different
|
|
interface (interfaces reversed in
|
|
<filename>/etc/shorewall/interfaces</filename>?).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the packet count is non-zero, check your log to see if
|
|
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 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
|
|
OUT=<dev> and DEST= <ip>from the REJECT/DROP log
|
|
message.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If everything seems to be correct according to these tests
|
|
but the connection doesn't work, it may be that your ISP is
|
|
blocking SYN,ACK responses. This technique allows your ISP to
|
|
detect when you are running a server (usually in violation of your
|
|
service agreement) and to stop connections to that server from
|
|
being established.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section id="faq1c">
|
|
<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>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis>In
|
|
/<filename>etc/shorewall/rules</filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
DNAT net loc:192.168.1.3:22 tcp 1022</programlisting>
|
|
</section>
|
|
|
|
<section id="faq1d">
|
|
<title>(FAQ 1d) I have a web server in my DMZ and I use port
|
|
forwarding to make that server accessible from the Internet. That
|
|
works fine but when my local users try to connect to the server using
|
|
the Firewall's external IP address, it doesn't work.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> See <link
|
|
linkend="faq2b">FAQ 2b</link>.</para>
|
|
</section>
|
|
|
|
<section id="faq1e">
|
|
<title>(FAQ 1e) In order to discourage brute force attacks I would
|
|
like to redirect all connections on a non-standard port (4104) to port
|
|
22 on the router/firewall. I notice that setting up a REDIRECT rule
|
|
causes the firewall to open both ports 4104 and 22 to connections from
|
|
the net. Is it possible to only redirect 4104 to the localhost port 22
|
|
and have connection attempts to port 22 from the net dropped?</title>
|
|
|
|
<para><emphasis role="bold">Answer </emphasis>courtesy of Ryan: Assume
|
|
that the IP address of your local firewall interface is 192.168.1.1.
|
|
If you configure SSHD to only listen on that address and add the
|
|
following rule, then you will have access on port 4104 from the net
|
|
and on port 22 from your LAN.</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
DNAT net fw:192.168.1.1:22 tcp 4104</programlisting>
|
|
</section>
|
|
|
|
<section id="faq1f">
|
|
<title>(FAQ 1f) Why must the server that I port forward to have it's
|
|
default gateway set to my Shorewall system's IP address?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Let's take an example.
|
|
Suppose that</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Your Shorewall firewall's external IP address is
|
|
206.124.146.176 (eth0) and its internal IP address is 192.168.1.1
|
|
(eth1).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You have another gateway router with external IP address
|
|
130.252.100.109 and internal IP address 192.168.1.254.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You have an FTP server behind both routers with IP address
|
|
192.168.1.4</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The FTP server's default gateway is through the second
|
|
router (192.168.1.254).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You have this rule on the Shorewall system:<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
DNAT net loc:192.168.1.4 tcp 21 - 206.124.146.176</programlisting></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Internet host 16.105.221.4 issues the command <command>ftp
|
|
206.124.146.176</command></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>This results in the following sequence of events:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>16.105.221.4 sends a TCP SYN packet to 206.124.146.176
|
|
specifying destination port 21.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The Shorewall box rewrites the destination IP address to
|
|
192.168.1.4 and forwards the packet.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The FTP server receives the packet and accepts the
|
|
connection, generating a SYN,ACK packet back to 16.105.221.4.
|
|
Because the server's default gateway is through the second router,
|
|
it sends the packet to that router.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>At this point, one of two things can happen. Either the second
|
|
router discards or rejects the packet; or, it rewrites the source IP
|
|
address to 130.252.100.109 and forwards the packet back to
|
|
16.105.221.4. Regardless of which happens, the connection is doomed.
|
|
Clearly if the packet is rejected or dropped, the connection will not
|
|
be successful. But even if the packet reaches 16.105.221.4, that host
|
|
will reject it since it's SOURCE IP address (130.252.100.109) doesn't
|
|
match the DESTINATION IP ADDRESS (206.124.146.176) of the original SYN
|
|
packet.</para>
|
|
|
|
<para>The best way to work around this problem is to change the
|
|
default gateway on the FTP server to the Shorewall system's internal
|
|
IP address (192.168.1.1). But if that isn't possible, you can work
|
|
around the problem with the following ugly hack in
|
|
<filename>/etc/shorewall/masq</filename>:<programlisting>#INTERFACE SOURCE ADDRESS PROTO PORT
|
|
eth1:192.168.1.4 0.0.0.0/0 192.168.1.1 tcp 21</programlisting></para>
|
|
|
|
<para>This rule has the undesirable side effect of making all FTP
|
|
connections from the net appear to the FTP server as if they
|
|
originated on the Shorewall system. But it will force the FTP server
|
|
to reply back through the Shorewall system who can then rewrite the
|
|
SOURCE IP address in the responses properly.</para>
|
|
</section>
|
|
|
|
<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
|
|
66.249.93.111</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> This requires a vile
|
|
hack similar to the one in <link linkend="faq2">FAQ 2</link>. Assuming
|
|
that your Internet zone is named <emphasis>net</emphasis> and connects
|
|
on interface <filename class="devicefile">eth0</filename>:</para>
|
|
|
|
<para>In <filename>/etc/shorewall/rules</filename>:<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
|
|
?SECTION ALL
|
|
?SECTION ESTABLISHED
|
|
?SECTION RELATED
|
|
?SECTION INVALID
|
|
?SECTION UNTRACKED
|
|
?SECTION NEW
|
|
|
|
DNAT net net:66.249.93.111:993 tcp 80 - 206.124.146.176</programlisting></para>
|
|
|
|
<para>In <filename>/etc/shorewall/interfaces</filename>, specify the
|
|
<emphasis role="bold">routeback</emphasis> option on
|
|
eth0:<programlisting>?FORMAT 2
|
|
#ZONE INTERFACE OPTIONS
|
|
net eth0 <emphasis role="bold">routeback</emphasis></programlisting></para>
|
|
|
|
<para><filename>/etc/shorewall/masq</filename>;<programlisting>#INTERFACE SOURCE ADDRESS PROTO PORT
|
|
eth0:66.249.93.111 0.0.0.0/0 206.124.146.176 tcp 993</programlisting></para>
|
|
|
|
<para>and in
|
|
<filename>/etc/shorewall/shorewall.conf</filename>:</para>
|
|
|
|
<programlisting>IP_FORWARDING=On</programlisting>
|
|
|
|
<para>Like the hack in FAQ 2, this one results in all forwarded
|
|
connections looking to the server (66.249.93.11) as if they originated
|
|
on your firewall (206.124.146.176).</para>
|
|
</section>
|
|
|
|
<section id="faq1h">
|
|
<title>(FAQ 1h) How do I set shorewall to allow ssh on port 9022 from
|
|
net? SSHD is listening on port 22.</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Use this rule.</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
REDIRECT net 22 tcp 9022</programlisting>
|
|
|
|
<para>Note that the above rule will also allow connections from the
|
|
net on TCP port 22. If you don't want that, see <link
|
|
linkend="faq1e">FAQ 1e</link>.</para>
|
|
</section>
|
|
|
|
<section id="faq1j">
|
|
<title>(FAQ 1j) Why doesn't this DNAT rule work?</title>
|
|
|
|
<para>I added this rule but I'm still seeing the log message
|
|
below</para>
|
|
|
|
<programlisting>RULE:
|
|
DNAT scnet:172.19.41.2 dmz0:10.199.198.145 udp 2055
|
|
|
|
LOG:
|
|
Sep 21 12:55:37 fw001 kernel: [10357687.114928] Shorewall:scnet2fw:DROP:IN=eth2 OUT=
|
|
MAC=00:26:33:dd:aa:05:00:24:f7:19:ce:44:08:00 SRC=172.19.41.2 DST=172.19.1.1 LEN=1492
|
|
TOS=0x00 PREC=0x00 TTL=63 ID=23035 PROTO=UDP SPT=6376 DPT=2055 LEN=1472</programlisting>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: There was already a
|
|
conntrack entry for the failing connection before you added the rule.
|
|
Install the <emphasis role="bold">conntrack</emphasis> utility program
|
|
and use it to delete the entry.</para>
|
|
|
|
<programlisting><command>conntrack -D -s 172.19.41.2 -d 172.19.1.1 -p udp -sport 6367 -dport 2055 </command></programlisting>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq30">
|
|
<title>(FAQ 30) I'm confused about when to use DNAT rules and when to
|
|
use ACCEPT rules.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> It would be a good idea
|
|
to review the <ulink url="shorewall_quickstart_guide.htm">QuickStart
|
|
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
|
|
network.<note>
|
|
<para>If you use both 1:1 NAT and SNAT/MASQUERADE, those connections
|
|
that are subject to 1:1 NAT should use ACCEPT rather than DNAT.
|
|
Note, however, that DNAT can be used to override 1:1 NAT so as to
|
|
redirect a connection to a different internal system or port than
|
|
would be the case using 1:1 NAT.</para>
|
|
</note> 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
|
|
your firewall and handle them on the firewall box itself; in that case,
|
|
you use a REDIRECT rule.</para>
|
|
|
|
<note>
|
|
<para>The preceding answer should <emphasis>not</emphasis> be
|
|
interpreted to mean that DNAT can only be used in conjunction with
|
|
SNAT. But in common configurations using private local addresses, that
|
|
is the most common usage.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="faq8">
|
|
<title>(FAQ 8) I have several external IP addresses and use
|
|
/etc/shorewall/nat to associate them with systems in my DMZ. When I add
|
|
a DNAT rule, say for ports 80 and 443, Shorewall redirects connections
|
|
on those ports for all of my addresses. How can I restrict DNAT to only
|
|
a single address?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Specify the external
|
|
address that you want to redirect in the ORIGDEST column.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
DNAT net net:192.168.4.22 tcp 80,443 - <emphasis
|
|
role="bold">206.124.146.178</emphasis></programlisting>
|
|
</section>
|
|
|
|
<section id="faq38">
|
|
<title>(FAQ 38) Where can I find more information about DNAT?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Ian Allen has written a
|
|
<ulink url="http://idallen.com/dnat.txt">Paper about DNAT and
|
|
Linux</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq48">
|
|
<title>(FAQ 48) How do I Set up a Transparent HTTP Proxy with
|
|
Shorewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> See <ulink
|
|
url="Shorewall_Squid_Usage.html">Shorewall_Squid_Usage.html</ulink>.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="DNS-DNAT">
|
|
<title id="DNS">DNS and Port Forwarding/NAT</title>
|
|
|
|
<section id="faq2">
|
|
<title>(FAQ 2) I port forward www requests to www.mydomain.com (IP
|
|
130.151.100.69) to system 192.168.1.5 in my local network. External
|
|
clients can browse http://www.mydomain.com but internal clients
|
|
can't.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> I have two objections to
|
|
this setup.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<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
|
|
cable, you can put your server in a DMZ such that it is isolated
|
|
from your local systems - assuming that the Server can be located
|
|
near the Firewall, of course :-)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The accessibility problem is best solved using
|
|
<firstterm>Split DNS</firstterm> (either <ulink
|
|
url="SplitDNS.html">use a separate DNS server</ulink> for local
|
|
clients or use <ulink url="shorewall_setup_guide.htm#DNS">Bind
|
|
Version 9 <quote>views</quote></ulink> on your main name server)
|
|
such that www.mydomain.com resolves to 130.141.100.69 externally and
|
|
192.168.1.5 internally. I use a separate DNS server (dnsmasq) here
|
|
at shorewall.net.</para>
|
|
</listitem>
|
|
</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
|
|
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
|
|
(separate server or Bind 9 views).</para>
|
|
|
|
<para>If physical limitations make it impractical to segregate your
|
|
servers on a separate LAN, the next best solution it to use Split DNS.
|
|
Before you complain "It's too hard to set up split DNS!", <ulink
|
|
url="SplitDNS.html"><emphasis role="bold">check
|
|
here</emphasis></ulink>.</para>
|
|
|
|
<para>If you really want to route traffic between two internal systems
|
|
through your firewall, then proceed as described below.<warning>
|
|
<para>All traffic redirected through use of this technique will look
|
|
to the server as if it originated on the firewall rather than on the
|
|
original client! So the server's access logs will be useless for
|
|
determining which local hosts are accessing the server.</para>
|
|
</warning></para>
|
|
|
|
<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:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>In <filename>/etc/shorewall/interfaces</filename>:</para>
|
|
|
|
<programlisting>?FORMAT 2
|
|
#ZONE INTERFACE OPTIONS
|
|
loc eth1 <emphasis role="bold">routeback</emphasis></programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In <filename>/etc/shorewall/masq</filename>:</para>
|
|
|
|
<programlisting>#INTERFACE SOURCE ADDRESS PROTO PORT
|
|
<emphasis role="bold">eth1:192.168.1.5 192.168.1.0/24 192.168.1.254 tcp www</emphasis></programlisting>
|
|
|
|
<para>Note: The technique described here is known as
|
|
<firstterm>hairpinning NAT</firstterm> and is described in section 6
|
|
of <ulink url="http://www.faqs.org/rfcs/rfc4787.html">RFC
|
|
4787</ulink>. In that RFC, it is required that the
|
|
<emphasis>external IP address</emphasis> be used as the
|
|
source:</para>
|
|
|
|
<programlisting>#INTERFACE SOURCE ADDRESS PROTO PORT
|
|
eth1:192.168.1.5 192.168.1.0/24 <emphasis role="bold">130.151.100.69</emphasis> tcp www</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In <filename>/etc/shorewall/rules</filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
|
|
?SECTION ALL
|
|
?SECTION ESTABLISHED
|
|
?SECTION RELATED
|
|
?SECTION INVALID
|
|
?SECTION UNTRACKED
|
|
?SECTION NEW
|
|
|
|
<emphasis role="bold">DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69</emphasis></programlisting>
|
|
|
|
<para>That rule (and the second one in the previous bullet) only
|
|
works of course if you have a static external IP address. If you
|
|
have a dynamic IP address then include this in
|
|
<filename>/etc/shorewall/params</filename>.</para>
|
|
|
|
<programlisting><command>ETH0_IP=$(find_first_interface_address eth0)</command> </programlisting>
|
|
|
|
<para>and make your DNAT rule:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
|
|
?SECTION ALL
|
|
?SECTION ESTABLISHED
|
|
?SECTION RELATED
|
|
?SECTION INVALID
|
|
?SECTION UNTRACKED
|
|
?SECTION NEW
|
|
|
|
DNAT loc loc:192.168.1.5 tcp www - <emphasis
|
|
role="bold">$ETH0_IP</emphasis></programlisting>
|
|
|
|
<para>Using this technique, you will want to configure your
|
|
DHCP/PPPoE/PPTP/… client to automatically restart Shorewall each
|
|
time that you get a new IP address.</para>
|
|
|
|
<note>
|
|
<para>If your local interface is a bridge, see <link
|
|
linkend="faq2e">FAQ 2e</link> for additional configuration
|
|
steps.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>For optional interfaces, use the function <emphasis
|
|
role="bold">find_first_interface_address_if_any()</emphasis>
|
|
rather than <emphasis
|
|
role="bold">find_first_interface_address()</emphasis>. The former
|
|
will return 0.0.0.0 if the interface has no configured IP address;
|
|
the latter terminates the calling program.</para>
|
|
</note>
|
|
|
|
<note id="Call">
|
|
<para>If you run Shorewall-lite on your firewall, you must use the
|
|
following in the firewall's configuration directory
|
|
<filename>params</filename> file:</para>
|
|
|
|
<programlisting><command>ETH0_IP=$(ssh root@firewall "/sbin/shorewall-lite call find_first_interface_address eth0")</command></programlisting>
|
|
</note>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<section id="faq2a">
|
|
<title>(FAQ 2a) I have a zone <quote>Z</quote> with an RFC1918 subnet
|
|
and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in
|
|
Z. Hosts in Z cannot communicate with each other using their external
|
|
(non-RFC1918 addresses) so they can't access each other using their
|
|
DNS names.</title>
|
|
|
|
<note>
|
|
<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 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
|
|
DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF
|
|
PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0</programlisting>
|
|
</note>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> This is another problem
|
|
that is best solved using split DNS. It allows both external and
|
|
internal clients to access a NATed host using the host's DNS
|
|
name.</para>
|
|
|
|
<para>Another good way to approach this problem is to switch from
|
|
one-to-one NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918
|
|
addresses and can be accessed externally and internally using the same
|
|
address.</para>
|
|
|
|
<para>If you don't like those solutions and prefer to route all
|
|
Z->Z traffic through your firewall then:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Set the routeback option on the interface to Z.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Set the ALL INTERFACES column in the nat file to
|
|
<quote>Yes</quote>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<example id="Example1">
|
|
<title>Example:</title>
|
|
|
|
<literallayout>Zone: dmz, Interface: eth2, Subnet: 192.168.2.0/24, Address of server 192.168.2.2</literallayout>
|
|
|
|
<para>In <filename>/etc/shorewall/interfaces</filename>:</para>
|
|
|
|
<programlisting>?FORMAT 2
|
|
#ZONE INTERFACE OPTIONS
|
|
dmz eth2 <emphasis role="bold">routeback</emphasis> </programlisting>
|
|
|
|
<para>In <filename>/etc/shorewall/masq</filename>:</para>
|
|
|
|
<programlisting>#INTERFACE SOURCE
|
|
eth2:192.168.1.2 192.168.2.0/24</programlisting>
|
|
|
|
<para>In <filename>/etc/shorewall/nat</filename>, be sure that you
|
|
have <quote>Yes</quote> in the ALL INTERFACES column.</para>
|
|
</example>
|
|
</section>
|
|
|
|
<section id="faq2b">
|
|
<title>(FAQ 2b) I have a web server in my DMZ and I use port
|
|
forwarding to make that server accessible from the Internet as
|
|
www.mydomain.com. That works fine but when my local users try to
|
|
connect to www.mydomain.com, it doesn't work.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Let's assume the
|
|
following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>External IP address is 206.124.146.176 on <filename
|
|
class="devicefile">eth0</filename> (www.mydomain.com).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Server's IP address is 192.168.2.4</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>You can enable access to the server from your local network
|
|
using the firewall's external IP address by adding this rule:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
|
|
?SECTION ALL
|
|
?SECTION ESTABLISHED
|
|
?SECTION RELATED
|
|
?SECTION INVALID
|
|
?SECTION UNTRACKED
|
|
?SECTION NEW
|
|
|
|
<emphasis role="bold">DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176</emphasis></programlisting>
|
|
|
|
<para>If your external IP address is dynamic, then you must do the
|
|
following:</para>
|
|
|
|
<para>In <filename>/etc/shorewall/params</filename>:</para>
|
|
|
|
<programlisting><command>ETH0_IP=`find_first_interface_address eth0`</command> </programlisting>
|
|
|
|
<para>and make your DNAT rule:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST
|
|
|
|
?SECTION ALL
|
|
?SECTION ESTABLISHED
|
|
?SECTION RELATED
|
|
?SECTION INVALID
|
|
?SECTION UNTRACKED
|
|
?SECTION NEW
|
|
|
|
DNAT loc dmz:192.168.2.4 tcp 80 - <emphasis
|
|
role="bold">$ETH0_IP</emphasis></programlisting>
|
|
|
|
<warning>
|
|
<para>With dynamic IP addresses, you probably don't want to use
|
|
<ulink
|
|
url="starting_and_stopping_shorewall.htm"><command>shorewall[-lite]
|
|
save</command> and <command>shorewall[-lite]
|
|
restore</command></ulink>.</para>
|
|
</warning>
|
|
|
|
<note>
|
|
<para>For optional interfaces, use the function <emphasis
|
|
role="bold">find_first_interface_address_if_any()</emphasis> rather
|
|
than <emphasis
|
|
role="bold">find_first_interface_address()</emphasis>. The former
|
|
will return 0.0.0.0 if the interface has no configured IP address;
|
|
the latter terminates the calling program.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>If you use Shorewall-lite, then you need to configure the
|
|
params file in the firewall's configuration directory as described
|
|
<link linkend="Call">above</link>.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="faq2c">
|
|
<title>(FAQ 2c) I tried to apply the answer to FAQ 2 to my external
|
|
interface and the net zone and it didn't work. Why?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Did you set <emphasis
|
|
role="bold">IP_FORWARDING=On</emphasis> in
|
|
<filename>shorewall.conf</filename>?</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>(FAQ 2d) Does Shorewall support hairpinning NAT?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Yes.</para>
|
|
|
|
<para>In the case of simple masquerade/SNAT, see <link
|
|
linkend="faq2">FAQ 2</link>.</para>
|
|
|
|
<para>For one-to-one (static), NAT, simply place 'Yes' in the ALL
|
|
INTERFACES column of each entry in <ulink
|
|
url="manpages/shorewall-nat.html">/etc/shorewall/nat</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq2e">
|
|
<title>(FAQ 2e) I have the situation in FAQ 2 but my local interface
|
|
is a bridge and the solution in FAQ 2 doesn't work</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Assume that the bridge
|
|
is br0 and that eth2 is the bridge port that connects to the LAN
|
|
containing 192.168.1.5</para>
|
|
|
|
<para>In addition to the steps in FAQ 2 (replacing eth1 with br0), you
|
|
also need to:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Set the <firstterm>hairpin</firstterm> option on
|
|
eth2.</para>
|
|
|
|
<programlisting>brctl hairpin br0 eth2 on</programlisting>
|
|
|
|
<para>On Debian and derivitives, you can place that command in
|
|
/etc/network/interfaces as a post-up command:</para>
|
|
|
|
<programlisting>auto br0
|
|
iface br0 inet static
|
|
bridge_ports eth2
|
|
bridge_fd 0
|
|
bridge_maxwait 0
|
|
address 192.168.1.1
|
|
netmask 255.255.255.0
|
|
<emphasis role="bold">post-up /sbin/brctl hairpin br0 eth2 on</emphasis></programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Install ebtables if it is not already installed.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Be sure that all traffic going out of eth2 has the correct
|
|
MAC address.</para>
|
|
|
|
<programlisting>ebtables -t nat -A POSTROUTING -o eth2 -j snat --to-source <emphasis>br0-MAC-address</emphasis> </programlisting>
|
|
|
|
<para>where br0-MAC-address is the MAC address of br0.</para>
|
|
|
|
<para>Here's a working example of /etc/shorewall/start that
|
|
executes the above command.</para>
|
|
|
|
<programlisting>if [ $(ebtables -t nat -L POSTROUTING | wc -l) -lt 4 ]; then
|
|
<emphasis role="bold">ebtables -t nat -A POSTROUTING -o eth2 -j snat --to-source 0:19:21:d0:61:65</emphasis>
|
|
fi</programlisting>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Blacklisting">
|
|
<title>Blacklisting</title>
|
|
|
|
<section id="faq63">
|
|
<title>(FAQ 63) I just blacklisted IP address 206.124.146.176 and I can
|
|
still ping it. What did I do wrong?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Nothing.</para>
|
|
|
|
<para>Blacklisting an IP address blocks incoming traffic from that IP
|
|
address. And if you set BLACKLISTNEWONLY=Yes in
|
|
<filename>shorewall.conf</filename>, then only new connections <emphasis
|
|
role="bold">from</emphasis> that address are disallowed; traffic from
|
|
that address that is part of an established connection (such as ping
|
|
replies) is allowed.</para>
|
|
|
|
<note>
|
|
<para>Beginning with Shorewall 4.4.13, you can use the
|
|
<option>blacklist</option> option in <ulink
|
|
url="manpages/shorewall-interfaces.html"><filename>/etc/shorewall/interfaces</filename></ulink>
|
|
to implement blacklisting by destination IP address.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>Beginning with Shorewall 4.4.26, you can use <ulink
|
|
url="manpages/shorewall-blrules.html">/etc/shorewall/blrules</ulink>
|
|
to implement arbitrary blacklist rules.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="faq84">
|
|
<title>(FAQ 84) I put some IPs in the blacklist file in /etc/shorewall
|
|
to block the ips but i'm still getting reports from PSAD from those ips
|
|
saying they're port scanning. Shouldn't being on the blacklist drop all
|
|
packets from those ips?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: You probably forgot to
|
|
specify the <emphasis role="bold">blacklist</emphasis> option for your
|
|
external interface(s) in <filename><ulink
|
|
url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink></filename>.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="MSN">
|
|
<title>Netmeeting/MSN</title>
|
|
|
|
<section id="faq3">
|
|
<title>(FAQ 3) I want to use Netmeeting or MSN Instant Messenger with
|
|
Shorewall. What do I do?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> There is an <ulink
|
|
url="http://www.kfki.hu/~kadlec/sw/netfilter/newnat-suite/">H.323
|
|
connection tracking/NAT module</ulink> that helps with
|
|
Netmeeting.</para>
|
|
|
|
<para>Look <ulink url="UPnP.html">here</ulink> for a solution for MSN IM
|
|
but be aware that there are significant security risks involved with
|
|
this solution. Also check the Netfilter mailing list archives at <ulink
|
|
url="http://www.netfilter.org">http://www.netfilter.org</ulink>.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Openports">
|
|
<title>Open Ports</title>
|
|
|
|
<section id="faq100">
|
|
<title>(FAQ 100) With Shorewall started, the output of 'iptables -L'
|
|
looks like my firewall is wide open!</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> The problem here is that
|
|
a bare <command>iptables -L</command> command produces totally useless
|
|
output. Use <command>shorewall show</command> instead.</para>
|
|
|
|
<note>
|
|
<para>The <command>shorewall show</command> command is a wrapper
|
|
around <command>iptables -L -n -v</command>.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="faq51">
|
|
<title>(FAQ 51) How do I Open Ports in Shorewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> No one who has installed
|
|
Shorewall using one of the <ulink
|
|
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 communication is
|
|
open by default. So you do not need to 'open ports' for output.</para>
|
|
|
|
<para>For input:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If you installed using the Standalone Guide, then please
|
|
<ulink url="standalone.htm#Open">re-read this
|
|
section</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you installed using the Two-interface Guide, then please
|
|
re-read these sections: <ulink url="two-interface.htm#DNAT">Port
|
|
Forwarding (DNAT)</ulink>, and <ulink
|
|
url="two-interface.htm#Open">Other Connections</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you installed using the Three-interface Guide, then please
|
|
re-read these sections: <ulink url="three-interface.htm#DNAT">Port
|
|
Forwarding (DNAT)</ulink> and <ulink
|
|
url="three-interface.htm#Open">Other Connections</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you installed using the <ulink
|
|
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink> then
|
|
you had better read the guide again -- you clearly missed a
|
|
lot.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Also please see the <link linkend="PortForwarding">Port Forwarding
|
|
section of this FAQ</link>.</para>
|
|
</section>
|
|
|
|
<section id="faq4">
|
|
<title>(FAQ 4) I just used an online port scanner to check my firewall
|
|
and it shows some ports as <quote>closed</quote> rather than
|
|
<quote>blocked</quote>. Why?</title>
|
|
|
|
<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
|
|
<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
|
|
<emphasis role="bold">REJECT</emphasis> action (i.e., <emphasis
|
|
role="bold">Auth(REJECT)</emphasis>). This is necessary to prevent
|
|
outgoing connection problems to services that use the
|
|
<quote>Auth</quote> mechanism for identifying requesting users. That is
|
|
the only service which the default setup rejects.</para>
|
|
|
|
<para>If you are seeing closed TCP ports other than 113 (auth) then
|
|
either you have added rules to REJECT those ports or a router outside of
|
|
your firewall is responding to connection requests on those
|
|
ports.</para>
|
|
|
|
<para>If you would prefer to 'stealth' port 113, then:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If you are running Shorewall 4.4.20 or earlier, copy
|
|
/<filename>usr/share/shorewall/action.Drop</filename> to
|
|
<filename>/etc/shorewall/</filename> and modify the invocation of
|
|
Auth to <emphasis role="bold">Auth(DROP)</emphasis>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you are running Shorewall 4.4.21 or later, in
|
|
shorewall.conf, set DROP_DEFAULT="Drop(-,DROP)". See the <ulink
|
|
url="Actions.html">Action HOWTO</ulink> to learn how that magic
|
|
works.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<section id="faq4a">
|
|
<title>(FAQ 4a) I just ran an nmap UDP scan of my firewall and it
|
|
showed 100s of ports as open!!!!</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Take a deep breath and
|
|
read the nmap manpage section about UDP scans. If nmap gets <emphasis
|
|
role="bold">nothing</emphasis> back from your firewall then it reports
|
|
the port as open. If you want to see which UDP ports are really open,
|
|
temporarily change your net->all policy to REJECT, restart
|
|
Shorewall and run the nmap UDP scan again.</para>
|
|
</section>
|
|
|
|
<section id="faq4b">
|
|
<title>(FAQ 4b) I have a port that I can't close no matter how I
|
|
change my rules.</title>
|
|
|
|
<para>I had a rule that allowed telnet from my local network to my
|
|
firewall; I removed that rule and restarted Shorewall but my telnet
|
|
session still works!!!</para>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Rules only govern the
|
|
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 firewall will block that attempt.</para>
|
|
</section>
|
|
|
|
<section id="faq4c">
|
|
<title>(FAQ 4c) How do I use Shorewall with PortSentry?</title>
|
|
|
|
<para><ulink
|
|
url="http://www.shorewall.net/pub/shorewall/contrib/PortsentryHOWTO.txt"><emphasis
|
|
role="bold">Answer:</emphasis> Here's a writeup</ulink> describing a
|
|
nice integration of Shorewall and PortSentry.</para>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Connections">
|
|
<title>Connection Problems</title>
|
|
|
|
<section id="pseudofaq17">
|
|
<title>Why are these packets being Dropped/Rejected? How do I decode
|
|
Shorewall log messages?</title>
|
|
|
|
<para>Please see <link linkend="faq17">FAQ 17</link>.</para>
|
|
</section>
|
|
|
|
<section id="faq5">
|
|
<title>(FAQ 5) I've installed Shorewall and now I can't ping through the
|
|
firewall</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> For a complete
|
|
description of Shorewall <quote>ping</quote> management, see <ulink
|
|
url="ping.html">this page</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq15">
|
|
<title>(FAQ 15) My local systems can't see out to the net</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Every time I read
|
|
<quote>systems can't see out to the net</quote>, I wonder where the
|
|
poster bought computers with eyes and what those computers will
|
|
<quote>see</quote> when things are working properly :-). That aside, the
|
|
most common causes of this problem are:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>The default gateway on each local system isn't set to the IP
|
|
address of the local firewall interface. You can test this
|
|
by:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>At a root shell prompt, type 'shorewall clear'.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>From a local system, attempt to ping the IP address of the
|
|
Shorewall system's internet (external) interface. If that
|
|
doesn't work, then the default gateway on the system from which
|
|
you pinged is not set correctly.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Be sure to 'shorewall start' after the test.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The entry for the local network in the
|
|
<filename>/etc/shorewall/masq</filename> file is wrong or
|
|
missing.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<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>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Forwarding is not enabled (This is often the problem for
|
|
Debian users). Enter this command:</para>
|
|
|
|
<programlisting>cat /proc/sys/net/ipv4/ip_forward</programlisting>
|
|
|
|
<para>If the value displayed is 0 (zero) then set <emphasis
|
|
role="bold">IP_FORWARDING=On</emphasis> in
|
|
<filename>/etc/shorewall/shorewall.conf</filename> and restart
|
|
Shorewall.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="faq29">
|
|
<title>(FAQ 29) FTP Doesn't Work</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> See the <ulink
|
|
url="FTP.html">Shorewall and FTP page</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq33">
|
|
<title>(FAQ 33) From clients behind the firewall, connections to some
|
|
sites fail. Connections to the same sites from the firewall itself work
|
|
fine. What's wrong?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Most likely, you need to
|
|
set CLAMPMSS=Yes in <filename><ulink
|
|
url="manpages/shorewall.conf.html">/etc/shorewall/shorewall.conf</ulink></filename>.</para>
|
|
</section>
|
|
|
|
<section id="faq35">
|
|
<title>(FAQ 35) I have two Ethernet interfaces to my local network which
|
|
I have bridged. When Shorewall is started, I'm unable to pass traffic
|
|
through the bridge. I have defined the bridge interface (br0) as the
|
|
local interface in <filename>/etc/shorewall/interfaces</filename>; the
|
|
bridged Ethernet interfaces are not defined to Shorewall. How do I tell
|
|
Shorewall to allow traffic through the bridge?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Add the
|
|
<option>routeback</option> option to <filename
|
|
class="devicefile">br0</filename> in <filename><ulink
|
|
url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink></filename>.</para>
|
|
|
|
<para>For more information on this type of configuration, see the <ulink
|
|
url="SimpleBridge.html">Shorewall Simple Bridge
|
|
documentation</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq64">
|
|
<title>(FAQ 64) I just upgraded my kernel to 2.6.20 (or later) and my
|
|
bridge/firewall stopped working. What is wrong?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> In kernel 2.6.20, the
|
|
Netfilter <firstterm>physdev match</firstterm> feature was changed such
|
|
that it is no longer capable of matching the output device of
|
|
non-bridged traffic. You will see messages such as the following in your
|
|
log:</para>
|
|
|
|
<programlisting>Apr 20 15:03:50 wookie kernel: [14736.560947] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for
|
|
non-bridged traffic is not supported anymore.</programlisting>
|
|
|
|
<para>This kernel change, while necessary, means that Shorewall zones
|
|
may no longer be defined in terms of bridge ports. See the<ulink
|
|
url="bridge-Shorewall-perl.html"> Shorewall-perl bridging
|
|
documentation</ulink> for information about how to configure
|
|
bridge/firewalls.<note>
|
|
<para>Following the instructions in the new bridging documentation
|
|
will not prevent the above message from being issued.</para>
|
|
</note></para>
|
|
</section>
|
|
|
|
<section id="faq85">
|
|
<title>(FAQ 85) Shorewall is rejecting connections from my local lan
|
|
because it thinks they are coming from the 'net' zone.</title>
|
|
|
|
<para>I'm seeing this in my log:</para>
|
|
|
|
<programlisting>Aug 31 16:51:24 fw22 kernel: Shorewall:net2fw:DROP:IN=eth5 OUT= MAC=00:0c:29:74:9c:0c:08:00:20:b2:5f:db:08:00
|
|
SRC=10.1.50.14 DST=10.1.50.7 LEN=57 TOS=0x00 PREC=0x00 TTL=255 ID=32302 DF
|
|
PROTO=UDP SPT=53289 DPT=53 LEN=37</programlisting>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: This occurs when the
|
|
external interface and an internal interface are connected to the same
|
|
switch or hub. See <ulink url="FoolsFirewall.html">this article</ulink>
|
|
for details. The solution is to never connect more than one firewall
|
|
interface to the same hub or switch (an obvious exception is that when
|
|
you have a switch that supports VLAN tagging and the interfaces are
|
|
associated with different VLANs).</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Logging">
|
|
<title>Logging</title>
|
|
|
|
<section id="faq91">
|
|
<title>(FAQ 91) I changed the shorewall.conf file in /etc/shorewall/ to
|
|
spit out logs to /var/log/shorewall.log and it's not happening after I
|
|
restart shorewall. LOGFILE=/var/log/shorewall.log <-- that should be
|
|
the correct line, right?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: No, that is not correct.
|
|
The LOGFILE setting tells Shorewall where to find the log; it does not
|
|
determine where messages are written. See <link linkend="faq6">the next
|
|
FAQ</link>.</para>
|
|
</section>
|
|
|
|
<section id="faq6">
|
|
<title>(FAQ 6) Where are the log messages written and how do I change
|
|
the destination?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> NetFilter uses the
|
|
kernel's equivalent of syslog (see <quote>man syslog</quote>) to log
|
|
messages. It always uses the LOG_KERN (kern) facility (see <quote>man
|
|
openlog</quote>) and you get to choose the log level (again, see
|
|
<quote>man syslog</quote>) in your <filename><ulink
|
|
url="manpages/shorewall-policy.html">policies</ulink></filename> and
|
|
<filename><ulink
|
|
url="manpages/shorewall-rules.html">rules</ulink></filename>. The
|
|
destination for messages logged by syslog is controlled by
|
|
<filename>/etc/syslog.conf</filename> (see <quote>man
|
|
syslog.conf</quote>). When you have changed
|
|
<filename>/etc/syslog.conf</filename>, be sure to restart syslogd (on a
|
|
RedHat system, <quote>service syslog restart</quote>).</para>
|
|
|
|
<para>It is also possible to <ulink url="shorewall_logging.html">set up
|
|
Shorewall to log all of Netfilter's messages to a separate
|
|
file</ulink>.</para>
|
|
|
|
<section id="faq6a">
|
|
<title>(FAQ 6a) Are there any log parsers that work with
|
|
Shorewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Here are several links
|
|
that may be helpful:</para>
|
|
|
|
<literallayout>
|
|
<ulink url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/pub/shorewall/parsefw/</ulink>
|
|
<ulink url="http://aaron.marasco.com/linux.html">http://aaron.marasco.com/linux.html</ulink>
|
|
<ulink url="http://cert.uni-stuttgart.de/projects/fwlogwatch">http://cert.uni-stuttgart.de/projects/fwlogwatch</ulink>
|
|
<ulink url="http://www.logwatch.org">http://www.logwatch.org</ulink>
|
|
</literallayout>
|
|
|
|
<para>I personally use <ulink
|
|
url="http://www.cert.uni-stuttgart.de.projects/fwlogwatch">fwlogwatch</ulink>.
|
|
It emails me a report each day from my various systems with each
|
|
report summarizing the logged activity on the corresponding system;
|
|
here's a sample:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>fwlogwatch summary
|
|
Generated Tuesday March 02 08:14:37 PST 2010 by root.
|
|
362 (and 455 older than 86400 seconds) of 817 entries in the file "/var/log/ulog/syslogemu.log" are packet logs, 138 have unique characteristics.
|
|
First packet log entry: Mar 01 08:16:06, last: Mar 02 08:06:21.
|
|
All entries were logged by the same host: "gateway".
|
|
All entries have the same target: "-".
|
|
Only entries with a count of at least 5 are shown.
|
|
|
|
net-dmz DROP eth2 36 packets from 61.158.162.9 to 206.124.146.177
|
|
net-fw DROP eth0 21 packets from 89.163.162.13 to 76.104.233.98
|
|
net-fw DROP eth0 19 packets from 61.184.101.46 to 76.104.233.98
|
|
net-fw DROP eth0 12 packets from 81.157.214.103 to 76.104.233.98
|
|
net-fw DROP eth0 11 packets from 174.37.159.222 to 76.104.233.98
|
|
net-fw DROP eth0 10 packets from 221.195.73.86 to 76.104.233.98
|
|
net-dmz DROP eth2 9 packets from 202.199.158.6 to 206.124.146.177
|
|
net-fw DROP eth2 9 packets from 202.199.158.6 to 206.124.146.176
|
|
net-dmz DROP eth2 9 packets from 202.199.158.6 to 206.124.146.178
|
|
net-fw DROP eth0 6 packets from 221.192.199.35 to 76.104.233.98
|
|
net-fw DROP eth2 5 packets from 61.158.162.9 to 206.124.146.177</programlisting>
|
|
</blockquote>
|
|
|
|
<para>Fwlogwatch contains a built-in web server that allows monitoring
|
|
recent activity in summary fashion.</para>
|
|
</section>
|
|
|
|
<section id="faq6b">
|
|
<title>(FAQ 6b) DROP messages on port 10619 are flooding the logs with
|
|
their connect requests. Can I exclude these error messages for this
|
|
port temporarily from logging in Shorewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Temporarily add the
|
|
following rule:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
|
|
?SECTION ALL
|
|
?SECTION ESTABLISHED
|
|
?SECTION RELATED
|
|
?SECTION INVALID
|
|
?SECTION UNTRACKED
|
|
?SECTION NEW
|
|
|
|
DROP net $FW udp 10619</programlisting>
|
|
|
|
<para>Alternatively, if you do not set BLACKLIST_LOGLEVEL you can
|
|
blacklist the port. In
|
|
<filename>/etc/shorewall/blrules</filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
|
|
DROP net $FW udp 10619</programlisting>
|
|
</section>
|
|
|
|
<section id="faq6d">
|
|
<title>(FAQ 6d) Why is the MAC address in Shorewall log messages so
|
|
long? I thought MAC addresses were only 6 bytes in length.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> What is labeled as the
|
|
MAC address in a Netfilter (Shorewall) log message is actually the
|
|
Ethernet frame header. It contains:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>the destination MAC address (6 bytes)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>the source MAC address (6 bytes)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>the Ethernet frame type (2 bytes)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para><example id="Example5">
|
|
<title id="Example2">Example</title>
|
|
|
|
<para><programlisting>MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00</programlisting>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Destination MAC address = 00:04:4c:dc:e2:28</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Source MAC address = 00:b0:8e:cf:3c:4c</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ethernet Frame Type = 08:00 (IP Version 4)</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
</example></para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq16">
|
|
<title>(FAQ 16) Shorewall is writing log messages all over my console
|
|
making it unusable!</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis></para>
|
|
|
|
<para>Just to be clear, it is not Shorewall that is writing all over
|
|
your console. Shorewall issues a single log message during each
|
|
<command>start</command>, <command>restart</command>,
|
|
<command>stop</command>, etc. It is rather your logging daemon that is
|
|
writing messages to your console. Shorewall itself has no control over
|
|
where a particular class of messages are written. See the <ulink
|
|
url="shorewall_logging.html">Shorewall logging
|
|
documentation</ulink>.</para>
|
|
|
|
<para>The max log level to be sent to the console is available in
|
|
/proc/sys/kernel/printk:<programlisting>teastep@ursa:~$ <emphasis
|
|
role="bold">cat /proc/sys/kernel/printk</emphasis>
|
|
6 6 1 7
|
|
teastep@ursa:~$ </programlisting>The first number determines the maximum log
|
|
level (syslog priority) sent to the console. Messages with priority
|
|
<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 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()
|
|
calls that do not specify a log level.</para>
|
|
|
|
<para>The third number specifies the minimum console log level while the
|
|
fourth gives the default console log level.</para>
|
|
|
|
<para>If, on your system, the first number is 7 or greater, then the
|
|
default Shorewall configurations will cause messages to be written to
|
|
your console. The simplest solution is to add this to your
|
|
<filename>/etc/sysctl.conf</filename> file:<programlisting>kernel.printk = 4 4 1 7</programlisting></para>
|
|
|
|
<para>then<programlisting><command>sysctl -p /etc/sysctl.conf</command></programlisting></para>
|
|
|
|
<section id="faq16a">
|
|
<title>(FAQ 16a) cat /proc/sys/kernel/prink returns '4 4 1 7' and
|
|
still I get dmesg filled up</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: While we would argue
|
|
that 'dmesg filled up' is not necessarily a problem, the only way to
|
|
eliminate that is to <ulink url="shorewall_logging.html">set up
|
|
Shorewall to log all of Netfilter's messages to a separate
|
|
file</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq16b">
|
|
<title>(FAQ 16b) Why can't I see any Shorewall messages in
|
|
/var/log/messages?</title>
|
|
|
|
<para>Some people who ask this question report that the only Shorewall
|
|
messages that they see in <filename>/var/log/messages</filename> are
|
|
'started', 'restarted' and 'stopped' messages.</para>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> First of all, it is
|
|
important to understand that Shorewall itself does not control where
|
|
Netfilter log messages are written. The LOGFILE setting in
|
|
<filename>shorewall.conf</filename> simply tells the
|
|
<filename>/sbin/shorewall[-lite]</filename> program where to look for
|
|
the log. Also, it is important to understand that a log level of
|
|
"debug" will generally cause Netfilter messages to be written to fewer
|
|
files in <filename class="directory">/var/log</filename> than a log
|
|
level of "info". The log level does not control the number of 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 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
|
|
write Shorewall messages to
|
|
<filename>/var/log/firewall</filename>.</para>
|
|
|
|
<para>Please see the <ulink url="shorewall_logging.html">Shorewall
|
|
logging documentation</ulink> for further information.</para>
|
|
</section>
|
|
|
|
<section id="faq16c">
|
|
<title>(FAQ 16c) Shorewall messages are flooding the output of
|
|
'dmesg'; how to I stop that?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Switch to using <ulink
|
|
url="???">ulogd</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq16d">
|
|
<title>(FAQ 16d) I set LOGFILE=/var/log/shorewall but log messages are
|
|
still going to /var/log/messages.</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: See the answer to <link
|
|
linkend="faq16b">FAQ 16b</link> above.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq17">
|
|
<title>(FAQ 17) Why are these packets being Dropped/Rejected? How do I
|
|
decode Shorewall log messages?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Logging of
|
|
dropped/rejected packets occurs out of a number of chains (as indicated
|
|
in the log message) in Shorewall:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry id="all2all">
|
|
<term><emphasis role="bold"><replaceable>zone</replaceable>2all,
|
|
<replaceable>zone</replaceable>-all,
|
|
all2<replaceable>zone</replaceable>,
|
|
all-<replaceable>zone</replaceable>, all2all or
|
|
all-all</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>You have a <filename><ulink
|
|
url="manpages/shorewall-policy.html">policy</ulink></filename>
|
|
that specifies a log level and this packet is being logged under
|
|
that policy. If you intend to ACCEPT this traffic then you need a
|
|
<ulink url="manpages/shorewall-rules.html">rule</ulink> to that
|
|
effect.</para>
|
|
|
|
<para>Packets logged out of these chains may have a source and/or
|
|
destination that is not in any defined zone (see the output of
|
|
<command>shorewall[-lite] show zones</command>). Remember that
|
|
zone membership involves both a firewall interface and an ip
|
|
address.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold"><replaceable>zone1</replaceable>2<replaceable>zone2</replaceable>
|
|
or <replaceable>zone1-zone2</replaceable></emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Either you have a <ulink
|
|
url="manpages/shorewall-policy.html">policy</ulink> for
|
|
<emphasis>zone1</emphasis> to <emphasis>zone2</emphasis> that
|
|
specifies a log level and this packet is being logged under that
|
|
policy or this packet matches a <ulink
|
|
url="manpages/shorewall-rules.html">rule</ulink> that includes a
|
|
log level.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">@<replaceable>zone1</replaceable>2<replaceable>zone2</replaceable>
|
|
or
|
|
@<replaceable>zone1</replaceable>-<replaceable>zone2</replaceable></emphasis></term>
|
|
|
|
<listitem>
|
|
<para>You have a policy for traffic from
|
|
<replaceable>zone1</replaceable> to
|
|
<replaceable>zone2</replaceable> that specifies TCP connection
|
|
rate limiting (value in the LIMIT column). The logged packet
|
|
exceeds that limit and was dropped. Note that these log messages
|
|
themselves are severely rate-limited so that a syn-flood won't
|
|
generate a secondary DOS because of excessive log message. These
|
|
log messages were added in Shorewall 2.2.0 Beta 7.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold"><replaceable>zone1</replaceable>2<replaceable>zone2</replaceable>~,
|
|
<replaceable>zone1</replaceable>-<replaceable>zone2</replaceable>~
|
|
or ~blacklist<replaceable>nn</replaceable></emphasis></term>
|
|
|
|
<listitem>
|
|
<para>These are the result of entries in the <ulink
|
|
url="manpages/shorewall-blrules.html">/etc/shorewall/blrules</ulink>
|
|
file.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold"><emphasis>interface</emphasis>_mac or
|
|
<emphasis>interface</emphasis>_rec</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>The packet is being logged under the <emphasis
|
|
role="bold">maclist</emphasis> <ulink
|
|
url="manpages/shorewall-interfaces.html">interface
|
|
option</ulink>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">blacklist</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>The packet is being logged because the source IP is
|
|
blacklisted in the <filename> <ulink
|
|
url="manpages/shorewall-blacklist.html">/etc/shorewall/blacklist</ulink>
|
|
</filename> file.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">INPUT or FORWARD</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>The packet has a source IP address that isn't in any of your
|
|
defined zones (<quote><command>shorewall[-lite] show
|
|
zones</command></quote> and look at the printed zone definitions)
|
|
or the chain is FORWARD and the destination IP isn't in any of
|
|
your defined zones. If the chain is FORWARD and the IN and OUT
|
|
interfaces are the same or they match the same wildcard entry in
|
|
<ulink
|
|
url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink>,
|
|
then you probably need the <emphasis
|
|
role="bold">routeback</emphasis> option on that interface
|
|
in<filename> <ulink
|
|
url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink>
|
|
</filename>, you need the <emphasis
|
|
role="bold">routeback</emphasis> option in the relevant entry in
|
|
<filename> <ulink
|
|
url="manpages/shorewall-hosts.html">/etc/shorewall/hosts</ulink>
|
|
or you've done something silly like define a default route out of
|
|
an internal interface.</filename></para>
|
|
|
|
<para>With OPTIMIZE=1 in <ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink>, such
|
|
packets may also be logged out of a <zone>2all chain or the
|
|
all2all chain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">OUTPUT</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>The packet has a destination IP address that isn't in any of
|
|
your defined zones(<command>shorewall[-lite] show zones</command>
|
|
and look at the printed zone definitions).</para>
|
|
|
|
<para>With OPTIMIZE=1 in <ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink>, such
|
|
packets may also be logged out of the fw2all chain or the all2all
|
|
chain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">logflags</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>The packet is being logged because it failed the checks
|
|
implemented by the <emphasis role="bold">tcpflags</emphasis>
|
|
<ulink url="manpages/shorewall-interfaces.html">interface
|
|
option</ulink>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">sfilter</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>On systems running Shorewall 4.4.20 or later, either the
|
|
packet matched the <option>filter</option> <ulink
|
|
url="manpages/shorewall-interfaces.html">interface option</ulink>
|
|
or it is being routed out of the same interface on which it
|
|
arrived and the interface does not have the
|
|
<option>routeback</option> or <option>routefilter</option> <ulink
|
|
url="manpages/shorewall-interfaces.html">interface
|
|
option</ulink>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<example id="Example3">
|
|
<title>Here is an example:</title>
|
|
|
|
<programlisting>Jun 27 15:37:56 gateway kernel:
|
|
Shorewall:<emphasis role="bold">all2all:REJECT</emphasis>:<emphasis
|
|
role="bold">IN=eth2</emphasis>
|
|
<emphasis role="bold">OUT=eth1</emphasis>
|
|
<emphasis role="bold">SRC=192.168.2.2</emphasis>
|
|
<emphasis role="bold">DST=192.168.1.3 </emphasis>LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF <emphasis
|
|
role="bold">PROTO=UDP</emphasis>
|
|
SPT=1803 <emphasis role="bold">DPT=53</emphasis> LEN=47</programlisting>
|
|
|
|
<para>Let's look at the important parts of this message:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>all2all:REJECT</term>
|
|
|
|
<listitem>
|
|
<para>This packet was REJECTed out of the <emphasis
|
|
role="bold">all2all</emphasis> chain -- the packet was rejected
|
|
under the <quote>all</quote>-><quote>all</quote> REJECT
|
|
policy (<link linkend="all2all">all2all</link> above).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>IN=eth2</term>
|
|
|
|
<listitem>
|
|
<para>the packet entered the firewall via eth2. If you see
|
|
<quote>IN=</quote> with no interface name, the packet originated
|
|
on the firewall itself.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>OUT=eth1</term>
|
|
|
|
<listitem>
|
|
<para>if accepted, the packet would be sent on eth1. If you see
|
|
<quote>OUT=</quote> with no interface name, the packet would be
|
|
processed by the firewall itself.</para>
|
|
|
|
<note>
|
|
<para>When a DNAT rule is logged, there will never be an OUT=
|
|
shown because the packet is being logged before it is routed.
|
|
Also, DNAT logging will show the <emphasis>original</emphasis>
|
|
destination IP address and destination port number. When a
|
|
REDIRECT rule is logged, the message will also show the
|
|
original destination IP address and port number.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>SRC=192.168.2.2</term>
|
|
|
|
<listitem>
|
|
<para>the packet was sent by 192.168.2.2</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>DST=192.168.1.3</term>
|
|
|
|
<listitem>
|
|
<para>the packet is destined for 192.168.1.3</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>PROTO=UDP</term>
|
|
|
|
<listitem>
|
|
<para>UDP Protocol</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>DPT=53</term>
|
|
|
|
<listitem>
|
|
<para>The destination port is 53 (DNS)</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>In this case, 192.168.2.2 was in the <quote>dmz</quote> zone and
|
|
192.168.1.3 is in the <quote>loc</quote> zone. I was missing the
|
|
rule:</para>
|
|
|
|
<programlisting>ACCEPT dmz loc udp 53</programlisting>
|
|
</example>
|
|
</section>
|
|
|
|
<section id="faq21">
|
|
<title>(FAQ 21) I see these strange log entries occasionally; what are
|
|
they?</title>
|
|
|
|
<programlisting>Nov 25 18:58:52 linux kernel:
|
|
Shorewall:net2all:DROP:IN=eth1 OUT=
|
|
MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179
|
|
DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 <emphasis
|
|
role="bold">PROTO=ICMP</emphasis>
|
|
<emphasis role="bold">TYPE=3 CODE=3</emphasis> [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00
|
|
TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]</programlisting>
|
|
|
|
<para>192.0.2.3 is external on my firewall... 172.16.0.0/24 is my
|
|
internal LAN</para>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> First of all, please note
|
|
that the above is a very specific type of log message dealing with ICMP
|
|
port unreachable packets (PROTO=ICMP TYPE=3 CODE=3). Do not read this
|
|
answer and assume that all Shorewall log messages have something to do
|
|
with ICMP (hint -- see <link linkend="faq17">FAQ 17</link>).</para>
|
|
|
|
<para>While most people associate the Internet Control Message Protocol
|
|
(ICMP) with <quote>ping</quote>, ICMP is a key piece of IP. ICMP is used
|
|
to report problems back to the sender of a packet; this is what is
|
|
happening here. Unfortunately, where NAT is involved (including SNAT,
|
|
DNAT and Masquerade), there are many broken implementations. That is
|
|
what you are seeing with these messages. When Netfilter displays these
|
|
messages, the part before the "[" describes the ICMP packet and the part
|
|
between the "[" and "]" describes the packet for which the ICMP is a
|
|
response.</para>
|
|
|
|
<para>Here is my interpretation of what is happening -- to confirm this
|
|
analysis, one would have to have packet sniffers placed a both ends of
|
|
the connection.</para>
|
|
|
|
<para>Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS
|
|
query to 192.0.2.3 and your DNS server tried to send a response (the
|
|
response information is in the brackets -- note source port 53 which
|
|
marks this as a DNS reply). When the response was returned to to
|
|
206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and
|
|
forwarded the packet to 172.16.1.10 who no longer had a connection on
|
|
UDP port 2857. This causes a port unreachable (type 3, code 3) to be
|
|
generated back to 192.0.2.3. As this packet is sent back through
|
|
206.124.146.179, that box correctly changes the source address in the
|
|
packet to 206.124.146.179 but doesn't reset the DST IP in the original
|
|
DNS response similarly. When the ICMP reaches your firewall (192.0.2.3),
|
|
your firewall has no record of having sent a DNS reply to 172.16.1.10 so
|
|
this ICMP doesn't appear to be related to anything that was sent. The
|
|
final result is that the packet gets logged and dropped in the all2all
|
|
chain.</para>
|
|
</section>
|
|
|
|
<section id="faq52">
|
|
<title>(FAQ 52) When I blacklist an IP address with "shorewall[-lite]
|
|
drop www.xxx.yyy.zzz", why does my log still show REDIRECT and DNAT
|
|
entries from that address?</title>
|
|
|
|
<para>I blacklisted the address 130.252.100.59 using <command>shorewall
|
|
drop 130.252.100.59</command> but I am still seeing these log
|
|
messages:</para>
|
|
|
|
<programlisting>Jan 30 15:38:34 server Shorewall:net_dnat:REDIRECT:IN=eth1 OUT= MAC=00:4f:4e:14:97:8e:00:01:5c:23:24:cc:08:00
|
|
SRC=130.252.100.59 DST=206.124.146.176 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=42444 DF
|
|
PROTO=TCP SPT=2215 DPT=139 WINDOW=53760 RES=0x00 SYN URGP=0</programlisting>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Please refer to the
|
|
<ulink url="NetfilterOverview.html">Shorewall Netfilter
|
|
Documentation</ulink>. Logging of REDIRECT and DNAT rules occurs in the
|
|
nat table's PREROUTING chain where the original destination IP address
|
|
is still available. Blacklisting occurs out of the filter table's INPUT
|
|
and FORWARD chains which aren't traversed until later.</para>
|
|
</section>
|
|
|
|
<section id="faq81">
|
|
<title>(FAQ 81) logdrop and logreject don't log.</title>
|
|
|
|
<para>I love the ability to type 'shorewall logdrop ww.xx.yy.zz' and
|
|
completely block a particular IP address. However, the log part doesn't
|
|
happen. When I look in the logdrop chain, there is no LOG prefix.</para>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: You haven't set a value
|
|
for BLACKLIST_LOGLEVEL in <ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink> (5).</para>
|
|
</section>
|
|
|
|
<section id="faq36">
|
|
<title>(FAQ 36) My log is filling up with these BANDWIDTH
|
|
messages!</title>
|
|
|
|
<programlisting>Dec 15 16:47:30 heath-desktop kernel: [17182740.184000] BANDWIDTH_IN:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:23:79:02:08:00
|
|
SRC=10.119.248.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64
|
|
ID=62081 PROTO=UDP SPT=67 DPT=68 LEN=308
|
|
Dec 15 16:47:30 heath-desktop last message repeated 2 times
|
|
Dec 15 16:47:30 heath-desktop kernel: [17182740.188000] BANDWIDTH_IN:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:23:79:02:08:00
|
|
SRC=10.112.70.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64
|
|
ID=62082 PROTO=UDP SPT=67 DPT=68 LEN=308
|
|
Dec 15 16:47:30 heath-desktop last message repeated 2 times</programlisting>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: The Webmin 'bandwidth'
|
|
module adds commands to <filename>/etc/shorewall/start</filename> that
|
|
creates rules to log every packet to/from/through the firewall.
|
|
<emphasis role="bold">DON'T START THE BANDWIDTH SERVICE IN
|
|
WEBMIN!</emphasis></para>
|
|
|
|
<para>To correct this situation once it occurs, edit
|
|
<filename>/etc/shorewall/start</filename> and insert 'return 0' prior to
|
|
the BANDWIDTH rules.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Routing">
|
|
<title>Routing</title>
|
|
|
|
<section id="faq32">
|
|
<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
|
|
url="MultiISP.html">this article about Shorewall and Multiple
|
|
ISPs</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq49">
|
|
<title>(FAQ 49) When I start Shorewall, my routing table gets blown
|
|
away. Why does Shorewall do that?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> This is usually the
|
|
consequence of a one-to-one nat configuration blunder:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Specifying the primary IP address for an interface in the
|
|
EXTERNAL column of <filename>/etc/shorewall/nat</filename> even
|
|
though the documentation (and the comments in the file) warn you not
|
|
to do that.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Specifying ADD_IP_ALIASES=Yes and RETAIN_ALIASES=No in
|
|
/etc/shorewall/shorewall.conf.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>This combination causes Shorewall to delete the primary IP address
|
|
from the network interface specified in the INTERFACE column which
|
|
usually causes all routes out of that interface to be deleted. The
|
|
solution is to <emphasis role="bold">not specify the primary IP address
|
|
of an interface in the EXTERNAL column</emphasis>.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Start-Stop">
|
|
<title>Starting and Stopping</title>
|
|
|
|
<section id="faq94">
|
|
<title>(FAQ 94) After I start Shorewall, ps doesn't show any shorewall
|
|
process running. What is the Shorewall daemon called?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorewall is not a
|
|
daemon. It is a configuration tool that configures your kernel based on
|
|
the contents of <filename>/etc/shorewall/</filename>. Once the
|
|
<command>start</command> command completes, Shorewall has done its job
|
|
and there are no Shorewall processes remaining in the system.</para>
|
|
</section>
|
|
|
|
<section id="faq7">
|
|
<title>(FAQ 7) When I stop Shorewall using <quote>shorewall[-lite]
|
|
stop</quote>, I can't connect to anything. Why doesn't that command
|
|
work?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> The
|
|
<command>stop</command> command places the firewall in a safe state;
|
|
connections that are allowed are governed by the setting of
|
|
ADMINISABSENTMINDED in <ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink> (5) and the
|
|
contents of <ulink
|
|
url="manpages/shorewall-stoppedrules.html">shorewall-stoppedrules</ulink>
|
|
(5). To totally open the firewall, use the <command>clear</command>
|
|
command.</para>
|
|
</section>
|
|
|
|
<section id="faq9">
|
|
<title>(FAQ 9) Why can't Shorewall detect my interfaces properly at
|
|
startup?</title>
|
|
|
|
<para>I just installed Shorewall and when I issue the
|
|
<command>start</command> command, I see the following:</para>
|
|
|
|
<programlisting>Processing /etc/shorewall/params ...
|
|
Processing /etc/shorewall/shorewall.conf ...
|
|
Starting Shorewall...
|
|
Loading Modules...
|
|
Initializing...
|
|
Determining Zones...
|
|
Zones: net loc
|
|
Validating interfaces file...
|
|
Validating hosts file...
|
|
Determining Hosts in Zones...
|
|
<emphasis role="bold">Net Zone: eth0:0.0.0.0/0
|
|
</emphasis><emphasis role="bold">Local Zone: eth1:0.0.0.0/0</emphasis>
|
|
Deleting user chains...
|
|
Creating input Chains...
|
|
...</programlisting>
|
|
|
|
<para>Why can't Shorewall detect my interfaces properly?</para>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> The above output is
|
|
perfectly normal. The Net zone is defined as all hosts that are
|
|
connected through <filename class="devicefile">eth0</filename> and the
|
|
local zone is defined as all hosts connected through <filename
|
|
class="devicefile">eth1</filename>. You can set the <emphasis
|
|
role="bold">routefilter</emphasis> option on an internal interface if
|
|
you wish to guard against '<firstterm>Martians</firstterm>' (a Martian
|
|
is a packet with a source IP address that is not routed out of the
|
|
interface on which the packet was received). If you do that, it is a
|
|
good idea to also set the <emphasis role="bold">logmartians</emphasis>
|
|
option.</para>
|
|
</section>
|
|
|
|
<section id="faq22">
|
|
<title>(FAQ 22) I have some iptables commands that I want to run when
|
|
Shorewall starts. Which file do I put them in?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis>You can place these
|
|
commands in one of the <ulink
|
|
url="shorewall_extension_scripts.htm">Shorewall Extension
|
|
Scripts</ulink>. Be sure that you look at the contents of the chain(s)
|
|
that you will be modifying with your commands so that the commands will
|
|
do what is intended. Many iptables commands published in HOWTOs and
|
|
other instructional material use the -A command which adds the rules to
|
|
the end of the chain. Most chains that Shorewall constructs end with an
|
|
unconditional DROP, ACCEPT or REJECT rule and any rules that you add
|
|
after that will be ignored. Check <quote>man iptables</quote> and look
|
|
at the -I (--insert) command.</para>
|
|
</section>
|
|
|
|
<section id="faq43">
|
|
<title>(FAQ 43) I just installed the Shorewall RPM and Shorewall doesn't
|
|
start at boot time.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> When you install using
|
|
the "rpm -U" command, Shorewall doesn't run your distribution's tool for
|
|
configuring Shorewall startup. You will need to run that tool (insserv,
|
|
chkconfig, run-level editor, …) to configure Shorewall to start in the
|
|
the default run-levels of your firewall system.</para>
|
|
</section>
|
|
|
|
<section id="faq59">
|
|
<title>(FAQ 59) After I start Shorewall, there are lots of unused
|
|
Netfilter modules loaded. How do I avoid that?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Copy
|
|
<filename>/usr/share/shorewall[-lite]/modules</filename> to
|
|
<filename>/etc/shorewall/modules </filename>and modify the copy to
|
|
include only the modules that you need. An alternative is to set
|
|
LOAD_HELPERS_ONLY=Yes in <ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink> (5).</para>
|
|
</section>
|
|
|
|
<section id="faq68">
|
|
<title>(FAQ 68) I have a VM under an OpenVZ system. I can't get rid of
|
|
the following message:</title>
|
|
|
|
<para>ERROR: Command "/sbin/iptables -A FORWARD -m state --state
|
|
ESTABLISHED,RELATED -j ACCEPT" failed.</para>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> See the <ulink
|
|
url="OpenVZ.html">Shorewall OpenVZ article</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq73">
|
|
<title>(FAQ 73) When I stop Shorewall, the firewall is wide open. Isn't
|
|
that a security risk?</title>
|
|
|
|
<para>It is important to understand that the scripts in <filename
|
|
class="directory">/etc/init.d</filename> are generally provided by your
|
|
distribution and not by the Shorewall developers. These scripts must
|
|
meet the requirements of the distribution's packaging system which may
|
|
conflict with the requirements of a tight firewall. So when you say
|
|
"…when I stop Shorewall…" it is necessary to distinguish between the
|
|
commands <command>/sbin/shorewall stop</command> and
|
|
<command>/etc/init.d/shorewall stop</command>.</para>
|
|
|
|
<para><command>/sbin/shorewall stop</command> places the firewall in a
|
|
<firstterm>safe state</firstterm>, the details of which depend on your
|
|
<filename>/etc/shorewall/stoppedrules</filename> file (<ulink
|
|
url="manpages/shorewall-stoppedrules.html">shorewall-stoppedrules</ulink>(5))
|
|
and on the setting of ADMINISABSENTMINDED in
|
|
<filename>/etc/shorewall/shorewall.conf</filename> (<ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink>(5)).</para>
|
|
|
|
<para><command>/etc/init.d/shorewall stop</command> may or may not do
|
|
the same thing. In the case of <trademark>Debian</trademark> systems for
|
|
example, that command actually executes <command>/sbin/shorewall
|
|
clear</command> which opens the firewall completely. In other words, in
|
|
the init script, <command>stop</command> reverses the effect of
|
|
<command>start</command>.</para>
|
|
|
|
<para>Beginning with Shorewall 4.4, when the Shorewall tarballs are
|
|
installed on a Debian (or derivative) system, the
|
|
<filename>/etc/init.d/shorewall</filename> file is the same as would be
|
|
installed by the .deb. The behavior of <command>/etc/init.d/shorewall
|
|
stop</command> is controlled by the setting of SAFESTOP in
|
|
<filename>/etc/default/shorewall</filename>. When set to 0 (the
|
|
default), the firewall is cleared; when set to 1, the firewall is placed
|
|
in a safe state.</para>
|
|
</section>
|
|
|
|
<section id="faq78">
|
|
<title>(FAQ 78) After restart and bootup of my Debian firewall, all
|
|
traffic is blocked for hosts behind the firewall trying to connect out
|
|
onto the net or through the vpn (although i can reach the internal
|
|
firewall interface and obtain dumps etc). Once I issue 'shorewall clear'
|
|
followed by 'shorewall start' it then works, despite the config not
|
|
changing</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Set IP_FORWARDING=On in
|
|
<filename><ulink
|
|
url="manpages/shorewall.conf.html">/etc/shorewall/shorewall.conf</ulink></filename>.</para>
|
|
</section>
|
|
|
|
<section id="faq86">
|
|
<title>(FAQ 86) My distribution (Ubuntu) uses NetworkManager to manage
|
|
my interfaces. I want to specify the upnpclient option for my interfaces
|
|
which requires them to be up and configured when Shorewall starts but
|
|
Shorewall is being started before NetworkManager.</title>
|
|
|
|
<para>Answer: I faced a similar problem which I solved as
|
|
follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Don't start Shorewall at boot time (Debian and Ubuntu users
|
|
may simply set startup=0 in
|
|
<filename>/etc/default/shorewall</filename>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In <filename>/etc/network/ip-up.d</filename>, I added a
|
|
<filename>shorewall</filename> script as follows:</para>
|
|
|
|
<programlisting>#!/bin/sh
|
|
|
|
shorewall status > /dev/null 2>&1 || shorewall start # Start Shorewall if it isn't already running</programlisting>
|
|
|
|
<para>Be sure to secure the script for execute access.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Update:</term>
|
|
|
|
<listitem>
|
|
<para>Beginning with Shorewall 4.4.10, there is a new <ulink
|
|
url="manpages/shorewall-init.html">Shorewall Init Package</ulink>
|
|
that is designed to handle this case.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
|
|
<section id="faq90">
|
|
<title>(FAQ 90) Shorewall starts fine but after several minutes, it
|
|
stops. Why is it doing that?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorewall uses the
|
|
presence of a chain named <emphasis>shorewall</emphasis> to indicate
|
|
whether is started or stopped. That chain is created during execution of
|
|
a successful <emphasis role="bold">start</emphasis>, <emphasis
|
|
role="bold">restart</emphasis> or <emphasis
|
|
role="bold">restore</emphasis> command and is removed during <emphasis
|
|
role="bold">stop</emphasis> and <emphasis role="bold">clear</emphasis>.
|
|
If <emphasis role="bold">shorewall status</emphasis> indicates that
|
|
Shorewall is stopped, then something has deleted that chain. Look at the
|
|
output of <emphasis role="bold">shorewall status</emphasis>; if it looks
|
|
like this:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>gateway:~# shorewall status
|
|
Shorewall-4.4.11 Status at gateway - Wed Jul 21 13:21:41 PDT 2010
|
|
|
|
Shorewall is <emphasis role="bold">stopped</emphasis>
|
|
State:<emphasis role="bold">Started</emphasis> (Tue Jul 20 16:01:49 PDT 2010)
|
|
|
|
gateway:~#</programlisting>
|
|
</blockquote>
|
|
|
|
<para>then it means that something outside of Shorewall has deleted the
|
|
chain. This usually means that you were running another firewall package
|
|
before you installed Shorewall and that other package has replaced
|
|
Shorewall's Netfilter configuration with its own. You must remove (or at
|
|
least disable) the other firewall package and restart Shorewall.</para>
|
|
|
|
<blockquote>
|
|
<programlisting>gateway:~# shorewall status
|
|
Shorewall-4.4.11 Status at gateway - Wed Jul 21 13:26:29 PDT 2010
|
|
|
|
Shorewall is <emphasis role="bold">stopped</emphasis>
|
|
State:<emphasis role="bold">Stopped</emphasis> (Wed Jul 21 13:26:26 PDT 2010)
|
|
|
|
gateway:~# </programlisting>
|
|
</blockquote>
|
|
|
|
<para>then a <emphasis role="bold">shorewall stop</emphasis> command has
|
|
been executed (if the State shown in the output is <emphasis
|
|
role="bold">Cleared</emphasis>, then a <emphasis role="bold">shorewall
|
|
clear</emphasis> command was executed). Most likely, you have installed
|
|
and configured the <emphasis>shorewall-init</emphasis> package and a
|
|
required interface has gone down.</para>
|
|
</section>
|
|
|
|
<section id="faq99">
|
|
<title>(FAQ 99) My /var/lib/shorewall-init.log shows that Shorewall is
|
|
running at boot but after boot 'iptables -L' shows an empty
|
|
configuration</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: This is caused by your
|
|
failure to disable your distributions default iptables configuration
|
|
tool when you installed Shorewall. Look for a service called 'iptables'
|
|
that is being started after Shorewall and disable it.</para>
|
|
</section>
|
|
|
|
<section id="faq101">
|
|
<title>(FAQ 101) How can I speed up 'shorewall start' and 'shorewall
|
|
restart' on my slow hardware?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: There are several steps
|
|
that you can take:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>If your kernel supports module autoloading (and distribution
|
|
default kernels almost always do), then set LOAD_HELPERS_ONLY=Yes in
|
|
shorewall.conf.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Set AUTOMAKE=Yes in shorewall.conf. This will avoid the
|
|
compilation phase in cases where the configuration has not changed
|
|
since the last time that the configuration was compiled.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Don't set optimization option 8. For example, if you currently
|
|
set OPTIMIZE=31, then change that to OPTIMIZE=23. Optimization
|
|
option 8 combines identical chains which can result in a smaller
|
|
ruleset, but it slows down the compilation of large rulesets.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="faq103">
|
|
<title>(FAQ 103) Shorewall fails to start at boot but will start
|
|
immediately after</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> This is usually
|
|
associated with SELinux. <ulink
|
|
url="https://lists.fedoraproject.org/pipermail/selinux/2010-June/012680.html">Here</ulink>
|
|
is an example.</para>
|
|
</section>
|
|
|
|
<section id="faq104">
|
|
<title>(FAQ 104) I see <emphasis>kernel</emphasis> messages in my log
|
|
when I start or restart Shorewall or Shorewall6</title>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting>> Oct 1 13:04:39 deb kernel: [ 9570.619744] xt_addrtype: ipv6 does not support BROADCAST matching
|
|
</programlisting>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> These are harmless.
|
|
Shorewall attempts to execute various commands to determine the
|
|
capabiities of your system. If you system doesn't support a command, it
|
|
will generally issue a kernel log message.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="MultiISP">
|
|
<title>Multiple ISPs</title>
|
|
|
|
<section id="faq57">
|
|
<title>(FAQ 57) I configured two ISPs in Shorewall but when I try to use
|
|
the second one, it doesn't work.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> The Multi-ISP
|
|
Documentation strongly recommends that you use the <emphasis
|
|
role="bold">balance</emphasis> option on all providers even if you want
|
|
to manually specify which ISP to use. If you don't do that so that your
|
|
main routing table only has one default route, then you must disable
|
|
route filtering. Do not specify the <emphasis
|
|
role="bold">routefilter</emphasis> option on the other interface(s) in
|
|
<filename>/etc/shorewall/interfaces</filename> and disable any
|
|
<emphasis>IP Address Spoofing</emphasis> protection that your
|
|
distribution supplies.</para>
|
|
</section>
|
|
|
|
<section id="faq58">
|
|
<title>(FAQ 58) But if I specify 'balance' then won't Shorewall balance
|
|
the traffic between the interfaces? I don't want that!</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Suppose that you want all
|
|
traffic to go out through ISP1 (mark 1) unless you specify otherwise.
|
|
Then simply add these two rules as the first marking rules in your
|
|
<filename>/etc/shorewall/mangle</filename> (was tcrules) file:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST
|
|
MARK(1):P 0.0.0.0/0
|
|
MARK(1) $FW
|
|
<emphasis>other MARK rules</emphasis></programlisting>
|
|
|
|
<para>Now any traffic that isn't marked by one of your other MARK rules
|
|
will have mark = 1 and will be sent via ISP1. That will work whether
|
|
<emphasis role="bold">balance</emphasis> is specified or not!</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Using DNS Names</title>
|
|
|
|
<section id="faq79">
|
|
<title>(FAQ 79) Can I use DNS names in Shorewall configuration file
|
|
entries in place of IP addresses?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: <ulink
|
|
url="configuration_file_basics.htm#dnsnames">Yes</ulink>, but we advise
|
|
strongly against it.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="TC">
|
|
<title>Traffic Shaping</title>
|
|
|
|
<section id="faq67">
|
|
<title>(FAQ 67) I just configured Shorewall's builtin 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
|
|
We have an error talking to the kernel
|
|
ERROR: Command "tc filter add dev eth2 parent ffff: protocol ip prio
|
|
50 u32 match ip src 0.0.0.0/0 police rate 500kbit burst 10k drop flowid
|
|
:1" Failed</programlisting><emphasis
|
|
role="bold">Answer:</emphasis> This message indicates that your kernel
|
|
doesn't have 'traffic policing' support. If your kernel is modularized,
|
|
you may be able to resolve the problem by loading the <emphasis
|
|
role="bold">act_police</emphasis> kernel module. Other kernel modules
|
|
that you will need include:<simplelist>
|
|
<member>cls_basic</member>
|
|
|
|
<member>cls_fw</member>
|
|
|
|
<member>cls_u32</member>
|
|
|
|
<member>sch_htb</member>
|
|
|
|
<member>sch_ingress</member>
|
|
|
|
<member>sch_sfq</member>
|
|
</simplelist></para>
|
|
</section>
|
|
|
|
<section id="faq97">
|
|
<title>(FAQ 97) I enable Shorewall traffic shaping and now my upload
|
|
rate is way below what I specified</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: This is likely due to TCP
|
|
Segmentation Offload (TSO) and/or Generic Segmentation Offload (GSO)
|
|
being enabled in the network adapter. To verify, install the
|
|
<firstterm>ethtool</firstterm> package and use the -k command:</para>
|
|
|
|
<programlisting>root@gateway:~# ethtool -k eth1
|
|
Offload parameters for eth1:
|
|
rx-checksumming: on
|
|
tx-checksumming: on
|
|
scatter-gather: on
|
|
tcp-segmentation-offload: <emphasis role="bold">on</emphasis>
|
|
udp-fragmentation-offload: off
|
|
generic-segmentation-offload: <emphasis role="bold">on</emphasis>
|
|
generic-receive-offload: off
|
|
large-receive-offload: off
|
|
ntuple-filters: off
|
|
receive-hashing: off
|
|
root@gateway:~#</programlisting>
|
|
|
|
<para>If that is the case, you can correct the problem by adjusting the
|
|
<replaceable>minburst</replaceable> setting in
|
|
/etc/shorewall/tcinterfaces (simple traffic shaping) or
|
|
/etc/shorewall/tcdevices (complex traffic shaping). We suggest starting
|
|
at 10-12kb and adjust as necessary. Example (simple traffic
|
|
shaping):</para>
|
|
|
|
<programlisting>#INTERFACE TYPE IN_BANDWIDTH OUT_BANDWIDTH
|
|
eth0 External 50mbit:200kb 5.0mbit:100kb:200ms:100mbit:<emphasis
|
|
role="bold">10kb</emphasis>
|
|
</programlisting>
|
|
|
|
<para>Alternatively, you can turn off TSO and GSO using this command in
|
|
<filename>/etc/shorewall/init</filename>:</para>
|
|
|
|
<programlisting><emphasis role="bold">ethtool -K eth<emphasis>N</emphasis> tso off gso off</emphasis></programlisting>
|
|
</section>
|
|
|
|
<section>
|
|
<title>(FAQ 97a) I enable Shorewall traffic shaping and now my download
|
|
rate is way below what I specified</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: This is likely due to
|
|
Generic Receive Offload (GRO) being enabled in the network adapter. To
|
|
verify, install the <firstterm>ethtool</firstterm> package and use the
|
|
-k command:</para>
|
|
|
|
<programlisting>root@gateway:/etc/shorewall# ethtool -k eth1
|
|
Offload parameters for eth1:
|
|
rx-checksumming: on
|
|
tx-checksumming: on
|
|
scatter-gather: on
|
|
tcp-segmentation-offload: on
|
|
udp-fragmentation-offload: off
|
|
generic-segmentation-offload: on
|
|
generic-receive-offload: <emphasis role="bold">on</emphasis>
|
|
large-receive-offload: off
|
|
ntuple-filters: off
|
|
receive-hashing: off
|
|
root@gateway:/etc/shorewall#
|
|
</programlisting>
|
|
|
|
<para>To work around the issue, use this command:</para>
|
|
|
|
<programlisting><emphasis role="bold">ethtool -K eth</emphasis>N <emphasis
|
|
role="bold">gro off</emphasis></programlisting>
|
|
|
|
<para>Beginning with Shorewall 4.4.25, another option is available in
|
|
the form of a <firstterm>rate-estimated policing
|
|
filter</firstterm>.</para>
|
|
|
|
<para>Example from /etc/shorewall/tcdevices:</para>
|
|
|
|
<programlisting>#INTERFACE IN_BANDWITH OUT_BANDWIDTH OPTIONS
|
|
1:COMB_IF <emphasis role="bold">~20mbit:250ms:4sec</emphasis> ${UPLOAD}kbit hfsc,linklayer=ethernet,overhead=0</programlisting>
|
|
|
|
<para>To create a rate-estimated filter, precede the bandwidth with a
|
|
tilde ("~"). The optional interval and decay_interval determine how
|
|
often the rate is estimated and how many samples are retained for
|
|
estimating. Please see <ulink
|
|
url="http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt">http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt</ulink>
|
|
for details.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="About">
|
|
<title>About Shorewall</title>
|
|
|
|
<section id="faq10">
|
|
<title>(FAQ 10) What Distributions does Shorewall work with?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorewall works with any
|
|
GNU/Linux distribution that includes the <ulink
|
|
url="shorewall_prerequisites.htm">proper prerequisites</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq11">
|
|
<title>(FAQ 11) What Features does Shorewall have?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> See the <ulink
|
|
url="shorewall_features.htm">Shorewall Feature List</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq12">
|
|
<title>(FAQ 12) Is there a GUI?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Yes! Shorewall support is
|
|
available in Webmin. See <ulink
|
|
url="http://www.webmin.com">http://www.webmin.com</ulink>. But beware of
|
|
the issue described in <link linkend="faq36">FAQ 36</link>.</para>
|
|
</section>
|
|
|
|
<section id="faq13">
|
|
<title>(FAQ 13) Why do you call it <quote>Shorewall</quote>?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorewall is a
|
|
concatenation of <quote> <emphasis>Shore</emphasis>line</quote> (<ulink
|
|
url="http://www.cityofshoreline.com">the city where I live</ulink>) and
|
|
<quote>Fire<emphasis>wall</emphasis> </quote>. The full name of the
|
|
product is actually <quote>Shoreline Firewall</quote> but
|
|
<quote>Shorewall</quote> is much more commonly used.</para>
|
|
</section>
|
|
|
|
<section id="faq23">
|
|
<title>(FAQ 23) Why do you use such ugly fonts on your web site?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> The Shorewall web site is
|
|
almost font neutral (it doesn't explicitly specify fonts except on a few
|
|
pages) so the fonts you see are largely the default fonts configured in
|
|
your browser. If you don't like them then reconfigure your
|
|
browser.</para>
|
|
</section>
|
|
|
|
<section id="faq25">
|
|
<title>(FAQ 25) How do I tell which version of Shorewall or Shorewall
|
|
Lite I am running?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> At the shell prompt,
|
|
type:</para>
|
|
|
|
<programlisting><command>/sbin/shorewall[-lite] version -a</command> </programlisting>
|
|
|
|
<section id="faq25a">
|
|
<title>(FAQ 25a) It says 4.4.7.5; how do I know if it is
|
|
Shorewall-shell or Shorewall-perl?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: It is Shorewall-perl.
|
|
Shorewall-shell is discontinued in Shorewall 4.4.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq31">
|
|
<title>(FAQ 31) Does Shorewall provide protection against....</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>IP Spoofing: Sending packets over the WAN interface using an
|
|
internal LAP IP address as the source address?</term>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Answer:</emphasis> Yes.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Tear Drop: Sending packets that contain overlapping
|
|
fragments?</term>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Answer:</emphasis> This is the
|
|
responsibility of the IP stack, not the Netfilter-based firewall
|
|
since fragment reassembly occurs before the stateful packet filter
|
|
ever touches each packet.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Smurf and Fraggle: Sending packets that use the WAN or LAN
|
|
broadcast address as the source address?</term>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorwall filters
|
|
these packets under the <firstterm>nosmurfs</firstterm> interface
|
|
option in <ulink
|
|
url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Land Attack: Sending packets that use the same address as the
|
|
source and destination address?</term>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Answer:</emphasis> Yes, if the <ulink
|
|
url="manpages/shorewall-interfaces.html">routefilter interface
|
|
option</ulink> is selected.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>DOS: - SYN Dos - ICMP Dos - Per-host Dos protection</term>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Answer:</emphasis> Yes.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
|
|
<section id="faq65">
|
|
<title>(FAQ 65) How do I accomplish failover with Shorewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> <ulink
|
|
url="http://linuxman.wikispaces.com/Clustering+Shorewall">This article
|
|
by Paul Gear</ulink> should help you get started.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="ALIASES">
|
|
<title>Alias IP Addresses/Virtual Interfaces</title>
|
|
|
|
<section id="faq18">
|
|
<title>(FAQ 18) Is there any way to use aliased ip addresses with
|
|
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
|
|
Interfaces</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq83">
|
|
<title>(FAQ 83) Is there no way to nest the firewall zone or create
|
|
subzones? I've got a system with Linux-VServers, it's one interface
|
|
(eth0) with multiple IPs</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Beginning with Shorewall
|
|
4.4.11 Beta 2, you can <ulink url="Vserver.html">create vserver
|
|
zones</ulink> that are nested within the firewall zone.</para>
|
|
|
|
<para>Prior to 4.4.11 Beta 2, there is no way to create sub-zones of the
|
|
firewall zone. But you can use shell variables to make vservers easier
|
|
to deal with.</para>
|
|
|
|
<para><filename>/etc/shorewall/params</filename>:</para>
|
|
|
|
<programlisting>VS1=fw:192.168.2.12
|
|
VS2=fw:192.168.2.13
|
|
VS3=fw:192.168.2.14</programlisting>
|
|
|
|
<para><filename>/etc/shorewall/rules</filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
|
|
?SECTION ALL
|
|
?SECTION ESTABLISHED
|
|
?SECTION RELATED
|
|
?SECTION INVALID
|
|
?SECTION UNTRACKED
|
|
?SECTION NEW
|
|
|
|
ACCEPT $VS1 net tcp 25
|
|
DNAT net $VS1 tcp 25
|
|
etc...</programlisting>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Lite">
|
|
<title>Shorewall Lite</title>
|
|
|
|
<section id="faq53">
|
|
<title>(FAQ 53) What is Shorewall Lite?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorewall Lite is a
|
|
companion product to Shorewall and is designed to allow you to maintain
|
|
all Shorewall configuration information on a single system within your
|
|
network. See the <ulink url="Shorewall-Lite.html">Compiled Firewall
|
|
script documentation</ulink> for details.</para>
|
|
</section>
|
|
|
|
<section id="faq54">
|
|
<title>(FAQ 54) If I want to use Shorewall Lite, do I also need to
|
|
install Shorewall on the same system?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> No. In fact, we recommend
|
|
that you do <emphasis role="bold">NOT</emphasis> install Shorewall on
|
|
systems where you wish to use Shorewall Lite. You must have Shorewall
|
|
installed on at least one system within your network in order to use
|
|
Shorewall Lite.</para>
|
|
</section>
|
|
|
|
<section id="faq55">
|
|
<title>(FAQ 55) How do I decide which product to use - Shorewall or
|
|
Shorewall Lite?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> If you plan to have only
|
|
a single firewall system, then Shorewall is the logical choice. I also
|
|
think that Shorewall is the appropriate choice for laptop systems that
|
|
may need to have their firewall configuration changed while on the road.
|
|
In the remaining cases, Shorewall Lite will work very well. At
|
|
shorewall.net, the two laptop systems have the full Shorewall product
|
|
installed as does my personal Linux desktop system. All other Linux
|
|
systems that run a firewall use Shorewall Lite and have their
|
|
configuration directories on my desktop system.</para>
|
|
</section>
|
|
|
|
<section id="faq60">
|
|
<title>(FAQ 60) What are the compatibility restrictions between
|
|
Shorewall and Shorewall Lite</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> There are no
|
|
compatibility constraints between Shorewall and Shorewall-lite.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="VOIP">
|
|
<title>VOIP</title>
|
|
|
|
<section id="faq77">
|
|
<title>(FAQ 77) Shorewall is eating my Asterisk egress traffic!</title>
|
|
|
|
<para>Somehow, my firewall config is causing a one-way audio problem in
|
|
Asterisk. If a person calls into the PBX, they cannot hear me speaking,
|
|
but I can hear them. If I plug the Asterisk server directly into the
|
|
router, bypassing the firewall, the problem goes away.</para>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> There are two things to
|
|
try when VOIP problems are encountered. Both begin with executing two
|
|
<command>rmmod</command> commands.</para>
|
|
|
|
<para>If your kernel version is 2.6.20 or earlier:<programlisting>rmmod ip_nat_sip
|
|
rmmod ip_conntrack_sip</programlisting>If your kernel version is 2.6.21 or
|
|
later:<programlisting>rmmod nf_nat_sip
|
|
rmmod nf_conntrack_sip</programlisting></para>
|
|
|
|
<para>The first alternative seems to work for those running recent
|
|
kernels (2.6.26 or later):</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Copy <filename>/usr/share/shorewall/module</filename>s to
|
|
<filename class="directory">/etc/shorewall</filename>
|
|
(<filename>/usr/share/shorewall/helpers</filename> if you have
|
|
LOAD_HELPERS_ONLY in shorewall.conf).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Edit the copy and change this line:</para>
|
|
|
|
<blockquote>
|
|
<para>loadmodule nf_conntrack_sip</para>
|
|
</blockquote>
|
|
|
|
<para>to</para>
|
|
|
|
<blockquote>
|
|
<para>loadmodule nf_conntrack_sip sip_direct_media=0</para>
|
|
</blockquote>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>shorewall restart</command></para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>The second alternative is to not load the sip helpers:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If you are running kernel 2.6.20 or earlier, then change the
|
|
DONT_LOAD specification in your shorewall.conf to:<programlisting>DONT_LOAD=ip_nat_sip,ip_conntrack_sip</programlisting></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you are running kernel 2.6.21 or later, then change Then
|
|
change the DONT_LOAD specification in your shorewall.conf
|
|
to:<programlisting>DONT_LOAD=nf_nat_sip,nf_conntrack_sip</programlisting></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq40">
|
|
<title>IPv6</title>
|
|
|
|
<section id="faq80">
|
|
<title>(FAQ 80) Does Shorewall support IPV6?</title>
|
|
|
|
<para>Answer: <ulink url="IPv6Support.html">Shorewall IPv6
|
|
support</ulink> is currently available in Shorewall 4.2.4 and
|
|
later.</para>
|
|
|
|
<section id="faq80a">
|
|
<title>(FAQ 80a) Why does Shorewall lPv6 Support Require Kernel 2.6.24
|
|
or later?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorewall implements a
|
|
stateful firewall which requires connection tracking be present in
|
|
ip6tables and in the kernel. Linux kernels before 2.6.20 didn't
|
|
support connection tracking for IPv6. So we could not even start to
|
|
develop Shorewall IPv6 support until 2.6.20 and there were significant
|
|
problems with the facility until at least kernel 2.6.23. When
|
|
distributions began offering IPv6 connection tracking support, it was
|
|
with kernel 2.6.25. So that is what we developed IPv6 support on and
|
|
that's all that we initially tested on. Subsequently, we have tested
|
|
Shorewall6 on Ubuntu Hardy with kernel 2.6.24. If you are running
|
|
2.6.20 or later, you can <emphasis role="bold">try</emphasis> to run
|
|
Shorewall6 by hacking<filename>
|
|
/usr/share/shorewall/prog.footer6</filename> and changing the kernel
|
|
version test to check for your kernel version rather than 2.6.24
|
|
(20624). But after that, you are on your own.</para>
|
|
|
|
<programlisting>kernel=$(printf "%2d%02d%02d\n" $(echo $(uname -r) 2> /dev/null | sed 's/-.*//' | tr '.' ' ' ) | head -n1)
|
|
if [ $kernel -lt <emphasis role="bold">20624</emphasis> ]; then
|
|
error_message "ERROR: $PRODUCT requires Linux kernel <emphasis role="bold">2.6.24</emphasis> or later"
|
|
status=2
|
|
else
|
|
</programlisting>
|
|
|
|
<para>Update: The above logic is found in
|
|
<filename>/usr/share/shorewall/prog.footer</filename> in later
|
|
Shorewall releases.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section>
|
|
<title>(FAQ 40) I have an interface that gets its IPv6 configuration
|
|
from radvd. When I start Shorewall6, I immediately loose my default
|
|
route. Why?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: You have configured
|
|
forwarding on the interface which disables autoconfiguration of the
|
|
interface. To retain autoconfiguration on the interface when Shorewall6
|
|
starts, specify <emphasis role="bold">forwarding=0</emphasis> in the
|
|
OPTIONS column on the interface's entry in <ulink
|
|
url="manpages6/shorewall6-interfaces.html">shorewall6-interfaces</ulink>
|
|
(5).</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title id="faq96">(FAQ 96) I am starting to use ipv6, but on my ipv4 FW,
|
|
when restarting Shorewall . it puts in ip6tables rules. How do i
|
|
dissable that ?</title>
|
|
|
|
<para>Answer: This is a two-step process.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Set DISABLE_IPV6=No in <ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink> (5) and
|
|
restart Shorewall.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Execute these commands at a root shell prompt:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>ip6tables -P INPUT ACCEPT</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ip6tables -P OUTPUT ACCEPT</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ip6tables -P FORWARD ACCEPT</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>You will probably want to soon install <ulink
|
|
url="IPv6Support.html">Shorewall6</ulink> so that you have an IPv6
|
|
firewall as well as one for IPv4.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Wifidog</title>
|
|
|
|
<section>
|
|
<title id="faq105">(FAQ 105) Can Shorewall work with Wifidog?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Yes, with a couple of
|
|
restrictions:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Wifidog must be started after Shorewall. If Shorewall is
|
|
restarted/reloaded, then wifidog must be restarted.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>FORWARD_CLEAR_MARK must be set to <option>No</option> in
|
|
shorewall.conf.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Misc">
|
|
<title>Miscellaneous</title>
|
|
|
|
<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>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Yes. Consult the <ulink
|
|
url="shorewall_quickstart_guide.htm">QuickStart guide</ulink> that you
|
|
used during your initial setup for information about how to set up rules
|
|
for your server.</para>
|
|
</section>
|
|
|
|
<section id="faq24">
|
|
<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
|
|
host/subnet addresses as a comma-separated list.</para>
|
|
|
|
<programlisting>net:<ip1>,<ip2>,...</programlisting>
|
|
|
|
<example id="Example4">
|
|
<title>Example:</title>
|
|
|
|
<programlisting>ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22</programlisting>
|
|
</example>
|
|
</section>
|
|
|
|
<section id="faq26">
|
|
<title>(FAQ 26) When I try to use any of the SYN options in nmap on or
|
|
behind the firewall, I get <quote>operation not permitted</quote>. How
|
|
can I use nmap with Shorewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Temporarily remove any
|
|
<emphasis role="bold">rejNotSyn</emphasis>, <emphasis
|
|
role="bold">dropNotSyn</emphasis>, <emphasis
|
|
role="bold">dropInvalid</emphasis>, <emphasis
|
|
role="bold">NotSyn(...)</emphasis> and <emphasis
|
|
role="bold">Invalid(...)</emphasis> rules from
|
|
<filename>/etc/shorewall/rules</filename> and restart Shorewall.</para>
|
|
</section>
|
|
|
|
<section id="faq27">
|
|
<title>(FAQ 27) I'm compiling a new kernel for my firewall. What should
|
|
I look out for?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> First take a look at the
|
|
<ulink url="kernel.htm">Shorewall kernel configuration page</ulink>. You
|
|
probably also want to be sure that you have selected the <quote>
|
|
<emphasis role="bold">NAT of local connections (READ HELP)</emphasis>
|
|
</quote> on the Netfilter Configuration menu. Otherwise, DNAT rules with
|
|
your firewall as the source zone won't work with your new kernel.</para>
|
|
</section>
|
|
|
|
<section id="faq28">
|
|
<title>(FAQ 28) How do I use Shorewall as a Bridging Firewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Shorewall Bridging
|
|
Firewall support is available — <ulink
|
|
url="bridge-Shorewall-perl.html">check here for details</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq39">
|
|
<title>(FAQ 39) How do I block connections to a particular domain
|
|
name?</title>
|
|
|
|
<para>I tried this rule to block Google's Adsense that you'll find on
|
|
everyone's site. Adsense is a Javascript that people add to their Web
|
|
pages. So I entered the rule:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO
|
|
REJECT fw net:pagead2.googlesyndication.com all</programlisting>
|
|
|
|
<para>However, this also sometimes restricts access to "google.com". Why
|
|
is that? Using dig, I found these IPs for domain
|
|
googlesyndication.com:<programlisting>216.239.37.99
|
|
216.239.39.99</programlisting>And this for google.com:<programlisting>216.239.37.99
|
|
216.239.39.99
|
|
216.239.57.99</programlisting>So my guess is that you are not actually
|
|
blocking the domain, but rather the IP being called. So how in the world
|
|
do you block an actual domain name?</para>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Packet filters like
|
|
Netfilter base their decisions on the contents of the various protocol
|
|
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)
|
|
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
|
|
expressed in terms of those IP addresses. So the rule that you entered
|
|
was equivalent to:</para>
|
|
|
|
<para><programlisting>#ACTION SOURCE DEST PROTO
|
|
REJECT $FW net:216.239.37.99 all
|
|
REJECT $FW net:216.239.39.99 all</programlisting>Given
|
|
that name-based multiple hosting is a common practice (another example:
|
|
lists.shorewall.net and www1.shorewall.net are both hosted on the same
|
|
system with a single IP address), it is not possible to filter
|
|
connections to a particular name by examination of protocol headers
|
|
alone. While some protocols such as <ulink url="FTP.html">FTP</ulink>
|
|
require the firewall to examine and possibly modify packet payload,
|
|
parsing the payload of individual packets doesn't always work because
|
|
the application-level data stream can be split across packets in
|
|
arbitrary ways. This is one of the weaknesses of the 'string match'
|
|
Netfilter extension available in later Linux kernel releases. The only
|
|
sure way to filter on packet content is to proxy the connections in
|
|
question -- in the case of HTTP, this means running something like
|
|
<ulink url="Shorewall_Squid_Usage.html">Squid</ulink>. Proxying allows
|
|
the proxy process to assemble complete application-level messages which
|
|
can then be accurately parsed and decisions can be made based on the
|
|
result.</para>
|
|
</section>
|
|
|
|
<section id="faq42">
|
|
<title>(FAQ 42) How can I tell which features my kernel and iptables
|
|
support?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Use the
|
|
<command>shorewall[-lite] show capabilities</command> command at a root
|
|
prompt.</para>
|
|
|
|
<programlisting>gateway:~# <command>shorewall show capabilities</command>
|
|
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
|
|
Extended Connection Tracking Match Support: Available
|
|
Old Connection Tracking Match Syntax: Not available
|
|
Packet Type Match: Available
|
|
Policy Match: Available
|
|
Physdev Match: Available
|
|
Physdev-is-bridged Support: Available
|
|
Packet length Match: Available
|
|
IP range Match: Available
|
|
Recent Match: Available
|
|
Owner Match: Available
|
|
Ipset Match: Available
|
|
CONNMARK Target: Available
|
|
Extended CONNMARK Target: Available
|
|
Connmark Match: Available
|
|
Extended Connmark Match: Available
|
|
Raw Table: Available
|
|
IPP2P Match: Available
|
|
Old IPP2P Match Syntax: Not available
|
|
CLASSIFY Target: Available
|
|
Extended REJECT: Available
|
|
Repeat match: Available
|
|
MARK Target: Available
|
|
Extended MARK Target: Available
|
|
Mangle FORWARD Chain: Available
|
|
Comments: Available
|
|
Address Type Match: Available
|
|
TCPMSS Match: Available
|
|
Hashlimit Match: Available
|
|
Old Hashlimit Match: Not available
|
|
NFQUEUE Target: Available
|
|
Realm Match: Available
|
|
Helper Match: Available
|
|
Connlimit Match: Available
|
|
Time Match: Available
|
|
Goto Support: Available
|
|
LOGMARK Target: Available
|
|
IPMARK Target: Available
|
|
LOG Target: Available
|
|
Persistent SNAT: Available
|
|
gateway:~# </programlisting>
|
|
|
|
<para/>
|
|
</section>
|
|
|
|
<section id="faq19">
|
|
<title>(FAQ 19) How do I open the firewall for all traffic to/from the
|
|
LAN?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> Add these two
|
|
policies:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOGLEVEL LIMIT CONNLIMIT
|
|
$FW loc ACCEPT
|
|
loc $FW ACCEPT</programlisting>
|
|
|
|
<para>You should also delete any ACCEPT rules from $FW->loc and
|
|
loc->$FW since those rules are redundant with the above
|
|
policies.</para>
|
|
</section>
|
|
|
|
<section id="faq88">
|
|
<title>(FAQ 88) Can I run Snort with Shorewall?</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: Yes. In <emphasis>Network
|
|
Intrusion Detection System (NIDS) mode</emphasis>, Snort is libpcap
|
|
based (like tcpdump) so it doesn't interfere with Shorewall. We have had
|
|
reports that users have also been successful in using Snort in
|
|
<emphasis>inline</emphasis> more with Shorewall, but no HOWTO exists at
|
|
this time.</para>
|
|
</section>
|
|
|
|
<section id="faq89">
|
|
<title>(FAQ 89) How do I connect to the web server in my aDSL modem from
|
|
my local LAN?</title>
|
|
|
|
<para>Answer: Here's what I did:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>My local network is 172.20.1.0/24, so I set the IP address in
|
|
the modem to 172.20.1.2.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The IP address of my firewall's interface to the LAN is
|
|
172.20.1.254. The logical name of the DSL interface is EXT_IF and my
|
|
LAN interface is INT_IF.</para>
|
|
|
|
<para>I added the following two configuration entries:</para>
|
|
|
|
<para><filename>/etc/shorewall/masq:</filename></para>
|
|
|
|
<programlisting>#INTERFACE SOURCE ADDRESS
|
|
|
|
COMMENT DSL Modem
|
|
|
|
EXT_IF:172.20.1.2 0.0.0.0/0 172.20.1.254
|
|
</programlisting>
|
|
|
|
<para><filename>/etc/shorewall/proxyarp</filename>:</para>
|
|
|
|
<programlisting>#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
|
|
172.20.1.2 EXT_IF INT_IF no yes
|
|
</programlisting>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>If you can't change the IP address of your modem and its current
|
|
address isn't in your local network, then you need to change this
|
|
slightly; assuming that the modem IP address is 192.168.1.1:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Do not include an entry in
|
|
<filename>/etc/shorewall/proxyarp</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Add an IP address in 192.168.1.0/24 to your external interface
|
|
using your configuration's network management tools. For
|
|
Debian-based systems, that means adding this to the interface's
|
|
stanza in <filename>/etc/network/interfaces</filename>:</para>
|
|
|
|
<programlisting> post-up /sbin/ip addr add 192.168.1.254/24 dev <replaceable>external-interface</replaceable></programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Your entry in <filename>/etc/shorewall/masq</filename> would
|
|
then be:</para>
|
|
|
|
<programlisting>#INTERFACE SOURCE ADDRESS
|
|
|
|
COMMENT DSL Modem
|
|
|
|
EXT_IF:192.168.1.1 0.0.0.0/0 192.168.1.254
|
|
</programlisting>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title id="faq93">(FAQ 93) I'm not able to use Shorewall to manage a
|
|
bridge. I get the following error: ERROR: BRIDGING=Yes is not supported
|
|
by Shorewall 4.4.13.3.</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> If you want to apply
|
|
firewall rules to the traffic passing between bridge ports, see <ulink
|
|
url="bridge-Shorewall-perl.html">http://www.shorewall.net/bridge-Shorewall-perl.html</ulink>.
|
|
If you simply want to allow all traffic between ports, then see <ulink
|
|
url="SimpleBridge.html">http://www.shorewall.net/SimpleBridge.html</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="faq95">
|
|
<title>(FAQ 95) What is this $FW that I see in the configuration files
|
|
and documentation?</title>
|
|
|
|
<para><emphasis role="bold">Answer: FW</emphasis> is a <ulink
|
|
url="configuration_file_basics.htm#Variables">shell variable</ulink>
|
|
that expands to the name that you gave to the firewall zone in <ulink
|
|
url="manpages/shorewall-zones.html">shorewall-zones</ulink>(5). The
|
|
default name for the firewall zone is <emphasis
|
|
role="bold">fw</emphasis>:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS
|
|
|
|
<emphasis role="bold">fw</emphasis> firewall</programlisting>
|
|
|
|
<para>So, using the default or sample configurations, writing <emphasis
|
|
role="bold">$FW</emphasis> is the same as writing <emphasis
|
|
role="bold">fw</emphasis>. If you give the firewall zone a different
|
|
name, <emphasis role="bold">gate</emphasis> for example, then writing
|
|
<emphasis role="bold">$FW</emphasis> would be the same as writing
|
|
<emphasis role="bold">gate</emphasis>.</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS
|
|
|
|
<emphasis role="bold">gate</emphasis> firewall</programlisting>
|
|
|
|
<section id="faq95a">
|
|
<title>Why was that done?</title>
|
|
|
|
<para><emphasis role="bold">Answer:</emphasis> The firewall zone has
|
|
special semantics, so having a way to refer to it in a
|
|
configuration-independent way makes writing the documentation,
|
|
examples, macros, etc. easier.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="faq98">
|
|
<title>(FAQ 98) How do I Unsubscribe from the Mailing List</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: There are two
|
|
ways:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>On the web</para>
|
|
|
|
<para>Go to <ulink
|
|
url="https://lists.sourceforge.net/lists/listinfo/shorewall-users">https://lists.sourceforge.net/lists/listinfo/shorewall-users</ulink>.
|
|
At the bottom of the form is a section entitled "<emphasis
|
|
role="bold">Shorewall-users Subscribers</emphasis>". At the bottom
|
|
of that section find:</para>
|
|
|
|
<blockquote>
|
|
<para>"To <emphasis role="bold">unsubscribe</emphasis> from
|
|
Shorewall-users, get a password reminder, or change your
|
|
subscription options <emphasis role="bold">enter your subscription
|
|
email address</emphasis>:".</para>
|
|
</blockquote>
|
|
|
|
<para>Enter your email address in the box provided and click on the
|
|
"<emphasis role="bold"><ulink url="???">Unsubscribe or edit
|
|
options</ulink></emphasis>" button. That will take you to a second
|
|
form.</para>
|
|
|
|
<para>At the top of the second form is a box to <emphasis
|
|
role="bold">enter your password</emphasis> -- enter it there then
|
|
click the <emphasis role="bold">Unsubscribe</emphasis> button in the
|
|
center of the form. You will be unsubscribed.</para>
|
|
|
|
<para>If you <emphasis role="bold">don't remember your
|
|
password</emphasis>, click on the <emphasis
|
|
role="bold">Remind</emphasis> button at the bottom of the form and
|
|
your password will be emailed to you.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Via email using this link: <ulink
|
|
url="mailto:shorewall-users-request@lists.sourceforge.net?subject=unsubscribe">mailto:shorewall-users-request@lists.sourceforge.net?subject=unsubscribe</ulink>.
|
|
You will receive a confirmation email shortly; follow the
|
|
instructions in that email.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title id="faq102">(FAQ 102) What is 'qt'? I see it in some of the older
|
|
documentation.</title>
|
|
|
|
<para><emphasis role="bold">Answer</emphasis>: 'qt' stands for 'quiet';
|
|
qt() is a shell function that accepts a command with arguments as
|
|
parameters. It redirects both standard out and standard error to
|
|
/dev/null. It is defined in the Shorewall-core shell library
|
|
lib.common.</para>
|
|
</section>
|
|
</section>
|
|
</article>
|