<!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>Proxy ARP</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="ProxyARP"></a>Proxy ARP</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-2006 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="#Example">Example</a></span></dt><dt><span class="section"><a href="#ARP">ARP cache</a></span></dt></dl></div><p>Proxy ARP (RFC 1027) is a way to make a machine physically located on
one network appear to be logically part of a different physical network
connected to the same router/firewall. Typically it allows us to hide a
machine with a public IP address on a private network behind a router, and
still have the machine appear to be on the public network "in front of" the
router. The router "proxys" ARP requests and all network traffic to and from
the hidden machine to make this fiction possible.</p><p>Consider a router with two interface cards, one connected to a public
network PUBNET and one connected to a private network PRIVNET. We want to
hide a server machine on the PRIVNET network but have it accessible from the
PUBNET network. The IP address of the server machine lies in the PUBNET
network, even though we are placing the machine on the PRIVNET network
behind the router.</p><p>By enabling proxy ARP on the router, any machine on the PUBNET network
that issues an ARP "who has" request for the server's MAC address will get a
proxy ARP reply from the router containing the router's MAC address. This
tells machines on the PUBNET network that they should be sending packets
destined for the server via the router. The router forwards the packets from
the machines on the PUBNET network to the server on the PRIVNET
network.</p><p>Similarly, when the server on the PRIVNET network issues a "who has"
request for any machines on the PUBNET network, the router provides its own
MAC address via proxy ARP. This tells the server to send packets for
machines on the PUBNET network via the router. The router forwards the
packets from the server on the PRIVNET network to the machines on the PUBNET
network.</p><p>The proxy ARP provided by the router allows the server on the
PRIVNETnetwork to appear to be on the PUBNET network. It lets the router
pass ARP requests and other network packets in both directions between the
server machine and the PUBNET network, making the server machine appear to
be connected to the PUBNET network even though it is on the PRIVNET network
hidden behind the router.</p><p>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><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Example"></a>Example</h2></div></div></div><p>The following figure represents a Proxy ARP environment.</p><div align="center"><img src="images/proxyarp.png" align="middle" /></div><p>Proxy ARP can be used to make the systems with addresses
130.252.100.18 and 130.252.100.19 appear to be on the upper
(130.252.100.*) subnet. Assuming that the upper firewall interface is eth0
and the lower interface is eth1, this is accomplished using the following
entries in <code class="filename">/etc/shorewall/proxyarp</code>:</p><pre class="programlisting">#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
130.252.100.18 eth1 eth0 no yes
130.252.100.19 eth1 eth0 no yes </pre><p><span class="bold"><strong>Be sure that the internal systems
(130.242.100.18 and 130.252.100.19 in the above example) are not included
in any specification in <code class="filename">/etc/shorewall/masq</code> or
<code class="filename">/etc/shorewall/nat</code>.</strong></span></p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>I've used an RFC1918 IP address for eth1 - that IP address is
largely irrelevant (see below).</p></div><p>The lower systems (130.252.100.18 and 130.252.100.19) <span class="bold"><strong>should have their subnet mask and default gateway configured
exactly the same way that the Firewall system's eth0 is configured. In
other words, they should be configured just like they would be if they
were parallel to the firewall rather than behind it.</strong></span></p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Do not add the Proxy ARP'ed address(es) (130.252.100.18 and
130.252.100.19 in the above example) to the external interface (eth0 in
this example) of the firewall.</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>It should be stressed that entries in the proxyarp 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></div><p>While the address given to the firewall interface is largely
irrelevant, one approach you can take is to make that address the same as
the address of your external interface!</p><div align="center"><img src="images/proxyarp1.png" align="middle" /></div><p>In the diagram above, <code class="filename">eth1</code>
has been given the address 130.252.100.17, the same as
<code class="filename">eth0</code>. Note though that the VLSM is 32 so there is no
network associated with this address. This is the approach <a class="ulink" href="XenMyWay.html" target="_self">that I take with my DMZ</a>.</p><p>To permit Internet hosts to connect to the local systems, you use
ACCEPT rules. For example, if you run a web server on 130.252.100.19 which
you have configured to be in the <span class="bold"><strong>loc</strong></span> zone
then you would need this entry in /etc/shorewall/rules:</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST
# PORT
ACCEPT net loc:130.252.100.19 tcp 80</pre><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Your distribution's network configuration GUI may not be capable
of configuring a device in this way. It may complain about the duplicate
address or it may configure the address incorrectly. Here is what the
above configuration should look like when viewed using
<span class="command"><strong>ip</strong></span> (the line "inet 130.252.100.17/32 scope global
eth1" is the most important):</p><pre class="programlisting">gateway:~# <span class="command"><strong>ip addr ls eth1</strong></span>
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:a0:cc:d1:db:12 brd ff:ff:ff:ff:ff:ff
<span class="bold"><strong>inet 130.252.100.17/32 scope global eth1</strong></span>
gateway:~#</pre><p>Note in particular that there is no broadcast address. Here is an
<code class="filename">ifcfg-eth-id-00:a0:cc:d1:db:12</code> file from SUSE that
produces this result (Note: SUSE ties the configuration file to the card
by embedding the card's MAC address in the file name):</p><pre class="programlisting">BOOTPROTO='static'
BROADCAST='130.252.100.17'
IPADDR='130.252.100.17'
MTU=''
NETMASK='255.255.255.255'
NETWORK='130.252.100.17'
REMOTE_IPADDR=''
STARTMODE='onboot'
UNIQUE='8otl.IPwRm6bNMRD'
_nm_name='bus-pci-0000:00:04.0'</pre><p>Here is an excerpt from a Debian /etc/network/interfaces file that
does the same thing:</p><pre class="programlisting">...
auto eth1
iface eth1 inet static
address 130.252.100.17
netmask 255.255.255.255
broadcast 0.0.0.0
...</pre></div></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 Proxy ARP, it will probably
be <span class="bold"><strong>HOURS</strong></span> 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 130.252.100.19, 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 <span class="bold"><strong>0:4:e2:20:20:33</strong></span> 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 <span class="bold"><strong>0:c0:a8:50:b2:57 </strong></span>ip 98: 130.252.100.254 > 130.252.100.19 : 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 left. 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="id257557" href="#ftn.id257557" 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
proxy ARP (or one-to-one NAT 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 Proxy ARP in the above example, you would
have to:</p><pre class="programlisting">shorewall clear
ip addr add 130.252.100.18 dev eth0
ip addr add 130.252.100.19 dev eth0
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
ip addr del 130.252.100.19 dev eth0
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.id257557" href="#id257557" class="para">1</a>] </sup>Courtesy of Bradey Honsinger</p></div></div></div></body></html>
