topic Re: BGP between two Check Point ClusterXL (HA) in Azure – Session stuck in Active/Idle in Cloud Firewall

BGP between two Check Point ClusterXL (HA) in Azure – Session stuck in Active/Idle

Jose_Luis_Hdz — Mon, 18 May 2026 17:00:57 GMT

Hi everyone,

I’m currently working on a scenario in Azure where I have two Check Point ClusterXL (HA) deployments in different VNETs that need to establish eBGP routing between them.

Environment overview
cpfwr1fwvpn1: 10.11.0.0/22
cpfwr1fwhub1: 10.11.4.0/22
Connectivity: Azure VNET Peering

Cluster IP layout:
cpfwr1fwhub1
VIP: 10.11.4.6
Members: 10.11.4.4, 10.11.4.5
Internal: 10.11.5.5, 10.11.5.6

cpfwr1fwvpn1
VIP: 10.11.1.6
Members: 10.11.1.4, 10.11.1.5
Internal: 10.11.2.5, 10.11.2.6

Initial BGP configuration:
I configured BGP between the private VIPs on the external interface (eth0):
cpfwr1fwhub1
set bgp external remote-as 64598 on
set bgp external remote-as 64598 peer 10.11.1.6 on

cpfwr1fwvpn1
set bgp external remote-as 64597 on
set bgp external remote-as 64597 peer 10.11.4.6 on

Initial behavior (BEFORE changes)
BGP state: Idle

Investigation findings:
Using ip route get:
cpfwr1fwhub1
10.11.1.6 via 10.11.4.1 dev eth0 src 10.11.4.4
10.11.1.4 via 10.11.5.1 dev eth1 src 10.11.5.5

cpfwr1fwvpn1
10.11.4.6 via 10.11.1.1 dev eth0 src 10.11.1.4
10.11.4.4 via 10.11.2.1 dev eth1 src 10.11.2.5

Based on the above, I understand that the VIPs were reachable via eth, but member IPs were resolved via eth1.

Changes implemented (AFTER)
To fix asymmetry, i added static routes so that VIP + all cluster member IPs are reached via eth0 only:
cpfwr1fwvpn1
10.11.4.4/32 via 10.11.1.1 dev eth0
10.11.4.5/32 via 10.11.1.1 dev eth0
10.11.4.6/32 via 10.11.1.1 dev eth0

cpfwr1fwhub1
10.11.1.4/32 via 10.11.4.1 dev eth0
10.11.1.5/32 via 10.11.4.1 dev eth0
10.11.1.6/32 via 10.11.4.1 dev eth0

Current behavior (AFTER changes)
BGP state: Active / OpenConfirm

When reviewing the routing logs, I notice that, i realized that even though the peer is configured against the VIP, but the firewall receives connections from member IPs:
cpfwr1fwvpn1
May 15 16:19:04.729369 [routed] WARNING: bgp_get_open(3143): peer 10.11.4.4+22960 (proto) has provided 4 Byte AS 64597
May 15 16:19:04.729369 [routed] NOTICE: bgp_pp_recv(4215): dropping peer 10.11.4.4+22960 (proto), no such peer configured locally
May 15 16:19:04.729369 [routed] WARNING: NOTIFICATION sent to 10.11.4.4+22960 (proto): code 2 (OpenMessageError) data
May 15 16:19:22.182290 [routed] WARNING: bgp_get_open(3143): peer 10.11.4.6 [eBGP AS 64597] has provided 4 Byte AS 64597
May 15 16:19:22.182290 [routed] WARNING: NOTIFICATION received from 10.11.4.6 [eBGP AS 64597]: code 2 (OpenMessageError) data
May 15 16:19:22.182290 [routed] NOTICE: bgp_peer_close(6403): closing peer 10.11.4.6 [eBGP AS 64597], state is 5 (OpenConfirm)
May 15 16:21:32.732262 [routed] WARNING: bgp_get_open(3143): peer 10.11.4.4+63906 (proto) has provided 4 Byte AS 64597
May 15 16:21:32.732262 [routed] NOTICE: bgp_pp_recv(4215): dropping peer 10.11.4.4+63906 (proto), no such peer configured locally
May 15 16:21:32.732262 [routed] WARNING: NOTIFICATION sent to 10.11.4.4+63906 (proto): code 2 (OpenMessageError) data
May 15 16:21:50.185917 [routed] WARNING: bgp_get_open(3143): peer 10.11.4.6 [eBGP AS 64597] has provided 4 Byte AS 64597
May 15 16:21:50.185917 [routed] WARNING: NOTIFICATION received from 10.11.4.6 [eBGP AS 64597]: code 2 (OpenMessageError) data
May 15 16:21:50.185917 [routed] NOTICE: bgp_peer_close(6403): closing peer 10.11.4.6 [eBGP AS 64597], state is 5 (OpenConfirm)
May 15 16:24:00.739103 [routed] WARNING: bgp_get_open(3143): peer 10.11.4.4+64418 (proto) has provided 4 Byte AS 64597
May 15 16:24:00.739103 [routed] NOTICE: bgp_pp_recv(4215): dropping peer 10.11.4.4+64418 (proto), no such peer configured locally

cpfwr1fwhub1
May 15 14:16:41.361524 [routed] WARNING: bgp_get_open(3143): peer 10.11.1.6 [eBGP AS 64598] has provided 4 Byte AS 64598
May 15 14:16:41.361524 [routed] WARNING: NOTIFICATION received from 10.11.1.6 [eBGP AS 64598]: code 2 (OpenMessageError) data
May 15 14:16:41.361524 [routed] NOTICE: bgp_peer_close(6403): closing peer 10.11.1.6 [eBGP AS 64598], state is 5 (OpenConfirm)
May 15 14:16:58.815991 [routed] WARNING: bgp_get_open(3143): peer 10.11.1.4+3469 (proto) has provided 4 Byte AS 64598
May 15 14:16:58.815991 [routed] NOTICE: bgp_pp_recv(4215): dropping peer 10.11.1.4+3469 (proto), no such peer configured locally
May 15 14:16:58.815991 [routed] WARNING: NOTIFICATION sent to 10.11.1.4+3469 (proto): code 2 (OpenMessageError) data
May 15 14:19:09.367861 [routed] WARNING: bgp_get_open(3143): peer 10.11.1.6 [eBGP AS 64598] has provided 4 Byte AS 64598
May 15 14:19:09.367861 [routed] WARNING: NOTIFICATION received from 10.11.1.6 [eBGP AS 64598]: code 2 (OpenMessageError) data
May 15 14:19:09.367861 [routed] NOTICE: bgp_peer_close(6403): closing peer 10.11.1.6 [eBGP AS 64598], state is 5 (OpenConfirm)
May 15 14:19:26.820545 [routed] WARNING: bgp_get_open(3143): peer 10.11.1.4+45477 (proto) has provided 4 Byte AS 64598
May 15 14:19:26.820545 [routed] NOTICE: bgp_pp_recv(4215): dropping peer 10.11.1.4+45477 (proto), no such peer configured locally

Given all of the above, could you please let me know if the configuration being set up is incorrect? Is any specific NAT required? Could this be related to a scenario that is not compatible with Check Point?

Best regards.

Re: BGP between two Check Point ClusterXL (HA) in Azure – Session stuck in Active/Idle

Chris_Atkinson — Sat, 16 May 2026 05:28:30 GMT

Some further configuration details and perhaps a diagram might be helpful but an observation is I don't see multihop configured yet your gateways aren't directly connected?

Re: BGP between two Check Point ClusterXL (HA) in Azure – Session stuck in Active/Idle

Jose_Luis_Hdz — Mon, 18 May 2026 17:01:58 GMT

Hello, thank you for your response. Please find the network diagram attached to this case.

Re: BGP between two Check Point ClusterXL (HA) in Azure – Session stuck in Active/Idle

the_rock — Mon, 18 May 2026 17:33:54 GMT

Hey Jose Luis,

Did you try doing simple zdebug to see if any of those IPs are getting dropped?

Re: BGP between two Check Point ClusterXL (HA) in Azure – Session stuck in Active/Idle

Duane_Toler — Tue, 19 May 2026 22:53:43 GMT

Sorry to ask an idiot question, but I must: HA cluster, yeah? Did you install policy after configuration in SmartConsole?

I said it was an idiot question, but that’s because you CAN configure BGP and even establish peering without a policy.. but only on single gateways. ClusterXL requires obvious cluster config to bring up the VIP. You’re getting replies from the native interface IP which says the gateway outgoing traffic isn’t being folded to the cluster VIP (which often screams “cluster not configured”). Check the output of “cphaprob -a if”). You should only have 1 cluster VIP. The inside interface is not clustered. (The internal load balancer replaces the VIP function).

Ultimately, I don’t think you can do it this way, with VNET peering. With peering, azure is establishing forwarding for all subnets in your VNET on both ends of the peering. With peering, you don’t need BGP anyway.. just unicast routing. BGP nets you nothing.

If you want.BGP anyway, without VNET peering, you may need to use site to site VPN and VTI (which means unnumbered VTI with loop back and ebgp-multihop; no it’s not that scary; this is how I do all my azure clusters BGP; peering with the loop back is soooo much nicer in the end. You can get BFD multihop too).

However, if you want to bang on it anyway, that’s fine, too! Instead of peering with the private VIP, try switching to the Azure public IP of the respective peer VIP (the “cluster-vip” ip address object). That will force the traffic through azure’s NAT boundary for outbound connections. If you do this, you might need multihop enabled and ttl 2 or more. eBGP is assumed to be 1 hop away so TTL defaults to 1.

Let us know how it goes and if you decide to break the peering and do VPN VTI instead.

Re: BGP between two Check Point ClusterXL (HA) in Azure – Session stuck in Active/Idle

Duane_Toler — Tue, 19 May 2026 23:06:13 GMT

You also can’t use local-address for eBGP on a cluster (specifically). Drop that from your configuration on each end, Gaia Advanced Routing Guide, page 73 (R81.20, page 74 for R82)

Hopefully you can get this working; it’d be really nice, if so.