Nov
21

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.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

8 Responses to “Minimalistic GET VPN Example”

 
  1. fonesurj says:

    We have deployed close to 1000 sites on GET. It is really important you follow the GET deployment guide. We have run into a number of scenarios that cause get to fail. The deployment guide compensates for most of these.

    Also, if you are using anything before 12.4(15)T9, then you MUST have the GMs use the local loopback as their peer point, or GET will not recover after a circuit bounce.

  2. Tacack says:

    Great article Petr. Always a fan! :)

  3. SecLearner says:

    Would have preferred a small topology diagram. Are R4 and R5 connected using 173.1.45.x? I used the topology that came with the VOD and I think I put the GETVPN_MAP in the wrong interface. I could not see the traffic go through the VPN and saw ping timeouts.

    Otherwise, please keep them coming. I love it.

    SecLearner.

  4. Anantha Subramanian Natarajan says:

    Thank you petr for the article …..

    Regards
    Anantha Subramanian Natarajan

  5. Anon says:

    Just looking at this, if either site fails you will lose connectivity to the other as well?

    i.e. In a small business environment where potentially only 3-10 locations backing onto a private WAN/MPLS cloud.

    In smaller environments you wouldn’t have the extra routers to act as a dedicated KS so they will double as GM in this sort of setup.

    Given that for RtrA to be a GM, it needs to register to RtrB and vice versa it seems GetVPN is actually reducing redundancy in that scenario.

    Only way around it I can think would be to have at least 3 KS operational so a single site failure does not bring down two sites.

  6. Adrian says:

    Hi, quick question:

    So if I use just one Member Server there is NO way, the KEY server is able to encrypt/decrypt user traffic ? They just provide ipsec policies? Thanks.

  7. peter says:

    Good stuff !

  8. [...] A Minimalist GET VPN Example [...]

 

Leave a Reply

Categories

CCIE Bloggers