Showing results for 
Search instead for 
Did you mean: 
Create a Post

Cloudguard backend routing problem

We're installing a CloudGuard IaaS High Availability using the latest deployment guide.

We experience problem on the internal routing, the internal load balancer, automatically created with the template, seems not to route the traffic to the cloudguard appliance.

On the management we do not see any traffic logs but if we configure a cluster ip address on the checkpoint backend network  using the address that should be configured to the backend-lb (.4) suddenly we see the traffic on the management, even the traffic from internet...

The routing table assigned to the backend subnets and the routing on the checkpoint are configured as described on the guide. (strange that checkpoint route to a phantomatic .1 address and the internal subnets route to the backend loadbalancer ip .4)

Any idea how to debug and solve this problem?




0 Kudos
6 Replies

Re: Cloudguard backend routing problem

On the Back End Connection you route traffic to the .1 Address in the Back End Network as that is assigned to an Azure Router that then puts the traffic into the Azure Software Defined Networking so can reach the other Subnets/Virtual Nets that may be behind the Firewall.

The BackEnd Subnets route traffic to the Load Balancer address as the Load Balancer performs a health check against the two firewalls backend interface ip using the health pool.   Only the Active Member in the Cluster responds so the Back End Load Balancer then forwards the traffic to the Active Member.

Upon failover then the newly Active Member starts to responds and the Standby Member doesn't so traffic sent to Second Member instead.  A lot better then how used to work with the API reconfiguring all the backend network UDR.

The Cluster IP on the Backend not certain will failover with the Cluster and you certainly shouldn't have to do it.

Sounds as though the Back End Load Balancer not deployed properly to me.

So would suggest that probably delete and recreate in Azure.

Someone with more Azure experience ( I am usually working with an Azure person when I do Cloudguard ) maybe able to help further with debugging but I would suggest that the Back End Load Balancer not correctly deployed.

0 Kudos

Re: Cloudguard backend routing problem and Expressroute

We're still experience problems and we're working with checkpoint to solve it.

In addition to this we attach also an ExpressRoute connection following the SK110993

In this SK network diagram there's only one cloudguard gw.

In our case we have an HA solution with frontend and backend subnet and load balancers in it.

Now the problem is that azure accept only one internal balancer for vnet so it's not possible to create another load balancer for the dmz interface connected to the ER gateway, for that reason we connect the gateway subnet directly to the internal load balancer without having a dedicated DMZ and we add a route on the gateway subnet to the internal load balancer ip.

Now if we try to ping a VM from the onprem network through the ExpressRoute to a VM behind the cloudguard we got a drop on the cloudguard because the "ICMP reply do not match a previous request", so it seems that the traffic has been sent to the VM without passing on the cloudguard.

Anyone has an idea what could be the problem?









0 Kudos

Re: Cloudguard backend routing problem and Expressroute

have you defined a UDR for the subnet in which the express route is configured (called GatewaySubnet) to forward packets for the destination subnet/VNET to the virtual IP on the internal LB ? If not, the echo request will be forwarded directly to the destination VM


0 Kudos

Re: Cloudguard backend routing problem and Expressroute

yes we did it but it seems to be ignored.



0 Kudos

Re: Cloudguard backend routing problem and Expressroute

make sure the size of your routes are matching, e.g if you have a VNET of /24, then a UDR of /22 would not override that /24 network route

0 Kudos

Re: Cloudguard backend routing problem and Expressroute

Problem solved.

the UDR on the gateway subnet had the right route but it was not associated to the gateway subnet.

after associating the udr the traffic was correctly managed by the cloudguard.

anyway thanks for your support.



0 Kudos