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.