Check Point Firewall-1 Virtual Private Networking


Excerpted (with permission) from Check Point FireWall-1 Administration Guide by Marcus Goncalves and Steven Brown

FireWall-1 and Certificate Authorities

In the FireWall-1 proprietary encryption scheme (FWZ), FireWalled management servers function as certificate authorities for the encrypting gateways. In the ISAKMP encryption scheme, the Entrust PKI (Public Key Infrastructure) can be used to obtain certificates for the encrypting gateways and for SecuRemote users.


Encryption Schemes Supported by FireWall-1

FireWall-1 supports the following encryption schemes:



Configuring FireWall-1 Encryption

FireWall-1 provides completely transparent selective encryption for a wide range of services. Encryption, decryption, and key management are all seamlessly integrated with other FireWall-1 features.

Figure 1 depicts a corporate internetwork where two private networks are connected via the Internet through FireWalled gateways. HQ is the management station for itself and London. The private networks (HQ-net, London-net and DMZ-net) are protected by the FireWalled gateways, but the public part of the network, the Internet must be considered insecure.

Figure 1 Two gateway network configuration



Encryption Domains

A gateway performs encryption on behalf of its encryption domain: the LAN or group of networks that the gateway protects is defined on the firewall as the encryption domain. Behind the gateway, in the internal networks, packets are not encrypted.


Note: In the example in figure 1, HQ-net is considered an encryption domain for HQ Firewall, and London-net is considered an encryption domain for the London firewall.


For example, if the system administrator has specified that communications between HQ and London are to be encrypted, FireWall-1 encrypts packets traveling between them on the Internet. A packet traveling from Sales to Admin is encrypted on the London-HQ segment of its trip, but not encrypted on the Sales-London and HQ-Admin segments.

In this way, encryption can be implemented for a heterogeneous network without the need to install and configure encryption on every host in the network.


Key Management

Key management is based on the Diffie-Hellman and RSA schemes described above. For each gateway it manages, a management station:


Specifying Encryption

To specify encryption, answer the following questions:

1. Who will encrypt? Define the encrypting gateways and their encryption domains.

2. What are the encryption keys? On the management station, generate keys for the gateways, or obtain the certified keys from the remote gateways or certificate authorities.

3. What will be encrypted? Add a rule (or rules) specifying encryption to the rule base.

4. Which encryption scheme will be used? Specify the encryption scheme in the rule. The scheme must be one that both parties to the encryption can implement.


Configuring a LAN-to-LAN (Two-Gateway) VPN

To encrypt communications between HQ's encryption domain and London's encryption domain, as shown in Figure 1 above, using the FWZ encryption scheme, proceed as follows on HQ, the management station:

Note: In this example we are configuring both gateways from the one management station on the HQ network, the admin station.

1. Define the gateways that will perform the encryption. If adding encryption to an existing FireWall-1 configuration, the gateway is already defined. Otherwise, define HQ and London as gateways.

Step 1 was done when the firewall object was created, there is no need to create the object unless this is a new install.

2. Define HQ-net, DMZ-net, and London-net as networks, as shown in Figure 2.

Again, these networks may have already been created. The reason for defining them, if not done so, is that these objects will be defined as encryption domains. This way, when the firewall checks the destination IP, it will be able to tell if it should encrypt the packet.

Figure 2 Defining London-net network


3. To define a gateway's encryption keys, open the Workstation Properties window for each encrypting gateway and then: In the Encryption tab, double-click on FWZ Encryption Method. This displays the FWZ Properties, as shown in figure 3

Figure 3 FWZ properties for gateway London


4. If the certificate authority is local, click on Generate to generate a Diffie-Hellman key pair for the gateway.

5. If the Certificate Authority is remote, click on Get to retrieve a Diffie-Hellman key pair for the gateway, as shown in figure 4. The Diffie-Hellman key is a public-private key pair, and is used to generate the Basic Session key. In the configuration example in figure 1, all the gateways are controlled from the same management station.

Figure 4 FWZ Properties window _ after a key has been generated

6. In the Workstation Properties window for each gateway, specify the Encryption Domain. In the example configuration, HQ's Encryption Domain is HQ-encrypted, and London's Encryption Domain is London-net, shown in figure 5

Figure 5 Specifying encryption domain for gateway London


7. Define a network object group consisting of all the networks that will participate in the encryption (HQ-net, DMZ-net, and London-net).

8. Define a rule in the rule base that specifies Encrypt as the Action for communications whose source and destination are the network object group defined in the previous step. In figure 6, the rule that is implemented on the London gateway is shown.

Figure 6 London gateway rule base

Figure 6 shows the rule base on the London firewall. If a user on the London-net (Source) tries to access either (HQ-net or DMZ-net) destination, with any service, the action is to encrypt the packet. The other side (HQ gateway) has a similar rule, which will encrypt packets going to London-Net.

The Encrypt action means

9. Double-click on the Encrypt in the action field for rule 2 to specify the encryption properties, as shown in figure 7.

Figure 7

10. Install the security policy on the gateways (HQ and London).

Other Firewall-1 Encryption Schemes

We’ve just seen how Firewall-1 is configured with the FWZ encryption algorithm available with Check Point. There are also other schemes, such as Manual IPSec, ISAKMP/OAKLEY, and SKIP as previously shown in figure 5

Each scheme has it’s own particular values, but they are all easily configurable with the GUI interface. In this following section, we will just take a look at some of the available options available to implement your VPN. Figure 8 looks at the ISAKMP/OAKLEY properties.

Figure 8 Firewall-1 ISAKMP/OAKLEY

In ISAKMP/OAKLEY, select the following options.

Figure 9 Setting pre-shared secret with Chicago

In figure 9, the workstations that have been defined as using ISAKMP/OAKLEY will be displayed in the "Peer Name" column. Highlight one of the gateways, enter the secret key (in this example, we typed in abc123) and click the set button.

Figure 10 Setting up a CA authority for PKI

Figure 10 illustrates using a public key infrastructure (PKI). Clicking on Generate on the Configure Public-Key Signature, brings up another window. In this window, you enter in a reference number and authorization code.

This is used for Entrust PKI

The sequence of events that follows are:

1 – A key pair is generated

2 – The public key is sent to Entrust

3 – Entrust computes a certificate

4 – Entrust sends the certificate to the Firewall-1 management station

5 – The management station stores the Entrust certificate on the firewall

6 – The DN and email fields are filled in by the firewall