topic Re: Question about NAT Failover SK 25152 in General Topics

Question about NAT Failover SK 25152

Jesse140515 — Mon, 31 Aug 2026 18:16:28 GMT

Hello! We are attempting to set up ISP Redundancy for our static NAT objects according to SK 25152.

We have done all of the steps up until step 10 where the cpisp_update script is updated. In the SK it shows this:

# You can see which ISP link is up with this command: tail -f /tmp/cpisp_state echo "--------------------------" >> /tmp/cpisp_state echo `/bin/date +%d-%b-%Y_%Hh-%Mm-%Ss` >> /tmp/cpisp_state echo "RESTARTING SCRIPT" >> /tmp/cpisp_state echo "LINK1" >> /tmp/cpisp_state echo $LINK1_STATE >> /tmp/cpisp_state echo "LINK2" >> /tmp/cpisp_state echo $LINK2_STATE >> /tmp/cpisp_state echo "--------------------------" >> /tmp/cpisp_state echo " " >> /tmp/cpisp_state # Check if the Link is up or down if ($LINK2_STATE == "down" || $LINK2_STATE == "disabled") then fw tab -t dynobj_cache -x -y dynamic_objects -o DYN_ISP_A -r 0.0.0.0 255.255.255.255 -a dynamic_objects -o DYN_ISP_B -r 0.0.0.0 255.255.255.255 -d dynamic_objects -o DYN_ISP_B -r 0.0.0.0 0.0.0.0 -a endif if ($LINK1_STATE == "down" || $LINK1_STATE == "disabled") then fw tab -t dynobj_cache -x -y dynamic_objects -o DYN_ISP_B -r 0.0.0.0 255.255.255.255 -a dynamic_objects -o DYN_ISP_A -r 0.0.0.0 255.255.255.255 -d dynamic_objects -o DYN_ISP_A -r 0.0.0.0 0.0.0.0 -a endif

In the previous step, I added the dynamic objects and replaced 0.0.0.0 0.0.0.0 with our Public IP ranges from the ISPs. Do I need to add the ISP ranges to this script as well or keep it exactly as shown?

Re: Question about NAT Failover SK 25152

Duane_Toler — Tue, 01 Sep 2026 02:06:52 GMT

If you're indeed referring to *static* NAT, then this script is of no use. Static NAT is (by definition) just that; static. What you need for static NAT on ISP Redundancy is manual NAT entries for the internal host and manual static NAT for an IP on both ISP interfaces. You can get away with DNS trickery with an external DNS host if you list multiple IPs for the host (round-robin externally). The firewall will track the inbound/outbound connections for that external host to your inbound static NAT host, regardless of the ISP it came in on. Downside with this trickery is that you are fully at the mercy of external round-robin; might not be an issue if both ISP links are similar (100mbps here, 120mbps there).

However, the preferred/recommended/documented way, tho, is to let the firewall read the inbound DNS requests which means (yay!) you hosting your own DNS server internally so the firewall re-writes the DNS reply based on the DYN_ISP_A/DYN_ISP_B state. This only works if you build the table of hostnames and their ISP A/B IP addresses. Not fun to do. (are you *sure* you want to host static NAT through ISP Redundancy? just sayin'... 🙂 ).

The ISP update script is more appropriate for primary/backup failure for outbound only. It doesn't matter for inbound traffic (because that's not the goal of ISP Redundancy).

The inbound static NAT rule will be:

- original_source: Any original_destination: HostA_ISP1_NAT translated_source: Original translated_destination: HostA - original_source: Any original_destination: HostA_ISP2_NAT translated_source: Original translated_destination: HostA

Because it's manual now, you'll need an outbound NAT for *each* ISP for this host, and that's where you DYN_ISP_A/DYN_ISP_B dynamic objects come into play:

- original_source: HostA original_destination: DYN_ISP_A translated_source: HostA_ISP1_NAT translated_destination: Original - original_source: HostA original_destination: DYN_ISP_B translated_source: HostA_ISP2_NAT translated_destination: Original

Yes, you counted that correctly.. 4 rules per host. Yep. It's not so bad now with Ansible, tho (in fact I just gave you the YAML model for them) However, "back in the day" when I configured this on R70.40 manually clicking my way through SmartDashboard... omg... and *of course* the customer had a dozen or so hosts. 🙂

Be sure you also set some ISP link aliveness check. Unique ping hosts per ISP. The firewall will take care of emitting these packets; no route table trickery necessary.

Anyhoo.. it works.. it's just a pain to setup the one time. That's why it's considered "poor man's BGP". Once it's in place, it works well.

Re: Question about NAT Failover SK 25152

Jesse140515 — Tue, 01 Sep 2026 14:20:06 GMT

Thanks for the reply! We use AWS for our external DNS with health checks that will fail over to the secondary if the primary is inaccessible. I have created 3 manual objects for the host, Host_ISPA, Host_ISPB, and Host_Internal. So if I'm understanding you correctly, it should just work for inbound NAT since the firewall will receive the traffic from AWS in the event of a primary ISP outage? The firewall is configured with ISP redundancy in primary/backup mode as a whole, so would I still need to configure outbound NAT objects for each host or will the firewall figure out how to route the traffic automatically?

Re: Question about NAT Failover SK 25152

Duane_Toler — Tue, 01 Sep 2026 14:18:37 GMT

Yep! So long as the packet "gets there", you're good to go.

Granted "get there" would also mean you need to have proxy ARP in place, one way or another. Global Properties has the option now to merge manual proxy ARP. Be sure you verify this is published before troubleshooting the wrong things (fw ctl arp -n is your friend here.)

Re: Question about NAT Failover SK 25152

Duane_Toler — Tue, 01 Sep 2026 14:23:28 GMT

For your ISP redundancy question: Outbound is gonna be pinned to the ISP link that's active from the cpisp_update script, and that will be selected in the NAT rule like the SK shows.

Re: Question about NAT Failover SK 25152

Jesse140515 — Wed, 02 Sep 2026 23:56:58 GMT

Hi, our outbound NAT is hidden behind the firewall's IP address, so I don't believe we need to configure outbound NAT for each host. The issue we're running into now is that the manual inbound NAT will work for a few hours, but then it dies and the host is inaccessible from the internet. We have health checks running in AWS and the firewall logs show that traffic flow stopping. We have 'merge manual ARP' enabled on the firewalls. I set the AWS record to simple so that it's forced to resolve to that address without dependency on the health check, so I don't think this is an AWS issue.

I ran 'fw ctl arp -n' and do not see the public IP of the object. ip neighbor does show the local address of the host in question. Is this issue likely related to ARP?