Defining Policy-Based VPN elements

The Policy-Based VPN element collects together the gateways and the VPN Profile, and provides the settings for defining the topology and the tunnels of the policy-based VPN.

The main configuration for the VPN consists of defining which gateways are in the VPN and which of the gateways form tunnels with each other. You can also enter and renew pre-shared keys if you use them for authentication in this VPN.

The topology is determined by selecting whether the Gateways are Central or Satellite in each particular policy-based VPN:

A central gateway establishes VPN tunnels with any other central or satellite gateway in the VPN, unless you specifically disable the tunnels.
A satellite gateway establishes VPN tunnels only with central gateways.
You can also create a VPN hub by adding a gateway so that it is listed under some other (central or satellite) gateway in the topology. Other gateways connect to the higher-level gateway, which forwards the connections to the lower-level gateway.

The Sites and networks for each gateway element can be adjusted in the policy-based VPN, but most of the settings are not specific to the policy-based VPN. The only change that is specific to the policy-based VPN is to disable a Site element in the policy-based VPN. Disabling a Site excludes the IP addresses from that policy-based VPN only. Any other adjustments to the Sites and networks affect all other VPNs where the same gateway element is used.

Tunnels are generated from each central gateway to all other gateways based on the overall topology. You can adjust the tunnels to limit which gateways and endpoints form tunnels with each other. You can also change some of the properties for tunnels between two particular gateways or endpoints, such as the VPN Profile used. You can also define Multi-Link VPN settings that allow you to select standby and active tunnels and to set tunnels to aggregate mode. In aggregate mode, each connection is automatically balanced between the aggregate tunnels. Aggregate mode is likely to cause packet reordering that can actually decrease performance, depending on the TCP stacks in the connection endpoints.

Note: Although the VPN endpoints usually correspond to the NetLink interfaces in a Multi-Link configuration, the VPN endpoint settings are separate from the NetLink and Outbound Multi-Link definitions. For example, a NetLink that is set to standby for non-VPN traffic in an Outbound Multi-Link element can still be used as an active endpoint for VPN traffic.

When you configure the policy-based VPN, the validity of the VPN is automatically checked based on settings in VPN Profile elements, VPN Gateway Profile elements assigned to gateways in the VPN, endpoint identity information, and gateways certificates. If problems are found, they are shown in the Issues view. While useful in many cases, the automatic check does not detect all problems, especially regarding external gateways or interference between several separate policy-based VPNs.

Consider the following when creating new policy-based VPNs:

Check whether you can use an existing policy-based VPN instead. Most settings can be set individually for each site-to-site tunnel even within a single policy-based VPN. The VPN Profile, pre-shared key, and Multi-Link settings can all be selected separately for each VPN tunnel. Site definitions are the only major exception to this rule.
There must not be duplicate tunnels (two tunnels between the same two endpoints) in the configuration of any Firewall. Duplicate tunnels cause a policy installation failure. The easiest way to avoid duplicate tunnels is to define all VPNs between your Firewalls in the same policy-based VPN.
If you are creating VPNs with partner organizations, you might only want to include a subset of the internal IP address space in the Site definitions. Limiting the IP address space allows you to avoid revealing all internal addresses to your partner. Any cases where Site definitions must be different for different VPN tunnels requires creating separate policy-based VPNs.

VPN topologies

policy-based VPN tunnels can be defined using different topologies:

Full-mesh topology connects each site to every other site in the same VPN. All gateways are central gateways, which means that all gateways can establish tunnels with all other gateways in the VPN.
Star topology connects sites behind satellite gateways to the sites behind central gateways. No VPN tunnels are established between the satellite gateways.
VPN hub topology routes site-to-site or mobile VPN connections to other sites through a central (hub) gateway using other site-to-site VPNs. The hub is usually a central gateway, but it can also be a satellite gateway.

Figure: Full mesh VPN topology

: The full mesh topology, is formed between sites that must all be able to connect to any other site.

Figure: Star VPN topology

: In VPNs with partner organizations or remote offices, VPN connectivity is often needed between remote sites and a main site, but not from one remote site to another. This topology is a star topology.; The star topology is defined with satellite gateways that connect only to the central gateway. There is no VPN between the satellite gateways. This topology reduces the number of VPN tunnels that the gateways maintain compared to full-mesh topology. Having fewer tunnels can save resources on the remote gateways.; Sometimes the star topology is preferred even if VPN connectivity is needed between the remote offices. In this case, the central gateway can be used as a hub that relays traffic from one VPN tunnel to another. Traffic can be forwarded from either a site-to-site tunnel or a mobile VPN tunnel.

Figure: Hub VPN topology

: The hub topology simplifies VPN client use if the clients connect to several gateways. It can also make setting up site-to-site VPNs easier, especially if the satellite gateways are third-party devices. VPN encryption and decryption require heavy computing. Consider hardware performance before high volumes of traffic are concentrated at a hub gateway.

Because the connectivity requirements vary from location to location, the VPN configuration can be a mix of the different topologies. This illustration shows an example of a mixed topology:

Figure: Combination of different topologies

: Replacing two of the central gateways from the full mesh example with satellite gateways results in a VPN where all but two gateways still have a VPN with each other.