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:
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 has four main components:
- GM (Group Member)
- KS (Key Server)
- GDOI (Group Domain of Interpretation)
Let’s take a closer look at each component:
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.
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.
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 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:
With traditional IPSec ESP tunnel mode, the outer header always has the IP addresses of the VPN routers. Here’s an example:
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:
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 now know the basics of GETVPN so let’s see if we can configure this. Here is the topology I’ll use:
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.
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 0.0.0.0
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:
We also have to add our own KS IP address:
R1(gkm-local-server)#address ipv4 192.168.1.254
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:
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?
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
I’ll encrypt all traffic including BGP but thanks for the link I’ll read about it.
can u provide some examples of the use cases of GETVPN?
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