IPSec VPN Design [Electronic resources] نسخه متنی

The Network-Based IPSec Solution: IOS Features

You have seen conceptually how a network-based IPSec VPN solution enables service providers to expand their VPN portfolio with secure off-net remote access and remote site-to-site services. This section focuses on understanding IOS features that are key to implementing this solution.

The following three key features will be discussed:

Virtual Routing and Forwarding (VRF) tables

Crypto keyrings

ISAKMP profiles

The Virtual Routing and Forwarding Table

The notion of a VRF table was defined in RFC 2547 for MPLS VPNs. As the name suggests, a VRF is a unique routing and forwarding table per VPN. A given PE router may be connected to sites from different VPNs and hence may have multiple VRFs. To provide per-VPN routing segregation and avoid accidentally forwarding packets from one VPN to another, VRFs are kept on the PE routers.

A CE connected to a PE is associated with a VPN by explicit configuration of the VRF on the PE interface connecting the CE. The association between a given VRF and its attached set of interfaces or subinterfaces is determined by explicit configuration.

When a packet arrives from a CE, the routing or forwarding lookup for the destination is performed in the associated VRF table ensuring packets are only forwarded to destinations in the VRF. The VRF itself is populated by learning IPv4 routes from the CE by typical routing protocols such as OSPF, eBGP, static, RIPv2, and EIGRP. The PE advertises the routes learned from the CE to all other PEs via multiprotocol extensions to BGP (MP-BGP). The routes advertised by the PE via MP-BGP are known as VPNv4 routes. A couple of key attributes that are tagged to the VPNv4 routes in MP-BGP are the route target (RT) and the route distinguisher (RD).

The RD enables overlapping address pools between VPNs or VRFs, whereas the RT determines the distribution of the routes into the remote PE's VRF. Both attributes are manually configured.

Crypto Keyrings

You learned in previous chapters that when you configure IPSec, you must configure the Internet Security Association and Key Management Protocol (ISAKMP) policies. If the authentication scheme used is a pre-shared key, then you have to configure the corresponding key for each IPSec endpoint. In the traditional IPSec model, all the IPSec terminations are for connectivity into a single IPSec VPN, whereas in the network-based IPSec model you need to terminate IPSec tunnels belonging to different VPNs on the same IPSec aggregator. This means you need a mechanism to demarcate the keys of different VPNs, which is exactly what crypto keyrings are about.

With crypto keyrings, each VPN has its own unique keyring. Example 9-1 shows crypto keyrings for two different VPNs. A crypto keyring is in use if it is attached to one or more ISAKMP profiles. A crypto keyring cannot be deleted while it is in use by one of the profiles.

Example 9-1. Crypto Keyring Configuration

crypto keyring vpn1                                                                   
description keys for vpn1
pre-shared-key address 9.1.1.145 key vpn1aes
crypto keyring vpn2                                                                   
description keys for vpn2
pre-shared-key address 9.1.1.149 key vpn2ikev2

If the VRF keyword is not specified in the crypto keyring command, the keyring is bound to the global VRF (global routing table). When a VRF keyword is used in the command, the keyring is associated with the front-door VRF (FVRF). Operation of Network-Based IPSec VPNs" section, later in this chapter.

Example 9-2. Crypto Keyring with FVRF Association

crypto keyring vpn1 vrf vpn1
description keys for vpn1
pre-shared-key address 9.1.1.145 key vpn1aes

ISAKMP Profiles

An ISAKMP profile can be viewed as a placeholder for holding phase 1 and phase 1.5 (x-auth/mode-cfg) configuration applicable to an aggregation of peers. The ISAKMP profile selected for a specific peer during Internet Key Exchange (IKE) negotiation can be identified by using one of the following:

Phase 1 IKE identity. The identities could be of type IP Address, FQDN, USER-FQDN, DN, and ID_KEY_ID.

Matching fields in the certificate forwarded by the peer during authentication.

Chapter 4, "IPSec Authentication and Authorization Models," ID_KEY_ID is the groupname for Cisco Unity clients. You can also see that in the case of remote access, you can configure all the AAA attributes within the ISAKMP profile, as shown in Example 9-3.

Example 9-3. ISAKMP Profile Configuration

crypto isakmp profile vpn1
vrf vpn1 description IVRF
keyring vpn1
 match identity address 9.1.1.145 255.255.255.255                                     
 match identity hostname domain vpn1.com                                              
accounting vpn
!
crypto isakmp profile vpn1-ra
vrf vpn1
  match identity user-fqdn user@vpn1.com                                              
  match identity group vpn1group                                                      
client authentication list vpn
isakmp authorization list vpn
client configuration address respond
accounting vpn

If the FVRF interface is in a VRF (not in global), then you must make sure there is a configuration that has the match identity statement with the VRF option, as shown in Example 9-4.

Example 9-4. Configuration Showing FVRF Association with Match Identity for Site-to-Site IPSec VPNs

crypto isakmp profile vpn2
vrf vpn2
keyring vpn2
 match identity address 9.1.1.149 255.255.255.255 vrf vpn2                            
accounting vpn

If the match criteria for the selection of the ISAKMP profile is based on certificates, then define the corresponding certificate map and assign that map to the match certificate, as shown in Example 9-5.

Example 9-5. Use of Certificates to Bind to a Profile and VRF

crypto isakmp profile vpn1-ra
vrf vpn1
  ca trustpoint vpn1                                                                  
  match certificate foo                                                               
  client configuration group vpn1group                                                
client authentication list vpn
isakmp authorization list vpn
client configuration address respond
accounting vpn
!
crypto ca certificate map foo
subject-name co ou=EAST
subject-name co o=VPN1

The main reason for using certificate matching is for cases in which the assignment of an ISAKMP profile cannot depend solely on the identity sent by the peer, and the intent is to be much more granular. For telecommuter clients wherein the group information cannot be retrieved from the certificate, you can assign a group to the clients.

Note

The ISAKMP profile must specify at least one "match" subcommand. An ISAKMP profile is regarded as incomplete without a match statement, and any traffic that matches a crypto map to which such a profile is attached will be dropped.

Any number of match statements can be specified in a single ISAKMP profile. The match statements should be used with care. An incoming identity will be matched in accordance with the following rules:

If the identity is of type IP address, the keyring and the match statement will be used. No two profiles should include the same match identity address and a common keyring. For identities of type ID_FQDN, or ID_USER_FQDN, the longest match will be chosen as the correct match.