Virtual Private Networks (VPNs) provide a highly secure way for customers to share bandwidth over an ISP backbone network. A VPN is a collection of sites sharing a common routing table. A customer site is connected to the service provider network by one or more interfaces, and the service provider associates each interface with a VPN routing table. A VPN routing table is called a VPN routing/forwarding (VRF) table. VRFs are generally associated with MPLS based VPNs.
With the VRF-lite feature, multiple VPN routing/forwarding instances can be supported in customer edge devices. VRF-lite extends limited PE functionality to a CE device, giving it the ability to maintain separate VRF tables to extend the privacy and security of a VPN to the branch office. This also helps the customer to share the same CE for various internal departments while maintaining separate VRF table for each department.
Now, the intention of this document is to enable Cisco IOS GET VPN on the CE's VRF-lite interfaces. Cisco IOS GET VPN is well documented at http://www.cisco.com/go/getvpn.
Document Scope
This document provides deployment guidelines to enable Cisco IOS GET VPN on the VRF-lite interfaces for an enterprise network. This document does not cover in-depth technical details about various features comprising Cisco IOS GET VPN. Please refer to the References section for more details.
Recommended Platforms and Images
Images based on Cisco IOS Software Release 12.4(11)T2 are recommended for both key server and group member routers. The recommended image subset is `adventerprisek9' for both the key server and the group member routers.
Key server: Cisco 2800/3800 Series Integrated Service Routers, Cisco 7200 Series Routers, Cisco 7301 Routers
Group member: Cisco 1800/2800/3800 Series Integrated Service Routers, Cisco 7200 Series Routers, Cisco 7301 Routers
Key server is not VRF aware. So, based on a single or multiple MPLS VPNs (PE VRFs) used in PE for each GETVPN group, there can be two cases.
Case (1): [Refer Figure 1]. PE uses a single MPLS VPN (PE VRF) for all the group member VRFs (CE VRFs). For this, group members can use the same certificate for authentication for all the crypto maps applied on VRF interfaces. No overlapping addresses can be supported in the group member VRFs because the PE has all the group member addresses in a single VRF. However, traffic excluded from any of the encryption policies are subject to be routed across group member VRFs.
Case (2): To use overlapping addresses between group member VRFs, PE should also use a unique MPLS VPN (PE VRFs) for each of the group member VRFs. In addition, a separate key server must be dedicated for each VRF, mainly because the key server is not VRF-aware. For this, group members should also use a separate certificate for authentication for each crypto map. The group member configuration is almost the same as in case 1 except that the additional certificate trustpoints and different key server addresses should be required.
Note: For both cases above, each VRF interface requires a unique crypto map and each crypto map MUST use different GET VPN group. Hence key server must be configured with multiple GET VPN groups to support multiple VRFs in group members.
This deployment focuses on the Case (1), i.e, all the group member VRFs are connected to a single MPLS VPN in PE, hence no overlapping addresses can be used among group member VRFs. For the key server, the additional configuration involves multiple GET VPN groups based on group member VRFs, no other configuration is needed. VRFs are defined only in the group members. Each VRF defined in CE are associated with sub-interfaces between CE-PE links.
VRF "corp" is configured on selective group members only to showcase this deployment, however, resources in this VRF is accessible from other group members which do not use VRF. VRF "engg" is defined only in two group members for this deployment. A separate routing instance is configured for vrf "engg" in these two group members. Management tunnel is setup using a global routing table using loopback interface.
Note: Since no routing protocol is defined for management loopback interface, an exclusive static route is configured in PE and redistributed in MPLS VPN.
The following key server and group member configurations show only the necessary configurations required for GET VPN and VRF Lite. Refer the Full Configuration section for more details.
Key Server Configuration
!!!! The following configuration enables the key server in a router. Each group defined in the key server has an identity that is shared among the members within the group. Here the identity is set to 1234 for group `VRF-CORP' and 5678 for group `VRF-ENGG'. Also VRF-CORP group uses multicast rekeying while VRF-ENGG uses unicast rekeying. !!!
rekey transport unicast // unicast rekeying method //
sa ipsec 1
profile vrf // TEK "AES" defined in profile //
match address ipv4 vrf-acl
replay time window-size 5
address ipv4 10.10.10.23
redundancy // Cooperative key server enabled //
local priority 75
peer address ipv4 10.10.10.56
!
ip access-list extended vrf-acl
permit ip 10.2.1.0 0.0.0.255 10.2.2.0 0.0.0.255
permit ip 10.2.2.0 0.0.0.255 10.2.1.0 0.0.0.255
Note: AES keys are difficult to hack, hence it is highly recommended to use "AES" for Traffic Encryption key (TEK) and Key encryption key (KEK). Also, AES keys can be used for longer duration as shown above using 8 hour TEK lifetime. In addition, AES is used for IKE phase 1 negotiations. However, 3DES is also supported but is not recommended for longer lifetimes.
Group Member Configuration
!!!! Only the necessary commands required to enable VRF lite and GETVPN are shown here. For setting up management interface and more VRF details, refer the Full Configuration section !!!!
!
ip vrf corp // VRF enabled globally //
rd 65002:1
route-target export 65002:1
route-target import 65002:1
!
interface FastEthernet0 // Interface for vrf corp //
description outside interface
ip vrf forwarding corp
ip address 10.10.10.30 255.255.255.248
!
router bgp 65002
!
address-family ipv4 vrf corp // Separate routing instance for vrf corp //
Note: This deployment use different multicast RPs for multicast rekeying and multicast data purpose. The RP used for multicast data is protected by encryption policy and is present behind the group member at corporate network. The RP used for multicast rekeying is configured in MPLS/VPN address space and is not protected by the encryption policy. Refer Verification section on group member for the output.
Verification
Key Server 1:
keyserver1#sh crypto gdoi ks coop
Crypto Gdoi Group Name :VRF-CORP
Group handle: 2147483650, Local Key Server handle: 2147483650
Local Address: 10.10.10.23
Local Priority: 100
Local KS Role: Primary , Local KS Status: Alive
Primary Timers:
Primary Refresh Policy Time: 20
Remaining Time: 9
Antireplay Sequence Number: 883
Peer Sessions:
Session 1:
Server handle: 2147483651
Peer Address: 10.10.10.56
Peer Priority: 75
Peer KS Role: Secondary , Peer KS Status: Alive
Antireplay Sequence Number: 2
IKE status: Established
<Output Omitted >
Crypto Gdoi Group Name :VRF-ENGG
Group handle: 2147483651, Local Key Server handle: 2147483652
Local Address: 10.10.10.23
Local Priority: 75
Local KS Role: Primary , Local KS Status: Alive
Primary Timers:
Primary Refresh Policy Time: 20
Remaining Time: 11
Antireplay Sequence Number: 878
Peer Sessions:
Session 1:
Server handle: 2147483653
Peer Address: 10.10.10.56
Peer Priority: 100
Peer KS Role: Secondary , Peer KS Status: Alive
Antireplay Sequence Number: 0
IKE status: Established
< Output Omitted >
keyserver1#sh crypto gdoi ks policy
Key Server Policy:
For group VRF-CORP (handle: 2147483650) server 10.10.10.23 (handle: 2147483650):
Number of rekeys sent for group VRF-CORP : 0 // Key server is secondary, so no rekeys sent //
Group Member ID : 10.10.10.30
Group ID : 1234
Group Name : VRF-CORP
Key Server ID : 10.10.10.56
Group Member ID : 10.10.10.86
Group ID : 1234
Group Name : VRF-CORP
Key Server ID : 10.10.10.23
Number of rekeys sent for group VRF-ENGG : 0 // Key server is secondary, so no rekeys sent //
Group Member ID : 10.10.10.70
Group ID : 5678
Group Name : VRF-ENGG
Key Server ID : 10.10.10.23
Rekeys sent : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
Group Member ID : 10.10.10.98
Group ID : 5678
Group Name : VRF-ENGG
Key Server ID : 10.10.10.23
Rekeys sent : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
keyserver2#
Group Member 1:
!! The following output shows the multicast RP used for multicast rekeying and multicast data are different. Also the RP is learned through Auto-RP, hence the group member configuration may not reflect this. !!
group-member1#sh ip pim vrf corp rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4 // Multicast data group address //
RP 192.168.1.13 (rp.cisco.com), v2v1
Info source: 192.168.1.13 (rp.cisco.com), elected via Auto-RP
Uptime: 08:29:08, expires: 00:02:02
Group(s) 239.192.1.190/32 // Multicast rekeying group address //
RP 10.10.10.25 (?), v2v1
Info source: 10.10.10.25 (?), elected via Auto-RP
Uptime: 1d19h, expires: 00:02:52
Acl: multicast_rp_blockdensemode, Static
RP: 192.168.1.13 (rp.cisco.com)
group-member1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
172.16.10.1 10.10.10.78 QM_IDLE 2006 0 ACTIVE // Management Tunnel //
10.10.10.56 10.10.10.30 GDOI_IDLE 2005 0 ACTIVE
10.10.10.23 10.10.10.70 GDOI_IDLE 2008 0 ACTIVE
239.192.1.190 10.10.10.23 GDOI_REKEY 2019 0 ACTIVE // Multicast rekey for vrf corp //
10.10.10.70 10.10.10.23 GDOI_REKEY 2018 0 ACTIVE // Unicast rekey for vrf engg //
IPv6 Crypto ISAKMP SA
group-member1#sh crypto gdoi gm
Group Member Information For Group vrf-corp:
IPSec SA Direction : Both
ACL Received From KS : gdoi_group_vrf-corp_temp_acl
Re-register
Remaining time : 3140 secs
Group Member Information For Group vrf-engg:
IPSec SA Direction : Both
ACL Received From KS : gdoi_group_vrf-engg_temp_acl
Re-register
Remaining time : 11246 secs
group-member1#sh crypto gdoi gm rekey
Group vrf-corp (Multicast)
Number of Rekeys received (cumulative) : 164
Number of Rekeys received after registration : 164
Multicast destination address : 239.192.1.190
Group vrf-engg (Unicast)
Number of Rekeys received (cumulative) : 8
Number of Rekeys received after registration : 8
Number of Rekey Acks sent : 8
group-member1#
Group Member 2:
The following ping generated from a pc behind group member 2 on vrf engg.
C:\>ping -n 100 10.2.1.3
Pinging 10.2.1.3 with 32 bytes of data:
Reply from 10.2.1.3: bytes=32 time=40ms TTL=126
Reply from 10.2.1.3: bytes=32 time=42ms TTL=126
Reply from 10.2.1.3: bytes=32 time=42ms TTL=126
.....
Reply from 10.2.1.3: bytes=32 time=42ms TTL=126
Reply from 10.2.1.3: bytes=32 time=41ms TTL=126
Ping statistics for 10.2.1.3:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: FastEthernet0.1
Session status: UP-NO-IKE
Peer: port 848 fvrf: engg ivrf: engg
Desc: (none)
Phase1_id: (none)
IPSEC FLOW: permit ip 10.2.2.0/255.255.255.0 10.2.1.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 100 drop 0 life (KB/Sec) 4529328/1449
Outbound: #pkts enc'ed 100 drop 0 life (KB/Sec) 4529324/1449
IPSEC FLOW: permit ip 10.2.1.0/255.255.255.0 10.2.2.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 4514092/1449
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4514092/1449
Interface: FastEthernet0.1
Uptime: 3d23h
Session status: UP-IDLE
Peer: 10.10.10.23 port 848 fvrf: engg ivrf: engg
Phase1_id: keyserver1.cisco.com
Desc: (none)
IKE SA: local 10.10.10.98/848 remote 10.10.10.23/848 Active
Capabilities:(none) connid:2101 lifetime:6w2d
IKE SA: local 10.10.10.98/848 remote 10.10.10.23/848 Active
Capabilities:D connid:2098 lifetime:18:33:28
IKE SA: local 10.10.10.98/848 remote 10.10.10.23/848 Active
Capabilities:(none) connid:2103 lifetime:6w2d
group-member2#sh crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
2370 10.10.10.102 172.16.10.1 ACTIVE 3des sha rsig 2 23:59:51 D // Management Tunnel //
Engine-id:Conn-id = SW:370
2358 10.10.10.98 10.10.10.23 engg ACTIVE aes sha rsig 2 00:34:37 D
Engine-id:Conn-id = SW:358
2369 239.192.1.190 10.10.10.23 corp ACTIVE aes sha psk 0 0 // KEK using AES //
Engine-id:Conn-id = SW:369
2368 10.10.10.98 10.10.10.23 engg ACTIVE aes sha psk 0 0 // KEK using AES //
Engine-id:Conn-id = SW:368
IPv6 Crypto ISAKMP SA
group-member2#sh crypto gdoi gm rekey
Group vrf-corp (Multicast)
Number of Rekeys received (cumulative) : 263
Number of Rekeys received after registration : 263
Multicast destination address : 239.192.1.190
Group vrf-engg (Unicast)
Number of Rekeys received (cumulative) : 8
Number of Rekeys received after registration : 8
Number of Rekey Acks sent : 8
group-member2#
Limitations / Final Notes
• Key server is not VRF aware.
• Need unique crypto map per group member vrf interface.
• Each crypto map must use different GETVPN group for registration.
• No overlapping addresses can be used between group member VRFs.
• If a group member cannot successfully register with the key server, the group member may transmit all data traffic in clear text. This would allow bridging traffic from one VRF to another within group member through the single PE VRF. The user must deploy necessary outbound ACLs in the group member VRF to protect from sending clear-text traffic. An example ACL "block_clear_text" is given in the Full Configuration section for group member.
• Any traffic excluded from the encryption policy may also be bridged between group member VRFs through the single PE VRF. The user could apply encryption policy for all or most of the enterprise traffic and also use the ACL "block_clear_text" mentioned above.
• When a group member use the same certificate for authenticating multiple VRF sessions, it is not possible to use "authorization" command in the GETVPN group to securely authorize the group member VRF to join the respective GETVPN group.