Gratuitous / Proxy ARP in Failover

[Haecker]

Hi,

I know that PA sends out an Gratuitous ARP in Failobver to inform the network partners that the active IF-IP has changed. But waht about the configured static NATs on the Public Network which redirects traffic to internal Servers (e.g. DMZ) ?

Are there also Gratuitous ARP send out for those "Proxy Arp" Adresses?

I ask this because at a customer site the Static IP Mapping will no longer work after an failover till the router in front will be flushed the arp cache?

Any answers welcom.

Stefan

[migration]

Confirmed.  PAN does not sent GARP for 'proxied' IPs including NATs or PATs.  Only IPs configured directly on an interface will GARP to the upstream/downstream devices.  If you don't have control over those devices (managed service provider controlling your Internet Router for example), you might be in trouble, or at least be in for a fun time on the phone with support for 2 hours to get them to do something that takes a few second (clear arp).  Best practice:  enable HA on your primary PAN, even if there is no secondary PAN.  Yes it works, it's harmless.  This will prevent the need for GARP or clear arp up/down stream because the virtual MAC associated with HA being enabled is already in those devices.  Cheers!

[kbrazil]

It is my understanding (and correct me if I am wrong) that the Proxy-Arp IP's share the same MAC as the Interface IP.  A Gratuitous ARP is not really sent to inform a layer3 device of a change (ARP Table), but to modify the CAM table of a switch (no IP information).  Since they share the same MAC address all of the IP's should correctly fail-over during an outage.

It is true that the MAC address changes to a virtual MAC address when enabling HA as dfreedman said, so it might be a good practice to get that set up long before you actually bring your secondary unit online, but that should not affect normal failover operation when HA is up and running.

If two Palo Alto firewalls are directly connected to a single L3 device, then you should have it configured to bridge the two interfaces, which will create an L2 CAM table, just like a switch.  If it honors Gratuitous ARP, then it should work like a charm.

Cheers,

Kelly

[migration]

So,

in a HA L3 environement (not so uncommon) what else do we have to do to make it working?

This is something not documented and it appears to be vital!

Thanks

[migration]

Example1:

You have FW1 and FW1 doesn't have HA enabled upon initial deployment.  Then you bring in FW2 and want to set up HA.  When you enable HA on FW1, that's when the problem with GARP/ Proxy ARP occurs.

Example2:

You have FW1 and FW1 has HA enabled upon initial deployment.  Then you bring in FW2 and want to set up HA.  Since you already have HA enabled on FW1, you will NOT experience the GARP / Proxy ARP problem.

Example 3:

You have FW1 and FW2 both with HA enabled upon initial deployment.  Then you will not experience the GARP / Proxy ARP problem.

So to reitterate, if you're deploying a single firewall, enable HA upon initial deployment and you will never experience the problem in Example 1.  It's really that simple.

[kbrazil]

There are many ways to successfully design an L3 HA solution.  The most common is the 'switch-sandwich' where the firewall sits between two switches or two pairs of switches.  With a Layer2 device between the firewall and the router it should work nicely.  In the example I used in the earlier post you would be logically and physically combining the switch and router on the same hardware, basically emulating one side of the switch-sandwich.

There are other designs that can utilize routing protocol, but these are a bit more complex.  You may want to work with your Palo Alto Networks or VAR SE to discuss the options.

Cheers,

Kelly