Azure R81.20 Cloudguard Cluster Deployment

Simon_Macpherso — Wed, 21 Jun 2023 05:25:58 GMT

Deploying R81.20 cloudguard cluster using the following IAC.

https://github.com/CheckPointSW/CloudGuardIaaS/tree/master/terraform/azure/high-availability-existing-vnet

Unable to ping, SSH, webUI, or SIC the gateways post-deployment for some reason.

When accessing devices via Azure serial console, the devices have internet connectivity. Both are running the initial policy.

There are no NSGs associated with the VNETs.

I'm deploying the gateways in to an existing /29 ip public prefix. But have also tried deploying using random Azure assigned public IP addresses, and creating an ip public prefix as part of the deployment.

First time I've encountered this problem post-deployment.

Re: Azure R81.20 Cloudguard Cluster Deployment

Nir_Shamir — Wed, 21 Jun 2023 12:25:05 GMT

Associate NSG's to the vNets.

Azure has Any Drop until you associate an NSG and allow traffic , specifically for Standard SKUs

Re: Azure R81.20 Cloudguard Cluster Deployment

Simon_Macpherso — Fri, 30 Jun 2023 07:04:50 GMT

Thanks @Nir_Shamir

I have another issue whereby

I have provisioned a test VM in another VNET to test egress connectivity
The VM VNET and FW backend VNETs have been associated with the internal routable
The required routes have been added to the internal routable- default route is 0.0.0.0/0 with next hop IP the backend lb
Per the documentation, the 3 required routes are as follows.

default_route 0.0.0.0/0 VirtualAppliance 172.18.0.69 (backend-lb)

vm-01-vnet-local 172.19.0.0/24 VNetLocal

vm-01-vnet-other-subnets 172.18.0.0/26 VirtualAppliance 172.18.0.69 (backend-lb)
VNET peering has been setup between the VM VNET and the connectivity VNET (VNET FW subnets reside in).
Static route to internal subnet has been configured on each gateway i.e.
set static-route <Virtual-Network-IP-address/Prefix> nexthop gateway address <eth1-router-IP-address> on
Anti-spoofing has been disabled on both eth0 and eth1 interfaces
In Smart Console, a test VM object has been created and allowed access in policy, outbound NAT has been configured translating source to frontend eth0 external private IP.

I can see traffic hitting the active member including the a reply. But the on the VM the ICMP requests are timing out.

[Expert@checkpoint-cloudguard-ha1:0]# tcpdump -nnnei any host 172.19.0.4 and host 1.1.1.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
06:14:29.364296 In fc:bd:67:89:19:6e ethertype IPv4 (0x0800), length 76: 172.19.0.4 > 1.1.1.1: ICMP echo request, id 1, seq 352, length 40
06:14:29.366766 Out 00:0d:3a:66:8a:a3 ethertype IPv4 (0x0800), length 76: 1.1.1.1 > 172.19.0.4: ICMP echo reply, id 1, seq 352, length 40
06:14:29.366785 Out 00:0d:3a:66:8a:a3 ethertype IPv4 (0x0800), length 76: 1.1.1.1 > 172.19.0.4: ICMP echo reply, id 1, seq 352, length 40
06:14:34.107158 In fc:bd:67:89:19:6e ethertype IPv4 (0x0800), length 76: 172.19.0.4 > 1.1.1.1: ICMP echo request, id 1, seq 353, length 40
06:14:34.109671 Out 00:0d:3a:66:8a:a3 ethertype IPv4 (0x0800), length 76: 1.1.1.1 > 172.19.0.4: ICMP echo reply, id 1, seq 353, length 40
06:14:34.109692 Out 00:0d:3a:66:8a:a3 ethertype IPv4 (0x0800), length 76: 1.1.1.1 > 172.19.0.4: ICMP echo reply, id 1, seq 353, length 40

fw monitor -w -F <172.19.0.4>,0,<1.1.1.1>,0,0 -F <1.1.1.1>,0,<172.19.0.4>,0,0

[vs_0][ppak_0] eth1:i[60]: 172.19.0.4 -> 1.1.1.1 (ICMP) len=60 id=44093
ICMP: type=8 code=0 echo request id=1 seq=356
[vs_0][fw_2] eth1:i[60]: 172.19.0.4 -> 1.1.1.1 (ICMP) len=60 id=44093
ICMP: type=8 code=0 echo request id=1 seq=356
[vs_0][fw_2] eth1:I[60]: 172.19.0.4 -> 1.1.1.1 (ICMP) len=60 id=44093
ICMP: type=8 code=0 echo request id=1 seq=356
[vs_0][fw_2] eth0:o[60]: 172.19.0.4 -> 1.1.1.1 (ICMP) len=60 id=44093
ICMP: type=8 code=0 echo request id=1 seq=356
[vs_0][fw_2] eth0:I[60]: 1.1.1.1 -> 172.19.0.4 (ICMP) len=60 id=55497
ICMP: type=0 code=0 echo reply id=1 seq=356
[vs_0][fw_2] eth1:o[60]: 1.1.1.1 -> 172.19.0.4 (ICMP) len=60 id=55497
ICMP: type=0 code=0 echo reply id=1 seq=356
[vs_0][fw_2] eth1:O[60]: 1.1.1.1 -> 172.19.0.4 (ICMP) len=60 id=55497
ICMP: type=0 code=0 echo reply id=1 seq=356

Re: Azure R81.20 Cloudguard Cluster Deployment

Nir_Shamir — Mon, 10 Jul 2023 05:44:14 GMT

remove the FW Backed Subnet association from the Route Table.

I think it creates a loop and anyway , it shouldn't be associated to the peered vNets route tables.

topic Re: Azure R81.20 Cloudguard Cluster Deployment in Cloud Firewall

Azure R81.20 Cloudguard Cluster Deployment

Re: Azure R81.20 Cloudguard Cluster Deployment

Re: Azure R81.20 Cloudguard Cluster Deployment

Re: Azure R81.20 Cloudguard Cluster Deployment