Chapter 6. FlexVPN Configuration and Troubleshooting
This chapter covers the following subjects:
• FlexVPN Overview: This section provides an overview on how FlexVPN is different from previous VPN technologies and what benefits it provides.
• FlexVPN Components: This section examines the building blocks of FlexVPN and how they work together to create a comprehensive solution for a variety of architectures.
• FlexVPN Design Considerations: This section reviews key requirements and considerations when you design a FlexVPN solution.
• FlexVPN Implementation: Hub-and-Spoke (IPv4/IPv6): This section steps through the components of a FlexVPN hub-and-spoke (IPv4/IPv6) configuration. It demonstrates, with examples, how each of the FlexVPN building blocks in a three-router solution operates.
• FlexVPN Troubleshooting: This section discusses how to break down your troubleshooting of FlexVPN based on the configuration building blocks.
“Relying on the government to protect your privacy is like asking a peeping tom to install your blinds.”
—John Perry Barlow
This chapter covers the following exam objectives:
• 1.0 Site-to-site Virtual Private Networks on Routers and Firewalls
• 1.3 Describe uses of FlexVPN
• 2.0 Remote access VPNs
• 2.4 Implement Flex VPN on routers
• 3.0 Troubleshooting using ASDM and CLI
• 3.1 Troubleshoot IPsec
• 3.3 Troubleshoot FlexVPN
• 4.0 Secure Communications Architectures
• 4.1 Describe functional components of GETVPN, FlexVPN, DMVPN, and IPsec for site-to-site VPN solutions
• 4.3 Recognize VPN technology based on configuration output for site-to-site VPN solutions
• 4.6 Design site-to-site VPN solutions
Welcome to the last site-to-site VPN topic, which is a deep dive into FlexVPN as well as a look at troubleshooting site-to-site VPN technology. Cisco offers many VPN flavors, and each one requires different configurations, show commands, and debug commands. Of all the options available, FlexVPN is the Cisco option used to simplify VPN deployments and covers all VPN types, including support for site-to-site VPN, hub-and-spoke VPN, and remote access VPN deployments. The only caveat to this statement is that FlexVPN does not cover GETVPN.
FlexVPN is a common configuration template for all VPN types and is based on IKEv2. It is important to point out that FlexVPN does not support IKEv1. Many experts view this as a good thing, as IKEv2 is more secure based on its support of the latest Suite B cryptographic algorithms. As mentioned in Chapters 4 and 5, the Implementing Secure Solutions with Virtual Private Networks (SVPN) exam expects you to be able to identify FlexVPN code as well as plan, deploy, and troubleshoot FlexVPN using Cisco technology. This chapter will help you master these topics.
Learning beyond the SVPN concepts:
• FlexVPN Overview
• VPN Licensing
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz enables you to assess whether you should read the entire chapter. If you miss no more than one of these self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section of the chapter. Table 6-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions related to the material in each of those sections to help you assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
Table 6-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
1. What feature does FlexVPN include to speed the configuration process?
a. Predefined templates
b. Predefined defaults
c. Installation script
d. Installation template
2. What are some benefits of FlexVPN compared to legacy VPN solutions? (Choose two.)
a. Support for multiple VPN types
b. Backward compatibility
c. Installation script
d. Support on all platforms
3. What new IKEv2 enhancements does FlexVPN support? (Choose two.)
a. PSK
b. Suite B
c. PKI
d. EAP
4. Which of the following configurations are supplied for FlexVPN? (Choose two.)
a. IKEv2 profile
b. IPsec profile
c. IKEv2 policy
d. IPsec policy
5. What VPN capabilities does FlexVPN support that both DMVPN and crypto maps do not support? (Choose three.)
a. Configuration push
b. Per-peer configuration
c. Remote access
d. Full AAA management
e. Dynamic routing
6. Which FlexVPN hub command block enables IKEv2 parameters to download to the spokes?
a. IKEv2 proposal
b. IKEv2 policy
c. IKEv2 authorization
d. IKEv2 profile
7. Which IPsec configuration piece is optional in FlexVPN?
a. IPsec profile
b. IKEv2 profile
c. Tunnel protection IPsec profile
d. Transform set
8. Which command attaches the IKEv2 authorization policy and the AAA local authentication to the IKEv2 profile?
a. aaa authentication
b. keyring local
c. match identity
d. aaa authorization
9. With which of the following does a spoke have both a FlexVPN tunnel interface and a virtual template interface?
a. Hub-and-spoke communication
b. Spoke-to-spoke communication
c. Never
d. Virtual access interface
10. Which of the following need to be configured for spoke-to-spoke connectivity? (Choose two.)
a. Keyring modification
b. Additional tunnel interface
c. Routing configuration
d. NHRP configuration
11. What command on the hub router enables you to determine whether the IKEv2 process has completed?
a. show crypto ikev2 authorization policy
b. show crypto ikev2 profile
c. show crypto ikev2 sa
d. show ip interface brief
12. What command on the spoke router shows whether spoke-to-spoke resolution has completed?
a. show ip route nhrp
b. show crypto ikev2 sa
c. show ip nhrp redirect
d. show ip protocol
13. Which of the following is not true regarding FlexVPN design considerations?
a. You must identify routing requirements
b. You must pick an encryption scheme
c. You must determine whether the deployment is site-to-site and/or remote access–related
d. You need to make sure at least IKEv1 or IKEv2 is supported
Foundation Topics
When you think about FlexVPN, Cisco wants you to think “easy.” One reason you should think FlexVPN is easy is the value of smart defaults. By using smart defaults, you can leverage predefined values based on industry best practices. Smart defaults can dramatically reduce the number of steps you must manually configure to stand up a VPN. FlexVPN is also very useful for customers looking to manage multiple VPN types. It can address the complexity of multiple solutions targeting remote access, teleworker, site-to-site, mobility, and managed security services, along with other use cases.
SVPN version 1.1 of the exam calls out requirements for understanding FlexVPN on Cisco routers, for remote access, site-to-site VPN for both routers and firewalls, and troubleshooting FlexVPN using both ASDM and command-line options. This is a lot of topics to cover, and this chapter focuses on the site-to-site VPN part of these requirements. Chapter 9, “AnyConnect IKEv2 FlexVPN,” covers using FlexVPN for remote access.
Let’s start off the FlexVPN conversation with a general overview of how the technology works.
FlexVPN Overview
Previous chapters explore the configuration of several types of VPN solutions. This chapter explores the fundamentals and configuration aspects of FlexVPN. Cisco’s FlexVPN is an implementation of the next generation of Internet Key Exchange (IKEv2). IKEv2 enhancements include mutual authentication and the establishment and maintenance of security associations (SAs).
FlexVPN was designed to take advantage of IKEv2, which is a next-generation key management protocol described in RFC 4306. Unlike IKEv1, IKEv2 performs mutual authentication and maintains SAs for both sides. The following are some key benefits of leveraging IKEv2 over IKEv1:
• It is more secure than IKEv1 because it supports the latest Suite B cryptographic algorithms.
• It includes built-in support for dead peer detection (DPD) and NAT Traversal.
• It combines IKEv1 main and aggressive modes into one method called initial.
• It supports native routing.
• Besides certificates and PSKs, it supports EAP authentication.
• XAUTH is replaced by EAP tunneling.
Some organizations might want to phase in FlexVPN rather than make a large-scale change. The support for legacy solutions permits a FlexVPN device to support IKEv1 remote sites while an organization is transitioning. However, FlexVPN is not backward compatible, meaning FlexVPN does not support legacy technology that can only leverage IKEv1. In addition, FlexVPN supports both IPv4 and IPv6 for transport and overlay. This means that organizations can use FlexVPN to transition to IPv6 while running IPv4 as the transport protocol or implement a dual stack solution.
A powerful feature included in FlexVPN is the use of a default configuration also known as smart defaults. This helps an engineer get a solution up and running quickly by providing some of the built-in defaults. For example, an engineer can use the default IKEv2 proposal rather than provide all of the configuration information for Diffie–Hellman key exchange, encryption, integrity, and pseudorandom functions (PRFs).
FlexVPN Advantages
FlexVPN has a wide range of support making it a popular option for VPN administrators. Figure 6-1 demonstrates the potential solutions that FlexVPN offers. As you can see, FlexVPN supports AnyConnect clients as well as hub-and-spoke and spoke-to-spoke solutions.
Figure 6-1 FlexVPN Hub-and-Spoke Solution with Remote Access
Modular Framework
FlexVPN architecture offers a modular and relatively simple approach to VPN configuration. For example, the FlexVPN modular framework in Figure 6-1 enables this solution to support hub-and-spoke topologies similar to DMVPN as well as remote access VPN clients.
Note
IKEv2 is not supported on Cisco Integrated Service Router (ISR) Generation 1 (G1).
Configuring Service Parameters
Another key advantage of FlexVPN is the ability to implement per-peer configuration of service parameters such as firewall services, quality of service (QoS) features, and other policies. Therefore, the hub router in a hub-and-spoke solution could implement a QoS policy for a remote site to improve VoIP communication; with another site that is a partner company, the configuration could include a firewall policy. FlexVPN offers improved the integration with external authentication, authorization, and accounting (AAA) databases for multi-tenancy scenarios.
EasyVPN Benefits Summarized
An easy way to view the benefits of EasyVPN is using a summary table. Table 6-2 covers the key benefits of IKEv2.
EXAM NOTE
Be sure to study these benefits for the SVPN 300-730 exam.
Table 6-2 Benefits of IKEv2
FlexVPN Versus Other Options
On the SVPN exam, you will find questions that ask you to choose the best VPN option for a specific situation. You could also be provided a small snippet of code and asked to identify which VPN option is being used. To help with these questions, we have created a summary table in Table 6-3 that compares crypto maps, DMVPN, and FlexVPN. Remember, FlexVPN does not support GETVPN, which is why it is not included in this table.
Table 6-3 FlexVPN Capabilities
Figure 6-2 provides a graphical representation of the capabilities of FlexVPN. Notice in this figure that FlexVPN can support both the legacy VPN solutions, remote access clients (Windows and AnyConnect), and site-to-site VPNs on the same device. This is one of the most powerful features of FlexVPN.
Figure 6-2 FlexVPN Capabilities
Benefits of IKEv2
As shown in Table 6-4, IKEv2 provides a number of security enhancements. The major improvements with IKEv2 are National Security Agency (NSA) Suite B and anti-denial of service (anti-DoS) capabilities. Proper implementation of IKEv2 features results in secure key exchange between sites and/or clients.
Table 6-4 IKEv2 Security Enhancements
IKEv2 offers some significant advantages over its predecessor IKEv1. Like IKEv1, IKEv2 negotiates a security association between a pair of communicating peers; however, it is based on the third-generation specifications (RFC 4301 to 4309) and addresses security issues and protocol inefficiencies such as resistance to denial-of-service (DoS) attacks and support for more authentication methods.
FlexVPN Requirements
Cisco FlexVPN relies on IKEv2 and a tunnel interface model. This architecture enables both backward legacy VPN support (that is, crypto maps) and multi-tenancy support (site-to-site, remote-access, hub-and-spoke, and spoke-to-spoke) in a single hub site. In addition, Figure 6-3 shows that in a hub-and-spoke solution, the hub is able to manage parameters such as firewall features, attributes such as quality of service (QoS), policies, and VRF-related settings. Notice that the graphic shows that the hub router (HQ) is pushing route injection information. You will see configurations related to this later in this chapter.
Note
To be clear about FlexVPN support, backward legacy VPN support is not for VPN options that only support IKEv1. FlexVPN does not support technology that only uses IKEv1.
Figure 6-3 FlexVPN Per-Peer Options
FlexVPN Components
Within the Internet Key Exchange (IKE) version 2 standard are a few key components that are important building blocks which help aid in the configuration of FlexVPN. Some of these key components even have preset defaults that can be invoked. Figure 6-4 shows these key FlexVPN building blocks and the interdependencies between them. Notice the arrows linking the boxes together. One set of arrows indicates that the IKEv2 proposal is added to the IKEv2 policy. What this means is you need to first create the IKEv2 proposal, then create the policy, and finally add the proposal to it. This process is similar to how a keyring is added to an IKEv2 profile but only after the keyring is created.
Figure 6-4 FlexVPN Building Blocks
FlexVPN Component Roles
To better understand the components shown in Figure 6-4, let’s look at the role each of the components plays in a FlexVPN configuration:
• IKEv2 proposal: The IKEv2 proposal defines the protection attributes used in the negotiation of IKE SAs. If you are troubleshooting IKEv2, this negotiation happens during the IKE_SA_INIT phase, which you can see in the debug command output. This is the first configuration step that you complete when setting up a FlexVPN, and the IKEv2 proposal is attached to the IKEv2 policy. Cisco provides a default proposal to give you a simple way to configure a FlexVPN solution.
• IKEv2 policy: The IKEv2 policy is used to negotiate the encryption, integrity, PRF, and Diffie–Hellman (DH) group and is bound to either the IP address or to a virtual routing and forwarding (VRF) instance. As with the default proposal option, Cisco includes a default IKEv2 policy. Notice in Figure 6-4 that this is where the IKEv2 proposal is attached.
• IKEv2 authorization: This policy defines the local authorization policy and provides attributes used by the local IKEv2 device (hub) and what the server provides to the remote peers. In addition, the IKEv2 authorization policy can provide authentication using AAA that is either local or RADIUS based. The authorization policy is called by the IKEv2 profile using the aaa authorization command.
• IKEv2 keyring: This repository is for the symmetric and asymmetric pre-shared keys and is independent of the IKEv1 keyring.
• IKEv2 profile: This is a repository of parameters that are nonnegotiable, such as local or remote identities and the authentication methods and services available to the authenticated peers, based on the profile that was matched. This building block does not have a default, so you must configure one and attach it to the IPsec profile. If a pre-shared key is being used, the IKEv2 profile is where the IKEv2 keyring is attached; otherwise, certificate information is configured.
• IPsec transform set: The transform set specifies the cryptographic security protocols and algorithms used to encrypt the traffic payload. You can use the default value or define the value.
• IPsec profile: The FlexVPN parameters are consolidated into a single profile that is applied to the interface.
Note
For the SVPN 300-730 exam, it is very important to understand how the IKEv2 command-line interface constructs work.
FlexVPN Smart Defaults
Using the IKEv2 smart defaults is an easy way to use built-in attributes and streamline your configurations. The goal of smart defaults is to minimize the FlexVPN configuration. Note that the IKEv2 smart defaults (listed in Table 6-5) can be customized for different use cases. However, customization is not recommended. Instead, it would be better to create a new configuration block for a specific scenario than to customize a smart default.
Table 6-5 Smart Defaults
Router Smart Defaults
To see the smart defaults on a router, you can enter the command show crypto ikev2 proposal or show crypto ikev2 policy or show crypto ipsec transform-set and then show crypto ipsec profile. In addition to modifying the defaults, you can disable the defaults to prevent them from being exploited or used accidentally. You do this by issuing the command shown in Example 6-1. This command also reenables the default settings.
Example 6-1 Smart Defaults
No Crypto ikev2 proposal default To return the default Default Crypto ikev2 proposal
FlexVPN Design Considerations
Now that you understand the components associated with a FlexVPN deployment, next you must establish a goal for the solution. Just like with the last two site-to-site VPN technology topics, you first need to understand what business problems you are going to solve. Once you have determined the goal, you can work back from the goal to the solution. This will be the third chapter that covers this concept, and therefore will shorten the focus. Know that the steps for designing a VPN solution are similar regardless of the technology being used.
FlexVPN Planning
For any VPN technology, including FlexVPN, you must consider the objectives for the technology, what available technologies can be used, and possible problems as planning occurs. FlexVPN allows for a few unique considerations, including involving smart defaults and use of its modular framework. If legacy support is needed, FlexVPN can work unless the technology only supports IKEv1, which is not supported by FlexVPN. FlexVPN also offers both site-to-site and remote access VPN capabilities, which make it a good choice when both technologies are needed. Other considerations are similar to planning recommendations for DMVPN and GETVPN, including considering routing requirements, IP blocks, traffic filtering, and what applications will be supported. See Chapters 4 and 5 for more questions and considerations when planning a VPN solution. The same general questions will apply regardless of the VPN technology used. This includes fault tolerance considerations.
Key FlexVPN Consideration
One best practice covered in the last two chapters is creating a design on paper first. We recommend sharing your design with your peers to validate and assess the design before moving forward with any deployment. The following are some of the many factors that should be documented and discussed before an implementation. You fill find this list to be similar to the one used in the last two chapters.
• IOS requirements
• Platform capabilities (and upgrade options)
• IP address scheme: IPv4, IPv6, or both
• Tunnel addresses
• Remote access and site-to-site
• External (public) addresses
• Routing requirements
• Authentication method: RSA signature, PKI, or pre-shared key
• Encryption scheme
• Deployment strategy
• Application requirements
Now that we have covered the necessary ingredients and design considerations for using FlexVPN, we are ready to move into learning how to deploy FlexVPN technology. We first start with a walkthrough of building a hub-and-spoke FlexVPN deployment.
FlexVPN Implementation: Hub-and-Spoke (IPv4/IPv6)
The SVPN 300-730 exam blueprint highlights FlexVPN hub-and-spoke as one of its key learning objectives. Therefore, the implementation part of this chapter will focus on hub-and-spoke configuration and setup. To keep things simple and to help you understand the differences and similarities between FlexVPN and DMVPN, this chapter uses the same solution used in Chapter 5. Figure 6-5 (for IPv4) and Figure 6-6 (for IPv6) show the core IP addressing solution used throughout this section.
Figure 6-5 IPv4 FlexVPN Solution
Figure 6-6 IPv6 FlexVPN Solution
This section shows how to configure FlexVPN hub-and-spoke for both IPv4 and IPv6. Where the IPv6 configuration differs from the IPv4 configuration, this section provides separate examples for the two protocols. In these examples, the names in IPv6-specific examples have v6 added at the end. For example, whereas the IPv4 local pool is named SpokePool, the IPv6 local pool is named SpokePoolv6.
Hub-and-Spoke Configuration Summary
To make the FlexVPN hub-and-spoke configuration easy to digest and understand, this section follows the building block approach shown in Figure 6-4 and breaks down the process into four steps:
Step 1. IKEv2 proposal and IKEv2 policy configuration
Step 2. IKEv2 authorization policy configuration
Step 3. Keyring and IKEv2 profile configuration
Step 4. IPsec profile configuration
As shown in Figure 6-7, this section uses steps to group the parts of the configuration process together to make the whole process more intuitive. The following sections illustrate the configuration using these steps, and later in this chapter, you will see how to troubleshoot the configuration using the same steps.
Figure 6-7 FlexVPN Building Blocks Configuration Flow
Step 1: IKEv2 Proposal and IKEv2 Policy Configuration
The configuration steps in this section start with using the defaults that are built into FlexVPN and show an example of a proposal attached to a policy. Figure 6-8 shows the two FlexVPN building blocks configured in this section, both of which have defaults associated with them.
Figure 6-8 IKEv2 Profile and Policy Configuration
FlexVPN IKEv2 Proposal
Example 6-2 shows how to create a custom IKEv2 proposal with options that deviate from the defaults.
Note
The IKEv2 proposal and IKEv2 policy building blocks are optional. Depending on your organization’s security policy, however, these building blocks may be required pieces of your configuration.
Example 6-2 FlexVPN Building Blocks
crypto ikev2 proposal Hub-Proposal encryption aes-cbc-256 group 15 integrity sah256 prf sha256
Figure 6-9 shows the execution of the command show crypto ikev2 proposal, whose output displays the default proposal included with FlexVPN. Compare this output with the proposal created in Example 6-2. The default configuration includes several options, but you can override them and even remove them.
Figure 6-9 FlexVPN Default IKEv2 Proposal
Example 6-3 shows how to build a basic IKEv2 policy on a hub router. This example shows the IKEv2 policy block with the proposal from Example 6-2 attached. Remember that this configuration is optional.
Example 6-3 FlexVPN IKEv2 Policy
HQ-Router(config)# crypto ikev2 policy Hub-Policy1 HQ-Router(config-ikev2-policy)# proposal Hub-Proposal
Figure 6-10 shows the default policy included on a FlexVPN-capable router.
Figure 6-10 FlexVPN IKEv2 Default Policy
When you define an IKEv2 proposal and IKEv2 policy, the peer must match. We show this in Figure 6-7 with the arrow pointing at the IKEv2 policy box that indicates this is where another peer must have a matching proposal and policy.
FlexVPN Transform Set
Another optional configuration component in the FlexVPN building block model is the transform set. Cisco routers include a default version, which you can use to keep the configuration simple. However, you can also configure the transform set yourself.
Example 6-4 shows a simple example of setting a custom transform set named Flex-Transform. Like the IKEv2 policy and proposal, the configuration of the transform set is also optional.
Example 6-4 Crypto IPsec Transform Set
crypto ipsec transform-set Flex-Transform esp-aes 192 esp-sha256-hmac
Step 2: IKEv2 Authorization Policy Configuration
This section explores the configuration of the IKEv2 authorization components for a FlexVPN hub-and-spoke solution. First, you need to configure authentication, authorization, and accounting (AAA) on the router. AAA is used to (at a minimum) authenticate the remote spoke’s access to the FlexVPN server. The router acts as a server because it has the capability to push the configuration features down to the spoke route. The authorization policy on the hub router needs to include a pool to provide IP addresses to the spoke router.
AAA
Figure 6-11 shows that the AAA, IP pool, and ACL configurations inside the IKEv2 authorization are attached to the IKEv2 profile. In addition, for security purposes, you can use a standard access control list (ACL) to control access to the spokes with the IPv4 or IPv6 routes that they can reach.
Figure 6-11 IKEv2 Authorization Policy Configuration
Example 6-5 shows a configuration that first enables AAA with the command aaa new-model and then creates an AAA authentication string for supporting the spokes to authenticate against the local database.
Example 6-5 AAA Authentication
HQ-Router(config)# aaa new-model HQ-Router(config)# aaa authentication network SpokeAuth local
Hub Pool
Examples 6-6 (IPv4) and 6-7 (IPv6) show the creation of a local IP pool so that when spoke routers authenticate to the FlexVPN server, they are able to successfully pull an IP address for the tunnel interface. You will see later in this chapter that the FlexVPN server or, as in this case, the HQ router, can role out IP addresses similar to how a DHCP server would.
Example 6-6 Hub IPv4 Pool
HQ-Router(config)# ip local pool SpokePool 10.50.50.2 10.50.50.254
Example 6-7 Hub IPv6 Pool
HQ-Router(config)# ipv6 local pool SpokePoolv6 2001:db8:BEEF:1::2/112 128
ACL Permitting Traffic
The configuration in Example 6-8 (IPv4) or Example 6-9 (IPv6) is necessary for the router to advertise to the spoke routers what routes are available on the hub side. That is, it enables the router to show what traffic should be encapsulated through the VPN tunnel. In this case, the network 10.1.1.0/24 is located on the HQ side, so the spoke sending traffic destined for that IP address block passes through the tunnel.
Example 6-8 Hub Standard IPv4 ACL
HQ-Router(config)# ip access-list standard HQTraffic HQ-Router(config-std-acl)# permit 10.1.1.0 0.0.0.255
Example 6-9 shows a configuration that advertises the IP block 2001:db8::/32 to all remote devices.
Example 6-9 Hub Standard IPv6 ACL
HQ-Router(config)# ipv6 access-list HQTrafficv6 HQ-Router(config-ipv6-acl)# permit 2001:db8::/32 any
Attach to Authorization Policy
After you create the minimum AAA authorization policy and IP pool information needed for the spoke to authenticate and obtain an IP address on the tunnel interface, you need to attach both of these to the IKEv2 authorization policy. Example 6-10 shows the IPv4 pool address that is assigned to the spoke’s tunnel interfaces after authentication and the access list used for spoke route table injection.
Example 6-10 IPv4 IKEv2 Authorization Policy
HQ-Router(config)# crypto ikev2 authorization policy SpokePolicy HQ-Router(config-ikev2-author-policy)# pool SpokePool HQ-Router(config-ikev2-author-policy)# route set interface HQ-Router(config-ikev2-author-policy)# route set access-list HQTraffic
Example 6-11 shows the IPv6 configuration, which is identical to the IPv4 configuration except that it references IPv6-specific configuration pieces.
Example 6-11 IPv6 IKEv2 Authorization Policy
HQ-Router(config)# crypto ikev2 authorization policy SpokePolicyv6 HQ-Router(config-ikev2-author-policy)# pool SpokePoolv6 HQ-Router(config-ikev2-author-policy)# route set interface HQ-Router(config-ikev2-author-policy)# route set access-list HQTrafficv6
Step 3: Keyring and IKEv2 Profile Configuration
Next, you need to configure the keyring on the hub router as shown in Figure 6-12. The keyring is for mutual authentication between the spoke and the hub router. There is IKEv2 documentation that refers to the spoke as the responder and the hub router as the initiator, which is a good way to look at things to help remember which does what. This section shows the keyring and IKEv2 profile configuration for both IPv4 and IPv6.
Figure 6-12 IKEv2 Keyring and Profile
Keyring
Example 6-12 (IPv4) and Example 6-13 (IPv6) show the configurations necessary to create a keyring building block that supports authentication for both sides. With IPv4, the use of address 0.0.0.0 0.0.0.0 allows any peer to match this keyring. Notice that with IPv6, the address ::/0 defines all addresses. You need to define a pre-shared key for each side because the keys defined on the two sides do not have to be the same. In addition, one keyring can represent multiple spokes or hosts connecting to the hub because the name under the keyword peer defines that peer match. So, you could have another peer match called peer remote under the same keyring for AnyConnect authentication.
Example 6-12 IPv4 Keyring Configuration
HQ-Router(config)# crypto ikev2 keyring HUB-KR HQ-Router(config-ikev2-keyring)# peer Spokes HQ-Router(config-ikev2-keyring)# address 0.0.0.0 0.0.0.0 HQ-Router(config-ikev2-keyring)# pre-shared-key local cisco HQ-Router(config-ikev2-keyring)# pre-shared-key remote cisco
Example 6-13 IPv6 Keyring Configuration
HQ-Router(config)# crypto ikev2 keyring HUB-KRv6 HQ-Router(config-ikev2-keyring)# peer Spokesv6 HQ-Router(config-ikev2-keyring)# address ::/0 HQ-Router(config-ikev2-keyring)# pre-shared-key local cisco HQ-Router(config-ikev2-keyring)# pre-shared-key remote cisco
IKEv2 Profile
Example 6-14 (IP4) and Example 6-15 (IPv6) show how to create an IKEv2 profile and attach to it components such as the AAA authorization policy (refer to Example 6-10) and the keyring (refer to Example 6-12). The aaa authorization group psk command indicates what authorization will take place when the spoke connects to the hub router. In this example, it says to use the AAA local database on the router and then provides the spoke with that specific policy (SpokePolicy).
Example 6-14 IPv4 IKEv2 Profile
HQ-Router(config)# crypto ikev2 profile Hub-Profile HQ-Router(config-ikev2-profile)# match identity remote address 0.0.0.0 HQ-Router(config-ikev2-profile)# match identity remote fqdn domain lab.com HQ-Router(config-ikev2-profile)# identity local address 192.0.2.3 HQ-Router(config-ikev2-profile)# keyring local Hub-KR HQ-Router(config-ikev2-profile)# authentication remote pre-share HQ-Router(config-ikev2-profile)# authentication local pre-share HQ-Router(config-ikev2-profile)# aaa authorization group psk SpokeAuth SpokePolicy HQ-Router(config-ikev2-profile)# virtual-template 1
Example 6-15 IPv6 IKEv2 Profile
HQ-Router(config)# crypto ikev2 profile Hub-Profilev6 HQ-Router(config-ikev2-profile)# match identity remote address ::/0 HQ-Router(config-ikev2-profile)# match identity remote fqdn domain lab.com HQ-Router(config-ikev2-profile)# identity local address 2001:db8:AAAA:1::1 HQ-Router(config-ikev2-profile)# keyring local Hub-KRv6 HQ-Router(config-ikev2-profile)# authentication remote pre-share HQ-Router(config-ikev2-profile)# authentication local pre-share HQ-Router(config-ikev2-profile)# aaa authorization group psk SpokeAuth SpokePolicyv6 HQ-Router(config-ikev2-profile)# virtual-template 1
Step 4: IPsec Profile Configuration
You are nearing the end of the hub router configuration steps. Figure 6-13 shows that now, in the fourth step, you need to attach the IKEv2 profile from Example 6-14 or 6-15 to the IPsec profile. In this section, you will see how to use the default transform set rather than create a custom one. Know when using FlexVPN, you have the options for using the default or custom transform set.
Figure 6-13 IPsec Profile Configuration
Example 6-16 (IPv4) and Example 6-17 (IPv6) show how to attach the IKEv2 profile to the IPsec profile.
Example 6-16 IPv4 IPsec Profile
HQ-Router(config)# crypto ipsec profile Hub-IPsec-Profile HQ-Router(config-profile)# set ikev2-profile Hub-Profile
Example 6-17 IPv6 IPsec Profile
HQ-Router(config)# crypto ipsec profile Hub-IPsec-Profile HQ-Router(config-profile)# set ikev2-profile Hub-Profilev6
Create Loopback Address
Example 6-18 (IPv4) and Example 6-19 (IPv6) show how to create a loopback address on the FlexVPN server (hub) router for use by the GRE tunnel interface. In this case, the IPv4/IPv6 pool you use will be the same IP address subnet block you created for the hub spoke pool. This means that when a spoke router authenticates, it will request its IPv4 or IPv6 address from SpokePool (which for IPv4 will be 10.50.50.2 through 10.50.50.254) or SpokePoolv6 and apply it to the GRE tunnel interface.
Example 6-18 IPv4 Loopback
HQ-Router(config)# Interface Loopback 0 HQ-Router(config-if)# ip address 10.50.50.1 255.255.255.255
Example 6-19 IPv6 Loopback
HQ-Router(config)# Interface Loopback 0 HQ-Router(config-if)# ipv6 address 2001:db8:BEEF:1::1/112
Virtual Template
Example 6-20 (IPv4) and Example 6-21 (IPv6) show how to create a virtual template and attach the IPsec profile. Notice that you reference the loopback address for the IP address that will be used by the GRE tunnel interface.
Example 6-20 IPv4 Virtual Template
HQ-Router(config)# interface virtual-template 1 type tunnel HQ-Router(config-if)# ip unnumbered loopback 0 HQ-Router(config-if)# tunnel source G0/0 HQ-Router(config-if)# tunnel protection ipsec profile Hub-IPsec-Profile
Example 6-21 IPv6 Virtual Template
HQ-Router(config)# interface virtual-template 1 type tunnel HQ-Router(config-if)# ipv6 unnumbered loopback 0 HQ-Router(config-if)# tunnel source G0/0 HQ-Router(config-if)# tunnel mode gre ipv6 HQ-Router(config-if)# tunnel protection ipsec profile Hub-IPsec-Profile
Pre-shared IKEv2 Keyring
If the local or remote authentication method is a pre-shared key, you need to configure keys in the peer configuration sub mode that defines a peer subblock. An IKEv2 keyring can have multiple peer subblocks. A peer subblock contains a single symmetric or asymmetric key pair for a peer or peer group identified by any combination of the hostname, identity, and IP address. IKEv2 keyrings are independent of IVEv1 keyrings.
FlexVPN Spoke Configuration
This section does not cover the built-in default FlexVPN spoke components. Rather, we will focus on the critical configuration steps you need to take when configuring your FlexVPN spokes.
Spoke AAA Configuration
First, you need to enable AAA and AAA authentication as shown in Example 6-22.
Example 6-22 Spoke AAA Configuration
Spoke1(config)# aaa new-model Spoke1(config)# aaa authentication network FlexAuth local
Spoke Access List
The next step is necessary for the spoke router to advertise to the routes that are available on the spoke side. Basically, you need the router to indicate what traffic should be encapsulated through the VPN tunnel to reach the spoke side, which is network 10.2.2.0/24 for this example. Examples 6-23 and 6-24 show IPv4 and IPv6 examples.
Example 6-23 IPv4 Spoke Access List
Spoke1(config)# ip access-list standard SpokeTraffic Spoke1(config-std-naacl)# permit 10.2.2.0 0.0.0.255
Example 6-24 IPv6 Spoke Access List
Spoke1(config)# ipv6 access-list SpokeTrafficv6 Spoke1(config-ipv6-acl)# permit 2001:db8:BBBB:2::0/64 any
Spoke Keyring
Example 6-25 (IPv4) and Example 6-26 (IPv6) show how to create the keyring building block needed by the spoke for authentication using a pre-shared key.
Example 6-25 IPv4 Spoke Keyring
Spoke1(config)# crypto ikev2 keyring Spoke-KR Spoke1(config-ikev2-keyring)# peer Hub Spoke1(config-ikev2-keyring)# address 192.0.2.3 Spoke1(config-ikev2-keyring)# pre-shared-key local cisco Spoke1(config-ikev2-keyring)# pre-shared-key remote cisco
Example 6-26 IPv6 Spoke Keyring
Spoke1(config)# crypto ikev2 keyring Spoke-KRv6 Spoke1(config-ikev2-keyring)# peer Hub Spoke1(config-ikev2-keyring)# address 2001:db8:AAAA:1::1 Spoke1(config-ikev2-keyring)# pre-shared-key local cisco Spoke1(config-ikev2-keyring)# pre-shared-key remote cisco
In FlexVPN, configuration works in both directions. That is, the hub router pushes information about its networks to the spoke, and the spoke pushes information about its local networks to the hub. Another solution might be for HQ-Router to use certificates for authentication and for the spoke routers to use pre-shared keys. Keep this concept in mind for the exam.
Spoke Authorization Policy
Example 6-27 shows how to configure the IKEv2 authorization policy on the spoke to send the route information specified in the Spoketraffic access list for IPv4.
Example 6-27 IPv4 Spoke IKEv2 Authorization Policy
Spoke1(config)# crypto ikev2 authorization policy SpokePolicy Spoke1(config-ikev2-author-policy)# route set interface Spoke1(config-ikev2-author-policy)# route set access-list Spoketraffic
Example 6-28 shows how to configure the IKEv2 authorization policy on the spoke to send the route information specified in the Spoketrafficv6 access list for IPv6.
Example 6-28 IPv6 Spoke IKEv2 Authorization Policy
Spoke1(config)# crypto ikev2 authorization policy SpokePolicyv6 Spoke1(config-ikev2-author-policy)# route set interface Spoke1(config-ikev2-author-policy)# route set access-list Spoketrafficv6
Spoke IKEv2 Profile
Example 6-29 (IPv4) and Example 6-30 (IPv6) show how to configure an IKEv2 spoke profile attach it to the local keyring. The aaa authorization command calls the AAA group FlexAuth with the authorization policy from Example 6-27 (SpokePolicy) or Example 6-28 (SpokePolicyv6).
Example 6-29 IPv4 Spoke IKEv2 Profile
Spoke1(config)# crypto ikev2 profile Spoke-Profile Spoke1(config-ikev2-profile)# match identity remote address 192.0.2.3 Spoke1(config-ikev2-profile)# identity local address 209.165.201.2 Spoke1(config-ikev2-profile)# authentication remote pre-share Spoke1(config-ikev2-profile)# authentication local pre-share Spoke1(config-ikev2-profile)# keyring local Spoke-KR Spoke1(config-ikev2-profile)# aaa authorization group psk list FlexAuth SpokePolicy
Example 6-30 IPv6 Spoke IKEv2 Profile
Spoke1(config)# crypto ikev2 profile Spoke-Profilev6 Spoke1(config-ikev2-profile)# match identity remote address 2001:db8:AAAA:1::1 Spoke1(config-ikev2-profile)# identity local address 2001:db8:BBBB:2::2 Spoke1(config-ikev2-profile)# authentication remote pre-share Spoke1(config-ikev2-profile)# authentication local pre-share Spoke1(config-ikev2-profile)# keyring local Spoke-KRv6 Spoke1(config-ikev2-profile)# aaa authorization group psk list FlexAuth SpokePolicyv6
Spoke IPsec Profile
Example 6-31 (IPv4) and Example 6-32 (IPv6) show how to create an IPsec profile.
Example 6-31 IPv4 Spoke IPsec Profile
Spoke1(config)# crypto ipsec profile Spoke-IPsec-Profile Spoke(ipsec-profile)# set ikev2-profile Spoke-Profile
Example 6-32 IPv6 Spoke IPsec Profile
Spoke1(config)# crypto ipsec profile Spoke-IPsec-Profile Spoke(ipsec-profile)# set ikev2-profile Spoke-Profilev6
Spoke Tunnel Interface
Example 6-33 (IPv4) and Example 6-34 (IPv6) show how to create the tunnel interface where you attach the IPsec profile.
Example 6-33 IPv4 Spoke Tunnel Interface
Spoke1(config)# Interface tunnel 0 Spoke1(config-if)# ip address negotiated Spoke1(config-if)# tunnel source GigabitEthernet0/0 Spoke1(config-if)# tunnel destination 192.0.2.3 Spoke1(config-if)# tunnel protection ipsec profile Spoke-IPsec-Profile
Example 6-34 IPv6 Spoke Tunnel Interface
Spoke1(config)# interface Tunnel 0 Spoke1(config-if)# ip address negotiated Spoke1(config-if)# tunnel source GigabitEthernet0/0 Spoke1(config-if)# tunnel destination 2001:db8:AAAA:1::1 Spoke1(config-if)# tunnel protection ipsec profile Spoke-IPsec-Profile
The configuration for the hub router and spoke router is now complete. When you enable the tunnel interface on the spoke router and the virtual template on the hub router, you should see the routers initializing IKEv2 and attempting to authenticate. Later in this chapter, you will see how to troubleshoot this configuration using the same four-action process used in this section.
Next, let’s look at a spoke-to-spoke Flex VPN deployment.
FlexVPN Implementation: Spoke-to-Spoke (IPv4/IPv6)
This section discusses how to implement FlexVPN spoke-to-spoke communication. Since we already covered how to build a hub-and-spoke FlexVPN configuration, now you just need to add NHRP so that the spokes can communicate directly with each other. With FlexVPN, NHRP plays a similar role to the one it plays with DMVPN. With shortcut switching (spoke-to-spoke tunnels), the spoke routers are able to use a dynamic virtual tunnel interface (dVTI) for communication. The spokes will have a main tunnel interface that communicates with the hub and a dynamic virtual interface that will be enabled when traffic must transit between the two spokes directly.
Note
When the FlexVPN virtual tunnel is up and running and tunnels are established from the spoke to the hub router, you can no longer make changes to the hub router’s virtual tunnel configuration.
Figure 6-14 shows what the network will look like when the spoke-to-spoke configuration is complete. Notice the flow of the NHRP messages and the shortcut switching established between the two spoke routers over the VTI.
Figure 6-14 FlexVPN Spoke-to-Spoke Solution
FlexVPN NHRP
Example 6-35 shows how to configure the hub router with NHRP. It is important to note two things about the two new lines on the virtual template (highlighted in this example): The network ID must be consistent across the FlexVPN network, and the hub router is the only router that will have the redirect option. NHRP enables the spoke to forward the spoke resolution to another spoke and send back the redirect information to the spoke that initiated the request. This NHRP redirect information informs the spoke of the other spoke’s information.
Note that the same configuration is used for both IPv4 and IPv6.
Example 6-35 Hub Router NHRP for Spoke-to-Spoke Communications
HQ-Router(config)# interface virtual-template 1 type tunnel HQ-Router(config-XXX)# ip unnumbered Loopback0 HQ-Router(config-XXX)# tunnel source GigabitEthernet0/0 HQ-Router(config-XXX)# tunnel protection ipsec profile Hub-IPsec-Profile HQ-Router(config-xxx)# ip nhrp network-id 1 HQ-Router(config-xxx)# ip nhrp redirect
FlexVPN Spoke-to-Spoke Spoke Router
The configuration for the spoke router in the spoke-to-spoke shortcut scenario is a little more complex. It resembles what you did in Chapter 5 when traffic has to traverse the hub. However, on the spoke you need to create a second virtual interface by using the interface virtual-template type tunnel command so that the dVTI will clone the tunnel that leads back to the hub. To do so, you need to follow these steps:
Step 1. Add a new keyring for spoke-to-spoke communication.
Step 2. Adjust the IKEv2 profile.
Step 3. Add NHRP commands to the tunnel interface.
Step 4. Create a virtual template tunnel.
Spoke-to-Spoke Keyring
Example 6-36 (IPv4) and Example 6-37 (IPv6) show how to add on to your existing keyring and create a new one for spoke-to-spoke authentication. Note that this example shows how to create a separate keyring for clarity and ease of understanding the configuration.
Example 6-36 IPv4 Spoke Keyring Addition
Spoke1(config)# crypto ikev2 keyring S2S-KR Spoke1(config-ikev2-keyring)# peer Spokes Spoke1(config-ikev2-keyring)# address 0.0.0.0 0.0.0.0 Spoke1(config-ikev2-keyring)# pre-shared-key local cisco Spoke1(config-ikev2-keyring)# pre-shared-key remote cisco
Example 6-37 IPv6 Spoke Keyring Addition
Spoke1(config)# crypto ikev2 keyring S2S-KRv6 Spoke1(config-ikev2-keyring)# peer Spokes Spoke1(config-ikev2-keyring)# address ::/0 Spoke1(config-ikev2-keyring)# pre-shared-key local cisco Spoke1(config-ikev2-keyring)# pre-shared-key remote cisco
Spoke-to-Spoke Route Injection
Example 6-38 and (IPv4) and Example 6-39 (IPv6) show how to solve the routing issue so that spokes are able to resolve the other remote locations’ IP blocks by changing the access list HQTraffic to add a static route on both spokes of 10.0.0.0/8 for IPv4 or 2001:db8::/32 for IPv6. Note that although we include this step, most implementations solve the IP connectivity issue with a routing protocol rather than trying to maintain an access list with routes.
Example 6-38 IPv4 Hub-to-Spoke Route Injection
HQ-Router(config)# ip access-list standard HQTraffic HQ-Router(config-std-nacl)# permit 10.0.0.0 0.255.255.255
Example 6-39 IPv6 Hub-to-Spoke Route Injection
HQ-Router(config)# ipv6 access-list HQTrafficv6 HQ-Router(config-ipv6-acl)# permit 2001:db8::/32 any
Spoke-to-Spoke IKEv2 Profile
Example 6-40 (IPv4) and Example 6-41 (IPv6) show how to create a new IKEv2 profile for the spoke-to-spoke authentication. This configuration differs from the one created for hub communication because it includes the virtual-Template command. This site-to-site profile needs to be replicated at each spoke that needs to communicate; alternatively, an any match can be used.
This example in this section has only have two remote sites, so the configuration is straightforward. Notice that Examples 6-40 and 6-41 call the keyring you created for the other spoke and uses the same aaa authorization group command as used in the hub-and-spoke solution (refer to Figure 6-11 and Example 6-5).
Example 6-40 IPv4 Spoke IKEv2 Profile
Spoke1(config)# crypto ikev2 profile S2S-Profile Spoke1(config-ikev2-profile)# match identity remote address 209.165.202.130 255.255.255.255 Spoke1(config-ikev2-profile)# identity local address 209.165.201.2 Spoke1(config-ikev2-profile)# authentication remote pre-share Spoke1(config-ikev2-profile)# authentication local pre-share Spoke1(config-ikev2-profile)# keyring local S2S-KR Spoke1(oncifg-ikev2-profile)# aaa Authorization group psk list FlexAuth Policy Spoke1(config-ikev2-profile)# virtual-Tempate 1
Example 6-41 IPv6 Spoke IKEv2 Profile
Spoke1(config)# crypto ikev2 profile S2S-Profilev6 Spoke1(config-ikev2-profile)# match identity remote address 2001:db8:db8:CCCC:2::2/128 Spoke1(config-ikev2-profile)# identity local address 2001:db8:BBBB:2::2 Spoke1(config-ikev2-profile)# authentication remote pre-share Spoke1(config-ikev2-profile)# authentication local pre-share Spoke1(config-ikev2-profile)# keyring local S2S-KRv6 Spoke1(oncifg-ikev2-profile)# aaa authorization group psk list FlexAuth Policyv6 Spoke1(config-ikev2-profile)# virtual-Tempate 1
Spoke-to-Spoke Add NHRP
Example 6-42 (which works for both IPv4 and IPv6) is where things start to get interesting. You need to add to the tunnel interface (Tunnel 0 in our example) to the NHRP network ID so the hub router knows you are part of the same NHRP network. In addition, the ip nhrp shortcut virtual-template command supports the setup of the IPsec tunnel between spokes. However, this setup happens only when interesting traffic forces the NHRP resolution process.
Example 6-42 NHRP Added to the Spoke Tunnel Interface
Spoke1(config)# interface tunnel 0 Spoke1(config-if)# ip address negotiated Spoke1(config-if)# tunnel source GigabitEthernet0/0 Spoke1(config-if)# tunnel destination 192.0.2.3 Spoke1(config-if)# ip nhrp network-id 1 Spoke1(config-if)# ip nhrp shortcut virtual-template 1 Spoke1(config-if)# tunnel protection ipsec profile Spoke-IPsec-Profile
Spoke-to-Spoke Virtual Template
Example 6-43 (IPv4) and Example 6-44 (IPv6) demonstrate the addition of a virtual template for spoke-to-spoke communication. This template is initialized only when interesting traffic triggers the tunnel. The trigger happens as a result of routing or access list matching. Notice that the IPv6 requires an additional command to enable the GRE tunnel to run over an IPv6 network layer and transport IPv6 packets.
Example 6-43 IPv4 Virtual Template for Spoke-to-Spoke Tunnel Communication
Spoke1(config)# interface Virtual-Template1 type tunnel Spoke1(config-if)# ip unnumbered Tunnel0 Spoke1(config-if)# ip nhrp network-id 1 Spoke1(config-if)# ip nhrp shortcut virtual-template 1 Spoke1(config-if)# tunnel protection ipsec profile Spoke-IPsec-Profile
Example 6-44 IPv6 Virtual Template for Spoke-to-Spoke Tunnel Communication
Spoke1(config)# Interface Virtual-Template1 type tunnel Spoke1(config-if)# ip unnumbered Tunnel0 Spoke1(config-if)# ip nhrp network-id 1 Spoke1(config-if)# ip nhrp shortcut virtual-template 1 Spoke1(config-if)# tunnel mode gre ipv6 Spoke1(config-if)# Tunnel protection ipsec profile Spoke-IPsec-Profile
We do not cover routing in this section of the chapter because we have already seen that the IKEv2 authorization policy calling the access list HQTraffic results in a summary route being sent to the remote FlexVPN spokes. The authorization policy inserts the summary route into the routing tables of both spokes. Because the two sites’ IP address blocks are in that summary (refer to Examples 6-38 and 6-39), they can communicate directly by way of NHRP resolution through the hub via redirection to cause one of the spokes to initiate the tunnel between the two sites. Figure 6-15 shows the routing table on the spoke router; notice that it has the summary address 10.0.0.0/8, pointing to the tunnel interface.
Figure 6-15 Showing the IPv4 Route on Spoke1
Note
The configuration of the IKEv2 authorization policy on the hub router allows the push of simple networks or the ones listed in the access list. To enable full functionality, dynamic routing needs to be configured on a FlexVPN network.
That wraps up how to configure both a hub-and-spoke and a spoke-to-spoke FlexVPN deployment. Make sure you are familiar with these steps before taking on the SVPN exam.
Our final topic for this chapter is a review of how to validate and troubleshoot your existing FlexVPN deployment.
FlexVPN Troubleshooting
With FlexVPN, troubleshooting can be very complex, especially when you have a combination of VPN solutions using a single hub. For example, if you are mixing remote access, legacy crypto map hosts, and a hub-and-spoke solution on the same hub router, troubleshooting can be extremely challenging. This chapter limits the configuration to a hub-and-spoke solution with additional capability for spoke-to-spoke communication. For the SVPN exam, you will likely see a FlexVPN configuration that targets one type of deployment, but real-world deployments can be much more complex!
The best way to troubleshoot FlexVPN is to use the blocks from the building block model we have used in the last few chapters to determine where the challenge is. Table 6-6 shows the building blocks on the left and the commands that can be used with each building block on the right. This format follows each section as an action.
Table 6-6 Key FlexVPN Troubleshooting Commands
Connectivity Troubleshooting
From the spoke router, you must determine whether the Tunnel0 interface has an IP address or if the VPN tunnel is up and running. If the interface does not have an IP address, you can proceed to determine what part of the configuration is not working correctly. For example, you can check on the spoke router to see if any Syslog messages are evident. Can you ping the hub’s outside IP address from the spoke router? If not, you know you have a basic routing problem. If you can ping that address, then you probably need to determine whether IKEv2 is set up correctly. Figure 6-16 shows a successful ping of the hub router from the spoke that validates connectivity.
Figure 6-16 Pinging the Hub’s IP Address
Figure 6-17 shows how to check that the tunnel has an IP address and that it is from the hub route pool. In this case, you can see that Spoke1 or R2 got an IP address from the SpokePool. As shown in Example 6-6, the SpokePool IPv4 configuration range is 10.50.50.2 through 10.50.50.254.
Figure 6-17 Spoke Router IP Address Assignment
Step 1: IKEv2 Proposal and IKEv2 Policy Troubleshooting
If you have determined that IKEv2 is not working, you need to look at the IKEv2 proposal and IKEv2 policy, using the commands show crypto ikev2 proposal and show crypto ikev2 policy. You need to make sure that, if you are not using the defaults, the proposal is attached to the policy. Figure 6-18 and Figure 6-19 show default configuration examples. However, the defaults still demonstrate that the proposal is attached to the policy and that the policy matches any local address.
Figure 6-18 show crypto ikev2 proposal Command and Output
Figure 6-19 show crypto ikev2 policy Command and Output
IKEv2 Debugging
If you cannot determine the issue, then another possible solution is to turn on debugging for IKEv2 with the command debug crypto ikev2 error. This will help you determine where IKEv2 is failing. Maybe the issue is that the IKEv2 authorization policy is not defined correctly, or perhaps the match address is not correct; to identify either case, you need to use the command debug crypto ikev2 error.
Step 2: IKEv2 Authorization Policy Troubleshooting
If a spoke is unable to get an IP address for the tunnel interface or a route is not in the table, you need to determine whether the IKEv2 authorization policy (that is, the one on the hub router) is misconfigured. Notice in Figure 6-20 that SpokePool is the IPv4 pool used for tunnel, and HQTraffic is the ACL for route injection. You need to validate that they actually exist on the hub router. If you use the debug ikev2 command and the configuration information is incorrect, the command identifies the problem. This command can also let you know if the configuration information is missing or the remote spokes get the wrong IP or route injection.
Figure 6-20 show crypto ikev2 authorization policy Command and Output
Step 3: Keyring and IKEv2 Profile Troubleshooting
You can troubleshoot the keyring and the IKEv2 profile by using one command. However, you might have to also use the show run command to verify the keyring settings or at least validate them against the other router’s keyring configuration. The command show crypto ikev2 profile in Figure 6-21 provides some key information for troubleshooting. For example, it shows whether you are using the keyring (Hub-KR) or pre-shared authentication. It also includes the identities and the AAA information.
Figure 6-21 show crypto ikev2 profile Command and Output
Step 4: IPsec Profile Troubleshooting
Troubleshooting IPsec for FlexVPN is basically the same as troubleshooting DMVPN (refer to Chapter 5). The command show crypto ipsec sa is probably the first place to start your IPsec troubleshooting. You can also use the command debug ipsec to see what that output tells you. The command show crypto ipsec profile provides a wealth of information and one that can be helpful for troubleshooting IPsec. Figure 6-22 shows that the output provides the profile name and the name of the transform set that is being used. Keep in mind that you need to validate that the profiles on the hub and spoke are in alignment.
Figure 6-22 show crypto ipsec profile Command and Output
As shown in Figure 6-23, the command show crypto ikev2 session displays a concise summary of the tunnels. It is similar to show crypto ipsec sa but with fewer details.
Figure 6-23 show crypto ikev2 session Command and Output
NHRP Troubleshooting
If your configuration requires spoke-to-spoke capabilities, you need to understand NHRP resolution and how to troubleshoot this part of the configuration. This section includes the commands you need for this troubleshooting. Make sure to know these commands for the SVPN exam.
The command shown in Figure 6-24 was executed from the spoke router. Note that this command is not included in Table 6-6 because it is only found in spoke-to-spoke communication. As you can see, the spoke (R2) uses NHRP to resolve 10.50.50.3 information and map its outside address, 209.165.202.130.
Figure 6-24 show ip nhrp detail Command and Output
Figure 6-25 indicates that interesting traffic initiated the tunnel, and R2 brought up the Virtual-Access interface to establish a VPN tunnel to R3. This output comes from using the command show crypto ipsec sa. The Virtual-Access interface would not exist without NHRP resolving the information about the other spoke.
Figure 6-25 Spoke1 Virtual-Access Interface
Figure 6-26 shows the command debug nhrp packet executed on a spoke router. It shows the resolution process diagramed in Figure 6-14, where by the spoke sends the NHRP resolution request to the hub via the Tunnel0 interface for destination 10.3.3.1. The hub router sends the redirect message back to the spoke via the Tunnel0 interface. The information included in the redirect message is src NMBA 209.165.202.130 and src 10.50.50.3. So now the spoke knows to establish a VPN tunnel to 10.50.50.3 and use a Virtual-Access interface.
Figure 6-26 debug nhrp packet Output
That wraps up key commands and concepts you need to know for troubleshooting FlexVPN deployments.
Summary
In this chapter we introduced FlexVPN technology, including the extensive benefits of FlexVPN capabilities. We covered learning objectives included on the SVPN 300-730 exam such as hub-and-spoke and spoke-to-spoke configuration. As you learned in this chapter, FlexVPN supports remote connectivity clients such as AnyConnect. Like the previous chapters, we used a building block model as the roadmap for configuration and troubleshooting success. Make sure to master both hub-and-spoke as well as spoke-to-spoke deployments and troubleshooting before attempting the SVPN exam.
At this point, we have covered all of the site-to-site VPN topics needed to meet the learning objectives of the SVPN exam. The final site-to-site VPN topic that needs to be covered before we move into remote access VPN concepts is troubleshooting, which makes up the largest learning objective on the SVPN exam. Make sure you have a firm understanding of IPsec, DMVPN, and FlexVPN before moving to the next chapter.
References
FlexVPN IPv6 in Hub and Spoke Deployment Configuration Example. Retrieved from https://www.cisco.com/c/en/us/support/docs/security/flexvpn/116528-config-flexvpn-00.html
Good general info DMVPN vs FlexVPN. Retrieved from https://packetpushers.net/cisco-flexvpn-dmvpn-high-level-design/?doing_wp_cron=1589135866.2408781051635742187500
Great troubleshooting and good example. Retrieved from https://integratingit.wordpress.com/2016/07/10/configuring-cisco-flexvpn-hub-and-spoke/
Introduction to FlexVPN. Retrieved from https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/15-mt/sec-flex-vpn-15-mt-book.pdf
Troubleshooting FlexVPN. Retrieved from https://www.cisco.com/c/en/us/support/docs/security/flexvpn/116032-flexvpn-aaa-config-example-00.html
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 11, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.
Review All Key Topics
Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 6-7 lists these key topics and the page number on which each is found.
Table 6-7 Key Topics for Chapter 6
Complete Tables and Lists from Memory
Print a copy of Appendix C, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix D, “Memory Tables Answer Key” (also on the companion website), includes completed tables and lists to check your work.
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
Internet Key Exchange Version 2 (IKEv2)
Extensible Authentication Protocol (EAP)