A minimum 3 NICs are required and will be broken down like so:
- eth0 – Public / External Interface facing Internet
- eth1 – Management interface used for Cluster sync. Can also be used for security management server communication
- eth2 – First internal interface. Usually faces internal servers & load balancers. Can be used for security management server communication
The Deployment launch template has a few fields which aren’t explained very well…
Security Management Server address
A static route to this destination via management interface will be created a launch time. If the Security Management server is accessed via one of the internal interfaces, use a dummy address here such as 18.104.22.168/32 and add the static routes after launch.
This is the password to communicate with the Security Management server. It can be set after launch, but if already known, it can be set here to be pre-configured at launch
Automatically generate an administrator password
This will create a new random ‘admin’ user password to allow access to the WebGUI right after launch, which saves some time especially in situations were SSH is slow or blocked.
Note – SSH connections always require public key authentication, even with this enabled
Allow download from/upload to Check Point
This will allow the instance to communicate outbound to Checkpoint to check for updates. It’s enabled by default on most CheckPoint appliances, so I’d recommend enabling this setting
This is the real catch, and a pretty stupid one. The form fills out these three subnets:
- “Cluster External Subnet CIDR” = 10.0.0.0/24
- “Management external subnet CIDR” = 10.0.1.0/24
- “1st internal subnet CIDR” = 10.0.2.0/24
If using an existing network, erase the pre-filled value and then select the appropriate networks in the drop-down menus like so:
Also, make sure all subnets have “Private Google Access” checked
After launch, access the gateways via SSH and/or WebGUI to set administrator password. The deployment will create static routes for RFC 1918 space via the management interface. If these need to be overridden to go via an internal interface the CLI command is something like this
set static-route NETWORK/MASK nexthop gateway address NEXTHOP_ADDRESS on save config
Before importing in to SmartConsole, you can test connectivity by trying to telnet to the security management’s server address on port 18191.
In SmartConsole, create a new ClusterXL. When prompted for the cluster address, enter the primary cluster address. The easy way to find this is look the the deployment result under Tools -> Deployment manager -> Deployments
Then add the individual gateways with the management interface. Complete by setting the first (external) interface to private use, the secondary (management) interface as sync/primary, and subsequent interfaces as private use with monitoring.
After creation, there should be 3 settings on the cluster to modify:
- Set to use NAT
- Disable IP spoofing on all interfaces.
- Set the VPN domain (optional). By default, this is the 3 RFC 1918 CIDR blocks
Do a policy install on the new cluster, and a few minutes later, the GCP console should map the primary and secondary external IP addresses to the two instances
Failover is done via API call and takes roughly 15 seconds.
On the external network (front end), the primary and secondary firewalls will each get external IP address mapped. CheckPoint calls these “primary-cluster-address” and “secondary-cluster-address”. I’d argue “active” and “standby” would be better names, because the addresses will flip during a failover event.
On the internal network (back end0, failover is done by modifying the static route to 0.0.0.0/0. The entries will be created on the internal networks when the cluster is formed.
The script $FWDIR/scripts/gcp_ha_test.py is missing
This is simply a mistake in CheckPoint’s documentation. The correct file name is:
Deployment Fails with error code 504, Resource Error, Timeout expired
Also, while the instances get created and External static IPs allocated, the secondary cluster IP never gets mapped and failover does not work.
Cause: there is a portion of the R80.30 deployment script relating to external IP address mapping that assumes the default service account is enabled, but many Enterprise customers will have default service account disabled as a security best practice. As of January 2020, the only fix is to enable the default service account, then redo the deployment.
StackDriver is enabled at launch, but never gets logs
Same issue as a above. As of January 2020, it depends on the default service account being enabled.