Tag: Checkpoint

Posted on

Checkpoint: Regenerate the Internal CA

Regenerate the Internal CA Without Breaking SIC

The internal CA certificate expires after 5 years, meaning that if you don’t catch this in time you won’t be able to log into the dashboard or the web UI. You can of course reset SIC on the command line using cpconfig but you will have to re-establish SIC with all your gateways which may be a lot of bother – besides that, any site-to-site or client certificate-based VPNs will also break. This article describes how to regenerate the internal CA without breaking SIC.

This is done on the command line and once completed (a matter of 5 minutes or less) then you will be able to log back in with SmartDashboard and push policies to all your managed gateways; all your certificate-based VPN operations will, quite happily, be none the wiser.

This example is from a R75.20 installation but is common to all up to R77.xx.

On the management station:

Enter expert mode and issue the following commands:

  1. Find the path to your existing (expired) certificate: 
    [Expert@mgmt]# find / -name "sic_cert.p12"
/var/opt/CPshrd-R75.20/conf/sic_cert.p12
[Expert@mgmt]
  2. Revoke the certificate: 
    [Expert@mgmt]# cpca_client revoke_cert -n “CN=cp_mgmt”
  3. Create a new certificate based on the old one 
    cpca_client create_cert -n “CN=cp_mgmt” -f /var/opt/CPshrd-R75.20/conf/sic_cert.p12
  4. Restart your Checkpoint services 
    [Expert@mgmt]# cpstop 
[Expert@mgmt]# cpstart

You should now be able to log in with SmartDashboard and everything else which relies on SIC!

Related posts:

Posted on

Checkpoint: Restore Your Routes in SecurePlatform After ifconfig down / up Without A Network Restart

If you ifconfig down your external interface then your default route will be deleted. ifconfig up however does not restore it. The general consensus is that this requires a service network restart but this will restart all your interfaces – not nice and not necessary.

config net ctrl action startup

will re-read and re-insert the routes contained in the /etc/sysconfig/netconf.C file which contains your default and static routes and things will be sweet once more.

Related posts:

Posted on

Checkpoint: Configuring Simplified VRRP on Nokia IP Appliances

This is a popular one and one I keep coming back to so here it is ..

In this example, we will configure VRRP with Check Point VPN-1/FireWall-1 NGX using Simplified VRRP Configuration feature of Nokia IPSO. It is assumed that the physical interfaces on the Nokia appliances are already configured, that Check Point packages are already installed and that the Management server object is already configured. Before beginning, ensure that the time and date on the modules and Management Server are correct.

For this example IPSO 4.2 and NGX (R65) was used.

We will use the following IP addresses.

FirewallA (master) External Eth1c0 10.207.122.201/24
Sync Eth3c0 172.31.10.1/24
Internal Eth2c0 192.168.10.11/24
FirewallB (backup) External Eth1c0 10.207.122.202/24
Sync Eth3c0 172.31.10.2/24
Internal Eth2c0 192.168.10.12/24
VRRP Addresses External 10.207.122.205
Internal 192.168.10.205
Management Server 192.168.10.10

We will begin by configuring VRRP in Network Voyager.

  1. Log into Voyager on the master (Firewall A)
  2. Expand the Configuration section then expand HighAvailability and then finally click on VRRPThis page will allow you to create the Virtual Router. In Simplified VRRP, only one Virtual Router is created.
  3. In the box “Create a new Monitored-Circuit Virtual Router:” enter 10
  4. Click APPLY .As you can see, the new virtual router has a VRID of 10. Its default “Priority” is 100 and default “Hello Interval” is 1. As FireWall A will be our VRRP Master, leave the Priority set at 100.
  5. In the box “Priority Delta” enter 10
  6. In the box “Backup Address” enter our external VRRP IP address of 10.207.122.205
  7. Click APPLY .Upon refresh, we will be able to enter our second (internal) VRRP IP.
  8. In the new box labeled “Backup Address” enter our internal VRRP IP address of 192.168.10.205 . The “VMAC Mode” should be left to VRRP and the “Static VMAC” box left blankNote: – DO NOT enter the Sync interface here as we do not want the Sync network monitored.
  9. Make sure that the option at the top of the page “Accept Connections to VRRP IP’s” is set to Enabled
  10. Also, for now, we will set “Monitor Firewall State” to Disabled
  11. Don’t forget to click APPLY .
  12. Finally we can click the SAVE button.You will need to create hostsentries on each module. This is done in Voyager, under Configuration, System Configuration then Host Address.There should be 4 entries hereOne for localhost, one for the Management Server, one for external IP of the local host, and one for the external IP of the other member.

    So in our example here, we would have these entries:

    localhost 127.0.0.1

    Master 10.207.122.201

    Backup 10.207.122.202

    Management 192.168.10.10

    ** The hostnames are the same as the name of the objects that will be used to represent each of these in SmartDashboard

    Save your configuration

    Once these steps have been completed, log into the backup (Firewall B)

    Perform the same steps with only one exception

    The priority of the Virtual Router on the backup will be 95.

    All other settings are the same

    Now log into each Nokia Appliance through console and run cpconfig

    ** If this is the first time running cpconfig, you will have to go through the Check Point configuration prompts first.

    Select option #6, which should read “Enable cluster membership for this gateway”

    It will ask you if you are sure, select [y]

    ** If this option reads “”Disable cluster membership for this gateway” then it has already been enabled

    This completes the VRRP configuration on the Nokia Appliances.

Configuring the Smart Center Server (Management Server)

To avoid asymmetrical routing, we will need to add 2 static routes on the management server. This only applies if the management server is on an internal network behind the VRRP pair.

Static route 1

To reach the external interface of Firewall A, go to Firewall A’s internal interface

So using our addressing schemes here running a Microsoft Windows Management Server, the command would be:

route add 10.207.122.201 mask 255.255.255.255 192.168.10.11 -p

Static route 2

To reach the external interface of Firewall B, go to Firewall B’s internal interface

route add 10.207.122.202 mask 255.255.255.255 192.168.10.12 -p

This will prevent traffic from the Management Server destined for Firewall B to be routed through Firewall A

Log into SmartDashboard

Create a Check Point Gateway object for each firewall module and define the object with the member’s external IP address.

Example:

FirewallA

10.207.122.201

FirewallB

10.207.122.202

Creating the objects with the internal IP addresses will cause problems with VPNs

Establish SIC with each module.

** If you are having difficulty establishing SIC, make sure the module is reachable then run fw unloadlocal on the modules and try again.

In addition, under Checkpoint Products under the general properties, make sure that Firewall is checked.

In the “Topology” section of each object, click “Get”, then “Interfaces with topology”

This will fetch the interface configurations.

Be sure to click OK to save this information.

Now create a new Check Point Gateway Cluster

The cluster Object should be defined using the external VRRP address.

10.207.122.205

Additionally, ensure that “ClusterXL” is NOT checked under Checkpoint products.

In the Cluster Members section, click “Add” then select “Add Gateway to Cluster”

Select the object we created for Firewall A and click ok

A message will inform you that some of this object’s data will be lost. Select “Yes”

Now follow the same steps to add Firewall B to the cluster.

Click OK

In the Gateway Cluster Properties

Go into the “3rd Party Configuration” section

Make sure that “High Availability” is selected for the Cluster operation mode.

Change the 3rd Party Solution from OPSEC to Nokia VRRP

Make sure that the check box for “Use State Synchronization” is selected

Now back to the Topology section, click Edit Topology.  First try clicking “get interfaces with topology” to fetch the VRRP interface configuration.  It should then appear as shown in the table below.  If it does not, then you need to manually enter that information.  Based on the network scheme above in this example, this is what the table should appear once configured.

VRRP

network obj. FirewallA FirewallB Topology
Get Top. Get Top. Get Top.
Name Cluster Eth2c0 Eth2c0 Eth2c0
IP Addr 192.168.10.205 192.168.10.11 192.168.10.12 Internal
Net Mask 255.255.255.0 255.255.255.0 255.255.255.0
Name Cluster Eth1c0 Eth1c0 Eth1c0
IP Addr 10.207.122.205 10.207.122.201 10.207.122.202 External
Net Mask 255.255.255.0 255.255.255.0 255.255.255.0
Name 1st Sync Eth3c0 Eth3c0
IP Addr 172.31.10.1 172.31.10.2 Internal
Net Mask 255.255.255.0 255.255.255.0

**Important

DO NOT add the sync interface under the Cluster as it is not a monitored interface

Click OK. The cluster object configuration is now completed.

Now push policy to the cluster object. If it fails to push the policy, run fw unloadlocal on the modules again to ensure that there is not a policy installed that could be blocking communication.

If there are console error messages that show up when policy is pushed (for example, antispoofing is not correctly defined) then you will need to go back to the VRRP configuration page and enable “Monitor Firewall State”.  For more information about this option please refer to resolution kb1355466

Log back into Network Voyager, go back into the VRRP configuration page then click on VRRP Monitor.
On Firewall A, you should see 0 interfaces in Backup state and the number of monitored interfaces in Master state (In our example here, 2 interfaces would be in Master state)

On Firewall B, you should see 0 interfaces in Master state and the number of monitored interfaces in Backup state. (In our example here, 2 interfaces would be in Backup state)

By running the command cphaprob stat on each module, you should see the local sync interface and the member’s sync interface as “active”. This indicates that state sync is communicating.

This ends the VRRP configuration.

Related posts: