-
Using Management Center for VPN Routers 1.3
-
Preface
-
Introduction
-
Getting Started with Router MC
-
Router MC Scenarios
-
Working with Activities
-
Managing Devices
-
Configuring VPN Settings
-
Configuring an IOS Firewall on your VPN Router
-
Defining IKE Policies
-
Defining VPN Tunnel Policies
-
Configuring Translation Rules
-
Working with Building Blocks
-
Uploading Device Configurations
-
Deploying Configurations
-
Viewing Reports
-
Router MC Administration
-
Troubleshooting
-
Router MC Operating Prerequisites
-
Router MC User Permissions
-
Table Of Contents
Understanding IPSec Tunnel Policies
What Traffic is Secured in an IPSec Tunnel?
How is Traffic Secured in an IPSec Tunnel?
Viewing Existing Tunnel Policies
Accessing the Tunnel Policy Wizard
Viewing a Summary of the Tunnel Policy
Working with Dynamic Crypto Policies
Viewing Existing Dynamic Crypto Policies
Creating a Dynamic Crypto Policy
Editing a Dynamic Crypto Policy
Deleting a Dynamic Crypto Policy
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
•
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.
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
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. You can also filter traffic by protocol and port. See Defining a Traffic Filter for more information.
Note
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 and click the Edit button to view the policy definitions and change them if necessary.
Table 1-1 describes the fields and buttons in the Tunnel Policies page.
Note
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 1-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:
•
•
Note
Accessing the Tunnel Policy Wizard
To access the wizard, complete the steps in this procedure.
Before You Begin
•
•
Procedure
Step 1
Step 2
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
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 1
Step 2
Table 1-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. You can also specify that traffic matching a specific protocol, from specific ports, should be tunneled.
See What Traffic is Secured in an IPSec Tunnel?, for information about split tunneling and traffic filters.
Note
The traffic filter is defined in the Traffic Filter page of the Tunnel Policy wizard. See Table 1-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 1
Step 2
Step 3
Step 4
Step 5
Step 6
Table 1-3 describes the elements in the Traffic Filter page.
Table 1-3 Traffic Filter—GUI Reference
Check box column
Enables you to select a a traffic flow to move, edit, or delete it.
Spoke Side column
Specifies the networks on the spoke side whose traffic will be secured in the tunnel. This column can contain the IP address and subnet mask of a specific network, the IP address or host name of a host, or a network group name, representing a range of networks. See Working with Network Groups, page 1-13 for information about network groups.
Router MC automatically establishes the filter in both directions, from spoke to hub and from hub to spoke. Therefore, the specified networks serve as the traffic source for one direction and the traffic destination for the other direction.
Hub Side column
Specifies the network(s) on the hub side whose traffic will be secured in the tunnel. This column can contain the IP address and subnet mask of a specific network, the IP address or host name of a host, or a network group name, representing a range of networks. See Working with Network Groups, page 1-13 for information about network groups.
Router MC automatically establishes the filter in both directions, from spoke to hub and from hub to spoke. Therefore, the specified networks serve as the traffic source for one direction and the traffic destination for the other direction.
Move Up button
Click to move the selected ACE one row up in the list. ACEs are scanned from top to bottom in the list to see if the any of them matches the traffic flow.
Move Down button
Click to move the selected ACE one row down in the list. ACEs are scanned from top to bottom in the list to see if any of them matches the traffic flow.
Rows per page list box
Enables you to change the number of ACEs displayed in the list.
Create button
Click to create a custom ACE to specify a particular traffic flow to be secured in the tunnel. See Table 1-4 for a description of the Create ACE dialog box.
Edit button
Click to edit a selected ACE. The Create ACE dialog box appears and you can change the spoke and hub side network specifications as required.
Delete button
Click to delete an ACE.
Back button
Click to return to the previous page in the wizard.
Next button
Click to go to the next page in the wizard.
Cancel button
Click to exit the wizard without saving your settings.
Table 1-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 1-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 more information.
Procedure
Step 1
Step 2
Note
Step 3
Table 1-5 describes the elements in the Select Transform Set page.
Table 1-5 Select Transform Set—GUI Reference
Transform Set 1 list box
Provides a list of transform sets from which you can choose the transform set you require for your policy. These include predefined transform sets provided by Router MC and any transform sets that you or another user defined previously. You must select a transform set in the Transform Set 1 field but selecting additional transform sets is optional.
Transform Set 2 and 3 list boxes
Provide a list of transform sets from which you can choose additional transform sets for your policy. If more than one of your selected transform sets is supported by both peers, the transform set that provides the highest security will be used.
Edit buttons
The Edit button next to each Transform Set field enables you to modify the selected transform set. When you click the Edit button, the first page of the Transform Set wizard appears and you can edit the values for the selected transform set as required. See Editing a Transform Set, page 1-12 for more information.
Create button
Click to create a new transform set using the Transform Set wizard. See Creating a Transform Set, page 1-7 for more information.
Back button
Click to return to the previous page in the wizard.
Next button
Click to go to the next page in the wizard.
Cancel button
Click to exit the wizard without saving your settings.
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 1-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 1
Step 2
Step 3
OR
If Summary does not appear in the TOC, 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 1-6 describes the elements in the PFS page.
Table 1-6 PFS—GUI Reference
Use PFS check box
Select this check box to enable PFS. See Enabling PFS for more information.
Modulus Group list box
Select the required Diffie-Hellman key derivation algorithm. Router MC supports Diffie-Hellman group 1, group 2, and group 5 key derivation algorithms. Each group has a different size modulus:
Group 1: 768-bit modulus.
Group 2: 1024-bit modulus.
Group 5: 2048-bit modulus.
The larger the modulus, the higher the security and the more processing time is required. Therefore, use Group 1 on low-end routers and Group 2 or 5 on high-end routers.
Back button
Click to go back to the previous page in the wizard.
Next button
Available only if Summary appears in the TOC. See Defining System Settings, page 1-1.
Click to go to the next page in the wizard.
Finish button
Available only if Summary does not appear in the TOC. See Defining System Settings, page 1-1.
Click to exit the wizard and complete the policy creation or modification process.
Cancel button
Click to exit the wizard without saving your settings.
Viewing a Summary of the Tunnel Policy
Note
The Summary page provides an overview of your tunnel policy definitions for your verification. See Table 1-7 for a description of the fields and buttons in this page.
Procedure
Step 1
Step 2
Table 1-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 1
Step 2
Step 3
Step 4
Step 5
Deleting a Tunnel Policy
You can delete any existing tunnel policy. You can delete multiple policies at one time.
Before You Begin
•
•
Procedure
Step 1
Step 2
Step 3
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
Note
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 1-8 describes the elements in the Dynamic Crypto page.
Table 1-8 Dynamic Crypto—GUI Reference
Inherit default policies check box
This check box is present if an object other than Global is selected in the Object Selector. If this check box is selected, dynamic crypto policies that have been inherited from a higher level object are displayed in the list of policies. If you do not want these policies to be applied to the selected object, deselect the check box to remove them from the list. If you deselect this check box, any new policies you define on the selected object effectively override the policies inherited from a higher level object.
Check box column
Enables you to select a dynamic crypto policy to edit or delete it. You can select more than one check box at a time to delete multiple policies.
Interface column
Displays the interface for which the policy is defined.
Transform Set column
Displays the transform set selected for the policy
Create button
Click to create a dynamic crypto policy. The Create Dynamic Crypto Policy dialog box appears. See Table 1-9 for a description of this dialog box.
Edit button
Click to edit a selected dynamic crypto policy.
Delete button
Click to delete a selected dynamic crypto policy or multiple selected policies.
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 1
Step 2
Step 3
Step 4
Step 5
Table 1-9 describes the elements in the Create Dynamic Crypto page.
Table 1-9 Create Dynamic Crypto Policy—GUI Reference
Interface Type list box
Select the interface on the hub to which you want the dynamic crypto policy to be written.
Slot list box
Select the slot on which the interface is located.
Port list box
Select the interface's physical port.
Subinterface field
If you want to define the dynamic crypto policy on a subinterface, specify the subinterface in this field.
Show Interfaces button
Click to open the Available Interfaces dialog box, in which you can select from a list of available interfaces. See Table 1-4 on page 1-22 for a description of elements displayed in the Available Interfaces dialog box.
Transform Set list box
Select the transform set to be used for the policy. You can only select one transform set per dynamic crypto policy. See Understanding Transform Sets, page 1-2 for more information.
OK button
Click to save your definitions and close the dialog box.
Cancel button
Click to exit the dialog box without saving your definitions.
Editing a Dynamic Crypto Policy
You can edit any existing dynamic crypto policy.
Before You Begin
•
•
Procedure
Step 1
Step 2
Step 3
Step 4
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 1
Step 2
Step 3
Defining the IPSec Lifetime
IPSec lifetime refers to the global lifetime settings for the crypto IPSec security association (SA). The IPSec lifetime can be specified in seconds and/or kilobytes. Router MC provides the default IPSec lifetime values. You can change these default values if necessary. Follow the procedure below.
Procedure
Step 1
Step 2
Step 3
Step 4
Table 1-10 describes the elements in the IPSec Lifetime page.
