2003-01-14 21:32:45 +01:00
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
2002-08-07 16:28:04 +02:00
|
|
|
|
<html>
|
|
|
|
|
|
<head>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<meta http-equiv="Content-Type"
|
|
|
|
|
|
content="text/html; charset=windows-1252">
|
|
|
|
|
|
<title>Shorewall Proxy ARP</title>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<meta name="Microsoft Theme" content="none">
|
2002-08-07 16:28:04 +02:00
|
|
|
|
</head>
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<body>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0"
|
|
|
|
|
|
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
|
2003-07-22 00:06:18 +02:00
|
|
|
|
bgcolor="#3366ff" height="90">
|
|
|
|
|
|
<tbody>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td width="100%">
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<h1 align="center"><font color="#ffffff">Proxy ARP</font></h1>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
|
|
|
|
|
|
</tbody>
|
2003-01-14 21:32:45 +01:00
|
|
|
|
</table>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<p>Proxy ARP allows you to insert a firewall in front of a set of servers
|
|
|
|
|
|
without changing their IP addresses and without having to re-subnet.
|
|
|
|
|
|
Before you try to use this technique, I strongly recommend that you read
|
2003-03-23 19:47:54 +01:00
|
|
|
|
the <a href="shorewall_setup_guide.htm">Shorewall Setup Guide.</a></p>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<p>The following figure represents a Proxy ARP environment.</p>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<p align="center"><strong> <img src="images/proxyarp.png"
|
|
|
|
|
|
width="519" height="397">
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</strong></p>
|
|
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<blockquote> </blockquote>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<p align="left">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.<2E> Assuming that the upper firewall interface is eth0 and the
|
|
|
|
|
|
lower interface is eth1, this is accomplished using the following entries
|
2003-03-23 19:47:54 +01:00
|
|
|
|
in /etc/shorewall/proxyarp:</p>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<tbody>
|
2003-03-23 19:47:54 +01:00
|
|
|
|
<tr>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<td><b>ADDRESS</b></td>
|
|
|
|
|
|
<td><b>INTERFACE</b></td>
|
|
|
|
|
|
<td><b>EXTERNAL</b></td>
|
|
|
|
|
|
<td><b>HAVEROUTE</b></td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>130.252.100.18</td>
|
|
|
|
|
|
<td>eth1</td>
|
|
|
|
|
|
<td>eth0</td>
|
|
|
|
|
|
<td>no</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>130.252.100.19</td>
|
|
|
|
|
|
<td>eth1</td>
|
|
|
|
|
|
<td>eth0</td>
|
|
|
|
|
|
<td>no</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
|
|
|
|
|
|
</tbody>
|
2003-01-14 21:32:45 +01:00
|
|
|
|
</table>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Be sure that the internal systems (130.242.100.18 and 130.252.100.19<EFBFBD>
|
|
|
|
|
|
in the above example) are not included in any specification in /etc/shorewall/masq
|
2003-03-08 16:48:57 +01:00
|
|
|
|
or /etc/shorewall/nat.</p>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<p>Note that I've used an RFC1918 IP address for eth1 - that IP address is
|
2003-03-23 19:47:54 +01:00
|
|
|
|
irrelevant. </p>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<p>The lower systems (130.252.100.18 and 130.252.100.19) 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
|
2003-03-23 19:47:54 +01:00
|
|
|
|
rather than behind it.<br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><font color="#ff0000"><b>NOTE: Do not add the Proxy ARP'ed address(es)
|
|
|
|
|
|
(130.252.100.18 and 130.252.100.19 in the above example)<29> to the external
|
2003-03-23 19:47:54 +01:00
|
|
|
|
interface (eth0 in this example) of the firewall.</b></font><br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</p>
|
|
|
|
|
|
|
2003-03-23 19:47:54 +01:00
|
|
|
|
<div align="left"> </div>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<p align="left">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 HOURS before that system can communicate with the internet.
|
2003-03-23 19:47:54 +01:00
|
|
|
|
There are a couple of things that you can try:<br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</p>
|
|
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<ol>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP
|
|
|
|
|
|
Illustrated, Vol 1</i> reveals that a <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
"gratuitous" 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...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
"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
|
2003-03-23 19:47:54 +01:00
|
|
|
|
cache for the old hardware address to update its ARP cache entry accordingly."<br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
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
|
|
|
|
|
|
static NAT for that matter). Happily enough, recent versions of Redhat's
|
2003-03-08 16:48:57 +01:00
|
|
|
|
iputils package include "arping", whose "-U" flag does just that:<br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
<20><><EFBFBD> <font color="#009900"><b>arping -U -I <i><net if> <newly
|
2003-03-23 19:47:54 +01:00
|
|
|
|
proxied IP></i></b></font><br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<20><><EFBFBD> <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for example</b></font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Stevens goes on to mention that not all systems respond correctly to
|
|
|
|
|
|
gratuitous ARPs, but googling for "arping -U" seems to support the idea
|
|
|
|
|
|
that it works most of the time.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To use arping with Proxy ARP in the above example, you would have to:<br>
|
2003-03-23 19:47:54 +01:00
|
|
|
|
<br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<font color="#009900"><b><EFBFBD> <20> shorewall clear<br>
|
|
|
|
|
|
</b></font><EFBFBD> <20> <font color="#009900"><b>ip addr add 130.252.100.18
|
2003-03-23 19:47:54 +01:00
|
|
|
|
dev eth0<br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<20> <20> ip addr add 130.252.100.19 dev eth0</b></font><br>
|
|
|
|
|
|
<20><><EFBFBD> <font color="#009900"><b>arping -U -I eth0 130.252.100.18</b></font><br>
|
|
|
|
|
|
<20> <20> <font color="#009900"><b>arping -U -I eth0 130.252.100.19</b></font><br>
|
|
|
|
|
|
<20> <20> <b><font color="#009900">ip addr del 130.252.100.18 dev eth0<br>
|
|
|
|
|
|
<20> <20> ip addr del 130.252.100.19 dev eth0<br>
|
|
|
|
|
|
<20> <20> shorewall start</font></b><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li>You can call your ISP and ask them to purge the stale ARP cache
|
2003-03-23 19:47:54 +01:00
|
|
|
|
entry but many either can't or won't purge individual entries.</li>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-01-14 21:32:45 +01:00
|
|
|
|
</ol>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
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
|
2003-03-23 19:47:54 +01:00
|
|
|
|
ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:</div>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<div align="left">
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we
|
2003-03-23 19:47:54 +01:00
|
|
|
|
will assume is 130.252.100.254):</p>
|
|
|
|
|
|
</div>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<pre> <b><font color="#009900">ping 130.252.100.254</font></b></pre>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div align="left">
|
2003-01-14 21:32:45 +01:00
|
|
|
|
<p align="left">We can now observe the tcpdump output:</p>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div align="left">
|
2003-03-08 16:48:57 +01:00
|
|
|
|
<pre> 13:35:12.159321 <u>0:4:e2:20:20:33</u> 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)<br> 13:35:12.207615 0:0:77:95:dd:19 <u>0:c0:a8:50:b2:57</u> ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply</pre>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<p align="left">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>
|
2003-03-23 19:47:54 +01:00
|
|
|
|
</div>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
|
2003-03-23 19:47:54 +01:00
|
|
|
|
<p><font size="2">Last updated 3/21/2003 - </font><font size="2"> <a
|
2003-01-14 21:32:45 +01:00
|
|
|
|
href="support.htm">Tom Eastep</a></font> </p>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<a href="copyright.htm"><font size="2">Copyright</font> <20> <font
|
2003-01-14 21:32:45 +01:00
|
|
|
|
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
|
2003-07-22 00:06:18 +02:00
|
|
|
|
<br>
|
2003-03-23 19:47:54 +01:00
|
|
|
|
<br>
|
|
|
|
|
|
<br>
|
2003-03-08 16:48:57 +01:00
|
|
|
|
<br>
|
2003-01-14 21:32:45 +01:00
|
|
|
|
</body>
|
|
|
|
|
|
</html>
|
