Chapter 16. Migration Strategies
Introduction to Migrating to IKEv2 and FlexVPN
Over the last three to four years, many customers have realized the benefits of using IKEv2 and started to migrate to VPN architectures that make use of the benefits of IKEv2 and FlexVPN.
In many instances, customers will make the transition at the same time they upgrade hardware. The rationale is that older hardware does not support the IKEv2 protocol, so the interruption caused by upgrading hardware and migrating to IKEv2 can be combined, minimizing the impact.
VPN architectures already in service are a critical component of any ICT system, allowing remote workers to connect and/or interconnecting remote offices or data centers. Thought and care are required in the migration of VPN architectures. Downtime should be minimized to avoid disruption to services. Due-diligence is needed to ensure that the new service provides the same and/or additional functionality as the previous solution. Functionality could be as simple as providing IP connectivity to clients or as complex as requiring dual stack (IPv4 and IPv6) with multiple VPN gateways with clients tracking connectivity to each gateway.
No two VPN architectures will be the same, so there is no universal solution when migrating from using IKEv1 to IKEv2. For this reason the concepts described within this chapter are based on high-level concepts and should be taken as a guide.
Consideration when Migrating to IKEv2
If there are plans to migrate a current VPN solution to IKEv2 or to have a new deployment use IKEv2, the following aspects need to be addressed.
Hardware Limitations
Cisco ISR Generation 2 (G2) routers (800, 1900, 2900, 3900), ISR 4000 series (43XX and 44XX), CSR1000V, and ASR1000 hardware include the support for IKEv2 and FlexVPN.
ISR Generation 1 routers do not support IKEv2.
Note that all ISR G2, ISR 4000 series, and CSR1000V platforms support next-generation encryption (NGE) algorithms for both control plane (IKEv2) and data plane (IPsec). Only ASR octeon-based platforms (ASR1001-X, ASR1002-X, Embedded Services Processor-100, and Embedded Services Processor-200) support NGE for both control plane and data plane. Older ASR 1000 platforms (non-octeon) support NGE only in the control plane.
In many VPN deployments not all the hardware will have the ability to support IKEv2. In this case the hardware will need to be upgraded. This is a perfect time to have the hardware upgrade coincide with transitioning the configuration from IKEv1 to IKEv2, rather than installing IKEv2-compatible hardware and configuring only IKEv1.
Current VPN Technology
Different VPN technologies allow for different features to be used. FlexVPN can be used to replace any overlay VPN technology, including site-site, remote-access, hub-and-spoke, and spoke-spoke. Specific technologies such as EzVPN or DMVPN can be migrated to FlexVPN. Specific considerations depend on which specific features are used.
Most of the features that are available within EzVPN are also available in FlexVPN, except for:
Auto-update, an automated upgrading mechanism for software and firmware.
URL configuration, a mode-configuration attribute pushed from a URL from the VPN server to the EzVPN remote device. The URL contains the configuration information that the remote device has to download and apply to the running configuration.
If these features are required, please contact your Cisco account team for guidance.
Other features that are available with EzVPN, such as allocation of DHCP, WINS, and domain-name, are all available and configurable using FlexVPN server. If a username and password are used as the method of authentication, this can be achieved with EAP credentials locally on the FlexVPN client.
The following example illustrates configuring local EAP credentials.
Router(config)#crypto ikev2 profile default
Router(config-ikev2-profile)#authentication local eap ?
gtc eap method gtc credentials
md5 eap method md5 credentials
mschapv2 eap method mschapv2 credentials
<cr>
Router(config-ikev2-profile)#authentication local eap md5 ?
password EAP password
username EAP username
Routing Protocol Selection
If the current VPN architecture uses a routing protocol and the new VPN architecture is required to integrate into this existing routing architecture, care should be taken to ensure that disruption does not occur. In most instances separate autonomous systems are recommended for each group of VPN devices. So an IKEv1 deployment would use one autonomous system, and an IKEv2 deployment would use another. This allows a clean separation between separate instances. This isn’t a strict rule, but has resulted in smooth deployments.
IKEv2 allows routing to occur over the IKE exchange, which allows an IKEv1 deployment to run a routing protocol and the new IKEv2 deployment to use IKEv2 routing. The benefits of using IKEv2 routing is that it is not a chatty protocol; it can easily be added to existing implementations and redistributed into the current autonomous system, because IKEv2 routes are installed as static routes. IKEv2 routing also provides the ability to tag prefixes learned via IKEv2. This can be useful in cases where IKEv2 routing is redistributed into routing protocols that will then make decisions based on the tagged prefixes. Tagging can be very useful for deployments where routing loops can occur. Tagging prefixes and using route maps to limit the redistribution of certain prefixes can prevent routing loops and suboptimal routing.
The administrative distance on prefixes learnt over IKEv2 can be set locally, this allows for tunnel interfaces which use IKEv2 routing to have the local administrative distance set to a higher (less preferable) metric than the routing protocol currently being used over a tunnel interface using IKEv1. This allows for the Routing Information Base (RIB) to be populated with the prefixes; however, the active prefixes will be learnt using the routing protocol running over the IKEv1 tunnel and not the IKEv2 tunnel, until the IKEv1 tunnel can be shut down and the corresponding IKEv1 prefixes removed.
Restrictions When Running IKEv1 and IKEv2 Simultaneously
In Cisco IOS, an IKEv1 and an IKEv2 SA cannot exist within the same IPsec profile on a tunnel interface. A tunnel interface has to run either IKEv1 or IKEv2; it cannot run both simultaneously. However, separate tunnel interfaces can be configured from and to the same peers, with one being protected by IKEv1 and the other by IKEv2.
A crypto map can have entries that use both IKEv1 and IKEv2 profiles; however, these must be referenced in separate entries. If a crypto map entry is configured for both IKEv1 and IKEv2 profiles, the error in the following example will be seen.
Router(config-crypto-map)#set isakmp-profile IKEv1
Router(config-crypto-map)#set ikev2-profile IKEv2
% WARNING: Configuring Ikev2 profile will remove the Ikev1 profile configured
under this ipsec profile
Because of the conditions described previously, it is always advised to run separate tunnel interfaces, with each running either IKEv1 or IKEv2. This allows for simple configurations in which each tunnel interface clearly describes the IKE version, resulting in clarity when monitoring and troubleshooting.
Current Capacity
There is a fixed limit on the number of IPsec sessions that can coexist on any given hardware.
The following example illustrates the method to view the number of IPsec sessions that are available on a given platform. Care should be taken so that the capacity for IKE and IPsec sessions is not exceeded if multiple tunnels are needed for IPsec sessions to new devices.
Router#show crypto eli
Hardware Encryption : ACTIVE
Number of crypto engines = 3
CryptoEngine Onboard VPN details: state = Active
Capability : IPPCP, DES, 3DES, AES, GCM, GMAC, IPv6, GDOI, FAILCLOSE, HA
CryptoEngine Software Crypto Engine details: state = Active
Capability : IPPCP, DES, 3DES, AES, SEAL, GCM, GMAC, RSA, IPv6, GDOI,
FAILCLOSE, HA
IKE-Session : 2 active, 2100 max, 0 failed
IKEv2-Session : 2 active, 2100 max, 0 failed
DH : 1 active, 1050 max, 0 failed
IPSec-Session : 0 active, 1000 max, 0 failed
When migrating from IKEv1 to IKEv2, one needs to monitor the capacity on a device if multiple tunnels are to coexist on it to ensure that the onboard limits are not exceeded during the migration. This can be minimized by restricting small groups of peers to connect using both IKEv1 and IKEv2 simultaneously. Allowing large groups of devices to connect simultaneously has potential for exhausting all available crypto engine resources because the resources required per peer double. If, for example, the current load was 70% of the full capacity, it could be prudent to migrate only a limited number of hosts at any given time so that capacity does not exceed 80%.
Factors such as the number of tunnels that can be set up per second should be taken into account. If the new IKEv2 SAs will use a Diffie-Hellman group that differs from the current IKEv1 SAs, care should be taken to ensure that the additional cryptographic load can be managed. Please consult Cisco Technical Assistance Center (TAC) or Advanced Services (AS) should professional guidance be required.
IP Addresses
If using FlexVPN server and allocating clients’ IP addresses, one needs to investigate whether there is enough capacity to allocate IP addresses for the new IP address pool. This is usually the largest allocation of IP addresses for a new deployment.
Furthermore, if a new piece of hardware running IKEv2 is going to be integrated into the current architecture, is current capacity sufficient to add IP addresses for the physical and tunnel interfaces?
Software
In some instances, devices running older versions of IOS or IOS-XE software might not actually support IKEv2 or other newer features that are required. In this instance, software can be upgraded on these devices, and then new IKEv2 protected traffic can be tested.
Another approach is to perform the software upgrade first. Once stability has been confirmed, IKEv2 can be implemented. This minimizes the chances that any degradation of performance caused by the upgraded software would be blamed on the IKEv2 component.
Amending the VPN Gateway
When making any changes on a live system, take care to ensure that disruptions to service do not occur. Adding additional tunnel interfaces correctly should not cause any disruption to traffic; however, care should be taken that the configuration is correct. For this reason, it is advisable to recreate the procedure in a lab first or consult with Cisco Advanced Services.
The initial contact feature, where any new session will tear down previous sessions with the same IKE identity, is only active with the same protocols. So if a peer had both IKEv1 and IKEv2 sessions with another system, these could coexist without initial contact coming into force.
Global IKE and IPsec Commands
Many commands relating to IPsec are global and can be used by IPsec Security Associations created by either IKEv1 or IKEv2. These settings are for global IPsec attributes and will be relevant for IPsec Security Associations created by both IKEv1 and IKEv2. The following example illustrates some of the global IPsec commands available.
Router(config)#crypto ipsec ?
client Configure a client
df-bit Handling of encapsulated DF bit.
fragmentation Handling of fragmentation of near-MTU sized packets
ipv4-deny Configure global ipv4 deny policy.
nat-transparency IPsec NAT transparency model
optional Enable optional encryption for IPSec
profile Configure an ipsec policy profile
security-association Security association parameters
transform-set Define transform and settings
Router(config)#crypto ipsec security-association ?
dummy Enable transmitting dummy packets
ecn Handling of ECN bit
idle-time Automatically delete IPSec SAs after a given idle period.
lifetime security association lifetime
replay Set replay checking
If SNMP monitoring is enabled for IKE or IPsec, the messages will be generated by either IKEv1 or IKEv2. There is no method to differentiate between either IKE protocol.
FlexVPN Features
FlexVPN brings a plethora of new features. When looking to move from an IKEv1 to IKEv2 deployment, understand the features that FlexVPN offers and evaluate them to ensure that the transition brings the most benefits.
The features that FlexVPN introduces could influence purchasing decisions if hardware is also upgraded. Features such as Tunnel Pivot, which allows a tunnel interface to amend the tunnel source based on a tracked event, or Backup Peers, where the tunnel destination can dynamically change, can potentially result in hardware configurations requiring fewer interfaces that previously needed.
FlexVPN combines a number of previous Cisco VPN technologies. Before FlexVPN was available, a number of hardware devices might have been required to terminate different types of VPN topologies, while now a single hardware device can be used.
Although not specific to FlexVPN, if the current VPN architecture uses crypto maps to protect traffic, the decision to move to using tunnel interfaces should be considered. A benefit of using tunnel interfaces when migrating from IKEv1 to IKEv2 is that only a single IPsec Security Association is created for the tunnel interface. With a crypto map, on the other hand, an IPsec Security Association is created for every entry within the crypto map’s access control list. In this instance there is less chance of exceeding the maximum number of IPsec Security Associations.
Familiarization
Any individual who is experienced with IKEv1 will require some degree of retraining when migrating a VPN architecture from IKEv1 to IKEv2.
The architects and designers of the VPN architecture should be familiar with the features that IKEv2 brings. Such features as high availability and third-party support should be understood to ensure that technologies are aligned to business requirements.
Staff who will be operating and monitoring the new architecture should be familiar with the operations of IKEv2. Knowing how the protocol operates will assist greatly in any troubleshooting or diagnostic scenario. Because Cisco TAC worked closely with the development team within Cisco, there are many commands and debug options that were not available in IKEv1. Support staff should be made aware of such tools to maximize productivity and minimize downtime.
Client Awareness
When a remote access architecture is in use, a move from IKEv1 to IKEv2 could require users to get a new version of code for the VPN client. In this instance, the new client software will need to be installed and checked for compatibility issues with the operating system; it will also be necessary to ensure that it operates as intended.
Public Key Infrastructure
For many customers that are moving to IKEv2 and have never previously had a requirement to use PKI, PKI is a new concept. There is a common assumption that setting up an internal PKI is a simple task, and this effort is not factored into the scope and budget for projects that involve migrations or new deployments using IKEv2. On the contrary, setting up a well-designed and architectured PKI can consume as much time (or even more) than as designing the VPN itself!
Cost can be a factor when designing a PKI. Hardware Security Modules (HSM) allow for governance around the storage and operation of key material. HSM are relatively expensive pieces of equipment and require specialist skill. This can come as a shock to customers who are required to use a HSM when it is specified in a standard or accreditation that they are governed by.
The following questions and considerations should be addressed when using IKEv2 with a PKI:
Should the current authentication mechanism not include PKI, and if PKI is introduced, will there be skilled individuals to design, architect, and support this?
When PKI is used as the method of authentication, will the existing capacity of the PKI be exceeded?
Can the existing PKI issue certificates for use with IPsec VPNs?
Is there a cost for obtaining certificates?
Will the installation of additional certificates on a client machine cause another PKI-based service to use the incorrect certificate?
Could the addition of revoked certificates cause disruption to other functions, consuming PKI services such as CRLs?
Is there accurate time available to ensure that validations do not fail or that expired certificates can’t be used?
Since nearly all remote-access IKEv2 deployments use EAP and/or digital signatures for authentication, PKI is a critical component. For this reason, care must be taken to ensure that the PKI is available and redundant. Outages can occur if a CRL is not published in a timely manner, or if OCSP checks fail. Having accurate and assured time is a mandatory requirement when using PKI; this is another factor to consider when clients are on an untrusted network.
Internet Protocol Version 6
In many circumstances when a new VPN gateway is deployed, IPv4 and/or IPv6 connectivity is required. It is now becoming common for transport networks to support only IPv6, so even if the overlay network is running solely IPv4, it can be prudent to enable both IPv4 and IPv6 on the VPN gateway for the transport network to ensure clients using any transport network can successfully connect.
If there is a requirement for both IPv4 and IPv6 to be transported within the same IPsec Security Association, then dual stack can be used. Auto tunnel mode can be used to support clients running IPv4 or IPv6 transport protocols, with the ability to dynamically create an IPv4 or IPv6 virtual-access interface on demand.
Mixed mode allows for IPv4 networks to be transported over an IPv6 transport network when using VTI. GRE allows for IPv4 and IPv6 prefixes to be transported over an IPv4 or IPv6 transport network.
When using DNS with IPv4 and IPv6, ensure that the A record and AAAA record are available. This is a common oversight when configuring IPv6-enabled clients.
Authentication
IKEv1 and IKEv2 use similar, but not identical authentication methods. While IKEv1 provides pre-shared key, RSA signatures, RSA nonces, and username/password when using extended authentication (X-Auth), IKEv2 supports authentication using pre-shared keys, RSA signatures, ECDSA signatures, and EAP.
If the current authentication method used is not available with IKEv2, then a strategy is required to provide a new means of authentication. For example, this may occur when implementing a PKI for the new IKEv2 deployment or migrating users from extended authentication to using EAP (which also requires a PKI).
High Availability
If a load balancer is currently used to distribute load between IKEv1 gateways and all clients connect to a single (virtual) IP address (VIP) of the load balancer, a new VIP could be required for clients to connect to the new IKEv2 gateways.
As an alternative to using a load balancer, for clients that support the IKEv2 redirect feature, FlexVPN load balancer can be used. In a scenario such as this, clients will use either IKEv1 or IKEv2. It is uncommon for clients to support both protocols. Cisco AnyConnect has only supported IKEv2 since version 3. For this reason, clients can be migrated to the new VPN gateway using the IKEv2 redirect feature, and when all clients have been migrated, the previous IKEv1 gateway and load balancer may be decommissioned.
Note
If clients or peers connect to a VPN gateway using a Fully Qualified Domain Name (FQDN) and DNS is used, an additional DNS record will be required if an IKEv1 and IKEv2 gateway is used simultaneously during migration.
Asymmetric Routing
In situations where states of network flows are maintained and used by network or security devices, you must ensure that symmetrical flows occur. Figure 16-1 illustrates a typical scenario in which separate hardware is used for IKEv1 and IKEv2 protected traffic. The two routers at the same branch have a software firewall, such a zone-based firewall (ZBF), which inspects unencrypted (plaintext) traffic. If traffic is sourced from the LAN behind the branch routers, goes to Hub1 via the IKEv2-protected IPsec Security Association, and returns via Hub2 and the IKEv1-protected IPsec Security Association, the software firewall on Brach router2 will drop this traffic because no state exists.
Example of other devices that maintain state are load balancers, proxies, Intrusion Prevention Systems (IPS), and Network Address Translation (NAT) devices. Care should be taken when migrating to ensure that these devices do not cause traffic to be dropped or blocked due to asymmetric routing.
Migration Strategies
In a transition from IKEv1 to IKEv2, there are a number of methods for migration that will depend on the type of topology being deployed and the equipment currently in use.
We can break the migration strategies down into two high level categories:
1. Ones where new equipment is required because of hardware, capacity, configuration, or licensing limitations, so the migration will involve swapping out existing hardware for new. This is known as a hard migration, in which there is a service outage when migrating between hardware.
2. Ones where the current equipment supports both IKEv1 and IKEv2 and both protocols will be operated at the same time. This is known as a soft migration, in which the amount of downtime is minimized and a slower approach can be taken.
Either method should be carefully planned to ensure that disruption is minimized.
Hard Migration
When new equipment is required, devices are swapped out or configurations removed and re-applied; testing should then occur within a lab environment to ensure that the new configuration will operate as intended.
Hard migrations will usually have a planned outage during which equipment will be swapped. Ensure that the ARP cache of adjacent devices is cleared when the new hardware is installed and ensure that management plane access to the new device is permitted.
For a hub-and-spoke topology, if the client is to be migrated in a hard migration, the hub site must be able to support both IKEv1 and IKEv2 clients. Having the hub support both types of clients or installing a new hub that will service IKEv2 clients can achieve this. Installing a new hub is a preferred option, for it allows the older hardware to be decommissioned once the migration has occurred.
If the hub is to service both IKEv1 and IKEv2 clients, then the cleanest method to separate access is to have a separate IP address for the IKEv1 tunnel source interface and another separate IP address for the IKEv2 tunnel source interface. This removes the chance of misconfigurations and allows for a clean differentiator between IKEv1 and IKEv2.
If architectures have an IPsec Security Association protecting traffic between two local-area networks (LAN) and both IKE peers are required to be swapped at the same time, the outage window should be scheduled accordingly. To enable ease of troubleshooting, security controls such as firewalls should be configured to allow ICMP echo (type 8 code 0) and echo-reply (type 0 code 0) from the tunnel source and destination addresses.
The configuration used when performing a hard migration depends on the implementation. From a new client device perspective, the configuration will be as you would configure any IKEv2 device, as explained in earlier chapters. For the hub device, the configuration will probably use virtual-templates; however, the exact configuration depends on the specific requirements.
If for some reason the new deployment was not successful, then reverting to the previous IKEv1 configuration should be a case of reinstalling the original hardware or reapplying the original configuration. A diagnosis can then be performed to determine the cause of the failure of the migration.
Soft Migration
When a soft migration is performed, both IKEv1 and IKEv2 will coexist on the same device for a period of time. For the time that both IKEv1 and IKEv2 are operational, a method must be used to differentiate sending traffic via an IPsec Security Association established using IKEv1 or IKEv2. This task is usually performed by the routing protocol, where traffic is continually sent down the IPsec Security Association created by IKEv1, until the IKEv2 SA and corresponding IPsec Security Association has been verified. Verification can be as simple as redistributing a small range of prefixes over the IKEv2-created IPsec Security Association and then sending traffic between peers who are consuming these prefixes.
Figure 16-2 illustrates the concept of testing an IKEv2-generated IPsec Security Association while sending the majority of traffic over the existing IKEv1-created IPsec Security Association. This can be achieved by setting a static route with the next hop of the tunnel interface using the command ip route 192.168.10.1 255.255.255.255 tunnel 10, with tunnel 10 being the tunnel protected by IKEv2.
Soft Migration Example
The following scenario provides guidance on migrating from an IKEv1 deployment to an IKEv2 deployment with minimal downtime and disruption.
This scenario will use IKEv2 routing as the new method to exchange prefixes between peers. For more complex architectures where a routing protocol is used, an adjustment should be made to ensure that the routing protocol used by IKEv2 does not override the routing protocol used by IKEv1 until the intended time.
We start with an initial configuration where IKEv1 is used to establish a secure connection between peers; this is a simple IPsec Security Association. Over the IPsec Security Association, EIGRP is used to create a neighbor relationship and distribute prefixes between devices.
The topology is illustrated in Figure 16-3. There are two routers currently connected with IKEv1.
The following was created to simulate an already established IKEv1 deployment.
1. An IKEv1 policy is created; this is vaguely equivalent to a IKEv2 proposal.
crypto isakmp policy 10
authentication pre-share
2. For simplicity, a pre-shared key is used.
crypto isakmp key cisco address 10.10.10.2
3. An IPsec profile is used, which will use the default IKEv1 policy created earlier.
crypto ipsec profile ikev1
4. A loopback interface is used that will allow traffic that will transverse the VPN to be sourced from and destined to.
interface Loopback0
ip address 192.168.10.1 255.255.255.0
5. The tunnel interface is created with the relevant source interface configured and the destination address of Router2. This is protected by the IPsec profile created previously.
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 10.10.10.2
tunnel protection ipsec profile ikev1
6. The interface used as the tunnel source.
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
7. EIGRP is used to establish a peer relationship over the tunnel interface and distribute the loopback prefix.
router eigrp 1
network 172.16.1.0 0.0.0.255
network 192.168.10.0
Router 2 has a similar configuration; the relevant details are displayed in the following example.
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco address 10.10.10.1
crypto ipsec profile ikev1
interface Loopback0
ip address 192.168.20.1 255.255.255.0
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 10.10.10.1
tunnel protection ipsec profile ikev1
interface Ethernet0/0
ip address 10.10.10.2 255.255.255.0
router eigrp 1
network 172.16.1.0 0.0.0.255
network 192.168.20.0
The IKEv1 SA is created, which in turn creates the IPsec Security Association that is used to protect the tunnel interface. The following example illustrates the verification of the IKEv1 SA and the neighbor establishment over the corresponding tunnel interface.
The IKEv1 SA can be seen. Note that the state QM_IDLE indicates that this was successfully created.
Router1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.10.10.2 10.10.10.1 QM_IDLE 1003 ACTIVE
IPv6 Crypto ISAKMP SA
The prefix for the IP address on the loopback interface on Router2 is distributed over EIGRP. Router1 will use the tunnel interface as the next hop to reach this prefix.
Router1#show ip route 192.168.20.0
Routing entry for 192.168.20.0/24
Known via "eigrp 1", distance 90, metric 27008000, type internal
Redistributing via eigrp 1
Last update from 172.16.1.2 on Tunnel0, 00:25:33 ago
Routing Descriptor Blocks:
* 172.16.1.2, from 172.16.1.2, 00:25:33 ago, via Tunnel0
Route metric is 27008000, traffic share count is 1
Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 1
Both routers will now be configured to use a second tunnel interface. This interface will be protected by an IPsec profile that uses IKEv2. Rather than using EIGRP as the mechanism to distribute prefixes between peers, IKEv2 routing will be used. As EIGRP uses a default Administrative Distance (AD) of 90 and IKEv2 routing will install prefixes in the RIB as static routes with a local AD of 1, the prefixes installed for IKEv2 routing will be amended to a value of 100, being less preferred than the EIGRP prefixes. This ensures that the RIB will always prefer the prefixes learned over EIGRP via the IKEv1-protected tunnel interface rather than the prefixes learned via the IKEv2-protected tunnel interface. If a large number of prefixes were required or these changed frequently, a routing protocol would be a better choice rather than IKEv2 routing. The following example shows the configuration required.
Note that in this configuration pre-shared key authentication is used with a weak shared-secret. For production environments, digital signatures should be used or a shared-secret containing sufficient entropy. For maximum security, next-generation encryption (NGE) algorithms should be used.
1. An access control list is created which contains the prefix that is to be sent to the peer router. This is the same prefix as Router1 distributes to Router2 using EIGRP over the IKEv1 IPsec Security Association.
access-list 50 permit 192.168.10.0 0.0.0.255
2. The default IKEv2 authorization policy is amended to send the prefixes created in access-list 50. Any prefixes received over IKEv2 will be applied with an administrative distance of 100.
crypto ikev2 authorization policy default
route set interface
route set access-list 50
route accept any distance 100
3. An IKEv2 profile is created that is used for connectivity to Router2. As IKEv2 routing is used, DPD is enabled to ensure that the IKEv2 SA is torn down and corresponding prefixes are removed if connectivity is lost. To enable sending and receiving prefixes to/from the peer using IKEv2 routing, AAA authorization is enabled.
crypto ikev2 profile ikev2
match identity remote address 10.10.10.2 255.255.255.255
authentication remote pre-share key cisco123
authentication local pre-share key cisco123
dpd 30 10 on-demand
aaa authorization group psk list default default
4. An IPsec profile is created that uses the IKEv2 profile created previously.
crypto ipsec profile ikev2
set ikev2-profile ikev2
5. The tunnel interface is created with the relevant source interface configured and the destination address of Router2. This is protected by the IPsec profile created previously, enabling IKEv2 on this interface. To ensure that the correct IKEv2 profile is selected and not the IKEv1 profile, this is defined using the ikev2-profile command.
interface Tunnel10
ip address 172.16.2.1 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 10.10.10.2
tunnel protection ipsec profile ikev2 ikev2-profile ikev2
The configuration for Router2 is very similar. The following example illustrates the configuration on Router2 with the differences being highlighted.
access-list 50 permit 192.168.20.0 0.0.0.255
crypto ikev2 authorization policy default
route set interface
route set access-list 50
route accept any distance 100
crypto ikev2 profile ikev2
match identity remote address 10.10.10.1 255.255.255.255
authentication remote pre-share key cisco123
authentication local pre-share key cisco123
dpd 30 10 on-demand
aaa authorization group psk list default default
crypto ipsec profile ikev2
set ikev2-profile ikev2
interface Tunnel10
ip address 172.16.2.2 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 10.10.10.1
tunnel protection ipsec profile ikev2 ikev2-profile ikev2
Each router now has two tunnel interfaces created between each other. One is protected using IKEv1 and the other using IKEv2. The following example shows the commands used to verify the new tunnel interface and the protection applied.
The IKEv2 SA includes the remote prefix that was sent over IKEv2 routing.
Router1#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.10.10.1/500 10.10.10.2/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:5, Auth sign:
PSK, Auth verify: PSK
Life/Active Time: 86400/629 sec
CE id: 1004, Session-id: 2
Status Description: Negotiation done
Local spi: CDB7428C1D03F3AB Remote spi: F5C4546346F689A9
Local id: 10.10.10.1
Remote id: 10.10.10.2
Local req msg id: 3 Remote req msg id: 0
Local next msg id: 3 Remote next msg id: 0
Local req queued: 3 Remote req queued: 0
Local window: 5 Remote window: 5
DPD configured for 30 seconds, retry 10
Fragmentation not configured.
Extended Authentication not configured.
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : Yes
Remote subnets:
192.168.20.0 255.255.255.0
Although the prefix for 192.168.20.0/24 was received, it will have an AD of 100. This is not installed into the RIB as the prefix is already populated by the prefix installed by EIGRP, with an AD of 90.
Router1#show ip route 192.168.20.0
Routing entry for 192.168.20.0/24
Known via "eigrp 1", distance 90, metric 27008000, type internal
Redistributing via eigrp 1
Last update from 172.16.1.2 on Tunnel0, 00:11:56 ago
Routing Descriptor Blocks:
* 172.16.1.2, from 172.16.1.2, 00:11:56 ago, via Tunnel0
Route metric is 27008000, traffic share count is 1
Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 1
Figure 16-4 illustrates both the IKEv1 and IKEv2 tunnels coexisting. Dataplane traffic will flow via the IKEv1-protected tunnel interface.
When the IKEv1-protected tunnel interface (Tunnel 0) is shut down, the EIGRP neighborship is deleted, and the prefix for 192.168.20.0/24 that was learned via EIGRP is removed. At this point the prefix that was received via the IKEv2-protected tunnel interface (Tunnel 10) is installed into the RIB. The following example illustrates this behaviour, where debugging of IP routing was enabled.
Router1(config)#interface tunnel 0
Router1(config-if)#shutdown
is_up: Tunnel0 0 state: 6 sub state: 1 line: 0
RT: interface Tunnel0 removed from routing table
RT: del 172.16.1.0 via 0.0.0.0, connected metric [0/0]
RT: delete subnet route to 172.16.1.0/24
RT: del 172.16.1.1 via 0.0.0.0, connected metric [0/0]
RT: delete subnet route to 172.16.1.1/32
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.2 (Tunnel0) is down: interface
down
RT: delete route to 192.168.20.0 via 172.16.1.2, eigrp metric [90/27008000]
RT: no routes to 192.168.20.0, delayed flush
RT: delete network route to 192.168.20.0/24
RT: updating static 192.168.20.0/24 (0x0) :
via 0.0.0.0 Tu10 0 1048578
RT: add 192.168.20.0/24 via 0.0.0.0, static metric [100/0]
The prefix is now accessible via the tunnel interface (Tunnel 10) protected by IKEv2.
Router1#show ip route 192.168.20.0
Routing entry for 192.168.20.0/24
Known via "static", distance 100, metric 0 (connected)
Tag 1
Routing Descriptor Blocks:
* directly connected, via Tunnel10, permanent
Route metric is 0, traffic share count is 1
Route tag 1
Now all traffic that is destined to the 192.168.20.0/24 prefix will flow over the tunnel that was created using IKEv2. This can be seen in Figure 16-5; as soon as the IKEv1-protected tunnel interface is shut down, traffic will flow over the IKEv2 tunnel interface.
For migration scenarios, it is advised that the IKEv2 SA is left to rekey a number of times to ensure that there is stability before bringing down the tunnel created by IKEv1. This check can verify that IKEv2 is functioning correctly.
Once it has been determined that the IKEv2 tunnel is working as intended, the IKEv1 tunnel interface can be shut down. When it is certain that the IKEv1 configuration is no longer required, this can be removed.
In the previous examples, the IPsec profile contained only IKEv1 or IKEv2 profiles, never mixed. It is currently impossible to specify an IKEv1 and an IKEv2 profile within an IPsec profile.
An IPsec profile will only allow either an IKEv1 profile or an IKEv2 profile to be attached. It is not possible to have both an IKEv1 and an IKEv2 profile configured within an IPsec profile.
The following example illustrates an attempt to apply both an IKEv1 and a IKEv2 profile to an IPsec profile and the error message generated.
Router(config)#crypto ipsec profile ipsec
Router(ipsec-profile)#set isakmp-profile ikev1
Router(ipsec-profile)#set ikev2-profile ikev2
% WARNING: Configuring Ikev2 profile will remove the Ikev1 profile configured
under this ipsec profile!
When tunnel protection is applied, the specific IKEv1 or IKEv2 profile that will be used can be configured. The following example illustrates applying an IPsec profile that is configured to use an IKEv1 profile; however, because the IKEv2 profile is specified in the tunnel protection command, the IKEv2 profile will be used instead, and IKEv1 traffic will not be processed for this tunnel interface.
Router(config)#interface tunnel 1
Router(config-if)#tunnel protection ipsec profile ipsec_profile ?
ikev2-profile Specify ikev2 profile for the crypto connection.
isakmp-profile Specify isakmp profile for the crypto connection.
shared Use a shared socket for the crypto connection.
Router(config-if)#tunnel protection ipsec profile ipsec_profile ikev2-profile
ikev2
Although this is not a common deployment and similar goals can be achieved using a configuration where a separate tunnel protection is applied per tunnel interface, this can be used for migrations from IKEv1 to IKEv2.
Migration Verification
When IKEv2 is active for the first time, basic checks should be performed to verify that the IKE and IPsec Security Association have been created as intended. The show crypto ikev2 sa command can be used to verify the status of the IKEv2 SA, with the detail keyword adding more verbose output. The IPsec Security Association can be verified along with the IKEv2 SA with the show crypto session command.
The IKEv2 SA should be left to rekey a number of times to ensure that rekey is successful; if PFS is enabled, this can be validated also.
The following example illustrates how to determine if PFS is enabled. Note that PFS will only show once the first CHILD_SA has been created, so you will need to allow the IPsec Security Association to rekey, which is by default 3600 seconds.
Router#show crypto ipsec sa
interface: Virtual-Access1
Crypto-map tag: Virtual-Access1-head-0, local addr 10.10.10.1
protected vrf: (none)
local ident (addr/mask/prot/port): (10.10.10.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.10.10.2/255.255.255.255/47/0)
current_peer 10.10.10.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 726, #pkts encrypt: 726, #pkts digest: 726
#pkts decaps: 1521, #pkts decrypt: 1521, #pkts verify: 1521
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.10.10.1, remote crypto endpt.: 10.10.10.2
plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0x3F82A9C5(1065527749)
PFS (Y/N): Y, DH group: group19
If PKI is used with certificate revocation, checks should occur to ensure that revocation is working correctly and that when a client’s certificate is revoked, access for that client is prevented due to a failed authentication.
Assuming that a like-for-like migration has occurred, the same number of peer devices should exist once the configuration has moved from IKEv1 to IKEv2. The following example illustrates viewing the number of active IKEv2 SAs and then viewing deeper details about these with the show crypto session brief and the show crypto ipsec sa commands. Note that this show command does not differentiate between IKEv1 and IKEv2 sessions.
Router#show crypto ikev2 stats
--------------------------------------------------------------------------------
Crypto IKEv2 SA Statistics
--------------------------------------------------------------------------------
System Resource Limit: 0 Max IKEv2 SAs: 0 Max in nego(in/out):
40/400
Total incoming IKEv2 SA Count: 2 active: 2 negotiating: 0
Total outgoing IKEv2 SA Count: 0 active: 0 negotiating: 0
...
Router#show crypto session brief
Status: A- Active, U - Up, D - Down, I - Idle, S - Standby, N - Negotiating
K - No IKE
ivrf = (none)
Peer I/F Username Group/Phase1_id Uptime Status
10.10.10.2 Vi1 hostname=R2.cisco.com,cn 01:30:00 UA
10.10.10.1 Vi2 hostname=R1.cisco.com,cn 00:07:00 UA
In most cases the same prefixes will exist in the RIB once migration has occurred, verifying that the RIB is populated as intended can be performed using the show ip route command.
Consideration for Topologies
The following topologies are examined, and the main considerations that pertain to each are described.
Common IPsec VPN topologies can be broken down into the following categories:
Site-to-Site
In this setup, a tunnel is created between two routers. This is a common method to securely connect two organizations or data centers together. Normally a single tunnel interface is used on each device. Having just a single pair of IPsec Security Associations allows for a simple migration path, in which a new tunnel can be created and brought up alongside the existing tunnel.
Should crypto maps be currently used, then there is the possibility that tunnel interfaces can be used instead. Should this occur, additional configuration may be required to ensure that only specific traffic is permitted to transverse the new tunnel interface.
If the current equipment supports IKEv2, then a new pair of tunnel interfaces can be created and migrated from IKEv1 to IKEv2. This is the simple approach and allows reuse of hardware; however, hardware capacity needs to be taken into account. For this scenario, routing protocols could be used over the existing IPsec Security Association. Thought should go into how the routing is going to be migrated from the existing architecture to the new design when traffic protected using IKEv2 will become active.
The following example illustrates moving a site-to-site VPN from using IKEv1 to IKEv2. High-level steps are shown to illustrate the concepts. For specific configuration information, please consult the previous chapters. This merely illustrates a method to follow for a migration with minimal disruption. This methodology can be implemented only on devices that are IKEv2-capable.
Figure 16-6 illustrates a simple site-to-site VPN between two routers. Currently this is using IKEv1.
Figure 16-7 shows a second protected tunnel interface created on both routers. This second IPsec protected tunnel is created using IKEv2. Routing protocols should be configured so that the IKEv1-protected VPN has preference over the IKEv2-protected VPN. Routing via the second tunnel must also be verified, which can be achieved manually, depending on routing protocol or static IKEv2 routing.
In the following figure there are multiple tunnels on each peer. This simulates both peers running IKEv1 and IKEv2 simultaneously. It could be the case that the IKEv1 tunnel is destined to one peer and the IKEv2 to another; however, for simplicity this is not shown, but the concept would be the same.
Figure 16-8 illustrates the IKEv1-protected VPN being shut down. Traffic will now flow over the VPN protected by IKEv2. Once it has been verified that the new IKEv2-protected VPN is functioning correctly, the previous configuration can be removed to minimize confusion.
Hub and Spoke
Hub-and-spoke topology is used when remote devices connect to a single location. An example is small offices or home workers who connect to a central location. It is common for EzVPN to be used in this scenario. Remote sites will usually have a default route or summary route via the hub. In situations where spoke devices have dual connections to hubs, IKEv2 routing is very suitable, for different paths can have different local administrative distances.
There are many features of FlexVPN that were not possible using previous VPN technologies. Features such as backup peers and/or tunnel based activation are well suited to hub-and-spoke architectures and can bring a number of business benefits that were previously unavailable.
For more complex routing scenarios, a routing protocol can be used over a tunnel interface, but care should be taken for lower-end models to ensure that the capacity is adequate if multiple tunnels and routing protocols are required for a transition phase.
If different groups of spoke devices have different requirements for policies such as QoS or ACLs, then the method to apply these must be defined. If a name-mangler is going to be used to extract a property within the IKE identity, it is critical that the property extracted is correctly defined and operates as intended.
The following example shows how a hub-and-spoke deployment can be migrated from a hub that is running IKEv1 to a new hub that is running IKEv2. As the spoke device is going to be running IKEv1 and IKEv2 concurrently, this would be classified as a soft move.
Figure 16-9 illustrates the topology. A spoke router has an IKEv1 connection to a hub router (Hub1). Hub1 cannot support IKEv2, hence another hub (Hub2) is provisioned. The spoke can support both IKEv1 and IKEv2.
Figure 16-10 illustrates a second protected tunnel interface created on the spoke to Hub2. The spoke now has two active tunnel interfaces, one to Hub1 protected by IKEv1 and one to Hub2 that is protected by IKEv2. Routing protocols should be configured so the IKEv1-protected VPN has preference over the IKEv2-protected VPN. Routing via the second tunnel must also be verified.
Figure 16-11 illustrates the IKEv1 tunnel interface being shut down on the spoke. Traffic will then flow via the IKEv2-protected interface to Hub2. Once it has been verified that the new IKEv2 protected VPN is correctly functioning the previous configuration can be removed to minimize confusion.
Once all spokes have been migrated from Hub1 to Hub2, Hub1 can be decommissioned and removed from service.
In the example shown above, if the Hub did support both IKEv1 and IKEv2 and there was sufficient capacity, both tunnels could be configured on the single hub.
If the spoke hardware could not support IKEv2, the same scenario could be achieved by physically swapping the spoke device for a hardware model that supported IKEv2. In this case a hard move would occur.
Remote Access
Remote access architectures allow for a number of clients to connect to a central location. The clients are usually software clients, small-form-factor routers, or similar devices. Internet of Things (IoT) is now an example of what could be described as remote access. Clients will be allocated an address dynamically and will usually tunnel all traffic to the VPN gateway. In some situations traffic might be split-tunneled, where the IPsec Security Association will not protect all traffic, certain traffic will be sent outside of the IPsec Security Association.
When new software clients are required, an upgrade of the operating system could be needed, or additional software patches be applied to clients. When IKEv2 is used, mandatory attributes might be required by the client that were not required in IKEv1.
In many instances remote access clients might require IKEv2 fragmentation to be enabled, especially if the authentication method has changed to using a certificate-based architecture. In this case, IKEv2 fragmentation should be considered and enabled if required.
Care should be taken in designing the allocation of client IP addresses, the pool must be re-distributed into the routing protocol to permit return traffic when accessing resources on the internal network. Clients should have full access to the resource that is needed, if multiple types of users or groups require separated access this will need to be integrated into the solution. It could be that multiple IVRFs are used for each group of users, or that a simple access control list (ACL) is applied to restrict or permit access.
Figure 16-12 illustrates a typical migration where two VPN gateways are being used to serve remote clients. The IP address pool that is used to allocate clients IP address must be redistributed internally to allow a return path for clients’ traffic. A common mistake when migrating is not redistributing this subnet into the local routing protocol, which results in clients having unidirectional access to resources on the protected LAN.
QoS can be enabled easily on remote access VPN architectures when using dVTI. This might not have been possible in the previous deployment and care should be taken to ensure that traffic does not exceed set rates and is rate limited or dropped.
If single-factor authentication is needed or dual-factor using aggregate authentication, then AnyConnect will be needed.
In many remote access scenarios in which users are connecting to a VPN gateway running IKEv2, new hardware will be required. The rationale behind this statement is that many remote access deployments are still running IKEv1 or TLS and at the time of this writing are moving to using IKEv2.
Summary
When migrating from IKEv1 to IKEv2, there is no one-size-fits-all model. Just as every IP network is unique, every migration will be unique. For this reason all considerations covered within this chapter potentially need to be addressed.
It is necessary to be aware of the considerations? when moving to IKEv2, such as what features are supported by current software and hardware, to ensure a smooth transition. Knowing the capacity of the current system is crucial. Deploying a migration that could cause disruption due to exceeding capacity could potentially be catastrophic.
When remote access solutions are migrated, a number of features provided by FlexVPN can be used to ensure a smooth transition. IKEv2 routing can be used to easily amend locally installed prefixes to install backup routes that become active once the legacy IKEv1 tunnel is shutdown.
There are a few key points to remember when migrating. Always leave the new IKEv2 tunnel running for a period of time to ensure that rekeying occurs. There are a number of restrictions when running IKEv1 and IKEv2 on the same device. Separate tunnel interfaces should be configured, protected by each protocol, and these should be clearly marked to ensure that the correct tunnel is shutdown when required.