Active-Active NAT Rule Binding

[CHammock]

I can't find anything which goes into enough detail on Active-Active design around NAT and more importantly ARP.

The easiest way to explain the current deployment is as follows:

• Site 1 / Firewall A
• Site 2 / Firewall B

Each firewall is connected to unique networks and routers internally and externally.

The expectation is to provide redundancy by putting both firewalls in HA A/A and setting floating addresses so that each firewall will be the primary for its site as listed above but in the event of a site or firewall failure the remaining firewall will take over both site and firewall responsibility.

From a network point of view we have L2 connectivity for all networks across both sites. The A/A config is such that floating IPs mean the correct firewall will ARP for the correct addresses for that site. Everything works fine apart from the NAT. DeviceID 0 is Primary, DeviceID 1 is Secondary

Destination NAT for Site 1 is fine. I have bound all destination NAT rules for Site 1 to the “Primary” device.  So Firewall A arps for all destination NAT addresses.  If Firewall A fails the remaining device becomes primary and ARPs for all destination NAT addresses.

The Problem 1:

Destination NAT for Site 2 can only be bound to DeviceID 1 which means if it fails the remaining firewall doesn’t arp for the Destination NAT. If I change the NAT binding to both I get an arp conflict for the IP as both firewalls are on the same L2 network and its hit and miss as to which firewall the routers send the traffic.

The Problem 2:

Source NAT can only be bound to DeviceID 0 or DeviceID 1. Which means similar to problem 1 I either get no failover or an ARP conflict.

I feel like the solution is to have a "Secondary" bind option and to allow Source NAT rules to be able to be bound to both Primary and Secondary devices.

Am I missing something from the network design or is this a limitation of the Active-Active Technology. A work around would be to disable the NAT rules from ARPing and it all being managed by the HA floating address configuration.  Is there a CLI command to disable NAT rule ARPing?

Any advice appriciated.

[pulukas]

You have correctly identified the issue of binding with NAT in A/A mode.  When you write a rule it requires you to choose a device.

However, you can duplicate rules and have them on both devices then for the same process.  This is a bit of a pain to double all the NAT rules and a little counter intuitive, but it does work once deployed.  I've used the method a couple years back.

[CHammock]

Thanks for the reply pulukas.

I understand the whole binding thing and really don't have a problem with having duplicate rules for each device (although its not ideal).  I guess my main issue is

When I use your suggested method of duplicate NAT rules DeviceID 0 and DeviceID 1 or use (both) binding which I still don't understand why this isn't available for source nat.  I can't control which FW responds to the request as it seems both are ARPing for the address, which is confirmed by the system log 'Received conflicting ARP on interface ethernet1/1 indicating duplicate IP 80.6.91.149, sender mac d4:f4:be:xx:xx:xx'

So really I guess the question is why are floating addresses available to control which firewall responds to ARP, unless you use NAT rules in which case both will.

It really would fix my problem if there was a CLI command to switch off NAT rule ARPing off as I could then define Floating Addresses for evertything used in NAT.

My confusion is increased by the fact I am not seeing this conflicting MAC behaviour consistantly across the customer enviroment (which has ) or my LAB setup.  Makes me wonder if I am seeing some wierd BUG.

[pulukas]

Well its not a bug but the way the feature works.  I never got a good answer as to why the specific node binding was required for an A/A setup.  It just is required so you can't choose both.  When you need both then you need to duplicate the rules.

The alternative to avoid the arp issue is to assign different ip addresses to the two nodes, but this is not always feasible which is why I had to use duplicate rules in that A/A deploy I did a few years ago.