Single Entry Point VPN Configurations (SEP)

SEP VPNs enable your enterprise to deploy a solution that protects what many consider an increasingly critical element of the network. VPNs enable you to extend your enterprise to the remote user, and as more companies look toward telecommuting, remote sales forces, and partner networks, their availability becomes increasingly important. Gone are the days when a VPN was a novelty or a convenience; today it's a necessity. Also, synchronized connections are a must. You wouldn't want users to notice that their VPN connection was just transferred to another gateway. Another nice feature is the support for SEP (and MEP) VPNs when dealing with both remote clients and with gateway-to-gateway VPNs.

Gateway Configuration

Before you go about configuring a SEP VPN solution, you need to make sure that Gateway Clusters are enabled on the management server. This is simply done from within the Global Properties in the Policy Editor. Figure 15.4 shows you the means of enabling HA on the Management server.

Figure 15.4: Enabling Gateway Clusters

In this section, you'll look at configuring an HA solution in depth. Figure 15.5 is presented here as a memory refresher. It shows you the General panel used for cluster configuration. This panel is used to initially identify the information about the cluster, such as the cluster name and IP address and also to specify the Check Point applications installed. Note that the IP address configured here is the cluster IP address. This will be the common IP of the cluster, and should be defined in the interface configuration of each cluster member.

Figure 15.5: Gateway Cluster: General Panel

You also can specify, on the topology panel (Figure 15.7), which addresses reside behind this cluster. This is similar to the features on a workstation object's interface properties topology panel. One of the most common uses of a manually defined VPN domain is to define an overlapping encryption domain for the gateway cluster. Figure 15.6 shows a gateway cluster with an overlapping VPN domain. Note that the VPN domain contains the protected network and all of the cluster members.

Figure 15.6: Overlapping VPN Domain in an SEP Configuration

You'll first need to define a network object symbolizing the protected network. Then you'll want to define a group object containing each gateway cluster member, as well as the newly created network object. In Figure 15.7, this group is called Remote_VPN_Domain. Specifying this object on the Topology panel as shown is all you need to do to institute a full VPN domain overlap.

Figure 15.7: Gateway Cluster: Topology Panel

The next panel enables you to specify cluster members. This is your next task. Cluster members are the workstations previously defined for inclusion within the cluster. This configuration panel is illustrated in Figure 15.8. Here it is important to note that order is important, as the order in which the gateways are listed defines their priority. The order can be shuffled without much effort by the use of the familiar Up and Down sort buttons. Also, new gateways can be added and old ones simply removed, as well. In this case, the Edit button will take you to the Properties panels for the selected gateway, allowing very handy alteration of its settings information.

Figure 15.8: Gateway Cluster: Cluster Members

Figure 15.9 shows you how the High Availability settings are defined. The first option, High Availability Mode, tells the HA process how to react when a failed cluster member returns to service. There are two options, which are explained below:

Figure 15.9: Gateway Cluster: High Availability Panel

• Active Gateway Up In this mode, when a primary gateway has failed and subsequently returned to service, it will not regain control of the cluster. Instead, it will assume the role of secondary. This is useful when you opt not to use state synchronization, as it causes the least interference in these cases.

• Higher Priority Gateway Up When the primary gateway in the cluster fails and subsequently returns to service, it will retake control of the cluster, assuming that it has been assigned a higher priority (as sorted in the cluster members panel).

Also defined on this panel is the action to take when a primary gateway fails:

• None

• Log

• Alert

• Mail

Figure 15.10 shows you the Synchronization panel. Synchronization is not required for a HA cluster to function, and is, in some cases, better excluded. Synchronization assures that no connections are lost when a primary cluster firewall fails. It does this by maintaining the state table across all cluster members. This table maintenance has an associated resource cost, which, depending on the size of the state table, can be large. The decision to use this feature is up to you. If you opt for its benefits, you'll need to define what Check Point calls a "synchronization ring," or, in common terms, a group of networks. Note that the network listed in this ring will be treated as trusted. The HA module will trust all messages coming from this network, and, as such, it should be segmented from normal user traffic. If you opt not to use synchronization, simply uncheck the Use State Synchronization field.

Figure 15.10: Gateway Cluster: Synchronization

Recall from our earlier discussion of State Synchronization what the purpose of this mechanism is. Imagine if a user behind your firewall is getting a very large file via FTP, downloading the newest service pack from Microsoft, for example. If the primary firewall failed and synchronization was enabled, the secondary firewall would take over the connections and the user wouldn't notice the slightest difference. Without synchronization, the transfer would have to be restarted, perhaps with the loss of the already downloaded data.

The remaining tabs of the Gateway Cluster are identical to their cousins in the workstation Properties. Hidden in the screenshots are VPN, Authentication, Masters, and Log Servers tabs (This is part of the workstation object). These allow the setting of the same information as for the individual member workstations, except that here the information is defined per cluster. This also means that the information will no longer be configurable on the individual cluster members.

Policy Configuration

When you have finished configuring the cluster and assigning all the proper members, you still need to allow the FW1 service to pass between the cluster members. As mentioned earlier in the High Availability section, it's best to make sure that the synchronization network is trusted completely. This is easily accomplished by simply not connecting that network to any other machines. You certainly wouldn't want others synching up with your firewalls—that could lead to very bad things. There's only one problem with making this rule. You can't use the cluster object as either a source or destination in the rule base. To work around this, you'll need to create a workstation object with the IP address of the interface on the synchronization network, and use that in the rule.