Proxy ARP – SPLAT
This guide explains the various parts involved in adding Proxy ARP`s to your SPLAT firewall. Along with showing you a number of pitfalls and goctha’s which hopefully will save you a lot of time and effort. This Proxy ARP guide has been based around SPLAT as this is the main Platform that people seem to have issues with in regards to Proxy ARP.
What is Proxy ARP
There are 2 ways to get a packet to a device you either route it to the device or you add a proxy ARP so that the network host answers to the ARP queries for the network address that it does not have configured on the receiving interface.
Proxy ARP on SPLAT
How to add Proxy ARP
In order to add a Proxy ARP to a SPLAT box you will need to create a file called $FWDIR/conf/local.arp within the CLI. In this file you will need to add the following,
[NAT IP] [MAC Address]
Once done, go into the Smart Dashboard and go to “Global Properties > NAT”.
Make sure that all the boxes under Automatic NAT and Manual NAT are ticked. But leave the “Translate on Client side left” boxes left as they were.
If these boxes aren’t ticked then for each Proxy ARP you add, you will need to add an additional route for each host. The route you will need to add will consist of,
/sbin/route add –host [NAT IP] gw [Real IP / Next Hop IP]
Once added use the ‘route –save’ command to commit the route so it survives any further reboots.Now reboot the firewall.
Once the firewall is back up, you will see that the Proxy ARP from the output of the command “fw ctl arp”, and the firewall will respond to any subsequent ARP requests for that IP (NAT) address.
If you need to add any further Proxy ARPs. Add the route (if using server side NAT), IP and MAC to the local.arp file and use the command,
/sbin/arp –s [NAT IP] [MAC Address] pub
This will prevent you from having to reboot the firewall each time you need to add a Proxy ARP.
Why do I have to add the route?
The route is required due to using Server Side NAT as the packet is NAT`d after it passes the Operating Systems routing table. In other words the outbound FW-1 Kernel NATs the packet rather than (in the case of client side NAT) the inbound Kernel.
If you have “Translate destination on Client Side” enabled. And have enabled “Allow bi-directional NAT” and then rebooted, you will not require to add a route for the pre-translated address.
I have found that the SPLAT device MUST be rebooted after enabling “Allow bi-directional NAT” for your traffic to work without a route.
In most cases you should be able to enable the Client Side NAT without it causing too many issues. But before doing so you must check your routing and Anti-Spoofing to ensure enabling this will not cause any issues to your network.
Gotcha’s
Removing a Node from a Cluster.
If you have detached a node from a cluster and have not disabled the nodes cluster membership in cpconfig, you may find that your Proxy ARP`s are shown in `fw ctl arp` but the firewall still doesn’t reply to the ARP requests. As mentioned, go into CPconfig and disable the cluster membership
Client Side NAT still requires a route
Though you have Client Side NAT enabled you may find that your traffic and Proxy ARP`s still require routes. You can see the Proxy ARP though from the `fw ctl arp` output. To resolve this, enable “Allow bi-directional NAT” and reboot the firewall.
IPSO to SPLAT migrations
You may find you convert all the Proxy ARPs and the routes then migrate over the SPLAT device but your traffic still fails to work. This can be down to the way in which IPSO (BSD) publishes its Proxy ARP`s. Due to it publishing them within its routing table this can result in IPSO not requiring routes for the pre-translated addresses, then causing a problem when changing operating systems.
With this you can either create your routes (from grepping the routing table for MAC addresses and then converting them into routes (the sed tool is great for this)) or use my last gotcha to enable Client Side and bi-dir NAT to eliminate the need for routes.
