In this blog, we will setup a Checkpoint lab using virtualbox and gns3 on windows.
Introduction
In this lab we implement a basic security architecture to demonstrate the operation of a firewall cluster to protect our network. Our “security domain” is segmented into four zones:
- management: only for management, operation and control purposes of equipments and services.
- intranet: our secured ressource
- internet: the untrusted network
- and dmz; the part of our network (trusted) that faces internet
Security topology
Our security topology is compound by two security gateways (SG) that are managed by a single security manager server (SM). The SG gateways (firewall) are in the same cluster such as to appear as a single entity to the rest of the world.
A management PC is configured with Check Point utilities such as: SmartDashboard, SmartUpdate, SmartView Tracker, and PuTTy for remote access to the gateways and manager using SSH. This PC belongs to the management network that connect only management interfaces. This network is physically separeted from the production trafic still that some ressources (memory, CPU, disk) may be sharable at single physical nodes…
Three routers emulate the operation of intranet, internet and dmz, are directly connected to both gateways: R3 connects intranet ressources, R2 simulates internet access and R1 our internet exposed servers…
The following topology summarizes this implementation:
Topology implementation
In the following we implement our security topology. First of all with create our instances or machines that will act as the security gateways and the security manager in our virtual environment, virtualbox, then we’ll connect those machines to the network provides by the host (windows) for them to join each other and the network from gn3. As soon as the network is available, the dashboard is ready to connect to those instances, to start the configuration of our SG gateways. We push our fist policy and check on smartview that this policy is in action.
Machines in virtualbox
To implement this architecture we first emulate gateways and manager using Oracle VirtualBox (installed on Windows). In figure we show the 3 emulated VM supporting: SM, SG1 and 2. We used this .iso image to build our VMs: Check_Point_R77.20_T124_Install.Gaia.iso.
Networking for virtualbox machines
Now that we created the virtual machines in virtualbox, will create the equivalent of subnets to connect those machines network interfaces in the correct security zone.
Next, on a windows 10 64-bit operating system we create 4 VirtualBox Host-Only Ethernet Adapters (loopbacks) that represent each a security zone such as in the figure:
These adapters correspond to the switches: Mgmt, Intranet, Internet and Dmz, in our topology. We configure them with the corresponding .254 ip addresses.
Map firewall interface to the correct network
In VirtualBox we map each loopback (adapter) to the corresponding firewall physical interface: MGMT adapter to eth0, INTRANET to eth1, INTERNET to eth2 and DMZ to eth3. We do the same for both firewall. If we need to add another device interface in any of those zone subnet we just map them.
After the interfaces are mapped, the next step is to configure to IP for them to be able to communicate.
Security gateways and security manager need to be configured with the correct ip addresses in the management network from the console (CLI or command line) at initial install or using this command afterwards :
Some ping tests
At this stage we could check that all firewall are pingable from the corresponding consoles. On the management PC we install the Check Point management suite: Check_Point_SmartConsole_and_SmartDomain_Manager_R77.20_T124_Windows.exe.
Our SG gateways in the SM
We gain access to SM using SmartDashboard and add our security gateways. In this procedure SIC (that stands for Secure Internal Communication) is used to establish trust between gateways and security manager.
SIC procedure
At the gateway level, SIC is initiated in expert mode by cpconfig command. At the security manager level, SIC initialization is done using SmartDashboard as show in this figure:
SIC operation is handled by cpd process and it is based on PKI and SSL/TLS. The gateways listen on TCP ports 18211. Traffic from the gateways to SM on TCP port 18209 should be also permitted. Another requirement for SIC to succeed is time synchronization within few minutes.
Also included in SIC procedure:
- SM Internal Certificate Authority (ICA) generate both SM and firewall certificates (SMS-cert and FW-cert).
- The initial established secure communication tunnel, using the One-Time SIC Activation Key, helps provide the gateways with this information.
SmartUpdate
We use the Check Point SmartUpdate (that provides a centralized way to guarantee that internet security throughout the enterprise network is always up to date) to check the attached licences like in the following figure :
Evaluation licences could be easily retrieved from Check Point UserCenter in case some of them are needed. They are valid for a month which is more than enough. Thank you Check Point!
Now that we’ve set up our 3 VM machines (SM, SG1, SG2) and get them synchronized (Host interface using Windows loopbacks) let’s move to our network configuration using GNS3 (our network emulator). In GNS3 we connect router R3 to the intranet network also defined by the corresponding security zone. The R2 router emulated internet access. Routers R1 and R4 are in our DMZ.
Moving to GN3 world…
In GNS3, we add 3 routers: R1, R2, and R3 corresponding to different security zones that are represented by cloud objects. Each cloud object maps to its corresponding Loopback (previously created) and through those loopback to virtual box objects thus VMs.
When adding links from routers to cloud objects we may encounter this error in GNS3 console.
As a workaround we apply this command in cmd: sc config npf start= auto, and restart the PC.
Back to our gateways and push the policy
From SmartDashboard (connected to our SM) we’re ready to get gateway topology information,
and push our first policy (with traceable rules) that allows our management traffic and a test traffic (pings) from dmz router (R1) to intranet (R3) using their directly attached interfaces to zones.
To achieve this we configure our routers with default routes to firewalls.
SmartView in action
A quick wrap up
In this post, using only a windows PC we’ve created 3 VM machines to emulate our firewall (gateways) and their manager (SM). 3 loopback interfaces was created on windows to simulate a switch operation to connect those VM interfaces to the cloud objects in GNS3. Each cloud in GNS3 maps to the corresponding VM interface through the windows interface (internal switch). GNS3 clouds connects the corresponding emulated routers (networks). These routers are logically separated and any trafic from those router should pass by the cloud objet reach the loopback windows interface before reaching the VM interface at the firewall where the policy is applied…
