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.
- 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.
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.
- 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
- 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.
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: