Healthchecks actually originate from GCP directly, rather than the load balancer instance itself. So these networks must be whitelisted in the firewall rules:
35.191.0.0/16130.211.0.0/22By default, load balancers operate in regional-only mode. To switch to global, edit the frontend properties and look for this radio button:
A minimum 3 NICs are required and will be broken down like so:
The Deployment launch template has a few fields which aren’t explained very well…
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 1.2.3.4/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
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
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:
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 using public key and/or WebGUI to run through initial setup. The first step is set a new password for the admin user:
set user admin password
set expert-password
Since eth1 rather than eth0 is the management interface, I would recommend setting that accordingly:
set management interface eth1
I would also recommend adding static routes. 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
Before importing in to SmartConsole, you can test connectivity by trying to telnet to the security management’s server address on port 18191. Once everything looks good, don’t forget to save the configuration:
save config
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. Walking through the wizard, you’ll need to define the type of each interface:
Note the wizard tends to list the interfaces backwards: eth2, eth1, eth0
The guide lists a few steps to do within the Gateway Cluster Properties, several of which I disagree with. Instead, I’d suggest the following:
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.
This is simply a mistake in CheckPoint’s documentation. The correct file name is:
$FWDIR/scripts/google_ha_test.py
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.
Same issue as a above. As of January 2020, it depends on the default service account being enabled.
The first step is to create a new object with the public IP address of the other side of the tunnel. This is fairly well buried in the menus:
After that, create a new VPN “community” in Objects -> More object types -> VPN Community -> New Meshed VPN and walk through the wizard.
The main gotcha is watch out for weird default settings. In particular, AES-128 is disabled as encryption cipher for Phase 1. My guess is since it’s the most popular cipher for Phase 2, they go with the “mix ciphers” strategy. But personally I just like to use AES-128 for everything – it’s simple, fast, and plenty secure.
Layer 77 