Implementing IPSec Network Security on Cisco IOS XR Software
Available Languages
Table Of Contents
Implementing IPSec Network Security on Cisco IOS XR Software
Feature History for Implementing IPSec Network Security on Cisco XR 12000 Series Router Contents
Prerequisites for Implementing IPSec Network Security
Restrictions for Implementing IPSec Network Security
Restrictions for Implementing a Cisco IPSec VPN SPA Within an IPSec Network
Information About Implementing IPSec Networks
Global Lifetimes for IPSec Security Associations
Manual IPSec Security Associations
DF Bit Override Functionality with IPSec Tunnels
IPSec Security Association Idle Timers
Prefragmentation for Cisco IPSec VPN SPAs
Information About IPSec Networks and the Cisco IPSec VPN SPA Using Cisco IOS XR Software
Displaying the SPA Hardware Type
Information About Security for VPNs with IPSec
MPLS Encapsulated Packets on Inbound Direction
Information About Implementing IPSec in a Site-to-Site or Remote VPN Topology
Restrictions to Implementing IPSec in a Site-to-Site or Remote VPN Topology
Configuration of IPSec in a Site-to-Site VPN Topology
Site-to-Site Encrypted Generic Routing Encapsulation Tunnels
Configuration of IPSec in a Remote-Access VPN Topology
Information About Object Tracking in IPSec
How to Implement General IPSec Configurations for IPSec Networks
Setting Global Lifetimes for IPSec Security Associations
Configuring the DF Bit for the Encapsulating Header in IPSec Tunnels
Configuring the IPSec Antireplay Window
Restrictions to Configuring the IPSec Antireplay Window
Configuring the IPSec Antireplay Window: Expanding and Disabling Globally
Disabling IPSec Replay Checking on a Crypto Profile
Configuring IPSec NAT Transparency
Disabling IPSec NAT Transparency
Configuring IPSec Security Association Idle Timers
Restrictions to Configuring IPSec SA Idle Timers
Lifetimes for IPSec Security Associations
IPSec Security Association Idle Timers
Configuring the IPSec SA Idle Timer Globally
Configuring the IPSec SA Idle Timer for Each Crypto Profile
Disabling Prefragmentation for Cisco IPSec VPN SPAs
Disabling Prefragmentation for service-ipsec Interfaces
Disabling Prefragmentation for service-gre Interfaces
Configuring Reverse-Route Injection in a Crypto Profile
Configuring IPSec Failure History Table Size
How to Implement IPSec Network Security for Locally Sourced and Destined Traffic
About Use of the any Keyword in Crypto Access Lists
Applying Crypto Profiles to tunnel-ipsec Interfaces
Applying Crypto Profiles to Crypto Transport
How to Implement IPSec Network Security for VPNs
Restrictions to Implementing IPSec Network Security for VPNs
Configuring IPSec Service Virtual Interfaces
Configuring Static IPSec Virtual Interfaces
Configuring IPSec-Protected GRE Virtual Interfaces
Configuring the Default Path Maximum Transmission Unit for the SA
Configuring a Static Profile and Attaching to a tunnel-ipsec Interface: Example
Configuring a Dynamic Profile and Attaching It to a tunnel-ipsec Interface: Example
Configuring a Static Profile and Attaching to Transport: Example
Configuration Examples for an IPSec Network with a Cisco IPSec VPN SPA
Displaying the SPA Hardware Type: Example
Configuring IPSec for a VRF-Aware service-ipsec Interface: Example
Configuring a service-gre Interface: Example
Configuration Examples for the Use of Object Tracking in IPSec
Tracking Connectivity From Site to Site, Based on a Physical or Logical Interface: Example
Option 1: Track Physical Interfaces
Option 2: Track a List of Logical Interfaces
Tracking Connectivity on a Remote Site, Using Routing Protocol Prefixes: Example
Option 1: Track the Routing Prefix in the Routing Table
Option 2: Track a List of Objects
Configuration Examples for Implementing IPSec in a Site-to-Site or Remote VPN Topology
Configuring IPSec in a Site-to-Site VPN Topology: Example
Configuring IPSec in a Remote-Access VPN Topology: Example
Implementing IPSec Network Security on Cisco IOS XR Software
IP Security (IPSec) provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets between participating IPSec devices ("peers"), such as Cisco routers.
With IPSec, data can be sent across a public network without observation, modification, or spoofing, which enables applications, such as Virtual Private Networks (VPNs), including intranets, extranets, and remote user access.
IPSec for Cisco IOS XR software supports the following two types of traffic:
•
IPSec for locally sourced traffic or traffic terminated on the router. Either tunnel-ipsec interfaces or a transport entity are used. This type is also called software-based IPSec.
•
This module describes the tasks that you need to implement IPSec network security on your Cisco IOS XR network.
Note
Feature History for Implementing IPSec Network Security on Cisco XR 12000 Series Router
Contents
•
•
•
•
•
•
•
•
•
•
•
•
•
Prerequisites for Implementing IPSec Network Security
The following prerequisites are required to implement IPSec network security:
•
•
•
For detailed information about optional PIE installation, see Cisco IOS XR System Management Configuration Guide.
•
•
Restrictions for Implementing IPSec Network Security
If you use Network Address Translation (NAT), you must configure static NAT translations so that IPSec works properly. In general, NAT translation should occur before the router performs IPSec encapsulation; in other words, IPSec should be working with global addresses.
Note
Restrictions for Implementing a Cisco IPSec VPN SPA Within an IPSec Network
The following restrictions exist with regard to implementing a Cisco XR 12000 Series Router IPSec VPN SPA within an IPSec network:
•
•
•
•
The following restrictions are known when implementing IPSec with the Cisco XR 12000 Series Router IPSec VPN SPA for Internet Security Association Key Management Protocol (ISAKMP) and IPSec profile configurations:
•
•
•
The following restrictions are known to implement Cisco XR 12000 Series Router IPSec VPN SPA for the tunnel source address:
•
•
Information About Implementing IPSec Networks
To implement IP network security, you should understand the following concepts:
•
•
•
•
Note
Crypto Profiles
Crypto profile entries created for IPSec combine the various parts used to set up IPSec security associations (SAs), including the following:
•
•
•
•
Crypto profiles are applied to IPSec interfaces (for example, tunnel-ipsec, service-ipsec, and service) or crypto transport.
If the access control lists (ACLs) specified within the profile match any outbound IP traffic, the IP traffic is protected by IPSec. The SA is established with the remote peer by IKE.
When using service-gre interfaces, the profile, which is attached to the interface, is not configured with an explicit ACL. Instead, all traffic, which is destined to the GRE tunnel, is protected by IPSec.
The policy described in the crypto profile entries is used during the negotiation of SAs. If the local router initiates the negotiation, it uses the policy specified in the static crypto profile entries to create the offer to be sent to the specified IPSec peer. If the IPSec peer initiates the negotiation, the local router checks the policy associated with the interface or profile associated with the identity specified in the ISAKMP profile, which is being used to decide whether to accept or reject the peer's request (offer).
For IPSec to succeed between two IPSec peers, both peers' crypto profile entries must contain compatible configuration statements. When two peers try to establish an SA, each must have at least one crypto profile entry that is compatible with one of the other peer's crypto profile entries. For two crypto profile entries to be compatible, they must at least meet the following criteria:
•
•
Note
•
Dynamic Crypto Profiles
A dynamic crypto profile entry is essentially a crypto profile entry without all the parameters configured. It acts as a policy template in which the missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match the requirements of a remote peer. This allows remote peers to exchange IPSec traffic with the router even if the router does not have a crypto profile entry specifically configured to meet all of the remote peer's requirements.
Dynamic crypto profiles are not used by the router to initiate new IPSec SAs with remote peers. Dynamic crypto profiles are used when a remote peer tries to initiate an IPSec SA with the router. Dynamic crypto profiles are also used in evaluating traffic.
If the router accepts the peer's request, at the point that it installs the new IPSec SAs it implicitly installs a temporary crypto profile entry. This entry is filled in with the results of the negotiation. At this point, the router performs normal processing, using this temporary crypto profile entry as a normal entry, even requesting new SAs if the current ones are expiring (based upon the policy specified in the temporary crypto profile entry). After the flow expires (that is, all of the corresponding SAs expire), the temporary crypto profile entry is then removed.
Static Crypto Profiles
When static crypto profile entries exist, if outbound traffic matches a permit statement in an access list and the corresponding SA is not yet established, the router initiates new SAs with the remote peer. In the case of dynamic crypto profile entries, if no SA existed, the traffic would be dropped because dynamic crypto profiles are not used for initiating new SAs.
Crypto Access Lists
Crypto access lists are used to define all IP traffic whether or not it is protected by crypto. For example, access lists can be created to protect all IP traffic between Subnet A and Subnet Y or Telnet traffic between Host A and Host B.
The access lists themselves are not specific to IPSec. It is the crypto profile entry referencing the specific access list that defines whether IPSec processing is applied to the traffic matching a permit in the access list.
Crypto access lists associated with IPSec crypto profile entries have four primary functions:
•
•
•
•
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 different crypto access lists to define the two different types of traffic.
Transform Sets
A transform set represents a certain combination of security protocols and algorithms. During the IPSec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow.
You can specify multiple transform sets and then one or more of these transform sets in a crypto profile entry. The transform set defined in the crypto profile entry is used in the IPSec SA negotiation to protect the data flows specified by that crypto profile entry's access list.
During IPSec SA negotiations with IKE, 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 applied to the protected traffic as part of both peers' IPSec SAs.
If you change a transform set definition, the change is applied only to crypto profile entries that reference the transform set. The change will not be applied to existing SAs, but is used in subsequent negotiations to establish new SAs. If you want the new settings to take effect sooner, you can clear all or part of the SA database by using the clear crypto ipsec sa command.
Global Lifetimes for IPSec Security Associations
You can change the global lifetime values that are used when negotiating new IPSec SAs.
Two lifetimes exist: a "timed" lifetime and "traffic-volume" lifetime. An SA expires after the first of these lifetimes is reached. The default lifetimes are 3600 seconds (1 hour) and 4,194,303 kilobytes (10 MBps for 1 hour).
A lifetime per profile is also supported. If a profile is configured with a lifetime, it overrides the global definition.
If you change a global lifetime, the new lifetime value is not applied to currently existing SAs, but is used in the negotiation of subsequently established SAs. If you want to use the new values immediately, you can clear all or part of the SA database. For more information, see the documentation of the clear crypto ipsec sa command in Cisco IOS XR System Security Configuration Guide.
IPSec SAs use one or more shared secret keys. These keys and their SAs time out together.
Assuming that the particular crypto profile entry does not have lifetime values configured, when the router requests new SAs it specifies its global lifetime values in the request to the peer; it uses this value as the lifetime of the new SAs. When the router receives a negotiation request from the peer, it uses the smaller of either the lifetime value proposed by the peer or the locally configured lifetime value as the lifetime of the new SAs.
The SA (and corresponding keys) expire according to whichever comes sooner, either after the number of seconds has passed (specified by the seconds keyword) or amount of traffic in kilobytes is passed (specified by the kilobytes keyword).
A new SA is negotiated before the lifetime threshold of the existing SA is reached, to ensure that a new SA is ready for use when the old one expires. The new SA is negotiated approximately 30 seconds before the seconds lifetime expires or when the volume of traffic through the tunnel reaches 300 kilobytes less than the kilobytes lifetime (whichever comes first).
If no traffic has passed through the tunnel during the entire life of the SA, a new SA is not negotiated when the lifetime expires. Instead, a new SA is negotiated only when IPSec sees another packet that should be protected.
Manual IPSec Security Associations
The use of manual IPSec security associations is a result of a prior arrangement between the users of the local router and the IPSec peer. The two parties can begin with manual security associations, but must move to using security associations established through IKE, or the system belonging to the remote party cannot support IKE. If IKE is not used to establish security associations, there is no negotiation of security associations, so the configuration information in both systems must be the same for traffic to be processed successfully by IPSec.
The local router can simultaneously support manual and IKE-established security associations, even within a single crypto profile entry. There is little reason to disable IKE on the local router unless the router supports only manual security associations.
Perfect Forward Secrecy
Perfect Forward Secrecy (PFS) ensures that a given key of an IPSec security association (SA) is not derived from any other secret, such as some other keys. In other words, if someone broke a key, PFS would ensure that the attacker would not be able to derive any other key. If PFS is not enabled, someone can hypothetically break the IKE SA secret key, copy all the IPSec-protected data, and use knowledge of the IKE SA secret to compromise the IPSec SAs set up by this IKE SA. With PFS, breaking IKE does not give an attacker immediate access to IPSec. The attacker needs to break each IPSec SA individually.
During negotiation, the set pfs command causes IPSec to request PFS when requesting new security associations for the crypto profile entry. If the set pfs command statement does not specify a group, the default (group1) is sent. If the peer initiates the negotiation and the local configuration specifies PFS, the remote peer must perform a PFS exchange or the negotiation fails. If the local configuration does not specify a group, a default of group1 is assumed, and an offer of either group1, group2, or group5 is accepted. If the local configuration specifies group2 or group5, the group must be part of the offer from the peer or the negotiation fails. If the local configuration does not specify PFS, the configuration accepts any offer of PFS from the peer.
Checkpointing
IPSec checkpoints SAs in the local database. If an IPSec process restarts, SAs are retrieved from the local database and need not be re-established with remote peers.
DF Bit Override Functionality with IPSec Tunnels
Note
A Don't Fragment (DF) bit is a bit within the IP header that determines whether a router is allowed to fragment a packet. The DF Bit Override Functionality with IPSec Tunnels feature allows you to specify whether your router can clear, set, or copy the DF bit from the encapsulated header.
Some configurations have hosts that perform the following functions:
•
•
•
If your configurations have hosts that prevent them from learning about the available MTU size, you can configure your router to clear the DF bit and fragment the packet.
The DF Bit Override Functionality with IPSec Tunnels feature allows you to configure the setting of the DF bit when encapsulating IPSec tunnels for IPSec traffic on a global or per-interface level. Thus, if the DF bit is set to clear, routers can fragment packets regardless of the original DF bit setting.
IPSec Antireplay Window
Note
Cisco IPSec authentication provides antireplay protection against an attacker duplicating encrypted packets, by assigning a unique sequence number to each encrypted packet. (Security association [SA] antireplay is a security service in which the receiver can reject old or duplicate packets to protect itself against replay attacks.) The decryptor checks off the sequence numbers that it has seen before. The encryptor assigns sequence numbers in an increasing order. The decryptor remembers the value X of the highest sequence number that it has already seen. N is the window size, and the decryptor also remembers whether it has seen packets having sequence numbers from X-N+1 through X. Any packet with the sequence number smaller than X-N is discarded. Currently, N is set at 64, so only 64 packets can be kept in the memory of the decryptor.
At times, however, the 64-packet window size is not sufficient. For example, Cisco quality of service (QoS) gives priority to high-priority packets, which could cause some low-priority packets to be discarded even though they could be one of the last 64 packets received by the decryptor. The IPSec Antireplay Window: Expanding and Disabling feature allows you to expand the window size, allowing the decryptor to keep more than 64 packets in its memory.
IPSec NAT Transparency
Note
Previously, a standard IPSec Virtual Private Network (VPN) tunnel does not work if there were one or more Network Address Translator (NAT) or Point Address Translation (PAT) points in the delivery path of the IPSec packet. The IPSec NAT transparency feature makes NAT IPSec-aware; therefore, allowing remote access users to build IPSec tunnels to home gateways.
IPSec Security Association Idle Timers
Note
When a router running Cisco IOS XR software creates an IPSec SA for a peer, resources must be allocated to maintain the SA. The SA requires both memory and several managed timers. For idle peers, these resources are wasted. If enough resources are wasted by idle peers, the counter could be prevented from creating new SAs with other peers. The IPSec security feature introduces a configurable idle timer to monitor SAs for activity, allowing SAs for idle peers to be deleted. The idle timers are configured either globally or on a crypto profile basis.
Prefragmentation for Cisco IPSec VPN SPAs
Note
When a packet is nearly the size of the maximum transmission unit (MTU) of the outbound link of the encrypting router and it is encapsulated with IPSec headers, the packet is likely to exceed the MTU of the outbound link. The packet causes packet fragmentation after encryption, which makes the decrypting router reassemble in the process path. Prefragmentation for Cisco IPSec VPN SPAs increases the decrypting router's performance by enabling it to operate in the high-performance CEF path instead of the process path.
This feature allows an encrypting router to predetermine the encapsulated packet size from information available in transform sets, which are configured as part of the IPSec SA. If it is predetermined that the packet exceeds the MTU of the output interface, the packet is fragmented before encryption. This function avoids process-level reassembly before decryption and helps improve decryption performance and overall IPSec traffic throughput.
Prefragmentation for the Cisco IPSec VPN SPA functionality depends on the service-ipsec interface from the crypto ipsec df-bit command configuration and the incoming packet "do not fragment" (DF) bit state (see Table 1).
Table 1 Pre-Fragmentation for Cisco IPSec VPN SPA Dependencies
Enabled
crypto ipsec df-bit copy
0
Fragmentation occurs before encryption.
Enabled
crypto ipsec df-bit copy
1
Packets are dropped.
Enabled
crypto ipsec df-bit clear
0
Fragmentation occurs before encryption.
Enabled
crypto ipsec df-bit clear
1
Packets are sent to egress interfaces (not fragmented before encryption).1
Enabled
crypto ipsec df-bit set
0
Fragmentation occurs before encryption.
Enabled
crypto ipsec df-bit set
1
Packets are dropped.
Disabled
crypto ipsec df-bit copy
0
Packets are sent to egress interfaces.1
Disabled
crypto ipsec df-bit copy
1
Packets are dropped.
Disabled
crypto ipsec df-bit clear
0
Packets are sent to egress interfaces.1
Disabled
crypto ipsec df-bit clear
1
Packets are sent to egress interfaces.1
Disabled
crypto ipsec df-bit set
0
Packets are sent to egress interfaces.1
Disabled
crypto ipsec df-bit set
1
Packets are dropped.
1 A packet that is sent to egress interfaces can get fragmented on an egress LC under the following conditions: Packet exceeds the MTU of the egress physical interface. The df-bit is not set on the outer IP header.
IPSec—SNMP Support
Note
The IPSec SNMP support feature allows you to specify the desired size of a tunnel history table by using the Cisco IOS XR CLI. The history table archives attribute and statistic information about the tunnel. A tunnel history table does not accompany every failure table, because every failure does not correspond to a tunnel. Thus, supported setup failures are recorded in the failure table, but an associated history table is not recorded because a tunnel was never set up.
Information About IPSec Networks and the Cisco IPSec VPN SPA Using Cisco IOS XR Software
To implement an IPSec network with a Cisco IPSec VPN SPA, you should understand the following concepts:
•
•
Cisco IPSec VPN SPA Overview
Cisco IOS XR Software supports security protocols such as Authentication Header (AH), Encapsulating Security Payload (ESP), and Internet Key Exchange (IKE). The resources consumed by these activities are significant and make it difficult to achieve line-rate transmission speeds over VPNs. Using the Cisco IPSec VPN SPA enables you to send all VPN traffic coming from or going to the Internet through the SPA hardware. The SPA supports all IPSec-related processing. Packets coming from the trusted LAN are encrypted and sent through the Internet. Packets that are received from the WAN routers pass through the Cisco IPSec VPN SPA for IPSec processing (for example, decryption and validation of the packet before the packet is sent onto the trusted LAN).
The following three SIP card types are supported:
•
•
•
Displaying the SPA Hardware Type
To verify that the SPA hardware type is installed, use the show diags command. In addition, you can use the show platform command to verify SPA hardware information.
For an example of the show diags command output for the Cisco XR 12000 Series Router IPSec VPN SPA, see the "Displaying the SPA Hardware Type: Example" section.
Information About Security for VPNs with IPSec
To implement security for VPNs with IPSec, you should understand the following concepts:
•
•
For information about configuring security for VPNs with IPSec, see How to Implement IPSec Network Security for VPNs.
IPSec Virtual Interfaces
IPSec virtual interfaces simplify configuration of IPSec for protection of remote links, support multicast, and simplify network management and load balancing.
Generic Routing Encapsulation (GRE) is a tunneling protocol that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to routers at remote points over an IP network.
When you configure an IPSec virtual interface, you must associate the service entity by using the service-location command. The association is done statically. The service-location command is mandatory. A virtual interface configuration is not fully verified until the service location is specified.
The following IPSec virtual interfaces are supported:
•
The tunnel endpoints are defined by the tunnel source command and tunnel destination command. The tunnel source can be shared between interfaces. Although the address is internal to the router, the address is used only as a tunnel source. Unlike other internal router IP addresses, the tunnel source is not used to serve routing protocols, or other applications that are terminated on the router. The sole purpose for a tunnel source is tunneling.
If a dynamic IPSec profile is attached to a static IPSec SVI, tunnel destination should not be configured and is negotiated when a new tunnel is created. In this case, it is possible that multiple IPSec tunnels can terminate on the same IPSec SVI and contain a different tunnel destination.
A virtual interface must be associated with an IPSec service SPA. The service-location command specifies both active and standby locations for the interface. All interfaces that share the same tunnel source and tunnel VRF (FVRF) must be associated to the same location. The only event in which virtual interfaces share the same source address, destination address, and FVRF, is when NAT traversal is in effect.
•
IPSec Load Balancing
Load balancing is the mechanism by which IPSec handling is distributed between Cisco IPSec VPN SPAs. You configure a traffic diversion policy to effect automatic switchover from one SPA to another, designating one SPA as the active (primary) SPA and another as the standby (secondary). If the active SPA goes down, the standby takes on the active role and traffic is diverted to it.
Another option is to configure auto-revert. Using this policy, when the previously active location again becomes functional, traffic is diverted back to the original, preferred active location. If you do not configure auto-revert, after a failure in location A, location B (originally configured as the standby) becomes active and location A becomes the standby.
Note
Reverse-route injection (RRI) is designed to simplify network design for Virtual Private Networks (VPNs) where redundancy or load balancing are required. For more information about RRI, see "IPSec—SNMP Support" section.
VRF-Aware IPSec
Each IPSec tunnel is associated with two VRF domains. The outer encapsulated domain belongs to one VRF domain, which is called the front door VRF (FVRF), while the inner, protected IP packet belongs to another domain called inside VRF (IVRF). Therefore, the local endpoint of the IPSec tunnel belongs to the FVRF, while the source and destination addresses of the inside packet belong to the IVRF.
Clear IP traffic is forwarded from an internal VRF to a remote site or host within the VRF over IPSec tunnels. The IVRF is determined on the SVI by using the vrf command. The encrypted packets going over the IPSec tunnel are forwarded over the FVRF, which is configured on one or more switched virtual interfaces (SVI) by using the tunnel vrf command. The tunnel source and destination are addresses of the FVRF. The encapsulated packets and the ACLs, which are configured in the IPSec profile, are all part of the IVRF.
MPLS Encapsulated Packets on Inbound Direction
The Multiprotocol Label Switching (MPLS) distribution protocol is a high-performance packet-forwarding technology that integrates the performance and traffic management capabilities of data link switching with the scalability, flexibility, and performance of network-layer routing.
The IPSec packet arrives from the Internet and is destined for the provider edge (PE) 2, which is also called the IPSec terminator. If the packet arrives at a PE1 outside of a VRF (for example, in the global table), the ingress PE1 pushes a label switched path (LSP) label onto the IPSec packet. The LSP packet is used to tunnel the IPSec packet to the egress PE, which is the IPSec terminator.
Reverse-Route Injection
Reverse-routes provide a scalable mechanism to dynamically learn and advertise the IP address and subnets that belong to a remote site that connects through an IPSec Virtual Private Network (VPN) tunnel. These static routes can then be redistributed into other dynamic routing protocols, so that they can be advertised to other parts of the network (usually done by redistributing the routes into dynamic routing protocols on the core side). Routes learned during the establishment of an IPSec tunnel are removed when the IPSec tunnel is torn down.
Reverse-route injection (RRI) refers to the ability to insert static routes automatically into the routing of networks and hosts protected by a remote tunnel endpoint. These protected hosts and networks are known as remote proxy identities.
RRI simplifies network design in cases where VPNs require load balancing or redundancy. RRI also integrates route availability to the IPSec state. Without RRI, routing decisions would be made independent from the IPSec peer.
A route to the secure subnet of a remote peer must exist. The route might be statically configured or derived through some form of end-to-end dynamic routing exchange.
Each route is created on the basis of the remote proxy network and mask, with the next hop to this network being the remote tunnel endpoint. By using the remote tunnel endpoint as the next hop, the traffic is forced through the crypto process to be encrypted.
After a static route is created on the VPN router, this information is propagated to upstream devices, allowing them to determine the appropriate VPN router in which to send returning traffic to maintain IPSec state flows.
Being able to determine the appropriate VPN router is particularly useful when multiple VPN routers are used to provide load balancing, automatic switchover, or when the remote VPN devices are not accessible through a default route.
Routes are created in either the global routing table or the appropriate VPN routing and forwarding (VRF) table. For information about configuring reverse-route injection, see Configuring Reverse-Route Injection in a Crypto Profile.
Information About Implementing IPSec in a Site-to-Site or Remote VPN Topology
The following topics describe the tasks required to enable IPSec on a VPN:
•
•
•
For examples, see Configuration Examples for Implementing IPSec in a Site-to-Site or Remote VPN Topology.
Restrictions to Implementing IPSec in a Site-to-Site or Remote VPN Topology
This functionality can only be implemented in a Cisco XR 12000 Series Router network, using the IPSec VPN SPA.
Configuration of IPSec in a Site-to-Site VPN Topology
Site-to-site VPNs are deployed in static configurations that change very infrequently. Both endpoints of the VPN are generally routers (or, occasionally, high-end security devices). IKE uses both phases of negotiation and the resulting connection typically has a maximum lifetime to prevent excessive protocol churn.
Site-to-site VPN deployment requires that you complete the following procedures:
1.
For detailed information, see the "Enabling or Disabling IKE" section on page 171 in the Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software module of Cisco IOS XR System Security Configuration Guide.
2.
For detailed information, see the "Configuring IKE Policies" section on page 172 in the Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software module of Cisco IOS XR System Security Configuration Guide.
3.
For detailed information, see "Defining Group Policy Information for Mode Configuration" section on page 174 of the Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software module of Cisco IOS XR System Security Configuration Guide.
4.
During the negotiation, the peers search for a transform set that is the same at both peers. When a matching transform set is found, IKE selects it and applies it to the protected traffic as part of the IPSec SAs for both peers.
For details, see Defining Transform Sets.
5.
A keyring is a repository of preshared keys and RSA public keys. The peer keys defined in the keyring are used by the ISAKMP profile to authenticate the remote side during IKE negotiation.
For details, see the "Configuring Crypto Keyrings" section on page 197 of the Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software module of Cisco IOS XR System Security Configuration Guide.
6.
For details, see Configuring Crypto Profiles.
If configured, the destination address from the ACL is added as a static route pointing to the SVI. While this command is optional in site-to-site configurations, it is on by default for remote access topologies. (See Configuring IPSec in a Remote-Access VPN Topology: Example.)
7.
The interface can be either of the following:
–
–
The service-ipsec interface supports only tunnel mode, while the service-gre interface supports only transport mode, because the generic routing encapsulation (GRE) already provides tunneling. Each of these modes is configured using the transform-set command referenced in Step 6. "Configure the IPSec profile.".
For details about configuring a tunnel source and destination, see the "Applying Crypto Profiles to tunnel-ipsec Interfaces" section.
Note
Multiple SVIs on the same SPA may be configured with the same tunnel source address, which is useful for conserving addresses.
8.
The crypto isakmp profile command defines an ISAKMP profile and audits IPSec user sessions. Peers are mapped to an ISAKMP profile when their identities are matched (Step 7.), as given in the ID payload of IKE. The ISAKMP profile successfully completes authentication of peers if the peer keys are defined in the keyring attached to this profile.
When the XR router is the IKE responder, this configuration line allows the router to determine the proper SVI for sending its encrypted traffic.
When the XR router is the IKE initiator, the correct SVI has already been chosen by doing a lookup in the forwarding table. The remote endpoint is then determined by the tunnel destination of that SVI.
For an example, see Configuring IPSec in a Site-to-Site VPN Topology: Example.
Site-to-Site Encrypted Generic Routing Encapsulation Tunnels
Generic routing encapsulation (GRE) is a tunneling protocol developed by Cisco Systems. This protocol supports:
•
•
For details, see Configuring Crypto Profiles.
Identity Verification
Preshared keys, which are insecure, provide no verification of the identity of the remote endpoint.To mitigate this risk, the Public Key Infrastructure (PKI) protocol provides the following options:
•
•
For information about Public Key Infrastructure commands, see the Public Key Infrastructure Commands on Cisco IOS XR Software module in Cisco IOS XR System Security Command Reference.
For information about the implementation of Certificate Authority Interoperability configurations, see the Implementing Certificate Authority Interoperability on Cisco IOS XR Software module in Cisco IOS XR System Security Configuration Guide.
Encryption of Public Key Infrastructure with RSA
PKI with RSA encryption consists of the following configuration tasks:
1.
For more information about the hostname command, see Cisco IOS XR System Management Command Reference. For more information about the domain name command, see Cisco IOS XR IP Addresses and Services Command Reference.
2.
3.
This configuration takes place under the keyring, in other words, the key is manually exchanged similar to a pre-shared key. See "Manually Configuring RSA Keys" section on page 184 of the Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software module of Cisco IOS XR System Security Configuration Guide.
4.
5.
The RSA key authentication must match the identity that was specified in the crypto keyring command. See again Configuring Crypto Keyrings, page 197.
For configuration details, see the Implementing Certification Authority Interoperability on Cisco IOS XR Software module in the Cisco IOS XR System Security Configuration Guide
Certificate Configuration
For a certification authority (CA), you do not need to configure keys between all the encrypting routers. Instead, enroll each participating router with the CA and request a certificate for the router.
The certificate enrollment, which takes place before establishment of a tunnel, specifies either the URL of the CA or a manual cut-and-paste of the enrollment (terminal).
Certificate configuration consists of the following tasks:
1.
2.
The router must authenticate the CA by obtaining the self-signed certificate of the CA, which also contains its public key.
3.
–
–
4.
Note
5.
For details, see the Implementing Certification Authority Interoperability on Cisco IOS XR Software module in the Cisco IOS XR System Security Configuration Guide.
Configuration of IPSec in a Remote-Access VPN Topology
Configuration of IPSec for a remote-access topology differs from configuration for a site-to-site topology in the following ways:
•
•
•
•
Use of the following provides addresses for remote clients:
•
•
•
The SVI can terminate many site-to-site tunnels, which is useful for remote access configurations where all remote devices may share the same parameters.
Remote access uses the following procedure:
1.
AAA is required to be configured for users and/or groups. The keys are stored in AAA and referenced from the ISAKMP profile, in Step 4.
See the Configuring AAA Services on Cisco IOS XR Software module of Cisco IOS XR System Security Configuration Guide.
2.
See the example under Configuring IPSec in a Remote-Access VPN Topology: Example.
3.
For details, see Defining Group Policy Information for Mode Configuration, page 174 of the module Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software in Cisco IOS XR System Security Configuration Guide.
4.
For details, see Configuring IKE Policies, page 172 of the module Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software in Cisco IOS XR System Security Configuration Guide.
5.
For details, see Configuring IKE Policies, page 172.
6.
For details, see Configuring IKE Policies, page 172, Limiting an IKE Peer to Use a Specific Policy Set, page 178, and Configuring Static IPSec Virtual Interfaces.
See also Configuring IPSec in a Remote-Access VPN Topology: Example.
Information About Object Tracking in IPSec
The purpose of object tracking in Cisco IOS XR and in IPSec is to prevent the dropping of packets routed to destinations that have become unreachable due to network changes (also called "blackholing").
This is achieved by tracking the state of the router interfaces or by tracking the prefixes used by the routing protocols. Any change to the state changes the value of the tracked object, as configured by the user, shutting previously defined service-IPSec interfaces. This causes the IPSec tunnel to be torn down and stops the flow of traffic to the black hole.
Cisco IOS XR currently supports tracking of the following:
•
•
•
•
The Cisco IOS XR System Management Configuration Guide provides detailed configuration information about each type of object tracking, while the "Configuration Examples for the Use of Object Tracking in IPSec" section of this chapter illustrates how to use these same object tracking procedures in the context of IPSec.
How to Implement General IPSec Configurations for IPSec Networks
This section contains the following implementation procedures:
•
•
•
•
•
•
•
•
•
•
•
•
•
Setting Global Lifetimes for IPSec Security Associations
This task sets global lifetimes for IPSec security associations.
SUMMARY STEPS
1.
2.
3.
or
commit4.
DETAILED STEPS
Creating Crypto Access Lists
This task creates a crypto access list.
SUMMARY STEPS
1.
2.
3.
or
[sequence-number] permit {tcp | udp}{ any | host source-ip | source-ip/prefix | source-ip source-wildcard}[eq port-number | gt port-number | lt port-number | neq port-number | range port-number port-number] {any | host destination-ip | destination-ip/prefix | destination-ip destination-wildcard} [eq port-number| gt port-number | lt port-number | neq port-number | range port-number port-number]
4.
or
commitDETAILED STEPS
Step 1
configure
Example:RP/0/0/CPU0:router# configure
Enters global configuration mode.
Step 2
ipv4 access-list name
Example:RP/0/0/CPU0:router(config)# ipv4 access-list InternetFilter
RP/0/0/CPU0:router(config-ipv4-acl)#
Creates an access list named "InternetFilter" and enters IPv4 access list configuration mode.
Note
Step 3
[sequence-number] permit {ipv4 | ipv4-protocol-number} {any | host source-ip | source-ip/prefix | source-ip source-wildcard} {any | host destination-ip | destination-ip/prefix | destination-ip destination-wildcard}
or
[sequence-number] permit {tcp | udp}{any | host source-ip | source-ip/prefix | source-ip source-wildcard}[eq port-number | gt port-number | lt port-number | neq port-number | range port-number port-number] {any | host destination-ip | destination-ip/prefix | destination-ip destination-wildcard} [eq port-number| gt port-number | lt port-number | neq port-number | range port-number port-number]
Example:RP/0/0/CPU0:router(config-ipv4-acl)# 10 permit tcp 100.0.1.0 0.0.0.255 lt 15 30.0.0.0/16 range 2000 2050
Specifies conditions to determine which IP packets are protected.
•
•
•
Caution
Note
•
•
•
•
•
Step 4
end
or
commit
Example:RP/0/0/CPU0:router(config)# end
or
RP/0/0/CPU0:router(config)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
Defining Transform Sets
This task defines a transform set.
SUMMARY STEPS
1.
2.
transform-set submode transform protocol
transform-set submode mode {transport | tunnel}3.
or
commitDETAILED STEPS
Configuring Crypto Profiles
This task configures static or dynamic crypto profiles.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
or
commit17.
18.
DETAILED STEPS
Configuring the DF Bit for the Encapsulating Header in IPSec Tunnels
This task configures the DF bit for the encapsulating header in IPSec tunnels. The DF bit configuration is also specified for both service-ipsec and service-gre interfaces.
Note
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Configuring the IPSec Antireplay Window
This section describes the configuration of the IPSec antireplay window:
•
•
•
Restrictions to Configuring the IPSec Antireplay Window
This IPSec feature is supported only on the Cisco XR 12000 Series Router using the Cisco IPSec VPN SPA.
Configuring the IPSec Antireplay Window: Expanding and Disabling Globally
This task globally expands and disables the IPSec Antireplay Window globally.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
Disabling IPSec Replay Checking on a Crypto Profile
This task disables replay checking on a crypto profile.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
Configuring IPSec NAT Transparency
Network Address Translator (NAT) is automatically detected by the Cisco IPSec VPN SPA. If both VPN devices are NAT-transparency capable, NAT transparency is automatically detected and negotiated. No configuration steps are needed to enable IPSec NAT transparency.
Note
Disabling IPSec NAT Transparency
This task disables NAT transparency if you already know that your network uses IPSec-awareness NAT (spi-matching scheme).
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Configuring IPSec Security Association Idle Timers
To configure the IPSec Security Association Idle Timers feature, you must understand the following concepts and tasks:
•
•
•
•
•
Restrictions to Configuring IPSec SA Idle Timers
This feature is configurable only on the Cisco XR 12000 Series Router using the Cisco IPSec VPN SPA.
Lifetimes for IPSec Security Associations
Cisco IOS XR software currently allows the configuration of lifetimes for IPSec SAs. Lifetimes can be configured globally or for each crypto profile. Two lifetimes exist: a "timed" lifetime and a "traffic-volume" lifetime. A security association expires after the first of these lifetimes is reached.
IPSec Security Association Idle Timers
The IPSec SA idle timers are different from the global lifetimes for IPSec SAs. The expiration of the global lifetime is independent of peer activity. The IPSec SA idle timer allows SAs associated with inactive peers to be deleted before the global lifetime has expired.
If the IPSec SA idle timers are not configured, only the global lifetimes for IPSec SAs are applied. SAs are maintained until the global timers expire, regardless of peer activity.
Note
Configuring the IPSec SA Idle Timer Globally
This task configures IPSec security association (SA) idle timers globally.
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Configuring the IPSec SA Idle Timer for Each Crypto Profile
This task configures the IPSec SA idle timer for a specified crypto profile. The idle timer configuration is applied to all SAs under the specified crypto profile. If no idle time is specified under the profile and idle time is configured in global mode, the idle time of the global mode is applied.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
Disabling Prefragmentation for Cisco IPSec VPN SPAs
This section provides the following procedures to disable prefragmentation for Cisco IPSec VPN SPAs on the Cisco XR 12000 Series Router:
•
•
Note
Disabling Prefragmentation for service-ipsec Interfaces
This task disables prefragmentation for service-ipsec interfaces.
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Disabling Prefragmentation for service-gre Interfaces
The fragmentation for a service-gre interface is done based on the original IP packet size, which does not include the GRE overhead.
This task disables prefragmentation for service-gre interfaces.
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Configuring Reverse-Route Injection in a Crypto Profile
This task configures reverse-route injection in a crypto profile, allowing insertion of either static or dynamically learned routes to take routing precedence primarily in networks and hosts protected by a remote tunnel endpoint. The ability to use dynamically learned routes is, for example, key to effecting failover policy in load balancing.
Note
For information about reverse-route injection, see IPSec—SNMP Support.
Note
SUMMARY STEPS
1.
2.
3.
4.
or
commit5.
DETAILED STEPS
Configuring IPSec Failure History Table Size
This task changes the size of the failure history table.
Note
SUMMARY STEPS
1.
2.
DETAILED STEPS
How to Implement IPSec Network Security for Locally Sourced and Destined Traffic
Locally sourced and terminated traffic are evaluated against IPSec profiles that are attached to tunnel-ipsec interfaces or crypto transport.
Note
•
This section contains the following procedures:
•
•
•
About Use of the any Keyword in Crypto Access Lists
When you create crypto access lists, using the any keyword could cause problems. We discourage the use of the any keyword to specify source or destination addresses. The any keyword is relevant only to locally sourced or terminated traffic.
No concept of default access lists exists for IPSec.
The permit any any statement is strongly discouraged, because it causes all outbound traffic to be protected (and all protected traffic to be sent to the peer specified in the corresponding crypto profile entry) and requires protection for all inbound traffic. Then, all inbound packets that lack IPSec protection are silently dropped, including packets for routing protocols, NTP, echo, and echo response.
Be sure to define which packets to protect. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.
Applying Crypto Profiles to tunnel-ipsec Interfaces
This task applies a crypto IPsec profile to a tunnel-ipsec interface.
You must apply a crypto profile to each tunnel-ipsec interface through which IPSec traffic flows. Applying the crypto profile set to a tunnel-ipsec interface instructs the router to evaluate all the interface's traffic against the crypto profile set and to use the specified policy during connection or SA negotiation on behalf of traffic to be protected by crypto.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
or
commitDETAILED STEPS
Applying Crypto Profiles to Crypto Transport
This task applies a crypto profile to crypto transport.
You need to apply a crypto profile to transport mode to make the profile active. Applying the crypto profile set to transport instructs the router to evaluate all of the locally sourced traffic against the crypto profile set and use the specified policy during connection or SA negotiation on behalf of traffic to be protected by crypto.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
How to Implement IPSec Network Security for VPNs
To implent IPSec network security for VPNs, review the following information:
•
•
•
Restrictions to Implementing IPSec Network Security for VPNs
This feature is supported only on the Cisco XR 12000 Series Router using the Cisco IPSec VPN SPA.
Configuring IPSec Service Virtual Interfaces
These tasks configure IPSec virtual interfaces:
•
•
Configuring Static IPSec Virtual Interfaces
This task configures static IPSec service virtual interfaces (SVIs).
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
or
commit11.
DETAILED STEPS
Configuring IPSec-Protected GRE Virtual Interfaces
This task configures IPSec-protected GRE service virtual interfaces.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
or
commit11.
DETAILED STEPS
Configuring the Default Path Maximum Transmission Unit for the SA
This task configures the default path maximum transmission unit (MTU) for the SA.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
Configuration Examples for Implementing IPSec Network Security for Locally Sourced and Destined Traffic
This section provides the following configuration examples:
•
•
•
Configuring a Static Profile and Attaching to a tunnel-ipsec Interface: Example
The following example shows a minimal IPSec configuration where a static crypto profile is created and attached to a tunnel-ipsec interface.
An IPSec access list named sample1 defines which traffic to protect:
ipv4 access-list sample1 permit ip 10.0.0.0 0.0.0.255 10.2.2.0 0.0.0.255A transform set defines how the traffic is protected. In this example, transform set myset1 uses Data Encryption Standard (DES) encryption and Secure Hash Algorithm (SHA) for data packet authentication:
crypto ipsec transform-set myset1transform esp-des esp-shaAnother transform set example is myset2, which uses 3DES encryption and the Message Digest 5 (MD5) (Hashed Message Authentication Code [HMAC] variant) algorithm for data packet authentication:
crypto ipsec transform-set myset2transform esp-3des esp-md5-hmacA crypto profile named toRemoteSite is created and joins the IPSec access list and transform set:
crypto ipsec profile toRemoteSitematch sample1 transform-set myset1endThe toRemoteSite crypto profile is then applied to a tunnel-ipsec interface:
interface tunnel-ipsec0profile toRemoteSitetunnel source 10.0.0.2tunnel destination 10.0.0.5Configuring a Dynamic Profile and Attaching It to a tunnel-ipsec Interface: Example
The following example shows a minimal IPSec configuration where a dynamic crypto profile is created and attached to a tunnel-ipsec interface.
An IPSec access list named sample2 defines which traffic to protect:
ipv4 access-list sample2 permit ip 10.0.0.0 0.0.0.255 10.2.2.0 0.0.0.255A transform set defines how the traffic is protected. In this example, transform set myset2 uses DES encryption and SHA for data packet authentication:
crypto ipsec transform-set myset2transform esp-des esp-shaAnother transform set example is myset3, which uses 3DES encryption and MD5 (HMAC variant) for data packet authentication:
crypto ipsec transform-set myset3transform esp-3des esp-md5-hmacA dynamic crypto profile named toRemoteSite is created and joins the IPSec access list and transform set:
crypto ipsec profile toRemoteSitematch sample2 transform-set myset3set type dynamicendThe toRemoteSite profile is applied to a tunnel-ipsec interface:
interface tunnel-ipsec0profile toRemoteSitetunnel source 10.0.0.2The tunnel destination is not required when the profile is dynamic.
Configuring a Static Profile and Attaching to Transport: Example
The following example shows a minimal IPSec configuration in which a static profile is created and attached to a transport.
An IPSec access list named sample3 defines which traffic to protect:
ipv4 access-list sample3 permit ip 10.0.0.0 0.0.0.255 10.2.2.0 0.0.0.255A transform set defines how the traffic is protected. In this example, transform set myset1 uses DES encryption and SHA for data packet authentication:
crypto ipsec transform-set myset1transform esp-des esp-shaAnother transform set example is myset2, which uses 3DES encryption and the MD5 (HMAC variant) for data packet authentication:
crypto ipsec transform-set myset2transform esp-3des esp-md5-hmacA crypto profile named toRemoteSite is created and joins the IPSec access list and transform set:
crypto ipsec profile toRemoteSitematch sample3 transform-set myset2endThe toRemoteSite profile is applied to a transport:
crypto ipsec transportprofile toRemoteSiteendConfiguration Examples for an IPSec Network with a Cisco IPSec VPN SPA
This section provides the following configuration examples:
•
•
•
Displaying the SPA Hardware Type: Example
The following sample output is from the show diags command on the Cisco XR 12000 Series Router IPSec VPN SPA installed in slot 1:
RP/0/0/CPU0:router# show diagsSLOT 1 (RP/LC 1): Cisco 12000 Series SPA Interface Processor-600MAIN: type 117, 800-26102-01 rev B0 dev 0HW config: 0x01 SW key: 00-00-00PCA: 73-9863-02 rev B0 ver 8HW version 1.0 S/N SAD092306A5MBUS: Embedded AgentTest hist: 0x00 RMA#: 00-00-00 RMA hist: 0x00DIAG: Test count: 0x00000000 Test results: 0x00000000FRU: Linecard/Module: 12000-SIP-600Route Memory: MEM-LC5-1024=Packet Memory: MEM-LC5-PKT-512=L3 Engine: 5 - ISE OC192 (10 Gbps)MBUS Agent Software version 2.49 (RAM) (ROM version is 3.6)Using CAN Bus AROM Monitor version 17.1Fabric Downloader version used 3.9 (ROM version is 3.9)Primary clock is CSC1Board State is IOS-XR RUNInsertion time: Thu Jun 29 23:23:48 2006 (1w0d ago)DRAM size: 1073741824 bytesFrFab SDRAM size: 268435456 bytesToFab SDRAM size: 268435456 bytes0 crashes since restart/fault forgiveSPA Information:subslot 0/1/0: SPA-IPSEC-2G (0x3d7), status is ok
Table 2 lists the hardware description that appears in the show diags command output for a Cisco XR 12000 Series Router IPSec VPN SPA.
Table 2 SPA Hardware Description in show diag Command
SPA-IPSEC-2G
SPA-IPSEC-2G (0x3d7)
For more information about the show diag command, see Cisco IOS XR Interface and Hardware Component Command Reference. For information about the related show platform command, see Cisco IOS XR System Management Command Reference.
Configuring IPSec for a VRF-Aware service-ipsec Interface: Example
The following example shows an IPSec configuration of two VRF-aware service-ipsec interfaces with a crypto IPSec profile that uses RRI.
The interface service-ipsec command is set to 1 and is part of the customer_1 VRF. FVRF is the global VRF (default). Clear traffic is coming from customer_1 VRF with a source IP address 100.0.1.0/24 and is destined to 30.0.1.0/24, which is encrypted and sent over to the global VRF. Respectively, the encrypted traffic from 30.0.1.0/24 is destined to 100.0.1.0/24 and is encrypted on the remote site or host and decrypted on the router.
Configuring VRF
vrf customer_1address-family ipv4 unicastimport route-target100:1000!export route-target100:1000!!!Configuring ACL That Is Used by the IPSec Profile
ipv4 access-list acl110 permit ipv4 100.0.1.0 0.0.0.255 30.0.1.0 0.0.0.255!Configuring the Service-ipsec Interface
interface service-ipsec1vrf customer_1 <------------- IVRFipv4 address 40.40.41.41 255.255.255.0profile prof1 <--------- the ipsec profiletunnel source 4.0.1.1tunnel destination 5.0.1.1service-location preferred-active 0/1/1 preferred-standby 0/2/0 <----------- The IPSec SPA is located on the 0/1/1 and the standby SPA on 0/2/0!Configuring IKE
crypto isakmpcrypto isakmp policy 1authentication pre-shareencryption 3deslifetime 86400!crypto keyring kr1 vrf defaultpre-shared-key address 5.0.1.1 255.255.255.255 key aBrAkAdAbRacrypto isakmp profile a_profkeyring kr1match identity address 5.0.1.1/32 vrf defaultset interface service-ipsec1!Configuring IPSec
The following example shows that the transform-set is set to esp-256-aes:
crypto ipsec transform-set ts1transform esp-256-aes!The following example shows that the IPSec profile uses acl1 as the traffic proxy and transform-set is ts1. In addition, RRI is configured.
crypto ipsec profile prof1set pfs group1set type staticmatch acl1 transform-set ts1reverse-route!The following example shows that the IPSec SA is created from the show crypto ipsec summary command and show crypto ipsec sa command:
RP/0/0/CPU0:router# show crypto ipsec summary# * Attached to a transform indicates a bundle# Active IPSec Sessions: 1SA Local Peer Remote Peer FVRF Profile Transform Lifetime-------------------------------------------------------------------------------502 4.0.1.1 5.0.1.1 default prof1 esp-256-aes 3600/4194303RP/0/0/CPU0:router# show crypto ipsec saSA id: 502Node id: 0/1/1 0/2/0SA Type: ISAKMPinterface: service-ipsec1profile : prof1local ident (addr/mask/prot/port) : (100.0.1.0/255.255.255.0/0/0)remote ident (addr/mask/prot/port) : (30.0.1.0/255.255.255.0/0/0)local crypto endpt: 4.0.1.1, remote crypto endpt: 5.0.1.1, vrf default#pkts tx :0 #pkts rx :0#bytes tx :0 #bytes rx :0#pkts encrypt :0 #pkts decrypt :0#pkts digest :0 #pkts verify :0#pkts encrpt fail:0 #pkts decrpt fail:0#pkts digest fail:0 #pkts verify fail:0#pkts replay fail:0#pkts tx errors :0 #pkts rx errors :0outbound esp sas:spi: 0x3482d5c8(880989640)transform: esp-256-aesin use settings = Tunnelsa agreed lifetime: 3600s, 4194303kbsa timing: remaining key lifetime (sec/kb): (3525/4194303)sa DPD disabledsa idle timeout: disable, 0ssa anti-replay (HW accel): enable, window 64inbound esp sas:spi: 0x3c9869ee(1016621550)transform: esp-256-aesin use settings = Tunnelsa agreed lifetime: 3600s, 4194303kbsa timing: remaining key lifetime (sec/kb): (3525/4194303)sa DPD disabledsa idle timeout: disable, 0ssa anti-replay (HW accel): enable, window 64The following example shows that RRI was configured so the proxy is added to the routing table of the VRF:
RP/0/0/CPU0:router# show route vrf customer_1Codes: C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGPi - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, su - IS-IS summary null, * - candidate defaultU - per-user static route, o - ODR, L - localGateway of last resort is not setS 30.0.1.0/24 is directly connected, 00:02:09, service-ipsec1C 40.40.41.0/24 is directly connected, 00:02:09, service-ipsec1L 40.40.41.41/32 is directly connected, 00:02:09, service-ipsec1C 100.100.100.0/24 is directly connected, 00:01:26, GigabitEthernet0/0/0/3L 100.100.100.1/32 is directly connected, 00:01:26, GigabitEthernet0/0/0/3The following example shows that the interface service-ipsec command is set to 1 and is part of the customer_1 VRF:
RP/0/0/CPU0:router# show crypto ipsec interface service-ipsec 1--------------- IPSec interface ----------------Interface service-ipsec1, mode Tunnel, intf_handle 0x5000180Locations 0/1/1 0/2/0, VRF customer_1 (60000002)Number of profiles 1, number of flows 1Tunnel: source 4.0.1.1, destination 5.0.1.1, tunnel VRF defaultDF-bit: copy, pre-fragmentation enabledefault pmtu: 92161 connected flows:502Configuring a service-gre Interface: Example
The following example shows a basic configuration of a service-gre interface and an IPSec SA that is created on the interface.
Configuring the Transform-set to Use Transport Mode
crypto ipsec transform-set tsfm2transform esp-3des esp-md5-hmacmode transport!Configuring the IPSec Profile to Use the Set Transform-set Format
crypto ipsec profile greset transform-set tsfm2!Configuring the Service-gre Interface
interface service-gre1ipv4 address 11.2.6.6 255.255.255.0profile gretunnel source 50.50.50.2tunnel destination 40.40.40.2service-location preferred-active 0/1/1!The following example shows the sample output from the show crypto ipsec summary command:
RP/0/0/CPU0:router# show crypto ipsec summary# * Attached to a transform indicates a bundle# Active IPSec Sessions: 2SA Local Peer Remote Peer FVRF Profile Transform Lifetime-------------------------------------------------------------------------------503 50.50.50.2 40.40.40.2 default gre esp-3des esp 120/4194303The following example shows that the service-gre interface is set to 1 with a profile gre:
RP/0/0/CPU0:router# show crypto ipsec sa 503SA id: 503Node id: 0/1/1SA Type: ISAKMPinterface: service-gre1profile : grelocal ident (addr/mask/prot/port) : (50.50.50.2/255.255.255.255/47/0)remote ident (addr/mask/prot/port) : (40.40.40.2/255.255.255.255/47/0)local crypto endpt: 50.50.50.2, remote crypto endpt: 40.40.40.2, vrf default#pkts tx :0 #pkts rx :0#bytes tx :0 #bytes rx :0#pkts encrypt :0 #pkts decrypt :0#pkts digest :0 #pkts verify :0#pkts encrpt fail:0 #pkts decrpt fail:0#pkts digest fail:0 #pkts verify fail:0#pkts replay fail:0#pkts tx errors :0 #pkts rx errors :0outbound esp sas:spi: 0x5aeffcbd(1525677245)transform: esp-3des esp-md5-hmacin use settings = Transportsa agreed lifetime: 120s, 4194303kbsa timing: remaining key lifetime (sec/kb): (108/4194303)sa DPD disabledsa idle timeout: disable, 0ssa anti-replay (HW accel): enable, window 64inbound esp sas:spi: 0x54373dd3(1412906451)transform: esp-3des esp-md5-hmacin use settings = Transportsa agreed lifetime: 120s, 4194303kbsa timing: remaining key lifetime (sec/kb): (108/4194303)sa DPD disabledsa idle timeout: disable, 0ssa anti-replay (HW accel): enable, window 64The following example shows that the interface service-gre command is set to 1:
RP/0/0/CPU0:router# show crypto ipsec interface service-gre 1--------------- IPSec interface ----------------Interface service-gre1, mode Transport, intf_handle 0x5000880Locations 0/1/1, VRF default (60000000)Number of profiles 1, number of flows 1Tunnel: source 50.50.50.2, destination 40.40.40.2, tunnel VRF defaultDF-bit: copy, pre-fragmentation enabledefault pmtu: 92161 connected flows:503Configuration Examples for the Use of Object Tracking in IPSec
The example scenarios in this section illustrate how you would use object tracking in IPSec, depending on whether you were tracking connectivity from site to site or in a remote network:
•
•
For a discussion of the use of object tracking in IPSec, see the "Information About Object Tracking in IPSec" section of this chapter. For general configuration procedures specific to each type of object tracking see Cisco IOS XR System Management Configuration Guide.
Tracking Connectivity From Site to Site, Based on a Physical or Logical Interface: Example
When the connectivity between the physical or logical interface between the IPSec router (the router starting or ending with the IPSec tunnel) and other routers goes down, traffic arriving from the IPSec tunnel is dropped, because there is suddenly no next hop.
To avoid this situation, configure tracking of the state of the interfaces and tear down the IPSec tunnel when the value of the interface state changes.
There are two options to dealing with this scenario.
Option 1: Track Physical Interfaces
In this example, traffic arrives from interface service-ipsec 1 and exits through interface GigabitEthernet 0/0/0/3. For configuration steps for this type of object tracking, see "Tracking the Line Protocol State of an Interface" in the Cisco IOS XR System Management Configuration Guide.
1.
track IPSec1type line-protocol stateinterface gigabitethernet0/0/0/32.
interface service-ipsec1ipv4 address 70.0.0.1 255.255.255.0profile vrf1_profile_ipsecline-protocol track ipsec1tunnel source 80.0.0.1tunnel destination 80.0.0.2service-location preferred-active 0/0/13.
RP/0/0/CPU0:Router# show trackTrack IPSec1Interface GigabitEthernet0_0_0_3 line-protocolLine protocol is UP1 change, last change 10:37:32 UTC Thu Sep 20 2007Tracked by:service-ipsec1Option 2: Track a List of Logical Interfaces
Traffic is arriving from interface service-ipsec 1 and should exit through interface GigabitEthernet 0/0/0/3 and interface ATM 0/2/0/0.1. This configuration example uses a Boolean OR expression to indicate that the IPSec tunnel should be torn down as soon as both interfaces go down. For configuration steps for this type of object tracking, see "Building a Track Based on a List of Objects" in the Cisco IOS XR System Management Configuration Guide.
track list1type list boolean orobject IPSec1object IPSec2!!track IPSec1type line-protocol stateinterface GigabitEthernet0/0/0/3!!track IPSec2type line-protocol stateinterface ATM0/2/0.1!interface service-ipsec1 << Associates the track with an IPSec interface.ipv4 address 70.0.0.1 255.255.255.0profile vrf1_profile_ipsecline-protocol track list1tunnel source 80.0.0.1tunnel destination 80.0.0.2service-location preferred-active 0/0/1Tracking Connectivity on a Remote Site, Using Routing Protocol Prefixes: Example
When a host or a network goes down on a remote site, routing protocols notify the router and the routing table is updated accordingly. You can track a route by configuring the routing process to notify the tracking process when the route state changes due to a routing update.
Option 1: Track the Routing Prefix in the Routing Table
In this example, traffic arriving from interface service-ipsec1 has its destination in network 7.0.0.0/24. We want to track when the state of the routing protocol prefix changes in the routing table. For configuration steps for this type of object tracking, see "Tracking IP Route Reachability" in the Cisco IOS XR System Management Configuration Guide.
track PREFIX1type route reachabilityroute ipv4 7.0.0.0/24!interface service-ipsec1vrf 1ipv4 address 70.0.0.2 255.255.255.0profile vrf_1_ipsecline-protocol track PREFIX1tunnel source 80.0.0.2tunnel destination 80.0.0.1service-location preferred-active 0/2/0Option 2: Track a List of Objects
In this example, traffic arriving from interface service-ipsec 1 exits through interface GigabitEthernet 0/0/0/3 and interface ATM 0/2/0/0.1. The destination of the traffic is at network 7.0.0.0/24.
We want to stop the flow of traffic if either one of the interfaces or the remote network goes down. To do this, we use a Boolean AND expression. For configuration steps for this type of object tracking, see "Building a Track Based on a List of Interfaces" in the Cisco IOS XR System Management Configuration Guide.
track LIST2type list boolean andobject IPSec1object IPsec2object PREFIX1!track IPSec1type line-protocol stateinterface GigabitEthernet0/0/0/3!track IPSec2type line-protocol stateinterface ATM0/2/0.1!track PREFIX1type route reachabilityroute ipv4 7.0.0.0/24!interface service-ipsec1vrf 1ipv4 address 70.0.0.2 255.255.255.0profile vrf_1_ipsecline-protocol track LIST2tunnel source 80.0.0.2tunnel destination 80.0.0.1service-location preferred-active 0/2/0Configuration Examples for Implementing IPSec in a Site-to-Site or Remote VPN Topology
This section contains the following sections:
•
•
For related information, see Information About Implementing IPSec in a Site-to-Site or Remote VPN Topology.
Configuring IPSec in a Site-to-Site VPN Topology: Example
To configure a site-to-site VPN, complete the following tasks. For details about each task example, follow the links to the associated configuration procedures.
1.
RP/0/0/CPU0:Router(config)# crypto isakmpRP/0/0/CPU0:Router(config)# commit2.
SHA-1 specifies the has algorithm. The other supported algorithm is MD-5.
RP/0/0/CPU0:Router(config)# crypto isakmp policy 1RP/0/0/CPU0:Router(config-isakmp)# description PSK_SHA_AESRP/0/0/CPU0:Router(config-isakmp)# authentication pre-shareRP/0/0/CPU0:Router(config-isakmp)# hash shaRP/0/0/CPU0:Router(config-isakmp)# group 2RP/0/0/CPU0:Router(config-isakmp)# encryption aesRP/0/0/CPU0:Router(config-isakmp)# exitRP/0/0/CPU0:Router(config)# commit
Note
3.
This example configures an ACL to permit communication between subnets 192.102.1.0 and 192.101.1.0. These are the subnet addresses on for both routers on a private network.
RP/0/0/CPU0:Router(config)# ipv4 access-list crypto-1(config-ipv4-acl)# permit ipv4 192.102.1.0 0.0.0.255 192.101.1.0 0.0.0.255
Note
4.
During the negotiation, the peers search for a transform set that is the same at both peers. When a matching transform set is found, IKE selects it and applies it to the protected traffic as part of the IPSec SAs for both peers.
RP/0/0/CPU0:Router(config)# crypto IPSec transform-set transform-1The following command specifies the mode. Supported modes are tunnel (default) and transport.
RP/0/0/CPU0:Router(config-transform-set transform-1)# mode tunnelThe following command defines the encryption and mac algorithms to use to protect traffic. In this example, Advanced Encryption Standard (AES) cipher (128 bits) algorithm was used.
RP/0/0/CPU0:Router(config-transform-set transform-1)# transform esp-aes esp-sha-hmacOther supported encryption and mac algorithms consist of the following:
–
–
–
–
–
–
–
–
–
ESP encapsulation normally uses both an encryption and hash algorithm. Because AH is not encrypted, it uses only a hash algorithm.
5.
A keyring is a repository of preshared keys and RSA public keys. The peer keys defined in the keyring are used by the ISAKMP profile to authenticate the remote side during IKE negotiation.
This configuration also allows the user to specify the fVRF referenced by the tunnel for various endpoints.
RP/0/0/CPU0:Router(config)# crypto keyring keyring-1 vrf defaultRP/0/0/CPU0:Router(config-keyring)# pre-shared-key address 201.201.201.1 255.255.255.255 key ciscoThe following command specifies the pre-shared key that is associated with the remote endpoint of the tunnel (IPSec tunnel IP address and mask). If the remote endpoint of the tunnel resides in a VRF other than the global table, it can be specified on this line.
RP/0/0/CPU0:Router(config-keyring)# commit6.
The following commands define the cryptographic behavior of the IPSec transport and IPSec-enabled interfaces.
RP/0/0/CPU0:Router(config)# crypto IPSec profile profile-1Th e following command defines the DH group to use when renegotiating IPSec SAs. In this case, the perfect forward secrecy (PFS) setting is for IKE to handle group 5 (1536-bit Diffie-Hellman prime modulus group) negotiation.RP/0/0/CPU0:Router(config-profile-1)# set pfs group5The following command defines which traffic (passing through ACL crypto-1) to encrypt and how to encrypt it (through transform set transform-1). It also defines which set of parameters to negotiate (transform-set) during IKE Phase 2.
RP/0/0/CPU0:Router(config-profile-1)# match crypto-1 transform-set transform-1
Note
For details, see Configuring Crypto Profiles.
If configured, the destination address from the ACL is added as a static route pointing to the SVI. While this command is optional in site-to-site configurations, it is on by default for remote access topologies. (See Configuring IPSec in a Remote-Access VPN Topology: Example.)
RP/0/0/CPU0:Router(config-profile-1)# reverse-route distance 255RP/0/0/CPU0:Router(config-profile-1)# commitFor details, see the "Configuring Reverse-Route Injection in a Crypto Profile" section.
7.
The interface can be either of the following:
–
–
The service-ipsec interface supports only tunnel mode, while the service-gre interface supports only transport mode, because the generic routing encapulation (GRE) already provides tunneling. Each of these modes is configured using the transform-set command referenced in Step 6. "Configure the IPSec profile.".
This example uses service-ipsec:
RP/0/0/CPU0:Router(config)# interface service-ipsec1RP/0/0/CPU0:Router(config-if)# ipv4 address 202.202.202.1 255.255.255.252Normally, you set the IPv4 address to be unnumbered, because the SVI itself is rarely a traffic destination. If absolutely needed for management or application purposes, the IP address must not have a /32 mask.
The following command specifies the IPSec profile configured in Step 6. "Configure the IPSec profile.".
RP/0/0/CPU0:Router(config-if)# profile profile-1The tunnel destination in the command below is the remote IPSec tunnel end point IP address:
RP/0/0/CPU0:Router(config-if)# tunnel source 201.201.201.2RP/0/0/CPU0:Router(config-if)# tunnel destination 201.201.201.1RP/0/0/CPU0:Router(config-profile-1)# commitThe following command provides the physical location (rack/slot/module) of the IPSec where this SVI should reside.
RP/0/0/CPU0:Router(config-if)# service-location preferred-active 0/2/1If the SVI has a standby SPA, it would also be configured with the preferred-standby keyword:
RP/0/0/CPU0:Router(config-if)# service-location preferred-active 0/2/1 preferred-standby 0/3/1RP/0/0/CPU0:Router(config-if)# commit
Note
Multiple SVIs on the same SPA may be configured with the same tunnel source address, which is useful for conserving addresses. For example:
interface service-ipsec1tunnel source 1.1.1.1tunnel destination 2.2.2.2interface service-ipsec2tunnel source 1.1.1.1tunnel destination 3.3.3.38.
The crypto isakmp profile command defines an ISAKMP profile and audits IPSec user sessions. Peers are mapped to an ISAKMP profile when their identities are matched (Step 7.), as given in the ID payload of IKE. The ISAKMP profile successfully completes authentication of peers if the peer keys are defined in the keyring attached to this profile.
The following command specifies the keyring defined in Step 5. Configure crypto keyring.
RP/0/0/CPU0:Router(config)# crypto isakmp profile isakmp_profile-1RP/0/0/CPU0:Router(config-isa-prof)# keyring keyring-1The following command defines the remote endpoint of the tunnel. This address and VRF should match an entry in the keyring specified in Step 5. Configure crypto keyring.
RP/0/0/CPU0:Router(config-isa-prof)# match identity address 201.201.201.1/32 vrf defaultThe following command determines the SVI to use for encryption/decryption when a matching peer is found:
RP/0/0/CPU0:Router(config-isa-prof-match)# set interface service-IPSec1RP/0/0/CPU0:Router(config-isa-prof-match)# commitWhen the XR router is the IKE responder, this configuration line allows the router to determine the proper SVI for sending its encrypted traffic.
When the XR router is the IKE initiator, the correct SVI has already been chosen by doing a lookup in the forwarding table. The remote endpoint is then determined by the tunnel destination of that SVI.
Configuring IPSec in a Remote-Access VPN Topology: Example
The SVI can terminate many site-to-site tunnels, which is useful for remote access configurations where all remote devices may share the same parameters.
Configuration of IPSec for a remote-access topology differs from configuration for a site-to-site topology in the following ways:
•
•
•
•
You can provide addresses for remote clients by using one of the following methods:
•
•
•
Configuring Addresses for Remote Clients, Using a Local Pool
The following example illustrates configuration of a local pool.
1.
AAA is required to be configured for users and/or groups. The keys are stored in AAA and referenced from the ISAKMP profile, in Step 4.
RP/0/0/CPU0:Router# aaa authorization network net23 localRP/0/0/CPU0:Router# aaa authentication login net23 local2.
RP/0/0/CPU0:Router# Local pool ipv4 pool-101 210.210.0.1 210.210.0.2543.
RP/0/0/CPU0:Router# crypto isakmp client configuration group group-1RP/0/0/CPU0:Router(config-isa-client)# key poolkeyRP/0/0/CPU0:Router(config-isa-client)# pool pool-1014.
crypto isakmp profile ra-1client authentication list foomatch identity group group-1set interface service-ipsec1!!isakmp authorization list author2!5.
RP/0/0/CPU0:Router# crypto ipsec profile ra-1 set type dynamicRP/0/0/CPU0:Router(config-profile-1)# match acl transform-set transform-set-nameRP/0/0/CPU0:Router(config-profile-1)# reverse-route6.
RP/0/0/CPU0:IOX2(config)# crypto isakmp policy 1RP/0/0/CPU0:IOX2(config-isakmp)#encryption 3desRP/0/0/CPU0:IOX2(config-isakmp)#group 2RP/0/0/CPU0:IOX2(config-isakmp)#exitRP/0/0/CPU0:IOX2(config)#RP/0/0/CPU0:IOX2(config)# crypto isakmp policy 2RP/0/0/CPU0:IOX2(config-isakmp)# encryption desRP/0/0/CPU0:IOX2(config-isakmp)# group 2RP/0/0/CPU0:IOX2(config-isakmp)# authentication pre-shareRP/0/0/CPU0:IOX2(config-isakmp)# exitRP/0/0/CPU0:IOX2(config)#RP/0/0/CPU0:IOX2(config)# crypto isakmp policy 3RP/0/0/CPU0:IOX2(config-isakmp)# authentication pre-shareRP/0/0/CPU0:IOX2(config-isakmp)# authentication rsa-sigRP/0/0/CPU0:IOX2(config-isakmp)# encryption desRP/0/0/CPU0:IOX2(config-isakmp)# exitRP/0/0/CPU0:IOX2(config)#RP/0/0/CPU0:IOX2(config)# crypto isakmp policy-set pol-set1RP/0/0/CPU0:IOX2(config-isakmp-pol-set)# policy 2 3RP/0/0/CPU0:IOX2(config-isakmp-pol-set)# match identity local-address 1.1.1.1RP/0/0/CPU0:IOX2(config-isakmp-pol-set)# exitRP/0/0/CPU0:IOX2(config)#RP/0/0/CPU0:IOX2(config)#interface service-ipsec 1RP/0/0/CPU0:IOX2(config-if)# ipv4 address 20.1.1.1 255.255.255.0RP/0/0/CPU0:IOX2(config-if)# tunnel source 1.1.1.1RP/0/0/CPU0:IOX2(config-if)# profile prof1RP/0/0/CPU0:IOX2(config-if)# service-location preferred-active 0/1/0RP/0/0/CPU0:IOX2(config-if)#RP/0/0/CPU0:IOX2(config-if)# commitAdditional References
The following sections provide references related to implementing IPSec network security.
Related Documents
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
—
To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
Technical Assistance
Feedback