I thought it would be cool to lab out a combination of DMVPN (Dynamic Multipoint VPN, utilizing multipoint GRE dynamic tunnels) with the integration of GETVPN. Group Encrypted Transport VPN, which utilizes a key server that distributes group keys to it's registered members and controls the group security associations between the peers. GETVPN does not use static ipsec tunnels or create the VPN frame work....you would need to have a vpn in place...DMVPN in this example, although GETVPN is best suited over MPLS. BTW...a great guide for setting up and understanding DMVPN can be found here at firewall.cx:
CONFIGURING CISCO DYNAMIC MULTIPOINT VPN (DMVPN)
Below is my GNS 3 lab diagram. I started by using a single router to represent the internet. I also Port Address Translated the 2 spoke and hub routers public interfaces to allow the private hosts to communicate with the rest of the "Internet" to add some realism. The DMVPN config is below
------------------------------------------------------------------------------------------------------------------------
interface Tunnel0
description mGRE DMVPN Tunnel ip address 192.168.1.1 255.255.255.0 no ip redirects no ip split-horizon eigrp 1 no ip next-hop-self eigrp 1 ip nhrp authentication DMVPN ip nhrp map multicast dynamic ip nhrp network-id 1 tunnel source 11.11.11.1 tunnel mode gre multipoint router eigrp 1 network 10.1.1.0 0.0.0.255 network 192.168.1.0 |
These are the pertinent parts of the DMVPN config. Nothing special with the physical interfaces- just assign them IPs and activate them. All the config is done on the tunnel interface- which is the fist thing you'll create.
This the hub config. You'll want to use a private address network for your tunnel interfaces. You will definitely need to disable split-horizon for the EIGRP process running on the tunnel interface. If you don't, your spokes will never get eachothers routes, only the updates from the hubs routes will be present on the spokes. Also if you want direct communication\routes between spoke routers, and not send all traffic via the hub, then disable next-hop-self as well for your EIGRP, Set your authentication string to allow queries and updates to the NHRP database Map multicast traffic to the spokes dynamically- this is used and necessary for routing protocols that use multicast packets (ie EIGRP in this case) in their routing updates. Set the network ID- which will be the same for all participating routers in the VPN cloud. Your tunnel source is the public facing interface IP. This command enables the tunnel interface as a multipoint GRE tunnel.
This is your basic advertising of your routers networks- you'll need to add the tunnel network as well in order for EIGRP adjacencies to form.
|
--------------------------------------------------------------------------------------------------------------------------
Next is the spoke config for the VPN........
--------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------
interface Tunnel0 description mGRE DMVPN Tunnel ip address 192.168.1.3 255.255.255.0 no ip redirects ip nhrp authentication DMVPN ip nhrp map multicast dynamic ip nhrp map 192.168.1.1 11.11.11.1 ip nhrp map multicast 11.11.11.1 ip nhrp network-id 1 ip nhrp nhs 192.168.1.1 tunnel source FastEthernet0/0 tunnel mode gre multipoint network 10.3.3.0 0.0.0.255 network 192.168.1.0
ip route 0.0.0.0 0.0.0.0 33.33.33.254
deny ip 192.168.0.0 0.0.255.255 any deny ip 10.3.3.0 0.0.0.255 10.0.0.0 0.255.255.255 permit ip 10.3.3.0 0.0.0.255 any |
Almost the same thing for the spokes...but here are the differences:
Maps the hubs NHS tunnel IP to it's public IP
Send multicast traffic to the hub, so that the hub processes it- this is essential for EIGRP to form adjacencies! They will not form otherwise, unless maybe you specify static EIGRP neighbors from hub to spoke, which use unicast instead.
This command tells the spoke who the hub NHRP router is-- in this case GM-R1
The tunnel source is specified as the public interface itself and not the IP- this can be used in case the IP changes dynamically.
I also have a static default route pointing to my ISP router so that clients behind my spoke router can get out to the internet.
What I did here is, deny the private networks in including the tunnel network, from being being natted. I had PAT overloaded the public interface on the spoke routers so that clients can NAT out to the internet, but we obviously don't want the VPN traffic to NAT.
|
--------------------------------------------------------------------------------------------------------------------------
The other spoke is the same exact thing as the first one....
At this point you should see the peers that have GRE tunnels- as expected, there are 2 tunnels connected to the hub router:
GM-R1#show dmvpn
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 33.33.33.3 192.168.1.3 UP 03:07:36 D
1 44.44.44.44 192.168.1.4 UP 02:59:23 D
You should have EIGRP neighborships between the hub and each spoke:
GM-R1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.1.4 Tu0 10 02:10:58 166 1470 0 31
0 192.168.1.3 Tu0 10 02:14:55 179 1470 0 28
GM-R4#show ip route
Gateway of last resort is 44.44.44.254 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 44.44.44.254
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D 10.1.1.0/24 [90/26882560] via 192.168.1.1, 02:12:47, Tunnel0
D 10.3.3.0/24 [90/28162560] via 192.168.1.1, 02:00:59, Tunnel0
C 10.4.4.0/24 is directly connected, FastEthernet0/1
L 10.4.4.4/32 is directly connected, FastEthernet0/1
44.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 44.44.44.0/24 is directly connected, FastEthernet0/0
L 44.44.44.44/32 is directly connected, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Tunnel0
L 192.168.1.4/32 is directly connected, Tunnel0
Ok......so here's the GETVPN part...utilizing the GDOI protocol running on UDP port 848. The IKE SAs are setup between the group members and the Key Server...communicating over the public internet. Since my key server sits behind R1 on the private network, I had to port forward UDP 848 and IKE 500 and 4500 (when behind NAT, which is my case) on R1- I used a static NAT mapping IP 11.11.11.5 to the private IP of the KS server......
I'll start with the Key Server setup here:
--------------------------------------------------------------------------------------------------------------------------
KS-R5(config)#crypto key generate rsa label VPNKEY1 modulus 1024 exportable
crypto isakmp policy 1 encr aes authentication pre-share group 2 lifetime 14400 crypto isakmp key getvpn address 0.0.0.0 crypto ipsec transform-set TRANS1 esp-aes esp-sha-hmac mode tunnel ! crypto ipsec profile IPSEC1 set transform-set TRANS1 crypto gdoi group GDOI1 identity number 1 server local rekey algorithm aes 128 rekey lifetime seconds 14400 rekey retransmit 15 number 2 rekey authentication mypubkey rsa VPNKEY1 rekey transport unicast sa ipsec 10 profile IPSEC1 match address ipv4 GETVPN-ACL replay counter window-size 64 address ipv4 10.1.1.5 crypto map CRYPTO1 10 gdoi set group GDOI1 no ip routing ip default-gateway 10.1.1.1 ip access-list extended GETVPN-ACL deny udp any eq 848 any eq 848 permit gre any any |
You'll want to create an RSA keypair here, to use for signing the packets.
ISAKMP policy is defined here. I lazily used the 0.0.0.0 (any ip) as the "allowed" addresses for the key usage among the GDOI members. You would want to restrict these to the public facing IP addresses of your member routers- use one line per address. Your ipsec transform set and encryption types are set here. Ipsec profile specifying your transform set The gdoi group settings here. Note the reference to the rsa key generated earlier. You will also match the traffic that is to be encrypted via an ACL....and reference the ipsec profile you just created (IPSEC1) You actually don't need to enable the crypto map on the interface of the key server since it sits on the private network-but I left it here for reference. Here, I disabled routing and set the KS's default gateway as if it was just a host unit. I denied the gdoi control traffic on udp port 848 here....and permitted GRE tunnel packets, which includes everything running through the DMVPN. This ACL will be downloaded by the member routers too. |
--------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------
ip nat inside source list NATISP interface FastEthernet0/0 overload
ip nat inside source static udp 10.1.1.5 500 11.11.11.5 500 extendable ip nat inside source static udp 10.1.1.5 848 11.11.11.5 848 extendable ip nat inside source static udp 10.1.1.5 4500 11.11.11.5 4500 extendable crypto isakmp policy 1 encr aes authentication pre-share group 2 lifetime 14400 crypto isakmp key getvpn address 10.1.1.5 crypto gdoi group GDOI1 identity number 1 server address ipv4 10.1.1.5 ! ! crypto map CRYPTO1 10 gdoi set group GDOI1 interface FastEthernet0/0 ip address 11.11.11.1 255.255.255.0 ip nat outside speed auto duplex auto crypto map CRYPTO1 |
With this router- I Natted an additional public IP (11.11.11.5) to the necessary ports on the KS server sitting on the private network.
Isakmp policy here, and, with this router, I referenced the KS server by it's real private IP address- on R3 and 4, you'll use the public natted IP defined above to reach the KS. GDOI group- basically specifying the KS server- same thing here- use the public natted IP address of the KS on the remote routers- use the real IP here. Tie it in w the crypto map- CRYPTO1 "Turn on" the Crypto map for the outside public facing interface. |
--------------------------------------------------------------------------------------------------------------------------
As soon as you enable the crypto map on the outside interface- the member router should register with the KS, and display the console output similar to below:
GM-R1(config-if)#
*Mar 9 22:05:44.991: %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.1.5 for group GDOI1 using address 10.1.1.1
GM-R1(config-if)#
*Mar 9 22:05:45.007: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
GM-R1(config-if)#
*Mar 9 22:06:06.455: %GDOI-5-GM_REKEY_TRANS_2_UNI: Group GDOI1 transitioned to Unicast Rekey.
*Mar 9 22:06:06.459: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated
*Mar 9 22:06:06.475: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Mar 9 22:06:06.583: %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.1.5 complete for group GDOI1 using address 10.1.1.1
*Mar 9 22:06:06.643: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 10.1.1.5 for group GDOI1 & gm identity 10.1.1.1
On the KS server, after configuring the other member routers, you should see Security Associations with each of the 3 member routers, as shown here:
KS-R5#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.1.1.5 11.11.11.1 GDOI_IDLE 1007 ACTIVE
10.1.1.5 44.44.44.44 GDOI_IDLE 1008 ACTIVE
10.1.1.5 33.33.33.3 GDOI_IDLE 1005 ACTIVE
This will show you group info, number of members, key lifetimes, group ACL etc
This will show you group info, number of members, key lifetimes, group ACL etc
KS-R5#show crypto gdoi
GROUP INFORMATION
Group Name : GDOI1 (Unicast)
Group Identity : 1
Crypto Path : ipv4
Key Management Path : ipv4
Group Members : 3
IPSec SA Direction : Both
Group Rekey Lifetime : 14400 secs
Group Rekey
Remaining Lifetime : 9195 secs
Rekey Retransmit Period : 15 secs
Rekey Retransmit Attempts: 2
Group Retransmit
Remaining Lifetime : 0 secs
IPSec SA Number : 10
IPSec SA Rekey Lifetime: 3600 secs
Profile Name : IPSEC1
Replay method : Count Based
Replay Window Size : 64
SA Rekey
Remaining Lifetime : 2213 secs
ACL Configured : access-list GETVPN-ACL
Group Server list : Local
This is the SA from a member router perspective
GM-R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
33.33.33.3 10.1.1.5 GDOI_REKEY 1004 ACTIVE
11.11.11.5 33.33.33.3 GDOI_IDLE 1003 ACTIVE
And again, GDOI info from a group member router- reference the KS via it's public IP
And again, GDOI info from a group member router- reference the KS via it's public IP
GM-R3#show cry gdoi
GROUP INFORMATION
Group Name : GDOI1
Group Identity : 1
Crypto Path : ipv4
Key Management Path : ipv4
Rekeys received : 1
IPSec SA Direction : Both
Group Server list : 11.11.11.5
Group member : 33.33.33.3 vrf: None
Version : 1.0.4
Registration status : Registered
Registered with : 11.11.11.5
Re-registers in : 1426 sec
Succeeded registration: 2
Attempted registration: 6
Last rekey from : 10.1.1.5
Last rekey seq num : 6
Unicast rekey received: 1
Rekey ACKs sent : 1
Rekey Rcvd(hh:mm:ss) : 01:27:29
allowable rekey cipher: any
allowable rekey hash : any
allowable transformtag: any ESP
Rekeys cumulative
Total received : 1
After latest register : 0
Rekey Acks sents : 1
ACL Downloaded From KS 11.11.11.5:
access-list deny udp any port = 848 any port = 848
access-list permit gre any any
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs) : 8521
Encrypt Algorithm : AES
Key Size : 128
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 1024
TEK POLICY for the current KS-Policy ACEs Downloaded:
FastEthernet0/0:
IPsec SA:
spi: 0x4F0F578E(1326405518)
transform: esp-aes esp-sha-hmac
sa timing:remaining key lifetime (sec): (1540)
Anti-Replay : Disabled
At this point, you'll want to send some pings over the network via the tunnel- the encaps and decaps should increment, confirming that the traffic is indeed being encrypted via GETVPN.
GM-R3#show crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: CRYPTO1, local addr 33.33.33.3
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
current_peer 0.0.0.0 port 848
PERMIT, flags={}
#pkts encaps: 964, #pkts encrypt: 964, #pkts digest: 964
#pkts decaps: 438, #pkts decrypt: 438, #pkts verify: 438
#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 64
local crypto endpt.: 33.33.33.3, remote crypto endpt.: 0.0.0.0
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x501F7AB8(1344240312)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x501F7AB8(1344240312)
--------------------------------------------------------------------------------------------------------------------------
So there you have it- 2 cool vpn technologies combined - hope this is helpful and thanks for reading. Also, here's a few excellent references on DMVPN , GETVPN, and IPSEC\IKE\ISAKMP in general.
http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/901-cisco-router-dmvpn-configuration.html
http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/getvpn-solution-managed-services/prod_white_paper0900aecd804c363f.html
--------------------------------------------------------------------------------------------------------------------------
So there you have it- 2 cool vpn technologies combined - hope this is helpful and thanks for reading. Also, here's a few excellent references on DMVPN , GETVPN, and IPSEC\IKE\ISAKMP in general.
http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/901-cisco-router-dmvpn-configuration.html
http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/getvpn-solution-managed-services/prod_white_paper0900aecd804c363f.html
No comments:
Post a Comment