Check Point ISP Redundancy - Dynamic Objects (Something Interesting Network)

[Chinmaya_Naik]

Network Topology:

ISP Redundancy : Active/Standby Mode

Source: Host_A IP : 11.201.6.171

              Host_B IP : 11.201.6.172

Destination is XYZ Server IP: 142.250.205.238

ISP-1 NAT Public IP: 116.113.114.25 (From pool)

ISP-2 NAT Public IP: 58.143.112.130 (From Pool)

I created a manual NAT rule for this like below

Outbound Connection we need:

NAT Rule No	Original Source	Original Destination	Original Service	Translate Source	Translate Destination	Translate Service
1	11.201.6.171	142.250.205.238	https	116.113.114.25	Original	Original
2	11.201.6.171	142.250.205.238	https	58.143.112.130	Original	Original
3	11.201.6.172	142.250.205.238	https	116.113.114.26	Original	Original
4	11.201.6.172	142.250.205.238	https	58.143.112.131	Original	Original

Challenge : If ISP-1 once goes down then NAT Rule No-1 will always hit and its not going to hit the NAT Rule No-2 and my internal system 11.201.6.171 unable to reach the XYZ Server IP: 142.250.205.238.

To resolved this issue We plan to implement Dynamic Object.

Below is our POA

Object Name	Comment
DYN_ISP_A	ISP 1
DYN_ISP_B	ISP 2

Object Name	Comment
HOST_INTERNAL	11.201.6.171
HOST_INTERNAL1	11.201.6.172

Object Name	Comment
HOST_VALID_ISP_A	116.113.114.19
HOST_VALID_ISP_B	58.143.112.129

Manual NAT Rule:

Original Source	Original Destination	Original Service	Translate Source	Translate Destination	Translate Service
HOST_INTERNAL	DYN_ISP_A	https	HOST_VALID_ISP_A	Original	Original
HOST_INTERNAL	DYN_ISP_B	https	HOST_VALID_ISP_B	Original	Original
HOST_INTERNAL1	DYN_ISP_A	https	HOST_VALID_ISP_A	Original	Original
HOST_INTERNAL1	DYN_ISP_B	https	HOST_VALID_ISP_B	Original	Original

On the Security Gateway / each member of ClusterXL, run the 'cpstop' command.

1. Transfer the cpisp_update file to the both gateways ($FWDIR/bin/ directory) using scp tool.
2. Stop the Standby Member First (cpstop)
When running the commands below, we have to use the exact object name from SmartConsole
(case-sensitive).
[Expert@HostName]# dynamic_objects -n DYN_ISP_A
[Expert@HostName]# dynamic_objects -n DYN_ISP_B
[Expert@HostName]# dynamic_objects -o DYN_ISP_A -r 0.0.0.0 0.0.0.0 -a
[Expert@HostName]# dynamic_objects -o DYN_ISP_B -r 0.0.0.0 0.0.0.0 -a

3. Convert the cpisp_update file script to Unix format (dos2unix
$FWDIR/bin/cpisp_update)
4. Make the script executable (chmod +x $FWDIR/bin/cpisp_update)
5. Start the service on Standby Member (cpstart)

Repeat Steps 1-5 on the Other Gateway
We can see which ISP link is up with this command: tail -f /tmp/cpisp_state

File: $FWDIR/bin/cpisp_update : (Refer sk25152)

Add the following configuration to have a Primary/Backup ISP solution (it will allow the Primary ISP to take back control after it is up again):

Challenges Question 1:  We already configured sk32073 (Configuring Cluster Addresses on Different Subnets) and its running on the production so is this going to impact the Dynamic Object implementation?

Challenges Question 2:  We also have a one internal server server communication and that routes towards the external sub-interface eth1-01.x and route is also created and its working fine but if I configured the Dynamic Object rule then I am sure its hit the access control rule and then NAT Rule-1 and the source 11.201.6.171 unable to reach to the Internal Server.

Its complicate and its running on a critical environment so please need all of your assistance will be Great.

Regards

@Chinmaya_Naik   

[the_rock]

Hey man,

Since you asked me about this post on zoom remote, I really believe best thing to do is open TAC case, since they may need to provide updated ISPR script. Thats what was given to my colleague and I while back when we had similar issue. Personally, I would be super careful updating this file. Just make sure if you do that you back it up first, so its easy to revert later.

Andy

[CheckPointerXL]

Did you try to use Zones instead?

The fact that we need to use script into a FW for operation like this it sounds ridiculous to me

[the_rock]

Now that I think about it, sounds logical.

Andy

[the_rock]

@Chinmaya_Naik Message me directly Friday and we can do zoom, I will have time to check. If 12 pm est is late, we can do say 8.30 am est, which is 7 pm for you, if that works?

Andy

[Chinmaya_Naik]

@the_rock  Thank you so much for the wonderful discussion we had yesterday  and last week —it truly left an impression on me.

I’m genuinely inspired by how you generously offer your valuable time to help others, diving into their challenges and sharing the best solutions with such care. The Checkpoint community is truly remarkable; being part of this forum and supporting one another reflects a beautiful spirit of curiosity and kindness.

Regards

@Chinmaya_Naik 

[the_rock]

Thank you @Chinmaya_Naik for your kind words. I know I may not be nearly as smart as lots of other people on here, but I will ALWAYS do my best to help.

Have a nice weekend and be free to reach out any time you are ready to check this further.

Andy

[the_rock]

Btw, if you wanted to give me some more details about this, we can have zoom remote, not an issue. Im good now for another 55 mins or same time as yesterday.

Andy

[Chinmaya_Naik]

@the_rock 

Thank you for your reply, yes will connect on zoom remote as yesterday time.

@Chinmaya_Naik 

[the_rock]

Awesome! I will send you zoom directly then.

Andy

[the_rock]

Hey man,

Sent you link directly.

Andy

[the_rock]

Hey everyone,

Just to update quick...did zoom with @Chinmaya_Naik and we went over below link:

https://support.checkpoint.com/results/sk/sk25152

I explained that in my view, as long as routes are correct, ISPR should function normally if active link fails, since it would not be used for VPN tunnels. I also showed the guys basic example for health check IP in my Fortinet lab with FortiSASE setup, though to me, as I explained, I would certainly try simulate all this to best of my ability in the lab, since asking the customer to do it and hope for the best, definitely not a good idea, as it may turn into hours long remote with TAC doing debugs/trhoubleshooting.

Anyway, @Chinmaya_Naik , if you have other questions/doubts, let me know. I used to have ISPR configured in our Azure lab, but had to get rid of it, since we have to built another Harmony SASE lab for a customer.

Andy

[Chinmaya_Naik]

Hi @the_rock 

I just wanted to reach out directly to say a heartfelt thank you for taking the time last Friday to join us for that Zoom session. Your generosity with your expertise and your willingness to dive into SK25152 (https://support.checkpoint.com/results/sk/sk25152) with us was incredibly valuable. I really appreciated how you broke down ISPR’s behavior—highlighting that it should handle failover fine with proper routing (outside of VPN tunnels)

On a related note, I came across a limitation I thought worth mentioning: per SK32073 (Configuring Cluster Addresses on Different Subnets), ISP Redundancy won’t failover in ClusterXL if the cluster members’ physical interfaces and the VIP are on different subnets. It’s noted as unsupported and “by design,” which surprised me a bit. (sk66521)

@Chinmaya_Naik 

[the_rock]

Glad we can help mate.

Andy