diff --git a/Shorewall-docs/ProxyARP.htm b/Shorewall-docs/ProxyARP.htm deleted file mode 100644 index 69828a93a..000000000 --- a/Shorewall-docs/ProxyARP.htm +++ /dev/null @@ -1,165 +0,0 @@ - - - - - Shorewall Proxy ARP - - - - - -

Proxy ARP
-

-

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 the Shorewall Setup -Guide.

-

The following figure represents a Proxy ARP environment.

-
-

-
-
-

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:

-
- - - - - - - - - - - - - - - - - - - - - -
ADDRESSINTERFACEEXTERNALHAVEROUTE
130.252.100.18eth1eth0no
130.252.100.19eth1eth0no
-
-

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.

-

Note that I've used an RFC1918 IP address for eth1 - that IP address -is irrelevant.

-

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 rather than behind it.
-

-

NOTE: 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.
-

-
-
-

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. There are a couple of things that you can try:
-

-
    -
  1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP -Illustrated, Vol 1 reveals that a
    -
    -"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...
    -
    -"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."
    -
    -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 "arping", whose "-U" flag does just -that:
    -
    -    arping -U -I <net -if> <newly proxied IP>
    -    arping -U -I eth0 -66.58.99.83 # for example
    -
    -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.
    -
    -To use arping with Proxy ARP in the above example, you would have to:
    -
    -     shorewall clear
    -         ip addr add -130.252.100.18 dev eth0
    -    ip addr add 130.252.100.19 dev eth0
    -    arping -U -I eth0 -130.252.100.18
    -    arping -U -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
    -
    -
    2. -
  2. 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.
    3. -
-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:
-
-
	tcpdump -nei eth0 icmp
-
-
-

Now from 130.252.100.19, ping the ISP's gateway (which -we will assume is 130.252.100.254):

-
-
-
	ping 130.252.100.254
-
-
-

We can now observe the tcpdump output:

-
-
-
	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
-
-
-

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.

-
-

Last updated 11/13/2003 - Tom Eastep

-Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
- -