<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>One-to-one NAT</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="NAT"></a>One-to-one NAT</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><a id="id290337"></a><p>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
“<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#One-to-one">One-to-one NAT</a></span></dt><dt><span class="section"><a href="#ARP">ARP cache</a></span></dt></dl></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span class="bold"><strong>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.</strong></span></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="One-to-one"></a>One-to-one NAT</h2></div></div></div><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p><span class="bold"><strong>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 <a class="ulink" href="manpages/shorewall-rules.html" target="_self">rules file</a>.</strong></span></p></div><p>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 <a class="ulink" href="shorewall_setup_guide.htm" target="_self">Shorewall Setup Guide</a>.</p><p>The following figure represents a one-to-one NAT environment.</p><div><img src="images/staticnat.png" /></div><p>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
<code class="filename">/etc/shorewall/nat</code> 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 <code class="filename">/etc/shorewall/nat</code> 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.</p><p><code class="filename">/etc/shorewall/nat</code></p><pre class="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</pre><p>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
<code class="filename">/etc/shorewall/masq</code> or
<code class="filename">/etc/shorewall/proxyarp</code>.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The “<span class="quote">ALL INTERFACES</span>” 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,
“<span class="quote">No</span>” is assumed . <span class="bold"><strong>Specifying
“<span class="quote">Yes</span>” in this column will not by itself allow systems on
the lower LAN to access each other using their public IP
addresses.</strong></span> 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. <a class="ulink" href="FAQ.htm#faq2a" target="_self">See FAQ 2a</a>.</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Shorewall will automatically add the external address to the
specified interface unless you specify <a class="ulink" href="manpages/shorewall.conf.html" target="_self">ADD_IP_ALIASES</a>=“<span class="quote">no</span>”
(or “<span class="quote">No</span>”) in
<code class="filename">/etc/shorewall/shorewall.conf</code>; If you do not set
ADD_IP_ALIASES or if you set it to “<span class="quote">Yes</span>” or
“<span class="quote">yes</span>” then you must NOT configure your own
alias(es).</p><p></p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The contents of the “<span class="quote">LOCAL</span>” 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
“<span class="quote">yes</span>” or “<span class="quote">Yes</span>” (and the ALL INTERFACES COLUMN
also contains “<span class="quote">Yes</span>” or “<span class="quote">yes</span>”) 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.</p></div><p>Entries in <code class="filename">/etc/shorewall/nat</code> 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
<code class="filename">/etc/shorewall/rules</code>:</p><pre class="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</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ARP"></a>ARP cache</h2></div></div></div><p>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.</p><p>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.</p><p>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:</p><pre class="programlisting">tcpdump -nei eth0 icmp</pre><p>Now from 10.1.1.3, ping the ISP's gateway (which we will assume is
130.252.100.254):</p><pre class="programlisting">ping 130.252.100.254</pre><p>We can now observe the tcpdump output:</p><pre class="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</pre><p>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.</p><p>If you have this problem, there are a couple of things that you can
try:</p><div class="orderedlist"><ol type="1"><li><p>A reading of <em class="citetitle">TCP/IP Illustrated, Vol 1</em> by
Stevens reveals<sup>[<a id="id258341" href="#ftn.id258341" class="footnote">1</a>]</sup> that a “<span class="quote">gratuitous</span>” 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...</p><div class="blockquote"><blockquote class="blockquote"><p>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.</p></blockquote></div><p>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 “<span class="quote">arping</span>”,
whose “<span class="quote">-U</span>” flag does just that:</p><pre class="programlisting">arping -U -I <<span class="emphasis"><em>net if</em></span>> <<span class="emphasis"><em>newly proxied IP</em></span>>
arping -U -I eth0 66.58.99.83 # for example</pre><p>Stevens goes on to mention that not all systems respond
correctly to gratuitous ARPs, but googling for “<span class="quote">arping
-U</span>” seems to support the idea that it works most of the
time.</p><p>To use arping with one-to-one NAT in the above example, you
would have to:</p><pre class="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</pre></li><li><p>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.</p></li></ol></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>There are two distinct versions of <span class="command"><strong>arping</strong></span>
available:</p><div class="orderedlist"><ol type="1"><li><p><span class="command"><strong>arping</strong></span> by Thomas Habets (Debian package
<span class="emphasis"><em>arping</em></span>).</p></li><li><p><span class="command"><strong>arping</strong></span> as part of the iputils package by
Alexey Kuznetsov (Debian package
<span class="emphasis"><em>iputils-arping</em></span>).</p></li></ol></div><p>You want the second one by Alexey Kuznetsov.</p></div></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id258341" href="#id258341" class="para">1</a>] </sup>Courtesy of Bradey Honsinger</p></div></div></div></body></html>
