Revision History
Revision 1.02003-06-15LA
first official release
Revision History
Revision 1.12003-06-19LA
minor format corrections
Revision History
Revision 1.22003-06-23LA
minor format corrections


This howto explains what Proxy-ARP is, when and where it should be used, and includes some sample configurations.

Table of Contents

When should I use proxy-arp?
Explanation of proxy-arp
How to setup the filtering/firewalling
The Routing Table
Finishing up the configuration


This How-To is intended for LEAF users that would like to use a service that is commonly referred to as a "transparent firewalling bridge" or specifically 'Proxy-ARP'. Proxy-ARP is generally used for servers in a protected subnet (DMZ) that need to use public ip addresses (in addition to the ip address of the router itself) and also make use of the firewalling capabilities of the router. It is not mandatory to use Proxy-ARP on a "DMZ" subnet, Proxy-ARP can be used between any number of interfaces. I would suggest against using public addresses on a LAN segment for work-stations where masquerading/NAT is generally the preferred choice.

Copyright and License

This document, PROXY-ARP HOWTO, is copyrighted (c) 2003 by Lynn Avants. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at


No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility.

All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.

Credits / Contributors

In this document, I have the pleasure of acknowledging:

  • Rick Onanian

  • Ray Olszewski

  • Matt Schalit

  • Charles Steinkuehler

  • Tom Eastep


Feedback is most certainly welcome for this document. Send your additions, comments and criticisms to the following email address : .

When should I use proxy-arp?

Proxy-ARP is generally used in much the same situations as Static NAT, but can be preferrable when NAT'ing of a service may cause problems or when the service itself MUST know/work from the public ip address. For the uninitiated, Static NAT (or SNAT) is a one-to-one mapping of a real internet-known ip address to a masqueraded private-class ip address as used by the actual server itself. Masquerading of ip addresses this way does not always work well with many applications or services. Proxy-ARP allows the use of the actual internet-known ip address on the protected side of the router, so masqerading is not used and all applications should work as expected. For services such as web, mail, and DNS on a topology that will use 3 or less DMZ (server) addresses, I would suggest using SNAT instead of Proxy-ARP since the filtering setup is generally less confusing. Users with a full subnet of ip addresses to run more servers and/or running services such as active-ftp, game-servers, or other non-standard services may find Proxy-ARP to be much easier to setup and run instead. An preferred system to use SNAT on would be a 2 or 3 ip address connection offered by many ISP's.

The largest apparent difference between 'true' bridging and proxy-arp is that bridging forwards all broadcast traffic across all interfaces. This cannot be done by any routing function, such as proxy-arp, and seperate broadcast domain is created for each interface. Any work-arounds that work with general routing for broadcast traffic will also work with proxy-arp such as adding WINS servers, dhrelay, or sometimes simply adding the ip address of the necessary server in the application configuration rather than relying on broadcast resolution.

A common use for proxy-arp is to avoid creating a seperate subnet with the required routing changes for use between different interfaces (both interfaces will work on a single subnet). On larger networks you may regularly need to split the ip addresses up into smaller subnets which commonly leads to 'lost' addresses due to the creation of these smaller subnets with each subnet using ip addresses for network and broadcast requirements. Use of proxy-arp can avoid the need to create these smaller subnets and conserve the available ip addresses in the process. My last reason is that it is simply easy to setup and can be used in most network topologies (WAN-LAN, LAN-LAN, WAN-DMZ, etc...).

Explanation of proxy-arp

The configuration and use of Proxy-ARP is really quite simple, but is generally found to be quite confusing because what is actually being done behind the scenes is not understood. "True" bridging is a OSI layer 2 (link layer, e.g., Ethernet) protocol that makes use of only the 'Address Routing Protocol' (ARP) that only uses MAC address resolution. Bridging does not look at ip addresses of the connecting machine or make use of routing tables and ip-filtering, thus making OSI layer 3 (network layer, e.g., IPv4 addresses) filtering impossible. Routing is done on the OSI layer 3 and makes use of routing tables and firewalling by use of ip addresses and routing tables setup on the machine. Proxy-ARP acts as if it is a consolidation of both features of bridging and routing whereas a client machine is bound to a designated ip address that is answered by one (or more) of the router's interfaces, but is done at OSI layer 3 so that filtering of the traffic on this ip address can be done by the router instead of being "blindly" passed through the router.

Proxy-ARP has been an available feature of Linux kernels since the 2.0.x series and is technically enabled by the kernel through a set of boolean files on the /proc file system located at '/proc/sys/net/ipv4/conf/<interface>/proxy_arp'. The boolean toggle (0|1) in this set of files "disables|enables" proxy-arp by interface. Rather than setting this option by hand editing, proxy-arp is generally enabled by the firewall/filtering program on the system. Arp-cache entries can also be manually set (persistent) by use of the 'arp' utility. Many firewall applications, such as Shorewall, make use of both 'arp' and the kernel proc files. All traffic filtering with proxy-arp must be configured with the firewall/filtering application that you are using.

A couple of things you will want to keep in mind is that:

  • Proxy-ARP is not bridging, so DO NOT CONFIGURE BRIDGE OPTIONS!!!

  • Proxy-ARP is a function of routing, so you MUST configure the interfaces as such.

  • Proxy-ARP ip addresses are not defined on the router with the ip address/netmask/etc...other than the necessary settings for the interfaces themselves.




Consider this example:
The use of the public subnet is "purely" for example use in this document.
Use the ip addresses/subnet assigned by your ISP instead!!!
Subnet (.16-.23)
Reserved Addresses in Subnet:
Network address
Broadcast address
Default gateway (ISP)

Picture of Example

Image of Example

Explanation of Example

From this example in a typical 3-interface DMZ setup we can see that we receive 6 ip addresses from our ISP in the block. The ip is the network address (not used by a machine) and the ip _must_ be used for the broadcast address of the block. The ISP will use the address for it's router (or default gateway for the network), so that leaves us with 4 usable ip addresses for our DMZ servers ( In the example I used the .18 address proxy-arp'ed on both the external and DMZ interfaces (eth0 and eth2), which has the effect of 'bridging' these interfaces. The DMZ machines now use ip addresses out of the rest of the public subnet pool allowed (.19-.22).

How to setup the filtering/firewalling

Proxy-ARP is set in a status file on the kernel's /proc file system for each interface, but most firewall applications have options to set the proxy-arp function. As the built-in firewall for Dachstein and the Bering/Shorewall combination are generally the most commonly used implementations for LEAF machines, I will cover the necessary configuration for these environments.

Dachstein Configuration

In Dachstein, you will need to edit the '/etc/network.conf' file. Under each interface you wish to Proxy-ARP, turn the '[interface]_PROXY_ARP' option to 'YES'.

Considering my previous example:


Routing controls which IP's the firewall thinks are connected to which interface. You can use the 'eth[X]_ROUTES' variable to control this in Dachstein. Considering the previous example:


Note that you can have more than one entry for the 'eth[X]_ROUTES'. For example, if you need to move one of the DMZ machines outside the firewall for testing, you could do the following, which routes the .19 machine outside the firewall:


Remember more specific routes take precedence over less specific routes, so the "host" routes to a single IP override the "default" route to the entire /29 network.

This will setup proxy-arp, but you still need to setup proper firewall rules. Dachstein is designed to allow creation of a Proxy-ARP based "DMZ" network for public server systems via the use of network.conf. A typical configuration for the above example would look like the following:




For this example, a web server is running on all DMZ machines, while .21 is also running a mail/pop server, and .22 is also running a domain server.


  • 'DMZ_NET' is typically your full external (public) subnet.

  • 'DMZ_EXT_ADDRS' *MUST* be configured with any IP's that are on the unprotected side of your firewall.

  • It is safe to allow a service such as 'www' to the entire network range (the first entry in DMZ_OPEN_DEST), as non-DMZ IP's (the gateway and firewall ip addresses in this example, specified by 'DMZ_EXT_ADDRS') are filtered prior to applying the 'DMZ_OPEN_DEST' accept rules.

  • Opening ports to the firewall's IP is done in the conventional manner, with the 'EXTERN_UDP_PORTS' and 'EXTERN_TCP_PORTS' variables and the 'EXTERN_UDP_PORT[n]' and 'EXTERN_TCP_PORT[n]' walk-lists. You can get more thorough information on doing this in the LEAF "Port-Forwarding with Dachstein" FAQ if needed.

Now save the file, backup the 'etc' package via the 'lrcfg' menu, and reload the networking with the command: 'svi network reload'. That should finish the necessary configuration for the firewall!

Bering using Shorewall Configuration

Using Bering with Shorewall, you will want to edit _either_ the '/etc/shorewall/interfaces' -OR- the '/etc/shorewall/proxyarp' file. Use the 'interfaces' method to proxy-arp an entire subnet, or use the 'proxyarp' file to allow single hosts (ip addresses)...... BUT DO NOT USE BOTH!!!

There are more details and explanations located at:

Considering my previous example: EXAMPLE-1 For a entire subnet use '/etc/shorewall/interfaces':

net 	eth0 	detect 	proxyarp,norfc1918,blacklist
loc 	eth1 	detect
dmz 	eth2 	detect 	proxyarp


EXAMPLE-2 For individual host/ip addresses use '/etc/shorewall/proxyarp':

 ADDRESS  	 INTERFACE  	 EXTERNAL  	HAVEROUTE 	eth2 	eth0 	No 	eth2 	eth0 	No 	eth2 	eth0 	No 	eth2 	eth0 	No

Now backup the 'shorewall' package and restart shorewall with the command: svi shorewall restart That should finish the necessary configuration for the firewall! Check the documentation for the necessary information to configure the filtering of the proxy-arp'ed traffic (

Other information on using proxy-arp with Shorewall can be found at:

The Routing Table

Verify that your routing table is correct. This is the routing table of my example:

# ip route show via dev eth0 dev eth1 proto kernel scope link src dev eth2 proto kernel scope link src
default via dev eth0

Finishing up the configuration

Now set up your client machines in the DMZ with the desired public ip addresses and everything *should* work. The possibility exists that you may need for the ISP's router to update it's ARP table to acknowledge the DMZ machines. You may be able to update the arp-cache with use of the 'arping' utility, or wait for the arp-cache to update itself (which may take an hour or longer). You may need to check with your ISP if the proxy-arp'ed addresses do not appear to be working to verify that the DMZ machines have been cached.

You may now setup any filtering for the proxy-arp'ed machines with your firewall application to allow/disallow traffic by ip address if you can access the proxy-arp'ed machines via the Internet.