topic Re: CheckPoint Cloudguard Iaas in Azure in Cloud Firewall

CheckPoint Cloudguard Iaas in Azure

Prabulingam_N1 — Wed, 10 Nov 2021 10:52:30 GMT

Dear Team,

Requesting anyone can help on the attached setup

Need to reach FROM internal VM 192.168.16.10 TO On-Prem VM 192.168.94.3 via ExpressRouteCircuit

We have VNET Peering between CheckPoint Vnet & ExpressRouteCircuit, ExpressRouteCircuit & On-Prem Vnet

1) CheckPoint Iaas Cluster in Azure Cloud
2) Internal VM (192.168.16.10, 17.10) has Route table pointing to BackendLB

Checked the packet capture in CheckPoint External interface: It leaves external interface, but not reaching On-Prem

How can i assure that this packet leaving CheckPoint External Interface passes via VNET Peering to ER Circuit and further

Any idea will be helpful.

Regards, Prabu

Nir_Shamir — Wed, 10 Nov 2021 11:39:26 GMT

Hi,

Does the Route table on the External Subnet of the Cluster points to the right default GW towards your On-Premise networks ?

Prabulingam_N1 — Thu, 11 Nov 2021 10:16:47 GMT

Hi Nir,

I had created Route table for Frontend (External) subnet with next hop as ER only (since I did not get default GW IP of OnPrem)

If I get default GW of On-Prem I will apply.

Meanwhile how can we make sure that traffic destined to On-Prem actually passes via VNet Peer (my cloud<-->ER)

Is there any I have to point towards VNet peering?

Regards, Prabu

Nir_Shamir — Thu, 11 Nov 2021 10:55:46 GMT

run 'fw monitor' on the Firewall to see the traffic.

you need to see:

i,I from incoming interface

o,O from outgoing interface.

if you have these four then traffic is going through the Firewall and exiting via the NIC.

Prabulingam_N1 — Thu, 11 Nov 2021 12:26:29 GMT

Hi Nir,

Yes I could see i,I,o,O the packet exits via External NIC of FW.

But how can we assure that this packet is passing inside VNET Peering and reaches other end On-Prem?

Or how can we force FW to send the packet inside the VNET Peering?

Regards, Prabu

Nir_Shamir — Thu, 11 Nov 2021 13:25:50 GMT

The only next hop the Firewall has is it's Azure Subnet Router on his Vnet. from there Azure takes charge.

You can contact Azure Support and they can see those packets in the backend and see if they are directed to the right place.