Change gateway IP address (Centrally managed)

[velo]

I'm looking to change my WAN IP address on an SMB Gateway (although I think the process is the same on normal Gateway also) 

I have done this before but some time ago. If I recall, this was the processed I followed.

1. Push a firewall policy to the gateway with Source: SMS -> Dst: New IP range that will be configured on the firewall
2. Log on locally to the Gateway, and change the IP address, and default route. 
3. Log on to SMS and change the Gateway IP, and IP address in topology
4. Push the policy
5. Delete the temporary firewall policy

Have I missed anything out here? 

I did this once without doing step one and I think I locked myself out of the firewall. Hypothetically in this instance you would need to do an "fw unloadlocal" , then push the policy again right? 

Thanks

[PhoneBoy · Accepted solution]

You've got this more or less correct, and yes fw unloadlocal might be necessary.

[velo]

Thanks

[the_rock · Accepted solution]

For what is worth, since AI seems to be part of every day life these days, here you go : - )

Andy

*******************************

Typical steps to change WAN IP on a Check Point Gateway

1. Pre-change policy rule (good call!)

   • Add a temporary rule allowing management traffic (SmartConsole / SIC / SSH, etc.) from your SMS (Security Management Server) to the new WAN IP.

   • Install policy.

   • This makes sure once the gateway is re-addressed, you can still reach it.

2. Change the IP on the gateway itself

   • On SMB appliances: done via WebUI or CLI (set interface, set static-route, etc.).

   • On Gaia: via clish or WebUI (update interface IP, update default route if needed).

   • Verify routing so return traffic goes back via the new WAN.

3. Update the object/topology in SmartConsole

   • Edit the Gateway object → update external interface IP(s) and topology.

   • Make sure the new IP is correctly marked as “External” if relevant.

   • Save.

4. Push policy again

   • Install policy to the gateway with updated topology.

   • Verify SIC trust if needed (if management IP is changing, see note below).

5. Clean up

   • Remove the temporary rule you added in Step 1.

   • Push policy again to tidy things up.

---

Common gotchas / additional considerations

• Management (SIC) IP
  If the management server itself talks to the gateway over this WAN IP, you’ll need to update the gateway’s “General Properties” → “IP Address” field to the new one. Otherwise SIC trust will break.
  If management connectivity is via another interface (e.g. internal LAN), you don’t need to worry here.

• NAT rules
  If the old WAN IP was explicitly used in NAT rules (static NATs, hide behind, etc.), you’ll need to update those too.

• Anti-Spoofing
  Double-check anti-spoofing settings on the external interface. The new WAN subnet should be reflected there.

• Routing
  Make sure the new default route points correctly, otherwise you’ll lose outbound connectivity.

---

Your question about “lockout” and recovery

Yes — if you forget to allow traffic to the new IP in advance, you can absolutely lock yourself out.

On a Gaia gateway:

• You’d need console access (serial/ILO/DRAC/VM console) to get in.

• Run fw unloadlocal — that unloads the policy and leaves only the implicit accept (basically open firewall).

• Fix the interface, topology, push policy again.

On an SMB appliance:

• Similar idea, but you’d use WebUI/CLI locally to reset policy if it blocks you.

---

✅ So your original steps are basically correct — the only extras I’d add are:

• Update anti-spoofing settings

• Update any NATs involving the old IP

• Be mindful of SIC/management connectivity if SMS → gateway communication depended on that WAN IP

[velo]

Thanks for that Andy.

The problem with AI is that it often just makes up things which are not true. 

[the_rock]

Well, it was invented by humans lol