As I have promised I would present the basic configuration process of GET VPN.

In the production enviroment GET VPN technology will be deployed over MPLS WAN. In case MPLS network, CE routers exchange routing with PE routers so pure IP communications is achived between LAN to LAN (branch to branch). Additionaly each CE is aware that to route the traffic to specific CE (to CE’s MPLS interface IP) it has to push the traffic towards MPLS cloud.

We can imagine that my example presents part of MPLS WAN with Group Members (GM) as R2, R3 and Key Server (KS) as R4 that is located somewhere in Company HQ DC. To simplify the lab enviroment all GM routers are placed in one 10.0.0.0/24 subnet, GM example will be configured on R2 (R1 and R3 will be configured similar, just different keys used). The main propose of GET VPN is to establish secure, efficient on demand any to any connectivity across private WAN. In the following example we achived encryption for branch to branch traffic (assumed that 10.0.x.x/16 IP addressing is used for branches).

Below IP addressing and LAB diagram:

  • R1 (GM) – 10.0.0.1
  • R2 (GM) – 10.0.0.2
  • R3 (GM) – 10.0.0.3
  • R4 (KS) – 10.0.14.4

Here you can find basic configuration steps to properly setup GET VPN architecture:

Group Member configuration

1. Internet Key Exchange (IKE) Phase 1

The same like in pure IPsec VPN we have to define ISAKMP policy on each GM and KS, so specify the encryption and hash algorithm, authentication method, Diffie-Hellman group and lifetime. As always all IKE Phase 1 parameters must match both sides to successfully established Phase 1.

I’m going to use 3DES as encryption algorithm and pre-share keys as authentication method, remaining will be default.
R2(config)#crypto isakmp policy 100
R2(config-isakmp)# encr 3des
R2(config-isakmp)# authentication pre-share
R2#show crypto isakmp policy
Global IKE policy
Protection suite of priority 100
encryption algorithm: Three key triple DES
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

It is possible to use the same pre-share key in whole GET VPN enviroment then each GM and KS needs just one kind of default pre-share key definition that looks like this one:
crypto isakmp key KEY address 0.0.0.0 0.0.0.0
Of course it is less secure solution then different key for each GM, but the best way of course is PKI architecture. For the LAB propose I use the different KEY for each GM. On R2 we have to defined KEY with peer address as KS so it will 10.0.14.4 IP address.
R2(config)#crypto isakmp key 0 R2-KEY address 10.0.14.4
The same key has to be configured on the KS with R2 as GM peer IP address 10.0.0.2.

2. Group Domain of Interpretation (GDOI) definition

After ISAKMP policy configuration we have to define GDOI on GM. Just two parameters are needed to properly define GDOI group on GM:

  • GDOI group identity number
  • KS IP address for that specific GDOI

R2(config)#crypto gdoi group GDOI-GROUP
R2(config-gdoi-group)#identity number 777
R2(config-gdoi-group)#server address ipv4 10.0.14.4

The GDOI-GROUP has been defined with identity number 777 that uniquely assign GMs to specific GDOI group on the KS and allows push the proper IPsec policy to them. Additionaly KS IP address has been configured, then GMs are aware to which KS they have to register.

3. GDOI crypto map configuration on GM
GDOI crypto map needs to be defined and GDOI-GROUP configured in point 2 is connected here.

R2(config)#crypto map GETVPN-MAP 100 gdoi
% NOTE: This new crypto map will remain disabled until a valid
group has been configured.
R2(config-crypto-map)#set group GDOI-GROUP

4. Apply GDOI crypto map to interface
The last step for GM is similar to the standard IPsec configuration, apply the crypto map to the external interface.
R2(config)#int fa0/0
R2(config-if)#crypto map GETVPN-MAP

As we see configuration of GET VPN and all IPsec parameters for GM is minimalized and thanks to this we have simply, fast and straight GET VPN deployment for CE routers. All IPsec policy is configured centrally on Key Server. Let’s take a look on the configuration of management router – Key Server.

Key Server configuration

1. Internet Key Exchange (IKE) Phase 1

As you are aware all IKE Phase 1 parameters must match both sides to successfully established Phase 1, so like on GM we have to define the same IKE policy here on KS:
R4(config)#crypto isakmp policy 100
R5(config-isakmp)# encr 3des
R4(config-isakmp)# authentication pre-share

As we have used the pre-share key authentication on GMs here we have to defined keys for each GM.
R4(config)#crypto isakmp key R1-KEY address 10.0.0.1
R4(config)#crypto isakmp key R2-KEY address 10.0.0.2
R4(config)#crypto isakmp key R3-KEY address 10.0.0.3

2. IPsec Phase 2 parameters – IPsec SA (transform-set and ipsec profile)
IPsec transofrm set defines the true IPsec encryption and authentication algorithms. 3DES and SHA with ESP have been used here. This IPsec policy will be part of GET VPN policy for specific GDOI group.
R4(config)#crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
IPsec transform set is defined under ipsec profile named GETVPN-PROFILE.
R4(config)#crypto ipsec profile GETVPN-PROFILE
R4(ipsec-profile)# set transform-set TRANSFORM-SET

3. Group Domain of Interpretation (GDOI) definition

RSA keys generation
First of all we have to generate the RSA keys. RSA key is generated only on the KS and is used to authenticate and sign rekey messages. The public key is sent to GMs at the registration. KS signs the rekeys with the private key and GMs verify the rekey messages using the public key. Additonaly public key of first KS has to be used by other KSs in case we would use redundant solution and ensure fault recovery architecture with more then one KS, this option is called as cooperative (COOP) KS. In case RSA keys need to be generated in exportable form and then imported to the redundant KSs.
R4(config)#crypto key generate rsa general-keys label GETVPN-R4-KS modulus 1024 exportable
The name for the keys will be: GETVPN-R4-KS
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be exportable...[OK]
R4(config)#

GDOI group identity – config-gdoi-group mode
Once we have generated KS’s RSA keys we are able to start true GDOI group configuration, all configuration will be done under config-gdoi-group mode. First we have to confiugre the same identity number that we have deifned on GM, it’s 777:
R4(config)#crypto gdoi group GDOI-GROUP
R4(config-gdoi-group)#identity number 777

Local Key Server identification – gdoi-local-server mode
To designate a device as GDOI KS and enter GDOI local server configuration mode we have to enter server local command, then we will be able to configure all GDOI parameters that are related to the IPsec and rekey policy:
R4(config-gdoi-group)#server local
R4(gdoi-local-server)#

GDOI Rekey configuration
First step in GDOI policy is rekey parameters configuration, rekey authentication key pair (PKI or localy stored) and Key Server source address for rekey messages are required values to configure, additionaly we can define rekey retransmit timers.
R4(gdoi-local-server)#rekey authentication mypubkey rsa GETVPN-R4-KS
R4(gdoi-local-server)#address ipv4 10.0.14.4
R4(gdoi-local-server)#rekey retransmit 10 number 3

10.0.14.4 IP has been defined as source IP for rekey messages, localy generated RSA keys in point 3 will be used to authenticate rekey messages, additionaly rekey mechanism will be send with three retransmits at 10 second intervals.

IPsec policy configuration for the GDOI group
The IPsec policy defined under GDOI group at KS will be downloaded to all GMs. This global policy will exactly provides the IPsec parameters for phase 2. Policy defines IPsec encryption, authentication algorithms and define the crypto ACL that says interesting traffic for encryption, so it’s exactly what have been missed on GMs. So all what have been configured on each peer in case of pure IPsec site to site VPN now is confiugred only on the KS. We are able to manage and provision configuration from just one point of network to all GMs.

To configure the IPsec policy we have to first define the crypto ACL, we have to exclude the GDOI protocol and OSPF from the interesting traffic for IPsec encryption:

R4(config)#ip access-list extended CRYPTO-ACL
R4(config-ext-nacl)#deny udp any eq 848 any eq 848
R4(config-ext-nacl)#deny tcp any host 224.0.0.5
R4(config-ext-nacl)#deny tcp any host 224.0.0.6
R4(config-ext-nacl)#permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

Having ACL in place we can define the IPsec policy for GDOI group, we bind ipsec profile GETVPN-PROFILE that defines the transofrm set and crypto acl together under IPsec Security Association:

R4(config-ext-nacl)#crypto gdoi group GDOI-GROUP
R4(config-gdoi-group)#server local
R4(gdoi-local-server)# sa ipsec 1
R4(gdoi-sa-ipsec)#profile GETVPN-PROFILE
R4(gdoi-sa-ipsec)#match address ipv4 CRYPTO-ACL

That’s all GET VPN configured, up and running. Let’s see completed R4 configuration that is related to the GET VPN:
ip domain name netcontractor.pl
!
crypto isakmp policy 100
encr 3des
authentication pre-share
crypto isakmp key R1-KEY address 10.0.0.1
crypto isakmp key R2-KEY address 10.0.0.2
crypto isakmp key R3-KEY address 10.0.0.3
!
crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
!
crypto ipsec profile GETVPN-PROFILE
set transform-set TRANSFORM-SET
!
crypto gdoi group GDOI-GROUP
identity number 777
server local
rekey retransmit 10 number 3
rekey authentication mypubkey rsa GETVPN-R4-KS
rekey transport unicast
sa ipsec 1
profile GETVPN-PROFILE
match address ipv4 CRYPTO-ACL
replay counter window-size 64
address ipv4 10.0.14.4
!
ip access-list extended CRYPTO-ACL
deny udp any eq 848 any eq 848
deny tcp any host 224.0.0.5
deny tcp any host 224.0.0.6
permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

To see the configuration of the GDOI group:
R4#show crypto gdoi group GDOI-GROUP
Group Name : GDOI-GROUP (Unicast)
Group Identity : 777
Group Members : 2
IPSec SA Direction : Both
Active Group Server : Local
Group Rekey Lifetime : 86400 secs
Group Rekey
Remaining Lifetime : 84481 secs
Rekey Retransmit Period : 10 secs
Rekey Retransmit Attempts: 3
Group Retransmit
Remaining Lifetime : 0 secs
IPSec SA Number : 1
IPSec SA Rekey Lifetime: 3600 secs
Profile Name : GETVPN-PROFILE
Replay method : Count Based
Replay Window Size : 64
SA Rekey
Remaining Lifetime : 1682 secs
ACL Configured : access-list CRYPTO-ACL
Group Server list : Local

To see reigsitered GMs:
R4#show crypto gdoi ks members
Group Member Information :
Number of rekeys sent for group GDOI-GROUP : 1
Group Member ID : 10.0.0.2
Group ID : 777
Group Name : GDOI-GROUP
Key Server ID : 10.0.14.4
Rekeys sent : 1
Rekeys retries : 3
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 1 2 3 4
Rcvd seq num : 0 0 0 0
Group Member ID : 10.0.0.3
Group ID : 777
Group Name : GDOI-GROUP
Key Server ID : 10.0.14.4
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0

I hope this post will be helpfull to understand the base configuration steps for the GET VPN with pre-share keys.

, ,
Trackback

4 comments untill now

  1. WP Themes @ 2010-08-14 05:41

    Good post and this enter helped me alot in my college assignement. Gratefulness you seeking your information.

  2. College Gift @ 2010-09-22 16:23

    Excellent blog! I genuinely love how it’ s easy on my eyes and also the details are well written. I am wondering how I could be notified whenever a new post has been made. I have subscribed to your rss feed which should do the trick! Have a nice day!

  3. Please leverage RSS Feed image above search field or use RSS link at the footer.

    Thanks,
    NetContractor

  4. Great post m8, good job 🙂

Add your comment now

You must be logged in to post a comment.