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!

Keith

Keith

Tagged with:
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,
Keith

Keith

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#
Tagged with:
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

Tagged with:
Apr 29

Probably one of the most confusing topics for people studying BGP/MPLS VPNs are EIGRP SoO and Cost communities. Not the concepts themselves, but rather their purpose. Lack of clear documentation makes it hard to understand why and how the specific features are implemented. In this blog post we discuss the BGP Cost community and EIGRP SoO attribute. First, a brief overview of MP-BGP is given along with general concepts of route redistribution in MPLS/BGP VPNs. Next, the problems that arise when using EIGRP in multihomed VPN environment are demonstrated. Lastly, the two specific EIGRP features are described and their use demonstrated. As usual, a reader is assumed to have basic understanding of fundamental L3 VPNs and PE-CE routing concepts. You may download the post in PDF format at the following link: Understanding EIGRP SoO and BGP Cost Community

Tagged with:
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 my friend and co-worker Marvin Greenlee says, “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,

Keith

Keith

Tagged with:
Nov 24
Test your core knowledge skills for the Security CCIE track...
Tagged with:
Nov 21
Some time ago I mentioned that it is possible to configure a functional GET VPN scenario using just two routers. It is finally time to demonstrate the actual configuration 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 [...]
Tagged with:
Oct 12
VRF and IPSec integration with a twist of Transparent IOS. Bob pushes the envelope, one more time...
Tagged with:
preload preload preload