Configuring an FWZ VPN

This section describes how to implement a site-to-site FWZ VPN. We discuss configuration of local and remote gateways first, and then add encryption rules to our rule base. We show configuration in the common situation of two gateway modules, with the local module acting as a management station for both modules. Since the management station manages both firewall modules, it will be a CA for both gateways. We must also decide which networks will participate in our VPN domain. For this example, we will use Local_Net and Remote_Net. Make sure these network objects are created prior to starting implementation of your VPN. It is worth noting that in order to install a policy with encryption rules, you will need to purchase an encryption license from Check Point. This can be added to an existing license, or included with an original software purchase.

Note

It is important not to include either peer's gateway object in their respective VPN domains, or else traffic to or from each gateway will be encrypted, which is not what we want, nor can it work, as key exchange has not yet taken place. Contrast this with SEP (Single Entry Point) configurations, in which gateways must be a member of each VPN domain. In addition, for nonroutable VPN domains, make sure opposing subnets are not identical. In large deployments, where you may have more than one gateway, each with a unique VPN tunnel, make sure the VPN domains don't "overlap" or include the same hosts/networks in both domains. Both gateways will want to encrypt traffic in cases where traffic passes through more than one gateway on the way to its destination. Better to use a SEP configuration for this, with some dynamic routing protocol inside your local network.

Defining Objects

For any site-to-site VPN, you will need to create and properly configure certain network objects, including both gateways and the networks or group objects representing your VPN domains.

Local Gateway

The first step in implementing your FWZ VPN is to configure your local gateway's encryption parameters. Under the VPN tab of your gateway's Workstation Properties window, select the FWZ encryption scheme and click Edit. The FWZ Properties dialog comes up (see Figure 16.1). Choose the management station (itself in this case) from the Key manager management server drop-down box, and generate a DH key if one is not present.

Figure 16.1: Local Gateway's FWZ Properties Dialog

Next, open the Topology tab of the Workstation Properties window (see Figure 16.2). This is where you will define your VPN domain for the local gateway. Under VPN Domain, select Manually Defined, and then choose your local network from the drop-down list.

Figure 16.2: Topology Tab of the Workstation Properties Window

Remote Gateway

The remote gateway is set up exactly as the local gateway, with the distinction that your remote gateway's VPN domain is defined as Remote_Net, and your Key manager management server is still the local gateway object, since that is acting as the management station for both of your encrypting gateways.

Adding VPN Rules

You want to modify your rule base so that traffic between Local_Net and Remote_Net is encrypted. This is done rather simply with the addition of two rules to your rule base (see Figure 16.3).

Figure 16.3: Rule Base Encryption Rules

One rule specifies the following:

• Source: Local_Net

• Destination: Remote_Net

• Service: Any

• Action: Encrypt

• Track: Log

While the other specifies the following:

• Source: Remote_Net

• Destination: Local_Net

• Service: Any

• Action: Encrypt

• Track: Log

If you double-click on the Encrypt action in either encrypt rule, you will open the Encryption Properties dialog, from which you select FWZ and click Edit (see Figure 16.4). In the FWZ Properties dialog, you can choose your encryption method, allowed peer gateway (which gateway or gateways you are allowed to establish a VPN with), and a data integrity method. You are limited to MD5 data integrity with FWZ encryption.

Figure 16.4: FWZ Properties Window

Note that in your encryption rule base, you have Rule 1 defined to allow the "FireWall1" group of services between both gateway endpoints. This rule is not always necessary, but must be added when you have Accept VPN-1 & FireWall-1 control connections unchecked in your security policy's Global Properties window (see Figure 16.5). This is checked by default after installation, so, in most cases you won't need a rule 1 as shown previously, but it is good to keep in mind, as this allows the key exchange between gateways.

Figure 16.5: FireWall-1 Implied Rules

Once the gateway objects are properly configured and the VPN rules are added to the rule base, the security policy must be installed for the changes to take effect. Once the policy has been installed on both gateways, you can open your log viewer and begin testing your VPN.

FWZ Limitations

Because FWZ is a nonencapsulating protocol, you cannot use it in situations where the networks participating in your VPN domains have nonroutable addresses, or where both the source and destination IP addresses are being translated. FWZ will also not interoperate with other third-party VPN products, as it is a Check Point proprietary scheme. If you are in any of these situations, use IKE instead.