Introduction to VPN

The Need for VPN

Communicating parties need a connectivity platform that is not only fast, scalable, and resilient but also provides:

• Confidentiality
• Integrity
• Authentication

Confidentiality

Only the communicating parties must be able to read the private information exchanged between them.

Authentication

The communicating parties must be sure they are connecting with the intended party.

Integrity

The sensitive data passed between the communicating parties is unchanged, and this can be proved with an integrity check.

How VPN Works

In the Figure, host 1 and host 6 need to communicate. The connection passes in the clear between host 1 and the local Security Gateway. From the source and destination addresses of the packet, the Security Gateway determines that this should be an encrypted connection. If this is the first time the connection is made, the local Security Gateway initiates an IKE negotiation with the peer Security Gateway in front of host 6. During the negotiation, both Security Gateways authenticate each other, and agree on encryption methods and keys. After a successful IKE negotiation, a VPN tunnel is created. From now on, every packet that passes between the Security Gateways is encrypted according to the IPSec protocol. IKE supplies authenticity (Security Gateways are sure they are communicating with each other) and creates the foundation for IPSec. Once the tunnel is created, IPSec provides privacy (through encryption) and integrity (via one-way hash functions).

After a VPN tunnel has been established:

• A packet leaves the source host and reaches the Security Gateway.
• The Security Gateway encrypts the packet.
• The packet goes down the VPN tunnel to the second Security Gateway. In actual fact, the packets are standard IP packets passing through the Internet. However, because the packets are encrypted, they can be considered as passing through a private "virtual" tunnel.
• The second Security Gateway decrypts the packet.
• The packet is delivered in the clear to the destination host. From the hosts' perspectives, they are connecting directly.

For more information regarding the IKE negotiation, see: IPSEC & IKE.

VPN Communities

Creating VPN tunnels between Security Gateways is made easier through the configuration of VPN communities. A VPN community is a collection of VPN enabled gateways capable of communicating via VPN tunnels.

To understand VPN Communities, a number of terms need to be defined:

• VPN Community member. Refers to the Security Gateway that resides at one end of a VPN tunnel.
• VPN domain. Refers to the hosts behind the Security Gateway. The VPN domain can be the whole network that lies behind the Security Gateway or just a section of that network. For example a Security Gateway might protect the corporate LAN and the DMZ. Only the corporate LAN needs to be defined as the VPN domain.
• VPN Site. Community member plus VPN domain. A typical VPN site would be the branch office of a bank.
• VPN Community. The collection of VPN tunnels/links and their attributes.
• Domain Based VPN. Routing VPN traffic based on the encryption domain behind each Security Gateway in the community. In a star community, satellite Security Gateways can communicate with each other through center Security Gateways.
• Route Based VPN. Traffic is routed within the VPN community based on the routing information, static or dynamic, configured on the Operating Systems of the Security Gateways.

The methods used for encryption and ensuring data integrity determine the type of tunnel created between the Security Gateways, which in turn is considered a characteristic of that particular VPN community.

A Security Management server can manage multiple VPN communities, which means communities can be created and organized according to specific needs.

Remote Access Community

A Remote Access Community is a type of VPN community created specifically for users that usually work from remote locations, outside of the corporate LAN. This type of community ensures secure communication between users and the corporate LAN. For more information, see: Introduction to Remote Access VPN.

Authentication Between Community Members

Before Security Gateways can exchange encryption keys and build VPN tunnels, they first need to authenticate to each other. Security Gateways authenticate to each other by presenting one of two types of "credentials":

• Certificates. Each Security Gateway presents a certificate which contains identifying information of the Security Gateway itself, and the Security Gateway's public key, both of which are signed by the trusted CA. For convenience, the Check Point product suite installs its own Internal CA that automatically issues certificates for all internally managed Security Gateways, requiring no configuration by the user. In addition, the Check Point Product Suite supports other PKI solutions. For more information, see: Public Key Infrastructure.
• Pre-shared secret. A pre-shared is defined for a pair of Security Gateways. Each Security Gateway proves that it knows the agreed upon pre-shared secret. The pre-shared secret can be a mixture of letters and numbers, a password of some kind.

Considered more secure, certificates are the preferred means. In addition, since the Internal CA on the Security Management server automatically provides a certificate to each Check Point Security Gateway it manages, it is more convenient to use this type of authentication.

However, if a VPN tunnel needs to be created with an externally managed Security Gateway (a gateway managed by a different Security Management server) the externally managed Security Gateway:

• Might support certificates, but certificates issued by an external CA, in which case both Security Gateways need to trust the other's CA. (For more information, see: Configuring a VPN with External Security Gateways Using PKI.)
• May not support certificates; in which case, VPN supports the use of a "pre-shared secret." For more information, see: Configuring a VPN with External Security Gateways Using a Pre-Shared Secret.

  A "secret" is defined per external Security Gateway. If there are five internal Security Gateways and two externally managed Security Gateways, then there are two pre-shared secrets. The two pre-shared secrets are used by the five internally managed Security Gateways. In other words, all the internally managed Security Gateways use the same pre-shared secret when communicating with a particular externally managed Security Gateway.

VPN Topologies

The most basic topology consists of two Security Gateways capable of creating a VPN tunnel between them. Security Management server's support of more complex topologies enables VPN communities to be created according to the particular needs of an organization. Security Management server supports two main VPN topologies:

• Meshed
• Star

Meshed VPN Community

A Mesh is a VPN community in which a VPN site can create a VPN tunnel with any other VPN site in the community:

Star VPN Community

A star is a VPN community consisting of central Security Gateways (or "hubs") and satellite Security Gateways (or "spokes"). In this type of community, a satellite can create a tunnel only with other sites whose Security Gateways are defined as central.

A satellite Security Gateway cannot create a VPN tunnel with a Security Gateway that is also defined as a satellite Security Gateway.

Central Security Gateways can create VPN tunnels with other Central Security Gateways only if the Mesh center Security Gateways option has been selected on the Central Security Gateways page of the Star Community Properties window.

Dynamically Assigned IP Security Gateways

A Dynamically Assigned IP (DAIP) Security Gateway is a Security Gateway where the external interface's IP address is assigned dynamically by the ISP. Creating VPN tunnels with DAIP Security Gateways are only supported by using certificate authentication. Peer Security Gateways identify internally managed DAIP Security Gateways using the DN of the certificate. Peer Security Gateways identify externally managed DAIP Security Gateways and 3rd party DAIP Security Gateways using the Matching Criteria configuration

DAIP Security Gateways may initiate a VPN tunnel with non-DAIP Security Gateways. However, since a DAIP Security Gateway's external IP address is always changing, peer Security Gateways cannot know in advance which IP address to use to connect to the DAIP Security Gateway. As a result, a peer Security Gateway cannot initiate a VPN tunnel with a DAIP Security Gateway unless DNS Resolving is configured on the DAIP Security Gateway. For more information, see Link Selection.

If the IP on the DAIP Security Gateway changes during a session, it will renegotiate IKE using the newly assigned IP address.

In a star community when VPN routing is configured, DAIP Security Gateways cannot initiate connections from their external IP through the center Security Gateway(s) to other DAIP Security Gateways or through the center to the Internet. In this configuration, connections from the encryption domain of the DAIP are supported.

Choosing a Topology

Which topology to choose for a VPN community depends on the overall policy of the organization. For example, a meshed community is usually appropriate for an Intranet in which only Security Gateways which are part of the internally managed network are allowed to participate; Security Gateways belonging to company partners are not.

A Star VPN community is usually appropriate when an organization needs to exchange information with networks belonging to external partners. These partners need to communicate with the organization but not with each other. The organization's Security Gateway is defined as a "central" Security Gateway; the partner Security Gateways are defined as "satellites."

For more complex scenarios, consider a company with headquarters in two countries, London and New York. Each headquarters has a number of branch offices. The branch offices only need to communicate with the HQ in their country, not with each other; only the HQ's in New York and London need to communicate directly. To comply with this policy, define two star communities, London and New York. Configure the London and New York Security Gateways as "central" Security Gateways. Configure the Security Gateways of New York and London branch offices as "satellites." This allows the branch offices to communicate with the HQ in their country. Now create a third VPN community, a VPN mesh consisting of the London and New York Security Gateways.

Topology and Encryption Issues

Issues involving topology and encryption can arise as a result of an organization's policy on security, for example the country in which a branch of the organization resides may have a national policy regarding encryption strength. For example, policy says the Washington Security Gateways should communicate using 3DES for encryption. Policy also states the London Security Gateways must communicate uses DES as the encryption algorithm.

In addition, the Washington and London Security Gateways need to communicate with each other using the weaker DES. Consider the solution:

In this solution, Security Gateways in the Washington mesh are also defined as satellites in the London star. In the London star, the central Security Gateways are meshed. Security Gateways in Washington build VPN tunnels with the London Security Gateways using DES. Internally, the Washington Security Gateways build VPN tunnels using 3DES.

Special Condition for VPN Security Gateways

Individually, Security Gateways can appear in many VPN communities; however, two Security Gateways that can create a VPN link between them in one community cannot appear in another VPN community in which they can also create a link. For example:

The London and New York Security Gateways belong to the London-NY Mesh VPN community. To create an additional VPN community which includes London, New York, and Paris is not allowed. The London and New York Security Gateways cannot appear "together" in more than one VPN community.

Two Security Gateways that can create a VPN link between them in one community can appear in another VPN community provided that they are incapable of creating a link between them in the second community. For example:

London and New York Security Gateways appear in the London-NY mesh. These two Security Gateways also appear as Satellite Security Gateways in the Paris Star VPN community. In the Paris Star, satellite Security Gateways (London and NY) can only communicate with the central Paris Security Gateway. Since the London and New York satellite Security Gateways cannot open a VPN link between them, this is a valid configuration.

Access Control and VPN Communities

Configuring Security Gateways into a VPN community does not create a de facto access control policy between the Security Gateways. The fact that two Security Gateways belong to the same VPN community does not mean the Security Gateways have access to each other.

The configuration of the Security Gateways into a VPN community means that if these Security Gateways are allowed to communicate via an access control policy, then that communication is encrypted. Access control is configured in the Security Policy Rule Base.

Using the VPN column of the Security Policy Rule Base, it is possible to create access control rules that apply only to members of a VPN community, for example:

The connection is matched only if all the conditions of the rule are true, that is - it must be an HTTP connection between a source and destination IP address within VPN Community A. If any one of these conditions is not true, the rule is not matched. If all conditions of the rule are met, the rule is matched and the connection allowed.

It is also possible for a rule in the Security Policy Rule Base to be relevant for both VPN communities and host machines not in the community. For example:

The rule in the Security Policy Rule base allows an HTTP connection between any internal IP with any IP:

An HTTP connection between host 1 and the Internal web server behind Security Gateway 2 matches this rule. A connection between the host 1 and the web server on the Internet also matches this rule; however, the connection between host 1 and the internal web server is a connection between members of a VPN community and passes encrypted; the connection between host 1 and the Internet web server passes in the clear.

In both cases, the connection is simply matched to the Security Policy Rule; whether or not the connection is encrypted is dealt with on the VPN level. VPN is another level of security separate from the access control level.

Accepting all Encrypted Traffic

If you select Accept all encrypted traffic on the General page of the VPN community Properties window, a new rule is added to the Security Policy Rule Base. This rule is neither a regular rule or an implied rule, but an automatic community rule, and can be distinguished by its "beige" colored background.

Routing Traffic within a VPN Community

VPN routing provides a way of controlling how VPN traffic is directed. There are two methods for VPN routing:

• Domain Based VPN
• Route Based VPN

Domain Based VPN

This method routes VPN traffic based on the encryption domain behind each Security Gateway in the community. In a star community, this allows satellite Security Gateways to communicate with each other through center Security Gateways. Configuration for Domain Based VPN is performed directly through SmartDashboard. For more information, see Domain Based VPN.

Route Based VPN

Traffic is routed within the VPN community based on the routing information, static or dynamic, configured on the Operating Systems of the Security Gateways. For more information, see Route Based VPN.

Excluded Services

In the VPN Communities Properties window Excluded Services page, you can select services that are not to be encrypted, for example Firewall control connections. Services in the clear means "do not make a VPN tunnel for this connection". For further information regarding control connections, see: How to Authorize Firewall Control Connections in VPN Communities. Note that Excluded Services is not supported when using Route Based VPN.

Special Considerations for Planning a VPN Topology

When planning a VPN topology it is important to ask a number of questions:

1. Who needs secure/private access?
2. From a VPN point of view, what will be the structure of the organization?
3. Internally managed Security Gateways authenticate each other using certificates, but how will externally managed Security Gateways authenticate?
   • Do these externally managed Security Gateways support PKI?
   • Which CA should be trusted?

Configuring Site to Site VPNs

VPN communities can be configured in either traditional or simplified mode. In Traditional mode, one of the actions available in the Security Policy Rule Base is Encrypt. When encrypt is selected, all traffic between the Security Gateways is encrypted. Check Point Security Gateways are more easily configured through the use of VPN communities — otherwise known as working in Simplified Mode. For more information regarding traditional mode, see: Traditional Mode VPNs.

Migrating from Traditional Mode to Simplified Mode

To switch from Traditional mode to Simplified mode (For more information, see Converting a Traditional Policy to a Community Based Policy):

Select Policy> Convert to > Simplified VPN.

or

1. On the Global Properties > VPN page, select either Simplified mode to all new Security Policies, or Traditional or Simplified per new Security Policy. File > Save. If you do not save, you are prompted to do so. Click OK.
2. File > New... The New Policy Package window opens.
3. Create a name for the new security policy package and select Firewall and Address Translation.

In the Security Policy Rule base, a new column marked VPN appears and the Encrypt option is no longer available in the Action column. You are now working in Simplified Mode.

Configuring a Meshed Community Between Internally Managed Gateways

To configure an internally managed VPN meshed community:

1. Install and configure the necessary Security Gateways as described in the R76 Installation & Upgrade Guide.
2. In SmartDashboard, double click on the Security Gateway object.
3. In the General Properties pane:
   1. Enter the gateway name.
   2. Enter the IPv4 and IPv6 addresses as necessary.
   3. Select VPN and establish SIC communication.
   1. On the Topology page, click Add to add interfaces. Once an interface appears in the table, clicking Edit... opens the Interface Properties window.
   2. In the Interface Properties window, define the general properties of the interface and the topology of the network behind it.
   3. On the Topology page, VPN Domain section, define the VPN domain as all the machines behind the Security Gateway based on the topology information or manually defined:
      • As an address range.
      • As a network.
      • As a group that can be a combination of address ranges, networks, and even other groups.

   (There are instances where the VPN domain is a group which contains only the Security Gateway itself, for example where the Security Gateway is acting as a backup to a primary Security Gateway in an MEP environment.)

   The network Security Gateway objects are now configured, and need to be added to a VPN community.

   Note - There is nothing to configure on the VPN page, regarding certificates, since internally managed Security Gateways automatically receive a certificate from the internal CA.

4. On the Network objects tree, select the VPN Communities tab.
   1. Right-click Site to Site.
   2. From the short-cut menu, select New Site To Site... > Meshed. The Meshed Communities Properties window opens.
   3. On the General page, select Accept all encrypted traffic if you need all traffic between the Security Gateways to be encrypted. If not, then create appropriate rules in the Security Policy Rule Base that allows encrypted traffic between community members.
   4. On the Participating Security Gateways page, add the Security Gateways created in step 1.

   A VPN tunnel is now configured. For more information on other options, such as VPN Properties, Advanced Properties, and Shared Secret, see: IPSEC & IKE

5. If you did not select Accept all encrypted traffic in the community, build an access control policy, for example:

Where "Meshed community" is the VPN community you have just defined.

Configuring a Star VPN Community

A star VPN community is configured in much the same way as a meshed community, the difference being the options presented on the Star Community Properties window:

• On the General > Advanced Settings > VPN Routing page, select To center only.
• On the Central Security Gateways page, Add... the central Security Gateways.
• On the Central Security Gateways page, select Mesh central Security Gateways if you want the central Security Gateways to communicate.
• On the Satellite Security Gateways page, click Add... to add the satellite Security Gateways.

Confirming a VPN Tunnel Successfully Opens

To make sure that a VPN tunnel has successfully opened:

1. Edit the VPN rule and Select log as the tracking option.
2. Open the applicable connection.
3. Open SmartView Tracker and examine the logs. A successful connection appears as encrypted.

Configuring a VPN with External Security Gateways Using PKI

Configuring a VPN with external Security Gateways (those managed by a different Security Management server) is more involved than configuring a VPN with internal Security Gateways (managed by the same Security Management server). This is because:

• Configuration is performed separately in two distinct systems.
• All details must be agreed and coordinated between the administrators. Details such as the IP address or the VPN domain topology cannot be detected automatically but have to be supplied manually by the administrator of the peer VPN Security Gateways.
• The gateways are likely to be using different Certificate Authorities (CAs). Even if the peer VPN Security Gateways use the Internal CA (ICA), it is still a different CA.

There are various scenarios when dealing with externally managed Security Gateways. The following description tries to address typical cases and assumes that the peers work with certificates. If this is not the case refer to Configuring a VPN with External Security Gateways Using a Pre-Shared Secret.

Although an administrator may choose which community type to use, the Star Community is more natural for a VPN with externally managed Security Gateways. The Internal Security Gateways will be defined as the central Security Gateways while the external ones will be defined as the satellites. The decision whether to mesh the central, internal Security Gateways or not depends on the requirements of the organization. The diagram below shows this typical topology.

Note that this is the Topology from the point of view of the administrator of Security Gateways A1 and A2. The Administrator of Security Gateways B1 and B2 may well also define a Star Topology, but with B1 and B2 as his central Security Gateways, and A1 and A2 as satellites.

The configuration instructions require an understanding of how to build a VPN. The details can be found in: Introduction to Site to Site VPN.

You also need to understand how to configure PKI. See Public Key Infrastructure.

To configure VPN using certificates, with the external Security Gateways as satellites in a star VPN Community:

1. Obtain the certificate of the CA that issued the certificate for the peer VPN Security Gateways, from the peer administrator. If the peer Security Gateway is using the ICA, you can obtain the CA certificate using a web browser from:

   http://<IP address of peer Security Gateway or Management Server>:18264

2. In SmartDashboard, define the CA object for the CA that issued the certificate for the peer. See Enrolling with a Certificate Authority.
3. Define the CA that will issue certificates for your side if the Certificate issued by ICA is not appropriate for the required VPN tunnel.

   You may have to export the CA certificate and supply it to the peer administrator.

4. Define the Network Object(s) of the Security Gateway(s) that are internally managed. In particular, be sure to do the following:
   • In the General Properties page of the Security Gateway object, select VPN.
   • In the Topology page, define the Topology, and the VPN Domain. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
5. If the ICA certificate is not appropriate for this VPN tunnel, then in the VPN page, generate a certificate from the relevant CA (see Enrolling with a Certificate Authority.)
6. Define the Network Object(s) of the externally managed Security Gateway(s).
   • If it is not a Check Point Security Gateway, define an Interoperable Device object from: Manage > Network Objects... > New... > Interoperable Device...
   • If it is a Check Point Security Gateway, In the Network Objects tree, right click and select New > Check Point > Externally Managed Security Gateway....
7. Set the various attributes of the peer Security Gateway. In particular, be sure to do the following:
   • In the General Properties page of the Security Gateway object, select VPN (for an Externally Managed Check Point Security Gateway object only).
   • In the Topology page, define the Topology and the VPN Domain using the VPN Domain information obtained from the peer administrator. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
   • In the VPN page, define the Matching Criteria. Specify that the peer must present a certificate signed by its own CA. If feasible, enforce details that appear in the certificate as well.
8. Define the Community. The following details assume that a Star Community was chosen, but a Meshed Community is an option as well. If working with a Meshed community, ignore the difference between the Central Security Gateways and the Satellite Security Gateways.
   • Agree with the peer administrator about the various IKE properties and set them in the VPN Properties page and the Advanced Properties page of the community object.
   • Define the Central Security Gateways. These will usually be the internally managed ones. If there is no another Community defined for them, decide whether or not to mesh the central Security Gateways. If they are already in a Community, do not mesh the central Security Gateways.
   • Define the Satellite Security Gateways. These will usually be the external ones.
9. Define the relevant access rules in the Security Policy. Add the Community in the VPN column, the services in the Service column, the desired Action, and the appropriate Track option.
10. Install the Security Policy.

Configuring a VPN with External Security Gateways Using Pre-Shared Secret

Configuring VPN with external Security Gateways (those managed by a different Security Management server) is more involved than configuring VPN with internal Security Gateways (managed by the same Security Management server) because:

• Configuration is done separately in two distinct systems.
• All details must be agreed and coordinated between the administrators. Details such as the IP address or the VPN domain topology cannot be detected automatically but have to be supplied manually by the administrator of the peer VPN Security Gateways.

There are various scenarios when dealing with externally managed Security Gateways. The following description tries to address typical cases but assumes that the peers work with pre-shared secrets. If this is not the case refer to Configuring a VPN with External Security Gateways Using PKI.

Although an administrator may choose which community type to use, the Star Community is more natural for a VPN with externally managed Security Gateways. The Internal Security Gateways will be defined as the central Security Gateways while the external ones will be defined as the satellites. The decision whether to mesh the central, internal Security Gateways or not depends on the requirements of the organization. The diagram below shows this typical topology.

Note that this is the Topology from the point of view of the administrator of Security Gateways A1 and A2. The administrator of Security Gateways B1 and B2 may well also define a Star Topology, but with B1 and B2 as his central Security Gateways, and A1 and A2 as satellites.

The configuration instructions require an understanding of how to build a VPN. The details can be found in: Introduction to Site to Site VPN.

To configure a VPN using pre-shared secrets, with the external Security Gateways as satellites in a star VPN Community, proceed as follows:

1. Define the Network Object(s) of the Security Gateway(s) that are internally managed. In particular, be sure to do the following:
   • In the General Properties page of the Security Gateway object, select VPN.
   • In the Topology page, define the Topology, and the VPN Domain. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
2. Define the Network Object(s) of the externally managed Security Gateway(s).
   • If it is not a Check Point Security Gateway, define an Interoperable Device object from: Manage > Network Objects... > New... > Interoperable Device...
   • If it is a Check Point Security Gateway, In the Network Objects tree, right click and select New > Check Point > Externally Managed Security Gateway....
3. Set the various attributes of the peer Security Gateway. In particular, be sure to do the following:
   • In the General Properties page of the Security Gateway object, select VPN (for an Externally Managed Check Point Security Gateway object only).
   • In the Topology page, define the Topology and the VPN Domain using the VPN Domain information obtained from the peer administrator. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
4. Define the Community. The following details assume that a Star Community was chosen, but a Meshed Community is an option as well. If working with a Mesh community, ignore the difference between the Central Security Gateways and the Satellite Security Gateways.
   • Agree with the peer administrator about the various IKE properties and set them in the VPN Properties page and the Advanced Properties page of the community object.
   • Define the Central Security Gateways. These will usually be the internally managed ones. If there is no another Community defined for them, decide whether or not to mesh the central Security Gateways. If they are already in a Community, do not mesh the central Security Gateways.
   • Define the Satellite Security Gateways. These will usually be the external ones.
5. Agree on a pre-shared secret with the administrator of the external Community members. Then, in the Shared Secret page of the community, select Use Only Shared Secret for all External Members. For each external peer, enter the pre-shared secret.
6. Define the relevant access rules in the Security Policy. Add the Community in the VPN column, the services in the Service column, the desired Action, and the appropriate Track option.
7. Install the Security Policy.

How to Authorize Firewall Control Connections in VPN Communities

Check Point Nodes communicate with other Check Point Nodes by means of control connections. For example, a control connection is used when the Security Policy is installed from the Security Management server to a Security Gateway. Also, logs are sent from Security Gateways to the Security Management server across control connections. Control connections use Secure Internal Communication (SIC).

Control connections are allowed using Implied Rules in the Security Rule Base. Implied Rules are added to or removed from the Security Rule Base, by selecting or clearing options in the Firewall Implied Rules page of the SmartDashboard Global Properties.

Some administrators prefer not to rely on implied rules, and instead prefer to define explicit rules in the Security Rule Base.

Why Turning off Firewall Implied Rules Blocks Control Connections

If you turn off implicit rules, you may not be able to install a Policy on a remote Security Gateway. Even if you define explicit rules in place of the implied rules, you may still not be able to install the policy:

The administrator wishes to configure a VPN between Security Gateways A and B by configuring SmartDashboard. To do this, the administrator must install a Policy from the Security Management server to the Security Gateways.

1. The Security Management server successfully installs the Policy on Security Gateway A. As far as gateway A is concerned, Security Gateways A and B now belong to the same VPN Community. However, B does not yet have this Policy.
2. The Security Management server tries to open a connection to Security Gateway B in order to install the Policy.
3. Security Gateway A allows the connection because of the explicit rules allowing the control connections, and starts IKE negotiation with Security Gateway B to build a VPN tunnel for the control connection.
4. Security Gateway B does not know how to negotiate with A because it does not yet have the Policy. Therefore Policy installation on Security Gateway B fails.

The solution for this is to make sure that control connections do not have to pass through a VPN tunnel.

Allowing Firewall Control Connections Inside a VPN

If you turn off implied rules, you must make sure that control connections are not changed by the Security Gateways. To do this, add the services that are used for control connections to the Excluded Services page of the Community object.

Discovering Which Services are Used for Control Connections

1. In the main menu, select View > Implied Rules.
2. In the Global Properties Firewall page, verify that 'control connections' are accepted.
3. Examine the Security Rule Base to see what Implied Rules are visible. Note the services used in the Implied Rules.