Chapter 4. Group Encrypted Transport VPN (GETVPN)
This chapter covers the following subjects:
• GETVPN Overview: This section provides an overview of how GETVPN uses a single security association to encrypt traffic between group members.
• GETVPN Components: This section examines the building blocks of GETVPN and how they work together to create a unique solution for either MPLS or a private IP network.
• GETVPN Implementation and Configuration: This section steps through the components of a GETVPN configuration. Examples demonstrate how the GETVPN building blocks work on a key server and on a group member.
“Passwords are like underwear: you don’t let people see it, you should change it very often, and you shouldn’t share it with strangers.”
—Chris Pirillo
This chapter covers the following exam objectives:
• 1.0 Site-to-site Virtual Private Networks on Routers and Firewalls
• 1.1 Describe GETVPN
• 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
Group Encrypted Transport VPN, more commonly referred to as GETVPN, provides a solution for tunnel-less, any-to-any and confidential branch communications. GETVPN leverages the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. GETVPN uses the concept of group members, where group members share a common security association, commonly referred to as an SA. Using this approach, GETVPN enables group members to encrypt and decrypt traffic with any other group member using the same SA. This eliminates the need to negotiate point-to-point IPsec tunnels between members of the group and associated overhead.
The Implementing Secure Solutions with Virtual Private Networks (SVPN) 300-730 exam expects you to be able to describe the functional components of GETVPN, recognize GETVPN technology, and identify troubleshooting problems within a GETVPN deployment. After reviewing this chapter, you will be able to accomplish the following:
• Describe GETVPN
• Identify functional components of GETVPN solutions
• GETVPN Configuration and Implementation
• GETVPN Status Commands
Learning beyond the SVPN concepts
• GETVPN Fundamental Concepts
• GETVPN Design Considerations
“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 4-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 4-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
1. What are the key benefits of GETVPN over traditional VPN solutions for enterprise organizations? (Choose two.)
a. It enables instant IP communication, thanks to IPsec.
b. An overlay routing protocol is required.
c. Any-to-any IP communication is possible.
d. It is a tunnel-based solution.
2. Why is GETVPN not used over a public network such as the Internet? (Choose two.)
a. Unchanged IP header
b. IP header encryption
c. RFC 1918 IP address requirement
d. Lack of support for NAT
3. Which protocol in GETVPN is responsible for securing the control plane communications?
a. IPsec
b. GDOI
c. KEK
d. ISAKMP
4. What are the primary components of GETVPN? (Choose three.)
a. GDOI protocol
b. IKEv2 protocol
c. Key server
d. Group member
5. Which GETVPN component is responsible for sending out encryption keys?
a. GDOI protocol
b. IKEv2 protocol
c. Key server
d. Group member
6. In the GDOI protocol, which of the following is responsible for sending out the new key to group members?
a. TEK
b. ISAKMP
c. IPsec
d. KEK
7. For which component would it be vital to have a redundant solution?
a. GDOI
b. KEK
c. Key server
d. Group member
8. Which component would require an RSA private key?
a. Group member
b. Key server
c. None
d. Both
9. In a GETVPN solution, which component is responsible for establishing the IPsec encryption policy?
a. Group member
b. Key server
c. GDOI
d. All of the above
10. On a group member router, where is the group identity specified?
a. IKE policy
b. GDOI group
c. Transform set
d. Crypto map
Foundation Topics
VPN technology has been adapted to fit a wide set of solutions, and Group Encrypted Transport VPN (GETVPN) is a perfect example of a unique environment that dictated an unusual set of requirements on an existing technology. Organizations typically use GETVPN to encrypt traffic across private network solutions such as Multiprotocol Label Switching (MPLS) networks. Typically, a service providers MPLS network carries traffic from numerous other enterprise organizations, and GETVPN ensures confidentiality across that network. Before we get into the specifics of GETVPN, we need to look at why this particular VPN implementation was developed.
Today, enterprise customers require instantaneous branch-to-branch and branch-to-main office communication for a wide variety of applications, such as voice over IP, video, and other delay-sensitive applications. Because some of these applications, such as video, involve high-bandwidth traffic, the traditional hub-and-spoke solutions do not suffice for branch-to-branch communications. MPLS was designed to address the enterprise need for both high speed and bandwidth capacity.
MPLS Security Challenges
MPLS provides the services that enterprises need while meeting and exceeding application bandwidth and speed requirements. However, there is a security challenge related to data confidentiality and integrity. If service providers are intermixing your enterprise traffic across the same platforms as other organizations, what assurances do you have that your traffic is secure? GETVPN was created to ensure that organizations could meet government regulations such as the Health Insurance Portability and Accountability Act (HIPPA), Gramm-Leach-Bliley Act (GLBA), and Payment Card Industry Data Security Standard (PCI-DSS). Even if your traffic is on a private IP network run and managed by the service provider, you still should consider your organization’s security needs to ensure that your network maintains government-mandated encryption.
Figure 4-1 illustrates a service provider MPLS network with two organizations using that infrastructure for communication. The dotted line indicates the VPN encryption used by each company. Company A and Company B will not see each other’s traffic, especially if they are using a GETVPN solution. Even in the event of a service provider configuration error, GETVPN will provide confidentiality.
Figure 4-1 GETVPN MPLS Service Provider View
Technically, it is possible to run solutions such as a site-to-site VPN or a Dynamic Multipoint VPN (DMVPN) solution over an MPLS network, but such solutions introduce limitations. For example, both site-to-site VPN and DMVPN solutions introduce administrative overhead in the form of configuration complexity as well as resource overhead due to the large number of security associations. The larger the MPLS network grows, the more impactful these limitations become. As another example, site-to-site VPN solutions suffer from multicast replication issues. These can be solved with DMVPN; however, this requires overlaying a secondary routing domain into the infrastructure to ensure that the spoke endpoints can locate each other.
Figure 4-2 provides an example of an MPLS solution for a four-site organization with private IP addresses used on the inside and also by the service provider. We do not get into the specifics of MPLS tagging in this chapter, but it is safe to say that one of the advantages of the service provider MPLS solution is that the IP address routing, configuration, and infrastructure management can be shifted to a service provider. There are numerous other benefits, such as not needing to use Network Address Translation (NAT). To the company, the MPLS network is just a private IP transport being managed by another organization.
Figure 4-2 GETVPN Corporate Solution
GETVPN Overview
GETVPN has a unique way of solving the challenge that other VPN solutions face in managing a large number of security associations (SAs). In typical site-to-site VPN solutions, each VPN tunnel adds one or more SAs. The more VPN tunnels, the more SAs that are created. In comparison, GETVPN uses a single SA for all the group members. Using a single SA eliminates hub-and-spoke solutions and partial mesh configurations. However, just because you have a single SA does not mean your security posture is weakened, because there are security enhancements that address these concerns. As shown in Figure 4-3, the GETVPN protocol Group Domain of Interpretation (GDOI) establishes the SA between the group members—in this case, Site A, Site B, and Site C. With a single SA, traffic from Site B can flow to Site C or Site A without delay and with encryption.
Figure 4-3 GETVPN Security Association Trust Groups and Tunneless VPN
GETVPN also introduces the concept of a trusted group. Each VPN router in a trusted group trusts the other routers in the group and can send traffic between itself and any member of the group. Because all group members share a common SA, this results in two distinct important advantages for GETVPN:
• Any group member can decrypt traffic that was encrypted by any other group member.
• Tunnel negotiation is not required because GETVPN is a non-tunnel-based solution.
GDOI Protocol
How does GETVPN achieve encryption without VPN tunnels between the locations? The answer lies in the use of the GDOI protocol. RFC 6407, which describes GDOI, states that “GDOI provides group key management to support secure group communications.” While other VPN solutions discussed in this book use Internet Key Exchange (IKE) to negotiate SAs; GETVPN uses GDOI to manage the group SA with the IPsec protocol stack used to encrypt the payload between the communicating devices.
In a traditional IPsec solution with ESP, the sender encrypts the entire IP payload and then wraps another new IP datagram around it in order to deliver it to the decrypting device. With GETVPN, the router encrypts the payload and then transmits the IP datagram with the original source and destination IP addresses. Because there is no outer wrapper on the IP datagram, a tunnel between the devices is not necessary; GETVPN is therefore referred to as a tunnel-less solution. Figure 4-4 compares an IP header for a traditional IPsec site-to-site VPN and an IP header for GETVPN.
Figure 4-4 GETVPN IP Packet Comparison
Figure 4-5 shows an IP packet traveling from host 10.2.2.10 to 10.3.3.50. The new IP header added is a copy of the original header generated by the host. The group member receiving the encrypted payload has the key to decrypt the IP packet before forwarding on to its final destination.
Figure 4-5 GETVPN Packet
Because GETVPN does not create VPN tunnels between sites and the original IP datagrams are left intact, this solution creates a unique challenge. Basically, GETVPN does not work in NAT environments. Therefore, this type of solution is rarely used across public networks, such as the Internet. GETVPN is ideally suited for either an MPLS network or a private IP network. Private IP network implementations can be found in large enterprises and government entities.
GETVPN Benefit Summary
Some of the general benefits from using GETVPN are as follows:
• Multicast infrastructure solutions do not require an overlay solution to replicate multicast traffic between multiple sites (see Chapter 5, “Dynamic Multipoint Virtual Private Network (DMVPN)”).
• No overlay routing protocol is required.
• GETVPN supports large-scale deployments and instant any-to-any IP communication with IPsec.
• Because the original IP source and destination are preserved, GETVPN integrates well with end-to-end QoS solutions. In addition, you have more intermediate control over your IP payloads, so optimal and efficient routing for both unicast and multicast traffic can be achieved.
• GETVPN supports both IKEv1 and IKEv2.
GETVPN Components
Before you can dive into GETVPN configuration, you first must understand how the various components of GETVPN work together so that device-to-device communication is secured. This section covers the role of the key server and the group member. It also discusses how devices communicate and encrypt payloads. Finally, this section addresses why group members communicate with key servers and what information they exchange.
Figure 4-6 provides an overview of the components involved in a GETVPN. This figure shows only one key server and three group members. We use this example throughout the chapter to help you form a conceptual understanding and for a detailed configuration example. First, let’s review how the key server works within GETVPN.
Figure 4-6 GETVPN Components
GETVPN Key Server
GETVPN has three primary components: the key server, the group member, and the GDOI protocol. Throughout the rest of this section, we look at each of these topics, as well as how IPsec functions in a GETVPN solution.
The key server is the most critical device in a GETVPN solution. The following are minimal components that should be configured on a key server:
• IKE policy
• RSA key for rekeying
• IPsec policies
• Traffic classification
The key server is responsible for registering the group members and sending out encryption keys. In addition, the key server is responsible for the rekeying process that occurs periodically. A key server cannot be a group member, and you need only one key server. The key server uses the GDOI protocol to communicate with the group members. Upon initialization, a group member registers with the key server by using either use a pre-shared key or certification (PKI). Once a group member is authorized, it retrieves the policy configuration and the two keys used for communication with other group members. Key servers are responsible for maintaining the SA policy, authenticating group members, and providing session keys for encrypting/decrypting traffic. When a group member tries to register with the key server, the key server checks a the group ID and IKE credentials.
Policy configuration for group members occurs in the key server. This policy configuration includes the crypto ACL, encryption protocols, rekeying timers, and security association information. Besides the policy information, the key server provided two keys to group members: the key encryption key (KEK) and the traffic encryption key (TEK). The KEK protects control plane communications, such as the rekeying process, and the TEK is responsible for payload encryption between group members. TEK supports the IPsec SA that all group members use to encrypt and decrypt payloads.
GETVPN Group Member
A group member requires minimal configuration because both the policy and SA information are retrieved from the key server. During registration, the group member provides the group ID to get the policy and keys. A group member is a VPN router that is a member of a GDOI group and can encrypt traffic being sent to any other group member since they all use the same IPsec SA. A fault tolerance concern would be having a single key server. It is possible to configure multiple key servers—up to eight of them for each group. A group member registers to one of the key servers, and the key server then replicates that information to the primary key server. The primary key server is responsible for maintaining the database of all registered group members and for the rekeying synchronization process.
GETVPN GDOI Protocol
The GDOI protocol, which is specified in IETF standard RFC 6407, is used as the communication mechanism between key servers and group members in a VPN. It is protected by ISAKMP Phase 1, which is the same method used in other IPsec site-to-site tunnels. Phase 1 IKE protects the Phase 2 exchange in which the members pull down the SA from the key server. The KEK is used when the key server pushes out a new key to group members. The key server can use multicast to push out the keys or notify them of the rekeying. The multicast feature enables GETVPN to scale and support a large number of group members. The key server sends out the rekeying information prior to the SA expiration time in order to ensure that the group members have the new key. Later in this chapter, you will see the unicast method of rekeying selected in a configuration example.
GETVPN Security Controls
GETVPN has some unique security controls that are different from what you see in site-to-site VPNs, DMVPN, or FlexVPN. As mentioned earlier, the KEK is responsible for control plane protection between the group members and the key server. How do you secure the data plane communication if all group members use the same SA and key? The TEK is responsible for the data plane security through encryption of the communication payloads between the group members.
Three security controls are unique to GETVPN:
• Rekeying
• Time-Based Anti-Replay (TBAR)
• IP-Delivery Delay Detection Protocol (IP-D3P)
Rekeying
Rekeying, which is configured in the key server, is a policy that is pushed out to the group members and facilitated by the KEK. Before the existing key expires, a new key is generated, and then the group members are notified to transition to the new key. This is the base security control to prevent an attacker from learning the SA key, which changes at a configured frequency.
TBAR
Traditional IPsec solutions do not share a common SA, and because GETVPN has a group SA, you need a mechanism to prevent anti-replay. This is achieved through Time-Based Anti-Replay (TBAR), which is a pseudo-time clock established for the group and managed by the key server. The key server keeps the pseudo-time synchronized via rekeying updates. When a packet arrives, the group member compares the pseudo-timestamp referenced in the packet with the synchronized time, and if the packet arrived too late, the group member drops the packet.
IP-D3P
IP-Delivery Delay Detection Protocol (IP-D3P) is designed to address IP delivery delay attacks. In this type of attack, which is similar to a replay attack, a packet that is not fresh (that is, not recently generated) is sent to a host or router. The IP-D3P datagram includes a header and an IP payload plus a timestamp that the receiver can use to compare to the local time. If the timestamp of the packet is outside the accepted window, the packet is not accepted. This setting, like the other security settings, is set at the key server and is part of the GDOI configuration parameters. This feature must be enabled.
Note
IP-D3P is an interoperability feature, which means that the Cisco IOS software and GDOI versions must be the same.
Now that we have covered the components and general concepts behind GETVPN, you are ready to start planning out what your GETVPN architecture could look like. This brings us to the design considerations you should be thinking about when developing a GETVPN solution.
GETVPN Design Considerations
Before you jump into configuring a GETVPN network, it is critical that you first establish a goal for the solution. Essentially, you need to determine what business problems you are aiming to solve. You will find that this recommendation will carry forward with any deployment you choose to use and a best practice that will be in future chapters.
This section considers common GETVPN design challenges and issues you need to think about as you develop your GETVPN architecture. You need to think about what value and limitations hardware will have. You need to think about whether GETVPN is the best option or whether another deployment option is better. You need to think about what your current investments are and whether they could be leveraged versus having to acquire new technology. All of this can impact how the design will look, including considerations for post deployment hurdles such as managing the solution and user/administration training.
GETVPN Fault Tolerance Considerations
One additional design consideration that will be echoed in future chapters is considerations for high availability/fault tolerance. These terms are used interchangeably throughout this book because both have the same end goals, and both terms are often used. The SVPN exam will likely have only a small number of questions involving fault tolerance, so coverage in this book is limited; however, real-world deployments will surely include some form of fault tolerance if budget allows. Budget is the key factor because we find that is the most common limitation for why a real-world deployment would not include fault tolerance.
Chapter 3 includes a section on high availability/fault tolerance. Those fundamental concepts apply to any form of VPN. To summarize, options can include active or passive configurations to share load or push load to another system if it's a primary system. Options can include redundant hardware that is powered on and ready or powered off and available to fire up if an event occurs. Options can purely be configuration-based, meaning if a fault is found, the deployment will reroute traffic another way to accommodate the loss of system or connection. The focus for every chapter moving forward in regard to fault tolerance is specific to the chapter’s focus. Moving forward, know that the general fault tolerance/high availability concepts covered in Chapter 3 apply to any deployment and must be part of your deployment considerations.
Key GETVPN Considerations
It is a good idea to create a design on paper first and then share it with your peers to validate and assess the design. We repeat this approach in future chapters of this book because this best practice applies to GETVPN as well as to any VPN topic covered.
The following are some of the many factors that should be documented and discussed before an implementation:
• IOS requirements
• Platform capabilities (and upgrade options)
• IP address scheme: IPv4, IPv6, or both
• Tunnel addresses
• External (public) addresses
• GETVPN key server and group members
• Routing requirements
• Authentication method: RSA signature, PKI, or pre-shared key
• Encryption scheme
• Deployment strategy
• Application requirements
GETVPN Implementation and Configuration
This next section covers the basics of configuring a GETVPN solution and how to configure both a key server and a group member. This section does not cover IKEv2 configuration for GETVPN because that protocol is discussed in detail in Chapter 6, “FlexVPN Configuration and Troubleshooting.” Furthermore, the configuration examples in this section do not include an MPLS network; for the sake of simplicity, they include a private IP network.
Figure 4-7 shows the building blocks needed for a key server and a group member. As you can see, there are basically three distinct configuration blocks: ISAKMP configuration, IPsec configuration, and GDOI group creation. In the following configuration example, you will see these building block pieces laid out.
Figure 4-7 GETVPN Basic Requirements
The GETVPN IP network consists of three group member routers and one key server. Each router provides VPN interconnection to the other routers, thus creating a VPN core IP network. As you can see in Figure 4-8, this example has an internal IP block at each of the three locations 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16, and the outside IP addresses are mandated by the private IP network. In this example, the routers are using a 172.16.x.0 address block for the outside, or private, network interface. The GETVPN identifier is the group member number, which in this case is 5. The key server defines both the GDOI information and the SA used by the group member routers. Figure 4-8 shows the topology and IP addresses used for the following key server and group member configuration examples.
Figure 4-8 GETVPN Topology
Configuring a Key Server
You set up the key server by building out the IKE policy that the key server will use and that the group members will need. The group members will have identical IKE policies. Next, the key server sets the IPsec transform policy, which will be downloaded by the group member. Finally, the GDOI protocol information needs to be established. This is where the SA information for the routers that are part of the GDOI network is defined and where the rekeying parameters are established by the key server. Figure 4-9 shows the pieces necessary for key server configuration.
Figure 4-9 GETVPN Key Server Configuration Requirements
IKE Phase 1 Policy
Example 4-1 shows the base IKE phase 1 policy configuration. With GETVPN, authentication is handled either through pre-shared key (PSK) or public key infrastructure (PKI). For simplicity, this example uses PSK for authentication.
Example 4-1 The GETVPN Key Server IKE Phase 1 Policy
KS1(config)# crypto isakmp policy 1 KS1(config-isakmp)# encryption aes 128 KS1(config-isakmp)# hash sha256 KS1(config-isakmp)# group 14 KS1(config-isakmp)# lifetime 3600 KS1(config-isakmp)# authentication pre-share
Key Server PSK Authentication
Because the configuration in Example 4-1 calls for PSK authentication, the commands in Example 4-2 are required for each group member to have a key specified on the key server.
Example 4-2 The GETVPN Key Server PSK Authentication
KS1(config)# crypto isakmp key cisco address 172.16.10.2 KS1(config)# crypto isakmp key cisco address 172.16.20.2 KS1(config)# crypto isakmp key cisco address 172.16.30.2
IKE Phase 2 Policy
Example 4-3 establishes the IPsec transform used between all the group members and the lifetime before the security associate expires and must be reauthenticated. In Figure 4-7, this is the IPsec information that each group member uses to secure the traffic between sites during communication.
Example 4-3 The GETVPN Key Server IKE Phase 2 Policy
KS1(config)# crypto ipsec transform-set Group5-Transform esp-aes esp-sha-hmac KS1(cfg-crypto-trans)# crypto ipsec profile Profile1 KS1(ipsec-profile)# set security-association lifetime seconds 7200 KS1(ipsec-profile)# set transform-set Group5-Transform
Key Server RSA Key
The configuration in Example 4-4 ensures that the key server has a certificate for signing rekeying messages for the group members. This component of the configuration is critical because the key server must be able to encrypt the TEK and KEK used by the group members.
Example 4-4 The Key Server RSA Key
KS1(config)# crypto key generate rsa general-keys label GETKEYS mod 2048 export
Key Server GDOI
Example 4-5 shows how to configure the GDOI group number and identity used by the routers in the SA.
Example 4-5 The Key Server GDOI
KS1(config)# crypto gdoi group Group5 KS1(config-gkm-group)# identity number 555 KS1(config-gkm-group)# server local
Unicast Rekeying Parameters
Example 4-6 shows a continuation of the GDOI group configuration and defines the rekeying method that group members must use. In this example, the key server establishes the rekeying method, which is unicast (as opposed to multicast). In addition, this example specifies the RSA certificate that will be used for the encryption.
Example 4-6 Key Server Unicast Rekeying Parameters
KS1(gkm-local-server)# rekey transport unicast
KS1(gkm-local-server)# rekey lifetime seconds 86400
KS1(gkm-local-server)# rekey retransmit 10 number 2
KS1(gkm-local-server)# rekey authentication mypubkey rsa GETKEYS
KS1(gkm-local-server)# address ipv4 172.16.5.5
Example 4-7 is a continuation of the GDOI configuration parameters, as you can see from the router prompt (gkm-local-server). This prompt indicates that you are configuring GDOI key server parameters on the local server. This is where you configure the access list used by the group members to determine what is encrypted between sites—in this case, basically all 10.0.0.0 through 10.3.0.0 traffic.
Example 4-7 Key Server Unicast Rekeying Parameters
KS1(gkm-local-server)# sa ipsec 1
KS1(gkm-sa-ipsec)# profile Profile1
KS1(gkm-sa-ipsec)# match address ipv4 101
KS1(gkm-sa-ipsec)# replay counter window-size 5
Key Server Policy Access List
Example 4-8 configures the access list required for the solution in Figure 4-6. The key server must inform the group members what IP packets will need to be encrypted between the sites. A routing solution is still required between the sites.
Example 4-8 Key Server Policy Access List Download
KS1(config)# access-list 101 permit ip 10.0.0.0 0.3.255.255 10.0.0.0 0.3.255.255
Configuring Group Members
The configuration of group members is much simpler than the configuration of the key server. Notice in Figure 4-10 that the first two building blocks are identical to the key server configuration. The GDOI parameters are taken from the key server distribution, but you must specify the key server you need to synchronize with, and you might have a secondary key server for redundancy. Finally, unlike in the key server configuration, the group members need to establish and attach the IPsec policy to the router’s outside interface.
Figure 4-10 GETVPN Group Member Configuration Requirements
Group Member IKE Phase 1 Policy
Example 4-9 shows the base IKE Phase 1 policy configuration used by both the key server and all the group member routers. Notice that pre-shared key authentication is defined, as it was on the key server.
Example 4-9 GETVPN Key Server IKE Phase 1 Policy
GM1(config)# crypto isakmp policy 1 GM1(config-isakmp)# encryption aes 128 GM1(config-isakmp)# hash sha256 GM1(config-isakmp)# group 14 GM1(config-isakmp)# lifetime 3600 GM1(config-isakmp)# authentication pre-share
Group Member PSK Authentication
Example 4-10 shows the pre-shared authentication information required by the key server to protect Phase 1 negotiation. In this example, you must specify not only the other group members but the key server because in order to share the GDOI policy, you must make sure to share it securely. The security for this is provided by ISAKMP.
Example 4-10 GETVPN Key Server PSK Authentication
GM1(config)# crypto isakmp key cisco address 172.16.5.5 GM1(config)# crypto isakmp key cisco address 172.16.20.2 GM1(config)# crypto isakmp key cisco address 172.16.30.2
Group Member GDOI Information
Example 4-11 shows the GDOI group member information required. The group identity and key server IP address are specified in this part of the configuration.
Example 4-11 Group Member GDOI Information
GM1(config)# crypto gdoi group Group5 GM1(config-gkm-group)# identity number 555 GM1(config-gkm-group)# server address ipv4 172.16.5.5
Crypto Maps
Example 4-12 shows the creation of a crypto map for the GDOI protocol and specification of the group member number that you will attempt to use to register with the key server.
Example 4-12 Establishing a Crypto Map
GM1(config)# crypto map GVPN-Map 10 gdoi GM1(config-crypto-map)# set group Group5
Finally, Example 4-13 shows how to apply the crypto map to the group member routers’ outside interface.
Example 4-13 Applying a Crypto Map to an Interface
GM1(config)# interface GigabitEthernet0/2 GM1(config-if)# ip address 172.16.10.2 255.255.255.0 GM1(config-if)# crypto map GVPN-Map
That covers all the steps regarding delivering a generic GETVPN deployment. Make sure you understand each step involved so you can recognize GETVPN configuration exam questions and be able to speak about the components as well as what purpose they serve. Next, let’s look at how to validate the status of your new or existing GETVPN deployment.
GETVPN Status Commands
The final topic to cover is how to validate whether things are working within your GETVPN deployment. You can do this using different show commands, and you will want to know what the output looks like for each command before taking the SVPN exam. This will help answer questions testing you on recognizing a GETVPN as well as troubleshooting potential problems. Figure 4-11 shows the output of the key server status and parameters. The identity Group 5 is listed, and the IP-D3P security feature is disabled.
Figure 4-11 show crypto gdoi ks Output
Figure 4-12 shows the output on the key server group information and parameters. This would be particularly useful if the key server were supporting multiple group identities. This configuration can be used on the group member as well as on the key server. The command lists more detail about GDOI, such as the rekeying status, which could be useful for troubleshooting. In addition, the output shows whether this solution is configured for IPv4 (as in this case) or IPv6.
Figure 4-12 show crypto gdoi group group5 Output
Figure 4-13 shows a list of the group members that have registered. In this example, you see only two registrations, but there were actually three members. The display output has been shortened because the third group member registration did not add additional value.
Figure 4-13 show crypto gdoi ks members Output
Figure 4-14 demonstrates the concept of KEK versus TEK. The output shows that KEK uses the RSA signature key name GETKEYS. With TEK policy, the transform for payload encapsulation is identified, and the access list is used to decide which packets are encapsulated and which are not.
Figure 4-14 show crypto gdoi ks policy Output
Group Member Show Commands
The following figures illustrate the use of key show commands from a group member’s perspective. In Figure 4-15, the output from the group member console shows some key information. First, it shows the start of the group member registration process to Group5 and the key server IP address 172.16.5.5. Next, it shows that the GDOI process is started, and Group5 is using unicast rekeying rather than multicast. Furthermore, you can see the KEK and TEK updated on the group member. Finally, the output shows the successful installation of the group member policy onto this particular member of Group5 SA.
Figure 4-15 Group Member Console Output
Figure 4-16 shows the output of the show crypto isakmp sa command and clearly demonstrates that GETVPN is different from other VPN solutions. You can see that the client state is GDOI_IDLE rather than QM_IDLE.
Figure 4-16 show crypto isakmp sa Output
In Figure 4-17, the output from the show crypto gdoi detail command provides validation of the group information (Group5), the group type, and the crypto path. Notice that the ACL has not been received because this group member is still registering (see Figure 4-18).
Figure 4-17 show crypto gdoi detail Output, Part 1
Figure 4-18 shows further output from show crypto gdoi detail. You can see the port on which GDOI communicates (848) as well as the IP address this member is using to register and the IP address of the key server. You can also see the rekeying cipher and rekeying hash. Each part of this output is a key to how GETVPN functions between the key server and group members and between group members.
Figure 4-18 show crypto gdoi detail Output, Part 2
Figure 4-19 shows a subset of the output from the command show crypto gdoi. It focuses on the two keys used by the key server: the KEK used to secure communication between the key server and group members and the TEK used to secure traffic between group members.
Figure 4-19 show crypto gdoi Output Subset
Figure 4-20 shows the output of the show crypto gdoi gm acl command. The interesting thing about this output is the ACL that was configured on the key server and downloaded by the group members; it shows what traffic will be encrypted between group members.
Figure 4-20 show crypto gdoi gm acl Output
GETVPN Status Commands Summary
Table 4-2 consolidates the key commands covered in this last section. The commands are organized in a list divided by running the command from either key server or group member. We highly recommend leveraging these commands during any deployment, and know their outputs and purposes for the SVPN exam.
Table 4-2 GETVPN Status Commands
That wraps up the steps in designing, configuring, and validating a GETVPN deployment. This last section focused on status validation, and many of these same commands can also be used for troubleshooting. In the next chapter, we focus on troubleshooting concepts, which will be similar for troubleshooting all forms of site-to-site VPN deployments.
Summary
This chapter introduced the Group Transport Encryption VPN (GETVPN) technology and its extensive benefits for enterprise environments using an MPLS or private network. This chapter covered a number of topics included on the SVPN 300-730 exam, such as GETVPN components and how GETVPN works. To give you a better understanding of how GETVPN works and the role of each of the components, this chapter provided a step-by-step configuration example. In addition, this chapter showed the basic components as organized building blocks that demonstrate the functions the configurations reviewed aim to achieve. This chapter also provided command output to link together the configuration building blocks and a successful solution.
Next up is a focus on DMVPN technology, followed by FlexVPN. GETVPN, DMVPN, and FlexVPN, making up the key site-to-site VPN topics you need to know for the SVPN exam.
References
GETVPN Deployment Guide. Retrieved from https://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html
Group Encrypted Transport VPN Configuration Guide. Retrieved from https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_getvpn/configuration/xe-3s/sec-get-vpn-xe-3s-book.pdf
Troubleshooting Common GETVPN Issues. Retrieved from https://www.cisco.com/c/en/us/support/docs/security/group-encrypted-transport-vpn/116958-troubleshoot-getvpn-00.html#anc14
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 4-3 lists these key topics and the page number on which each is found.
Table 4-3 Key Topics for Chapter 4
Complete Tables and Lists from Memory
There are no memory tables in this chapter.
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
Group Encrypted Transport VPN (GETVPN)
Multiprotocol Label Switching (MPLS)