mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-23 08:03:11 +01:00
4a10f31d7f
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@8609 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
245 lines
11 KiB
XML
245 lines
11 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="NAT">
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>One-to-one NAT</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2001-2004</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 3.0 and
|
|
later. If you are running a version of Shorewall earlier than Shorewall
|
|
3.0.0 then please see the documentation for that
|
|
release.</emphasis></para>
|
|
</caution>
|
|
|
|
<section id="One-to-one">
|
|
<title>One-to-one NAT</title>
|
|
|
|
<important>
|
|
<para><emphasis role="bold">If all you want to do is forward ports to
|
|
servers behind your firewall, you do NOT want to use one-to-one NAT.
|
|
Port forwarding can be accomplished with simple entries in the <ulink
|
|
url="manpages/shorewall-rules.html">rules file</ulink>.</emphasis></para>
|
|
</important>
|
|
|
|
<para>One-to-one NAT is a way to make systems behind a firewall and
|
|
configured with private IP addresses (those reserved for private use in
|
|
RFC 1918) appear to have public IP addresses. Before you try to use this
|
|
technique, I strongly recommend that you read the <ulink
|
|
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink>.</para>
|
|
|
|
<para>The following figure represents a one-to-one NAT environment.</para>
|
|
|
|
<graphic fileref="images/staticnat.png" />
|
|
|
|
<para>One-to-one NAT can be used to make the systems with the 10.1.1.*
|
|
addresses appear to be on the upper (130.252.100.*) subnet. If we assume
|
|
that the interface to the upper subnet is eth0, then the following
|
|
<filename>/etc/shorewall/nat</filename> file would make the lower
|
|
left-hand system appear to have IP address 130.252.100.18 and the
|
|
right-hand one to have IP address 130.252.100.19. It should be stressed
|
|
that these entries in the <filename>/etc/shorewall/nat</filename> file do
|
|
not automatically enable traffic between the external network and the
|
|
internal host(s) — such traffic is still subject to your policies and
|
|
rules.</para>
|
|
|
|
<para><filename>/etc/shorewall/nat</filename><programlisting>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
|
|
130.252.100.18 eth0 10.1.1.2 no no
|
|
130.252.100.19 eth0 10.1.1.3 no no</programlisting></para>
|
|
|
|
<para>Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the
|
|
above example) is (are) not included in any specification in
|
|
<filename>/etc/shorewall/masq</filename> or
|
|
<filename>/etc/shorewall/proxyarp</filename>.</para>
|
|
|
|
<note>
|
|
<para>The <quote>ALL INTERFACES</quote> column is used to specify
|
|
whether access to the external IP from all firewall interfaces should
|
|
undergo NAT (Yes or yes) or if only access from the interface in the
|
|
INTERFACE column should undergo NAT. If you leave this column empty,
|
|
<quote>No</quote> is assumed . <emphasis role="bold">Specifying
|
|
<quote>Yes</quote> in this column will not by itself allow systems on
|
|
the lower LAN to access each other using their public IP
|
|
addresses.</emphasis> For example, the lower left-hand system (10.1.1.2)
|
|
cannot connect to 130.252.100.19 and expect to be connected to the lower
|
|
right-hand system. <ulink url="FAQ.htm#faq2a">See FAQ 2a</ulink>.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>Shorewall will automatically add the external address to the
|
|
specified interface unless you specify <ulink
|
|
url="manpages/shorewall.conf.html">ADD_IP_ALIASES</ulink>=<quote>no</quote>
|
|
(or <quote>No</quote>) in
|
|
<filename>/etc/shorewall/shorewall.conf</filename>; If you do not set
|
|
ADD_IP_ALIASES or if you set it to <quote>Yes</quote> or
|
|
<quote>yes</quote> then you must NOT configure your own
|
|
alias(es).</para>
|
|
|
|
<para></para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>The contents of the <quote>LOCAL</quote> column determine whether
|
|
packets originating on the firewall itself and destined for the EXTERNAL
|
|
address are redirected to the internal ADDRESS. If this column contains
|
|
<quote>yes</quote> or <quote>Yes</quote> (and the ALL INTERFACES COLUMN
|
|
also contains <quote>Yes</quote> or <quote>yes</quote>) then such
|
|
packets are redirected; otherwise, such packets are not redirected. This
|
|
feature requires kernel 2.4.19 or later and iptables 1.2.6a or later and
|
|
you must have enabled CONFIG_IP_NF_NAT_LOCAL in your kernel.</para>
|
|
</note>
|
|
|
|
<para>Entries in <filename>/etc/shorewall/nat</filename> only arrange for
|
|
address translation; they do not allow traffic to pass through the
|
|
firewall in violation of your policies. In the above example, suppose that
|
|
you wish to run a web server on 10.1.1.2 (a.k.a. 130.252.100.18). You
|
|
would need the following entry in
|
|
<filename>/etc/shorewall/rules</filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST SOURCE ORIG
|
|
# PORT(S) PORT(S) DEST
|
|
ACCEPT net loc:10.1.1.2 tcp 80 - 130.252.100.18</programlisting>
|
|
</section>
|
|
|
|
<section id="ARP">
|
|
<title>ARP cache</title>
|
|
|
|
<para>A word of warning is in order here. ISPs typically configure their
|
|
routers with a long ARP cache timeout. If you move a system from parallel
|
|
to your firewall to behind your firewall with one-to-one NAT, it will
|
|
probably be HOURS before that system can communicate with the
|
|
internet.</para>
|
|
|
|
<para>If you sniff traffic on the firewall's external interface, you can
|
|
see incoming traffic for the internal system(s) but the traffic is never
|
|
sent out the internal interface.</para>
|
|
|
|
<para>You can determine if your ISP's gateway ARP cache is stale using
|
|
ping and tcpdump. Suppose that we suspect that the gateway router has a
|
|
stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as
|
|
follows:</para>
|
|
|
|
<programlisting>tcpdump -nei eth0 icmp</programlisting>
|
|
|
|
<para>Now from 10.1.1.3, ping the ISP's gateway (which we will assume is
|
|
130.252.100.254):</para>
|
|
|
|
<programlisting>ping 130.252.100.254</programlisting>
|
|
|
|
<para>We can now observe the tcpdump output:</para>
|
|
|
|
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
|
|
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply</programlisting>
|
|
|
|
<para>Notice that the source MAC address in the echo request is different
|
|
from the destination MAC address in the echo reply!! In this case
|
|
0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
|
|
0:c0:a8:50:b2:57 was the MAC address of the system on the lower right. In
|
|
other words, the gateway's ARP cache still associates 130.252.100.19 with
|
|
the NIC in that system rather than with the firewall's eth0.</para>
|
|
|
|
<para>If you have this problem, there are a couple of things that you can
|
|
try:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>A reading of <citetitle>TCP/IP Illustrated, Vol 1</citetitle> by
|
|
Stevens reveals<footnote>
|
|
<para>Courtesy of Bradey Honsinger</para>
|
|
</footnote> that a <quote>gratuitous</quote> ARP packet should cause
|
|
the ISP's router to refresh their ARP cache (section 4.7). A
|
|
gratuitous ARP is simply a host requesting the MAC address for its own
|
|
IP; in addition to ensuring that the IP address isn't a
|
|
duplicate...</para>
|
|
|
|
<blockquote>
|
|
<para>if the host sending the gratuitous ARP has just changed its
|
|
hardware address..., this packet causes any other host...that has an
|
|
entry in its cache for the old hardware address to update its ARP
|
|
cache entry accordingly.</para>
|
|
</blockquote>
|
|
|
|
<para>Which is, of course, exactly what you want to do when you switch
|
|
a host from being exposed to the Internet to behind Shorewall using
|
|
one-to-one NAT (or Proxy ARP for that matter). Happily enough, recent
|
|
versions of Redhat's iputils package include <quote>arping</quote>,
|
|
whose <quote>-U</quote> flag does just that:</para>
|
|
|
|
<programlisting>arping -U -I <<emphasis>net if</emphasis>> <<emphasis>newly proxied IP</emphasis>>
|
|
arping -U -I eth0 66.58.99.83 # for example</programlisting>
|
|
|
|
<para>Stevens goes on to mention that not all systems respond
|
|
correctly to gratuitous ARPs, but googling for <quote>arping
|
|
-U</quote> seems to support the idea that it works most of the
|
|
time.</para>
|
|
|
|
<para>To use arping with one-to-one NAT in the above example, you
|
|
would have to:</para>
|
|
|
|
<programlisting>shorewall clear
|
|
ip addr add 130.252.100.18 dev eth0 # You need to add the addresses only if Shorewall clear
|
|
ip addr add 130.252.100.19 dev eth0 # deletes them
|
|
arping -U -c 10 -I eth0 130.252.100.18
|
|
arping -U -c 10 -I eth0 130.252.100.19
|
|
ip addr del 130.252.100.18 dev eth0 # You need to delete the addresses only if you added
|
|
ip addr del 130.252.100.19 dev eth0 # them above
|
|
shorewall start</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You can call your ISP and ask them to purge the stale ARP cache
|
|
entry but many either can't or won't purge individual entries.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<warning>
|
|
<para>There are two distinct versions of <command>arping</command>
|
|
available:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para><command>arping</command> by Thomas Habets (Debian package
|
|
<emphasis>arping</emphasis>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>arping</command> as part of the iputils package by
|
|
Alexey Kuznetsov (Debian package
|
|
<emphasis>iputils-arping</emphasis>).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>You want the second one by Alexey Kuznetsov.</para>
|
|
</warning>
|
|
</section>
|
|
</article>
|