Checkpoint Vsec ClusterXL deployment in Azure with Active/Active - Loadsharing mode

[Abhishek_Singh1]

Hi guys ,

I am looking for a solution to implement Active-Active (Load sharing)  clusterXL in Azure , but didn't find any templates  . Does checkpoint Vsec in Azure doesnot support this by design , or , What changes it would require to support this config ?

Thanks!

[Chris_Atkinson]

VMSS is typically the approach used for this in Azure, please see:
https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_VMSS_for_Azure/Default.htm

[PhoneBoy]

The multicast traffic required for traditional ClusterXL (Load Sharing or otherwise) is not supported by public cloud providers.
However, you get "active active" deploying as a VMSS, which incorporates load balancers into the design.
It's not Clustering, which means the scalability is significantly better.

[Abhishek_Singh1]

Thanks @PhoneBoy  , @Chris_Atkinson  for your responses . 

I am running a POC to implement the VMSS in Azure to utilize both the gateways . 

I believe because of the dynamic nature of the Gateways being scaled out/in we cann't use the traditional Gateway object in the policy rules cells ( Source , destination , Install On) . 

Refer attachment for reference on the existing policy .

Can you help me out what object I shall use in the standard policy of Firewall management , Stealth rule , MTA specific rules ??  -- Is it the dynamic "LocalGateway" object ? 

Also how we manipulate the Gateway specific settings for the VMSS gateways , that we used to do using SMS - editing the GW object properties - like enabling MTA , configuring HTTPS inspection , etc ??  -- I mean do we need to change these properties for all the gateways being spinup during scale out event manually ? Or is there any setting approch in the auto-confi provision files to handle this ?

Regards,

Abhishek

[Tommy_Forrest]

It's not a good idea to use the actual firewall object in your policy.  That's because if Azure scales up or down (and especially down) the objects are no longer valid.

What I did (after setting the Min/Max/Def to 2/2/2) was create secondary FW objects and put those into the policy.  The manager complains every push or FW modification because of duplicate objects.  But it works.

If you have to host inbound traffic, you should be looking at those setup steps now too.  It's an utter pain in the rear.

Probably the coolest thing I've seen is autoprovisioning doing its thing.  Azure adds a firewall and autoprovisioning does the rest.  Which is super cool, but I lost 2/3rds of the hair on my head getting it all going.

I still need to figure out how to modify autoprovisioning so that it will deploy all of our machine level settings (TZ/passwords/routes/usernames/etc).

Also, you don't need to define a gateway to "install on".  That's done in your autoprov script and is taken care of for you automagically.

[Abhishek_Singh1]

@Tommy_Forrest  - so you have created the secondary gateway object after spinning the firewalls from autoprovisioning... 

Did you faced any issue with using the dynamic object - "LocalGatewayExternal" In policy rules as source / destination?? 

About inbound traffic, we have the usercase of using Checkpoint gateway as MTA, do you have any experience with this regard?? --- hence was my query second part... How we manipilate the gateway objects global properties - blades, https inspection, MTA, etc in  gateways being spin-up by VMSS autoprovisioning template. 

@PhoneBoy  -- can you pls guide me here with any official recommendation(s) ??   Or, may be tag some more folks who have an prior experience with VMSS deployment

[PhoneBoy]

The dynamic objects LocalGateway or LocalGatewayExternal can safely be used.
In the past (pre-R80.10), there was a performance penalty to use these objects (not SecureXL friendly) but that issue has since been resolved.
I would do this over using secondary firewall objects.

As for what blades are enabled as part of the provisioning process, that's actually controlled on the management server.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Abhishek_Singh1]

Thanks @PhoneBoy   .Do we have control on adding specific route, enabling MTA settings with custom specs?? May be in autoprovisioning file, or some sort of script. 

[PhoneBoy]

If it requires setting specific properties on the gateway object and they can be set via the API, there is a way to set those.
See the SK I specified previously.
Not sure you need to change routes on the AWS instance as that doesn't really have an effect, given the way VPCs work.
That said, the gateways are created using an autoprovision.json file that I assume you can modify to do what is required (the user-data section, I believe).

[Abhishek_Singh1]

Thanks @PhoneBoy  for sharing the details . However , I dont see any management API command to manipulate the MTA config ( adding mail domain , next hop  ) Refer the attachment - Desired setting for MTA.

Also , now I am a bit confused between  CME (Cloud Management Extension )  and Autoprovision Add-On.  There is a latest update on 23-Sep-2019 to the checkpoint official VMSS deployment guide and it talks about using the CME .

The CME has a limitation of not working in parallel with Autoprovision Add-On . Please refer the attachment -

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_VMSS_for_Azure/Default.htm

Do we have any guidelines what should be used and recommended between these two , whats the advantage/disadvantage of using these respectively ( CME Vs Autoprovision add-on ) .

[PhoneBoy]

Based on the screenshot you provided, I assume these are modifications to the gateway object, some of which may not have a specific API exposed to modify.
They may be doable with Generic Objects, but recommend asking that specific question in the appropriate space: https://community.checkpoint.com/t5/API-CLI-Discussion-and-Samples/bd-p/codehub

My understanding is that CME supersedes the Autoprovision add-on.
The configuration steps are similar in either case.