Note: Full working solution is located at the end of the document. 
Change was in the air, and Bob knew it. Bob had simply been ignoring the fact that the existing IPSec site to site tunnels that he inherited at his company were old school, and there were better options, especially when plans included bringing up dozens of new sites. Since his company was going to be purchasing MPLS services, Bob was open to learning better ways of implementing secure tunnels. In Bob’s studies, he read a article written by Petr Lapukhov on DMVPN and was very interested. Bob’s glee was short lived when he learned that when the spokes of DMVPN had to build tunnels to other spokes, it was not quick enought for voice traffic. Bob learned that the latency happens when setting up the IKE phase 1 and 2 tunnels between the spokes. Then Bob chanced upon one of Anthony Sequeira’s blog posts regarding GET VPN, and learned that with GET (Group Encrypted Transport), there was no need to build the tunnels between spokes, and therefore less latency. This would solve the latency issue for time sensitive traffic, and still have the benefits of encryption! It sounded almost too good to be true.
Eagerly, Bob set up 4 routers to test DMVPN for dynamic GRE tunnels and GET VPN to provide the encryption services.
Bob’s heart beat a little faster as he thought about the layout of the test; R1 would be the KEY, CA and NTP server. R2 would be the DMVPN hub with R3 and R4 being spokes. From the GET VPN side of the house, R2, R3 and R4 would all be GET VPN group members so no IPSec profiles would be required for the GRE interfaces.
Bob put the configuration he planned to use into his favorite configuration editor (notepad), and realized that when he eventually pastes this into the routers, he may have to intervene at times to supply manual input for certificate related tasks, and he was ok with that. Bob also remembered that it is best to allow time to synchronize with peers when using digital certificates.
All the switchports used by R1-4 Fa0/0 were set up correctly as access-ports, and in the same VLAN. Bob verified that no L1 or L2 problems were standing between him and success.
In contrast to his anticipation of building the “perfect” new solution for his company, Bob had a sneaking suspicion that something in his proposed configuration wasn’t quite right, or maybe was missing something. Below is the proposed configuration:
Hint: there are 4 specific configuration related issues based on the proposed configuration.
Will you assist Bob in creating a working DMVPN/GET VPN solution?
PS Bob passes on his appreciation for all the help he has received from you in the past! The solutions you provided worked like a charm, and Bob is being treated like a Network Rock Star by his manager. Keep up the great work!
Change was in the air, and Bob knew it. Bob had simply been ignoring the fact that the existing IPSec site to site tunnels that he inherited at his company were old school, and there were better options, especially when plans included bringing up dozens of new sites. Since his company was going to be purchasing MPLS services, Bob was open to learning better ways of implementing secure tunnels. In Bob’s studies, he read a article written by Petr Lapukhov on DMVPN and was very interested. Bob’s glee was short lived when he learned that when the spokes of DMVPN had to build tunnels to other spokes, it was not quick enought for voice traffic. Bob learned that the latency happens when setting up the IKE phase 1 and 2 tunnels between the spokes. Then Bob chanced upon one of Anthony Sequeira’s blog posts regarding GET VPN, and learned that with GET (Group Encrypted Transport), there was no need to build the tunnels between spokes, and therefore less latency. This would solve the latency issue for time sensitive traffic, and still have the benefits of encryption! It sounded almost too good to be true.
Eagerly, Bob set up 4 routers to test DMVPN for dynamic GRE tunnels and GET VPN to provide the encryption services.
Bob’s heart beat a little faster as he thought about the layout of the test; R1 would be the KEY, CA and NTP server. R2 would be the DMVPN hub with R3 and R4 being spokes. From the GET VPN side of the house, R2, R3 and R4 would all be GET VPN group members so no IPSec profiles would be required for the GRE interfaces.
Bob's test bed for DMVPN/GET VPN
All the switchports used by R1-4 Fa0/0 were set up correctly as access-ports, and in the same VLAN. Bob verified that no L1 or L2 problems were standing between him and success.
In contrast to his anticipation of building the “perfect” new solution for his company, Bob had a sneaking suspicion that something in his proposed configuration wasn’t quite right, or maybe was missing something. Below is the proposed configuration:
R1 Key, NTP and CA Server
enable
conf t
hostname R1
ip domain-name INE.com
no ip domain-lookup
line con 0
no exec-time
logging sync
privi level 15
exit
int fa 0/0
no shut
ip address 10.0.0.1 255.255.255.0
int loop 0
ip address 1.1.1.1 255.255.255.0
exit
ntp master 2
ntp authentication-key 1 md5 cisco
ntp trusted-key 1
ntp authenticate
clock timezone PST -8
clock summer-time PDT recurring
crypto key generate rsa general-keys modulus 1024
ip http server
crypto pki server R1-CA_Server
database url nvram:
database level minimum
grant auto
no shutdown
exit
crypto isakmp policy 1
auth rsa-sig
exit
crypto ipsec transform-set TSET esp-aes esp-sha
mode transport
exit
crypto ipsec profile GDOI-PROF
set transform-set TSET
exit
crypto gdoi group group1
identity number 1
server local
address ipv4 10.0.0.1
rekey authentication mypubkey rsa R1.INE.com
rekey transport unicast
sa ipsec 1
profile GDOI-PROF
match address ipv4 100
exit
exit
access-list 100 permit gre 10.0.0.0 0.0.0.255 10.0.0.0 0.0.0.255
R2 DMVPN HUB
enable
conf t
hostname R2
ip domain-name INE.com
no ip domain-lookup
line con 0
no exec-time
logging sync
privi level 15
exit
int fa 0/0
no shut
ip address 10.0.0.2 255.255.255.0
int loop 0
ip address 2.2.2.2 255.255.255.0
exit
clock timezone PST -8
clock summer-time PDT recurring
ntp authentication-key 1 md5 cisco
ntp trusted-key 1
ntp authenticate
ntp server 10.0.0.1 key 1
ip domain-name INE.com
crypto key generate rsa general-keys modulus 1024
crypto isakmp policy 1
auth rsa-sig
exit
interface Tunnel0
bandwidth 1000
delay 1000
ip address 172.168.0.2 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 1
ip nhrp authentication DMVPN_NW
ip nhrp map multicast dynamic
ip nhrp network-id 2210
ip nhrp holdtime 360
ip tcp adjust-mss 1360
no ip split-horizon eigrp 1
tunnel source Fa0/0
tunnel mode gre multipoint
tunnel key 6738
exit
router eigrp 1
network 172.16.0.0 0.0.255.255
network 2.2.2.2 0.0.0.0
no auto-summary
exit
crypto pki trustpoint R1-CA
enrollment url http://10.0.0.1:80
revocation-check none
exit
cry pki authenticate R1-CA
crypto pki enroll R1-CA
crypto gdoi group group1
identity number 1
server address ipv4 10.0.0.1
exit
crypto map map-group1 10 gdoi
set group group1
interface FastEthernet0/0
crypto map map-group1
end
R3 DMVPN Spoke
enable
conf t
hostname R3
ip domain-name INE.com
no ip domain-lookup
line con 0
no exec-time
logging sync
privi level 15
exit
int fa 0/0
no shut
ip address 10.0.0.3 255.255.255.0
int loop 0
ip address 3.3.3.3 255.255.255.0
exit
clock timezone PST -8
clock summer-time PDT recurring
ntp authentication-key 1 md5 cisco
ntp trusted-key 1
ntp authenticate
ntp server 10.0.0.1 key 1
ip domain-name INE.com
crypto key generate rsa general-keys modulus 1024
crypto isakmp policy 1
auth rsa-sig
exit
interface Tunnel0
bandwidth 1000
delay 1000
ip address 172.16.0.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication DMVPN_NW
ip nhrp map multicast 10.0.0.2
ip nhrp map 10.0.0.2 172.16.0.2
ip nhrp network-id 2210
ip nhrp holdtime 360
ip nhrp nhs 172.16.0.2
ip tcp adjust-mss 1360
tunnel source FA0/0
tunnel mode gre multipoint
tunnel key 6783
exit
router eigrp 1
network 172.16.0.0 0.0.255.255
network 3.3.3.3 0.0.0.0
no auto-summary
exit
crypto pki trustpoint R1-CA
enrollment url http://10.0.0.1:80
revocation-check none
exit
cry pki authenticate R1-CA
crypto pki enroll R1-CA
crypto gdoi group group1
identity number 1
server address ipv4 10.0.0.1
exit
crypto map map-group1 10 gdoi
set group group1
interface FastEthernet0/0
crypto map map-group1
end
R4 SpokeYour mission, should you choose to accept it, (feel free to hum the tune of mission impossible), is to find the errors regarding this configuration.
enable
conf t
hostname R4
ip domain-name INE.com
no ip domain-lookup
line con 0
no exec-time
logging sync
privi level 15
exit
int fa 0/0
no shut
ip address 10.0.0.4 255.255.255.0
int loop 0
ip address 4.4.4.4 255.255.255.0
exit
clock timezone PST -8
clock summer-time PDT recurring
ntp authentication-key 1 md5 cisco
ntp trusted-key 1
ntp authenticate
ntp server 10.0.0.1 key 1
ip domain-name INE.com
crypto key generate rsa general-keys modulus 1024
crypto isakmp policy 1
auth rsa-sig
exit
interface Tunnel0
bandwidth 1000
delay 1000
ip address 172.16.0.4 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication DMVPN_NW
ip nhrp map multicast 10.0.0.2
ip nhrp map 10.0.0.2 172.16.0.2
ip nhrp network-id 2210
ip nhrp holdtime 360
ip nhrp nhs 172.16.0.2
ip tcp adjust-mss 1360
tunnel source FA0/0
tunnel mode gre multipoint
tunnel key 6783
exit
router eigrp 1
network 172.16.0.0 0.0.255.255
network 4.4.4.4 0.0.0.0
no auto-summary
exit
crypto pki trustpoint R1-CA
enrollment url http://10.0.0.1:80
revocation-check none
exit
cry pki authenticate R1-CA
crypto pki enroll R1-CA
crypto gdoi group group1
identity number 1
server address ipv4 10.0.0.1
exit
crypto map map-group1 10 gdoi
set group group1
interface FastEthernet0/0
crypto map map-group1
end
Hint: there are 4 specific configuration related issues based on the proposed configuration.
Will you assist Bob in creating a working DMVPN/GET VPN solution?
PS Bob passes on his appreciation for all the help he has received from you in the past! The solutions you provided worked like a charm, and Bob is being treated like a Network Rock Star by his manager. Keep up the great work!
0 comments:
Post a Comment