Table of Contents

Defining VPN Tunnel Policies

A tunnel policy consists of a set of rules that define the endpoints of the IPSec tunnel, what traffic is routed into the tunnel, and how the traffic is secured in the tunnel.

The following topics provide information about defining tunnel policies in Router MC:

Understanding IPSec Tunnel Policies

IPSec is a framework of open standards for ensuring secure private communications over the Internet. Based on standards developed by the Internet Engineering Task Force (IETF), IPSec ensures confidentiality, integrity, and authenticity of data communications across a public network.

With IPSec, data is transmitted over a public network through tunnels. Each tunnel is a secure, logical communication path between two routers (endpoints), commonly referred to as peers. Tunneling is a technique that uses an internetworking infrastructure to transfer data for one network over another network. The data or payload to be transferred can be the frames of another protocol. The tunneling protocol encapsulates each frame in an additional header that provides routing information to enable the frame to traverse the network between the tunnel endpoints. When an encapsulated frame arrives at its destination tunnel endpoint, it is unencapsulated and sent on to its final destination. Tunneling includes the entire process of encapsulation, transmission, and unencapsulation of frames.

Within the IPSec tunnels, data is authenticated and secured by means of a combination of authentication and encryption algorithms, known as a transform set.

What is a Tunnel Policy?

A tunnel policy is a series of policy rules that define:

This information is defined in a crypto map entry, which is a named series of CLI commands. Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set, which is applied to the VPN interfaces on the relevant devices. All IP traffic passing through the interface is evaluated against the applied crypto map set. If a crypto map entry sees outbound IP traffic that should be protected and the crypto map specifies the use of IKE, a security association is negotiated with the remote peer according to the parameters included in the crypto map entry.

When two peers try to establish a security association, they must each have at least one crypto map entry that is compatible with one of the other peer's crypto map entries.

For two crypto map entries to be compatible, they must meet the following minimum criteria:

How does Router MC manage policy compatibility on VPN tunnel peers?

Router MC automatically ensures that the policies on both peers are compatible so that the VPN connection can be established.

In Router MC, tunnel policies are defined on spokes. Router MC generates the relevant CLI commands for the spoke and also automatically adds matching policies on the spoke's corresponding hub. If you always deploy to both peers of the VPN connection together, Router MC will ensure compatible policy configuration.

If the spoke identity is unknown, dynamic crypto policies can be created on the hub. See Working with Dynamic Crypto Policies for more information.

Note   On deployment of tunnel polices to a device, Router MC removes all existing crypto maps on the VPN interface of a hub or spoke that were manually defined through the CLI.

What Traffic is Secured in an IPSec Tunnel?

When creating IPSec tunnels, the main goal is to protect data flows that carry confidential or sensitive data over an untrusted or public network. Therefore, before planning your IPSec tunnel implementation, you must have a solid understanding of the traffic you want protected by IPSec tunnels, and the sources and destinations of this traffic.

For example, you might want specific traffic between a remote office and a main office intranet to be encrypted so that remote office users can access confidential company information from the main office's internal network, yet at the same time permit traffic to the Internet.

The ability to transmit both secured and unsecured traffic on the same interface is known as split tunneling. Split tunneling requires that you specify exactly which traffic will be secured and what the destination of that traffic is, so that only the specified traffic enters the IPSec tunnel, while the rest is transmitted unencrypted across the public network.

With IPSec, crypto ACLs define what traffic should be protected between two IPSec peers. Traffic might be selected based on source and destination address.

Note   The crypto ACLs used for IPSec are used only to determine which traffic should be protected by IPSec, not which traffic should be blocked or permitted through the interface.

ACLs are applied to interfaces by way of crypto map sets. Each tunnel policy you create with Router MC is translated into a crypto map entry that includes an ACL. A crypto map set can contain multiple entries, each with a different ACL. The crypto map entries are searched in order and the router tries to match the packet to the ACL specified in each entry.

Multiple IPSec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of security algorithms. If you want certain traffic to receive one combination of IPSec protection (for example, authentication only) and other traffic to receive a different combination of IPSec protection (for example, both authentication and encryption), you must create two separate tunnel policies, each one with a different ACL to define the two different types of traffic. However, if you want different traffic flows to receive the same set of security algorithms, you can define one tunnel policy in which you differentiate between the traffic flows by using different ACEs.

If you configure multiple ACEs for a given ACL, the first statement that is matched is usually the condition used to determine the scope of the IPSec security association. Later, if traffic matches a different statement of the ACL, a new, separate IPSec security association will be negotiated to protect traffic matching the newly matched ACL.

Traffic Filters in Router MC

In Router MC, you specify what traffic to secure in your IPSec tunnels by defining a traffic filter. This provides the ACL reference in the crypto map entry that is written to the relevant devices for each tunnel policy. Router MC provides a predefined filter to tunnel internal traffic on the hub and the spoke. This filter is made up of predefined ACEs that specify the flows that should be tunneled, as follows:

The predefined ACEs together ensure that all the internal traffic on the hub and spoke will be tunneled.

In addition, you have the option to tunnel specific traffic flows only by creating a custom traffic filter to specify the source and destination of these flows.

Note   When using Generic Routing Encapsulation (GRE), you cannot isolate specific traffic flows on an interface for securing in a GRE tunnel. With GRE, all flows between the networks directly attached to the peers' inside interfaces will be secured in the GRE tunnel as long as the inside interfaces on both sides are published in the secured Interior Gateway Protocol (IGP) process. See Prerequisites for Successful Configuration of GRE for more information.

How is Traffic Secured in an IPSec Tunnel?

Traffic that enters an IPSec tunnel is secured by means of a combination of security protocols and algorithms, called a transform set. During the IPSec security association negotiation, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and will be applied to the protected traffic as part of both peers' IPSec security associations.

In Router MC, transform sets are selected during the definition of tunnel policies, usually on spokes (except for dynamic crypto policies). Router MC generates configurations for the spokes and by inference, also for their assigned hubs, thereby ensuring that there are matching transform sets on the peers.

Router MC provides predefined transform sets that you can use in your tunnel policies. You can also create your own transform sets.

Working With Tunnel Policies

Tunnel policies define the VPN connection between two peers. They specify which traffic will be secured and the authentication and encryption algorithms that will be used to secure the traffic. For each of your tunnel policies, Router MC generates the appropriate CLI commands for deployment to your devices. Router MC creates a crypto map entry for each tunnel policy.

In Router MC, tunnel policies are defined on spokes. Router MC infers from the spoke policies what commands are required on the spokes' assigned hubs to establish the VPN connection, and automatically generates these commands for the relevant hubs.

You can access the tunnel policies section of the Router MC user interface by selecting the Configuration tab and then selecting the Tunnels option. Router MC provides a wizard-based interface that enables you to quickly and easily define all the components of IPSec tunnel policies. You can either define policies on individual spokes or on a group of spokes simultaneously.

A tunnel policy's priority is indicated by its position in the list of policies (higher indicates higher priority). If a traffic flow matches the filter conditions in more than one tunnel policy, the policy with the highest priority is applied. You can change the order of the policies in the list according to the priority you want them to have. For example, if you have one tunnel policy for all internal traffic on the hub and spoke and a second policy for high-security traffic to a specific server (that also matches the internal traffic condition), the second policy must be in a higher position in the list so that it is applied.

The following topics provide information about working with tunnel policies in Router MC:

Viewing Existing Tunnel Policies

The Tunnel Policies page, accessed from the Tunnels section of the Configuration tab, displays a list of all the tunnel policies that have been defined on a particular device or device group, in table format. Each table row represents a tunnel policy and each table column provides a different field of information for that policy. You can select a policy in the list to edit or delete it.

Table 9-1 describes the fields and buttons in the Tunnel Policies page.

Tunnel policies are listed in the order that you define them. A tunnel policy's priority is indicated by its position in the list of policies (higher indicates higher priority). By default, policies that were inherited from higher level device groups are placed at the bottom of the list. You can remove inherited policies from the list by deselecting the Inherited Policies check box. If you do this, the inherited policies will not be deployed to the devices.

Table 9-1 describes the elements in the Tunnel Policies page.

Creating a Tunnel Policy

Tunnel policies are defined on spokes. Router MC generates CLI commands for the spokes to implement the policies. It also deduces what commands are required on the spokes' assigned hubs to implement the policies and generates these commands as well.

You can create tunnel policies on individual spokes or on a group of spokes. You first select the required spoke or group in the Object Selector and then you create the tunnel policy. You can create several tunnel policies per device, according to your network requirements.

You create a tunnel policy using the Tunnel Policy wizard. The following topics describe the tasks you perform to create a tunnel policy using this wizard:

Accessing the Tunnel Policy Wizard

To access the wizard, complete the steps in this procedure.

Before You Begin

Procedure

Step 2   Select Tunnel Policies from the TOC.

The Tunnel Policies page appears. It contains a list of the tunnel policies defined on the selected device or device group (if any).

Step 3   Click Create.

The first page of the Tunnel Policy wizard appears. The steps in the wizard are listed in the TOC on the left side of the page.

Naming the Tunnel Policy

The Name and Comment page of the Tunnel Policy wizard appears when you click the Create button in the Tunnel Policies page. It enables you to specify a name and description for the policy.

After you have finished creating the policy, it is listed by name in the Tunnel Policies page (see Viewing Existing Tunnel Policies for more information). Because the policy name enables you to distinguish one policy from another for reviewing, editing, or deleting policies, you should assign a logical name and description that reflect the policy contents.

Procedure

Step 2   Click Next. The Traffic Filter page appears. Proceed to Defining a Traffic Filter.

Table 9-2 describes the elements in the Tunnel Policy Name and Comment page.

Defining a Traffic Filter

The Traffic Filter page of the Tunnel Policy wizard enables you to specify the traffic that will be secured in the IPSec tunnel. This provides the ACL reference in the crypto map entry that is written to the relevant devices for each tunnel policy.

Router MC provides a predefined filter to tunnel internal traffic on the hub and the spoke. This filter is made up of predefined ACEs that specify the flows that should be tunneled, as follows:

The predefined ACEs together ensure that all the internal traffic on the hub and spoke will be tunneled.

You have the option to delete any of the predefined ACEs from the filter if they are not currently relevant. However, best practice would be to leave them in the filter. Router MC will ignore the currently irrelevant ACEs. For example, if you have not defined internal networks for your devices, Router MC will ignore the ACEs specifying internal networks. However, if you define the internal networks at a later stage, these ACEs will become relevant again and you will not need to create a new ACE to filter traffic from internal networks.

In addition to predefined ACEs, you have the option to tunnel specific traffic flows only by creating a custom ACE. In this ACE, you specify the traffic on the spoke side and the traffic on the hub side that you want to secure. Router MC automatically establishes the filter in both directions, meaning from hub to spoke and vice versa.

See What Traffic is Secured in an IPSec Tunnel?, for information about split tunneling and traffic filters.

Note   When GRE is enabled, only traffic between the inside interfaces on both peers is secured. The options in the Traffic Filter page are grayed out and you cannot create a custom ACE. See Understanding GRE, page 6-4 for information about GRE.

The traffic filter is defined in the Traffic Filter page of the Tunnel Policy wizard. See Table 9-3 for a description of the options in the Traffic Filter page. The order of the ACEs in the Traffic Filter page has significance in that the list is searched for a matching traffic flow definitions at both peers, from top to bottom. The policy is applied to the first matching traffic flow.

Define the traffic filter for your policy by following the steps in this procedure.

Procedure

Step 2   If you want to secure an additional specific flow, click Create to create a custom ACE to specify the flow.

Step 3   If you clicked the Create button, the Create ACE dialog box appears. Specify the spoke side and hub side devices/networks to be secured and click Apply. Note that you can either enter an IP address or you can select a predefined network group. See Table 9-4 for a description of the Create ACE dialog box.

Step 4   Click Next in the Traffic Filter page. Proceed to Selecting Transform Sets.

Table 9-3 describes the elements in the Traffic Filter page.

Table 9-4 describes the elements in the Create ACE dialog box.

Selecting Transform Sets

The Transform Sets page of the Tunnel Policy wizard enables you to select the transform sets to be used for the tunnel policy. This will specify which authentication and encryption algorithms will be used to secure the traffic in the tunnel. See Table 9-5 for a description of the fields in the Transform Sets page.

You can select up to three transform sets per tunnel policy. If you are defining the policy on a spoke or a group of spokes, it is usually not necessary to select more than one transform set. This is because the spoke's assigned hub would typically be a higher performance router capable of supporting any transform set that the spoke supports. However, if you are defining the policy on a hub for dynamic crypto, you should select more than one transform set to ensure that there will be a transform set match between the hub and the unknown spoke.

Router MC provides you with predefined transform sets. You can use these if they meet your requirements.

You can access the Transform Set wizard directly from the Transform Sets page to create a new transform set, if required. See Selecting Transform Sets, for information about transform sets.

Procedure

Step 2   If required, select additional transform sets in the Transform Set 2 and Transform Set 3 fields respectively.

---

Note    You can click the Edit button to modify a selected transform set.

---

Step 3   Click Next. Proceed to Enabling PFS.

Table 9-5 describes the elements in the Select Transform Set page.

Enabling PFS

Perfect forward secrecy (PFS) is a cryptographic characteristic associated with a derived shared secret value. With PFS, if one key is compromised, previous and subsequent keys are not compromised, because subsequent keys are not derived from previous keys. See Table 9-6 for a description of the fields in the PFS page.

PFS generates a new key by carrying out a Diffie-Hellman (DH) exchange every time a new quick-mode SA needs new key generation. This option increases the level of security but at the same time increases processor overhead. Therefore, use PFS only if the sensitivity of the data mandates it. The strength of the Diffie-Hellman exchange is configurable; Groups 1 (768 bits), 2 (1024 bits), and 5 (2048 bits) are supported. Group 2 is recommended, because Group 5 is not supported on some smaller routers, such as Cisco 800, 2500, or1700 routers.

Procedure

Step 2   Select the required Diffie-Hellman group from the Modulus Group list box.

Step 3   Click Next. Proceed to Viewing a Summary of the Tunnel Policy.

Table 9-6 describes the elements in the PFS page.

Viewing a Summary of the Tunnel Policy

The Summary page provides an overview of your tunnel policy definitions for your verification. See Table 9-7 for a description of the fields and buttons in this page.

Procedure

Step 2   Click Finish to complete the creation of the tunnel policy or go back to a previous step in the wizard to change your definitions, as required.

Table 9-7 describes the elements in the Tunnel Policy Summary page.

Editing a Tunnel Policy

You can edit any existing tunnel policy. Policy editing is done in the Tunnel Policies wizard that was used to create the policy. You can use the TOC to go directly to the page you want to edit.

Before You Begin

Procedure

Step 2   Select Tunnel Policies from the TOC. The Tunnel Policies page appears.

Step 3   Select the check box next to the policy you want to edit and click Edit. The Name and Comment page of the Tunnel Policies wizard appears. It contains the name and comment for the selected policy.

Step 4   Select the required page from the TOC or click the Next button to move through the pages in the wizard. Each page shows the values that were defined for the selected tunnel policy and you can edit them as required.

Step 5   Click Finish when you have finished editing the policy.

Deleting a Tunnel Policy

You can delete any existing tunnel policy. You can delete multiple policies at one time.

Before You Begin

Procedure

Step 2   Select Tunnel Policies from the TOC. The Tunnel Policies page appears.

Step 3   Select the check box next to each policy you want to delete and click Delete. The policy is deleted from the list of policies.

Working with Dynamic Crypto Policies

Dynamic crypto policies are recommended for use in networks where the peers are not always predetermined. They allow remote peers to exchange IPSec traffic with a local hub even if the hub does not know the remote peer's identity.

A dynamic crypto map policy created in Router MC essentially creates a crypto map entry without all the parameters configured. The missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match a remote peer's requirements.

Dynamic crypto map entries are used when an unknown remote peer tries to initiate an IPSec security association with the local hub. The hub cannot be the initiator of the security association negotiation.

Note   Dynamic crypto policies are only relevant for hubs.

Note   If a dynamic crypto policy is defined on the hub, dynamic preshared keys must be defined for IKE authentication. See Creating Dynamic Shared Keys for more information.

The following topics provide information about working with dynamic crypto policies:

Viewing Existing Dynamic Crypto Policies

The Dynamic Crypto Policies page, accessed from the Tunnels section of the Configuration tab, displays a list of all the dynamic crypto policies that have been defined on a particular device or device group, in table format. Each table row represents a dynamic crypto policy and each table column provides a different field of information for that policy. You can select a policy in the list to edit or delete it.

Table 9-8 describes the elements in the Dynamic Crypto page.

Creating a Dynamic Crypto Policy

Dynamic crypto policies are relevant for hubs only. You can create a dynamic crypto policy on individual hubs or on a device group that contains a hub(s), in which case the policy will only be written to the hubs (not to any spokes that might be contained in the group).

Follow the procedure below to create a dynamic crypto policy.

Before You Begin

Procedure

Step 2   Select Dynamic Crypto Policies from the TOC. The Dynamic Crypto Policies page appears. See Table 9-8 for a description of the elements in this page.

Step 3   Click Create. The Create Dynamic Crypto Policy dialog box appears. See Table 9-9 for a description of the elements in this dialog box.

Step 4   Name the policy and select an interface and a transform set in the fields provided.

Step 5   Click OK.

Table 9-9 describes the elements in the Create Dynamic Crypto page.

Editing a Dynamic Crypto Policy

You can edit any existing dynamic crypto policy.

Before You Begin

Procedure

Step 2   Select Dynamic Crypto Policies from the TOC. The Dynamic Crypto Policies page appears.

Step 3   Select the check box next to the dynamic crypto policy you want to edit and click Edit. The Dynamic Crypto dialog box appears. It shows the values defined for the selected policy. See Table 9-9 for a description of the dialog box.

Step 4   Edit the policy as required and click OK.

Deleting a Dynamic Crypto Policy

You can delete any existing dynamic crypto policy. You can delete multiple policies at the same time.

Before You Begin

Procedure

Step 2   Select Dynamic Crypto Policies from the TOC. The Dynamic Crypto Policies page appears.

Step 3   Select the check box next to the dynamic crypto policy or multiple policies you want to delete and click Delete. The policy is removed from the list.