Group Encrypted Transport VPN (GETVPN)

GETVPN (Group Encrypted Transport VPN) is a tunnel-less VPN technology meant for private networks like MPLS VPN where we use a single SA (Security Association) for all routers in a group.

Traditional IPSec has some scalability issues because it’s point-to-point. Take a look at the following picture:

Routers Traditional Point To Point Ipsec

Each line represents an IPSec point-to-point tunnel. For each IPSec tunnel, the router has an IPSec SA. For example, R1 has four tunnels so that’s four IPsec SAs. With only a couple of routers this is no problem, but if you have a large topology and you need a full mesh of IPSec tunnels, things can get hairy. There is a limit to the number of IPSec SAs each router can have.

When you run IPSec on top of a hub and spoke topology like DMVPN then the hub has an IPSec SA with each and every spoke router. This limits the number of spoke routers you can have.  DMVPN supports direct spoke-to-spoke traffic but when a spoke wants to send traffic to another spoke, it first has to create a new IPSec SA which takes time, causing delay.

Another issue with traditional IPSec is that you can’t encapsulate multicast traffic unless you encapsulate it first with GRE.

GETVPN solves the scalability issue by using a single IPSec SA for all routers in a group. It also supports multicast traffic without GRE. In this lesson, I’ll explain how GETVPN works and I’ll show you how to configure it.

GETVPN Components

GETVPN has four main components:

Getvpn Key Server Group Members

  • GM (Group Member)
  • KS (Key Server)
  • GDOI (Group Domain of Interpretation)
  • IPSec

Let’s take a closer look at each component:

Group Member

The GM (Group Member) is a VPN router that is a member of the group and encrypts traffic with other GMs. All GMs have the same IPSec SA so any GM can encrypt traffic with any other GM right away.

Key Server

The KS (Key Server) is the “caretaker” of our group. They KS takes care of group registration and authentication of GMs. Each GM that wants to join the group registers with the KS and when authentication is successful, the KS sends the encryption keys and the policy that we use for the group.

When a GM tries to register with the KS, the KS checks a group ID and IKE credentials. When this checks out, the KS sends the following items to the GM:

  • The security policy that we use for the group.
  • Two keys:
    • KEK (Key Encryption Key): this is used to encrypt rekey messages. GMs use this key to decrypt rekey messages from the KS.
    • TEK (Traffic Encryption Key): this becomes the IPSec SA that all GMs use to encrypt traffic between each other.

The KS sends rekey messages when the current IPSec SA is about to expire or when the security policy is changed. Rekeying can be done through unicast or multicast. With unicast, each GM sends an acknowledgment to the KS when it receives the new key. When the KS doesn’t receive an acknowledgment after 3 transmissions, it deletes the GM. Multicast is a more scalable method for rekeying but it doesn’t support acknowledgments.

The KS takes care of registration, authentication, the security policy, and the keys but it’s not a GM. The KS does not become part of the group, it doesn’t install and use the IPSec SA.


GDOI is the protocol we use between the KS and GMs. It is protected with ISAKMP phase 1, the same ISAKMP we use for regular IPSec. You can use all ISAKMP authentication options like a pre-shared key or certificates. In phase 2, the KS sends the two keys (KEK and TEK) and the security policy. The KS keeps track of the SA lifetime and rekeys a new SA when it is about to expire. The rekey messages are signed with a private key of the KS since anyone could pretend to be the KS.

GETVPN does not support volume-based SA expiry, only time-based SA expiry. Volume-based is not practical since many GMs use the same SA.


GETVPN uses ESP (Encapsulating Security Payload), the same as traditional IPSec VPNs. It only supports tunnel mode which encapsulates the entire IP packet which adds a new IP header. There is a twist however, GETVPN uses tunnel mode with address preservation. This means it copies the inner IP header to the outer IP header, without any changes. Here’s an example:

Ipsec Esp Tunnel Mode Address Preservation

With traditional IPSec ESP tunnel mode, the outer header always has the IP addresses of the VPN routers. Here’s an example:

Traditional Ipsec Tunnel Mode Headers

The internal IP header shows traffic from different hosts on the network but the outside IP header always shows the IP addresses of the VPN routers. Using tunnels like this is known as overlay routing and one of the disadvantages is that these packets probably always get routed the same way throughout our network since the IP addresses never change.

Using tunnel mode with address preservation, the outer IP header has the IP addresses of the inner IP header:

Getvpn Ipsec Tunnel Mode Address Preservation Headers

The advantage of copying the inner IP header to the outer IP header is that the network can route packets based on the actual destination and find the best path to each destination. One disadvantage, however, is that you can’t use address preservation on the Internet since private IP addresses are unroutable. It’s incompatible with NAT since NAT makes changes to the outer IP header.

GETVPN is meant for private networks, like MPLS VPN where you have full reachability between all sites.

You might wonder, why don’t we just use IPSec transport mode instead of tunnel mode? Transport mode uses the original IP header without copying so there is less overhead. This is true but transport mode has some issues with fragmentation. There is only one IP header so if you fragment the IP packet before IPSec and it gets fragmented again during transit, you need an extra header to store the second fragmentation. Because of this, they decided to use ESP tunnel mode with address preservation for GETVPN.


You now know the basics of GETVPN so let’s see if we can configure this. Here is the topology I’ll use:

Getvpn Lab Topology Ks1 Gms

We have one key server and four group members. The cloud in the middle represents a private WAN. OSPF is configured on the GM routers to advertise the loopback interfaces.

Key Server

Let’s start with the KS, that’s where we need to configure most things. There are a couple of items we need:

  • IKE phase 1 policy: this is how the GMs authenticate with the KS.
  • RSA key: used for rekeying to secure the re-key messages.
  • IPSec policy: the policy that defines how we encrypt traffic.
  • Access-list: the traffic that we want to encrypt.

Let’s start with an IKE phase 1 policy. This is exactly the same as traditional IPSec:

R1(config)#crypto isakmp policy 10
R1(config-isakmp)#encryption aes
R1(config-isakmp)#hash sha
R1(config-isakmp)#authentication pre-share 
R1(config-isakmp)#group 5

We will keep it simple and use a pre-shared key. You can configure a different pre-shared key for each GM but I will use the same pre-shared key for all GMs:

R1(config)#crypto isakmp key MY_KEY address

GETVPN uses IPSec ESP so we need a transform-set for this:

R1(config)#crypto ipsec transform-set TRANSFORM_SET esp-aes esp-sha-hmac

In the transform-set, you don’t have to configure mode tunnel since that’s the default option.

We don’t use a crypto map but an IPSec profile and we add the transform-set to it:

R1(config)#crypto ipsec profile IPSEC_PROFILE
R1(ipsec-profile)#set transform-set TRANSFORM_SET

The last part we need to configure is the GDOI group but before we can do this, I need an RSA key pair. The KS uses the private key of the RSA key pair to sign the rekey messages. Let’s create a new RSA key pair and add a label called “RSA_KEYS” to it:

R1(config)#crypto key generate rsa modulus 1024 label RSA_KEYS

I also need an access-list that tells the GMs what traffic to encrypt. Let’s create an access-list that matches ICMP traffic:

R1(config)#ip access-list extended ICMP
R1(config-ext-nacl)#permit icmp any any

Now we can configure the GDOI group:

R1(config)#crypto gdoi group GDOI_GROUP
R1(config-gkm-group)#identity number 123

The KS and all GMs need to use the same group identity number. I use identity 123. The next command tells the router that this is the KS:

R1(config-gkm-group)#server local

We also have to add our own KS IP address:

R1(gkm-local-server)#address ipv4

Next is the rekey configuration. We tell the router to use the RSA key-pair to protect the rekey messages and to send them with unicast:

R1(gkm-local-server)#rekey authentication mypubkey rsa RSA_KEYS
R1(gkm-local-server)#rekey transport unicast

The last thing to do is to configure the IPSec policy. This is where we add the IPSec profile and our access-list:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 788 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

610 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,

Forum Replies

  1. Due to an audit we just had we need to encrypt all traffic going out MPLS, should my ACL include the LANs and BGP/30 network in the ACL on my MPLS router in the datacenter (which is acting as the KS)?
    In your lab you used OSPF but we’re running BGP, is it better to use a IGP verse BGP?

  2. Hi Corwyn,

    It shouldn’t matter too much that you use BGP. There is one issue with BGP/GETVPN where traffic can be get blackholed if a GM doesn’t receive keys. Take a look at this:

    Apparently, the “Routing Awareness for BGP” feature prevents this from happening but that’s something you should test.

    I think the answer depends on what “all traffic” exactly means. Is this about data from your LANs o

    ... Continue reading in our forum

  3. I’ll encrypt all traffic including BGP but thanks for the link I’ll read about it.

  4. Rene,

    can u provide some examples of the use cases of GETVPN?

  5. Hello Ray

    Rene explains the difficulties that IPsec presents when you have a multi site WAN deployment. Even with DMVPN, it is difficult and cumbersome to employ IPsec within such a WAN topology.

    The advantages of GETVPN will allow you to create a multi site WAN topology with a single IPsec SA, thus simplifying the implementation of IPsec into a multi site WAN topology.

    So examples for the use of GETVPN include all multi site WAN topologies that want to employ IPsec in a scalable manner. For example, a corporation with a DMVPN hub and spoke topology with multi

    ... Continue reading in our forum

19 more replies! Ask a question or join the discussion by visiting our Community Forum