Azure R81.20 Cloudguard Cluster Deployment

[Simon_Macpherso]

Deploying R81.20 cloudguard cluster using the following IAC.

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

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. 

[Nir_Shamir]

Associate NSG's to the vNets.

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

[Simon_Macpherso]

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

[Nir_Shamir]

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.