2002-08-13 22:45:21 +02:00
|
|
|
|
<html>
|
|
|
|
|
|
|
|
|
|
|
|
<head>
|
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|
|
|
|
|
<title>Shorewall Proxy ARP</title>
|
|
|
|
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
|
|
|
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
2002-08-22 23:21:41 +02:00
|
|
|
|
<meta name="Microsoft Theme" content="none">
|
2002-08-13 22:45:21 +02:00
|
|
|
|
</head>
|
|
|
|
|
|
|
|
|
|
|
|
<body>
|
|
|
|
|
|
|
2002-08-22 23:21:41 +02:00
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td width="100%">
|
|
|
|
|
|
<h1 align="center"><font color="#FFFFFF">Proxy ARP</font></h1>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
</table>
|
2002-08-13 22:45:21 +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.</p>
|
|
|
|
|
|
<p>The following figure represents a Proxy ARP
|
|
|
|
|
|
environment.</p>
|
2002-08-22 23:21:41 +02:00
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<p align="center"><strong>
|
2002-08-22 23:21:41 +02:00
|
|
|
|
<img src="images/proxyarp.png" width="519" height="397"></strong></p>
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<blockquote>
|
|
|
|
|
|
</blockquote>
|
2002-08-22 23:21:41 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<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. Assuming that the upper firewall interface is eth0 and the
|
|
|
|
|
|
lower interface is eth1, this is accomplished using the following entries in
|
|
|
|
|
|
/etc/shorewall/proxyarp:</p>
|
2002-08-22 23:21:41 +02:00
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<table border="2" cellpadding="2" style="border-collapse: collapse">
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<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>
|
|
|
|
|
|
</table>
|
2002-08-22 23:21:41 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<p>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
|
|
|
|
|
|
/etc/shorewall/masq or /etc/shorewall/nat.</p>
|
|
|
|
|
|
<p>Note that I've used an RFC1918 IP address for eth1 - that IP address is
|
|
|
|
|
|
irrelevant. </p>
|
|
|
|
|
|
<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.</p>
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<p align="left">A word of warning is in order here. ISPs typically configure
|
2002-08-22 23:21:41 +02:00
|
|
|
|
their routers with a long ARP cache timeout. If you move a system from
|
2002-08-13 22:45:21 +02:00
|
|
|
|
parallel to your firewall to behind your firewall with Proxy ARP, it will
|
|
|
|
|
|
probably be HOURS before that system can communicate with the internet. 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. 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:</div>
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<pre> tcpdump -nei eth0 icmp</pre>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we will
|
|
|
|
|
|
assume is 130.252.100.254):</div>
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<pre> ping 130.252.100.254</pre>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<p align="left">We can now observe the tcpdump output:</div>
|
|
|
|
|
|
<div align="left">
|
|
|
|
|
|
<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)
|
|
|
|
|
|
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>
|
|
|
|
|
|
</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.</div>
|
|
|
|
|
|
|
2002-08-22 23:21:41 +02:00
|
|
|
|
<p><font size="2">Last updated 8/17/2002 - </font><font size="2">
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<a href="support.htm">Tom
|
|
|
|
|
|
Eastep</a></font> </p>
|
|
|
|
|
|
<font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
|
|
|
|
|
|
<EFBFBD> <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></body></html>
|
