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:
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:
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
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!
Keith
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.
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
May 17
The two engineers, as they grabbed a quick lunch, looked over the following diagram.
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:
With encryption, it would look like this:
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
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. Keith Barker, CCIE#6783 (R&S, SC), will be teaching the CCIE Routing & Switching Advanced Technologies Class and Marvin Greenlee, CCIE#12237 (R&S, SC, SP), will be teaching the CCIE Security Advanced Technologies Class.
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.
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.
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
Mar 22
One of our students asked me for a concise example of SNMPv3. James, here you go! This blog has examples and explanations of the features used in SNMPv3.
Older versions of SNMP didn’t provide all the features of SNMPv3. V3 supports a User-based Security Model (USM) for authentication, and a View-based Access Control Model (VACM) to control what that user account may access. Of course the user accounts don’t represent end users, they are just the configuration elements we configure on the SNMP devices, primarily for creating the connection to or from the SNMP device.
With version 3 we may use the following methods:
- noAuthNoPriv: requires username, but no MD5 validation of that user, and no encryption
- authNoPriv: requires username, provides MD5 validation, but no encryption
- authPriv: You guessed it. Requires username, uses MD5 validation, and encrypts too.
Let’s configure the router to support a SNMPv3 manager who will be communicating with it. First, we assign an engineID. This is optional, as the router would have automatically assigned one, but helpful due to the fact that we may need to configure the engineID on the remote manager and by hard coding it on the router we will know what the value is beforehand. (Note: the 00 in food, are Zero Zero, as the engineID is in hexadecimal. )
R1(config)#snmp-server engineID local badf00dbabe
Next we can define a view that specifies what may be managed (VACM, see above). In this example, the two views refer to mib-2 and Cisco object IDs respectively.
R1(config)#snmp-server view MYVIEW mib-2 included R1(config)#snmp-server view MYVIEWRW cisco included
So far, these views are not worth much, as they are just sitting in the config, and not being called on. We can verify the views exist, and also see the other default views present on the router.
R1#show snmp view *ilmi system - included permanent active *ilmi atmForumUni - included permanent active MYVIEW mib-2 - included nonvolatile active MYVIEWRW cisco - included nonvolatile active v1default iso - included permanent active v1default internet.6.3.15 - excluded permanent active v1default internet.6.3.16 - excluded permanent active v1default internet.6.3.18 - excluded permanent active v1default ciscoMgmt.394 - excluded permanent active v1default ciscoMgmt.395 - excluded permanent active v1default ciscoMgmt.399 - excluded permanent active v1default ciscoMgmt.400 - excluded permanent active
Let’s set up some groups and users, so that a remote SNMP manager may get information from this router and/or configure via SNMP. We have options. If we want to allow the manager station to request data, but not require a MD5 hash validation of the user, nor require encryption for the SNMP traffic, we could create a group that doesn’t require MD5 authentication nor encryption. The group and user that we might put in this group may look like this:
R1(config)#snmp-server group groupone v3 noauth read MYVIEW R1(config)#snmp-server user keith groupone v3 Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait...
Note, this would not be much better than SNMPv1, with simple plain text passwords. To verify the group and user, we can use a few simple show commands.
R1#show snmp group groupname: ILMI security model:v1 readview : *ilmi writeview: *ilmi notifyview: row status: active groupname: ILMI security model:v2c readview : *ilmi writeview: *ilmi notifyview: row status: active groupname: groupone security model:v3 noauth readview : MYVIEW writeview: notifyview: row status: active R1#show snmp user User name: keith Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: None Privacy Protocol: None Group-name: groupone
Next, we create another group, still with NO authentication or encryption, but we will add the ability to write via SNMP based on the view named MYVIEWRW.
R1(config)#snmp-server group grouptwo v3 noauth read MYVIEW write MYVIEWRW R1(config)#snmp-server user anthony grouptwo v3
Notice, the show group and user commands include both users and groups. Grouptwo has a writeview specified, just as we configured it.
R1#show snmp group <snip> groupname: groupone security model:v3 noauth readview : MYVIEW writeview: notifyview: row status: active groupname: grouptwo security model:v3 noauth readview : MYVIEW writeview: MYVIEWRW notifyview: row status: active R1#show snmp user <snip> User name: anthony Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: None Privacy Protocol: None Group-name: grouptwo
Now, lets add some MD5 authentication . No encryption yet, but we are making progress over groupone and grouptwo.
R1(config)#snmp-server group groupthree v3 auth read MYVIEW R1(config)#snmp-server user marvin groupthree v3 auth md5 marvin-passwd
Notice in the show command, that the new group includes “auth”. We are beginning to use the features that makes SNMPv3 desireable.
R1#show snmp group groupname: groupone security model:v3 noauth readview : MYVIEW writeview: notifyview: row status: active groupname: grouptwo security model:v3 noauth readview : MYVIEW writeview: MYVIEWRW notifyview: row status: active groupname: groupthree security model:v3 auth readview : MYVIEW writeview: notifyview: row status: active R1#show snmp user <snip> User name: marvin Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: MD5 Privacy Protocol: None Group-name: groupthree R1#
Now, we will add a group and user, that leverages the authentication and encryption.
R1(config)#snmp-server group groupfour v3 priv read MYVIEW R1(config)#snmp-server user scott groupfour v3 auth md5 scott-passwd priv des crypt-key R1#show snmp group groupname: groupfour security model:v3 priv readview : MYVIEW writeview: notifyview: row status: active R1#show snmp user User name: scott Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: MD5 Privacy Protocol: DES Group-name: groupfour R1#
Our final group and user will use authentication and encryption, along with the ability to write to the SNMP device based on the view MYVIEWRW. This is the most secure of all the examples shown here.
R1(config)#snmp-server group groupfive v3 priv read MYVIEW write MYVIEWRW R1(config)#snmp-server user petr groupfive v3 auth md5 peter-passwd priv 3des crypt-key R1#show snmp group <snip> groupname: groupfive security model:v3 priv readview : MYVIEW writeview: MYVIEWRW notifyview: row status: active R1#show snmp user User name: petr Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: MD5 Privacy Protocol: 3DES Group-name: groupfive R1#
SNMPv3 has the ability to communicate via TRAPs and INFORMs. A TRAP is an SNMP message sent from one application to another, probably the manager station. Unfortunately, TRAPs are not acknowledged so the router doesn’t know if the remote device received it. SNMPv2 and v3 may use an INFORM, which is nothing more than an acknowledged TRAP.
To set up traps and informs, we can use the syntax below. Note that the traps are being sent using an account that doesn’t use MD5 authentication, or encryption, based on the user account configured to send it. The inform destination is using an account that uses authentication, but not encryption. A better use would be to include authentication and encryption, using an account that is assigned to groupfive. The SNMP manager would need to be properly configured with the correct user account information to receive these traps and inform PDUs. The parameters at the end of the command indicate what will trigger the traps/informs.
R1(config)#snmp-server host 10.0.0.100 version 3 noauth keith snmp ipsla hsrp cpu R1(config)#snmp-server host 10.0.0.100 informs version 3 auth marvin cpu syslog
Note: Any names used in the demonstration are purely intentional. Thanks to some of my fellow CCIE comrades, namely Anthony, Marvin, Scott and Petr.
Thanks again James for your request, and best wishes to all in your studies.
Keith
Mar 21
Bob took a moment to reflect back, and realize how far he had come over that past several months. He smiled to himself as he remembered how much he has learned about the technologies of DMVPN, the ASA Firewall and IPSec, including GET VPN.
He had also improved his skills in MPLS, Multi-Protocol BGP, IOS IPS, EEM, and many other areas by using the sweet blog articles at INE. (Shameless Plug ).
One Monday morning, as he was feeling refreshed from a rare weekend of no support calls, he was met by one of his co-workers with a technical riddle. Bob thought about it, googled it and then attempted to lab up a few solutions, all without success.
Your mission, should you choose to accept it, is to assist Bob by identifying the possible solution(s) to use IKE PHASE 1 in the desired way. Here is the topology, followed by the IPSec IKE Phase 1 riddle.
Here is the riddle. Can you solve it for IKE Phase 1?
R1 and R2 will protect IP traffic between 4.0.0.0/24 and 6.0.0.0/24 using EasyVPN with R1 as the server, and use Digital Certificates for the authentication of IKE Phase 1. R1 and R2 will also protect traffic between 5.0.0.0/24 and 7.0.0.0/24 but use an IKE Phase 1 authentication of Pre-Shared of "cisco" associated with the protection of this traffic. R3 may be used in any capacity for this task, including CA server, time server, etc.
Any and all ideas and observations are welcome, and you don’t need to provide a full working configuration to voice your opinion. So let’s have it, can this even be done?
From of all the ideas you offer as replies to this post, I am going to put all the names in a virtual hat, and draw a single winner for 50 rack tokens to our preferred rack vendor, Graded Labs. If you like, I can do a future blog with the detailed solutions, along with the name of the winner from the drawing.
Best wishes, and good luck!
Keith
Mar 14
Learn the trick to ARP inspection on the ASA Firewall in transparent mode.
