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 Spoke 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 endYour mission, should you choose to accept it, (feel free to hum the tune of mission impossible), is to find the errors regarding this 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!
0 comments:
Post a Comment