Aug
25

The first portion of INE's new CCIE Security Advanced Technologies Class for the 3.0 blueprint is now available in both streaming and download formats.  Subscribers to the All Access Pass already have access to this new course, and can upgrade to the download version for $159.  Non-subscribers can purchase the standalone download for $299, or subscribe to the AAP for just $159 per month.  Customers who have access to previous versions of the CCIE Security ATC will get access to the new streaming version at no extra charge.

The current release of the class contains the first 18 hours of videos.  New videos will be posted incrementally over the next few weeks, to bring the final runtime somewhere between 40 and 60 hours.  Specifically the following topics are covered in this first portion of the release:

  • Introduction 0h 37m
  • CCIE Security Preparation Resources 0h 50m
  • ASA Overview 0h 37m
  • Basic ASA Initialization 1h 02m
  • ASA Routing 0h 37m
  • ASA Reliable Static Routing
  • ASA Access Control Lists (ACLs) 0h 41m
  • ASA Modular Policy Framework (MPF) Overview 0h 53m
  • ASA Modular Policy Framework (MPF) Configuration 0h 51m
  • ASA Advanced TCP Inspection with MPF 0h 40m
  • ASA Advanced Application Inspection with MPF 0h 36m
  • ASA Quality of Service (QoS) 0h 30m
  • ASA Network Address Translation (NAT) Part 1 0h 50m
  • ASA Network Address Translation (NAT) Part 2 0h 30m
  • ASA Transparent Firewall Overview 0h 25m
  • ASA Transparent Firewall Configuration 0h 43m
  • ASA ARP Inspection with Transparent Firewall 0h 21m
  • ASA Multiple Context Mode Overview 0h 42m
  • ASA Multiple Context Mode Configuration 0h 59m
  • ASA Redundant Interfaces 0h 22m
  • ASA Failover Overview 0h 19m
  • ASA Active/Standby Failover Routed Firewall Configuration 0h 29m
  • ASA Active/Standby Failover Transparent Firewall Configuration 0h 17m
  • ASA Active/Active Failover Routed Firewall Configuration
  • ASA Multiple Context Transparent Firewall Configuration 0h 29m
  • ASA Active/Active Failover Transparent Firewall Configuration 0h 29m
  • IOS Access Control Lists (ACLs) 0h 23m
  • IOS Time Based ACLs 0h 13m
  • IOS Lock & Key Security with Dynamic ACLs 0h 24m
  • IOS Reflexive ACLs 0h 44m
  • IOS TCP Intercept and Content Based Access Control (CBAC) 0h 39m
Jan
24

Today's challenge is drawn from the exciting area of CCNA Security. Enjoy. As always, you can find the answer in the comments area a day or two after the date of this post.

IINS-1: The CIA Triad seeks to define the three primary purposes for network security. These are to secure an organization's data confidentiality, integrity, and availability. Define integrity as it is used in the CIA Triad. For bonus credit, provide the term texts often attribute the A for in CIA as opposed to Availability.

Answer: ______________________________________________________________________________

Bonus: _______________________

Dec
01

Catalyst switch port security is so often recommended. This is because of a couple of important points:

  • There are many attacks that are simple to carry out at Layer 2
  • There tends to be a gross lack of security at Layer 2
  • Port Security can guard against so many different types of attacks such as MAC flooding, MAC spoofing, and rouge DHCP and APs, just to name a few

I find when it comes to port security, however, many students cannot seem to remember two main points:

  1. What in the world is Sticky Learning and how does it work?
  2. What is the difference between the different violation modes and how can I remember them?

Sticky Learning

Sticky learning is a convenient way to set static MAC address mappings for MAC addresses that you allow on your network. What you do is confirm that the correct devices are connected. You then turn on sticky learning and the port security feature itself, for example:

switchport port-security maximum 2
switchport port-security mac-address sticky
switchport port-security

Now what happens is the 2 MAC addresses for the two devices you trust (perhaps an IP Phone and a PC) are dynamically learned by the switch. The switch now automatically writes static port security entries in the running configuration for those two devices. All you have to do is save the running configuration, and poof, you are now configured with the powerful static MAC port security feature.

Please note that it is easy to forget to actually turn on port security after setting the parameters. This is what the third line is doing in the configuration above. Always use your show port-security commands to confirm you remembered this important step of the process!

Violation Modes

The violation modes are Shutdown, Protect, and Restrict. Shutdown is the default and the most severe. If there is a violation, the port is error-disabled and notifications are sent (SNMP traps can be used and violation counters are incremented, etc.). With Restrict mode, the bad MAC cannot communicate on the port, but the port does not error-disable. There are notifications sent. With the Protect mode, the bad MAC cannot communicate and there is no eror-disabling, but the problem is, there are no notfications sent. Cisco does not recommend this mode as a result.

How can you remember these easily? Just think of the alphabet. P the R then S gives you the levels of severity. :-)

Where do you find these features documented should you still forget?

Cisco.com - Support - Configure - Products - Switches - LAN Switches - Access - 3560 Series - Configuration Guides - Software Configuration Guides - Latest Release - Configuring Port-Based Traffic Control

Oct
16

In this series of blog posts, we will examine WLAN security mechanisms in an even greater detail than in our popular 5-Day CCNA Wireless course. We will begin with one that is now considered legacy due to major weaknesses that were quickly discovered in its implementation.

We Don't Need No Stinken' Wires!

This security mechanism receives the least coverage in the CCNA Wireless materials and exam, because, as we stated, it is indeed considered legacy. The official title for this technology is Preshared Key Authentication with Wired Equivalent Privacy. This name tells us a lot. We are not really truly authenticating someone using this approach, we are just ensuring that they possess a piece of information, the preshared key (password). Notice the Wired Equivalent Privacy portion of the name tells us that the creators of the technology were really trying to sell it to WLAN designers and implementers!

The WEP process consists of a series of steps as follows:

  1. The wireless client sends an authentication request.
  2. The Access Point (AP) sends an authentication response containing clear-text (uh-oh!) challenge text.
  3. The client takes the challenge text received and encrypts it using a static WEP key.
  4. The client sends the encrypted authentication packet to the AP.
  5. The AP encrypts the challenge text using its own static WEP key and compares the result to the authentication packet sent by the client. If the results match, the AP begins the association process for the wireless client.

The big issue with WEP is the fact that it is very susceptible to a Man in the Middle attack. The attacker captures the clear-text challenge and then the authentication packet reply. The attacker then reverses the RC4 encryption in order to derive the static WEP key. Yikes!

As you might guess, the designers attempted to strengthen WEP using the approach of key lengths. The native Windows client supported a 104-bit key as opposed to the initial 40-bit key. The fundamental weaknesses in the WEP process still remained however.

We hope you are excited to learn more about the next generations WLAN security mechanisms that resulted...

Jun
21

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.

Jun
15

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:

3 routers in a row-NO-user

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.

<strong>R3:</strong>
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.

Jun
06

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

U.S.A. - Pacific) Tuesday, June 8, 2010 at 11:00:00 AM UTC-7 hours PDT
UTC Tuesday, June 8, 2010 at 18:00:00

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!

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#

Apr
05

We are excited to announce that for the first time INE is traveling to Nigeria! In partnership with New Horizons, INE will be offering two classes in Lagos, Nigeria. We will be offering both our CCIE Routing & Switching Advanced Technologies Class and our CCIE Security Advanced Technologies Class. These classes will be held in New Horizons Training centers.

Both classes will be held from May 3-7, 2010. Both classes will be tentatively held May 24 - 28, 2010.

For additional information on classes held in Nigeria:

Email:

Class/Sales Information

Mr. Oluwaseyi Ojo

oluwaseyi@newhorizonsnigeria.com

Class/Information Hotlines:

Seyi: 234-7030160944 or Edward: 234-8073809974

New Horizons Nigeria General:

234-1-7901013 or 234-1-8976386

INE is looking forward to providing training in a new location! For more information on the Advanced Technologies Class please visit our website.

Routing & Switching Advanced Technologies Class

Security Advanced Technologies Class

Subscribe to INE Blog Updates

New Blog Posts!