Manual NAT and local.arp file vs Automatic NAT

[Anthony_Kahwati]

Hi all

We are about to do a migration / DC refresh and our current environment has NAT deployed by way of manual rules and amendment of the local.arp file per VS on a VSX cluster. This is fine, but as time goes on and as house-keeping gets forgotten about we need to log into every VS to check the local.arp file to make sure that an address is definitely not in use. 

In what situations should I use an automatic NAT object vs using manual NAT and the local.arp file?

Thanks

[PhoneBoy]

I’d use manual NAT where an automatic NAT doesn’t cut it (more complex, conditional scenarios, or involving dynamic/updatable objects)
Automatic NAT for everything else.

[Magnus-Holmberg]

I would build with linknetworks and then route all the public ip ranges in to the VS so there is no need for local.arp entrys.

[Bob_Zimmerman]

Definitely my preferred path, especially since it allows you to use the full address block. The old broadcast and new broadcast addresses (.0 and .255 in a /24) are only special in a broadcast domain. If it's not on an interface, it doesn't necessarily correspond to any broadcast domain, so you can use both for traffic endpoints. Matters a lot more for smaller blocks. In a /29, for example, it takes you from six usable addresses to eight.

[Anthony_Kahwati]

I get that it would be good to be able to use the whole range and route to the NAT's rather than be onlink with them but we are handed a public network from our ISP and they have 3 of those addresses, one of which is our default gateway. I didn't realise that you don't need the local.arp file if the NAT's are not onlink though so that's good. We do have a range at a site set up like this so I'll keep that in mind for the next NAT which is just about to be set up funnily enough!

Thanks for the feedback all.

[stallwoodj]

I frequently come across deployments where manual NAT has been used with proxy ARP, and can invariably lead to trickiness when the version or hardware is replaced.

In those cases I usually create dummy objects which have automatic Hide NAT which creates interface proxy ARPs automatically without the need for external files or configs. These can be scripted in the Mgmt CLI as well, e.g.

add host name NAT_Dummy_30 ipv4-address 192.0.0.30 nat-settings.auto-rule true nat-settings.method hide nat-settings.hide-behind ip-address nat-settings.ipv4-address 8x.x.x.30 nat-settings.install-on ClusterName

Note that if you ever migrate your NAT interface, you MUST update the interface definitions in the firewall object topology. Unlike cluster IP's which are based on the subnet ID, proxy ARP uses the interface NAME. On clusters, make sure you update the interface name on both Members in the topology Advanced section!

Thanks

Jamie

[Wolfgang]

Have a look at this thread.

Proxy arp on VSX 

Wolfgang