diff --git a/Shorewall-docs/ProxyARP.xml b/Shorewall-docs/ProxyARP.xml new file mode 100644 index 000000000..0a5607cb9 --- /dev/null +++ b/Shorewall-docs/ProxyARP.xml @@ -0,0 +1,199 @@ + + +
+ + Proxy ARP + + + + Tom + + Eastep + + + + 2003-11-13 + + + 2001 + + 2002 + + 2003 + + Thomas M. Eastep + + + + 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 "GNU Free Documentation License". + + + + 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. + +
+ Example + + 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: + + + /etc/shorewall/proxyarp + + + + + ADDRESS + + INTERFACE + + EXTERNAL + + HAVEROUTE + + + + + + 130.252.100.18 + + eth1 + + eth0 + + no + + + + 130.252.100.19 + + eth1 + + eth0 + + no + + + +
+ + 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. + + + 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. + + + 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. + +
+ +
+ ARP cache + + 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: + + + + A reading of TCP/IP Illustrated, Vol 1 by + Stevens revealsCourtesy of Bradey Honsinger + 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 + + + + 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: + + 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. +
+
\ No newline at end of file