ISP REDUDANCY FAILOVER NOT WORKING

[VIKAS1]

 We are using ClsuterXl with 2gateway cp9100 and we have two isp, we have configured isp redundancy but when isp 1 down then we are not able to get internet, we have configured ISP Redundancy from ClusterXL, I have mentioned some output below.

Please provide the output of the following:

1. cphaprob -a if
   → To check which interfaces are monitored in ClusterXL and if they failover correctly…find the logs below..

[Expert@RM2-FW02:0]# cphaprob -a if

CCP mode: Manual (Unicast)

Required interfaces: 5

Required secured interfaces: 1

Interface Name:      Status:

eth1                 UP

eth2                 UP

eth3                 UP

Sync (S)             UP

Mgmt                 Non-Monitored

bond1 (LS)           UP

S - sync, HA/LS - bond type, LM - link monitor, P - probing

Virtual cluster interfaces: 7

eth1            125.17.XX.XX -ISP1

eth2            14.195.XX.XX-ISP2

eth3            10.20.xx.10

bond1           10.199.xx.5

vpnt1           169.254.xx.118

vpnt2           169.254.xx.157

vpnt3           169.254.xx.222

[Expert@RM2-FW02:0]#

1. ISP Redundancy Method (Load Sharing or Primary/Backup?)
   
   

1. NAT Rules Overview
   → Are you using "Hide NAT behind gateway" or static NAT? , we are using hide behind gateway NAT.
2. Show route all.

EMB-SJRM2-FW01> show route all

Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),

       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),

       IS - IS-IS (L1 - Level 1, L2 - Level 2, IA - InterArea, E - External),

       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,

       NP - NAT Pool, U - Unreachable, i - Inactive

S               0.0.0.0/0           via 14.195.XX.XX, eth2, cost 0, age 55725

C               1.1.1.0/24          is directly connected, Sync

                                        SYNC

C               10.20.XX.0/28       is directly connected, eth3

                                        Sens ASA

C            i  10.20.XX.0/28       is directly connected, eth3

                                        Sensopart ASA

S               10.98.XX.0/23      via 169.254.106.117, vpnt1, cost 0, age 55725

                                        AWS SG Tunnel

S               10.159.XX.0/19      via 169.254.84.157, vpnt2, cost 0, age 55725

                                        BFL AWS Mumbai

S               10.162.XX.0/16       via 169.254.XXX.221, vpnt3, cost 0, age 55725

                                        BFL BFSI AWS Mumbai

C               10.199.XX.0/28       is directly connected, bond1

                                        CORE_SW _1_2-LAN

C            i  10.199.XX.0/28       is directly connected, bond1

                                        CORE_SW _1_2-LAN

S            i  10.199.XX.0/28       via 10.199.XX.1, bond1, cost 0, age 55725

                                        FIREWALL VLAN 199

ClusterXL snap below.

[AkosBakos]

Hi @VIKAS1 

Have you read this?

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topic...

Primary/Backup

Outgoing traffic uses an active primary link. Hide NAT is used to change the source address of outgoing packets to the address of the interface, through which the packet leaves the Security Gateway / Scalable Platform Security Group. This allows return packets to be automatically routed through the same ISP link, because their destination address is the address of the correct link. Administrator configures the Hide NAT settings.

When "not working" you're able to ping the 8.8.8.8, or there is no traffic to outside direcion at all?

Akos

[VIKAS1]

When "not working" you're able to ping the 8.8.8.8, or there is no traffic to outside direcion at all? 

Not able to ping 8.8.8.8

ISP Redundancy on a Security Gateway / Security Group , i will go through this once

[AkosBakos]

And if you run a fw monitor to 8.8.8.8 you see the leaving interface correctly (iIoO)?

What do you see in the SmarLog? Is this traffic NATed to the correcp publicIP?

[VIKAS1]

we are planning a controlled troubleshooting activity bcz of its live setup during weekend ,However, we have observed that when one ISP (e.g., Airtel or TATA) goes down, the entire network loses internet access — impacting all users

[AkosBakos]

I suppose that, there would be a NAT issue. There is a manual NAT which translated the traffic eg.: to TATA's public IP address and when it goes down the NAT still NAT to TATA's private address instead of Artiel.

Here an article about NAt: https://support.checkpoint.com/results/sk/sk174197

Could you please check this too?

Akos

[VIKAS1]

Yes sure, i will go through sk174197. will share you NAT configuration which we have applied.

[AkosBakos]

One more thing:

Have you tried to set this thing?

[VIKAS1]

Yes we have