There are still a few days left to get any questions you might have about the CCIE Security Lab Exam in to Yusuf Bhaiji, but hurry – the discussion ends Monday 13 Sept!

Time is a valuable resource in the lab.   In a lab task, if asked to configure a policy-map named “BOB”, it doesn’t get the same point value if we happen to accidentally name it “bob”, especially  if they are looking to see if you configured what they asked for.

The challenge is, that when reviewing a lab task, and we discover that we need to change a name, it could be a hassle, as we need to remove the policy-map, recreate the policy map, and then put it in place again.

So if you are down to the last minute, here is a time saving solution, that can assist with that process.

IOS allows us to rename a policy-map, and the IOS will swap out the name in other areas of the configuration that reference that policy map.

Here is an example, of a policy map from Volume 2, lab 5.

Rack1R5#show run policy-map
Building configuration...

Current configuration : 352 bytes
!
policy-map TRANSIT_RATE_LIMIT
class FRAGMENTS
   police rate 1000000 pps burst 200000 packets
policy-map type port-filter HOST_PORT_FILTER
class CLOSED_PORTS
   drop
policy-map CEF_EXCEPTION_RATE_LIMIT
class class-default
   police rate 100 pps burst 20 packets
policy-map HOST_RATE_LIMIT
class ICMP
   police rate 10 pps burst 5 packets
!
end

Rack1R5#show run | begin control
control-plane host
service-policy input HOST_RATE_LIMIT
service-policy type port-filter input HOST_PORT_FILTER
!
control-plane transit
service-policy input TRANSIT_RATE_LIMIT
!
control-plane cef-exception
service-policy input CEF_EXCEPTION_RATE_LIMIT

Let’s say that after reviewing our configuration, we discovered that the policy-map for the cef-exception sub interface of the control plane should have been named “NEW-NAME-CEF”.

To change it everywhere in the configuration, instead of creating it new, and replacing it, we could simply do this:

Rack1R5(config)#policy-map CEF_EXCEPTION_RATE_LIMIT
Rack1R5(config-pmap)#rename NEW-NAME-CEF

Now, when we look at the configuration, we can see that not only the name has changed for the policy-map, but it also updated our control-plane configuration to reflect the new name there as well:

Rack1R5#show run policy-map
Building configuration...

Current configuration : 340 bytes
!
policy-map TRANSIT_RATE_LIMIT
class FRAGMENTS
   police rate 1000000 pps burst 200000 packets
policy-map type port-filter HOST_PORT_FILTER
class CLOSED_PORTS
   drop
policy-map NEW-NAME-CEF
class class-default
   police rate 100 pps burst 20 packets
policy-map HOST_RATE_LIMIT
class ICMP
   police rate 10 pps burst 5 packets
!
end

Rack1R5#show run | begin control
control-plane host
service-policy input HOST_RATE_LIMIT
service-policy type port-filter input HOST_PORT_FILTER
!
control-plane transit
service-policy input TRANSIT_RATE_LIMIT
!
control-plane cef-exception
service-policy input NEW-NAME-CEF
!
!

Best wishes on your studies, and may your policy-maps be named correctly the first time around.

Keith

“Why doesn’t this PING work!?!”

Here is a simple 3 router configuration, well at least it is simple on 2 of the 3 routers. R1 and R3 are configured quite traditionally, but R2 is a bit more involved.
Here is the diagram.

Here are the details.

R2 is using a VRF which includes both LAN interfaces. R2 is also acting as a Zone Based Firewall in transparent mode, allowing all ICMP traffic in both directions, as well as SSH from the inside to the outside networks. R2 has a bridged virtual interface in the 10.123.0.0/24 network. All are running OSPF, but pings issued from R2 to the loopbacks of R1 and R3 are failing.

Can you identify why?
Here is the relevant output:

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   FULL/DR         00:00:39    10.123.0.3      FastEthernet0/0
10.123.0.2        1   FULL/BDR        00:00:32    10.123.0.2      FastEthernet0/0
R1#show ip route ospf
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/2] via 10.123.0.3, 00:01:33, FastEthernet0/0

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/172 ms
R1#ssh -l admin 3.3.3.3
Password: <password>

R3#show ssh
Connection Version Mode Encryption  Hmac         State                 Username
0          1.99     IN   aes128-cbc  hmac-sha1    Session started       admin
0          1.99     OUT  aes128-cbc  hmac-sha1    Session started       admin
%No SSHv1 server connections running.
R3#exit

[Connection to 3.3.3.3 closed by foreign host]
R1#

Now for R2:

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DROTHER    00:00:37    10.123.0.1      BVI1
3.3.3.3           1   FULL/DR         00:00:35    10.123.0.3      BVI1

R2#show ip route ospf

R2#show policy-map type inspect zone-pair
 Zone-pair: zp-in-to-out

  Service-policy inspect : p-in-to-out

    Class-map: c-in-to-out (match-any)
      Match: protocol icmp
        4 packets, 320 bytes
        30 second rate 0 bps
      Match: protocol ssh
        3 packets, 72 bytes
        30 second rate 0 bps
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [4:390]
        icmp packets: [0:50]

        Session creations since subsystem startup or last reset 8
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [2:1:1]
        Last session created 00:02:23
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 3
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any
      Drop (default action)
        0 packets, 0 bytes
 Zone-pair: zp-out-to-in

  Service-policy inspect : p-out-to-in

    Class-map: c-out-to-in (match-all)
      Match: protocol icmp
      Inspect
        Packet inspection statistics [process switch:fast switch]
        icmp packets: [0:20]

        Session creations since subsystem startup or last reset 2
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [1:1:0]
        Last session created 00:25:24
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 1
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any
      Drop (default action)
        4 packets, 96 bytes

R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2# show run
version 12.4
hostname R2
!
ip vrf myvrf
!
class-map type inspect match-any c-in-to-out
 match protocol icmp
 match protocol ssh
class-map type inspect match-all c-out-to-in
 match protocol icmp
!
policy-map type inspect p-in-to-out
 class type inspect c-in-to-out
  inspect
 class class-default
policy-map type inspect p-out-to-in
 class type inspect c-out-to-in
  inspect
 class class-default
!
zone security inside
zone security outside
zone-pair security zp-in-to-out source inside destination outside
 service-policy type inspect p-in-to-out
zone-pair security zp-out-to-in source outside destination inside
 service-policy type inspect p-out-to-in
bridge irb
!
interface FastEthernet0/0
 ip vrf forwarding myvrf
 no ip address
 zone-member security inside
 bridge-group 1
!
interface FastEthernet0/1
 ip vrf forwarding myvrf
 no ip address
 zone-member security outside
 bridge-group 1
!
interface BVI1
 ip vrf forwarding myvrf
 ip address 10.123.0.2 255.255.255.0
!
router ospf 1 vrf myvrf
 router-id 10.123.0.2
 network 0.0.0.0 255.255.255.255 area 0
!
bridge 1 protocol ieee
bridge 1 route ip
end

Here is R3:

R3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DROTHER    00:00:32    10.123.0.1      FastEthernet0/1
10.123.0.2        1   FULL/BDR        00:00:31    10.123.0.2      FastEthernet0/1

R3#show ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.123.0.1, 00:29:36, FastEthernet0/1

R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/117/176 ms
R3#

Similar configuration scenarios are included in both our RS and SC workbooks at INE.

Take a moment, and post your ideas on why the PING from R2 is failing, and thanks for taking the time to assist!

Best wishes, Keith

Join us Friday, June 25th at 11AM Pacific / 2PM Eastern for another installment in the Open Lecture Series.

The topic that will be covered is Privilege Levels and Role Based CLI.

We look forward to seeing you there. Seats are limited.

A big shout out to all the students in the Raleigh Security CCIE bootcamp last week.   I had a blast!   Thank you for all your hard work, as well as the after hours discussions about the unknown, and why people feel they know it. 

I promised a few blog posts related to security over the next few weeks, and this one is regarding Certificate-based ACLs.

This blog may also serve as a review on how to configure the CA clients so that their certificates contain various fields and values, such as subject-name.

Let’s use this diagram for the backdrop of our discussion:

R2 will be the NTP and CA server with R1 and R3 as IPSec VPN peers.  (Remember, with certificates we really do need time to be on “our side”). 

R1’s configuration for the trustpoint is as follows:

crypto pki trustpoint R2
enrollment url http://2.2.2.2:80
serial-number
ip-address 10.0.0.1
subject-name cn=R1,ou=ccsp,o=ine,st=NV,c=US
revocation-check none

R3’s configuration for the trustpoint is here:

crypto pki trustpoint R2
enrollment url http://2.2.2.2:80
serial-number
ip-address 23.0.0.3
subject-name cn=R3,ou=ccie,o=ine,st=NV,c=US
revocation-check none

The problem, is that any device that has a valid certificate from R2, would be able to authenticate with R1 and R3 (from a CA perspective regarding certificates).   If R3 wanted to limit the peers it would authenticate with, we can use a certificate map, which acts as Certificate based Access Control.  A certificate map looks for specific fields from the peers certificate, and values for those fields (specified by the certificate map).   The router will only accept a certificate from a peer if the certificate map specified fields/values from the would-be peer’s certificate match, and if they don’t match, then the IKE phase 1 won’t complete.     We could match several fields from the peers certificate.  The field-name is one of the following case-insensitive name strings or a date:

–subject-name

–issuer-name

–unstructured-subject-name

–alt-subject-name

–name

–valid-start

–expires-on

The match-criteria is one of the following :

–eq—equal (valid for name and date fields)

–ne—not equal (valid for name and date fields)

–co—contains (valid only for name fields)

–nc—does not contain (valid only for name fields)

–lt—less than (valid only for date fields)

–ge—greater than or equal (valid only for date fields)

To begin, lets look at what is in R1’s certificate.

R1#show crypto pki certificates
Certificate
 Status: Available
 Certificate Serial Number: 0x2
 Certificate Usage: General Purpose
 Issuer:
 cn=R2
 ou=CA-OF-THE-WORLD
 o=INE
 st=NV
 c=US
 Subject:
 Name: R1.ine.com
 IP Address: 10.0.0.1
 Serial Number: XXXXXXXXXXX
 serialNumber=XXXXXXXXXXX+ipaddress=10.0.0.1+hostname=R1.ine.com
 cn=R1
 ou=ccsp
 o=ine
 st=NV
 c=US
 Validity Date:
 start date: 14:05:12 PDT Jun 15 2010
 end   date: 14:05:12 PDT Jun 15 2011
 Associated Trustpoints: R2

We have several choices, but let’s select the cn field in our example.    On R3, we will create a certificate map, that is looking for the subject-name to contain the value of “R1″.  The certificate map is inserted into the PKI trustpoint configuration.

R3:

crypto pki certificate map CERT-MAP 1
 subject-name co R1
 exit 

crypto pki trustpoint R2
 match certificate CERT-MAP
 exit

With this in place, the IKE phase 1 works, and encrypted traffic flows between the peers.

If we change the Certificate Map to look for for the string R9 (which won’t match inside of R1’s certificate) and then test the VPN connection, we can see the debug messages and the certificate error:

R3(config)#crypto pki certificate map CERT-MAP 1
R3(ca-certificate-map)#no subject-name co r1
R3(ca-certificate-map)# subject-name co r9

R3#debug crypto isakmp
Crypto ISAKMP debugging is on

R3#clear crypto sa
R3#clear crypto isakmp

R3#ping 1.1.1.1 so lo 0 re 1

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

IPSEC(sa_request): ,
 (key eng. msg.) OUTBOUND local= 23.0.0.3, remote= 10.0.0.1,
 local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
 remote_proxy= 1.1.1.1/255.255.255.255/0/0 (type=1),
 protocol= ESP, transform= esp-aes esp-sha-hmac  (Tunnel),
 lifedur= 3600s and 4608000kb,
 spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 10.0.0.1, peer port 500
ISAKMP: New peer created peer = 0x66031B38 peer_handle = 0x80000009
ISAKMP: Locking peer struct 0x66031B38, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 66033338
ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
ISAKMP:(0):No pre-shared key with 10.0.0.1!
ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1

ISAKMP:(0): beginning Main Mode exchange
ISAKMP:(0): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_NO_STATE
ISAKMP:(0):Sending an IKE IPv4 Packet.
ISAKMP (0:0): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_NO_STATE
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_I_MM2

ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismat.
Success rate is 0 percent (0/1)
R3#ch
ISAKMP (0:0): vendor ID is NAT-T RFC 3947
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 65535 policy
ISAKMP:      encryption DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth RSA sig
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP:(0):Acceptable atts:actual life: 0
ISAKMP:(0):Acceptable atts:life: 0
%CRYPTO-4-IKE_DEFAULT_POLICY_ACCEPTED: IKE default policy was matched and is being used.
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:86400
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400.

ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
ISAKMP (0:0): vendor ID is NAT-T RFC 3947
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0):Old State = IKE
R3#_I_MM2  New State = IKE_I_MM2

ISAKMP (0:0): constructing CERT_REQ for issuer cn=R2,ou=CA-OF-THE-WORLD,o=INE,st=NV,c=US
ISAKMP:(0): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_SA_SETUP
ISAKMP:(0):Sending an IKE IPv4 Packet.
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3

ISAKMP (0:0): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_SA_SETUP
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4

ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(1008): processing CERT_REQ payload. message ID = 0
ISAKMP:(1008): peer wants a CT_X509_SIGNATURE cert
ISAKMP:(1008): peer wants cert issued by cn=R2,ou=CA-OF-THE-WORLD,o=INE,st=NV,c=US
 Choosing trustpoint R2 as issuer
ISAKMP:(1008): processing vendor id payload
ISAKMP:(1008): vendor ID is Unity
ISAKMP:(1008): pr
R3#ocessing vendor id payload
ISAKMP:(1008): vendor ID is DPD
ISAKMP:(1008): processing vendor id payload
ISAKMP:(1008): speaking to another IOS box!
ISAKMP:received payload type 20
ISAKMP:received payload type 20
ISAKMP:(1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1008):Old State = IKE_I_MM4  New State = IKE_I_MM4

ISAKMP:(1008):Send initial contact
ISAKMP:(1008):SA is doing RSA signature authentication using id type ID_IPV4_ADDR
ISAKMP (0:1008): ID payload
 next-payload : 6
 type         : 1
 address      : 23.0.0.3
 protocol     : 17
 port         : 500
 length       : 12
ISAKMP:(1008):Total payload length: 12
ISAKMP (0:1008): constructing CERT payload for serialNumber=XXXXXXXXXXX+ipaddress=23.0.0.3+hostname=R3.ine.com,cn=R3,ou=ccie,o=ine,st=NV,c=US
ISAKMP:(1008): using the R2 trustpoint's keypair to sign
ISAKMP:(1008): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
ISAKMP:(1008):Sending an IKE IPv4 Packet.
ISAKMP:(
R3#1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1008):Old State = IKE_I_MM4  New State = IKE_I_MM5

ISAKMP (0:1008): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP:(1008): processing ID payload. message ID = 0
ISAKMP (0:1008): ID payload
 next-payload : 6
 type         : 1
 address      : 10.0.0.1
 protocol     : 17
 port         : 500
 length       : 12
ISAKMP:(0):: peer matches *none* of the profiles
ISAKMP:(1008): processing CERT payload. message ID = 0
ISAKMP:(1008): processing a CT_X509_SIGNATURE cert
ISAKMP:(1008): peer's pubkey isn't cached
%PKI-3-CERTIFICATE_INVALID_UNAUTHORIZED: Certificate chain validation has failed. Unauthorized
%CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 10.0.0.1 is bad: certificate invalid
ISAKMP:(1008):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(1008):Old State = IKE_I_MM5  New State = IKE_I_MM6

%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main mode failed with peer a
R3#t 10.0.0.1
ISAKMP:(1008): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
ISAKMP:(1008):Sending an IKE IPv4 Packet.
ISAKMP:(1008):peer does not do paranoid keepalives.

ISAKMP:(1008):deleting SA reason "Phase1 SA policy proposal not accepted" state (I) MM_KEY_EXCH (peer 10.0.0.1)
ISAKMP (0:1008): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP:(1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1008):Old State = IKE_I_MM6  New State = IKE_I_MM6

ISAKMP:(1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR
ISAKMP:(1008):Old State = IKE_I_MM6  New State = IKE_I_MM5

ISAKMP:(1008):deleting SA reason "Phase1 SA policy proposal not accepted" state (I) MM_KEY_EXCH (peer 10.0.0.1)
ISAKMP: Unlocking peer struct 0x66031B38 for isadb_mark_sa_deleted(), count 0
ISAKMP: Deleting peer node by peer_reap for 10.0.0.1: 66031B38
ISAKMP:(1008):deleting node -1424120631 error FALSE reason "IKE deleted"
ISAKMP:(1008):Input
R3# = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
ISAKMP:(1008):Old State = IKE_I_MM5  New State = IKE_DEST_SA

IPSEC(key_engine): got a queue event with 1 KMI message(s)
ISAKMP (0:1008): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_NO_STATE
R3#un all
All possible debugging has been turned off
R3#

This is another important technique to put in our ever expanding tool belt.   On an upcoming post, we will take a closer look at the  ID type, including:

ID type ID_KEY_ID
ID type ID_IPV4_ADDR
ID type ID_FQDN
ID type ID_USER_FQDN

Best wishes in your studies,

Keith

I just returned from an awesome Security bootcamp in Raleigh, and am looking forward to more there in the future. Core knowledge is still alive and well in the Security LAB exam, as well as troubleshooting, which is integrated as part of the configuration section.

Often times, what seem like complex network troubleshooting scenarios are caused by overlooking simple fundamental components of the technology. Join me on Tuesday, June 8th as we discuss developing the Tier 1 knowledge that you need to know for the CCIE Security LAB, as well as strategy that may be used to continually build your base of knowledge as you prepare for your CCIE certification.

This v-Seminar is open to the public, and will be held online at

To sign up for v-Seminars, click here, and select the link for Free v-Seminars.

To join the meeting listed above, click here now.

See you soon!

Keith

Summer is here and it’s time to get certified!  Join us during the Summer of Success by attending one of our bootcamps and save up-to $1000.  Get $500 off any one week on-site bootcamp or $1000 off any two week on-site bootcamp when you purchase during this limited offer.  This special promotion applies to CCIE Routing & Switching, CCIE Voice, CCIE Service Provider or CCIE Security.

To take advantage of this special promotion, use discount code 1WEEKBOOTCAMP or 2WEEKBOOTCAMP when you check out at http://www.ine.com.

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.

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

It isn’t my fault, they configured it that way before I got here! That was the entry level technician’s story Monday morning, and he was sticking to it. 

Here is the rest of the story.   Over the weekend, some testing had been done regarding a proposed BGP configuration.   The objective was simple, R1 and R3 needed to ping each others loobacks at 1.1.1.1 and 3.3.3.3 respectively, with those 2 networks, being carried by BGP.  R2 is performing NAT.    The topology diagram looks like this:

The ping between loopbacks didn’t work, but R1 and R3 had these console messages:

R1#
%TCP-6-BADAUTH: No MD5 digest from 10.0.0.3(179) to 10.0.0.1(28556) (RST)
R1#
%TCP-6-BADAUTH: No MD5 digest from 10.0.0.3(179) to 10.0.0.1(28556) (RST)
R1#

R3#
%TCP-6-BADAUTH: No MD5 digest from 23.0.0.1(179) to 23.0.0.3(59922) (RST)
R3#
%TCP-6-BADAUTH: No MD5 digest from 23.0.0.1(179) to 23.0.0.3(59922) (RST)
R3#

The senior engineer looked at the configurations for R1, R2 and R3 and found 5 specific items, each of which was independently causing a failure.

Here is the challenge:  Can you find 1 or more of them?

Let us know what your troubleshooting skills can find, and post your comments here on the blog.

Here are the configurations for the 3 routers:

R1#show run
version 12.4
hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
router ospf 1
 network 10.0.0.0 0.0.0.255 area 0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.0.0.3 remote-as 3
 neighbor 10.0.0.3 password cisco
 no auto-summary
!
end
R1#

R2#show run
version 12.4
hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
interface FastEthernet0/1
 ip address 23.0.0.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 10.0.0.2 0.0.0.0 area 0
 network 23.0.0.2 0.0.0.0 area 0
!
ip nat inside source static 10.0.0.1 23.0.0.1
ip nat outside source static 23.0.0.3 10.0.0.3
!
end

R3#show run
version 12.4
hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/1
 ip address 23.0.0.3 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 23.0.0.0 0.0.0.255 area 0
!
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 network 3.3.3.3 mask 255.255.255.255
 neighbor 23.0.0.1 remote-as 1
 neighbor 23.0.0.1 password cisco123
 no auto-summary
!
end
R3#

Let us know what you find!

Best wishes,

Keith

UPDATE:   ANSWERS

Your contributions and input is great.  You ROCK!

I have summarized the 5 specific errors/issues with the configuration, and here they are:

• R2: NAT isn’t fully baked. Can fix with  “ip nat outside source static 23.0.0.3 10.0.0.3 add-route” (or we could manually add the route as well).
• R1 & R3: The BGP passwords don’t match, but it doesn’t matter. BGP authentication doesn’t work between NAT’d BGP neighbors, so it would have to be removed.
• R1 & R3: Incorrect network statements for loopback addresses on both BGP routers (incorrect mask)
• R1 & R3: Ebgp-multihop statements are needed on both neighbors (not directly connected EBGP)
• R2: R2 doesn’t know how to reach 1.1.1.1 or 3.3.3.3 (non-BGP routing issue)

Again, thanks for the time and effort invested in this solution, and in learning in general.   I appreciate you!

Best wishes,

Keith

As you know, purchasers of the new INE 5-day QoS bootcamp receive the class in four different modalities. There is the interactive self-paced version, the live class, the recorded live class, and an audio bootcamp.

If you would like to check out a sample lesson of the audio bootcamp, tune into W-INE Internet radio, or visit the course’s Samples page. The lesson is also going to appear on our iTunes podcast channel by Saturday, May 22, 2010. Just search the iTunes store for INE.

Enjoy, and I look forward to “seeing you” in class soon.