FireWall-1 FAQ: How Do I Set Up a Highly Available VPN?
Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.
I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.
If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)
The key to a highly available VPN is setting up clustering on the enforcement points. This creates a gateway cluster, which is when two or more enforcement points appear as a single logical entity in respect to traffic traversal, installing a security policy, and encryption. This is accomplished through the synchronization of the internal tables on each enforcement point in the cluster so that when one module in the cluster fails not only is traffic redirected to the remaining module but also connections initiated via the failed module are allowed to be properly processed.
Setting up a VPN involving gateway clusters is not very different from setting up a VPN involving a single gateway. You will notice that the moment you make a firewall workstation object part of a gateway cluster, many of the tabs in the workstation properties simply disappear. This configuration now needs to be done from the gateway cluster object. When you configure the VPN-related parameters for the firewall, you configure them on the gateway cluster object, not on the workstation object for the firewalls that are a member of the gateway cluster.
Depending on your topology requirements, you have to decide which type of clustering you want to configure.
- Load sharing (Active / Active)
- High Availability (Active / Stand-by)
Load sharing means that traffic is distributed among the gateways in the cluster. This is accomplished via multicast mode (all gateways receive all packets) or unicast mode (one pivot gateway acts as traffic cop directing traffic to the other gateways).
High Availability means that one gateway is active and firewalling while the other gateway is passive and only “wakes up” when the first goes down.
One caveat: Setting up SecuRemote to work properly with the cluster requires some more steps. With SecureClient it’s possible to use the Policy Server to manage behavior. This will be explained in another article.
For NG, you have the choice of using 3rd party software, eg from Stonebeat or Nokia’s VRRP. Or, you can use Check Point’s Cluster XL. The scope of this website motivates us to describe how to configure the Cluster XL product. This document will discuss the configuration of multicast load balancing and leave High Availability as an exercise for the reader. Unicast load balancing won’t be covered because switches that support multicast are so inexpensive nowadays only something along the lines of religious reasons should force you not to upgrade your switches if they don’t already support multicast packets.
At the time of this writing, there are apparently still decisions pending at Check Point regarding how the licensing will work out. If you have information on this, let us know.
Requirements:
- All enforcement modules must be running the same OS
- FW-1/VPN-1 software must be same version/feature pack
- Same security policy must be installed
- Distributed Check Point environment
- You need to have a separate network for the sync packets (using extra NICs and a xover cable is optimal)
Steps:
- Establish SIC to both gateways
- Configure the IP addresses on the sync network
- Retrieve topology on both gw objects
- Disable IP pool NAT on both gw objects
- Create gw cluster object
- Set IP address on cluster object (should be external network not used by either gw object)
- Under Check Point products activate Cluster XL
- Add/create the enforcement modules to the cluster object (careful some policy packages require deletion)
- Edit the cluster member objects, under topology clear cluster interface box for the sync network
- Define sync network under synchronization in the cluster object’s properties
- Define the topology of the cluster (NB: make sure not to use addresses taken by the gateway objects)
- Under Cluster XL select load sharing multicast
Once you click ok, the CA should be created and you can use this object in the policy. Don’t forget to change the policy so that the “Install On” column doesn’t contain any of the gateways in the cluster. The cluster object must replace them, otherwise the policy push will return errors.
For FireWall-1 4.1:
To enable Gateway Clusters, you will need to enable them in the Rulebase Properties, High Availability tab. Check the “Enable Gateway Clusters” feature. Once you’ve done this, you will be able to create a Gateway Cluster. Create the Gateway Cluster object using the VRRP (or other Highly Available) IP address and configure it as you would a workstation object for a VPN. Now go into each of the workstation objects representing the real firewalls and make them a member of the Gateway Cluster. Note that you may need to accept certain things (like the IKE service) to the Gateway Cluster address, but you can not put the Gateway Cluster object in the rulebase. In this case, simply create a workstation object with a different name and the same IP address as the Gateway Cluster. You will get a warning about this. Provided you created the Gateway Cluster address first, you can ignore this error message.
If you manage the remote end of the VPN with the same management console, no other changes need to be made. If the remote end of the VPN uses a different management console, only a workstation object needs to be created to represent the Gateway Cluster. The primary IP address of this object should be the Gateway Cluster. The “interfaces” tab should be defined with all of the IP addresses of both “real” firewalls plus the Gateway Cluster address. Note that the interface names (or even the netmasks) do not need to be correct here, but all IP addresses must be listed. This is because the Gateway Cluster will receive packets on the Gateway Cluster IP but send packets using the real IP addresses.
FireWall-1 4.1 SP3 and later have a feature that will force FireWall-1 to only use the Gateway Cluster IP address when it originates packets. This will be necessary when UDP Encapsulation is used or when talking to a third-party VPN endpoint. To enable this feature in 4.1 SP3 or SP4, add the following line to the :props ( section of objects.C (For guidelines on editing objects.C, see How do I Edit Objects.C?).
:IPSec_cluster_nat (true)
In 4.1 SP5 and above, add this to the gateway definition in objects.C, not the Gateway Cluster definition or the :props ( section:
: (mygate-1
:color (black)
:type (gateway)
:host_schemes_val (25)
:host_schemes_names (
: ("S/Key")
: ("Internal Password")
: (RADIUS)
)
:comments ()
:location (internal)
:firewall (installed)
:IPSec_cluster_nat (true)
...
) Once you enable Gateway Clusters, make sure you change the Install-On targets that specifically list the firewall and replace it with the Gateway Cluster object. You will get errors on policy installation if you do not do this.
