Multiple Entry Point VPN Configurations (MEP)

MEP VPN deployments make use of the VPN-1/FW-1 Backup Gateway feature. With this sort of implementation, gateways for logically separated networks can be used to connect to the same destination network, assuming that a link exists between those networks. A diagram of a MEP configuration is shown in Figure 15.11.

Figure 15.11: Simple MEP Illustration

We consider MEP configurations to be more of a redundancy solution than a true HA solution. Since the networks are logically (and often geographically) separated, firewall synchronization is not possible. With this being the case, connections cannot be maintained as they can be with a SEP configuration. Instead, when the SecuRemote client's gateway fails, there is a brief pause before the backup gateway is connected. This will cause an interruption in the connection from a user's perspective. Usually this isn't a big deal. A user browsing the Web, for example, will simply click the browser's refresh button to continue as normal. Something like an SSL-secured Web page, however, would be more of a bother.

The first step toward setting up a MEP solution is to enable backup gateways on the Management server. This is done by altering the Global Properties | Gateway High Availability by placing a checkmark in the box labeled Enable Backup Gateway, as shown in Figure 15.12.

Figure 15.12: Enabling MEP

Overlapping VPN Domains

A VPN domain (a.k.a. an encryption domain) defines the entirety of the network residing behind the VPN-1/FW-1 device, and also includes the VPN-1/FW-1 gateway(s). Recent versions of VPN-1 support the use of overlapping VPN domains. This inclusion is the key element that allows the implementation of HA for VPN connections. There are three methods of creating an overlapping VPN domain:

• Partial Overlap

• Full Overlap

• Proper Subset

Figure 15.13 shows a graphical representation of these VPN domain types.

Figure 15.13: VPN Domain Types

Check Point has included support for Full Overlap and Proper Subset VPN domains. Since it isn't a supported method, Partial Overlap is outside of the scope of this chapter. We'll look at the particulars of the two supported VPN domains over the next few paragraphs.

As we mentioned in the first paragraph of this section, a VPN domain consists of the network residing behind the gateway, including that gateway. What this means for you, as a firewall administrator, is that you define a network object consisting of the protected network and then point to that network object within the configuration of the workstation object that is the VPN gateway. Implementing a fully overlapping VPN domain isn't much more difficult. All you need to do is properly define the network object. Simply define a group of network objects containing all of the involved gateways and all of their protected networks, and then point to this new group object as the VPN domain for those gateways.

This type of VPN domain is very handy when dealing with critical connections. When a SecuRemote client attempts to communicate with a server residing within this overlapping domain, it will attempt to connect to all of the gateways, and will complete that connection with the first gateway to respond. This brings up a potential problem in that traffic that came in through one gateway could possibly be sent back out through a different gateway, which would result in that packet not being encrypted. To prevent this from happening, you have two choices.

• The use of Network Address Translation Using NAT enables you to hide the connections passing through the gateway behind the gateway. This requires the use of a sensible hiding IP address (the hiding address, that is, for the SecuRemote client) that is routable to the issuing gateway.

• The use of IP pools IP pools enable you to assign an address to the SecuRemote client from a previously configured source. This source can be either a network object or an address range.

Note that State Synchronization cannot be considered a solution to asymmetric routing. There is no way that you could hope two firewalls could synchronize fast enough to avoid this problem.

A popular solution to the problem of asymmetric routing is the use of IP pools. If you ever have to use a VPN solution that doesn't support pools, you'll quickly see why having them available is far superior to not having them. To enable pools, you need to modify the Global Properties to place a check in the field called Enable IP Pool NAT for SecuRemote and VPN connections. What to do when the pool evaporates is up to you. Figure 15.14 illustrates this panel.

Figure 15.14: Enabling IP Pool NAT

Address exhaustion, which has the familiar three options of None, Log, and Alert, defines what to do when the addresses allocated to your pool are all gone. It is not recommended that you select None. Address allocation and release is a must for logging. Equate this with DHCP lease information as far as function, and consider the gap in your security policy if you didn't have accountability here.

Gateway Configuration

The gateway configuration is much more simple than the SEP configuration. This is essentially because, as previously mentioned, this is more of a failover solution than a HA solution. The gateways aren't clustered and there's no way to synchronize. SecuRemote clients will connect to their primary gateway as normal. If that gateway fails, then the connections are reestablished with the backup gateway. This takes a few seconds, so there will be a momentary interruption in the user's connection. But momentary is a lot better than permanent, we think you'll agree. If, however, you don't want even a moment's interruption, SEP would be considered the best choice.

Note

So, you aren't sure if either SEP or MEP is the solution for you? Say, for example, that you have a really mission-critical connection, one that just cannot be down. But you also have a requirement for redundant connections. These redundant connections have to be available even if an entire site goes down.

You have options. There's nothing that says you can't use both SEP and MEP in tandem. You could define a SEP group to handle the requirement for the highly available connection and then use MEP to define a redundant backup link!

Once you've enabled backup gateways in the Global Properties, you are able to define them within the Workstation object representing the gateways in your infrastructure. On the VPN tab of the Workstation Properties panel, you'll see a new checkbox called Use Backup Gateways: and an associated drop-down menu. Place a checkmark in this box and select the desired backup gateway from the list, and you're off to the races. The results will resemble the panel as shown in Figure 15.15.

Figure 15.15: Configuring a Backup Gateway

The next step is to define the VPN domain for this gateway. There are really no special tricks involved here. All you have to do is define the proper VPN domain for this gateway, just as you would if you were using a single gateway solution. Figure 15.16 illustrates this panel.

Figure 15.16: Selecting the VPN Domain

Overlapping VPN Domains

Establishing a MEP configuration using an overlapping VPN domain makes things about as easy as possible. In simple terms, an overlapping VPN domain makes the VPN domain of all participating gateways identical. While a VPN domain usually contains a single gateway and the network that resides behind it, when establishing an overlap, the domain contains all of the gateways and their respective protected networks. Configuring a MEP configuration for a fully overlapping encryption setup isn't all that hard. Let's take a look at the steps. For these examples, we'll assume a dual gateway architecture protecting the following networks:

• 10.1.1.0/24

• 10.1.2.0/24

Figure 15.17 shows you a MEP configuration using a fully overlapping VPN domain.

Figure 15.17: Fully Overlapping VPN Domain

The first step is to define these networks for use within your rule base. By selecting Manage | Network Objects | New | Network from the Policy Editor, you'll be able to create the networks representing your VPN domain. You'll also need to create the workstation objects representing the gateways that you'll be using. After you have done that, you have to place them all into a group. Select Manage | Network Objects | New | Group | Simple Group from the Policy Manager menu, and create a group like the one shown in Figure 15.18.

Figure 15.18: Overlapping VPN Domain Group

Next, you have to configure this new VPN domain on all of the firewalls that are participating within the configuration, and that's it. Shown in Figure 15.19 is what the Topology panel will look like. Note the Manually Defined VPN domain.

Figure 15.19: Overlapping VPN Domain

You also must use some means of avoiding the problem of asymmetric routing. Again, a popular choice is the use of IP pools. You'll also need to make sure that the routing within your network is properly configured to handle passing the traffic back to the network associated with the IP pool network. To associate an IP pool with the gateway, you first must define an address range that will be used as the pool. After you do that, access the Workstation Properties and select the NAT panel. Place a checkmark in the box marked Use IP Pool NAT for SecuRemote and VPN connections, select the previously defined address range object, and you're ready to go. Figure 15.20 shows you this final configuration panel.

Figure 15.20: Using IP Pools

When your SecuRemote clients attempt to initiate a connection, the first gateway to respond will be selected. This is a pretty simple method and is one of the reasons that this configuration is so straightforward.