GETVPN COOP with PKI & Multicast Rekey

Introduction

 

In this blog, we will be taking a look at group encrypted transport VPN, or GETVPN.  GETVPN is a Cisco VPN technology that is generally usually used to secure private WAN links. For example, you might implement GETVPN if you had an MPLS L3VPN with a service provider, but you wanted to make sure the traffic flowing between sites on that MPLS WAN cloud was secured with IPsec. If it is a private WAN, why would you want to secure it with IPsec?  Well, there could be a number of reasons.  For example, maybe your organization’s security policy demands that traffic going over the WAN is encrypted, regardless of the transport technology or if it is a “private” network.  Maybe you just don’t trust your SP.  Maybe you are studying for the CCIE lab exam : )

The general concept of how GETVPN works is actually pretty neat.  Imagine that you had a WAN with a number of different sites. Through some kind of routing implementation, each site can talk to each of the other sites.  Now, you want to secure the traffic between those sites.  Additionally, you want the traffic to go directly between the sites without having to transit through a central “hub”. Traditionally, this would be possible, but rather cumbersome, because the implementation would have to rely on a full mesh of point-to-point tunnels, or maybe something crazy like DMVPN phase III running over your private WAN cloud. In those types of implementations, ultimately, we would end up with unique ISAKMP SA’s and IPsec SA’s for the traffic going between sites. That means whenever traffic is going between sites, the routers at those sites would have to setup an ISAKMP SA and one or more IPsec SA’s. There is setup delay and overhead associated with all of that.  Additionally, it would be really difficult and messy to try to pull that off with straight up point-to-point tunnels using crypto maps.  If you used GRE/IPsec or VTI tunnel interfaces, that would also mean you would have to implement an additional overlay network.  That then leads to other challenges like having to then figure out and manage the routing over that overlay network.

GETVPN aims to simplify this whole thing.  GETVPN uses a protocol called GDOI, or group domain of interpretation.  The basic idea of it is simple – Instead of negotiating individual ISAKMP and IPsec SA’s for traffic going between all these sites, why don’t we instead have a group SA?  In other words, we have a single SA that is good for traffic going between any of the sites. That is the first big thing GETVPN accomplishes.  Secondly, it enables us to do this without implementing any kind of overlay network and without having to use tunnel interfaces or complicated full mesh crypto map configurations!  For the customer of something like an MPLS WAN, this is really cool because it means they can still rely on the service provider to deal with getting traffic directly between sites in the most efficient way possible, but at the same time, they can secure that traffic in an easy way.

 

Key Servers and Group Members

 

With GETVPN, you have one or more key servers that are really responsible for driving the control plane of the GETVPN solution, and you have the group members (GM), which are the routers at all the sites that you need to communicate with each other.  A key server can not be a group member.  Basically, the way this whole thing works is that first, the group members register with the key server.  Technically, they do this by initiating and nailing up an ISAKMP SA with the key server. The key server will have all the configuration needed that is necessary to generate the IPsec group SA (For example, the transform-set and proxy ACL). The key server then pushes all the information necessary to the group members that will allow the group members to securely communicate with each other using this shared group SA. This communication is secured by the ISAKMP SA just created between the GM and the KS. The key server generates, pushes, and periodically rekeys a few different keys.  Namely, these are the key encryption key (KEK) and the traffic encryption key (TEK). The TEK is the key used to actually secure the data plane for traffic between GMs. When the TEK needs refreshed, the KS pushes it to the GMs, and encrypts it with the KEK. The rekey mechanism can be configured to happen via multicast or unicast, with multicast actually being the default.  Keep in mind, that for multicast rekey to work properly, the network you are implementing this on already needs to have a working multicast solution.  In all but the most basic of situations, this includes full blown multicast routing.  In this blog, we will be looking at a very basic multicast implementation.

So, obviously the key server is important.  Therefore, having more than one in a production environment is a good idea.  We call this co-op mode, or COOP.  In COOP, GMs are configured to register to more than one KS, in case one should go down.  However, only one KS is designated as the primary, while others are standby.  This is based on a configurable priority, with the highest configured priority being elected the primary.  The active primary KS is always responsible for maintaining and pushing the KEK and TEK down to the GMs.  Additionally, since the rekeys are digitally signed by the KS, all the key servers need to have the same RSA private/public key pair.  Therefore, you must export the RSA keypair configured for GETVPN on the primary, and import it on the secondary units. The various key servers also build ISAKMP SA’s between each other to secure the communications between them that keep things in sync. This includes the GM registration database and keys.

Once a GM registers and receives the TEK from the primary KS, it can then securely communicate using the shared group SA with other GMs immediatley.  What’s nice is that there is no phase I or phase II negotiation between GMs at this point.  The GMs already have everything they need to know to encrypt and decrypt traffic.

Another thing worth mentioning is that while GETVPN is a “tunnel-less” non-overlay VPN technology, there is still sort of tunnel like behavior.  What exactly do I mean by that?  Let’s say there was an endpoint behind one GM trying to talk to an endpoint behind another GM.  Since no overlays or tunnel interfaces are used here, it would make sense for one to think we could implement this with pure IPsec transport mode.  The problem with that is that it is not the endpoints initiating and terminating the IPsec connections.  When the host behind GM1 wants to talk to the host behind GM2, the traffic gets to GM1, and it is then GM1 that initiates the IPsec encapsulated traffic to GM2.  Cisco does not actually allow a router to initiate an IPsec connection in transport mode to another router for traffic that is transiting through the router itself.  So, what actually happens?  IP address preservation without needing tunnel overlays is one of the most important goals of GETVPN.  What actually happens is that the original IP header is copied to an outer header.  This happens weather you have mode transport or mode tunnel configured on the transport set.  So in other words, let’s say host 192.168.0.1 was talking to 192.168.10.1.  The packet structure would look something like this when it left GM1:

[Outer IP header: 192.168.0.1 –> 192.168.10.1][ESP Header][Inner IP header: 192.168.0.1 –> 192.168.10.1][Upper layers / payload]

As you can see it is transport mode LIKE behavior, but still with tunnel mode LIKE overhead.

From a configuration perspective, the key servers and the GMs will all have the same phase I ISAKMP policy configured.  However, the proxy ACL that determines what traffic is going to be encrypted between sites and the transform-set that determines how exactly that is going to happen only need configured on the key servers.  After all, it is the key server that pushes this information down to the GMs.

 

Lab Topology

OK, let’s get to the configs!  Here is out topology for today. As you can see, we will be doing GETVPN COOP where R1 and R5 are our key servers and R2, R3 and R4 are GMs.  We will be configuring all the ISAKMP SA authentication to happen using digital certificates, and the rekey to happen using multicast.  Now, the G1 interfaces of all these routers are on the same VLAN, so granted, the multicast topology is very simple, but it will need to be there and be functional to pull this off. R1 will also act as our PKI CA here to grant digital certificates. Keep in mind, I have already configured the basic IP addressing and OSPF routing in VLAN 100. All the routers run OSPF on VLAN 100 and also advertise in their loopbacks.

 

GETVPN_COOP

 

Primary Key Server

First thing we will want to do is enable multicast routing, and setup our PKI environment. Before doing this step, I also generated two different RSA keypairs – One to be used for the root CA itself, and one to be used for the trustpoint the router will use to enroll a certificate from itself. 239.192.1.190 is the address of the multicast group we will use to do the rekey. We will implement the multicast using SSM. R1 will also be an NTP server. We want to make sure all the routers have synced clocks because of the certificate authentication we will be using.

ip multicast-routing distributed
ip pim ssm range 1
!
no ip domain-lookup
ip domain name lab.local
!
crypto pki server ROOT_CA
 no database archive
 issuer-name CN=r1.lab.local
 grant auto
 hash sha512
!
crypto pki trustpoint ROOT_CA
 revocation-check crl
 rsakeypair ROOT_CA_KEYS
!
crypto pki trustpoint CA
 enrollment url http://100.100.100.1:80
 fqdn r1.lab.local
 revocation-check none
 rsakeypair MYKEYS
!
interface GigabitEthernet1
 ip address 100.100.100.1 255.255.255.0
 ip pim sparse-mode
 ip ospf priority 255
!
access-list 1 permit 239.192.1.190
!
ip access-list extended getvpn-rekey-multicast-group
 permit ip any host 239.192.1.190
!
ntp master 3

After this, I went ahead and issued “crypto pki authenticate” and “crypto pki enroll” so R1 could generate the digital certificate it will use for authentication. Some quick verification:

R1#sh crypto pki certificates
Certificate
  Status: Available
  Certificate Serial Number (hex): 09
  Certificate Usage: General Purpose
  Issuer:
    cn=r1.lab.local
  Subject:
    Name: r1.lab.local
    hostname=r1.lab.local
  Validity Date:
    start date: 05:47:26 UTC Jul 17 2017
    end   date: 05:47:26 UTC Jul 17 2018
  Associated Trustpoints: CA
  Storage: nvram:r1lablocal#9.cer

CA Certificate
  Status: Available
  Certificate Serial Number (hex): 01
  Certificate Usage: Signature
  Issuer:
    cn=r1.lab.local
  Subject:
    cn=r1.lab.local
  Validity Date:
    start date: 04:30:27 UTC Jul 17 2017
    end   date: 04:30:27 UTC Jul 16 2020
  Associated Trustpoints: CA ROOT_CA
  Storage: nvram:r1lablocal#1CA.cer

OK, next we will configure our ISAKMP policy for IPsec phase I and our transform-set/IPsec profile for IPsec phase II. Additionally, we will need to configure the proxy ACL to be pushed to all the GMs. This ACL should reflect any traffic you want protected between GMs in both directions:

crypto isakmp policy 10
 encr aes 256
 hash sha512
!
crypto isakmp keepalive 15 periodic
!
crypto ipsec transform-set GETVPN-TRANSFORM-SET esp-aes 256 esp-sha512-hmac
 mode transport
!
crypto ipsec profile GETVPN-IPSEC-PROFILE
 set transform-set GETVPN-TRANSFORM-SET
!
ntp server 100.100.100.1
!
ip access-list extended GETVPN-ACL
 permit ip host 2.2.2.2 host 3.3.3.3
 permit ip host 2.2.2.2 host 4.4.4.4
 permit ip host 3.3.3.3 host 2.2.2.2
 permit ip host 3.3.3.3 host 4.4.4.4
 permit ip host 4.4.4.4 host 2.2.2.2
 permit ip host 4.4.4.4 host 3.3.3.3

OK, finally, we will configure the primary KS: The identity number can be anything we like. You can see that I have specified the ACL getvpn-rekey-multicast-group to determine the multicast group we will use for rekey (239.192.1.190), and also the RSA keypair that will be used to digitally sign the rekeys. It is vitally important that we export this keypair and import it to the standby key server. You can do this with the command crypto key export and crypto key import respectively. After the rekey configuration, we get into the group SA config. As you can see, we call the IPsec profile, which in turn calls the IPsec transform set to protect the SA. We then call the proxy ACL that determines what it is we will be protecting between GMs. Finally, we specific the local address we will use to source our GDOI messages. Last, but not least, we specify that R5 will be the backup KS. Notice that I set the priority to 255 locally. Later, we will set priority to 254 for R5.

crypto gdoi group GETVPN
 identity number 123
 server local
  rekey address ipv4 getvpn-rekey-multicast-group
  rekey authentication mypubkey rsa GETVPN-KEYS
  sa ipsec 1
   profile GETVPN-IPSEC-PROFILE
   match address ipv4 GETVPN-ACL
   replay counter window-size 64
   no tag
  address ipv4 100.100.100.1
  redundancy
   local priority 255
   peer address ipv4 100.100.100.5

Secondary Key Server

The configuration of the secondary KS is almost identical to the primary. To save room and time here, I will just paste in the GETVPN section. Obviously, the secondary also has a PKI trustpoint configured already, and has already authenticated the CA and received it’s own digital certificate.  The phase I and phase II policies will be identical, as will the multicast configurations. The only thing that really changes here is that we specify a local priority lower than R1’s and specify R1 as our peer, a well as configuring our own local address. Again, it is VITALLY VITALLY important that we have already imported the RSA keypair “GETVPN-KEYS” from the primary KS

crypto gdoi group GETVPN
 identity number 123
 server local
  rekey address ipv4 getvpn-rekey-multicast-group
  rekey authentication mypubkey rsa GETVPN-KEYS
  sa ipsec 1
   profile GETVPN-IPSEC-PROFILE
   match address ipv4 GETVPN-ACL
   replay counter window-size 64
   no tag
  address ipv4 100.100.100.5
  redundancy
   local priority 254
   peer address ipv4 100.100.100.1

Group Members

The GM configurations are all basically identical.  We will show R2 here. Note that again, I have already generated the RSA keypair “MYKEYS” for my trustpoint ahead of time. First thing we do is enable multicast routing and set our PIM SSM range, just like we did on the server. Then, we setup our PKI environment, telling R2 that R1 is the root CA. Not shown here is that I then have pulled down R1’s CA certificate and enrolled a certificate for R2 as well. Next, we have our phase I ISAKMP policy matching what is on the KS. Remember, this is needed because the GM uses an ISAKMP SA to register with the key server. Note we have no configuration for phase II, which is normal. That all gets pushed down from the KS after registration. Finally, we have the “client” end of GDOI where we simply point the GM to both key servers.

To tie it all up, we write a special kind of crypto map (GDOI) and we specify what the GDOI group is that we configured above. We then apply this crypto map to our G1 interface. Also note that we have enabled PIM and told the G1 interface to join the multicast group 239.192.1.190 from both sources. This tells the GM to join the group used for the rekey coming down from the KS. As you can imagine, we are basically repeating this on R3 and R4.

ip multicast-routing distributed
ip pim ssm range 1

no ip domain lookup
ip domain name lab.local
!
crypto pki trustpoint CA
 enrollment url http://100.100.100.1:80
 fqdn r2.lab.local
 revocation-check none
 rsakeypair MYKEYS
!
crypto isakmp policy 10
 encr aes 256
 hash sha512
!
crypto gdoi group GETVPN
 identity number 123
 server address ipv4 100.100.100.1
 server address ipv4 100.100.100.5
!
crypto map GETVPN 10 gdoi
 set group GETVPN
!
interface GigabitEthernet1
 ip address 100.100.100.2 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 239.192.1.190 source 100.100.100.1
 ip igmp join-group 239.192.1.190 source 100.100.100.5
 crypto map GETVPN
!
access-list 1 permit 239.192.1.190

Verifications

Let’s start looking through some things from the perspective of the GM first.  First off, did we register properly? Also, were we able to pull down the TEK/KEK and proxy ACL from the KS?

R2#sh crypto gdoi
GROUP INFORMATION

    Group Name               : GETVPN
    Group Identity           : 123
    Group Type               : GDOI (ISAKMP)
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Rekeys received          : 24
    IPSec SA Direction       : Both

     Group Server list       : 100.100.100.1
                               100.100.100.5

Group Member Information For Group GETVPN:
    IPSec SA Direction       : Both
    ACL Received From KS     : gdoi_group_GETVPN_temp_acl

    Group member             : 100.100.100.2   vrf: None
       Local addr/port       : 100.100.100.2/848
       Remote addr/port      : 100.100.100.1/848
       fvrf/ivrf             : None/None
       Version               : 1.0.16
       Registration status   : Registered
       Registered with       : 100.100.100.1
       Re-registers in       : 2655 sec
       Succeeded registration: 1
       Attempted registration: 1
       Last rekey from       : 100.100.100.1
       Last rekey seq num    : 3
       Multicast rekey rcvd  : 24
       DP Error Monitoring   : OFF
       IPSEC init reg executed    : 1
       IPSEC init reg postponed   : 0
       Active TEK Number     : 1
       SA Track (OID/status) : disabled

       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 24
       After latest register : 24
       Rekey Rcvd(hh:mm:ss)  : 00:11:40

 ACL Downloaded From KS 100.100.100.1:
   access-list   permit ip host 2.2.2.2 host 3.3.3.3
   access-list   permit ip host 2.2.2.2 host 4.4.4.4
   access-list   permit ip host 3.3.3.3 host 2.2.2.2
   access-list   permit ip host 3.3.3.3 host 4.4.4.4
   access-list   permit ip host 4.4.4.4 host 2.2.2.2
   access-list   permit ip host 4.4.4.4 host 3.3.3.3

KEK POLICY:
    Rekey Transport Type     : Multicast
    Lifetime (secs)          : 82458
    Encrypt Algorithm        : 3DES
    Key Size                 : 192
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 4400

TEK POLICY for the current KS-Policy ACEs Downloaded:
  GigabitEthernet1:
    IPsec SA:
        spi: 0x244D5E88(609050248)
        KGS: Disabled
        transform: esp-256-aes esp-sha512-hmac
        sa timing:remaining key lifetime (sec): (2880)
        Anti-Replay(Counter Based) : 64
        tag method : disabled
        alg key size: 32 (bytes)
        sig key size: 64 (bytes)
        encaps: ENCAPS_TRANSPORT

    IPsec SA:
        spi: 0xA77887F7(2809694199)
        KGS: Disabled
        transform: esp-256-aes esp-sha512-hmac
        sa timing:remaining key lifetime (sec): expired
        Anti-Replay(Counter Based) : 64
        tag method : disabled
        alg key size: 32 (bytes)
        sig key size: 64 (bytes)
        encaps: ENCAPS_TRANSPORT

That is looking fantastic. Now, a quick look at the KS side

R1#sh crypto gdoi ks
Total group members registered to this box: 3

Key Server Information For Group GETVPN:
    Group Name               : GETVPN
    Re-auth on new CRL       : Disabled
    Group Identity           : 123
    Group Type               : GDOI (ISAKMP)
    Group Members            : 3
    Rekey Acknowledgement Cfg: Cisco
    IPSec SA Direction       : Both
    CKM status               : Disable
    ACL Configured:
        access-list GETVPN-ACL
    Redundancy               : Configured
        Local Address        : 100.100.100.1
        Local Priority       : 255
        Local KS Status      : Alive
        Local KS Role        : Primary
        Local KS Version     : 1.0.18

Cool, we have 3 registered GMs. What bout the secondary KS?

R1#sh crypto gdoi ks coop
Crypto Gdoi Group Name :GETVPN
        Group handle: 2147483650, Local Key Server handle: 2147483650

        Local Address: 100.100.100.1
        Local Priority: 255
        Local KS Role: Primary   , Local KS Status: Alive
        Local KS version: 1.0.18
        Primary Timers:
                Primary Refresh Policy Time: 20
                Remaining Time: 6
                Per-user timer remaining time: 0
                Antireplay Sequence Number: 1411
        Peer Sessions:
        Session 1:
                Server handle: 2147483651
                Peer Address: 100.100.100.5
                Peer Version: 1.0.18
                Peer Priority: 254
                Peer KS Role: Secondary , Peer KS Status: Alive
                Antireplay Sequence Number: 30

                IKE status: Established
                Counters:
                    Ann msgs sent: 1167
                    Ann msgs sent with reply request: 0
                    Ann msgs recv: 5
                    Ann msgs recv with reply request: 0
                    Packet sent drops: 244
                    Packet Recv drops: 1
                    Total bytes sent: 1348354
                    Total bytes recv: 7111

Looks good, let’s finally do a test between the GMs:

R2#ping 3.3.3.3 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/6 ms

R2#ping 4.4.4.4 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/7 ms

R2#show crypto gdoi gm dataplane counters

Data-plane statistics for group GETVPN:
    #pkts encrypt            : 10       #pkts decrypt            : 10
    #pkts tagged (send)      : 0        #pkts untagged (rcv)     : 0
    #pkts no sa (send)       : 0        #pkts invalid sa (rcv)   : 0
    #pkts encaps fail (send) : 0        #pkts decap fail (rcv)   : 0
    #pkts invalid prot (rcv) : 0        #pkts verify fail (rcv)  : 0
    #pkts not tagged (send)  : 0        #pkts not untagged (rcv) : 0
    #pkts internal err (send): 0        #pkts internal err (rcv) : 

R3#ping 4.4.4.4 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/8 ms

R3#show crypto gdoi gm dataplane counters

Data-plane statistics for group GETVPN:
    #pkts encrypt            : 70       #pkts decrypt            : 70
    #pkts tagged (send)      : 0        #pkts untagged (rcv)     : 0
    #pkts no sa (send)       : 0        #pkts invalid sa (rcv)   : 0
    #pkts encaps fail (send) : 0        #pkts decap fail (rcv)   : 0
    #pkts invalid prot (rcv) : 0        #pkts verify fail (rcv)  : 0
    #pkts not tagged (send)  : 0        #pkts not untagged (rcv) : 0
    #pkts internal err (send): 0        #pkts internal err (rcv) : 0

As we can see, every GM was able to securely communicate with every other GM.

 

Failover

 

Now let’s examine what happens in the event that our primary KS goes down.  To simulate this, let’s shut down the G1 interface of R1 and wait a few moments

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int gi1
R1(config-if)#shut
R1(config-if)#
Jul 28 02:59:32.481: %PIM-5-NBRCHG: neighbor 100.100.100.2 DOWN on interface GigabitEthernet1 non DR
Jul 28 02:59:32.481: %PIM-5-NBRCHG: neighbor 100.100.100.4 DOWN on interface GigabitEthernet1 non DR
Jul 28 02:59:32.481: %PIM-5-NBRCHG: neighbor 100.100.100.5 DOWN on interface GigabitEthernet1 DR
Jul 28 02:59:32.481: %PIM-5-NBRCHG: neighbor 100.100.100.3 DOWN on interface GigabitEthernet1 non DR
Jul 28 02:59:32.487: %OSPF-5-ADJCHG: Process 123, Nbr 2.2.2.2 on GigabitEthernet1 from FULL to DOWN, Neig
R1(config-if)#hbor Down: Interface down or detached
Jul 28 02:59:32.487: %OSPF-5-ADJCHG: Process 123, Nbr 3.3.3.3 on GigabitEthernet1 from FULL to DOWN, Neighbor Down: Interface down or detached
Jul 28 02:59:32.487: %OSPF-5-ADJCHG: Process 123, Nbr 4.4.4.4 on GigabitEthernet1 from FULL to DOWN, Neighbor Down: Interface down or detached
Jul 28 02:59:32.487: %OSPF-5-ADJCHG: Process 123, Nbr 5.5.5.5 on GigabitEthernet1 from FULL to DOWN, Neighbor Down: Interface down or detached
R1(config-if)#
Jul 28 02:59:34.483: %LINK-5-CHANGED: Interface GigabitEthernet1, changed state to administratively down
Jul 28 02:59:35.485: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1, changed state to down

We need to wait a few moments for R5 to take over as the active KS. Keep in mind, that while we are waiting, the data plane is not effected. Remember, the GMs already have the group SA information, and the GM database has already been shared with R5 as well. After a bit, we see the following logs on R5 (the secondary KS)

Jul 28 03:00:49.720: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 100.100.100.1 Unreachable in group GETVPN. IKE SA Status = Failed to establish.
Jul 28 03:00:49.720: %GDOI-5-COOP_KS_TRANS_TO_PRI: KS 100.100.100.5 in group GETVPN transitioned to Primary (Previous Primary = 100.100.100.1)

What should happen now in a case like this is that when the TEK expires, the active KS will need to push the new key down to the GMs. Let’s simulate this by forcing a rekey from our secondary, now active KS:

R5#crypto gdoi ks rekey
Jul 28 03:04:42.726: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 100.100.100.1 Unreachable in group GETVPN. IKE SA Status = Failed to establish.
Jul 28 03:04:43.820: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey with policy-replace for group GETVPN from address 100.100.100.5 to 239.192.1.190 with seq # 4 spi: 0xB6351B18E187EFEA76A40BCA3A60544

We see this on the GMs…

Jul 28 03:04:43.827: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
Jul 28 03:04:43.827: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0xB77A59EE872FD204AA52F03926F42D
Jul 28 03:04:43.830: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GETVPN from 100.100.100.5 to 239.192.1.190 with seq # 4, spi 0x76A40BCA3A60544B6351B18E187EFEA
Jul 28 03:04:43.884: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 100.100.100.5 for group GETVPN & gm identity 100.100.100.2 fvrf default

Sweet, looks like it worked. Quick test…

R2#ping 4.4.4.4 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/8 ms

R2#ping 3.3.3.3 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/7 ms

Finally, let’s fail it back over…

R1(config)#int gi1
R1(config-if)#no shut

Jul 28 03:06:53.488: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 100.100.100.1 on interface GigabitEthernet1
Jul 28 03:06:55.051: %LINK-3-UPDOWN: Interface GigabitEthernet1, changed state to up
Jul 28 03:06:55.056: %PIM-5-NBRCHG: neighbor 100.100.100.5 UP on interface GigabitEthernet1
Jul 28 03:06:55.057: %PIM-5-DRCHG: DR change from neighbor 100.100.100.1 to 100.100.100.5 on interface GigabitEthernet1
Jul 28 03:06:55.057: %PIM-5-NBRCHG: neighbor 100.100.100.4 UP on interface GigabitEthernet1
Jul 28 03:06:55.057: %PIM-5-NBRCHG: neighbor 100.100.100.3 UP on interface GigabitEthernet1
Jul 28 03:06:55.057: %PIM-5-NBRCHG: neighbor 100.100.100.2 UP on interface GigabitEthernet1
Jul 28 03:06:56.051: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1, changed state to up
Jul 28 03:06:57.085: %CRYPTO-6-IKMP_NO_ID_CERT_FQDN_MATCH: (NOT ERROR BUT WARNING ONLY)ID of R5.lab.local (type 2) and certificate fqdn with r5.lab.local
Jul 28 03:06:57.085: %CRYPTO-6-IKMP_NO_ID_CERT_FQDN_MATCH: (NOT ERROR BUT WARNING ONLY)ID of R5.lab.local (type 2) and certificate fqdn with r5.lab.local
Jul 28 03:06:57.086: %GDOI-5-COOP_KS_REACH: Reachability restored with Cooperative KS 100.100.100.5 in group GETVPN.
Jul 28 03:06:57.805: %IGMP-3-QUERY_INT_MISMATCH: Received a non-matching query interval 0, from querier address 0.0.0.0
Jul 28 03:06:59.863: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey for group GETVPN from address 100.100.100.1 to 239.192.1.190 with seq # 111 spi: 0xB6351B18E187EFEA76A40BCA3A60544
Jul 28 03:07:00.664: %OSPF-5-ADJCHG: Process 123, Nbr 4.4.4.4 on GigabitEthernet1 from LOADING to FULL, Loading Done
Jul 28 03:07:00.763: %OSPF-5-ADJCHG: Process 123, Nbr 5.5.5.5 on GigabitEthernet1 from LOADING to FULL, Loading Done

Cool, R1 took back over as primary active. Notice also, that it send another rekey out.

R1#sh crypto gdoi ks coop
Crypto Gdoi Group Name :GETVPN
        Group handle: 2147483650, Local Key Server handle: 2147483650

        Local Address: 100.100.100.1
        Local Priority: 255
        Local KS Role: Primary   , Local KS Status: Alive
        Local KS version: 1.0.18
        Primary Timers:
                Primary Refresh Policy Time: 20
                Remaining Time: 16
                Per-user timer remaining time: 0
                Antireplay Sequence Number: 1454
        Peer Sessions:
        Session 1:
                Server handle: 2147483651
                Peer Address: 100.100.100.5
                Peer Version: 1.0.18
                Peer Priority: 254
                Peer KS Role: Secondary , Peer KS Status: Alive
                Antireplay Sequence Number: 53

                IKE status: Established
                Counters:
                    Ann msgs sent: 1189
                    Ann msgs sent with reply request: 0
                    Ann msgs recv: 7
                    Ann msgs recv with reply request: 0
                    Packet sent drops: 265
                    Packet Recv drops: 1
                    Total bytes sent: 1373691
                    Total bytes recv: 10487

Success!!

Summary

 

In this blog, we took a look at GETVPN, and at a specific implementation of it using mutlicast rekey and PKI based authentication. As we saw, the GETVPN allows us to protect the dataplane for traffic flowing directly between sites by using the concept of a group IPSEC SA. This type of technology allows us to protect data between sites without having to implement an overlay VPN network, and keeps the original IP address intact as the packets traverse the network.  This also means that as long as we have IP reachability between sites, we can implement GETVPN. In other words, we don’t have to worry about routing on top of it if the SP is already providing that. This is a major benefit in something like an MPLS L3 VPN situation where this technology is usually seen.

As we discussed and saw firsthand, the “brains” of the operations handling the dataplane of GETVPN is the key server, which can also be configured in a redundant COOP type of mode with one or more other secondary standby key servers. The key server generates and distributes keying material, transform-sets, and proxy ACL used to secure the group SA, and does this over a secured ISAKMP tunnel that is dynamically stood up with each GM at registration time. The GETVPN group members register with the key server, pull down the relevant information, and can then encrypt and and decrypt traffic to/from other GMs in the GETVPN network.

I hope this blog was useful for everybody, and thanks for reading!

Leave a Reply