CloudGuard Network for Azure VMSS Gateway Load Balancer (Public Preview) VXLAN issue

[leonfranken]

Hi all,

Microsoft just announced Azure Gateway Load Balancer to be in Public Preview.
Check Point published the following article about this:

https://blog-checkpoint-com.cdn.ampproject.org/c/s/blog.checkpoint.com/2021/11/02/check-point-cloudg...

Configuration steps can be found at: 

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_Azure_VMSS_GWLB/Content/Topics-Azure-...

This weekend I've tried to set this up. Basically the setup is almost identical to a normal CoudGuard Scale Set. The only difference is the fact that you need to forward traffic from a Azure Standard Load Balancer (ASLB) using a VXLAN tunnel to the Azure Gateway Load Balancer (AGLB). The AGLB forwards the traffic to one of your CloudGuard instances using VXLAN as well. The problem I am facing is the fact that no VXLAN interfaces are deployed in my CloudGuard instance. Documentation doesn't mention configuring these interfaces yourself.

Troubleshooting steps I took:

• tcpdump on eth0 shows UDP port 2001 coming from the AGLB. This is the VXLAN tunnel port.
• Created the external VXLAN tunnel interface using: add vxlan id 801 dev eth0 remote <AGLB_IP> dstport 2001
  after this a tcpdump on interface vxlan801 immediately show my actual test traffic arriving
• Created the internal VXLAN tunnel interface using: add vxlan id 800 dev eth0 remote <AGLB_IP> dstport 2000
• The Known Limitations describe that the solution uses bridge mode. I did create a bridge group containing both the vxlan800 and vxlan801 interfaces but without any difference.

I am not sure if I am missing some steps in the deployment or if there is an issue with the Azure template.

Hopefully other CheckMates members can share their experience!

Leon

[arielto]

Hi Leon, 

The VXLAN tunnels don't require user configuration as they are configured automatically by the Cloud Management Extension (CME).

After completing step 3 in the admin guide, each GW will establish a VXLAN tunnel to Azure Gateway Load Balancer automatically.

Thanks,

Ariel

[leonfranken]

Hi Ariel,

Thanks for your reply!

Should I see actual vxlan interfaces in the Gaia config?
Only interfaces I have are eth0 and enP37229p0s2 (Hyper-V VF nic).

Thanks,
Leon

[roye]

Hi Leon,

In order for the CME to configures the VXLAN tunnel, the Security Management server must be R81.10 and the CME needs to be from take 168 or above (autoprov_cfg -v).

Can you verify these prerequisites?

The VXLAN interfaces should appear when running 'ifconfig' command from expert mode and their names are: vxlan800 and vxlan801.

Regards,

Roy

[leonfranken]

Thanks for your reply Roy!

That's the problem 😠
I am running CME Version: Build: 991592117 Take: 164

I used the cme_installation.sh from sk157492 and made the assumption it would install the latest version, which it didn't.
Just performed the offline installation of take 168 and will test again. Keep you posted!

Thanks

Leon
 

[leonfranken]

Hi all,

So using the correct CME version solved 99% of my issues 😉

The final 1%:

As described in the documentation:

As a part of each CloudGuard IaaS Security Gateway provisioning process, the Security Management Server creates automatic Access rules to allow tunnel traffic between the Gateway Load Balancer and the CloudGuard IaaS Security Gateway. By default the automatic Access rules are created at the top of the rulebase.Sometimes it is recommended to add the rules in a specific place in the policy rather than at the top.

The only rule CME creates is from the Azure Gateway Loadbalancer IP to the CloudGuard gateway(s) for both port 2000 (internal VXLAN tunnel)  and 2001 (external VXLAN tunnel).

I noticed that the CloudGuard gateway was dropping traffic initiated by itself towards the Azure Gateway Loadbalancer IP on both port 2000 and port 2001. This resulted in the VXLAN tunnels not being established and therefore traffic did not arrive on my VM's.

Manually adding a rule allowing 2000 and 2001 from my CloudGuard gateway(s) to the Azure Gateway Loadbalancer IP resolved it.

Anyone experienced the same?

Thanks

Leon

[roye]

Hi Leon,

We are investigating the issue you described and will update this thread when we will know more.

It seems that these rules are required when the following Implied Rule is disabled: "Accept outgoing packets originating from Gateway".

Regards,

Roy

[leonfranken]

Hi Roy,

Implied rule "Accept outgoing packets originating from Gateway" is indeed disabled in my environment.

Thanks,

Leon

[arielto]

Hi Leon, 

We will add this support in a future release of CME.

Meanwhile, you can create another access rule with LocalGatewayExteral as the source, and it will work for all the newly created instances.

Thanks,

Ariel

[roye]

Hi Leon,

The issue with the automatic rules was fixed in CME take 175.

Regards,

Roy

[leonfranken]

Hi @roye 

That is great! Thanks for the update!

BR,

Leon