Dec
19

The recording of last week's seminar on Introduction to DMVPN for CCIE R&S v5 Candidates is now available to view here.  This is the first of many new free seminars on new topics that have been added to the CCIE R&S version 5 blueprint.  New upcoming sessions will include IPv6 First Hop Security, IPsec LAN-to-LAN tunnels, GET VPN, IGP Convergence & Scalability, and BGP Convergence & Scalability, just to name a few. Feel free to submit requests for additional topics in the comments below.

 

Good luck in your studies!

Dec
05

Tomorrow, December 6th 2013, at 10:00 PST (GMT 18:00) I will be running a free live online session on Introduction to DMVPN for CCIE R&S v5 Candidates.  You can sign-up for this seminar here.  Additionally the link to attend is available at the top of the dashboard when you login to the INE Members Site.

This session is the first of many to help candidates transition from the current CCIE R&S v4 Blueprint to the recently announced CCIE R&S v5 Blueprint that goes live on June 4th 2014. We will continue to run additional sessions in the future on new topics that have been added to the CCIE R&S v5 Blueprint, such as IPv6 First Hop Security, IPsec LAN-to-LAN tunnels, GET VPN, IGP Convergence & Scalability, and BGP Convergence & Scalability, just to name a few.  These sessions are not only applicable to CCIE R&S v5 candidates, but also to those pursuing the CCNA, CCNP, or CCIE Security tracks, as well as for everyday engineers looking to apply these technologies in their production environments.

Tomorrow’s session will focus on the theory of what Dynamic Multipoint VPN (DMVPN) is, what problems it was designed to solve, and where it fits in the overall network design as compared to other technologies such as MPLS Virtual Private LAN Service (VPLS) or MPLS Layer 3 VPNs.  The session will also include live implementation examples of DMVPN on the Cisco IOS CLI.  Expect this session to run somewhere around 2 – 3 hours in length.

I hope to see you there!

Jun
23

INE is proud to announce the upcoming release of the following new additions to our All Access Pass Video-on-Demand library:

  • CCNA Security - Implementing Cisco IOS Network Security (640-553 IINS)
  • CCNP Security - Securing Networks with Cisco Routers and Switches (642-637 SECURE v1.0)
  • CCNP Security - Deploying Cisco ASA Firewall Solutions (642-617 FIREWALL v1.0)
  • CCNP Security - Deploying Cisco ASA VPN Solutions (642-647 VPN v1.0)
  • CCNP Security - Implementing Cisco Intrusion Prevention System v7.0 (642-627 IPS v7.0)
  • CCIE Security Advanced Technologies Class for Blueprint v3.0
  • CCIE Service Provider Advanced Technologies Class for Blueprint v3.0

All of these classes will be delivered by me, Brian McGahan - 3 x CCIE #8593.  Release dates for the CCNA Security and CCNP Security videos will be early and late July 2011 respectively.  The CCIE Security Advanced Technologies Class will be running as a live online class from July 25th – July 29th 2011, with an estimated release date of August 5th 2011 for the videos.  The CCIE Service Provider Advanced Technologies Class will be running as a live online class from August 29th – September 2nd 2011, with an estimated release date of September 9th 2011.

Subscribers to the All Access Pass will have immediate access to the streaming videos as they become available, and can attend the live online sessions of CCIE Security ATC and CCIE Service Provider ATC at no additional charge.  Seating is limited for the live class sessions, so contact sales@ine.com as soon as possible if you are interested in attending.  Download versions of each of the classes will be available for purchase as a standalone product, or as a discounted upgrade for AAP subscribers.

We will also releasing a new CCNA course delivered by Brian Dennis - 5 x CCIE #2210, and both CCNA Voice & CCNP Voice courses delivered by Mark Snow - 2 x CCIE #14073.  More details about these releases will be available soon.

 

Mar
09

As continuing pioneers of so many firsts in the CCIE training space, we have noted before on this blog how we have been offering you for over 6 months now, the first and only 100% web-based remote control client that controls not only CUCM SIP & SCCP phones, but also that controls SRST & CME SIP & SCCP phones. And we give it to you at no additional cost to your rental - it's built-in to every rack for free (no need to install a messy Windows-only software client). And now, we are very excited to offer you another first - the ability to access and control everything in our Voice Racks, with no need for any VPN client.

Simply use one of the following HTTP links below to access your Voice Rack (you must have a valid session during the time you try to authenticate):

Please take a moment to watch this instructional video on how to use this VPN-Less connection to access and control your Voice Rack and IP phones.

So to summarize:

  • No messing around with silly macros which don't apply in the CCIE Lab
  • Actual support for SRST (not only CME)
  • Who needs VPN?
  • A software client? Our lips shudder to even think it. No, we live in the real, web-based world
  • 7960's in our 3 Sites? What's the point?? They aren't usable when studying for the CCIE Lab - they're vastly different in every realm of configuration, which will only distract you from studying for the real exam - so why would we even consider including them? We don't, save for a PSTN phone, which just like in the real lab, you don't configure.

And to top it all off, our Voice Racks cost 1/4 of any others.

We look forward to continuing to being the first to bring you the best and brightest innovations that get you one step closer to both of our goals: You Passing Your CCIE Lab Exam.

May
28

In a recent post here on the INE blog, we received some follow-up questions similar to the following:

"Why do IPSec peers end up using tunnel mode, even though we had explicitly configured transport mode in the IPSec transform-set?"

It is an excellent question, and here is the answer.   In a site to site IPSec tunnel the "mode transport"  setting is only used when the traffic to be protected (traffic matching the Crypto ACLs) has the same IP addresses as the IPSec peers, and excludes all other IP addresses.   When Crypto ACLs include IP addresses beyond of the 2 peer endpoints the "mode transport" setting is ignored, and tunnel mode is negotiated (due to IP addresses, other than the 2 peers, being part of the crypto ACL).       There is also an option for the key word "require" after "mode transport" which will prevent the peers from negotiating tunnel mode, and if the IP addresses in the Crypto ACLs are outside of the peers's own IP addresses, IKE phase 2 will not successfully complete.

One notable exception to this, is GET VPN, where the KS policy of tunnel mode or transport mode will be used by the group members (whichever mode the KS has configured), regardless of the IP addresses used in the KS ACL for policy.

Below is a site to site example.  Let's use the following topology, with R1 and R3 being peers, and a Crypto ACL that says to encrypt all ICMP traffic, regardless of the IP addresses.   This Crypto ACL will cause our peers to ignore the mode transport option, and negotiate tunnel mode.

3 routers in a row-NO-user

Below are the full configs, some debug output, and show commands to demonstrate that even with transport mode explicitly configured in the transform sets, if the crypto ACLs don't exclusively include the endpoints of the VPN tunnel, the two peers go ahead and negotiate tunnel mode instead of transport mode.  Note the Crypto ACL includes all ICMP from any source to any destination.

First, here is R1:

R1#show run
!
hostname R1
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-sha-hmac
mode transport
!
crypto map MYMAP 10 ipsec-isakmp
set peer 23.0.0.3
set transform-set MYSET
match address 100
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
crypto map MYMAP
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
!
access-list 100 permit icmp any any
!
end

Now for R3

R3#show run
!
hostname R3
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-sha-hmac
mode transport
!
crypto map MYMAP 10 ipsec-isakmp
set peer 10.0.0.1
set transform-set MYSET
match address 100
!
interface FastEthernet0/1
ip address 23.0.0.3 255.255.255.0
crypto map MYMAP
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
access-list 100 permit icmp any any
!
end
R3#

Let's enable debug of crypto isakmp, and send a couple sets of PING requests from R3 to R1

R3#debug crypto isakmp
Crypto ISAKMP debugging is on

R3#ping 10.0.0.1 source 23.0.0.3 repeat 10

Here is the relevant portion of the debug output:

ISAKMP (0:1001): received packet from 10.0.0.1 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1001): processing HASH payload. message ID = 1137801467
ISAKMP:(1001): processing SA payload. message ID = 1137801467
ISAKMP:(1001):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP: attributes in transform:
ISAKMP: encaps is 1 (Tunnel)
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 3600
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
SAKMP: authenticator is HMAC-SHA
ISAKMP: key length is 128
ISAKMP:(1001):atts are acceptable.

To verify the tunnel mode is in place, we can look at the details of the SA:

R3# show crypto ipsec sa

interface: FastEthernet0/1
Crypto map tag: MYMAP, local addr 23.0.0.3

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/1/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/1/0)
current_peer 10.0.0.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
#pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 23.0.0.3, remote crypto endpt.: 10.0.0.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1
current outbound spi: 0x96474B70(2521254768)

inbound esp sas:
spi: 0x59B117E1(1504778209)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: SW:1, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4399136/3319)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x96474B70(2521254768)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: SW:2, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4399136/3319)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

Thanks for the question, and best wishes in all of your studies!

 

May
17

The two engineers, as they grabbed a quick lunch, looked over the following diagram.

3 routers in a row-tunnel-2

The 13.0.0.0/24 network is GRE.   The routing in place, uses the tunnel interfaces to reach the remote networks of 1.1.1.0 and 3.3.3.0.   The IPSec policy is to encrypt all GRE traffic between R1 and R3.  R1 and R3 are peering with each other using loopback 11 and loopback 33 respectively.

The technicians considered the traffic pattern if a host on the 3.3.3.0/24 network sent a packet to a device on the 1.1.1.0/24 network.

Then they reviewed the configurations (below), and discussed them. Based on what they saw, they just couldn’t agree completely with each other regarding the following questions?

1. How many IP headers would be in each packet.
2. What would the source and destination address be of each IP header.
3. What order the IP headers would be in (beginning with the outside header).
4. Would the IPSec be using transport or tunnel mode.
5. Would this be called IPSec over GRE, GRE over IPSec, or something else, (like "nightmare").

So they called for the expert, YOU, to assist in these questions.

Are you up to the challenge.   Answering even 1 of them will be appreciated, so take moment now, and GO FOR IT !

Post your ideas, and we will put all the people who post ideas into a virtual hat, and draw a winner to receive 100 rack tokens to our preferred lab gear provider, graded labs. Please have your posts in by

the end of the day Monday, May24, 2010 to be in the drawing.

UPDATE:

It is May 24 - 2010.  Here are the answers:

How many IP headers would be in each packet?

3 headers total. 1 outside header between the IPsec peers, and 2 encrypted headers in the ESP payload.  (I used host addresses of 1.1.1.1 and 3.3.3.3 in the ping testing.)

What would the source and destination address be of each IP header?

1. source 33.33.33.3 destination 11.11.11.1
2. source 23.0.0.3 destination 10.0.0.1
3. source 3.3.3.3 destination 1.1.1.1

What order the IP headers would be in (beginning with the outside header)?

Using the numbering above:
1=Outside (just before ESP)
2=IP header, used for transporting the GRE, which is now being encrypted by ESP
3=Original IP header, buried deep in the encrypted packed.

Without encryption, the packet would look like this:

Before Encryption

With encryption, it would look like this:

After Encryption

Would the IPSec be using transport or tunnel mode?

Tunnel.  Because the crypto ACL included IP addresses outside of the endpoints of the tunnel, the peers will negotiate and use tunnel mode, (even though we administratively configured transport mode on the transform-sets).

This would be called GRE over IPSec, as in “GRE traffic, being carried over the network by IPSec”.

Thanks to everyone who responded!

We put all who contributed (anything at all) into a hat and drew a name.    The winner of the 100 rack tokens is: Kingsley Charles ! (Please email me directly, and I will get the tokens for you.  My email address is kbarker@ine.com)

The full configs for R1 and R3 are below, as well as a couple show commands to assist in your final determination.

Best wishes.

 

 

R1#show run
hostname R1
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-des esp-md5-hmac
mode transport
!
crypto map MYMAP local-address Loopback11
crypto map MYMAP 10 ipsec-isakmp
set peer 33.33.33.3
set transform-set MYSET
match address 100
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip rip advertise 60
!
interface Loopback11
ip address 11.11.11.1 255.255.255.0
ip rip advertise 60
!
interface Tunnel0
ip address 13.0.0.1 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 23.0.0.3
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
ip rip advertise 60
duplex auto
speed auto
crypto map MYMAP
!
router rip
timers basic 60 90 90 90
network 10.0.0.0
network 11.0.0.0
!
ip route 3.0.0.0 255.0.0.0 Tunnel0
!
access-list 100 permit gre any any
end

R1#show ip route | begin resort
Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
R 2.0.0.0/8 [120/1] via 10.0.0.2, 00:00:27, FastEthernet0/0
R 33.0.0.0/8 [120/2] via 10.0.0.2, 00:00:27, FastEthernet0/0
S 3.0.0.0/8 is directly connected, Tunnel0
R 23.0.0.0/8 [120/1] via 10.0.0.2, 00:00:27, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
11.0.0.0/24 is subnetted, 1 subnets
C 11.11.11.0 is directly connected, Loopback11
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, Tunnel0
R1#

R1#show crypto map
Crypto Map: "MYMAP" idb: Loopback11 local address: 11.11.11.1

Crypto Map "MYMAP" 10 ipsec-isakmp
Peer = 33.33.33.3
Extended IP access list 100
access-list 100 permit gre any any
Current peer: 33.33.33.3
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
MYSET,
}
Interfaces using crypto map MYMAP:
FastEthernet0/0

R1#

******************************************************
******************************************************

R3#show run
hostname R3
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-des esp-md5-hmac
mode transport
!
crypto map MYMAP local-address Loopback33
crypto map MYMAP 10 ipsec-isakmp
set peer 11.11.11.1
set transform-set MYSET
match address 100
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip rip advertise 60
!
interface Loopback33
ip address 33.33.33.3 255.255.255.0
ip rip advertise 60
!
interface Tunnel0
ip address 13.0.0.3 255.255.255.0
tunnel source FastEthernet0/1
tunnel destination 10.0.0.1
!
interface FastEthernet0/1
ip address 23.0.0.3 255.255.255.0
ip rip advertise 60
duplex auto
speed auto
crypto map MYMAP
!
router rip
timers basic 60 90 90 90
network 23.0.0.0
network 33.0.0.0
!
ip route 1.0.0.0 255.0.0.0 Tunnel0
!
access-list 100 permit gre any any
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
line vty 0 4
privilege level 15
no login
!
!
end

R3#

R3#show ip route | begin resort
Gateway of last resort is not set

S 1.0.0.0/8 is directly connected, Tunnel0
R 2.0.0.0/8 [120/1] via 23.0.0.2, 00:00:48, FastEthernet0/1
33.0.0.0/24 is subnetted, 1 subnets
C 33.33.33.0 is directly connected, Loopback33
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C 23.0.0.0 is directly connected, FastEthernet0/1
R 10.0.0.0/8 [120/1] via 23.0.0.2, 00:00:48, FastEthernet0/1
R 11.0.0.0/8 [120/2] via 23.0.0.2, 00:00:48, FastEthernet0/1
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, Tunnel0

R3#show crypto map
Crypto Map: "MYMAP" idb: Loopback33 local address: 33.33.33.3

Crypto Map "MYMAP" 10 ipsec-isakmp
Peer = 11.11.11.1
Extended IP access list 100
access-list 100 permit gre any any
Current peer: 11.11.11.1
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
MYSET,
}
Interfaces using crypto map MYMAP:
FastEthernet0/1

R3#ping 1.1.1.1 so lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/152/180 ms
R3#

May
07

Thank you to all those who have submitted questions and comments to our blog and our CCIE Instructors. If you have a question, please email them to blog@ine.com.

Question 1:

Can anyone explain what is VPN intercept?

--
Bhavik Joshi

VPN Intercept can mean a few different things, depending on the specific context.

One interpretation is from a driver perspective, where a VPN connection breaks the binding between TCP/IP and the physical interface, acting as a shim.  See also:

http://www.informit.com/articles/article.aspx?p=25042

Another meaning can be in regards to intercepting SSL traffic.

See also:
http://www.howtoforge.com/ssl_vpn_one_time_passcodes_mutual_authentication
PPTP attacks:
http://www.sans.org/security-resources/malwarefaq/pptp-vpn.php
Cisco - VPN-based IPv4 Lawful Intercept Taps -
https://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/lawful_intercept/76LIch2.html#wp1058552

Answered by: Marvin Greenlee, CCIE #12237

Question 2:

Dear Valuable Technical Teachers and Friends,

First of all , i wish and thank you for your great support to those who are
all preparing Network studies. I've completed my CCNA two years back.Now am
preparing for next step. At this point, i have bit confusion of deciding
whether can i do CCNP or CCIE(R&S). I would like to reach a top level in
Cisco Networking technology.So am requesting your suggestions, which is best
for me.

Also can you suggest any good simulators to improve my practical skills.

--
Thanks,
K.Saleem Jaffer

Thanks for the question.   Having the CCIE certification makes for an excellent stepping stone in a technical career.   An important aspect to successfully passing the CCIE lab exam, is a very solid understanding of all the technologies involved.    A great way to prepare for this is through the CCNP level of studies.   If a person chooses that path, they would do well to take time to learn the technologies while studying CCNP, and not have the feeling of just learning enough to pass a CCNP written exam.  By truly  learning the core technologies in CCNP, it will serve as a springboard into the CCIE studies.   Many candidates waste large amounts of time in complex configurations, because they are lacking the basic understanding of the protocols and technologies that make up the scenario.    I would recommend a 1-2 yr plan, that begins with CCNP, carries into CCIE studies, and end with you attaining your CCIE.    Best wishes in your studies and journey.

Keith

Answered by: Keith Barker, CCIE #6783

Question 3:

Hi.

would u mind please, explaining the benefit of command "area x nssa default-information-originate" ? i know how we use it but i don't know its benefit? and do we use this command on ALL of the routers or just ABR? when we don't use this what will happen?

thanks a lot
timaz mohsenzadeh

The benefit of having a default route is that you have somewhere to send traffic when you don't have more specific information.

One point of using stub areas in OSPF is to minimize the information in the OSPF database.

With a stub area, you will have some OSPF routes, but not external routes (E1/E2) in the stub area.  So, if somewhere else across the topology, there is redistribution happening, the device in the stub area won't know about the redistributed networks.  Having a default route out to the ABR can be all that a stub area needs, if the ABR has the routing information to send the traffic forward to the destination.

The R&S Advanced Technologies Class section on OSPF area types shows the difference of not having this command, as well as looking at the contents of the OSPF database.

Marvin

Answered by: Marvin Greenlee, CCIE #12237

Question 4:

Hi everybody
I have a question regarding ISDN Backup. I have two cisco routers 800 (IOS 12.4(15)T5) and 1600 (IOS 12.1(4)).
The 800 router is the primary link with SHDSL and the backup router is the 1600 with ISDN.
I have OSPF running between these two routers and HSRP. Now when the primary link (SHDSL) fails,
the Backup router (1600) should take over. How can I solve this problem. Or what is a suitable solution.
I have searched various forums and cisco, but I can't find any sample according my example.
I am going to be an CCNA. But I guess there is much left to learn.

Thanks for your help.

Regards Alen

Firstly, you dont need OSPF unless you have IGP requirements for other routers behind the border rouers (the 800 and the 1600). You only need HSRP running between the routers and static reliable route on the primary gateway (SHDSL). Next, configure HSRP to track the static route object in the primary router, and lower the priority when the static route fails. Your Cisco 800 should support this functionaly, and the 1600 only needs to know if the active router changes. So here are the steps

1) Create an IP SLA object in the 800 router, pinging your provider's IP ("ip sla" commad)
2) Create an object tracking the state of IP SLA ping object ("track" commad)
3) Create a static default route in the 800 pointing to you ISP and tracking the object above
4) Configure static default route in the 1600
5) Configure HSRP so that 800 is the primary gateway
6) Configure the HSRP to track the object you created before ("standby XX track" command)
7) Ensure HSRP is configured to preempt so primary router may kick back in when the link recovers

This will ensure automatic switchover upon the lost of primary connection and automatic retun back to normal. You may want to read

http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html

for more information on reliable static routes.

Answered by: Petr Lapukhov's, CCIE #16379

Mar
27

In a word, "Way to GO" (without the spaces, that would be one word :) ). I am impressed at all the feedback and ideas we received regarding the IKE phase 1 riddle we posed last week. You can read the original post here. Ideas were creative and varied.

As one of our INE Instructors say, "If there are 2 different ways to configure something, as a CCIE candidate, you had better be prepared to know all 3 ".  If you would like to see "a solution", read on.

Ideas sent in included unique identities, isakmp profiles, DMVPN, GETVPN, virtual tunnel interfaces, key-rings, and a few even included full configurations regarding their ideas.  Excellent work and effort to all!

So a huge thanks goes out to Nick, Igor, Fedia, Jeff, AJN, MG, Paul A and Paul S!  Read below to find out which one of you won the tokens!

There are more than 1 way of solving this IKE challenge. My intention was to assist those getting ready for the lab with the absolute best preparation, and that preparation is practicing it. My feeling is that unless we have gone through the debugs for IKE phase 1, and IKE phase 2, and pushed through the CA authentication and enrollment process, we aren't ready to face the lab. When we are to the point that we can look at the debugs, and say, "Yup, that's the problem, and here's why" that is a good indication we are getting close to ready for that topic.

Here is the solution I put together for this task. I chose what I felt would be a fairly straight forward solution, separating the termination points, logically, for the different sets of traffic, and placing keys and IKE phase 1 policies strategically. One of the items, that I failed to remember while putting this solution together, was to match the EasyVPN group name on the server, with the OU name in the client certificate. I appreciate the opportunity to "remember" and to sharpen my skills too!

Here is the diagram again. Below it, the final solutions and verifications.

IKE several different ways

Here are the configurations for the routers, beginning with R1, which is the EasyVPN server. Both R1 and R2 authenticated and enrolled with R3 who acted as a CA server for this IPSec "get-together".

R1#show run brief
version 12.4
hostname R1
!
aaa new-model
!
aaa authentication login Method-2 local
aaa authorization network Method-1 local
clock timezone PST -8
clock summer-time PDT recurring
ip cef
!
no ip domain lookup
ip domain name ine.com
!
crypto pki trustpoint CA-R3
enrollment url http://3.3.3.3:80
fqdn R1.ine.com
subject-name O=ine, OU=vpn_group, CN=R1, C=us, ST=nv
revocation-check none
!
username admin privilege 15 password 0 cisco
!
crypto isakmp policy 1
encr 3des
group 2
!
crypto isakmp policy 2
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 2.2.2.2
!
crypto isakmp client configuration group vpn_group
pool MyPOOL
acl 100
save-password
netmask 255.255.255.0
!
crypto isakmp profile IKE-PROF-1
match identity group vpn_group
client authentication list Method-2
isakmp authorization list Method-1
client configuration address respond
virtual-template 1
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto ipsec profile IPSec-PROF-1
set transform-set ESP-3DES-SHA
set isakmp-profile IKE-PROF-1
!
crypto map MYMAP 1 ipsec-isakmp
set peer 2.2.2.2
set transform-set ESP-3DES-SHA
match address 101
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface Loopback4
ip address 4.0.0.1 255.255.255.0
!
interface Loopback5
ip address 5.0.0.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.12.0.1 255.255.255.0
crypto map MYMAP
!
!
interface Virtual-Template1 type tunnel
ip unnumbered Loopback0
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSec-PROF-1
!
router rip
version 2
network 1.0.0.0
network 4.0.0.0
network 5.0.0.0
network 10.0.0.0
no auto-summary
!
ip local pool MyPOOL 4.0.0.51 4.0.0.100
!
!
access-list 100 permit ip 4.0.0.0 0.0.0.255 any
access-list 101 permit ip 5.0.0.0 0.0.0.255 7.0.0.0 0.0.0.255

line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
line vty 0 4
privilege level 15
!
ntp authentication-key 1 md5 0822455D0A16 7
! Note: the trusted-key statement isn't needed on the server, but there is a bug
! that on some IOS versions causes to not function if it is not there.
ntp trusted-key 1
ntp source Loopback0
ntp master 5
!
end

R1#

What a fun read that was. Now for R2.

R2#show run brief
version 12.4
hostname R2
clock timezone PST -8
clock summer-time PDT recurring
ip cef
!
no ip domain lookup
ip domain name ine.com
!
crypto pki trustpoint CA-R3
enrollment url http://3.3.3.3:80
fqdn R2.ine.com
subject-name O=ine, OU=vpn_group, CN=R2, C=us, ST=nv
revocation-check none
!
username admin privilege 15 password 0 cisco
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 10.12.0.1
!
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto ipsec client ezvpn EZVPN_CLIENT
connect auto
mode network-extension
peer 1.1.1.1
virtual-interface 1
username admin password cisco
xauth userid mode local
!
crypto map MYMAP local-address Loopback0
crypto map MYMAP 1 ipsec-isakmp
set peer 10.12.0.1
set transform-set ESP-3DES-SHA
match address 100
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
interface Loopback6
ip address 6.0.0.2 255.255.255.0
crypto ipsec client ezvpn EZVPN_CLIENT inside
!
interface Loopback7
ip address 7.0.0.2 255.255.255.0
!
interface FastEthernet0/0
ip address 10.12.0.2 255.255.255.0
crypto map MYMAP
crypto ipsec client ezvpn EZVPN_CLIENT
!
interface Serial0/1
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial0/1.23 point-to-point
ip address 10.23.0.2 255.255.255.0
frame-relay interface-dlci 203
!
interface Virtual-Template1 type tunnel
no ip address
tunnel mode ipsec ipv4
!
router rip
version 2
network 2.0.0.0
network 6.0.0.0
network 7.0.0.0
network 10.0.0.0
no auto-summary
!
access-list 100 permit ip 7.0.0.0 0.0.0.255 5.0.0.0 0.0.0.255
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
line vty 0 4
privilege level 15
no login
!
ntp authentication-key 1 md5 05080F1C2243 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179982
ntp server 1.1.1.1
!
end

R2#

Let's start the verification process on R1. We will clear the tunnels, and initiate traffic from R2 from network 4 to 6, and then from network 5 to 7. Because R2 is an EasyVPN remote, it will be initiating the tunnel back for the network 6 to 4 encryption with EasyVPN (nothing to to with IPv6 tunnels) :)

R1#clear crypto isakmp
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
R1#clear crypto sa
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
R1#ping 6.0.0.2 source 4.0.0.1 repeat 15

Type escape sequence to abort.
Sending 15, 100-byte ICMP Echos to 6.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 4.0.0.1
!!!!!!!!!!!!!!!
Success rate is 100 percent (15/15), round-trip min/avg/max = 72/179/252 ms
R1#ping 7.0.0.2 source 5.0.0.1 repeat 75

Type escape sequence to abort.
Sending 75, 100-byte ICMP Echos to 7.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 5.0.0.1
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!
Success rate is 98 percent (74/75), round-trip min/avg/max = 28/154/292 ms
R1#show crypto ipsec sa

interface: FastEthernet0/0
Crypto map tag: MYMAP, local addr 10.12.0.1

protected vrf: (none)
local ident (addr/mask/prot/port): (5.0.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (7.0.0.0/255.255.255.0/0/0)
current_peer 2.2.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 74, #pkts encrypt: 74, #pkts digest: 74 #pkts decaps: 74, #pkts decrypt: 74, #pkts verify: 74
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 10.12.0.1, remote crypto endpt.: 2.2.2.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xEB4512D2(3947172562)

inbound esp sas:
spi: 0xE00894E5(3758658789)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 37, flow_id: SW:37, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4398286/3579)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xEB4512D2(3947172562)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 38, flow_id: SW:38, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4398286/3579)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

interface: Virtual-Access2
Crypto map tag: Virtual-Access2-head-0, local addr 1.1.1.1

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.12.0.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 17, #pkts encrypt: 17, #pkts digest: 17 #pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 1.1.1.1, remote crypto endpt.: 10.12.0.2
path mtu 1514, ip mtu 1514, ip mtu idb Loopback0
current outbound spi: 0xB923167D(3106084477)

inbound esp sas:
spi: 0x44649B73(1147444083)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 35, flow_id: SW:35, crypto map: Virtual-Access2-head-0
sa timing: remaining key lifetime (k/sec): (4575108/3520)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB923167D(3106084477)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 36, flow_id: SW:36, crypto map: Virtual-Access2-head-0
sa timing: remaining key lifetime (k/sec): (4575107/3520)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

R1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
1.1.1.1 10.12.0.2 QM_IDLE 1015 0 ACTIVE 2.2.2.2 10.12.0.1 QM_IDLE 1016 0 ACTIVE

R1#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.

1015 1.1.1.1 10.12.0.2 ACTIVE 3des sha rsig 2 23:58:18 CX
Engine-id:Conn-id = SW:15

1016 10.12.0.1 2.2.2.2 ACTIVE 3des sha psk 2 23:59:24
Engine-id:Conn-id = SW:16
R1#

Now we will look at R2, using the same process. Clear the SAs, then send interesting traffic.

R2#clear crypto isakmp
%CRYPTO-6-EZVPN_CONNECTION_DOWN: (Client) User=admin Group= Server_public_addr=1.1.1.1 c
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
R2#clear crypto sa
R2#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
R2#
%CRYPTO-6-EZVPN_CONNECTION_UP: (Client) User=admin Group= Server_public_addr=1.1.1.1
R2#
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
R2#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
R2#ping 4.0.0.1 source 6.0.0.2 repeat 32

Type escape sequence to abort.
Sending 32, 100-byte ICMP Echos to 4.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 6.0.0.2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (32/32), round-trip min/avg/max = 128/171/256 ms
R2#ping 5.0.0.1 source 7.0.0.2 repeat 99

Type escape sequence to abort.
Sending 99, 100-byte ICMP Echos to 5.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 7.0.0.2
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 98 percent (98/99), round-trip min/avg/max = 16/133/352 ms
R2#show crypto ipsec client ezvpn
Easy VPN Remote Phase: 6

Tunnel name : SDM_EZVPN_CLIENT_1
Inside interface list: Loopback6
Outside interface: Virtual-Access1 (bound to FastEthernet0/0)
Current State: IPSEC_ACTIVE
Last Event: MTU_CHANGED
Save Password: Allowed
Split Tunnel List: 1
Address : 4.0.0.0
Mask : 255.255.255.0
Protocol : 0x0
Source Port: 0
Dest Port : 0
Current EzVPN Peer: 1.1.1.1

R2#show crypto ipsec sa

interface: Virtual-Access1
Crypto map tag: Virtual-Access1-head-0, local addr 10.12.0.2

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 1.1.1.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 32, #pkts encrypt: 32, #pkts digest: 32 #pkts decaps: 35, #pkts decrypt: 35, #pkts verify: 35
#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

local crypto endpt.: 10.12.0.2, remote crypto endpt.: 1.1.1.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xB7873D1E(3079093534)

inbound esp sas:
spi: 0xE8738BE2(3899886562)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 39, flow_id: SW:39, crypto map: Virtual-Access1-head-0
sa timing: remaining key lifetime (k/sec): (4595984/3495)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB7873D1E(3079093534)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 40, flow_id: SW:40, crypto map: Virtual-Access1-head-0
sa timing: remaining key lifetime (k/sec): (4595985/3495)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

interface: FastEthernet0/0
Crypto map tag: MYMAP, local addr 2.2.2.2

protected vrf: (none)
local ident (addr/mask/prot/port): (7.0.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (5.0.0.0/255.255.255.0/0/0)
current_peer 10.12.0.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 98, #pkts encrypt: 98, #pkts digest: 98 #pkts decaps: 98, #pkts decrypt: 98, #pkts verify: 98
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 2.2.2.2, remote crypto endpt.: 10.12.0.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x419146C7(1100039879)

inbound esp sas:
spi: 0xEFAA9897(4020934807)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 41, flow_id: SW:41, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4378766/3562)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x419146C7(1100039879)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 42, flow_id: SW:42, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4378766/3562)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

R2# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
1.1.1.1 10.12.0.2 QM_IDLE 1017 0 ACTIVE 10.12.0.1 2.2.2.2 QM_IDLE 1018 0 ACTIVE

R2# show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.

1017 10.12.0.2 1.1.1.1 ACTIVE 3des sha rsig 2 23:57:32 CX
Engine-id:Conn-id = SW:17

1018 2.2.2.2 10.12.0.1 ACTIVE 3des sha psk 2 23:59:12
Engine-id:Conn-id = SW:18

Thanks again to all who posted ideas.

I did a drawing from all the people who contributed, and the winner of the 50 rack tokens to our preferred rack vendor Graded Labs goes to Nick! Congratulations Nick, please email me privately and send me the email address that you use for your INE account, and I will have the tokens credited to your account. Again, thanks to all for all your contributions!

Keep up the great studies, hang in there, and never surrender.

P.S.  Bob says "thank you"  ;)

Best wishes.

Nov
24

For Part 2 of this series, click here.

The following questions will be added to the Core Knowledge Simulation engine.   Answers will be provided in the comments section.

Implement Identity Management

Refer to the diagram.   The software running on the PC performs what role?

Basic 802.1x

Configure Cisco IPS to mitigate network threats

Refer to the diagram.   How are IPS alerts from the IOS router collected on IME and MARS?

IOS IPS

Implement secure networks using Cisco ASA Firewalls

When a new policy-map is applied globally, what effect does that have on the interfaces of the ASA?

Implement secure networks using Cisco VPN solutions

What layer 4 ports / protocols would  typically be used as part of a GDOI implementation?

Nov
21

Some time ago I mentioned that it is possible to configure a functional GET VPN scenario using just two routers. Normally, GET VPN requires a dedicated Key Server, which does not participate is user traffic encryption and only distributes keying information and encryption policies. All other routers – group members – register to the Key Server. A router could not register to itself when configured as a key server and group member simultaneously. However, there is a Key Server redundancy feature known as KOOP Key Servers that allows for two servers to synchronize the keying information and the group member to register to the redundant key servers.

Relying upon this feature, we may take two routers and configure them both in a KOOP key server pair. At the same time, every router is configured as a Group Member registering to another router. Since the keying information is being kept in sync, both routers will be able to properly exchange encrypted GET VPN traffic. Now, for the practical implementation we chose two directly connected routers: R4 and R5. GET VPN is supposed to encrypt traffic sent off respective VLAN4 and VLAN5 interfaces of these routers destined to the multicast groups in range 232.0.0.0/8. The IP addresses for VLAN4 and VLAN5 subnets are 173.X.4.0/24 and 173.X.5.0/24. Here is how we configure R4 for Key Server functionality. Notice the redundancy configuration using R5 as the peer.

KS-R4:
crypto isakmp keepalive 10 periodic
!
crypto isakmp policy 50
encr 3des
hash md5
group 2
authentication pre-share

crypto isakmp key CISCO address 150.1.5.5

crypto ipsec transform-set GETVPN_TS esp-3des esp-md5-hmac

crypto ipsec profile GETVPN_PROFILE
set transform-set GETVPN_TS
!
crypto key generate rsa general-keys label GETVPN_KEYS modulus 1024 exportable
!
no access-list 100
access-list 100 permit ip 173.1.4.0 0.0.0.255 232.0.0.0 0.255.255.255
access-list 100 permit ip 173.1.5.0 0.0.0.255 232.0.0.0 0.255.255.255
!
crypto gdoi group GETVPN_GROUP
identity number 1234
server local
rekey authentication mypubkey rsa GETVPN_KEYS
rekey transport unicast
sa ipsec 1
profile GETVPN_PROFILE
match address ipv4 100
replay time window-size 5
address ipv4 150.1.4.4
redundancy
local priority 100
peer address ipv4 150.1.5.5

Now an important thing. GET VPN uses RSA signatures to authenticate GET VPN keying information. Because of that, both R4 and R5 should use the same private/public keys for signing. To accomplish this, export the keys from the first KS and import them in the second. For example, considering R4 was configured as the first KS, you may use the commands below to export/import RSA keys using IOS CLI (don’t forget the blank line between the public and private keys when importing).

Export Keys at R4:
crypto key export rsa GETVPN_KEYS pem terminal 3des CISCO1234

Import Keys at R5:
crypto key import rsa GETVPN_KEYS pem exportable terminal CISCO1234

After you have imported the RSA keys in R5, configure R5 for the Key server functionality. Notice that the imported key pair is used for GET VPN keying information signing.

KS-R5:
crypto isakmp keepalive 10 periodic
!
crypto isakmp policy 10
encr 3des
hash md5
group 2
authentication pre-share

crypto isakmp key CISCO address 150.1.4.4

crypto ipsec transform-set GETVPN_TS esp-3des esp-md5-hmac

crypto ipsec profile GETVPN_PROFILE
set transform-set GETVPN_TS
!
access-list 100 permit ip 173.1.4.0 0.0.0.255 232.0.0.0 0.255.255.255
access-list 100 permit ip 173.1.5.0 0.0.0.255 232.0.0.0 0.255.255.255
!
crypto gdoi group GETVPN_GROUP
identity number 1234
server local
rekey authentication mypubkey rsa GETVPN_KEYS
rekey transport unicast
sa ipsec 1
profile GETVPN_PROFILE
match address ipv4 100
replay time window-size 5
address ipv4 150.1.5.5
redundancy
local priority 50
peer address ipv4 150.1.4.4

This completes the KOOP Key Server configuration part. The next part, which is relatively simple, is configuring both routers as group members. As a group member, R4 should register to R5 and vice versa. Notice that there could be a separate ISAKMP policy used for GM/KS communications, but we just re-use the same settings.

GM-R4:
crypto isakmp policy 50
encr 3des
hash md5
authentication pre-share
group 2
!
crypto gdoi group GETVPN_GROUP_GM
identity number 1234
server address ipv4 150.1.5.5

crypto map GETVPN_MAP local-address Loopback0
crypto map GETVPN_MAP 10 gdoi
set group GETVPN_GROUP_GM
!
interface Serial0/1/0
crypto map GETVPN_MAP

GM-R5:
crypto isakmp policy 50
encr 3des
hash md5
authentication pre-share
group 2
!
crypto gdoi group GETVPN_GROUP_GM
identity number 1234
server address ipv4 150.1.4.4

crypto map GETVPN_MAP local-address Loopback0
crypto map GETVPN_MAP 10 gdoi
set group GETVPN_GROUP_GM
!
interface Serial0/1/0
crypto map GETVPN_MAP

Both GM crypto-maps use Loopback0 as the source interface, but this only affects the ISAMP phase, as GET VPN by design simply copies the original header. The last two steps complete the two-node GET VPN configuration. Now for verification. – start by checking for KOOP KS:

Rack1R4#show crypto gdoi ks 
Total group members registered to this box: 1

Key Server Information For Group GETVPN_GROUP:
Group Name : GETVPN_GROUP
Group Identity : 1234
Group Members : 1
IPSec SA Direction : Both
ACL Configured:
access-list 100
Redundancy : Configured
Local Address : 150.1.4.4
Local Priority : 100
Local KS Status : Alive
Local KS Role : Primary

Rack1R5#show crypto gdoi ks
Total group members registered to this box: 2

Key Server Information For Group GETVPN_GROUP:
Group Name : GETVPN_GROUP
Group Identity : 1234
Group Members : 2
IPSec SA Direction : Both
ACL Configured:
access-list 100
Redundancy : Configured
Local Address : 150.1.5.5
Local Priority : 50
Local KS Status : Alive
Local KS Role : Secondary

Check the data-plane status (IPSec SAs):

Rack1R4#show crypto gdoi ipsec sa 

SA created for group GETVPN_GROUP:

SA created for group GETVPN_GROUP_GM:
Serial0/1/0:
protocol = ip
local ident = 173.1.4.0/24, port = 0
remote ident = 232.0.0.0/8, port = 0
direction: Both, replay(method/window): Time/5 sec
protocol = ip
local ident = 173.1.5.0/24, port = 0
remote ident = 232.0.0.0/8, port = 0
direction: Both, replay(method/window): Time/5 sec

Rack1R5#show crypto gdoi ipsec sa

SA created for group GETVPN_GROUP:

SA created for group GETVPN_GROUP_GM:
Serial0/1/0:
protocol = ip
local ident = 173.1.4.0/24, port = 0
remote ident = 232.0.0.0/8, port = 0
direction: Both, replay(method/window): Time/5 sec
protocol = ip
local ident = 173.1.5.0/24, port = 0
remote ident = 232.0.0.0/8, port = 0
direction: Both, replay(method/window): Time/5 sec

Now initiate some multicast traffic and ensure it is getting encrypted: The test below assumes R4 has joined the respective multicast group:

Rack1R5#ping 232.1.1.1 source fastEthernet 0/1 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 173.1.5.5

Reply to request 0 from 173.1.45.4, 40 ms
Reply to request 1 from 173.1.45.4, 36 ms

Rack1R4#show crypto ipsec sa

interface: Serial0/1/0

protected vrf: (none)
local ident (addr/mask/prot/port): (173.1.5.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (232.0.0.0/255.0.0.0/0/0)
current_peer 0.0.0.0 port 848
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 107, #pkts decrypt: 107, #pkts verify: 107
#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

local crypto endpt.: 150.1.4.4, remote crypto endpt.: 0.0.0.0
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0
current outbound spi: 0xF66A6278(4134167160)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0xF66A6278(4134167160)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2011, flow_id: FPGA:11, sibling_flags 80000040, crypto map: GETVPN_MAP
sa timing: remaining key lifetime (sec): (2387)
IV size: 8 bytes
replay detection support: Y replay window size: 5
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xF66A6278(4134167160)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2012, flow_id: FPGA:12, sibling_flags 80000040, crypto map: GETVPN_MAP
sa timing: remaining key lifetime (sec): (2387)
IV size: 8 bytes
replay detection support: Y replay window size: 5
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

This final test ensures that our two-node configuration is working. Finally, this type of configuration is just a curious example, which probably has little application in real life, where you probably want a dedicated GET VPN Server. However, from the CCIE Security Lab standpoint it is important to understand the interaction between GET VPN components and know the little tricks that could be used.

Subscribe to INE Blog Updates