Some time ago I mentioned that it is possible to configure a functional GET VPN scenario using just two routers. Normally, GET VPN requires a dedicated Key Server, which does not participate is user traffic encryption and only distributes keying information and encryption policies. All other routers – group members – register to the Key Server. A router could not register to itself when configured as a key server and group member simultaneously. However, there is a Key Server redundancy feature known as KOOP Key Servers that allows for two servers to synchronize the keying information and the group member to register to the redundant key servers.

Relying upon this feature, we may take two routers and configure them both in a KOOP key server pair. At the same time, every router is configured as a Group Member registering to another router. Since the keying information is being kept in sync, both routers will be able to properly exchange encrypted GET VPN traffic. Now, for the practical implementation we chose two directly connected routers: R4 and R5. GET VPN is supposed to encrypt traffic sent off respective VLAN4 and VLAN5 interfaces of these routers destined to the multicast groups in range 232.0.0.0/8. The IP addresses for VLAN4 and VLAN5 subnets are 173.X.4.0/24 and 173.X.5.0/24. Here is how we configure R4 for Key Server functionality. Notice the redundancy configuration using R5 as the peer.

KS-R4:

crypto isakmp keepalive 10 periodic

!

crypto isakmp policy 50

  encr 3des

  hash md5

  group 2

  authentication pre-share 
crypto isakmp key CISCO address 150.1.5.5
crypto ipsec transform-set GETVPN_TS esp-3des esp-md5-hmac 
crypto ipsec profile GETVPN_PROFILE

  set transform-set GETVPN_TS

!

crypto key generate rsa general-keys label GETVPN_KEYS modulus 1024 exportable

!

no access-list 100

access-list 100 permit ip 173.1.4.0 0.0.0.255 232.0.0.0 0.255.255.255

access-list 100 permit ip 173.1.5.0 0.0.0.255 232.0.0.0 0.255.255.255

!

crypto gdoi group GETVPN_GROUP

  identity number 1234

  server local

  rekey authentication mypubkey rsa GETVPN_KEYS

  rekey transport unicast

  sa ipsec 1

   profile GETVPN_PROFILE

   match address ipv4 100

   replay time window-size 5

  address ipv4 150.1.4.4

   redundancy

    local priority 100

    peer address ipv4 150.1.5.5

Now an important thing. GET VPN uses RSA signatures to authenticate GET VPN keying information. Because of that, both R4 and R5 should use the same private/public keys for signing. To accomplish this, export the keys from the first KS and import them in the second. For example, considering R4 was configured as the first KS, you may use the commands below to export/import RSA keys using IOS CLI (don’t forget the blank line between the public and private keys when importing).

Export Keys at R4:

crypto key export rsa GETVPN_KEYS pem terminal 3des CISCO1234 
Import Keys at R5:

crypto key import rsa GETVPN_KEYS pem exportable terminal CISCO1234

After you have imported the RSA keys in R5, configure R5 for the Key server functionality. Notice that the imported key pair is used for GET VPN keying information signing.

KS-R5:

crypto isakmp keepalive 10 periodic

!

crypto isakmp policy 10

  encr 3des

  hash md5

  group 2

  authentication pre-share 
crypto isakmp key CISCO address 150.1.4.4
crypto ipsec transform-set GETVPN_TS esp-3des esp-md5-hmac 
crypto ipsec profile GETVPN_PROFILE

  set transform-set GETVPN_TS

!

access-list 100 permit ip 173.1.4.0 0.0.0.255 232.0.0.0 0.255.255.255

access-list 100 permit ip 173.1.5.0 0.0.0.255 232.0.0.0 0.255.255.255

!

crypto gdoi group GETVPN_GROUP

  identity number 1234

  server local

  rekey authentication mypubkey rsa GETVPN_KEYS

  rekey transport unicast

  sa ipsec 1

   profile GETVPN_PROFILE

   match address ipv4 100

   replay time window-size 5

  address ipv4 150.1.5.5

    redundancy

    local priority 50

    peer address ipv4 150.1.4.4

This completes the KOOP Key Server configuration part. The next part, which is relatively simple, is configuring both routers as group members. As a group member, R4 should register to R5 and vice versa. Notice that there could be a separate ISAKMP policy used for GM/KS communications, but we just re-use the same settings.

GM-R4:

crypto isakmp policy 50

 encr 3des

 hash md5

 authentication pre-share

 group 2

!

crypto gdoi group GETVPN_GROUP_GM

 identity number 1234

  server address ipv4 150.1.5.5
crypto map GETVPN_MAP local-address Loopback0

crypto map GETVPN_MAP 10 gdoi

  set group GETVPN_GROUP_GM

!

interface Serial0/1/0

  crypto map GETVPN_MAP 
GM-R5:

crypto isakmp policy 50

 encr 3des

 hash md5

 authentication pre-share

 group 2

!

crypto gdoi group GETVPN_GROUP_GM

 identity number 1234

  server address ipv4 150.1.4.4
crypto map GETVPN_MAP local-address Loopback0

crypto map GETVPN_MAP 10 gdoi

  set group GETVPN_GROUP_GM

!

interface Serial0/1/0

  crypto map GETVPN_MAP

Both GM crypto-maps use Loopback0 as the source interface, but this only affects the ISAMP phase, as GET VPN by design simply copies the original header. The last two steps complete the two-node GET VPN configuration. Now for verification. – start by checking for KOOP KS:

Rack1R4#show crypto gdoi ks 

Total group members registered to this box: 1
Key Server Information For Group GETVPN_GROUP:

    Group Name               : GETVPN_GROUP

    Group Identity           : 1234

    Group Members            : 1

    IPSec SA Direction       : Both

    ACL Configured:

        access-list 100

    Redundancy               : Configured

        Local Address        : 150.1.4.4

        Local Priority       : 100

        Local KS Status : Alive

        Local KS Role : Primary
Rack1R5#show crypto gdoi ks 

Total group members registered to this box: 2
Key Server Information For Group GETVPN_GROUP:

    Group Name               : GETVPN_GROUP

    Group Identity           : 1234

    Group Members            : 2

    IPSec SA Direction       : Both

    ACL Configured:

        access-list 100

    Redundancy               : Configured

        Local Address        : 150.1.5.5

        Local Priority       : 50

        Local KS Status : Alive

        Local KS Role : Secondary

Check the data-plane status (IPSec SAs):

Rack1R4#show crypto gdoi ipsec sa 
SA created for group GETVPN_GROUP:
SA created for group GETVPN_GROUP_GM:

  Serial0/1/0:

    protocol = ip

      local ident  = 173.1.4.0/24, port = 0

      remote ident = 232.0.0.0/8, port = 0

      direction: Both, replay(method/window): Time/5 sec

    protocol = ip

      local ident  = 173.1.5.0/24, port = 0

      remote ident = 232.0.0.0/8, port = 0

      direction: Both, replay(method/window): Time/5 sec
Rack1R5#show crypto gdoi ipsec sa 
SA created for group GETVPN_GROUP:
SA created for group GETVPN_GROUP_GM:

  Serial0/1/0:

    protocol = ip

      local ident  = 173.1.4.0/24, port = 0

      remote ident = 232.0.0.0/8, port = 0

      direction: Both, replay(method/window): Time/5 sec

    protocol = ip

      local ident  = 173.1.5.0/24, port = 0

      remote ident = 232.0.0.0/8, port = 0

      direction: Both, replay(method/window): Time/5 sec

Now initiate some multicast traffic and ensure it is getting encrypted: The test below assumes R4 has joined the respective multicast group:

Rack1R5#ping 232.1.1.1 source fastEthernet 0/1 repeat 100
Type escape sequence to abort.

Sending 100, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 173.1.5.5 
Reply to request 0 from 173.1.45.4, 40 ms

Reply to request 1 from 173.1.45.4, 36 ms
Rack1R4#show crypto ipsec sa
interface: Serial0/1/0

    
  
  
  
  
   protected vrf: (none)

   local  ident (addr/mask/prot/port): (173.1.5.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (232.0.0.0/255.0.0.0/0/0)

   current_peer 0.0.0.0 port 848

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

    #pkts decaps: 107, #pkts decrypt: 107, #pkts verify: 107

    #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.: 150.1.4.4, remote crypto endpt.: 0.0.0.0

     path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0

     current outbound spi: 0xF66A6278(4134167160)

     PFS (Y/N): N, DH group: none
     inbound esp sas:

      spi: 0xF66A6278(4134167160)

        transform: esp-3des esp-md5-hmac ,

        in use settings ={Tunnel, }

        conn id: 2011, flow_id: FPGA:11, sibling_flags 80000040, crypto map: GETVPN_MAP

        sa timing: remaining key lifetime (sec): (2387)

        IV size: 8 bytes

        replay detection support: Y  replay window size: 5

        Status: ACTIVE
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:

      spi: 0xF66A6278(4134167160)

        transform: esp-3des esp-md5-hmac ,

        in use settings ={Tunnel, }

        conn id: 2012, flow_id: FPGA:12, sibling_flags 80000040, crypto map: GETVPN_MAP

        sa timing: remaining key lifetime (sec): (2387)

        IV size: 8 bytes

        replay detection support: Y  replay window size: 5

        Status: ACTIVE
     outbound ah sas:
     outbound pcp sas:

This final test ensures that our two-node configuration is working. Finally, this type of configuration is just a curious example, which probably has little application in real life, where you probably want a dedicated GET VPN Server. However, from the CCIE Security Lab standpoint it is important to understand the interaction between GET VPN components and know the little tricks that could be used.