Checkpoint

Checkpoint – SMART Update, Remote Access VPN and High Availability – Part VI

Smart Update :

As we know in any firewall, there is OS, patches, hotfixes, licenses are installed on the system. And time to time we need to upgrade them. And we want to do these upgrades remotely instead of going near the device and do the upgrades.

And to do that we have this wonderful tool named : SMART Update

License Management :

Central : Links licenses to the IP of the manager. Means manager is centrally controlling the licenses on the devices. Either it can be in unattached state (means license is not even assigned to any gateway)

OR in Assigned State : means license is assigned to gateway but not installed

OR in Attached State : means license is assigned and installed on the gateway and gateway is using that         license.

Local : Link license to IP of the gateway. Means license is associated with particular gateway IP and that license won’t work anymore if that IP address is different.Means we have to do some more backend work to get that updated information for the new license.

Preferred method of do licensing is central.

Sources to get the License : Download Center , User Center , DVD

Licenses are stored in $FWDIR/conf file system.

And from SMART Update we can verify the version of software running on our managed gateways, what features are they running , how their licenses are doing (Are they about to expire) and from those reports we can do proactive management and take necessary action before they expire.

Proactive management includes : Download updated license information, patches and updates and then using SMART Update to deploy those updates.

Either they are software updates or license updates.

I am going to showcase this in demo mode as we are using the virtual environment and there is no license info in that.

To check which all licenses are expiring in next let’s say 30 (we can modify number of days) days :

Go to Launch Menu — License and contracts — See expired and below window will open :
cp1.png

Click on any license and click on properties to see all details/properties related to that license.

There are two tabs which shows the gateways installed and what package is running on them.
cp2.png

Also to see the repository :

There are 2 type of repositories :

  1. license Repository : Go to Launch Menu — License and contracts –View Repository

double Click on any license installed to get more info on that like expiry date.
cp3.png

To see Package repository :

Go to Launch Menu–> packages–> View Repository
cp4.png

Also there is a task bar at the top having shortcuts of all the possible options :
cp5.png

Just go over any icon and it will show what it can do for us.

There is a pre-install verifier feature also which tells us three things :

  1. packages are appropriate for the gateway and SIC is in place between manager and the device.
  2. it checks the disk space.
  3. it also verifies if that package has already been pushed out to that gateway or not.

go to Launch Menu –> go to packages –> click on get data from all to see all details
cp7.png

It tells us on what OS the gateway is running and we can upgrade all packages, install/uninstall/reboot the gateway and even launch the GAIA HTTPS portal from here itself.

To add any package from your PC : there is an option to add packages from File in the option set we earlier shown.

As we are using the evaluation license of 15 days : So this is showing in trail period expiring on 31Jan.
cp6.png

Additional Check Point Features :

Remote Access VPN : As we know there are 2 types of Remote Access VPN are generally used.

  1. IPSEC RAVPN
  2. SSL RAVPN

In this series we are strictly going to discuss SSL VPN on a checkpoint firewall.

Like IPSEC, With SSL also we can also build a VPN tunnel from the user to the corporate network Eg : we can give the user the SSL portal and he connects to a specific URL to the firewall and authenticates and after authentications we can give him specific URL so that he can log in or click on to access resources in the company.

Traffic from user’s PC will go encrypted till the firewall and then access the resources and return traffic also gets encrypted from gateway to user’s PC.

This gives user the access to internal resources without giving virtual IP of the corporate network.

Another option is to use a “Full Client” (Like Cisco Anyconnect mobility client) is a software which user can download on his PC  and have a IP address of the corporate network.

So there are generally two type of access :

  1. Clientless (Via Portal)
  2. Client (Like Full client or Cisco Anyconnect mobility client) : IP address is given in this type

Full Client also does inspection of user’s machine so that no vulnerabilities occur.

Now to allow the RAVPN, first enable the feature on the firewall :
cp9.png

Once we enable the feature , it will ask for which type of clients we want it to connect. Click on little “?” to see what licenses it requires for those features. See the example for SSL VPN Portal.
cp10.png

Click on Next, and it will ask for Portal URL. Generally this should be outside interface IP as user connects to the outside IP on the firewall.
cp11.png

Also import the CA signed certificate if you have. For now here, i am using the self signed certificate.

Click on Next, and configure applications that users can access after connecting. Here i am giving IP of our DMZ server : 172.16.1.50

And here we don’t have any mail exchange, so, I am not choosing anything.
cp12.png

Click on next and it will ask for AD details for authentication of users. As we are using lab.com domain so we test this connectivity and once it is successful then click on next.
cp13.png

Now, it will test the access to application resources : Click on run test and it should be successful.
cp14.png

Click on next and select which users are allowed to access the application resources. Here I am choosing my LDAP group.
cp15.png

Click on Next and then final window will appear and click on finish.
cp17.png

Once finished but we still want to make any changes then click on firewall and click on remote access on the left side and make changes according to your need.

cp18.png

Save and push the policy.

Now, browse the portal with below URL :

https://192.168.10.100/sslvpn

and it will give error of self signed certificate click on advance and you’ll see below portal :
cp19.png

give away the credentials and yeah…… you see the application server :
cp20.png

Click on it and you can see the server web page.
cp21.png

And if you want more functionality and want to assign own IP address assign to us eg : office mode that would require us to install a client on the user computer.

Data Loss prevention :

Not giving away the information that shouldn’t be available publically. Like credit card info of million users if you have in your database.

Similarly we have other features like : IPS, Anti-Bot, Anti-Virus, Anti-Spam and Email Security and QOS blades.

SMART Log :

To enable the SMART LOG, below feature should be enabled on manager.

cp22.png

and you need some hardware requirements also to run the SMART log. In virtual environment I have limited memory and hence can’t run.

Similarly we can do lot more things in SMART events, IPS, Anti-Bot, Anti-Spam, QOS features.

Like if we want to block traffic (From and To) to any country and do this in IPS :
cp23.png

Also if we want to enable some network exceptions then we can include those subnets in the list.

In SMART Events, if we want to block any source of the attack then in SMART Event, do this :
cp24.png

HA Functionality :

Now, we are going to deploy HQ firewalls in HA cluster, and then we’ll try to establish VPN connection with the remote firewall.

For that, first let’s deploy the secondary firewall at HQ named : HQFW2

complete the installation as we did for our HQFW1. Only thing to remember is during first time wizard make sure we make it as a part of VRRP cluster.

So this topology will work like this :Please refer the topology mentioned in series 1, for HA set up please refer the below topology :

HA Topology :
cp25.png

The whole topology will be same as I showcased in blog 1 except the HA cluster on the HQ side.

So, We’ll be using .101 address as HA address.

For Example : HQFW1 : 10.1.1.100 (Internal interface IP address)

HQFW2 : 10.1.1.102 (Internal interface IP address)

And 10.1.1.101 will be the virtual address of the cluster.

Similarly, 192.168.10.101 and 172.16.1.101 will be the virtual addresses of Outside and DMZ interfaces respectively.

Once the firewall gets boot up perform these 2 steps to enable clustering on the firewall :

1.invoke cpconfig and enable clustering

2.configure VRRP using the web UI or the command shell
cp26.png

Once it’s comes up after first time installation wizard then open GAIA and configure the interfaces like this :
cp27.png

Now, configure VRRP on both the gateways through GAIA.
cp28.png

This is for the Primary HQFW1 where we have set the VRRP priority as 105 and delta priority as 10.

Delta priority : how much priority will decrease once the link/device will become unavailable.

Similarly, for Secondary HQFW2 firewall :
cp29.png

Priority is default means 100 and I have only enabled preemption only on primary firewall.

Now from here, I will showcase everything in R80.10. GUI interface in R80 will be little different which I’ll discuss later but for now let’s go for HA.

First discover both the firewalls in Smart Console and then include them in the cluster.

Here, I’ll discuss how we can configure HA in checkpoint strictly. For more explanation on HA I’ll share checkpoint link if one wish to read this in depth. For now let’s implement this on GAIA R80.10 .

To do this in R80.10 : Go to Gateway and Services :
cp30.png

Choose Cluster here : Below screen will appear and now give the virtual IP of the firewall to discover the cluster. Here 10.1.1.101 is the VRRP virtual IP of the internal interface on HQ firewalls.

Here, I am enabling IPSEC VPN blade only to test this with HA.
cp31.png

Click on Clusters members to add the gateways :

cp32.png

Here we have added HQFW1 and HQFW2 as a part of our HQ cluster named as : HQFW

In Cluster XL and VRRP choose below option :
cp33.png

I have chosen VRRP here.

Now click on network management and make sure you get the topology of both the gateways. Click on get interface and then edit those interfaces :
cp34.png

When we edit the topology interfaces then we define our cluster interfaces individually and which interface we want to use for sync the topology.

Here, I am editing my internal interface :

In network type I have selected cluster + sync, other options are : cluster , sync , private.

So, based on requirement we can choose the interface type.

Also it tells us the cluster member IP’s and security zone and anti-spoofing information.

Click on Advance tab to see the interface included, their names and multicast info.

Also, here we can define or select which interface we are going to monitor.
cp35.png

Click on ok now and below cluster will be seen on the smart console.
cp36.png

Here under Gateway and Services tab we can see the cluster and its members.

Now define rules under security policies and push directly on the cluster and it will eventually push on both the gateways which are the part of the cluster.

Also make sure we allow VRRP Multicast IP 224.0.0.18 so that both firewalls can see each other.

Via CLI also we can see the status :

Below command List cluster status :
cp37.png

Here, we can see both the firewalls are active at the moment and local firewall IP is 10.1.1.100.

To see the HA interfaces :
cp38.png

Here we can see what interface is selected for sync and virtual IP assigned to the interfaces.

To see the sync status :
cp39.png

To show the status in list form :

cphaprob list

Starts/Stops clustering on the specific node : cphastart/stop

To see the connections :

fw tab -t connections -s ; use connections -f if want to see the IP addresses of the connections.

Commands in CLI

sh mode
show vrrp summary
show vrrp interfaces

Commands to configure VRRP via CLI :
cp40.png

For more on VRRP and HA clustering , please refer below URL :

https://sc1.checkpoint.com/documents/R76/CP_R76_Gaia_WebAdmin/87911.htm

Now, let’s make the IPSEC VPN where we’ll define policies and see if we can set up a IPSEC VPN from HQFW cluster to BRFW firewall and then we’ll test the failover during any catastrophic failure.

We are going to perform same steps which we have performed while creating the IPSEC tunnel from HQ to BR when there was no clustering.

Now, first define the VPN domain and now we will define the domain on the HQFW cluster.
cp41.png

I have selected my internal network on the HQ side as a part of the VPN domain.

Similarly select 10.2.2.0/24 for branch inside network.

Let’s create a VPN community of star type means hub and spoke.

In R80 , like in R77 first enable the blade and then choose star VPN community as given in the below snapshot :
cp42.png

Then choose the center and Satellite gateway :
cp43.png

Then add some other properties :  Like Encryption Suite
cp44.png

And disable NAT under Advanced section as we don’t want our interesting traffic to NAT while traversing through VPN tunnel.
cp45.png

Click on ok and now let’s create a rule in the policy to allow the communication over VPN.
cp46.png

As you can see I allowed the VPN rule in the policy . Install the policy on the firewalls to test this.

In R80, Policy installation tab looks little different :
cp47.png

Once installed, let us check the VPN status through SMART View Tracker.

In R80, if you want to run Smart View Tracker then run from this path :

C:\Program Files (x86)\CheckPoint\SmartConsole\R80\PROGRAM\CPlgv.exe

Let’s ping from HQ subnet to BR subnet :
cp48.png

And the ping is successful and see the first packet response time it’s 312ms means all those IPSEC negotiations happened when we first initiated the interesting traffic.

Let’s check through SVT :
cp49.png

We can many IPSEC VPN logs : let’s expand those :

Here, we can see traffic initiated from Admin_PC on HQ side to R3 on the BR side means from 10.1.1.15 to 10.2.2.1

when we expand the logs then we can see the main mode, quick mode exchange, key installation and then the interesting traffic logs :

On HQFW Cluster : currently HQFW1 is primary and processing all traffic. We can see it in origin and the phase 1 main mode exchange.
cp50.png

Similarly, if we expand then we can see the quick mode and actual encrypted/decrypted traffic :

Below is Quick mode completion log on BRFW :

cp51.png

Below is Quick mode completion log on HQFW1

cp52.png

And now, it’s phase 2 interesting traffic decryption on BRFW:
cp53.png

Similarly, we can check the status via CLI. I have already shared VPN CLI commands in our previous series.

Now, Let’s test the HA :

I am going to reboot the primary FW and let’s see the VPN traffic :
cp54.png

As we can see there is just 1 drop.

Let’s see the HA state.
cp55.png

Now, HQFW2 has all interfaces in Master state. Once HQFW1 will be up then it will again become primary because of preemption.

See the SVT when HQFW2 was Primary :
cp56.png

And once HQFW1 is up after reboot then it’s again become primary .
cp57

And we can see HQFW1 is again primary.

Checkpoint Series:

 

Advertisements

Categories: Checkpoint, Security

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s