GETVPN

CCIE Security GET VPN Quick Overview
CCIE&CCSI: Yasser Ramzy Auda
Cisco IOS GETVPN (Group Encrypted Transport VPN) Solution

Why we need GETVPN?
We used to use tunnel interfaces in crypto map , SVTI , DVTI , DMVPN etc and this lead to have
some limitations when we apply QoS and other services , and solution was GET VPN.
So First of all GET VPN is not DMVPN but we can call it "VPN without Tunnels" , yes we will not
use tunnel interface in this VPN Solution since It uses the core network's ability to route and
replicate the packets between various sites within the enterprise. GETVPN designed for WAN
enterprise networks such as IP/MPLS/MPLS-VPN networks
-it is largely suited for an enterprise running over a private Multiprotocol Label
Switching (MPLS)/IP-based core network.
-It is also better suited to encrypt multicast traffic.
-It ensure low latency and jitter by enabling full-time/direct communications between
sites, without requiring transport through a central hub.
-It allows replication of the packets after encryption. This allows the multicast traffic to
be replicated at the core, thereby reducing the load and band width requirement on the
Customer Premises Equipment (CPE).
-IP Address Preservation enables encrypted packets carry the original source and
destination IP addresses in the outer IP header rather than replacing them with tunnel
endpoint addresses. This technique is known as IPSec Tunnel Mode with Address
Preservation.
-DMVPN using tunnels so implement QoS will be possible but with some limitations
since New IPsec ip header is added while GETVPN can make use of QoS without any
limitations since it keep the original IP Header
What are the components of GETVPN?

Key Server (KS): distribute the encryption key to all the group members. Minimum one KS is
required for a GETVPN deployment. But using two KS for redundancy will be better.
KS also known as Group Control/Key sever (GCKS).
Group Member (GM): encrypt/decrypt the traffic, Since all GMs use the same key, any GM can
decrypt the traffic encrypted by any other GM.
Group Domain of Interpretation (GDOI) protocol: used between the GM and KS for group key
and group SA management , Its use UDP port# 848 and occur between IKE Phase 1 and 2, it is
not used between GMs but only between every GM and KS
Simply, Hub and Spokes in GETVPN are seen as trusted group members GMs and we have one
or more KS authenticate GMs and share/Maintains the group key to all GMs and send Policies
to each GM , policy is telling GM what to encrypt , what encryption algorithm to use and what
key is going to be used by this algorithm .
How GDOI protocol working?

-used for Group key and group SA management.
-uses ISAKMP for authenticating the GMs and KSs.using pre-shared or RSA certificate
-All the necessary crypto policies are configured only on the KS. This includes the crypto access
list, crypto policies, life times etc.
Simply, GDOI protocol will let KS and GM communicate with each other by sending polices &
distribute the keys
How GETVPN components act with each others?
-GMs registers with the KS to get the IPSec SA that is necessary to encrypt data traffic
within the group.
-each GM provides the group ID to the KS to get the respective policy and keys for this
group.
-These keys are refreshed periodically by KS, and before the current IPSec SAs expire, so
that there is no loss of traffic.
-KS is responsible for maintaining security policies, authenticating the GMs and
providing the session key for encrypting traffic.
-KS authenticates the individual GMs at the time of registration.
-KS verifies the group id number of the GM. If this id number is a valid and the GM has
provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA
policy and the Keys to the group member.
Typically the KS is installed in the data center of the customer network. The CPE routers
connecting to the MPLS core is configured as GMs. The KS should be reachable from all GMs
through the core or the enterprise network.
The steps below explain protocol flows that are necessary for Group Members to participate in a
GETVPN group:
1. Once the GM boots up, it attempts to register with the KS using the GDOI protocol.
2. Registration goes through after successful mutual authentication.
3. After successful registration GM receives KEK and TEK keys.
4. GMs can now encrypt and decrypt the packets as specified by the SA.
5. KS keeps track of the SA life time. It sends rekey information when the current SA is about to
expire.
Rekey information includes the new SA and session key details. Rekey messages are sent in
advance of the SA expiration time to ensure that valid group keys are always available.
Remember, KS keep track SA life time , will send rekey information (new SA/new session key )
when current SA is about to expire
TEK & KEK Keys & rekey Distributed Methods :

GMs receive two keys from KS , (TEK & KEK Keys ):
KEK : used by GM for GDOI negotiation control messages protection
simply , used to encrypt messages between KS & GM such as rekey messages.
TEK: used by GM to encrypt/decrypt data send/received to/from other GM
The KS is not only responsible for creating the encryption policies and keys, but also for
refreshing keys and distribute them to GMs.
The process of sending out new keys when existing keys are about to expire, is known as the
rekey process.
Keys distributed during rekey using Multicast or Unicast:
Multicast allow for Bandwidth conservation, more scalable , but KS will not receive ACK from
GM to that he received the keys.
To use multicast transport for rekeying, the entire network must be multicast capable, including
the MPLS/IP core. That means Multicast VPN (MVPN) is required on the MPLS core.
(anyway MVPN is beyond CCIE Security blueprint and fall in CCIE SP blueprint .)
Unicast will allow KS to receive ACK from GM , additionally KS will delete GM from its database
if three rekeys are not acknowledged by that GM .
GETVPN provide replay attack protection using the following process :
GM sync time with KS
Sender GM time stamp all outgoing packets
Receiver GM check that time stamp & should be within acceptable range such as 10
sec
If not packet will be dropped
GET VPN Solution Comparison
Note: VPN addresses must be routable in the transport network. This is because of the use of
the original IP header, and in most cases, it prevents GET VPNs from being used over the
Internet. Check the picture next page.
This Limitation is important to remember when use GETVPN especially when we use GETVPN
VRF Aware.
Important things to remember when to use multicast or unicast rekey transport:

If all members of a group are multicast capable, use no rekey transport unicast (this means
that multicast rekeying will be used).
If all the members of a group are only unicast capable, use rekey transport unicast.
if there is a mix of members in a group, and the majority of the members are multicast
capable and only a few are unicast capable, use no rekey transport unicast.
GET VPN & IPv6
GETVPN support for IPv6 - from 15.2(3)T
- Secures IPv6 traffic in the data plane
- Control Plane is still IPv4
- Implies GMs must be dual-stack devices
- Group can be only configured for v4 or v6 IP no mixed modes
To ensure that all devices are capable of IPv6 support :
show crypto gdoi feature ipv6-crypto-path
Configuration is almost the same as in IPv4 GETVPN we just change ipv4 keyword to ipv6:
crypto gdoi group ipv6 group_name
crypto map ipv6 MAP1 seq_nr gdoi
Lab 1 GETVPN with single KS
Basic Configuration
R2
int s1/0
ip add 10.1.24.2 255.255.255.0
no sh
int s1/1
ip add 10.1.25.2 255.255.255.0
no sh
int f0/0
ip add 10.1.12.2 255.255.255.0
no sh
R4
int s1/0
ip add 10.1.24.4 255.255.255.0
no sh
int loop 0
ip add 192.168.4.4 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.1.24.2
R5
int s1/1
ip add 10.1.25.5 255.255.255.0
no sh
int loop 0
ip add 192.168.5.5 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.1.25.2
R1
int f0/0
ip add 10.1.12.1 255.255.255.0
no sh
int loop0
ip add 192.168.1.1 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.1.12.2
Now Lets Configure GET VPN solution for traffic going between 192.168.0.0/16 networks
(LANs behind R4 and R5 , we represented here with loopbacks in both routers).
R1 will be Key Server and R5 and R4 are Group Members.
For KS configuration Parameters:
Group name: GETVPN
Server: Identity 1
IP address 10.1.12.1
Rekey: Unicast
2 retransmit, every 10 seconds
RSA key name R1.cbtme.com
Authorization: Only R5 and R4 GM routers
IPSec SA: Time-based anti replay window: 64
Policy: 192.168.0.0/16, do not encrypt GDOI
Encryption: AES-128
Integrity: SHA
ISAKMP Policy Authentication: PSK
Encryption: DES
Hashing: SHA
Pre-shared key: GETVPN-R5 (for R5), GETVPN-R4 (for R4)
Do not encrypt SSH traffic between 192.168.5.0/24 and 192.168.4.0/24 networks.
This exception must be configured on GMs only.
Answer:
R1 (KS)
ip domain-name cbtme.com
crypto key generate rsa modulus 1024
crypto isakmp policy 10
authentication pre-share
exit
< ISAKMP security policy (3DES, SHA, Diffie-Hellman Group 2,

Pre-Share Authentication) for IKE Phase I.
crypto isakmp key GETVPN-R5 address 10.1.25.5

< Each GM IP address and authentication key (PSK)
(IPSec parameters must be configured in KS ,KS will not use it but will send to GM)
crypto ipsec transform-set TEST esp-aes esp-sha-hmac
< IPSec encryption policy (ESP 3DES and SHA)
crypto ipsec profile GETVPN-PROF

set transform-set TEST
crypto gdoi group GETVPN <Each KS may have many groups and each group may have different security policy
identity number 1
server local
We use the identity command in GDOI group configuration mode to set the identity of the
group to either an IP address or a number. The identity distinguishes the specific group
configuration, because there can be multiple GET VPN groups on each key server or member.
rekey authentication mypubkey rsa R1.cbtme.com

rekey retransmit 10 number 2
rekey transport unicast
<Now we need to specify the rekey phase

and can be unicast rekey or multicast rekey
if multicast was going to used to transport rekeys we was going to use the following commands :
access-list 100 permit udp host 10.1.12.1 host 239.1.1.1 eq 848
rekey address ipv4 100
authorization address ipv4 GM-LIST
sa ipsec 1
profile GETVPN-PROF
match address ipv4 LAN-LIST
replay counter window-size 64
address ipv4 10.1.12.1
exit
exit
<To authorize GMs to able to register in this group on KS ,

you need to specify a standard acl with GMs ip address ,
we named the acl here GM-LIST
<We configure policy for our GMs , encryption policy created by ipsec
profile , and this will tell GMs how to encrypt traffic , which traffic to
encrypt we will use extended acl we call it LAN-LIST
ip access-list stand GM-LIST

permit 10.1.25.5
permit 10.1.24.4
ip access-list ext LAN-LIST
deny udp any eq 848 any eq 848
permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
<We exclude GDOI UDP 848 from this policy

acl , since gdoi already encrypted so need to
re-encrypt
Notice: nothing to apply under KS interfaces, all above IPSec SA will not be used by KS and will
be send to GMs only
R5 (GM)
exit
crypto gdoi group GETVPN
identity number 1
server address ipv4 10.1.12.1 < KS ip address
exit
(Optionally we can exclude some traffic from flow , in question he ask to exclude ssh traffic
between 192.168.4.0/24 and 192.168.5.0/24 , when we create acl here we can deny traffic
only not use it for permit)
ip access-list ext dont-encrypt
deny tcp 192.168.4.0 0.0.0.255 eq 22 192.168.5.0 0.0.0.255
deny tcp 192.168.4.0 0.0.0.255 192.168.5.0 0.0.0.255 eq 22
deny tcp 192.168.5.0 0.0.0.255 eq 22 192.168.4.0 0.0.0.255
deny tcp 192.168.5.0 0.0.0.255 192.168.4.0 0.0.0.255 eq 22
crypto map CMAP-GETVPN 10 gdoi
set group GETVPN
match address dont-encrypt
exit
int s1/1
crypto map CMAP-GETVPN
(R4 will have same configuration as below but we change the key for pre-share to GETVPN-R4)
R4 (GM)
crypto gdoi group GETVPN
identity number 1
server address ipv4 10.1.12.1
exit
crypto map CMAP-GETVPN 10 gdoi
set group GETVPN
match address dont-encrypt
int s1/0
crypto map CMAP-GETVPN
9
R2
ip route 192.168.4.0 255.255.255.0 10.1.24.4
ip route 192.168.5.0 255.255.255.0 10.1.25.5
Verification:
R1#sh crypto gdoi group GETVPN
Group Name
: GETVPN (Unicast)
Re-auth on new CRL
: Disabled
Group Identity
:1
Crypto Path
: ipv4
Key Management Path : ipv4
Group Members
:2
IPSec SA Direction
: Both
Group Rekey Lifetime : 86400 secs
Rekey Retransmit Period : 10 secs
Rekey Retransmit Attempts: 2
IPSec SA Number
:1
IPSec SA Rekey Lifetime: 3600 secs
Profile Name
: GETVPN-PROF
Replay method
: Count Based
Replay Window Size : 64
Tagging method
: Disabled
SA Rekey
Remaining Lifetime : 3432 secs
Time to Rekey
: 3046 secs
ACL Configured
: access-list LAN-LIST
Group Server list
: Local
R4#sh crypto isakmp sa

Note in normal IPSec QM_IDLE means everything is
IPv4 Crypto ISAKMP SA
ok while in GET VPN its GDOI_IDLE
dst
src
state
conn-id slot status
10.1.12.1
10.1.24.4
GDOI_IDLE
1001 0 ACTIVE
R4#ping 192.168.5.5 so lo0
!!!!!
10
To verify the policy configured on GMs, you can enable SSH server on R4 and
R5 and configure local user database. Note that you must test SSH traffic between 192.168.[45].0/24 networks, so you need to inform the routers what interface use as SSH source.
R4
ip ssh source-interface lo0
cry key gen rsa mod 1024
line vty 0 4
login local
R5
ip ssh source-interface lo0
cry key gen rsa mod 1024
line vty 0 4
login local
username yasser password cisco123
R5#sh cry ips sa | in local|remot|enca|deca
Crypto map tag: CMAP-GETVPN, local addr 10.1.25.5
local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
local crypto endpt.: 10.1.25.5, remote crypto endpt.: 0.0.0.0
R4#ssh -l yasser 192.168.4.4
Password:
Crypto map tag: CMAP-GETVPN, local addr 10.1.25.5
Notice No encryption counters incremented because SSH between those networks is excluded
from encryption.
11
GET VPN Multi KS (COOP)
In lab 1 we had one KS and if it goes down we lost everything , a single KS is a single
point of failure for an entire GET VPN network.
So GET VPN supports multiple KS's serving the same group.
This is called COOP KS, and KS's use a COOP protocol to negotiate and synchronize with
each other.
Among a group of KS's, one is elected as primary and others are designated as
secondary.
The primary server is responsible for re-keying, but still GMs may register to any KS in
the group and obtain current keys. Which allows for load distribution plus the
redundancy.
The primary KS keep sends periodic GDOI messages to the secondaries; when a certain
number of messages are missing, the re-election process is started and a new primary is
elected.
The secondary KS taking the role of the primary will transparently continue to notify the
GM of the re-keys. And GM will not detect the loss of the original server.
Lab 2 GETVPN with Dual KS
12
Basic Configuration
KS1
interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 1
network 10.1.1.0 0.0.0.255 area 0
KS2
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.1.1.2 255.255.255.0
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.1.0 0.0.0.255 area 0
GM-Hub
interface Loopback0
ip address 3.3.3.3 255.255.255.255
interface Loopback1
ip address 10.2.3.1 255.255.255.0
ip address 10.1.1.3 255.255.255.0
ip ospf priority 100
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.1.0 0.0.0.255 area 0
network 10.2.3.0 0.0.0.255 area 3
GM-Spoke1
interface Loopback0
ip address 4.4.4.4 255.255.255.255
interface Loopback1
ip address 10.2.4.1 255.255.255.0
ip address 10.1.1.4 255.255.255.0
13
ip ospf priority 0
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.1.1.0 0.0.0.255 area 0
network 10.2.4.0 0.0.0.255 area 4
GM-Spoke2
interface Loopback0
ip address 5.5.5.5 255.255.255.255
interface Loopback1
ip address 10.2.5.1 255.255.255.0
ip address 10.1.1.5 255.255.255.0
ip ospf priority 0
router ospf 5
network 5.5.5.5 0.0.0.0 area 5
network 10.1.1.0 0.0.0.255 area 0
network 10.2.5.0 0.0.0.255 area 5
Now lets configure our primary key server router first before we configure the second.
Notice the only different commands between Single KS and Multiple KS will be in Yellow
encr 3des
group 2
crypto isakmp key cisco123 address 10.1.1.2
crypto ipsec transform-set gvpn-ts esp-3des esp-sha-hmac
crypto ipsec profile gdoi-profile-gvpn1

set security-association lifetime seconds 1800
set transform-set gvpn-ts
14
Now we will configure an ACL specifying what traffic will be encrypted using the GET VPN
services.
access-list 101 permit ip 10.2.0.0 0.0.255.255 10.2.0.0 0.0.255.255
Finally we will configure GDOI on our Key Server to have an identity of "1"; this is required for
all sites to be configured for the same identity number.
crypto gdoi group gvpn1
identity number 1
server local
rekey lifetime seconds 10800
rekey authentication mypubkey rsa gvpn1-export-general
We will associate our configured IPSec profile and ACL 101 policy configured under "sa ipsec
1" for our GDOI configuration.
sa ipsec 1
profile gdoi-profile-gvpn1
match address ipv4 101
Next we will specify the source IP address that will be used to identify this KS router. This is
the IP address the group member routers would use for peering with the KS router.

Till above step nothing new , now we will specify the redundant KS server in our network. We
will configure our local priority to be 10. The priority value determines which of the two KS
routers will be the primary or active KS. Higher the priority number, the more preferred KS the
sites within the WAN/MAN will use as their primary. In
redundancy
local priority 10
peer address ipv4 10.1.1.2
15
Similar to KS1, below is our configuration for the second key server router except under
"redundancy" our local priority is 1
encr 3des
group 2
crypto ipsec transform-set gvpn-ts esp-3des esp-sha-hmac
crypto ipsec profile gdoi-profile-gvpn1
set transform-set gvpn-ts
access-list 101 permit ip 10.2.0.0 0.0.255.255 10.2.0.0 0.0.255.255
identity number 1
server local
rekey authentication mypubkey rsa gvpn1-export-general
sa ipsec 1
profile gdoi-profile-gvpn1
redundancy
local priority 1
peer address ipv4 10.1.1.1
We can use crypto isakmp keepalive command to verify mutual reachability of key servers.
lifetime 86400
crypto isakmp keepalive 10 periodic
16
GET VPN Multi KS configuration on GM routers

encr 3des
group 2
Next we will configure crypto map peers to each of the KS routers on our network with the
same pre-share password we configured on the two KS routers.
Next we will configure GDOI on our Group Member routers with the KS IP addresses, the
identity group number (matching what was configured on the KS routers), then associating
the GDOI group policy to an IPSec security policy.
identity number 1
crypto map vpn 10 gdoi
set group gvpn1
crypto map vpn
Note:
All secondary KS's must use the same key-pair to be able to sign the keys. This requires that
you export the keys at the primary KS and import them at the secondary. You may
export/import keys via a TFTP server or terminal.
Exporting and Importing RSA Keys ,we can use TFTP or terminal method , lets use Terminal
method
K1(config)#crypto key generate rsa general-keys label getvpn-export-general modulus 1024
exportable
K1(config)#crypto key export rsa getvpn-export-general pem terminal 3des passphrase
% Key name: getvpn-export-general
Usage: General Purpose Key
Key data:
-----BEGIN PUBLIC KEY----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC96RhInBlxIGAq4bYd4z1FwWft
cJKAoJTxfoKYwZpi5+PZ41CApgO/8Y0SJLuXnpDVlxWbjNTIoVf4RQyerQSvph6X
BBvX4j5d9pJZJdcdIBymq3F/CEnnbJWxukHQCnN1UCgdJ87oTp4gN7THaGFM3ui2
PgfEpUH5WujPrSCQ4QIDAQAB
-----END PUBLIC KEY----17
-----BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,5DD792A00CA3675D
nVKal5JqzMUeqF/1DQKDkTrNOeB5GSOqbm6/8/lz2Z6SoxbyRICSsk7tsntdvyo9
SxVh5nf4Z//gj4cKm9cM4DvC8ui66WncIvhU1+dCqQ9QK1OOZ1T3GcWMr5rCvkST
+XgVtZvK/3b8CyE1vMwK5GhZ8s/BkU86fO0vdnAw3X3dlCO2kTMrttHTHh5quFJi
mhgUUJJWM//Rv5k2iU3ap99FyIB+52QEKiCMYE/WmjYp8+BLcA1qLJhqTs76P/oc
NlM2XaZquMWUqmRFJyTnveuh0tL57ZQXzL8tCmSh1B59TzfFftwlcWtrihZEzP4x
Ek3dX/VECRA5X0nc9ZOmaYJUyAY6Xy3ZfHlqCd8h1wQ+AxpuOqNUYwR/54r6v25k
kl1aK7NZ3mh075qjdsEtXNWb+9I9RrvttNkTcbfeyZifv8ZP1YN5OcX1w1Z4E17P
hxo/EFs1AwNgoY0kmgnfNi6g1f9duqykLnLtD6NONrfQQAqTLe59FXKMo9oXG3TE
KpAcDKJ37CayzWeIAKekxJX4YCX7CsT2njbM2WSoHTX90vB1sm0UajATpltil2WD
3c4Lyv8oy0A6FNHJhqZJeFW3w+A0OiHeggKL5Aytoyu41I3zozvGGvhDoyjPfXmu
cxaK2FywKuzz5KYrqvUGwGIAoMR8tn4pwQs7CM+MlrVMOOM7ghLmnlEziLSEis36
b94kIPs70heSclECWJrnOCP/NRJ84p4xvtwEPDA68bzlyQOgQ5mrLLwvbIR1CGgm
l+JyTws+j9TaDzaWSbhnt2lqtTxmkRAbRGGpjzAykONulwSXk0BZ8Q==
-----END RSA PRIVATE KEY----Import this key using cut-and-paste to other KSs in the GET VPN network. The exportable
option supports this.
K2(config)# crypto key import rsa getvpn-export-general pem exportable terminal passphrase
% Enter PEM-formatted public General Purpose key or certificate.
% End with a blank line or "quit" on a line by itself.
% Enter PEM-formatted encrypted private General Purpose key.
% End with "quit" on a line by itself.
Network Splits and Network Merges

A possible negative aspect to deploying multiple key servers is when connectivity between key
servers is down for a long period of time. If this network split occurs, it can lead to several
independent groups of key servers, rekeying group members with different session keys. This
will lead to connectivity issues between group members, because they will not be able to
decrypt traffic from other GET VPN members. After the connectivity is restored, the GET VPN
will automatically merge and unify session keys across all members. It is critical that
communication among key servers not be interrupted.
18
GETVPN Show Commands

Lets Practice it in Lab2
Show crypto gdoi ks
Used on KS only , showing all GODI groups configured and number of trusted group members ,
showing who is primary and who is secondary
KS1#sh crypto gdoi ks
Show crypto isakmp sa

Used with GMs to show active IPSec VPN Tunnel established with primary key server at
10.1.1.1
GM-Spoke1#show crypto isakmp sa
Show crypto gdoi group gvpn1
It gives similar details to command show crypto gdoi ks
KS1#show crypto gdoi group gvpn1
If we same command in any GM will gives a lot of helpful information
show crypto gdoi ks members
Used in KS where we can see all registered GMs
KS1#show crypto gdoi ks members
show crypto gdoi ks policy
Used in KS where it will shows all key servers enabled on the network along with gdoi policy
KS1#sh crypto gdoi ks policy
show crypto gdoi ks acl
To check what subnets can communicate securely
KS1#sh crypto gdoi ks acl
19
Show crypto ipsec sa

It shows how many packets encrypted and other useful information
GM-Hub#sh crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: vpn, local addr 10.1.1.3
protected vrf: (none)
Group: gvpn1
current_peer 0.0.0.0 port 848
PERMIT, flags={}
#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
plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x8F115E51(2400280145)
PFS (Y/N): N, DH group: none
inbound esp sas:
GM-Hub#ping 10.2.4.1 source loopback 1
!!!!!
GM-Hub#sh crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: vpn, local addr 10.1.1.3
protected vrf: (none)
Group: gvpn1
current_peer 0.0.0.0 port 848
PERMIT, flags={}
#send errors 0, #recv errors 0
20
Lab 3 secure DMVPN with GETVPN
We can use DMVPN without encryption (no IPsec profile applied at tunnel level) and
configure GET VPN to encrypt traffic between GRE tunnel headends.
GET VPN will be in charge with IPsec.
There is no need to negotiate a spoke-to-spoke IPsec tunnel on demand, so traffic no
longer passes through the hub. All traffic is routed over the DMVPN tunnel, and because
it is GRE encapsulated, it will be automatically encrypted.
Basic configuration
Internet
int f0/0
ip add 10.1.1.100 255.255.255.0
no sh
int f0/1
ip add 10.2.2.100 255.255.255.0
no sh
int f1/0
ip add 10.3.3.100 255.255.255.0
no sh
R1
int f0/0
ip add 10.1.1.1 255.255.255.0
no sh
ip route 0.0.0.0 0.0.0.0 10.1.1.100
int loop 0
ip add 136.1.11.1 255.255.255.0
21
R2
int f0/0
ip add 10.2.2.2 255.255.255.0
no sh
ip route 0.0.0.0 0.0.0.0 10.2.2.100
int loop 0
ip add 136.1.22.2 255.255.255.0
R3
int f0/0
ip add 10.3.3.3 255.255.255.0
no sh
ip route 0.0.0.0 0.0.0.0 10.3.3.100
int loop 0
ip add 136.1.33.3 255.255.255.0
Lets configure DMVPN Phase 2 with EIGRP AS 123
R2 will be Hub, R3 will be Spoke
R2
interface Tunnel0
ip address 100.100.100.2 255.255.255.0
no ip split-horizon eigrp 123
no ip next-hop-self eigrp 123
tunnel source f0/0
tunnel mode gre multipoint
ip nhrp network-id 123
ip nhrp map multicast dynamic
!
router eigrp 123
no auto-summary
network 100.100.100.0 0.0.0.255
network 136.1.22.0 0.0.0.255
R3
interface Tunnel0
ip address 100.100.100.3 255.255.255.0
tunnel source f0/0
tunnel mode gre multipoint
ip nhrp network-id 123
ip nhrp map 100.100.100.2 10.2.2.2
ip nhrp map multicast 10.2.2.2
ip nhrp nhs 100.100.100.2
!
router eigrp 123
no auto-summary
network 100.100.100.0 0.0.0.255
network 136.1.33.0 0.0.0.255
22
GM-DMVPN-Hub-R2#sh ip nhrp
100.100.100.3/32 via 100.100.100.3
Tunnel0 created 00:00:29, expire 01:59:36
Type: dynamic, Flags: unique registered used nhop
NBMA address: 136.1.33.3
(Claimed NBMA address: 10.3.3.3)
GM-DMVPN-Hub-R2#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 136.1.33.3
100.100.100.3 UP 00:00:26 DN
GM-DMVPN-Spoke-R3#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 10.2.2.2
100.100.100.2 NHRP 00:04:43 S
GM-DMVPN-Spoke-R3#sh ip nhrp
100.100.100.2/32 via 100.100.100.2
Tunnel0 created 00:04:52, never expire
Type: static, Flags: used
NBMA address: 10.2.2.2
23
Now lets configure GET VPN to secure our DMVPN network.

R1 will be KS, R2 & R3 will be GMs
R1
encryption 3des
hash md5
group 2
!
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
crypto ipsec transform-set GETVPN esp-3des esp-md5-hmac
!
crypto ipsec profile GETVPN_PROFILE
set transform-set GETVPN
!
crypto key generate rsa general-keys label GETVPN_KEYS modulus 1024 exportable
access-list 100 permit ip any any
!
crypto gdoi group GETVPN_GROUP_GM
identity number 123
server local
rekey authentication mypubkey rsa GETVPN_KEYS
sa ipsec 1
profile GETVPN_PROFILE
R2
encryption 3des
hash md5
group 2
!
crypto isakmp key CISCO address 10.1.1.1
identity number 123
!
crypto map GETVPN_MAP local-address f0/0
crypto map GETVPN_MAP 10 gdoi
set group GETVPN_GROUP_GM
!
interface f0/0
crypto map GETVPN_MAP
24
R3
encryption 3des
hash md5
group 2
!
crypto isakmp key CISCO address 10.1.1.1
identity number 123
!
crypto map GETVPN_MAP local-address FastEthernet0/0
crypto map GETVPN_MAP 10 gdoi
set group GETVPN_GROUP_GM
!
crypto map GETVPN_MAP
Notice: no IPSec SA will be applied to tunnel interface
Verification
GM-DMVPN-Spoke-R3#sh crypto ipsec sa | i #pkts
GM-DMVPN-Spoke-R3#ping 136.1.22.2 source loop0 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 136.1.22.2, timeout is 2 seconds:
Packet sent with a source address of 136.1.33.3
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 288/337/380 ms
GM-DMVPN-Spoke-R3#sh crypto ipsec sa | i #pkts
25
GET VPN VRF Aware

Remember, Remember KS is not VRF aware GM is VRF aware
Remember, Remember VPN addresses must be routable in the transport network. This is
because of the use of the original IP header, and in most cases, it prevents GET VPNs from being
used over the Internet. thats mean KS should be able by way or another reach VRF networks
without being part of this VRF implementation , one of the ways is using VRF Route Leaking .
It is possible to configure the VRFs for GET VPN deployment on the GM if the following
consideration kept in mind:
1. Each VRF will require a unique WAN interface/sub-interface to apply the crypto map
2. Crypto map applied to each VRF will require reference to a unique GET VPN group ID
Because the GET VPN KS is currently not VRF aware, GMs should register to a distinct set of KSs
per group. This means a KS set per VRF is recommended.
Lets assume GM's had two vrf (BLUE/GREEN)
In this case in KS we will create two of the following one for each vrf:
crypto ipsec profile
crypto gdoi group ( with different identity number ,Must be Different GET VPN Group)
In GM we will create two of the following one for each vrf:
crypto gdoi group ( with different identity number ,Must be Different GET VPN Group)
crypto map [crypto map name] 10 gdoi
26
Lab 4 GET VPN VRF Aware
Basic Configuration
R4
interface e0/1.1
encapsulation dot1Q 4
ip address 4.4.4.4 255.255.255.0
!
interface e0/1.2
ip address 44.44.44.44 255.255.255.0
router ospf 100
net 0.0.0.0 255.255.255.255 area 0
R2
ip vrf BLUE
rd 19:110
route-target export 19:110
route-target import 19:110
!
ip vrf GREEN
rd 19:120
interface Loopback1
ip vrf forwarding BLUE
ip address 109.10.1.1 255.255.255.0
!
interface Loopback2
27
ip vrf forwarding GREEN

ip address 109.10.1.1 255.255.255.0
interface e0/0.2
ip address 2.2.2.2 255.255.255.0
!
interface e0/0.22
ip address 22.22.22.22 255.255.255.0
!
interface e0/0.222
ip address 222.222.222.222 255.255.255.0
interface e0/1.1
ip address 172.16.110.1 255.255.255.248
interface e0/1.2
ip address 172.16.120.1 255.255.255.248
router ospf 100
net 0.0.0.0 255.255.255.255 area 0
ip route 172.16.110.0 255.255.255.248 e0/1.1 172.16.110.3
ip route 172.16.120.0 255.255.255.248 e0/1.2 172.16.120.3
ip route vrf BLUE 44.44.44.44 255.255.255.255 2.2.2.20
ip route vrf BLUE 44.44.44.44 255.255.255.255 e0/0.2 2.2.2.20 global
ip route vrf GREEN 44.44.44.44 255.255.255.255 2.2.2.20
ip route vrf GREEN 44.44.44.44 255.255.255.255 e0/0.2 2.2.2.20 global
!
router bgp 109
bgp router-id 2.2.2.2
address-family ipv4 vrf BLUE
network 109.10.1.0 mask 255.255.255.0
neighbor 172.16.110.3 remote-as 109
neighbor 172.16.110.3 activate
address-family ipv4 vrf GREEN
network 109.10.1.0 mask 255.255.255.0
28
R3
ip vrf BLUE
rd 19:110
!
ip vrf GREEN
rd 19:120
interface Loopback1
ip address 109.10.3.3 255.255.255.0
!
interface Loopback2
ip address 109.10.3.3 255.255.255.0
interface e0/0.1
ip address 172.16.110.3 255.255.255.248
!
interface e0/0.2
ip address 172.16.120.3 255.255.255.248
interface e0/1.1
ip address 3.3.3.3 255.255.255.0
!
interface e0/1.2
ip address 33.33.33.33 255.255.255.0
router bgp 109
bgp router-id 3.3.3.3
address-family ipv4 vrf BLUE
network 109.10.3.0 mask 255.255.255.0
address-family ipv4 vrf GREEN
network 109.10.3.0 mask 255.255.255.0
29
ip route 0.0.0.0 0.0.0.0 3.3.3.10

ip route vrf BLUE 44.44.44.44 255.255.255.255 172.16.110.1
SW1
vlan 2
vlan 3
vlan 44
vlan 22
vlan 120
vlan 222
vlan 4
vlan 222
vlan 33
vlan 110
int e1/2
sw tr encap dot
sw mo tr
int e0/1
sw tr encap dot
sw mo tr
int e1/1
sw tr encap dot
sw mo tr
int e0/2
sw tr encap dot
sw mo tr
int e0/3
sw tr encap dot
sw mo tr
int e1/0
sw tr encap dot
sw mo tr
ip routing
int vlan 3
ip add 3.3.3.10 255.255.255.0
no sh
int vlan 2
ip add 2.2.2.20 255.255.255.0
no sh
int vlan 4
ip add 4.4.4.100 255.255.255.0
no sh
int vlan 44
ip add 44.44.44.100 255.255.255.0
no sh
30
int vlan 22
ip add 22.22.22.100 255.255.255.0
no sh
router ospf 100
net 0.0.0.0 255.255.255.255 area 0
Verify Basic configuration
R2#ping vrf BLUE 109.10.3.3 source 109.10.1.1
!!!!!
R2#ping vrf GREEN 109.10.3.3 source 109.10.1.1
!!!!!
R2# sh ip bgp vpnv4 vrf GREEN
BGP table version is 5, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network
Next Hop
Metric LocPrf Weight Path
Route Distinguisher: 19:120 (default for vrf GREEN)
*> 109.10.1.0/24 0.0.0.0
0
32768 i
*>i 109.10.3.0/24 172.16.120.3
0 100 0 i
R2# sh ip bgp vpnv4 vrf BLUE
Network
Next Hop
Route Distinguisher: 19:110 (default for vrf BLUE)
*> 109.10.1.0/24 0.0.0.0
0
32768 i
*>i 109.10.3.0/24 172.16.110.3
0 100 0 i
31
R2#sh ip route | exclude L

S* 0.0.0.0/0 is directly connected, Virtual-Access1
1.0.0.0/32 is subnetted, 1 subnets
O
1.1.1.1 [110/11] via 10.1.1.1, 00:01:24, Ethernet0/0
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O
4.4.4.0 [110/20] via 10.1.1.1, 00:01:03, Ethernet0/0
C
10.1.1.0/24 is directly connected, Ethernet0/0
C
22.22.22.0/24 is directly connected, Ethernet0/0.22
O
44.44.44.0 [110/20] via 10.1.1.1, 00:01:03, Ethernet0/0
S
172.16.110.0 [1/0] via 172.16.110.3, Ethernet0/1.1
S
172.16.120.0 [1/0] via 172.16.120.3, Ethernet0/1.2
C
S
192.168.100.100/32 is directly connected, Virtual-Access1
C
R3#ping vrf BLUE 109.10.1.1 source 109.10.3.3
!!!!!
R3#ping vrf GREEN 109.10.1.1 source 109.10.3.3
!!!!!
R3#sh ip bgp vpnv4 vrf BLUE
Network
Next Hop
Route Distinguisher: 19:110 (default for vrf BLUE)
*>i 109.10.1.0/24 172.16.110.1
0 100 0 i
*> 109.10.3.0/24 0.0.0.0
0
32768 i
32
R3#sh ip bgp vpnv4 vrf GREEN

Network
Next Hop
Route Distinguisher: 19:120 (default for vrf GREEN)
*>i 109.10.1.0/24 172.16.120.1
0 100 0 i
*> 109.10.3.0/24 0.0.0.0
0
32768 i
R3#sh ip route | exclude L
S* 0.0.0.0/0 [1/0] via 192.168.100.2
[1/0] via 3.3.3.10
C
C
C
In above topology we can notice the following :
R2 has two interfaces
int e0/1 used to connect to two VRF networks using two sub interfaces represent two
different networks vlan 110 vrf BLUE , vlan 120 vrf GREEN
int e0/0 used to connect Globally (RIB) to other networks using three sub interfaces represent
three different networks (VLANs) 2,22,222
VRF BLUE use rd 19:110
VRF GREEN use rd 19:120
Interface Loopback1 assigned to VRF BLUE with ip address 109.10.1.1/24
Interface Loopback2 assigned to VRF GREEN with ip address 109.10.1.1/24
R3 has two interfaces

int e0/0 used to connect to two VRF networks using two sub interfaces represent two
different networks vlan 110 vrf BLUE , vlan 120 vrf GREEN
int e0/1 used to connect Globally (RIB) to other networks using two sub interfaces represent
two different networks (VLANs) 3,33
VRF BLUE use rd 19:110
VRF GREEN use rd 19:120
Interface Loopback1 assigned to VRF BLUE with ip address 109.10.3.3/24
Interface Loopback2 assigned to VRF GREEN with ip address 109.10.3.3/24
33
MB-BGP AS109 used to route between VRF's in R2 & R3

R4 has one interface
int e0/1 used to connect Globally (RIB) to other networks using two sub interfaces represent
two different networks (VLANs) 4,44
SW1 is ip routing enabled and has SVI for each vlan used in R2,R3,R4
SW1 using ospf to advertise his RIB routes to R2 & R4
R3 use default route pointing to SW1
Notice that R4 (44.44.44.44) will be KS address , check that R1 R3 GM can ping it

R2#ping 44.44.44.44
!!!!!
R3#ping 44.44.44.44
!!!!!
Now lets Implement Get VPN to protect the traffic between the two VPN Sites BLUE & GREEN
BLUE & GREEN will be using the following SA parameters:
Isakmp Policies :
Encryption AES-256
Authentication Pre-Shared Key : ccie
DH group 2
Life time 600
Data protection Policy :
Data Encryption ESP-AES 256
Data authentication ESP-SHA-HAMC
Life Time 600
VPN BLUE GET VPN Parameters:
Group Name GET-GROUP1
Identity Number 1
Rekey Encryption AES 256
Rekey Life time 600
Rekey Transport Unicast
Protected Traffic Between 109.10.0.0/16 109.10.0.0/16
Key server 44.44.44.44
Rekey authentication RSA key R4.ccie.com
34
VPN GREEN GET VPN Parameters:

Group Name GET-GROUP2
Identity Number 2
Rekey Encryption AES 256
Rekey Life time 600
Rekey Transport Unicast
Protected Traffic Between 109.10.0.0/16 109.10.0.0/16
Key server 44.44.44.44
Rekey authentication RSA key R4.ccie.com
R4 will be KS while R2 and R3 will be GM and should should perform GDOI Registration using
172.16.x.x/29 onwards.
R4
crypto key generate rsa label R4.ccie.com modulus 1024
ip access-list ext BLUE
permit ip 109.10.0.0 0.0.255.255 109.10.0.0 0.0.255.255
ip access-list ext GREEN
permit ip 109.10.0.0 0.0.255.255 109.10.0.0 0.0.255.255
encr aes 256
group 2
lifetime 600
crypto isakmp key ccie address 0.0.0.0 0.0.0.0
crypto ipsec transform-set TRANS esp-aes 256 esp-sha-hmac
crypto ipsec profile PRO1
set transform-set TRANS
crypto gdoi group GET-GROUP1
identity number 1
server local
rekey algorithm aes 256
rekey authentication mypubkey rsa R4.ccie.com
sa ipsec 1
profile PRO1
match address ipv4 BLUE
35

identity number 2
server local
rekey algorithm aes 256
rekey authentication mypubkey rsa R4.ccie.com
sa ipsec 1
profile PRO1
match address ipv4 GREEN
R2
crypto keyring BLUE vrf BLUE
pre-shared-key address 44.44.44.44 key ccie
crypto keyring GREEN vrf GREEN
encr aes 256
group 2
crypto isakmp profile BLUE
vrf BLUE
keyring BLUE
match identity address 44.44.44.44 255.255.255.255 BLUE
crypto isakmp profile GREEN
vrf GREEN
keyring GREEN
match identity address 44.44.44.44 255.255.255.255 GREEN
identity number 1
identity number 2
crypto map BLUE isakmp-profile BLUE
crypto map BLUE 10 gdoi
set group GET-GROUP1
36
crypto map GREEN isakmp-profile GREEN

crypto map GREEN 10 gdoi
int e0/1.1
crypto map BLUE
int e0/1.2
crypto map GREEN
R3
crypto keyring BLUE vrf BLUE
crypto keyring GREEN vrf GREEN
encr aes 256
group 2
crypto isakmp profile BLUE
vrf BLUE
keyring BLUE
match identity address 44.44.44.44 255.255.255.255 BLUE
crypto isakmp profile GREEN
vrf GREEN
keyring GREEN
match identity address 44.44.44.44 255.255.255.255 GREEN
identity number 1
identity number 2
crypto map BLUE isakmp-profile BLUE
crypto map BLUE 10 gdoi
37
crypto map GREEN isakmp-profile GREEN

crypto map GREEN 10 gdoi
int e0/0.1
crypto map BLUE
int e0/0.2
crypto map GREEN
Verification
R2#sh crypto gdoi group GET-GROUP1
Group Name
: GET-GROUP1
Group Identity
:1
Crypto Path
: ipv4
Rekeys received
:0
IPSec SA Direction
: Both
Group Server list
: 44.44.44.44
Group Member Information For Group GET-GROUP1:

IPSec SA Direction
: Both
ACL Received From KS :
Group member
: 172.16.110.1 vrf: BLUE
Version
: 1.0.8
Registration status : Registering <
Registering to
: 44.44.44.44
Re-registers in
: 54 sec
Succeeded registration: 0
Attempted registration: 2
Last rekey from
: 0.0.0.0
Last rekey seq num : 0
Multicast rekey rcvd : 0
DP Error Monitoring : OFF
allowable rekey cipher: any
allowable rekey hash : any
allowable transformtag: any ESP
Rekeys cumulative
Total received
:0
After latest register : 0
Rekey Received
: never
ACL Downloaded From KS UNKNOWN:
TEK POLICY for the current KS-Policy ACEs Downloaded:
38

Group Name
: GET-GROUP2
Group Identity
:2
Crypto Path
: ipv4
Rekeys received
:0
IPSec SA Direction
: Both
Group Server list
: 44.44.44.44

IPSec SA Direction
: Both
ACL Received From KS :
Group member
: 172.16.120.1
Version
: 1.0.8
Registration status : Registering
Registering to
: 44.44.44.44
Re-registers in
: 42 sec
Last rekey from
: 0.0.0.0
Multicast rekey rcvd : 0
vrf: GREEN

Rekeys cumulative
Total received
:0
Rekey Received
: never
ACL Downloaded From KS UNKNOWN:
39
We had problem here, no registering successful in R4 KS

Notice the following static routes for route leaking in R2 & R3
R2
ip route vrf BLUE 44.44.44.44 255.255.255.255 2.2.2.20
ip route vrf BLUE 44.44.44.44 255.255.255.255 E0/0.1 2.2.2.20 global
R2 will use sw2 to reach r4 (44.44.44.44) for vrfs
And globally he can also reach R4 using ospf
R1#sh ip route 150.1.7.100
Routing entry for 150.1.7.0/24
Known via "ospf 100", distance 110, metric 2, type intra area
Last update from 22.22.22.2200 on FastEthernet0/0.2, 01:08:51 ago
Routing Descriptor Blocks:
22.22.22.2200, from 150.1.7.100, 01:08:51 ago, via FastEthernet0/0.2
Route metric is 2, traffic share count is 1
* 2.2.2.20, from 150.1.7.100, 01:09:01 ago, via FastEthernet0/0.1
Route metric is 2, traffic share count is 1
R3
ip route 0.0.0.0 0.0.0.0 3.3.3.10
ip route vrf BLUE 44.44.44.44 255.255.255.255 172.16.110.1
R3 will use R1 to reach R4 (44.44.44.44) for vrfs
R3 will use SW1 as Default route to reach R4 (44.44.44.44) globally
Now we need to make R4 KS able to reach BLUE & GREEN networks , to do so we will add two
static routes in SW1 to help him reach it through R2 2.2.2.2 global address
SW1
ip route 172.16.110.0 255.255.255.0 2.2.2.2
ip route 172.16.120.0 255.255.255.0 2.2.2.2
R4
ip route 172.16.110.0 255.255.255.0 44.44.44.100
ip route 172.16.120.0 255.255.255.0 44.44.44.100
R4#ping 172.16.110.1
!!!!!
40
R4#ping 172.16.120.1
!!!!!
And finally the word registered appears
R1# sh crypto gdoi group GET-GROUP1
Group Name
: GET-GROUP1
Group Identity
:1
Crypto Path
: ipv4
Rekeys received
:0
IPSec SA Direction
: Both
Group Server list
: 44.44.44.44

IPSec SA Direction
: Both
ACL Received From KS : gdoi_group_GET-GROUP1_temp_acl
Group member
: 172.16.110.1
Version
: 1.0.8
Registration status : Registered
Registered with
: 44.44.44.44
Re-registers in
: 515 sec
Last rekey from
: 0.0.0.0
Unicast rekey received: 0
Rekey ACKs sent
:0
Rekey Received
: never
vrf: BLUE

Rekeys cumulative
Total received
:0
Rekey Acks sents : 0
ACL Downloaded From KS 44.44.44.44:
access-list permit ip 109.10.0.0 0.0.255.255 109.10.0.0 0.0.255.255
41
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs)
: 588
Encrypt Algorithm
: AES
Key Size
: 256
Sig Hash Algorithm
: HMAC_AUTH_SHA
Sig Key Length (bits) : 1024
FastEthernet1/0.1:
IPsec SA:
spi: 0xFCFD286B(4244449387)
transform: esp-256-aes esp-sha-hmac
sa timing:remaining key lifetime (sec): (590)
Anti-Replay(Counter Based) : 64
tag method : disabled
alg key size: 32 (bytes)
sig key size: 20 (bytes)
encaps: ENCAPS_TUNNEL

Group Name
: GET-GROUP1
Group Identity
:1
Crypto Path
: ipv4
Rekeys received
:0
IPSec SA Direction
: Both
Group Server list
: 44.44.44.44

IPSec SA Direction
: Both
ACL Received From KS : gdoi_group_GET-GROUP1_temp_acl
Group member
: 172.16.110.3
Version
: 1.0.8
Registration status : Registered
Registered with
: 44.44.44.44
Re-registers in
: 226 sec
Last rekey from
: 0.0.0.0
Unicast rekey received: 0
Rekey ACKs sent
:0
Rekey Received
: never
vrf: BLUE
42

Rekeys cumulative
Total received
:0
Rekey Acks sents : 0
ACL Downloaded From KS 44.44.44.44:
access-list permit ip 109.10.0.0 0.0.255.255 109.10.0.0 0.0.255.255
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs)
: 413
Encrypt Algorithm
: AES
Key Size
: 256
Sig Hash Algorithm
: HMAC_AUTH_SHA
Sig Key Length (bits) : 1024
FastEthernet0/0.1:
IPsec SA:
spi: 0xFCFD286B(4244449387)
transform: esp-256-aes esp-sha-hmac
sa timing:remaining key lifetime (sec): (415)
Anti-Replay(Counter Based) : 64
tag method : disabled
alg key size: 32 (bytes)
sig key size: 20 (bytes)
encaps: ENCAPS_TUNNEL
Group Name
: GET-GROUP1 (Unicast)
Re-auth on new CRL
: Disabled
Group Identity
:1
Crypto Path
: ipv4
Group Members
:2
IPSec SA Direction
: Both
Group Rekey Lifetime : 600 secs
Group Rekey
Time to Rekey
: 210 secs
Rekey Retransmit Period : 10 secs
Rekey Retransmit Attempts: 2
Group Retransmit
43

IPSec SA Number
:1
IPSec SA Rekey Lifetime: 600 secs
Profile Name
: PRO1
Replay method
: Count Based
Replay Window Size : 64
Tagging method
: Disabled
SA Rekey
Time to Rekey
: 320 secs
ACL Configured
: access-list BLUE
Group Server list
: Local
We should apply all above commands for group GET-GROUP2 as well for verification.
Now lets verify that our interested traffic is encrypted
Crypto map tag: BLUE, local addr 172.16.110.3
Crypto map tag: GREEN, local addr 172.16.120.3
R3#Ping VRF GREEN 109.10.1.1 source 109.10.3.3
!!!!!
44

R3#Ping VRF BLUE 109.10.1.1 source 109.10.3.3
!!!!!
R3#sh crypto isakmp sa

dst
src
state
conn-id status
44.44.44.44 172.16.120.3 GDOI_IDLE
1006 ACTIVE
44.44.44.44 172.16.110.3 GDOI_IDLE
1005 ACTIVE
45
Good Luck
CCIE & CCSI: Yasser Auda
https://www.facebook.com/YasserRamzyAuda
https://learningnetwork.cisco.com/people/yasserramzy/content
https://www.youtube.com/user/yasserramzyauda
46

GETVPN

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

GETVPN

Diunggah oleh

Hak Cipta:

Format Tersedia

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

Cisco IOS GETVPN (Group Encrypted Transport VPN) Solution

What are the components of GETVPN?

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

How GDOI protocol working?

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

TEK & KEK Keys & rekey Distributed Methods :

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

Important things to remember when to use multicast or unicast rekey transport:

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

Lab 1 GETVPN with single KS

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

< ISAKMP security policy (3DES, SHA, Diffie-Hellman Group 2,

crypto isakmp key GETVPN-R5 address 10.1.25.5

< Each GM IP address and authentication key (PSK)

crypto ipsec transform-set TEST esp-aes esp-sha-hmac

< IPSec encryption policy (ESP 3DES and SHA)

crypto ipsec profile GETVPN-PROF

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

rekey authentication mypubkey rsa R1.cbtme.com

<Now we need to specify the rekey phase

<To authorize GMs to able to register in this group on KS ,

ip access-list stand GM-LIST

<We exclude GDOI UDP 848 from this policy

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

R4#sh crypto isakmp sa

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

GET VPN Multi KS (COOP)

Lab 2 GETVPN with Dual KS

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

crypto ipsec profile gdoi-profile-gvpn1

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

address ipv4 10.1.1.1

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

GET VPN Multi KS configuration on GM routers

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

-----BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED

Network Splits and Network Merges

CCIE Security GET VPN Quick Overview

CCIE&CCSI: Yasser Ramzy Auda

GETVPN Show Commands