VSEC - Deployment guide - Check Point CheckMates

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

10 Replies

Vladimir

Champion

‎2018-01-2410:00 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Alan,

Please check the Deploying a Check Point Cluster in Microsoft Azure for details. I've done quite a few AWS vSEC deployments, but didn't get my hands on Azure yet.

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Participant

‎2018-01-2410:08 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Alan,

You can follow sk110194 to deploy a cluster in Azure.

The short short description.

Define a vNet

Define a Frontend Subnet within the vNet

Define a Backend Subnet within the vNet

Deploy CheckPoint vSec Cluster from the marketplace

Follow the steps to deploy. This will take about 10 minutes once you complete all the steps.

Enable vSec on the management server via CLI. Command is vsec on

Create a new cluster object in your domain. Use the public IP created for the cluster as the cluster IP

Add each object to the cluster

Set both interfaces as sync only

You will need to create a service principal that has contributor rights

Run the command azure-ha-conf --client-id (with client-id from the service principal here) --client-secret (with the key created when you created the service principal here) This needs to be done on each firewall in the cluster.

Run the command $FWDIR/scripts/azure-ha-cli.py reconf This also needs to be done on each firewall in the cluster

Install your vsec license in the domain where you are deploying vSec.

Attach the license to the CMA.

Go to CLI of the management server and change to the domain environment mdsenv domain-name-here

Run the command vsec-central-license

That is the very short version.

Hope that helps.

1\ \ \ Kudo

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Vladimir

Champion

‎2018-01-2411:41 AM

In response to John_Parnell

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

John,

can you expand on "Set both interfaces as sync only"?

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Participant

‎2018-01-2811:33 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

In response to Vladimir

Vladimir,

This is done under network management in the cluster object with SmartConsole. So the cluster for the most part is created just like any other cluster. Except with the interfaces. You have options like private, cluster, sync, and cluster + sync. Here we choose sync then use Azure route tables to direct traffic to the active firewalls interface. If the firewalls fail over they will use the python script to change the route table to point to the active firewalls interface. This used to take up to 3 minutes to complete, however now I generally see times as quick as less than 1 second.

I hope that better explains.

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Vladimir

Champion

‎2018-01-2812:44 PM

In response to John_Parnell

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Thanks.

Still hard to visualize: I am not getting which "both" interfaces you are referring to.

Since you've described FrontEnd and BackEnd vNets, I'd imagine each cluster member should have at least three interfaces, unless you are using Cluster + Sync, in which case it may be two.

I'll probably have to go through deployment myself in order to get a better feel for it.

Regards,

Vladimir

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Participant

‎2018-01-3006:42 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

In response to Vladimir

No each cluster will have two interfaces by default. You will have eth0 and eth1. eth0 will be your frontend interface, which is just what Azure calls it, but it will set your default route to go out this interface. eth1 will be your backend interface. There is not VIP to define. So if your frontend subnet is 10.10.10.0/24 eth0 will get assigned 10.10.10.4 for firewall1 in the cluster and firewall2 will get 10.10.10.5. Your backend subnet must be different from your frontend subnet so lets give it 10.10.20.0/24. eth1 will get 10.10.20.4 for firewall1 and firewall2 will get 10.10.20.5. There will also be a public IP set as an alias to firewall1 on eth0. You will set a route table to direct traffic from your other subnets to point to the active cluster members eth1, so lets say 10.10.20.4. If you failover the firewalls the python script on the other firewall will reach out to Azure and change the route table to point 10.10.20.5. So as you can see there are no cluster interfaces in Azure. You just set both eth0 and eth1 to sync.

I hope this better describes how it works.

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Alan_Camelo1

Contributor

‎2018-01-2602:54 AM

In response to John_Parnell

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Many Thanks,

I shall have a look and let you know how I get on.

I'm sure there may be a few more questions due to my lack of knowledge of Azure at the moment, some terminology things like "Define Frontend subnet within Vnet" ? is this done within Azure or on Vsec?

Thanks again in advance!

Alan

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Participant

‎2018-01-2811:37 AM

In response to Alan_Camelo1

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Alan,

Both are done in Azure. During the deployment of the firewall cluster you can create both a new vNet(Virtual Network) and the front end and back end subnet.

I hope that helps.

Kudos