We really have to talk about GETVPN. Despite its drawbacks, I can’t seem to get it out of my head now and I’m constantly running through scenarios where using it might make sense.
If you’re not too familiar with GETVPN, let me offer this high-level summary of the technology. GETVPN is a technology that allows all endpoints to share a common phase2 Security Association (SA) by building their phase1 tunnels to a shared key server. This keyserver tells all VPN endpoints (referred to as Group Members) about what traffic is to be encrypted, what ciphers to use, etc. The benefit being, if you have two Group Members that have never exchanged information with one another, you don’t have to build a tunnel between them as they will already have a shared/common SA. Anyone who’s ever used ping to bring a tunnel up knows this pain. The first ping always drops right? Not in GETVPN. GETVPN is recommended for securing communication in full mesh networks (like MPLS or DMVPN). So today I thought I’d run through what I think is a fairly practical use of GETVPN, securing DMVPN traffic.
Goals
- Use front-door VRF on all DMVPN devices
- Protect traffic using GETVPN
- Avoid pre-shared-keys for phase 1 tunnels, use certificate authentication instead
Let’s take a quick look at our topology
One annoying caveat to deploying GETVPN is that the Keyserver cannot also be a group member. This means, as in my topology, you have a router who’s not actively going to passing user/data plane traffic in the mix. The good news here, you could probably virtualize this function in the real world leveraging a CSR1000v to be your KS. I’ll also be using my KS as a Certificate Authority (you don’t have to do this, pre-shared-keys work just fine with GETVPN, I just like using certs). At my hub location, I also have an ASA firewall. This will be using NAT to forward both ports 80 (for cert requests to my CA) as well as udp port 848 (GETVPN’s default port for ISAKMP).
Relevant Config from ASAv
interface GigabitEthernet0/0
nameif OUTSIDE
security-level 0
ip address 208.0.0.201 255.255.255.0
!
interface GigabitEthernet0/1
nameif INSIDE
security-level 100
ip address 10.12.12.254 255.255.255.0
summary-address eigrp 47884 0.0.0.0 0.0.0.0 20
!
router eigrp 47884
network 10.0.0.0 255.0.0.0
!
object network KS
host 10.12.12.10
!
object network KS
nat (INSIDE,OUTSIDE) static 208.0.0.254
!
nat (INSIDE,OUTSIDE) after-auto source dynamic any interface
!
access-list OUTSIDE_access_in extended permit udp any object KS eq 848
access-list OUTSIDE_access_in extended permit udp any object KS eq isakmp
access-list OUTSIDE_access_in extended permit udp any object KS eq 4500
access-list OUTSIDE_access_in extended permit tcp any object KS eq www
!
access-group OUTSIDE_access_in in interface OUTSIDE
We shouldn’t have to go back to the ASA to make any additional changes from here on out. Next I’m going to setup my front-door VRF (FVRF) and get all base routing setup for my two hubs and two spokes.
Hub1 and Hub2
vrf definition FVRF
!
address-family ipv4
exit-address-family
!
interface GigabitEthernet0/0
vrf forwarding FVRF
ip address 208.0.0.1 255.255.255.0
!
interface GigabitEthernet0/1
ip address 10.12.12.x 255.255.255.0
!
ip route vrf FVRF 0.0.0.0 0.0.0.0 208.0.0.254
Spoke1 and Spoke2
vrf definition FVRF
!
address-family ipv4
exit-address-family
!
interface GigabitEthernet1
vrf forwarding FVRF
ip address 208.0.0.1 255.255.255.0
!
interface GigabitEthernet2
ip address 10.x0.x0.x 255.255.255.0
!
ip route vrf FVRF 0.0.0.0 0.0.0.0 208.0.0.254
Configuring the KS as a Certificate Authority
Again, this part is optional if you would prefer to use pre-shared-keys. You could also use a Microsoft CA server, something I’ve done in previous posts (e.g. FlexVPN). With that said, let’s quickly run through a basic PKI server setup on our future KS.
clock set [input time/date]
!
ip domain name networkknerd.com
crypto key generate rsa general-keys modulus 2048!
!
crypto pki server KSCA
no database archive
issuer-name CN=KSCA.networkknerd.com
hash sha256
database url flash:
no shutdown
You could also configure your IOS CA to automatically grant certificates requests, but I’m fine with manually granting requests.
Requesting certificates from IOS CA
This is pretty basic, and I’ll provide the config output from Hub1 but it’s copy/paste and find and replace for the configs on the other DMVPN routers. Obviously changing only the fqdn and subject-name values to match.
crypto pki trustpoint KSCA
enrollment retry count 3
enrollment url http://208.0.0.254:80
fqdn Hub1.networkknerd.com
subject-name CN=Hub1.networkknerd.com
vrf FVRF
!
crypto pki authenticate KSCA
% Do you accept this certificate? [yes/no]: yes
!
crypto pki enroll KSCA
% The subject name in the certificate will include: CN=Hub1.networkknerd.com
% The subject name in the certificate will include: Hub1.networkknerd.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]:
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The ‘show crypto pki certificate verbose KSCA’ command will show the fingerprint.
!
[Rise and Repeate on Hub2, Spoke1, and Spoke2]
You’ll also want an RSA signature certificate on the KS, which in our case is also our CA. So back on the KS/CA router issue the following:
crypto pki trustpoint KSCA_sig
enrollment retry count 3
enrollment url http://10.12.12.10:80
fqdn Hub1.networkknerd.com
subject-name CN=KSCA.networkknerd.com
!
crypto pki authenticate KSCA_sig
% Do you accept this certificate? [yes/no]: yes
!
crypto pki enroll KSCA_sig
% The subject name in the certificate will include: CN=KSCA.networkknerd.com
% The subject name in the certificate will include:
KSCA.networkknerd.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]:
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The ‘show crypto pki certificate verbose KSCA’ command will show the fingerprint.
Then from the IOS CA server
crypto pki server KSCA grant all
Configuring the Keyserver
The key server has the unique role of being the only router in our topology other routers (Group Members) will actually build phase 1 tunnels. This can be a little unsettling to look at if you’ve only ever worked with more traditional IPsec deployments, but essentially ‘show crypto isakmp sa’ on your routers will only ever should an SA with the Keyserver. That said the KS is also where most of our GETVPN configurations actually live. First we’ll setup an isakmp policy (NOTE GDOI/GKM does support IKEv2, I’m just using IKEv1 in this lab because I have enough moving peices as is).
ALL ROUTERS (GMs and KS)
crypto isakmp policy 10
encr aes 256
hash sha256
lifetime 28800
You’ll notice I didn’t specify “authentication pre-share”, since I’m using certificates I don’t need this.
KS Configurations
ip access-list extended GKM_PROTECT
permit gre any any
!
ip access-list extended KS
permit ip host 10.12.12.10 any
!
crypto ipsec transform-set ESP-AES256-SHA2 esp-aes 256 esp-sha256-hmac
!
crypto ipsec profile GKM_PROF
set transform-set ESP-AES256-SHA2
!
crypto gkm group GDOI
identity number 47884
server local
rekey algorithm aes 128
rekey sig-hash algorithm sha256
rekey address ipv4 KS
rekey authentication mypubkey rsa KSCA
rekey transport unicast
sa ipsec 1
profile GKM_PROF
match address ipv4 GKM_PROTECT
replay counter window-size 128
no tag
address ipv4 10.12.12.10
First I defined a couple access-lists, GKM_PROTECT is my interesting traffic ACL. Telling GMs to encrypt gre traffic (since this is protecting DMVPN traffic). If you weren’t deploying DMVPN, your ACL here may contain something like “permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255” to protect any IP traffic betwen 10.0.0.0/8 subnets. Then second ACL “KS” is used to specify my rekey address, basically telling GETVPN I want to use 10.12.12.10 to rekey GMs. This can be skipped when multicast is used for rekey transport, but in this lab (since I’m mimicking an Internet deployment style) I’m using unicast for transport.
Next, I’m setting up my phase 2 transform-set, and an IPsec profile calling that transform-set. This information is actually managed by the KS and pushed out to GMs later on. After that I have a fairly basic GETVPN server configuration, however I am changing the default rekey sig-hash to sha256 and rekey encryption algorithm to aes-128.
Group Member Configuration
This configuration is copy/paste, so I’ll only provide the output from one GM, but it needs to be applied to all GMs.
crypto gkm group GDOI
identity number 47884
server address ipv4 208.0.0.254
!
crypto map GETVPN 1 gdoi
set group GDOI
!
interface GigabitEthernet0/0
crypto map GETVPN
Notice how much simpler this configuration compared to the KS. Here we only have to define the server’s address, match the identity number (or address if chose to use that instead) and plug that GKM configuration into a crypto map that’s assigned to our WAN interface. If all is successful you should see some similar output to this:
Apr 23 16:06:22.673: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
Apr 23 16:06:22.679: %CRYPTO-5-GM_REGSTER: Start registration to KS 208.0.0.254 for group GDOI using address 208.0.0.1 fvrf FVRF ivrf FVRF
Apr 23 16:06:22.810: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
Apr 23 16:06:22.821: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0xFDA735C08E607248BF18DCE835ACEE53
Apr 23 16:06:22.824: %GDOI-5-GM_REGS_COMPL: Registration to KS 208.0.0.254 complete for group GDOI using address 208.0.0.1 fvrf FVRF ivrf FVRF
Apr 23 16:06:22.841: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 208.0.0.254 for group GDOI & gm identity 208.0.0.1 fvrf FVRF ivrf FVRF
Now we can run through and do some quick validation on the KS and GM. After that we’ll do our DMVPN configuration and call it a day!
GM Validations:
show crypto gkm gm
Group Member Information For Group GDOI:
IPSec SA Direction : Both
ACL Received From KS : gdoi_group_GDOI_temp_acl
Group member : 208.0.0.1 vrf: FVRF
Local addr/port : 208.0.0.1/848
Remote addr/port : 208.0.0.254/848
fvrf/ivrf : FVRF/FVRF
Version : 1.0.12
Registration status : Registered
Registered with : 208.0.0.254
Re-registers in : 3247 sec
Succeeded registration: 1
Attempted registration: 1
Last rekey from : 0.0.0.0
Last rekey seq num : 5
Unicast rekey received: 0
Rekey ACKs sent : 0
Rekey Received : never
DP Error Monitoring : OFF
IPSEC init reg executed : 0
IPSEC init reg postponed : 0
Active TEK Number : 2
SA Track (OID/status) : disabled
show crypto gkm gm acl
Group Name: GDOI
ACL Downloaded From KS 208.0.0.254:
access-list permit gre any any
ACL Configured Locally:
ACL of default bypass policy for group-key management traffic:
GigabitEthernet0/0: deny udp host 208.0.0.1 eq 848 any eq 848 vrf FVRF
KS Validations:
show crypto gkm ks
Total group members registered to this box: 4
Key Server Information For Group GDOI:
Group Name : GDOI
Re-auth on new CRL : Disabled
Group Identity : 47884
Group Type : GDOI (ISAKMP)
Group Members : 4
Rekey Acknowledgement Cfg: Cisco
IPSec SA Direction : Both
IP D3P Window : Disabled
Split Resiliency Factor : 0
CKM status : Disabled
ACL Configured:
access-list GKM_PROTECT
!
show crypto gkm ks members
Group Member Information :
Number of rekeys sent for group GDOI : 5
Number of retransmits during the last rekey for group GDOI : 0
Duration of the last rekey for group GDOI : 10011 msec
Group Member ID : 208.0.0.1 GM Version: 1.0.12
Group ID : 47884
Group Name : GDOI
Group Type : GDOI (ISAKMP)
GM State : Registered
Key Server ID : 10.12.12.10
Rekeys sent : 5
Rekeys retries : 0
Rekey Acks Rcvd : 5
Rekey Acks missed : 1
Sent seq num : 2 3 4 5
Rcvd seq num : 2 3 4 5
Group Member ID : 208.0.0.2 GM Version: 1.0.12
Group ID : 47884
Group Member Information :
Group Name : GDOI
Group Type : GDOI (ISAKMP)
GM State : Registered
Key Server ID : 10.12.12.10
Rekeys sent : 5
Rekeys retries : 0
Rekey Acks Rcvd : 5
Rekey Acks missed : 0
Sent seq num : 2 3 4 5
Rcvd seq num : 2 3 4 5
Group Member ID : 208.0.0.10 GM Version: 1.0.16
Group ID : 47884
Group Name : GDOI
Group Type : GDOI (ISAKMP)
GM State : Registered
Key Server ID : 10.12.12.10
Rekeys sent : 5
Rekeys retries : 0
Rekey Acks Rcvd : 5
Rekey Acks missed : 0
Group Member Information :
Sent seq num : 2 3 4 5
Rcvd seq num : 2 3 4 5
Group Member ID : 208.0.0.20 GM Version: 1.0.16
Group ID : 47884
Group Name : GDOI
Group Type : GDOI (ISAKMP)
GM State : Registered
Key Server ID : 10.12.12.10
Rekeys sent : 5
Rekeys retries : 0
Rekey Acks Rcvd : 5
Rekey Acks missed : 0
Sent seq num : 2 3 4 5
Rcvd seq num : 2 3 4 5
DMVPN Configuration
Spoiler alert, there’s not much exciting happening here :-). Fairly standard Dual-Hub single cloud DMVPN deployment, with the exception I’m not going to configure any tunnel protection (since we have a crypto map tied to the phyiscal WAN interface protecting traffic via GETVPN). So I’ll share the configurations from Hub1 and Spoke1 below to give you an idea of what the config looks like.
Hub1
interface Tunnel0
ip address 10.255.255.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 1337
ip nhrp shortcut
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel vrf FVRF
!
router eigrp 47884
network 10.0.0.0
Spoke1
interface Tunnel0
ip address 10.255.255.10 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast 208.0.0.1
ip nhrp map multicast 208.0.0.2
ip nhrp map 10.255.255.1 208.0.0.1
ip nhrp map 10.255.255.2 208.0.0.2
ip nhrp network-id 1337
ip nhrp nhs 10.255.255.1
ip nhrp nhs 10.255.255.2 priority 10
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel source GigabitEthernet1
tunnel mode gre multipoint
tunnel vrf FVRF
!
router eigrp 47884
network 10.0.0.0
Annnndddddd that’s it. Really basic, straightforward DMVPN configuration using a front-door VRF and dual hubs. So let’s do some quick validations.
Hub1
show dmvpn | b IPv4 NHRP Details
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
—– ————— ————— —– ——– —–
1 208.0.0.10 10.255.255.10 UP 01:53:19 D
1 208.0.0.20 10.255.255.20 UP 01:52:37 D
!
show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(47884)
H Address Interface Hold Uptime
(sec) (ms) Cnt Num
4 10.255.255.20 Tu0 11 00:06:04
3 10.255.255.10 Tu0 13 00:06:15
2 10.12.12.10 Gi0/1 12 05:44:28
1 10.12.12.2 Gi0/1 13 05:46:00
0 10.12.12.254 Gi0/1 12 05:46:09
show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(47884)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
4 10.255.255.20 Tu0 11 00:06:04 14 1398 0 6
3 10.255.255.10 Tu0 13 00:06:15 16 1398 0 7
2 10.12.12.10 Gi0/1 12 05:44:28 4 100 0 7
1 10.12.12.2 Gi0/1 13 05:46:00 79 474 0 23
0 10.12.12.254 Gi0/1 12 05:46:09 8 100 0 11
Spoke1
show dmvpn | b IPv4 NHRP Details
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
—– ————— ————— —– ——– —–
1 208.0.0.1 10.255.255.1 UP 01:56:37 S
1 208.0.0.2 10.255.255.2 UP 01:56:32 S
!
show ip route | b Gateway
Gateway of last resort is 10.255.255.2 to network 0.0.0.0
D* 0.0.0.0/0 [90/26880512] via 10.255.255.2, 00:09:36, Tunnel0
[90/26880512] via 10.255.255.1, 00:09:36, Tunnel0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.10.10.0/24 is directly connected, GigabitEthernet2
L 10.10.10.1/32 is directly connected, GigabitEthernet2
D 10.12.12.0/24 [90/26880256] via 10.255.255.2, 00:09:36, Tunnel0
[90/26880256] via 10.255.255.1, 00:09:36, Tunnel0
C 10.255.255.0/24 is directly connected, Tunnel0
L 10.255.255.10/32 is directly connected, Tunnel0
!
ping 10.20.20.1 source gig2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!!!
!
show dmvpn | b IPv4 NHRP Details
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:3,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
—– ————— ————— —– ——– —–
2 208.0.0.20 10.255.255.20 UP 00:00:23 DT1
10.255.255.20 UP 00:00:23 DT1
1 208.0.0.1 10.255.255.1 UP 02:00:16 S
1 208.0.0.2 10.255.255.2 UP 02:00:11 S
!
show ip route | b Gateway
Gateway of last resort is 10.255.255.2 to network 0.0.0.0
D* 0.0.0.0/0 [90/26880512] via 10.255.255.2, 00:13:31, Tunnel0
[90/26880512] via 10.255.255.1, 00:13:31, Tunnel0
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C 10.10.10.0/24 is directly connected, GigabitEthernet2
L 10.10.10.1/32 is directly connected, GigabitEthernet2
D 10.12.12.0/24 [90/26880256] via 10.255.255.2, 00:13:31, Tunnel0
[90/26880256] via 10.255.255.1, 00:13:31, Tunnel0
H 10.20.20.0/24 [250/255] via 10.255.255.20, 00:00:56, Tunnel0
C 10.255.255.0/24 is directly connected, Tunnel0
L 10.255.255.10/32 is directly connected, Tunnel0
H 10.255.255.20/32 is directly connected, 00:00:56, Tunnel0
Notice that there was no ping lost during the dynamic tunnel creation between Spoke 1 and Spoke 2, since there was no latency caused by IPsec negotiation. Exactly the key reason WHY GETVPN is so cool, and why we had to spend a few minutes talking about it today. I’m uploading all the configs below if you want to test this out on your own… and I might even do a short video recapping all the above.
