My notes on deploying Check Point CloudGuard IaaS solution on Azure

I was recently involved in an Azure deployment of Check Point CloudGuard IaaS solution so please allow me to describe some tips for remembrance.

There may be various reasons for one to deploy a security solution like this in any public cloud infrastructure, the main one being that usually it fits better customer’s cloud security requirements than using the provider native ones – and there are a lot of them out there!

The other reason may be that you are already accustomed to manage a solution from that provider on your on-premises infrastructure and want to keep the ease of management in a way that you prefer most. Or even… You may just want different vendors to analyse and secure your cloud environments.

Right after you choose to deploy this kind of solutions, another thing to consider is what provider to choose, but that is a separate topic on its so, let’s keep with Check Point (although I usually go for pfSense, but I’m biased…).

So, let’s proceed with my notes:

  • Typical Azure HA setup (the obvious choice for a core solution like this) will include both a back-end and a front-end Load Balancer object, so that your traffic can still get routed, even if one of your cluster nodes is down
  • Remember to always route your traffic to this Virtual IP object instead of the nodes themselves (you do this by creating Route Table objects and adding static routes to it)
    • Sub-bullet/note: the way that Azure and Check Point handle a node fail is by re-registering the “cluster IP” (the VIP address presented above) with one node’s Azure Network Interface Card, so make sure you follow the official documentation carefully
  • Also, remember to route traffic back from your Check Point to other Virtual Network’s subnets you may have behind it
    • Example: you may have an Application Gateway (with its respective subnet – i.e. 172.16.100.0/30) in use and its backend pool has Virtual Machines in subnets protected by Check Point – i.e. 172.16.50.0/24
    • Both subnets must have an associated static route present in their corresponding Route Table pointing to the same gateway (i.e. Check Point back-end VIP address will be 172.16.250.4/32) when trying to reach that destination network
  • Another important topic to mention about routing in Azure, specifically in Check Point’s case is that you may have to configure a static route in Check Point Gaia OS, destined to a non-Check Point subnet, where its next hop address will be the first IP address on that network.
    • Example: consider a subnet 172.16.21.0/24 that is not behind Check Point. If you want to keep traffic getting back to it, when sourced from a Check Point protected subnet, you should create a route in which the next hop is 172.16.21.1 (Azure “virtually internal” core switch IP address)
  • Another interesting topic that I would like to note on this blog post is NAT stuff. It works in a different way it does on a regular Check Point deployment for a typical and physically controlled setup
    • The front-end Load Balancer object I’ve mentioned before, created under Azure, routing traffic to each cluster node, has (or may have) a lot of public IP addresses attached to it. So, for the NAT part (like publishing an internal web server, for example) what you would do is something like this:
    • Example: Public IP (1.2.3.4) object is attached to frontend-lb object. Then you will create an LBR (Load Balancing Rule) that will translate the destined source (publicly available) port – i.e. TCP/443 – into the internally mapped (and received by Check Point cluster) port – i.e. TCP/50443. Lastly, you’ll created an inbound NAT rule that will convert traffic destined to LocalGatewayExternal object (created manually so, once again, don’t miss the documentation stuff) at network port TCP/50443 and forward traffic back to port TCP/443 to the internal host object
  • Last but not least and in case you’re not aware of it, Cloud Guard IaaS is able to integrate with Azure in a way that it can fetch objects from Azure AD, like Virtual Machines, Virtual Networks, etc. – directly from their API, by the way – so you don’t have to update them in your firewall device whenever they get an update in Azure
    • In regards to this, I would like you to take note that you cannot use this kind of objects for NAT stuff (why the HELL?!), but just policies, so just create regular objects for this stuff

Hope you like it and comment if you have any other tips you want to share with the community!

Join the Conversation

1 Comment

Leave a comment

Your email address will not be published. Required fields are marked *

%d bloggers like this: