IPSec VPN tunnels are pretty straight forward. Define the ISAKMP policy and keys (phase I), define the IPSec transform set, define the interesting traffic (traffic that will be encypted), create a crypto map or ipsec policy, then apply the policy to an interface. All IPSec VPN technologies use this basic format. However, there are various applications for a VPN. There are remote access VPNs (where the endpoint can be anywhere) or site to site VPNs (where the endpoints are static and known). For site to site VPN technologies, the type of traffic and layout of the network can determine the type of VPN tunnel that is being used, whether it is a crypto map, VTI, DMVPN, or GET VPN.
GET VPN uses the Group Domain of Interpretation (GDOI) specification that is defined in RFC 3547. Unlike other site to site VPNs where the endpoints manage both phase I and phase II of the VPN, GDOI uses the concept of a Key Server (KS) to control data and control plane traffic between VPN endpoints. The need for GDOI comes from having an internal network (such as MPLS) that requires encryption on the end points. Traditional site to site VPNs do not scale very well, and DMVPN can take longer to rekey, causing some delay in setting up phase II traffic. DMVPN uses a sliding window to prevent anti-replay attacks, creating the delay. GDOI uses a time-based window that prevents attacks but speeds up the rekey process. This is because all group members in a GDOI use the same security SA (common policy), so a sliding window will not even work.
GDOI uses the original IP header when tunneling traffic, so it works well in a private environment. However, because private IP addresses are blocked on the Internet in accordance to RFC 2827, GDOI does not work well in a publicly routet environment, which is where DMVPN is most suited. If the DMVPN is being used in a private environment (such as an environment that utilizes multiple frame relays without MPLS), then GDOI can be used in conjunction with DMVPN…but this is a pretty rare case. That will be saved for a later post. 
So how does GET VPN work? First, there are key servers on the network that store both the phase I and phase II information. There can be one key server on a network, but if the key server were to fail, so would the VPNs, which may create a Career Limiting Event (CLE). In order to allow network administrators and engineers to keep their jobs, the concept of a KS COOP was developed. This allows multiple servers to act as key servers on the network. If one were to fail, the other would maintain the current SA and become responsible for rekey responsibilities. This is done by exporting the key of the primary KS and importing it into the secondary KS.
The keys are exhanged between the KS and the Group Member (GM). There are two types of keys. First, there is the Key Encryption Key (KEK) used for the Re-Key SA, while the Traffic Encryption Key (TEK) is used for the encryption of the traffic using the Data Security SA. The initial exchange is a pull from the GM to the KS, and the keys are exchanged. This is called the Request Message. During the rekey process, the KS pushes the rekey to the GM. This is called the Push Message. During the third exchange, the POP and CERT payloads are sent from the GM to the KS, which is called the ACK Message. Finally, the KS verifies all the data and the HASH message and issues a Key Download Message.
That was a bit of a brief overview. Check out Cisco’s website or the RFC for a more detailed (and less entertaining) description. For now, a quick and dirty configuration is in order. Our network diagram:
Here, R1 and R2 are going to be the group members (GM). R3 and R4 are going to be the Key Servers (KS). R3 and R4 are going to be in COOP mode. All routers are able to route to each other on both the Ethernet and Loopback interfaces by setting up EIGRP and advertising all Ethernet and Loopback networks.
The tunnel between R1 and R2 is going to encrypt any traffic going between the Loopback interfaces. While in a normal environment we would use the internal networks, this will do for our lab to get the desired results. However, it will lead to a bit of a pitfall, which will be described later.
First, we should setup the KS routers. R3 will be the primary KS, while R4 will be the secondary KS. The steps for setting up the KS are similar to setting up a regular VPN, with some funky additions:
- Define the ISAKMP policy.
- Create the ISAKMP keys (pre-shared authentication only).
- Define the interesting traffic with an ACL.
- Generate an exportable key (needed for COOP).
- Create the IPSec transform set.
- Create the IPSec profile.
- Create the GDOI group.
The two key points here are generating an exportable key and creating the GDOI group. This is what differentiates this from other site to site VPNs. The exportable keys are necessary to create the COOP. Even if only one KS is going to be used, it is good practice to generate the exportable keys for future use.
R3:
crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.10.10.1 crypto isakmp key cisco address 10.10.20.2 crypto isakmp key cisco address 10.10.30.4 ! ! crypto ipsec transform-set STRONG esp-aes esp-sha-hmac ! ! Next we do the ACL before creating the GDOI groups ! access-list 101 permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255 ! ! Next we create the exportable keys crypto key gen rsa general-keys exportable label GDOI_KEYS ! ! Now the GDOI fun stuff! ! crypto ipsec profile GDOI set security-association lifetime seconds 1800 set transform-set STRONG ! crypto gdoi group GDOI_GROUP identity number 1 server local rekey retransmit 10 number 2 rekey authentication mypubkey rsa GDOI_KEYS rekey transport unicast sa ipsec 1 profile GDOI match address ipv4 101 replay time window-size 5 address ipv4 10.10.30.3 redundancy local priority 100 peer address ipv4 10.10.30.4
If you notice the ACL, we are using what is called a Symmetric ACL. The defined traffic on both sides of the ACL are identical. This allows us to encrypt all traffic on the loopback interfaces. We do NOT want to add the 10.10.0.0/16 network, as that would also try to encrypt traffic between the key servers and the group members. This will lead to pain. It also shows the value of using GET VPN in a private environment. We could use the loopbacks as the endpoints and the source of the key exchanges, while the traffic from all the private networks can talk to each other with a minimal ACL entry.
R4 is the same, but the last part of the GDOI profile is a bit different, along with the ISAKMP keys. Before getting started, it would be a fine idea to export and import the keys from R3. First, use the export command to expose the keys to the terminal:
R3(config)#crypto key export rsa GDOI_KEYS pem terminal 3des CISCO1234 % Key name: GDOI_KEYS Usage: General Purpose Key Key data: -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAeSciKuAgSdzbR+nNeTpSrGfF 6B7wf8Mk+ZS10iBpxWhFOykksg+ffl6GqSLIqifAplFO0mUQUXmowt6U+90lUkzZ Uk60n/Z3/6LjyMEMYxTZxzoZYOAw6YBMNGgE45UeWBw40tg/pjmWd8DKgw1uE6hz 0U2x2xPjhbdQmOVk2wIDAQAB -----END PUBLIC KEY----- -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,1C89433617040F00 48hBYLj3eURGsLZE6jMTDTm1VBGjFQhqSyNElBBH2j6AUqt+Fi5aZXwQ81CX28/u FWdVRFeQA+auicyR3axE/WbpmWxM8fXBL9aJcT0esEebfaSLVA28hfb1BxNngVvq 5F4GzT32IwYxrRbadeyegx00ndVzQp7vWyOdlbb5I7cRdIALi1Ikk6tOXbnbFehG bpt9WPWD77YR2UJeKJQmvLfxnBq1wqlVqwLIXGDCk3e2SG0ow6o2n+ekca6qCJ9F r+Zhyc4XM2zBtVK2yd71jVFyWss5G3Xc5b8mBOupdH6CBAcv7cwOpT2Lv/NnktwX 1FkDicHWJcvDCSf/iEbBKKWHrihu2raZoOJPXgqtgy5l0+jNW8Qt8xbGPaUipnVx gFePzwrJkVDmuSxdZ4m1cElkxCA5wo0BejHwU+88RW7zEMFV54iAWt0Yjt8NN/PP CDrqtBCiXJHAUqd1NII6PGRhLee+DokGsWK9GSFKGV/Rf8CYcbCiGSnxNgmx8z7E Hp/wOMdHN0PG4RqWaCJpPFF9HOAQ5Vt5/YaVZJwe42JQ1zLLHIuW6qepEj4N8J6F m2+OIth6aojeyJH+xpl4cygUnUT7TitVKmeuBISaW5s5wOVxr/1Lr50c8INgR6uX 56A2b1STmMUMkDshqcuRKBV9Je8kFOEdgPU/Btsp5uX9GC/jPbHp5WvCwlzAAbn7 MrW4T2CAyH5iMq6864pPEDiUMsZALqE6qRcV3x9qLnbpiEdUswT933LnEAmgmCLu C1FlXZFWpDu6zRZqz1/aNBbrJy1qbmFF0Nqv2ynAbo8iLsY6Ig0MCQ== -----END RSA PRIVATE KEY----- R3(config)#
The first line, oddly enough, is done from configuration mode. The last word in the line is the passphrase for the key for export. Make sure you use the same word at the end of the import line. Now to R4 for the import:
R4(config)#crypto key import rsa GDOI_KEYS pem terminal CISCO1234 % Enter PEM-formatted public General Purpose key or certificate. % End with a blank line or "quit" on a line by itself. -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAeSciKuAgSdzbR+nNeTpSrGfF 6B7wf8Mk+ZS10iBpxWhFOykksg+ffl6GqSLIqifAplFO0mUQUXmowt6U+90lUkzZ Uk60n/Z3/6LjyMEMYxTZxzoZYOAw6YBMNGgE45UeWBw40tg/pjmWd8DKgw1uE6hz 0U2x2xPjhbdQmOVk2wIDAQAB -----END PUBLIC KEY----- quit % Enter PEM-formatted encrypted private General Purpose key. % End with "quit" on a line by itself. -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,1C89433617040F00 48hBYLj3eURGsLZE6jMTDTm1VBGjFQhqSyNElBBH2j6AUqt+Fi5aZXwQ81CX28/u FWdVRFeQA+auicyR3axE/WbpmWxM8fXBL9aJcT0esEebfaSLVA28hfb1BxNngVvq 5F4GzT32IwYxrRbadeyegx00ndVzQp7vWyOdlbb5I7cRdIALi1Ikk6tOXbnbFehG bpt9WPWD77YR2UJeKJQmvLfxnBq1wqlVqwLIXGDCk3e2SG0ow6o2n+ekca6qCJ9F r+Zhyc4XM2zBtVK2yd71jVFyWss5G3Xc5b8mBOupdH6CBAcv7cwOpT2Lv/NnktwX 1FkDicHWJcvDCSf/iEbBKKWHrihu2raZoOJPXgqtgy5l0+jNW8Qt8xbGPaUipnVx gFePzwrJkVDmuSxdZ4m1cElkxCA5wo0BejHwU+88RW7zEMFV54iAWt0Yjt8NN/PP CDrqtBCiXJHAUqd1NII6PGRhLee+DokGsWK9GSFKGV/Rf8CYcbCiGSnxNgmx8z7E Hp/wOMdHN0PG4RqWaCJpPFF9HOAQ5Vt5/YaVZJwe42JQ1zLLHIuW6qepEj4N8J6F m2+OIth6aojeyJH+xpl4cygUnUT7TitVKmeuBISaW5s5wOVxr/1Lr50c8INgR6uX 56A2b1STmMUMkDshqcuRKBV9Je8kFOEdgPU/Btsp5uX9GC/jPbHp5WvCwlzAAbn7 MrW4T2CAyH5iMq6864pPEDiUMsZALqE6qRcV3x9qLnbpiEdUswT933LnEAmgmCLu C1FlXZFWpDu6zRZqz1/aNBbrJy1qbmFF0Nqv2ynAbo8iLsY6Ig0MCQ== -----END RSA PRIVATE KEY----- quit % Key pair import succeeded. R4(config)#
Note how this was imported. The first key (public) was added, then the word “quit” was typed. Then instructions came up asking for the private key. The key was pasted, followed by the word “quit”. Then, we are done. Yay! The keys are now imported successfully, as the boys in Berkeley have just noted.
With keys properly imported, R4 can now be configured:
crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.10.10.1 crypto isakmp key cisco address 10.10.20.2 crypto isakmp key cisco address 10.10.30.3 ! ! crypto ipsec transform-set STRONG esp-aes esp-sha-hmac ! ! Next we do the ACL before creating the GDOI groups ! access-list 101 permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255 ! ! Next we create the exportable keys crypto key gen rsa general-keys exportable label GDOI_KEYS ! ! Now the GDOI fun stuff! ! crypto ipsec profile GDOI set security-association lifetime seconds 1800 set transform-set STRONG ! crypto gdoi group GDOI_GROUP identity number 1 server local rekey retransmit 10 number 2 rekey authentication mypubkey rsa GDOI_KEYS rekey transport unicast sa ipsec 1 profile GDOI match address ipv4 101 replay time window-size 5 address ipv4 10.10.30.4 redundancy local priority 50 peer address ipv4 10.10.30.3
If you look at the highlighted lines, you will see the ISAKMP key now has the other server in it. The address in the profile is for R4, the peer address is R3, and the local priority is 50, which relegates it to the secondary server.
The group members are a bit easier to configure. Here, we have the following steps:
- Define the ISAKMP policy.
- Define the ISAKMP keys to the KS.
- Configure the GDOI group.
- Configure the crypto map.
- Apply the crypto map to an interface.
Because all the IPSec information is handled by the KS, the GMs simply need to make an IKE Phase I connection to the key servers. After the four messages are exchanged, the tunnel is created between all GMs.
R1:
crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.10.30.3 crypto isakmp key cisco address 10.10.30.4 ! crypto gdoi group GDOI_GROUP identity number 1 server address ipv4 10.10.30.3 server address ipv4 10.10.30.4 ! crypto map GDOI_MAP local-address FastEthernet0/0 crypto map GDOI_MAP 10 gdoi set group GDOI_GROUP ! interface FastEthernet0/0 ip address 10.10.10.1 255.255.255.0 speed 100 full-duplex crypto map GDOI_MAP
Thats it! R2 is configured the same way, except that fa0/0 will have an IP address of 10.10.20.2. Otherwise, they are the same. The KS COOP handles all the information about the group members, so the ISAKMP keys only need to have the servers added. This creates an incredibly scalable solution in a multi-site enterprise environment. Once the KS routers are configured, the template for each additional group member is a copy/paste solution. And network people like copy/paste…it increases the ability to get things done with minimal effort.
No configuration is complete without fully verifying functionality. First, verify that phase I is complete from the GM to the KS:
R1#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status 10.10.30.3 10.10.10.1 GDOI_IDLE 1015 0 ACTIVE 10.10.10.1 10.10.30.3 GDOI_REKEY 1016 0 ACTIVE IPv6 Crypto ISAKMP SA R1#
R1 looks good. And R2:
R2#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status 10.10.20.2 10.10.30.3 GDOI_REKEY 1012 0 ACTIVE 10.10.30.3 10.10.20.2 GDOI_IDLE 1011 0 ACTIVE IPv6 Crypto ISAKMP SA R2#
Nice. Send some traffic from the loopback on R1 to the loopback on R2, then look at the IPSec SA:
R1#ping 192.168.2.2 sour 192.168.11.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/144/180 ms
R1#sh crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: GDOI_MAP, local addr 10.10.10.1
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
current_peer port 848
PERMIT, flags={origin_is_acl,}
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.10.10.1, remote crypto endpt.:
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x46AD6F53(1185771347)
inbound esp sas:
spi: 0x46AD6F53(1185771347)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 305, flow_id: SW:305, crypto map: GDOI_MAP
sa timing: remaining key lifetime (sec): (775)
IV size: 16 bytes
replay detection support: Y replay window size: 5
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x46AD6F53(1185771347)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 306, flow_id: SW:306, crypto map: GDOI_MAP
sa timing: remaining key lifetime (sec): (775)
IV size: 16 bytes
replay detection support: Y replay window size: 5
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
R1#
Cool! We see encrypted traffic and decrypted traffic.
Now verify that the KS COOP server is functioning:
R3#sh crypto gdoi ks coop Crypto Gdoi Group Name :GDOI_GROUP Group handle: 2147483650, Local Key Server handle: 2147483650 Local Address: 10.10.30.3 Local Priority: 100 Local KS Role: Primary , Local KS Status: Alive Primary Timers: Primary Refresh Policy Time: 20 Remaining Time: 9 Antireplay Sequence Number: 2757 Peer Sessions: Session 1: Server handle: 2147483655 Peer Address: 10.10.30.4 Peer Priority: 50 Peer KS Role: Secondary , Peer KS Status: Alive Antireplay Sequence Number: 2751 IKE status: Established Counters: Ann msgs sent: 2755 Ann msgs sent with reply request: 2 Ann msgs recv: 2749 Ann msgs recv with reply request: 2 Packet sent drops: 0 Packet Recv drops: 1 Total bytes sent: 1518072 Total bytes recv: 2472067 R3#
Yep, we can see that R3 and R4 are in a primary/secondary relationship. We can also see that both are alive.
In our little scenario, there are two pitfalls. The first one I alluded to earlier. The pitfall comes from the Symmetric ACL that is applied to all of the 192.168.0.0/16 network. So what happens if a PING is sent from R1 to R3 using the loopback interface?
R1#ping 192.168.3.3 sour 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.3.3, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 ..... Success rate is 0 percent (0/5) R1#
Bummer. It fails.
Because the ACL defines that all traffic going from 192.168.0.0/16 to 192.168.0.0/16 is interesting traffic, that traffic must use IPSec to get across. The KS is not a GM, so there is no IPSec tunnel between the KS and the GM, only an ISAKMP tunnel exists. So, traffic from the loopback of R1 is being encrypted to the loopback of R3, but there is no IPSec SA associated with R3. Hence, it fails. One way around this is to use the loopbacks as the endpoints of the tunnel and the source points for the key servers. Then apply the crypto map to the physical interface, but have all the information sourced from the loopback. Then you could have a separate loopback network that is used only for GDOI.
The second pitfall is lab related. All traffic is being routed through R3, which is a KS. This is not best practice for design. Each KS should server ONLY as a KS and not as a KS and a main router. If R3 were to fail, then neither GM can get to R4 due to routing issues. In a multi-site design, best practice would dictate that there would be a KS in different locations. The GMs would then use the KS that is closest by hop count as the primary.
Finally, best practice also dictates that NTP should be used to synchronize time. This is especially important in GDOI, as it uses a time scale for anti-replay protection. Also, if certificates are used with a CA server, NTP MUST be configured. In short, just configure it, will ya?
Good luck!
