Converting a Traditional Policy to a Community Based Policy

Introduction to Converting to Simplified VPN Mode

Building VPNs using Simplified Mode has many benefits. Simplified Mode makes it possible to maintain and create simpler, and therefore less error prone and more secure VPNs.

Simplified Mode separates the VPN definitions from the Access Control Security Policy. This makes it easier to understand the VPN topology of an organization, and to understand who is allowed to securely communicate with who. In addition, such as VPN routing are supported only with a Simplified Mode Security Policy.

In order to manage all existing policies in a unified way and utilize the latest features of the current release, it is recommended to convert Traditional Mode Security Policies to Simplified Mode. For new policies, it is recommended to use Simplified Mode, the default option.

A security policy configured in Traditional Mode can be converted to the Simplified VPN Mode using the Security Policy Converter Wizard.

After using the converter wizard, it is possible to greatly simplify many security policies by moving rules and grouping rules together.

The process is simple, and both automatic and manual changes are explained here in detail. The intention is to give you the confidence to move your Traditional VPN Policies to the Simplified VPN Mode.

To start the converter wizard, save the Policy, and from the SmartDashboard main menu, select Policy > Convert to > Simplified VPN…

How Traditional VPN Mode Differs from a Simplified VPN Mode

A Traditional Mode Security Policy differs from a Simplified Mode Policy in the following ways:

In Traditional VPN Mode, a single rule, with the Encrypt rule action, deals with both access control and encryption. VPN properties are defined per Security Gateway.

In Simplified VPN Mode, the Security Rule Base deals only with access control. In other words, the Rule Base determines only what is allowed. VPN properties, on the other hand, are dealt with per VPN community.

VPN communities are groups of Security Gateways. The community defines the encryption methods for the VPN. All communication between community members is encrypted, and all other communication is not encrypted.

Simplified VPN Mode and communities are described in Introduction to Site to Site VPN.

The simplified VPN policy makes it easier for the administrator to configure a VPN. However, Traditional policies allow VPNs to be created with greater granularity than Simplified policies, because

• Whether or not to encrypt can be defined per rule (source, destination and service)
• Simplified policies requires all the connections between two Security Gateways to encrypted using the same methods, using the Community definitions.

What this means is that after running the wizard, some manual optimization of the Rule Base may be required.

How an Encrypt Rule Works in Traditional Mode

When a Traditional policy is converted to a Simplified policy, an Encrypt rule is converted to rules that use communities. In order to understand the conversion, it is important to understand how an Encrypt rule works.

The following figure will be used to understand the conversion, and the limitations of the conversion process. It shows a VPN between Security Gateways, and the Encryption Domain of each Security Gateway. Net_A and Net_B are the encryption Domain of Security Gateway 1, and Net_D is the encryption Domain of Security Gateway 2.

The following table shows how the VPN is implemented in an Encrypt rule.

Sample Encrypt rule in a Traditional Rule Base

A connection that matches an Encrypt rule is encrypted (or decrypted) and forwarded by the Security Gateways enforcing the policy. There are two exceptions:

If the source or the destination are behind the Security Gateway, but are not in the VPN Domain of the Security Gateway, the connection is dropped.

For example, referring to Figure B‑1 and Table B‑1, if Source X is in Net_C and Destination Y is in Net_D, Security Gateway 1 drops the connection. This is because the Action says Encrypt but the connection cannot be encrypted because the source is not in the Encryption Domain of Security Gateway 1.

If the source and destination are inside the encryption Domain of the same Security Gateway. In this case, the connection is accepted in the clear.

For example, referring to Figure B‑1 and Table B‑1, if Source X is in Net_A and Destination Y is in Net_B, the connection originates at X and reaches the Security Gateway, which forwards the response back to Y. The connection is not encrypted because there is no peer Security Gateway for Y that could decrypt the connection. A SmartView Tracker log is issued "Both endpoint are in the Encryption Domain".

Principles of the Conversion to Simplified Mode

The converter Wizard attempts to maintain the best possible balance between connectivity and security, by using the following principles:

• Refuse all traffic that could have been refused in traditional Mode. This may mean that some connections may be dropped that were allowed by the traditional rule base.
• Encrypt at least all traffic that would be encrypted in traditional policy. This means that the converted policy may encrypt more connections than the original policy.

What this means is that not all traditional policies can be converted in a way that exactly preserves the policy that is specified in the Security Rule Base. The converted rule(s) in the Simplified VPN can under certain circumstances behave somewhat differently than the encryption rule for Traditional VPNs (described in How an Encrypt Rule Works in Traditional Mode).

Running the converter is a simple two or three step process. After running the wizard, you should review the Security Rule Base to make sure that it has maintained its required functionality, and optimize it if needed.

Placing the Security Gateways into the Communities

The first step in converting a traditional VPN to a simplified VPN is to create VPN communities that describe the topology of the organization. The conversion wizard requires the administrator to place Security Gateways into communities. It cannot do this automatically because it is very difficult to deduce from the traditional policy what communities should be defined between Security Gateways.

The wizard allows you define communities, and to drag-and-drop Security Gateways into the communities. The administrator must make Security Gateway 1 and Security Gateway 2 members of the same community by dragging both the Security Gateway objects into the same site-to-site community object.

You may prefer to create several communities with different encryption properties to reflect the way that the traditional VPN policy works.

If no communities have been previously defined, there are by default two predefined, empty community objects. One is a site-to-site VPN "intranet" community (a Mesh community), and the other is a remote access community. If these are the only two Communities, the wizard gives you the choice of simply placing all Security Gateways into the Site-to-Site Community, and placing all Remote Access Security Gateways into the Remote Access Community.

Conversion of Encrypt Rule

After Security Gateways have been placed into Communities, the Encrypt rules are converted. The converted rule base preserves the behavior of the Encrypt rule in Simplified VPN Mode to the greatest extent possible.

Encrypt rules are converted by the Conversion wizard to two rules:

A converted rule in a simplified Rule Base

The first rule says that the connection is matched and is allowed, if the connection originates at X and its destination is Y, within any Site-to-Site Community.

The second rule says that if a connection originates at X and has the destination Y, but is not encrypted (or decrypted) by any site-to-site community, the connection should be dropped.

The second rule (the Drop rule) is needed where either the source or the destination are not in the VPN Domain. In the Traditional policy, the Encrypt rule would drop this connection. If there were no drop rule in the Simplified policy, the connection may be matched to and allowed by a rule further down in the Rule Base.

When the Converted Rule Base is too Restrictive

This translation of Encrypt rules into two Simplified Mode rule is at least as restrictive as the original rule. However, in the converted Rule Base, some connections that were matched to and allowed by the original rule may be dropped. This may happen with connections between two hosts in the encryption domain of the same Security Gateway.

For example, in the Traditional mode rule, shown below, connections from a node in Net_A to a Node in Net_B are allowed:

Sample Encrypt Rule in a Traditional Rule Base

After the conversion to Simplified mode, a node in Net_A to a Node in Net_B will be dropped by the converted Rule Base. This is because community rules define traffic between VPN Domains, and do not relate to traffic within a VPN Domain.

Converted Rule in a Simplified Rule Base

To allow these connections in the converted rule-base, you must explicitly allow them. To do this, add one rule between the first rule and the second rule, for each policy target appearing in the "install on" field. For example, the two Rules in the table above become three rules below:

Manually Added Rule in the converted Encrypt Rule Base

In most cases it is not necessary to add these rules. Only add them when connections inside the encryption domain are matched by the Encrypt rule. An indication of this is the appearance of the log in SmartView Tracker "Both endpoints are in the Encryption Domain."

Conversion of Client Encrypt Rules

Each Client Encrypt rule translates to a single rule that preserves the behavior of the client Encrypt rule. For example, the Traditional Mode rule in the following table allows Remote Access users to access Net_D. 

Remote Access Rule in Traditional Mode

The translated rule is shown in the following table. The Remote Access community is put in the VPN field, and the Action of the rule is Accept: 

Translated Remote Access Rule in Simplified Mode

Conversion of Auth+Encrypt Rules

In a Traditional Mode policy, Auth+Encrypt Rules are rules with User, Client or Session Authentication, together with Add Encryption selected in the Action of the Rule.

For Auth+Encrypt rules, as shown with Client Authentication in the following table, the Source specifies both a restriction on the source location, and also the authorized users. Any connection matching the rule must be authenticated and encrypted. If encryption is not possible, the connection is dropped.

Since the identification of users is possible only in authentication rules, and not in drop rules, it is not possible to define a rule that drops connections that were not encrypted.

Add the Services that should not be encrypted inside the Community to the Excluded Services list. For example, if you have explicitly defined implied rules in the Traditional Policy. See How to Authorize Firewall Control Connections in VPN Communities.

Because of this, Auth+Encrypt rules cannot be automatically translated in such a way that the translated Rule Base is at least as restrictive as the original rule. Instead, the Converter wizard translates Auth+Encrypt rules to a single rule, and does not add a Drop rule, as shown in the following table. This is a security problem, because connections that match the Source location, where the users authenticated successfully, but were not encrypted, may be accepted further down in the translated Rule Base if some later rule specifies Accept for the same Source.

When the converter encounters Auth+Encrypt rules, it warns the administrator by displaying an error stating that the converter cannot translate such rules automatically. In this case it is important to review the translated rule base before installing it, in order to avoid security breaches. It may be necessary to add rules to make sure that all the traffic that was previously dropped by the original Rule Base is dropped in the translated Rule Base.

How the Converter Handles Disabled Rules

If a rule in the Traditional VPN Rule Base was disabled, the translated rule in the simplified Rule Base will also be disabled.

After Running the Wizard

After running the Wizard, examine the Rule Base to see that it has retained the desired functionality, and if necessary, optimize the Rule Base, and make other changes, as follows. These points have been covered in the earlier discussion, but are summarized here for convenience:

Take out Unneeded Drop Rules

In some cases you can delete the second Drop rule generated by the conversion of an Encrypt rule because it will never match any connection, and the first rule is sufficient. This is the case for rules where the following are true:

• The source and destination are located in the encryption domain of Security Gateways appearing in the "Installed on" column of the rule.
• A Community links all Security Gateways protecting addresses in the Source and also links Security Gateways protecting addresses in the Destination.

Another case where you can delete the second Drop rule generated by the conversion of an Encrypt rule is where connections that do not match the first rule are dropped by rules that appear later in the Rule Base. Sometimes you can group several Drop rules generated by the conversion of several Encrypt rules into a single Drop rule.

Add Rules Allowing Communication Inside the VPN Domain

Connections matching Encrypt rules where both endpoints are located inside the encryption domain of the same Security Gateway, are accepted in a Traditional Rule Base. To achieve the same effect in the simplified rule base, you must manually add rules that accept the traffic inside the encryption domains of the Security Gateways. In most cases it is not necessary to add these rules. Add them if you see the SmartView Tracker log message: "Both endpoint are in the Encryption Domain".

Auth+Encrypt Rules

Auth+Encrypt rules are not converted automatically. When such rules appear in the Rule Base, review the converted Rule Base and make sure that the security of these rules are maintained.