Checkpoint Lab - 9 (Policies and DB versions) Tutorial

Before we discuss the policies and db versions lets start expanding our lab a little bit. We will start working on the Branch Office setup and Branch Office DMZ configuration. Go ahead using the previously discussed steps in LAB-4. Set it up a Security Gateway/Firewall only for Branch Office. We will use the existing Manager to connect to both the firewalls (Main and Branch Office).
Assuming you are done installing the firewall and are ready to add it to the Manager, we first need to create rules for manager to access the branch Office firewall. To add it to the manager, this time we will use the wizard mode (Previously we used classic mode)

Once you select the Wiz mode you will see the screen below - Select the external ISP ip 10.100.100.253 and Gateway name appropriately.

Click "Next" and enter the one time password for the manager to establish SIC.

And as expected it will fail. The manager will not be able to connect since its in the internal Main office. For it to reach the branch office firewall we need to NAT the manager traffic to use an external ISP IP address. Refer the below screen print.

Double click the "Manager" object and in the NAT assign it a public ISP address, select MainOffice_Firewall on the install on gateway option and check the Apply for security gateway control connections. This option means use this NAT to manage any other firewalls via this manager.

Now try establishing the SIC communication again between the manager and the BR_Firewall with the NAT in place the devices will communicate and trust will be now established.

Earlier chapter covered how to create policy now lets try to create a consolidated policy that can be applied on multiple firewall gateway since its not feasible to maintain different policies for different firewall, it can be confusing and tedious. So below is the example on how to create single policy and push it to multiple gateways.

 The first management policy can be applied to all the firewall gateways in the company. So the destination would include both the firewalls. Same applies to the Stealth, Netbios and cleanup. The install on will actually decided which device the policy will be applied. If the "Install on" is "Policy Targets" it will be pushed to all the gateways. For targeted deployments just chose which device it needs to go to. Form the above above example - "Main Office rules3-4" will get pushed to MainOffice Firewall and "Branch Office Rules 5-6" will go to the Branch Office firewall. When the policy is pushed you will be presented with both the devices selected and we can opt out at this point as well to where the policy goes.

Don't forget to dynamically NAT the inside traffic going external for both Main and Branch internal networks. You can select option "Hide behind gateway". Choose the appropriate firewall device on with this will be deployed as well.

Now lets take a look at the DMZ policies that were implemented as per our lab setup. Assumption - DMZ servers at both sites will be running web and ftp services. First the DMZ server objects needs to be defined as Nodes.

The DMZ server at MAin office DMZ - 172.16.1.2

And we are enabling a static NAT to a public IP - 10.100.100.205, the ip that can be accessed from "outside" the network by clients. This would add the NAT rule automatically - 

Outbound - 
Original Pkt - Source - DMZ server (172.16.1.2) , Destination - Any, Service - Any
Translated as - Source - DMZ server NAT ip (10.100.100.205), Destination - Same as Original pkt, Service - Any

So when the server initiates outbound connection like a response to client 1.2.3.4, the packet inside the DMZ network before it hot the firewall would be
Src - 172.16.1.2, Client - 1.2.3.4, Port 80
and when it leaves the firewall interface that packet will be modified as
Src - 10.100.100.205, Client - 1.2.3.4, Port 80
This way the client cal talk back to the 10.100.100.205 ip since it does not know the private DMZ ip 172.16.1.2

Inbound - 
Original Pkt - Source - Any , Destination - DMZ server (172.16.1.2), Service - Any
Translated as Source - Same as Original pkt, Destination - DMZ server NAT ip (10.100.100.205), Service - Any
Same rule applies for an inbound connection as well. When a client 1.2.3.4 connect to DMZ server to consume ftp service, before the packet hits the firewall - 
Src - 1.2.3.4, Client - 10.100.100.205, Port 21
After it hits the firewall - 
Src - 1.2.3.4, Client - 172.16.1.2, Port 21
The red S symbol implies that the object has a Static NAT, Similarly H implies its a hide NAT.Now we create the policy as below where we specify the services and on what firewall that this rule must be applied.

Similarly configure the branch office DMZ server  and group the Common (go on both), Main office - HQ_Firewall, Branch - BR_Firewall and you should have something like below -

Database -

Checkpoint gave admin's a great option to backup the policies and objects that are created. This options is presented when the policies are being installed on the gateways. By giving the option to backup we can take easily recover when a bad policy is deployed and cause an outage. Using the previously taken backup we can restore in matter of min and then investigate what happened with the bad policy at leisure.

Once you hit "OK" a backup is created and stored in the database of the manager. To view options of the backups, go to File--> Database Revision Control option. I created multiple backups when building the lab and it looks like below - 

There are diff options you can configure
You can rotate/restrict the number of backups that are saved on the system.
Select "Automatically delete old versions - Configure" tab

Multiple options are available on how the versions can be retained. Since this is a lab setup I choose 10 options. It also depends on how much disk space was allocated during the initial install.
If you want to lock on to a backup which you know is good and can fall back to
it as safety net you might want to mark that as "don't delete" copy. Select the db version and click "Properties" tab and choose - "Keep this version from being deleted automatically." This options will display a crossed trash can which visually indicates that it will not be deleted when the version deletes happen.

The restore can be done by clicking "Action" and selecting the "Restore Version"...since its a lab setup...try deleting few objects and rules and use this option to check if the deleted items are restored correctly. "Remove Keep" will negate the "Keep this version" option and will enable the policy to be deleted. "View version" will open that version in a new dashboard instance.