Networked applications such as voice and video increase the need for instantaneous, branch-interconnected, and QoS-enabled WANs. The distributed nature of these applications results in increased demands for scale. At the same time, enterprise WAN technologies force businesses to trade off between QoS-enabled branch interconnectivity and transport security. As network security risks increase and regulatory compliance becomes essential, Group Encrypted Transport VPN (GET VPN), a WAN encryption technology, eliminates the need to compromise between network intelligence and data privacy.

With GET, Cisco provides tunnelless VPN, which eliminates the need for IPsec tunnels. By removing the need for point-to-point tunnels, meshed networks can scale higher while maintaining network-intelligence features critical to voice and video quality. GET is a standards-based security model that is based on the concept of a trusted group to eliminate point-to-point IPsec tunnels and their associated overlay routing. Trusted group members share a common security association (SA), also known as a group SA. This enables group members to decrypt traffic that was encrypted by any other group member. By using trusted groups instead of point-to-point tunnels, full-mesh networks can scale higher while maintaining network-intelligence features (such as QoS, routing, and multicast), which are critical to voice and video quality.

GET-based networks can be used in a variety of WAN environments, including IP and Multiprotocol Label Switching (MPLS). MPLS VPNs that use this encryption technology are highly scalable, manageable, and cost-effective, and they meet government-mandated encryption requirements. The flexible nature of GET allows security-conscious enterprises either to manage their own network security over a service provider WAN service or to offload encryption services to their providers. GET simplifies securing large Layer 2 or MPLS networks that require partial or full-mesh connectivity.

In addition to leveraging the existing IKE, IPsec and multicast technologies, a GET VPN topology includes these key elements and features:

• Group members—The routers that exchange the actual traffic within the VPN are called group members. Group members provide encryption services to the traffic. Encryption policies are defined centrally on the key server and downloaded to the group member at the time of registration. Based on these downloaded policies, a group member decides whether traffic needs to be encrypted or decrypted and what keys to use.

Although group members primarily obtain encryption policies from the key server, you can configure local service policy ACLs on the group members to exclude traffic from encryption based on local requirements. For more information, see Understanding the GET VPN Security Policy and Security Associations.

Note	A device can be a group member of more than one group.

• Key servers—The routers that act as key servers are the gatekeepers to the topology. The group member must successfully register with a key server before becoming an active member of the VPN. The key servers control the shared service policy, and generate and transmit keys to group members. Key servers cannot be group members themselves, but a single key server can service more than one topology. For more information, see Understanding the GET VPN Registration Process.

• The Group Domain of Interpretation (GDOI) group key management protocol is used to provide a set of cryptographic keys and policies to a group of devices. In a GET VPN network, GDOI is used to distribute common IPsec keys to a group of enterprise VPN gateways (group members) that must communicate securely. Devices designated as key servers periodically refresh and send out the updated keys to the group members using a process called “rekeying.”

The GDOI protocol uses the Phase 1 Internet Key Exchange (IKE) SA. All participating VPN gateways authenticate themselves to the device providing keys using IKE. All IKE authentication methods, for example, pre-shared keys (PSKs) and public key infrastructure (PKI), are supported for initial authentication. After the VPN gateways are authenticated and provided with the appropriate security keys using the IKE SA, the IKE SA expires and GDOI is used to update the group members in a more scalable and efficient manner. For more information about GDOI, refer to RFC 3547.

• Address preservation—IPsec-protected data packets carry the original source and destination in the outer IP header rather than replacing them with tunnel endpoint addresses. Address preservation allows GET VPN to use the routing functionality present within the core network. Address preservation allows routing to deliver the packets to any customer-edge (CE) device in the network that advertises a route to the destination address. Any source and destination matching the policy for the group will be treated in a similar manner. In the situation where a link between IPsec peers is not available, address preservation also helps combat traffic “black-hole” situations.

Header preservation also maintains routing continuity throughout the enterprise address space and in the WAN. As a result, end host addresses of the campus are exposed in the WAN (for MPLS, this applies to the edge of the WAN). For this reason, GET VPN is applicable only when the WAN network acts as a “private” network (for example, in an MPLS network).

The following figure shows the general operation of a GET VPN topology.

1. Group members register with the key server using the Group Domain of Interpretation (GDOI) protocol. The key server authenticates and authorizes the group members and downloads the IPsec policy and keys that are necessary for them to encrypt and decrypt IP multicast and unicast packets. The registration process can use unicast or multicast communications.

2. Group members exchange IP packets that are encrypted using IPsec. Only the group members are an active part of the VPN.

3. As needed, the key server pushes a rekey message to the group members. The rekey message contains new IPsec policy and keys to use when old IPsec security associations (SAs) expire. Rekey messages are sent in advance of the SA expiration time to ensure that valid group keys are always available.

GET VPN is provisioned using Security Manager with the following caveats:

• GET VPN-aware VRF is not supported.

• DMVPN with GET is not supported, because there is no way to define DMVPN without tunnel protection in Security Manager.

• Manual configuration of a group member to join a multicast group (ip igmp join-group) is not supported. Security Manager only provisions static source-specific multicast (SSM) mappings.

In GET VPN, group members comprise the VPN topology. Traffic in the VPN is traffic between group members. For a device to become a group member, the device must successfully register with a key server. Key servers maintain the security association (SA) policy and create and maintain the keys for the group. When a group member registers, the key server downloads the policy and the keys to the group member. The key server also rekeys the group before existing keys expire.

The key server has two responsibilities: servicing registration requests and sending rekeys. A group member can register at any time and receive the most current policy and keys. When a group member registers with the key server, the key server verifies the group ID that the group member is attempting to join. If the group ID is valid, the key server sends the security association policy to the group member. After the group member acknowledges that it can handle the downloaded policy, the key server downloads the respective keys.

Communication among the key server and group members is encrypted and secured using two types of keys: the traffic encryption key (TEK) and the key encryption key (KEK). The TEK is downloaded by the key server to all the group members. The downloaded TEK is used by all the group members to communicate securely among each other. This key is essentially the group key that is shared by all the group members. The group policies and IPsec SAs are refreshed by the key server using periodic rekey messages to the group members. The KEK is also downloaded by the key server and is used by the group members to decrypt the incoming rekey messages from the key server.

The key server sends out rekey messages either because of an impending IPsec SA expiration or because the security policy has changed on the key server. A rekey can also happen if the KEK timer has expired (the key server sends out a KEK rekey). Rekey messages might also be retransmitted periodically to account for possible packet loss. If the rekey mechanism is multicast, there is no efficient feedback mechanism by which receivers can indicate that they did not receive a rekey message, so retransmission seeks to bring all receivers up to date. If the rekey mechanism is unicast, the receivers send an acknowledgment message.

The key server generates the group policy and IPsec security associations (SAs) for the GDOI group. The information generated by the key server includes multiple TEK attributes, traffic encryption policy, lifetime, source and destination, a Security Parameter Index (SPI) ID that is associated with each TEK, and the rekey policy (one KEK). Note that the group member might also have a local security policy configured that is merged with the one downloaded; for complete information see Understanding the GET VPN Security Policy and Security Associations.

The following figure illustrates the communication flow between group members and the key server. The key server, after receiving registration messages from a group member, generates the information that contains the group policy and new IPsec SAs. The new IPsec SA is then downloaded to the group member. The key server maintains a table that contains the IP address of each group member per group. When a group member registers, the key server adds its IP address in its associated group table, thus allowing the key server to monitor an active group member. A key server can support multiple groups. A group member can be part of multiple groups.

When you configure the GET VPN topology, you can configure the following registration-related features:

• Decide whether to use unicast or multicast for group registration and rekeying. For more information, see Choosing the Rekey Transport Mechanism.

Note	If you use multicast, you need to enable multicast on the key servers and group members manually. Security Manager does not provision multicast commands.

• Decide whether to configure more than one key server to provide redundancy and load balancing. For more information, see Configuring Redundancy Using Cooperative Key Servers.

• Decide whether to configure fail-close mode on group members to protect their traffic prior to successful registration with the key server. For more information, see Configuring Fail-Close to Protect Registration Failures.

• Decide whether to require authorization for group members to join the group. You can use certificate authorization (which requires that you also configure the Public Key Infrastructure policy) or preshared keys. Configuring authorization is required if the key server serves more than one group. For information about the configuration options, see the Authorization Type setting described in Defining GET VPN Group Encryption.

GET VPN uses crypto map access control lists (ACLs) to identify the traffic that needs to be encrypted in the VPN. These ACLs also identify traffic that should be sent as clear text instead of being encrypted (essentially, traffic that lies outside of the VPN). The collection of these ACLs define the security policy for the VPN.

GET VPN provides a multi-layered security policy. You define the general policy for the entire VPN on the key server, but you can also define a separate security policy on group members to account for local variations. The group member security policy always takes priority over the policy received from the key server. When the group member registers with the key server, the group member downloads the key server’s security policy and associations and the group member creates a new, single security policy crypto map ACL by concatenating the individual security policies in this order: first, the group member’s ACL; second, the key server’s first ACL; third, and so forth, any additional ACLs from the key server in the order defined on the key server. It is important to understand that these merged ACLs are treated as a single ACL; they are not searched as separate ACLs. Thus, if traffic matches a deny statement from the group member’s ACL, that traffic is never tested against any ACL rules downloaded from the key server.

Tip	If a group member leaves the GET VPN, the ACLs downloaded from the key server are removed, but the group member security policy ACL is retained and remains configured on the device.

In GET VPN security policy ACLs (and crypto map ACLs in general), the permit and deny keywords have special meaning:

• Permit—Means “encrypt this traffic.” Permit entries are allowed only in the security policy ACLs defined on the key server (in the Group Encryption Policy), because encrypted traffic needs to have a full IPsec security association, which includes the transform set used for encrypting traffic, and anti-replay and IPsec lifetime configurations. If a packet matches a permit entry, but no IPsec SA exists for that packet, the packet is dropped.

Normally, your permit rules should be symmetric, that is, the source and destination addresses should be the same. If you need to specify different source and destination addresses, you must create two rules; the second rule should be a mirror image of the first rule, with the source and destination address switched.

• Deny—Means “do not encrypt this traffic.” In practice, this typically means that the traffic that matches the deny statement is sent in the clear. However, if you configure other features that use crypto maps, “denied” traffic is actually compared to subsequent (lower priority) crypto map ACLs to see if there is a match. IPsec security associations (SAs) are not generated for deny rules.

Following is a summary of the security policies that you can configure, in priority order:

• Group member security policy—When you configure the group member, as described in Configuring GET VPN Group Members, you can optionally select an ACL policy object that defines the local group member security policy.

This group member ACL policy object is allowed to have deny statements only. You use this ACL to identify any traffic that you want to exclude from encryption and send in the clear. For example, if a handful of group members in the group are running a different routing protocol than the usual one, you can configure a local entry to these group members’ security policy ACL to bypass encryption of the routing protocol traffic instead of defining the policy globally at the key server level.

• Key server security policies and security associations—When you configure the Group Encryption Policy for the GET VPN, as described in Defining GET VPN Group Encryption, you configure ACLs that identify the traffic that should be encrypted and protected in the VPN.

The security policies on the key server are coupled with transform sets and other settings to define security associations; two IPsec security associations (SAs) are actually configured for every rule within the ACL, and these SAs define how the selected traffic should be encrypted. Thus, all group members use the same group SAs and they do not need to negotiate them with each other.

Because the key server policy is appended to the group member policy, the policy might be as simple as permit ip any any, that is, encrypt all traffic that has not been excluded by the group member policy.

However, you can create more complex sets of security policies and associations, setting up several separate ACL policy objects that are coupled to different transform sets to define different types of encryption.

If you create more than one security association, you must identify their order, and they are appended to the group policy in that order. Remember, the end result is a single ACL, so if you include a deny statement in the first ACL, any permit rules for the same traffic in subsequent security associations are ignored, and the traffic is sent in clear text rather than being encrypted.

Note

When you consider the security associations defined in the Group Encryption Policy as a whole, you can define up to 100 ACL permit entries. Each permit entry results in a pair of IPsec SAs; the maximum number of IPsec SAs in a group can not exceed 200. It is a best practice to summarize interesting traffic to as few permit entries as possible, and to build symmetric policies, where the source and destination addresses are the same. Unlike traditional IPSec policies, where source and destination address ranges must be uniquely defined, GET VPN is optimized when the source and destination address range are the same. If you configure a rule that has different source and destination addresses, you must also configure the mirrored rule (where the source and destination address are flipped), meaning that four SAs are consumed.

In addition to these security policies, there is an additional fail-close ACL that influences traffic patterns if you configure fail-close mode on a group member. For a complete discussion, see Configuring Fail-Close to Protect Registration Failures.

To configure a full mesh VPN with group encrypted transport (GET), use the Create VPN wizard as described in Creating or Editing VPN Topologies. When you finish the wizard, you are asked if you want to synchronize RSA keys, which is required for normal VPN functioning; for detailed information, see Generating and Synchronizing RSA Keys.

If you select multicast as the rekey transport mechanism, you must enable multicast on all key servers and the desired group members. For more information, see Choosing the Rekey Transport Mechanism.

You can change only the name and description of a GET VPN using the Edit VPN wizard. If you need to make changes to other policies and settings, open the policies from the Site-to-Site Manager page, as follows:

• For ISAKMP and IPSec settings, select Global Settings for GET VPN. See Configuring Global Settings for GET VPN.

• For IKE proposal policies, select IKE Proposal Policy for GET VPN. See Configuring the IKE Proposal for GET VPN.

• For security associations (ACL rules) and IPSec policies, select Group Encryption Policy > Security Associations. See Defining GET VPN Group Encryption.

• For preshared key policies, select IKEv1 Preshared Key. See Configuring IKEv1 Preshared Key Policies.

• For public key (PKI) policies, select Public Key Infrastructure. See Configuring IKEv1 Public Key Infrastructure Policies in Site-to-Site VPNs.

• For rekey settings, select Group Encryption Policy > Group Settings. See Defining GET VPN Group Encryption and Generating and Synchronizing RSA Keys.

• For key server configuration, including RSA key synchronization, select Key Servers. See Configuring GET VPN Key Servers and Generating and Synchronizing RSA Keys.

• For group membership and endpoint settings, select Group Members. See Configuring GET VPN Group Members.

When you specify the RSA key label in the Group Encryption Policy (as described in Defining GET VPN Group Encryption, the corresponding RSA key (public and private keys) needs to be configured on all key servers in the GET VPN topology. The key can either be a pre-existing key that you defined on the device, or it could be a new key label, and Security Manager can generate the key for you and synchronize all key servers to use the same key.

You can use the following methods to have Security Manager generate and synchronize the RSA key:

• When creating a new GET VPN using the Create VPN wizard, you are asked at the end of the wizard if you want to synchronize the keys. If you click Yes, Security Manager does the key synchronization immediately, and generates a new key if the key does not already exist. For information on using the Create VPN wizard, see Creating or Editing VPN Topologies.

• For an existing GET VPN, you can click the Synchronize Keys button on the Key Servers policy. Use this process whenever you add key servers or generate a new key on the primary key server. For information on configuring key server settings for existing topologies, see Configuring GET VPN Key Servers.

Tip

For existing GET VPN topologies, if you want to generate a new RSA key, it might be easiest to update the Group Encryption Policy to specify a new, unused RSA key label, then click the Synchronize Keys button in the Key Servers policy. Because the key will not exist on any key server, Security Manager will generate the new key and import it into all key servers. You can then manually delete the old key from each key server.

Following are the uses for the RSA key:

• The key server uses the private RSA key to authenticate rekey messages from the group members.

• The key server provides the public RSA key to group members during registration.

• The key server uses the private key to sign the key encryption key (KEK) and traffic encryption key (TEK). The absence of an RSA key prevents the key server from creating the KEK and TEK.

• The RSA key is also used to sign messages between cooperative key servers.

When you start the RSA key synchronization process, the Synchronize Keys dialog box opens and shows you the overall progress as well as the results for each key server. (You can click the Abort button at any time to stop the process.) Security Manager performs the following steps:

1. Logs into all key servers and retrieves the RSA key information from each of them for the RSA key label configured for the VPN.

2. Determines whether any key server has a key with the required label:

   • If no key server has an RSA key with the required label, Security Manager generates the key on the primary key server (the one with the highest priority).

   • If one or more key server does not have the key, but all of the key servers that do have the key have the identical keys, Security Manager uses the existing key on any key server that has it.

   • If more than one key server has the key, but the contents of the key is different among the servers, you are asked if Security Manager can overwrite the keys. If you click Yes, Security Manager uses the existing key on the primary key server.

If you click No, you can log into the key servers outside of Security Manager and manually adjust the keys according to your requirements. However, all key servers must have the same key contents for the RSA key. See below for an explanation of the process.

1. Creates an exportable version of the key.

2. Imports the key into each of the remaining key servers.

Tip

For the synchronization process to succeed, the devices must be online and reachable and you must have Deploy authorization. If the device connection fails or times out, ensure that you can ping the key server from the Security Manager server. If it is your practice to deploy to file instead of to live devices, you might need to manually generate and synchronize the keys as described below. If you do not have sufficient authorization, you are prevented from initiating the process; someone else must do it.

Use the IKE Proposal for GET VPN page to define the IKE proposal to be used by the GET VPN topology. The IKE proposal is configured on the key servers and the group members.

These settings are for the ISAKMP security association (SA). If you are using a single key server, the ISAKMP SA is not used after initial group member registration. If you are using more than one key server (cooperative key servers), the ISAKMP SA is needed for communications among the key servers.

To open the IKE Proposal for GET VPN page:

• (Site-to-Site VPN Manager Window) Select an existing GET VPN topology and then select IKE Proposal for GET VPN in the Policies selector.

• (Policy view) Select Site-to-Site VPN > IKE Proposal for GET VPN, and then select an existing policy or create a new one.

The following table explains the settings you can configure in this policy.

Use the Global Settings for GET VPN page to define global settings for ISAKMP and IPsec that apply to devices in your GET VPN topology.

Note	The lifetime settings in this policy do not apply to the ISAKMP security association lifetime for the key server and group members. Those lifetime values are configured in the IKE Proposal for GET VPN policy. For more information, see Configuring the IKE Proposal for GET VPN.

To open the Global Settings for GET VPN page:

• (Site-to-Site VPN Manager Window) Select an existing GET VPN topology and then select Global Settings for GET VPN in the Policies selector.

• (Policy view) Select Site-to-Site VPN > Global Settings for GET VPN, and then select an existing policy or create a new one.

The following table explains the settings you can configure in this policy.

Use the Key Servers policy to define key servers to be used by a GET VPN topology.

To open the Key Servers policy, in the Site-to-Site VPN Manager Window, select an existing GET VPN topology, then select Key Servers from the Policies list.

The table lists the key servers used in the VPN, showing the device name, identity, priority, and registration interface. For detailed information about these attributes, see Edit Key Server Dialog Box.

• To add a key server to the table, click the Add Row button and select the device from the list presented. Only devices that can be included as key servers are shown.

• To edit the characteristics of a key server, select it and click the Edit Row button. Fill in the Edit Key Server dialog box (see Edit Key Server Dialog Box).

• To delete a key server, select it and click the Delete Row button.

• To synchronize the RSA keys among the key servers, so that they all use the identical key, click the Synchronize Keys button. For detailed information about the key synchronization process, including when and why you would do it, see Generating and Synchronizing RSA Keys.

  To change the order of a key server when using cooperative key servers, select it and click the up or down arrow button. This order does not define which server is the primary key server (this is determined by the Priority value, the higher the value, the higher the likelihood that the server will be elected the primary key server).

Instead, the order determines the default order in which group members will try to register with a key server. Group members register with the first key server in the list. If the first key server cannot be reached, group members register with the second key server, and so on. For more information about key server redundancy, see Configuring Redundancy Using Cooperative Key Servers. Note that you can override this order for individual group members; see Configuring GET VPN Group Members and Edit Group Member Dialog Box.

Tip	You can toggle between showing the interface roles or the actual interfaces defined by those roles in the Identity and interfaces columns using the Show field below the table.

Use the Group Members policy to define the group members in a GET VPN topology.

To open the Group Members policy, in the Site-to-Site VPN Manager Window, select an existing GET VPN topology, then select Group Members from the Policies list.

The group members table lists the members of the GET VPN, showing the device name, GET-enabled interface, local interface, and security policy. For detailed information about these attributes, seeEdit Group Member Dialog Box.

• To add a group member to the table, click the Add Row button and select the device from the list presented. Only devices that can be included as group members are shown.

• To edit the endpoint characteristics of a group member, select it and click the Edit Row button. Fill in the Edit Group Member dialog box (see Edit Group Member Dialog Box).

If you select multiple group members in the table, you can also right-click and select the following commands to edit just these attributes:

• Edit Key Server Order—To change the key server list and priority order for the selected group members.

• Edit Passive SA Mode—To change whether the selected group members use passive SA mode.

• To delete a group member, select it and click the Delete Row button.

Tip	You can toggle between showing the interface roles or the actual interfaces defined by those roles in the interfaces columns using the Show field below the table.

If after provisioning and deploying GET VPN using Security Manager, the GET VPN is not working, check the following:

• Ensure that the RSA key is synchronized among all cooperative key servers (that is, the RSA key is the same). For information on how to synchronize keys, see Generating and Synchronizing RSA Keys.

• If desired traffic is not being encrypted, make sure the key server security policy ACL (security association) has a permit ACE for the desired traffic. For asymmetric ACEs (where the source and destination addresses are different), ensure that there is a mirrored ACE (with the source and destination addresses reversed). For more information, see Understanding the GET VPN Security Policy and Security Associations.

• For multicast rekey, make sure that the network is multicast enabled and that all key servers and most group members are configured to enable multicast. You must enable multicast on the devices directly; Security Manager does not provision the commands required to enable multicast. For more information, see Choosing the Rekey Transport Mechanism.

• When using multicast rekey, check whether there is a deny ACE in the key server security ACL for the multicast group address to prevent encryption of multicast rekey messages.

• Check that the local security ACL on the group member has only deny ACEs. If you include a permit statement in an attempt to identify traffic that should be encrypted, the matching traffic is actually dropped because there is no corresponding IPsec SA. Because the permit entry is defined in the group member, the key server is not aware of it and cannot generate the required IPsec SA. For more information, see Understanding the GET VPN Security Policy and Security Associations.

• For group member authorization using certificates, check that the ISAKMP authentication uses certificates and that a PKI policy is configured. ISAKMP identity on the group member and key server should be set to use the distinguished name (dn).

• Normally, network address translation (NAT) is not used in the type of WAN environments where GET VPN is deployed. However, if you use NAT, ensure that the security policy ACL has permit statements for the translated addresses. Also, if you are using Network Address Translation-Traversal (NAT-T), the GDOI protocol port changes to 4500.

• A control plane replay protection mechanism was added to Cisco IOS Software releases 12.4(15)T10, 12.4(22)T3, 12.4(24)T2, 15.0(1)M, and 12.2(33)XNE. This mechanism is not backward-compatible, so if any GET VPN group member in the network is running any of these (or later) releases, you must also upgrade all key servers to one of these (or newer) releases. Otherwise, network disruption might occur because of a failed rekey, which causes one of the following system logging (syslog) messages to appear:

  • %GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 2 in seq payload for group get-group, last seq # 6

  • %GDOI-3-PSEUDO_TIME_TOO_OLD: Rekey received in group get-group is too old and failed PST check: my_pst is 184 sec, peer_pst is 25 sec, allowable_skew is 10 sec

Tip	For additional troubleshooting tips from the CLI configuration perspective, including information about valuable show commands, see Cisco Group Encrypted Transport VPN on Cisco.com.