You know how it is? You are typing so fast making changes in you cisco gear you not always pay attention to which mode you are in? Doing config-command in exec-level, exec-commands in config-level and adding “do” in front just to make them pass? Wanna know if that happens to fast and you are in the wrong place doing the wrong time?

Below I am in system context of a multi context ASA firewall. My intention is to do something with a context. I go into config mode and then into the context definition of the context I wanna change. What if I get interrupted or whatever and enter the “conf t”-command in the context configuration mode?


act# sh mode
Security context mode: multiple
act#
act# conf t
act(config)# context LEFT
act(config-ctx)# conf t
INFO: Converting t to disk0:/t
.
WARNING: Could not fetch the URL disk0:/t
INFO: Creating context with default config
INFO: Admin context will take some time to come up .... please wait.
act(config-ctx)#


Congrats! Your firewall is gone!

I did not pass the test today.

I just left Brussels after my first take on the CCIE Security lab. So, what happened? I Showed up early, 7:40. The test was about to start 8.15 and I waited in the reception with the other candidates untill we were escorted to the lab room. The proctor was We had a lunch break that I can barely remember anything from and all of a sudden it was 5pm and time to leave.

I made a list of tasks and marked each item as it was configured. My sum total was 78p. (100 is max, 80 is passing score). I am not 100% sure that all checked tasks was correct so I expect a somewhat lower score. Score report will probably be available later tonight.

The first hour I did all preparations. Diagram, task list, lab reading and all that. After 1:30 I had the basic l2-l3 setup with ASAs and IPS. I got kinda stuck at the same point as so many times before: understanding the topology, get a feeling about what part of the network should work like what and where the boundaries are. Which addresses should be hidden and which should be universal routable. Doing a few mistakes with that costed me at least an hour to troubleshoot and fix what I killed by mistake.

The self confidence was way low when it was time for lunch. After having something to eat (a hamburger, but I honestly don’t remember what else was on that plate!) I decided to do some cherry-picking. Selecting and gaining the easies points in the work book always do miracles to your mind! I summarized the task list and found that I had cleared about 70p!

The last hour or 2 I just tried my best to get as many of the remaining points as possible.

When I left I had the following list of uncleared tasks:

* 2 individual tasks within the same technology. I definitely know what to study for the next attempt! I tried them both bud left them unfinished after I spent way too much time on them. These could have pushed me over the line!

* one task worth 5 (or so) points. I left it untouched because I realized how much work it would have taken. If I had more Time at the end I’d probably fixed it.

* one 3p task that I immediately saw that I had no idea how to solve. I could have done this as well if I had more time.

Conclusion: I wasn’t prepared enough. I need to speed up my workflow even more and focus on configuring a few specific technologies over and over with different tweaks.

Oh. And the OEQ;s. My worst nightmare came thru: I got 2 hard questions. Now when I think about them I am quite sure that I nailed them. But they are EVIL!

I am SO focused on getting this done. I can hardly get on the plane back to Sweden, I just wanna have one more attempt on it right now!

Out of those other candidates I met today there was none that was confident with their result. At least 3 blew it for sure. One candidate lost ALL configs when doing a reload the last 30 minutes.

While of course feeling a bit sad and worthless today I keep telling myself that there would probably be noone except for me at my company that would pass this test.

I keep repeating Markos words: there are no failures when it comes to the CCIE lab exam. There are only “pass” and “no pass”.

Wait and see, I’ll be back!

The entrance of the Cisco Campus in Brussels

An update: The support from OSL is overwhelming. Only an hour after posting a note in the mailing list I´ve plenty of supporting feedbacks from friends all over the world. Thanks guys, you are all the best!

snippets:

I know the feeling Jimmy. All the memories of my failed attempt came back as I read your e-mail.

and:

Jimmy,

Cheers,
TacACK

and:

Jimmy,

cheers,
Piotr

I recently got a question from a collegue regarding address translations in Cisco ASA. He wrote:

Got a question from a customer if you can do the following:

ok. Lets try. I put together a quick lab-setup. A 3-legged ASA with a one-legged router on each firewall-interface:


interface Vlan10
nameif outside
security-level 0
ip address 200.1.1.1 255.255.255.0
!
interface Vlan20
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
!
interface Vlan30
no forward interface Vlan20
nameif dmz
security-level 50
ip address 10.2.2.1 255.255.255.0
!


And the routers.

R1:

interface FastEthernet0
ip address 200.1.1.99 255.255.255.0
duplex auto
speed auto
end


R2:

interface FastEthernet0
ip address 10.1.1.99 255.255.255.0
duplex auto
speed auto
end


and R3:

interface FastEthernet0
ip address 10.2.2.2 255.255.255.0
duplex auto
speed auto
end


Ok. R1 is the outside host on internet. R2 is an inside host on our corporate network. R3 is this magical server on DMZ. In this example it is a high performance telnet server!


line vty 0 4
no login


First, make sure that this is reachable from internet. We do a static and allow the traffic on outside acl:


static (dmz,outside) 200.1.1.2 10.2.2.2 netmask 255.255.255.255
access-list OUTSIDE extended permit tcp any host 200.1.1.2 eq telnet


Verification. Telnet from R1 to public IP:

R1#telnet 200.1.1.2
Trying 200.1.1.2 ... Open
R3>


Great. Now we want to reach the DMZ server from inside. Since this is higher security level to lower and we dont have any acl on inside we dont have to care about open the traffic. But we want to use an OUTSIDE address as destination ip to reach a DMZ host. Lets try a static:


FW(config)# static (dmz,inside) 200.1.1.2 10.2.2.2


The command above seems weird, right? I agree. Someday when I have a lot of time I will explain the theory but for now, just trust me!

Verification:

R2#telnet 200.1.1.2
Trying 200.1.1.2 ... Open
R3>


Next step is to hide the source address of that telnet client on inside. Right now it is using its own source ip:

R3>en
Password:
R3#
R3#sh users
Line User Host(s) Idle Location
0 con 0 idle 00:08:09
* 6 vty 0 idle 00:00:00 10.1.1.99

R3#


So, how do we accomplish that? The easiest way is to use a policy nat-statement. We create an access-list which defines which traffic to translate. We then create a nat-statement with a nat-id of your choice and call the access-list. Finaly we define which global ip to use. (outside. Remember dmz is outside relative to inside since dmz has lower security-level)

access-list Inside2DMZ extended permit tcp 10.1.1.0 255.255.255.0 host 200.1.1.2 eq telnet
nat (inside) 1 access-list Inside2DMZ
global (dmz) 1 200.1.1.10


Verification:

R2#telnet 200.1.1.2
Trying 200.1.1.2 ... Open

R3>

Voila! So, the client is on a private ip network 10.1.1.0 and establish a connection to what he think is on outside, because it is an public/outside ip. The traffic passes the magic ASA and the server on DMZ believes that the client is on internet since it has a public/outside source ip.

Mission accomplished.

Hi

I haven´t been very active on my blog lately. Guess why? This Lab preparation is killing me…

But today I dived into Yusufs Practice Lab 1 and I did a few notes. Please comment.

/Jimmy

First of all. If you use proctorlabs gear to do Yusuf Labs you see that the naming of the device doesnt match. Here is the correct matching:
ProctorLabs Cat 3 – Yusuf Sw1
ProctorLabs Cat 2 – Yusuf Sw2
ProctorLabs R7 = Yusuf R1
ProctorLabs R8 = Yusuf R2
ProctorLabs R9 = Yusuf R3
ProctorLabs R4 = Yusuf R4
ProctorLabs R6 = Yusuf R5
ProctorLabs R5 = Yusuf R6

Also note that the interface names doesnt always match!

Q2.1 – configure NAT on ASA:s. Do not enable NAT Control. Configure static identity nat on context abc1 for web server.

Why configure identity nat? There is no NAT configured on the device, whats the purpose of adding a “static (i,o) 10.7.7.7 10.7.7.7.7″ statement? It works both with and without it.

Q2.1 – “Configure static NAT on ASA2 such that Sw2 can reach dest R6 Lo0 interface using local address 192.168.10.6″

this is an ugly one! I did source translation (Telnet from Sw2:s real address TO 192.168.10.6) but I was supposed to do destination translation (telnet FROM Sw2:s natted source address 192.168.10.6). It´s SO easy to misinterprete the questions!

Q3.2 – “Configure IPSEC on ASA2 and R5. Configure high-availability IPsec peering in such wah tyat it should continue to work if euther WAN link on R5 goes down. You are not allowed to configure multiple crypto maps of mutiple peer statements. Only one crypto map with one peer statement is allowed on bith sides”.
In my opinion “high availability IPsec” is plain IPsec on router spiced up with HSRP redundancy and RRI. But here is no HSRP involved since the the requirement is to esablish ipsec between one ASA and one router.

My solution to this was to create a new loopback on R5, route the remote network (Sw2 lo0) to that loopback and apply the crypto map on this loopback. I guess the drawback with this is routing ALL traffic destined for Sw2 Lo0 to the loopback interface, not only traffic hitting the crypto map (sourced R5 lo0). I doubt that my solution would get any points on the real lab… But either way have the desired results, imho.

Q4.2 – “configure NTP on IPS Sensor”

I was unable to configure NTP. Got the same error message both in IDM and CLI:
“Error: Authenticaion failed – invalid NTP key value or ID”

This happened in CLI:


IPS(config)# service host
IPS(config-hos)# ntp-option enabled
IPS(config-hos-ena)# ntp-keys 1 md5-key cisco
IPS(config-hos-ena)# ntp-servers 10.1.1.1 key-id 1
IPS(config-hos-ena)# exit
IPS(config-hos)# exit
Apply Changes?[yes]: yes
Error: Authentication failed - invalid NTP key value or ID


There is obviously communications because these ntp debugs shows up on the NTP server R1:


R1#
Jun 27 12:54:52.811: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.811: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.811: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.811: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.811: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.811: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.815: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.815: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.815: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.819: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.819: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.819: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.819: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.819: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.919: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.919: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.919: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.923: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.923: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.923: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.927: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.927: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).


Q5.1 Typo. “Configure AAA auth on Sw1″ and “Add Sw2 ip address 192.168.8.11″. It should be Sw1 everywhere in this task.

Q5.2 CLI views assigned from ACS.
It feels abit weird that there is no pound-sign in the prompt when getting into a custom view:


R6#telnet 192.168.4.11
Trying 192.168.4.11 ... Open

R2>sh pars view
Current view is 'netop'
R2>configure
Configuring from terminal, memory, or network [terminal]? t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)>


Q5.3 Configure Sw2 Fa0/7 for 802.1x
Really? I was expecting the port to configure to be unused/down. Sw2 Fa0/7 is the trunk to R1. Enabling port-control here would kill alotá traffic in my network, right?

Q6.0 configure CoPP on R2 allowing ping source from RFC1918-addresses only.
I created an acl, class-map and policy-map but I applied on “control-plane host” instead of “control-plane”. For verification Yusuf runs “show policy-map control-plane” which in my solution would give an empty output. But is there any difference in my solution and Yusufs? We are talking about icmp pings TO the router, why not apply int to the CoP host?

Q7.1 Web server protection.
The task was to limit the number of incoming embryonics to an internal web server, on ASA. Of course with limitations on how to ackomplish it. I missed the “Do not use ACL” which made me fail. Yusufs solution was to do “match port” in the class-map but instead I matched an access-group. To my defense I must say that “match port” would put the same limits on ALL incoming tpc/80-traffic not only the one destined for our web server.

Comparizon between 3 different ways to configure EzVPN on IOS.

Example 1: EzVPN-server vanilla-style


aaa new-model
!
!
aaa authentication login default none
aaa authentication login AAA-AUTHEN local
aaa authorization network default none
aaa authorization network AAA-AUTHOR local
!
!
username cisco password 0 cisco
!
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp client configuration group MYGROUP
key cisco
dns 8.8.8.8
pool LOCALPOOL
acl SPLITTUNNEL
save-password
!
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
!
crypto dynamic-map DYNMAP 10
set transform-set TSET
reverse-route
!
!
crypto map CMAP client authentication list AAA-AUTHEN
crypto map CMAP isakmp authorization list AAA-AUTHOR
crypto map CMAP client configuration address respond
crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP
!
interface GigabitEthernet0/1
crypto map CMAP
!
!
ip access-list extended SPLITTUNNEL
permit ip 8.9.5.0 0.0.0.255 any
permit ip 8.9.6.0 0.0.0.255 any
!
!


Example 2: Vanilla-style with ISAKMP profile on top


aaa new-model
!
!
aaa authentication login default none
aaa authentication login AAA-AUTHEN local
aaa authorization network default none
aaa authorization network AAA-AUTHOR local
!
!
crypto keyring EZVPN-KEYRING
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp client configuration group MYGROUP
key cisco
dns 8.8.8.8
pool LOCALPOOL
acl SPLITTUNNEL
save-password
!
crypto isakmp profile ISAKMP-PROFILE
keyring EZVPN-KEYRING
match identity group MYGROUP
client authentication list AAA-AUTHEN
isakmp authorization list AAA-AUTHOR
client configuration address respond
!
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
!
crypto dynamic-map DYNMAP 10
set transform-set TSET
set isakmp-profile ISAKMP-PROFILE
reverse-route
!
!
crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP
!
!
interface GigabitEthernet0/1
crypto map CMAP
!
ip local pool LOCALPOOL 8.9.24.201 8.9.24.254
!
!
!
ip access-list extended SPLITTUNNEL
permit ip 8.9.5.0 0.0.0.255 any
permit ip 8.9.6.0 0.0.0.255 any
!
!


Differences between Example 1 and Example 2:

crypto keyring EZVPN-KEYRING
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
!
crypto isakmp profile ISAKMP-PROFILE
keyring EZVPN-KEYRING
match identity group MYGROUP
client authentication list AAA-AUTHEN
isakmp authorization list AAA-AUTHOR
client configuration address respond
!
crypto dynamic-map DYNMAP 10
set isakmp-profile ISAKMP-PROFILE
!
crypto map CMAP client authentication list AAA-AUTHEN
crypto map CMAP isakmp authorization list AAA-AUTHOR
crypto map CMAP client configuration address respond


Example 3: DVTI

aaa new-model
!
!
aaa authentication login default none
aaa authentication login AAA-AUTHEN local
aaa authorization network default none
aaa authorization network AAA-AUTHOR local
!
!
username cisco password 0 cisco
!
crypto keyring EZVPN-KEYRING
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp client configuration group MYGROUP
key cisco
dns 8.8.8.8
pool LOCALPOOL
acl SPLITTUNNEL
save-password
!
crypto isakmp profile ISAKMP-PROFILE
keyring EZVPN-KEYRING
match identity group MYGROUP
client authentication list AAA-AUTHEN
isakmp authorization list AAA-AUTHOR
client configuration address respond
virtual-template 1
!
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
!
crypto ipsec profile IPSEC-PROFILE
set transform-set TSET
set isakmp-profile ISAKMP-PROFILE
!
interface Virtual-Template1 type tunnel
ip unnumbered GigabitEthernet0/1
tunnel source GigabitEthernet0/1
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC-PROFILE
!
ip local pool LOCALPOOL 8.9.24.201 8.9.24.254
!
!
ip access-list extended SPLITTUNNEL
permit ip 8.9.5.0 0.0.0.255 any
permit ip 8.9.6.0 0.0.0.255 any


Differences between Example 2 and Example 3

crypto isakmp profile ISAKMP-PROFILE
virtual-template 1
!
crypto ipsec profile IPSEC-PROFILE
set transform-set TSET
set isakmp-profile ISAKMP-PROFILE
!
crypto dynamic-map DYNMAP 10
set transform-set TSET
set isakmp-profile ISAKMP-PROFILE
reverse-route
!
!
crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP
!
interface GigabitEthernet0/0
crypto map CMAP
!
interface Virtual-Template1 type tunnel
ip unnumbered GigabitEthernet0/1
tunnel source GigabitEthernet0/1
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC-PROFILE
!

Until now I had my Cisco-devices console connected to a windows-pc. It was easy but not as flexible as I wanted since I had to rdp to it when I wasn´t at home and use a putty to serial port inside that rdp-session.

So I found an old laptop, installed linux on it (actually Backtrack 3) and connected my Usb2Serial-connectors to the USB-port via an USB-hub. They popped up as tty-ports within seconds:


Apr 19 22:21:11 (none) kernel: usb 1-4.1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB0
Apr 19 22:21:11 (none) kernel: usb 1-4.1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB1
Apr 19 22:21:11 (none) kernel: usb 1-4.1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB2
Apr 19 22:21:11 (none) kernel: usb 1-4.1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB3
Apr 19 22:21:11 (none) kernel: usb 1-4.2: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB4
Apr 19 22:21:11 (none) kernel: usb 1-4.2: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB5
Apr 19 22:21:11 (none) kernel: usb 1-4.2: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB6
Apr 19 22:21:11 (none) kernel: usb 1-4.2: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB7
Apr 19 22:21:11 (none) kernel: usb 1-4.3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB8
Apr 19 22:21:11 (none) kernel: usb 1-4.3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB9
Apr 19 22:21:11 (none) kernel: usb 1-4.3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB10
Apr 19 22:21:11 (none) kernel: usb 1-4.3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB11
Apr 19 22:21:11 (none) kernel: usb 1-4.4.3: pl2303 converter now attached to ttyUSB12
Apr 19 22:30:36 (none) kernel: usb 1-4.4.2: pl2303 converter now attached to ttyUSB13


The easiest way (that I´ve found out. I am not a Linux-exert) to connect to the serial-port is by using screen. Like this:


bt ~ # screen /dev/ttyUSB8


I created a few scripts/aliases to simplify this:


bt ~ # ls -l
total 732968
-rwxr-xr-x 1 root root 22 Apr 19 23:08 fw*
-rwxr-xr-x 1 root root 21 Apr 19 23:08 r1*
-rwxr-xr-x 1 root root 21 Apr 19 23:08 r2*
-rwxr-xr-x 1 root root 21 Apr 19 23:08 r3*
-rwxr-xr-x 1 root root 21 Apr 19 23:08 sw*
..
..
..
bt ~ #
bt ~ # cat r1
screen /dev/ttyUSB6
bt ~ #
bt ~ # cat r2
screen /dev/ttyUSB0
bt ~ #
bt ~ # cat r3
screen /dev/ttyUSB9
bt ~ #


After opening ssh-access thru my internet-firewall I can now access my home lab from anywhere by just creating one or multiple ssh-sessions and connect to each serial port by using the aliases. Or even create multiple connection entries in my terminal software and configure each one with a script that executes “r1″ or “r2″ and so on after login.I exit each session with CTRL-A + K.

Cisco recently released a Exam Preparation Checklist which is kinda like a extended blueprint. It´s an extensive and detailed list of topics that you should know before taking the CCIE lab exam.

I made a copy of that Checklist and graded my current knowledge of each topic on a scale from 1 to 5 where 1 is “I´ve no idea what this is” and 5 is “I know it completely!”.

My idea is to do a new grading of my knowledges again every now and then to get a feeling on my progress.

At the bottom I´ve summarized the grades and displays it as a percentage. Simply “how close am I to having a 5 on all tasks?”.

GRE tunnel-interfaces

Tunnel-interfaces are real cool. In later post I will describe how to use them to establish ipsec-tunnel but for now we will just ignore the fact that we doesn´t encrypt the packets.

GRE (Generic Routing Encapsulation) is invented by Cisco. It uses IP protocol 47 and encapsultates the entire packet within a new GRE-header.

Lets setup a GRE-tunnel in our example-topology. A Tunnel-interface is a virtual interface created in the router. It has an IP-address and can be treated just like any physical interface. In normal case a tunnel-interface needs to be configured with a tunnel source (usually a physical interface in the local router) and a tunnel destination (usually the remote IP to which to establish the tunnel). Like this:

Lets do it. First, make sure that we have connectivity with remote peer. Never forget that.


r1#ping 10.10.30.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.30.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
r1#


Now we configure our tunnel-interfaces:


r1(config)#int tu0
r1(config-if)#
*Mar 19 13:31:05.402: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
r1(config-if)#
r1(config-if)#ip address 10.99.99.1 255.255.255.0
r1(config-if)#tunnel source fa0.11
r1(config-if)#tunnel destination 10.10.30.3
*Mar 19 13:32:24.014: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
r1(config-if)#
r1(config-if)#tunnel mode gre ip

r3(config)#int tu0
r3(config-if)#ip address 1
*Mar 19 13:34:54.058: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
r3(config-if)#
r3(config-if)#ip address 10.99.99.3 255.255.255.0
r3(config-if)#tunnel source fa0.30
r3(config-if)#tunnel destination 10.10.11.1
*Mar 19 13:36:00.578: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
r3(config-if)#
r3(config-if)#tunnel mode gre ip
r3(config-if)#


Now we can see that we have our tunnel-interfaces configured and up/up:

r1#sh ip int brie | excl unassigned
Interface IP-Address OK? Method Status Protocol
FastEthernet0.10 10.10.10.2 YES NVRAM up up
FastEthernet0.11 10.10.11.1 YES NVRAM up up
Loopback0 10.1.1.1 YES NVRAM up up
Tunnel0 10.99.99.1 YES manual up up
r1#


Does it work?


r1#ping 10.99.99.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.99.99.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
r1#


Great. Now we have a virtual interface on each router inter-connecting them. Wanna have a look at the transit-traffic? Lets go to the wireshark between the routers:

As you see in the screen-dump above wireshark is smart enough to see that it is icmp-pings in the packets. Have a look at the middle-part of the window and you can see that the original IP-packet is inserted into a GRE-packet which in turn is inserted into a new IP-header. The internal (original) IP-header is destinated to the ip-address we pinged but the outer header is between the GRE tunnel endpoints, the physical interfaces. Remember, in my transit-network I might have routers that has no clue about any 10.99.99-addresses.

But our goal was to make our client 192.168.1.50 behind r1 reach the 10.3.3.3-address behind r3, right? How about routing? First r1.


r1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.10.10.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.2.2.2/32 [170/1285120] via 10.10.10.1, 23:48:00, FastEthernet0.10
C 10.99.99.0/24 is directly connected, Tunnel0
C 10.10.10.0/24 is directly connected, FastEthernet0.10
C 10.10.11.0/24 is directly connected, FastEthernet0.11
C 10.1.1.1/32 is directly connected, Loopback0
S 10.10.30.3/32 [1/0] via 10.10.11.2
D EX 192.168.1.0/24 [170/1285120] via 10.10.10.1, 23:48:00, FastEthernet0.10
D*EX 0.0.0.0/0 [170/1285120] via 10.10.10.1, 23:48:02, FastEthernet0.10
r1#


and r3.


r3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.3.3.3/32 is directly connected, Loopback0
C 10.99.99.0/24 is directly connected, Tunnel0
S 10.10.11.1/32 [1/0] via 10.10.30.1
C 10.10.30.0/24 is directly connected, FastEthernet0.30
r3#


Ooops. r1 doesn´t know of 10.3.3.3 and r3 doesnt know of 192.168.1.50. First we do it the ugly lazy way: add static routes of remote networks. Next-hop should be the remote router tunnel-interface:


r1(config)#ip route 10.3.3.3 255.255.255.255 10.99.99.3
r3(config)#ip route 192.168.1.50 255.255.255.255 10.99.99.1


Now we have a working tunnel. My windows-client 192.168.1.50 can ping 10.3.3.3


^C
C:\Users\Jimmy\Desktop>ping 10.3.3.3

Skickar ping-signal till 10.3.3.3 med 32 byte data:
Svar från 10.3.3.3: byte=32 tid=1ms TTL=254
Svar från 10.3.3.3: byte=32 tid=1ms TTL=254
Svar från 10.3.3.3: byte=32 tid=1ms TTL=254
Svar från 10.3.3.3: byte=32 tid=2ms TTL=254

Ping-statistik för 10.3.3.3:
Paket: Skickade = 4, Mottagna = 4, Förlorade = 0 (0 %),
Ungefärlig överföringstid i millisekunder:
Lägsta = 1 ms, Högsta = 2 ms, Medel = 1 ms

C:\Users\Jimmy\Desktop>


One of the major functions of tunnel-interfaces is that it supports routing protocols. In r1 we already have eigrp running. Lets try to run eigrp thru the tunnel…

First, remove our static routes.


r1(config)#no ip route 10.3.3.3 255.255.255.255 10.99.99.3
r3(config)#no ip route 192.168.1.50 255.255.255.255 10.99.99.1


First, add the tunnel-interface to the eigrp-process of r1:

r1#sh run | sect router
router eigrp 11
network 10.1.1.1 0.0.0.0
network 10.10.10.2 0.0.0.0
no auto-summary
r1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
r1(config)#router eigrp 11
r1(config-router)#network 10.99.99.1 0.0.0.0
r1(config-router)#


In r3 we have no routing protocol running. Time to add that…

r3(config)#router eigrp 11
r3(config-router)#network 10.3.3.3 0.0.0.0
r3(config-router)#network 10.99.99.3 0.0.0.0
*Mar 19 14:06:26.522: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 11: Neighbor 10.99.99.1 (Tunnel0) is up: new adjacency
r3(config-router)#no auto-summary
r3(config-router)#


So, what happened?

r3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.99.99.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D EX 10.2.2.2/32 [170/26885120] via 10.99.99.1, 00:01:08, Tunnel0
C 10.3.3.3/32 is directly connected, Loopback0
C 10.99.99.0/24 is directly connected, Tunnel0
S 10.10.11.1/32 [1/0] via 10.10.30.1
D 10.10.10.0/24 [90/26882560] via 10.99.99.1, 00:01:08, Tunnel0
D 10.1.1.1/32 [90/27008000] via 10.99.99.1, 00:01:08, Tunnel0
C 10.10.30.0/24 is directly connected, FastEthernet0.30
D EX 192.168.1.0/24 [170/26885120] via 10.99.99.1, 00:01:09, Tunnel0
D*EX 0.0.0.0/0 [170/26885120] via 10.99.99.1, 00:01:09, Tunnel0
r3#

Cool. r3 got itself a default-route to the world thru the tunnel.


r1#sh ip route
*Mar 19 14:06:30.122: %SYS-5-CONFIG_I: Configured from console by console
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.10.10.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D EX 10.2.2.2/32 [170/1285120] via 10.10.10.1, 1d00h, FastEthernet0.10
D 10.3.3.3/32 [90/27008000] via 10.99.99.3, 00:02:06, Tunnel0
C 10.99.99.0/24 is directly connected, Tunnel0
C 10.10.10.0/24 is directly connected, FastEthernet0.10
C 10.10.11.0/24 is directly connected, FastEthernet0.11
C 10.1.1.1/32 is directly connected, Loopback0
S 10.10.30.3/32 [1/0] via 10.10.11.2
D EX 192.168.1.0/24 [170/1285120] via 10.10.10.1, 1d00h, FastEthernet0.10
D*EX 0.0.0.0/0 [170/1285120] via 10.10.10.1, 1d00h, FastEthernet0.10
r1#

… and r1 knows how to find 10.3.3.3

As I said before: Voila!

Here are the configs for r1 and r3.

Next session will add encryption to this configuration.

(Topology here)

Ok. So we have established a static VPN-tunnel between two routers. But what if r1 has a dynamic or unknown peer ip? Let´s change the previous configuration to reflect this:

The config on r1 will be the same. The changes will be done on r3. First, remove what we don´t need anymore:


r3(config)#no crypto map CMAP 10
r3(config)#no crypto isakmp key cisco address 10.10.11.1


Next, let´s compensate for that. Since we cannot use a standard crypto map we need to create a dynamic one instead. Into that we ties the proxy-acl (acl_vpn) as well as the transform-set. What´s the difference? Well it doesn´t have any set peer statement…


r3(config)#crypto dynamic-map DYNMAP 10
r3(config-crypto-map)#set transform-set TSET
r3(config-crypto-map)#match address acl_vpn


Also, we must have a pre-shared key. But we don´t know which host ip to tie it to, so it must be a wildcard key.


r3(config)#crypto isakmp key cisco address 0.0.0.0


We still need a crypto map into which we ties the dynmap. Let´s make it with the highest sequence-number available since we might add more tunnels in the future, and this “wildcard”-alike dynmap need to be put as a last resort to not match all other tunnels…


r3(config)#crypto map CMAP 65535 ipsec-isakmp dynamic DYNMAP


One thing left. Remember that reverse-route in the crypto-map of our previous config? Can we put it into the dynmap instead?


r3(config)#crypto dynamic-map DYNMAP 10
r3(config-crypto-map)#reverse-route static
%Static keyword not applicable to dynamic maps, re-enter cmd
r3(config-crypto-map)#


Darn! Then we have to use a static route to point out the direction of the remote network:


r3(config)#ip route 192.168.1.50 255.255.255.255 10.10.30.1


Now the tunnel goes up! But only if we try to initiate it from 192.168.1.50. It cannot be initiated from 10.3.3.3 since r3 doesn´t have a clue how to contact r1. However, as long as the tunnel is up traffic can be generated from both ends.

Here are the relevant parts of configurations:

r1

ip access-list extended acl_vpn
permit ip host 192.168.1.50 host 10.3.3.3
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key cisco address 10.10.30.3
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
!
crypto map CMAP 10 ipsec-isakmp
set peer 10.10.30.3
set transform-set TSET
match address acl_vpn
reverse-route static
!
interface FastEthernet0.11
ip address 10.10.11.1 255.255.255.0
crypto map CMAP


r3

ip access-list extended acl_vpn
permit ip host 10.3.3.3 host 192.168.1.50
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
!
crypto dynamic-map DYNMAP 10
set transform-set TSET
match address acl_vpn
crypto map CMAP 65535 ipsec-isakmp dynamic DYNMAP
!
interface FastEthernet0.30
ip address 10.10.30.3 255.255.255.0
crypto map CMAP


(and the full configs for r1 and r3)

(Topology here)

This is the far most common implementation of IPSEC Lan2Lan (at least in my world). It uses static crypto-maps applied to outbound interface of each router. A proxy-acl defines interresting traffic, authentication is done with a pre-shared key and it uses isakmp main-mode for setting up the tunnel.

Ok. First thing first. Make sure that the peer router is reachable before doing anything else:


r1#ping 10.10.30.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.30.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms


Great. Now for the config. Start with r1. What traffic need to be protected? Create the crypto acl.

ip access-list extended acl_vpn
permit ip host 192.168.1.50 host 10.3.3.3


Next. Create an isakmp policy defining the parameters for phase 1.

crypto isakmp policy 10
encr aes
authentication pre-share
group 5


For phase 1 we also need to set the pre-shared key.

crypto isakmp key cisco address 10.10.30.3


For phase 2 we need to create an ipsec transform-set.

crypto ipsec transform-set TSET esp-aes esp-sha-hmac


Now this needs to be put together in a crypto map.

crypto map CMAP 10 ipsec-isakmp
set peer 10.10.30.3
set transform-set TSET
match address acl_vpn


Last step is to assign this crypto-map to the outside interface.

interface FastEthernet0.11
crypto map CMAP


On the other router the exact thing needs to be defined, except for the crypto access-list that of course must be mirrored because of the reverse point of view. Also the peer ip must be the correct one. Here is the config for r3 with modifications from above highlighted.

ip access-list extended acl_vpn
permit ip host 10.3.3.3 host 192.168.1.50
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key cisco address 10.10.11.1
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
crypto map CMAP 10 ipsec-isakmp
set peer 10.10.11.1
match address acl_vpn
reverse-route static
crypto map CMAP
interface FastEthernet0.30
crypto map CMAP


In this example there is only one thing left to do: make sure that there are routes for the remote-end network. In my daily work I´ve setup lots of tunnels like this. It´s almost always the same: the router (or firewall) is connected to internet on outside with a default-route to the isp. But what if there is no default route? In my XXXXXXXXXXXXXXXXXXXXXXtopology the isn´t. Look:


r1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.3.3.3/32 is directly connected, Loopback0
S 10.10.11.1/32 [1/0] via 10.10.30.1
C 10.10.30.0/24 is directly connected, FastEthernet0.30
r3#


As you can see r1 has no route for 10.3.3.3 but only a default-route pointing in the wrong direction. R3 has no default-route at all, and certanly not a route for 192.168.1.50.

That means that even thou the vpn-peers have connectivity to establish a VPN-tunnel AND there is a definition of crypto traffic in the acl bound to the crypto map on outside interface the router is not clever enough to understand to send it that way. The route is not in the routing table. So, we need to add that. The cheapest way to do it is with static routes:

r1:

ip route 10.10.30.3 255.255.255.255 10.10.11.2


r3:

ip route 10.10.11.1 255.255.255.255 10.10.30.1


Now we are good to go. Lets ping 10.3.3.3 from our 192.168.1.50-host:


C:\>ping 10.3.3.3

C:\>

(I apologize for the swedish OS )

But what if we are not allowed to use static routes. In real world noone would ever care but remember that in CCIE lab they will often throw a “and besides, you are not allowed to do it the easy way!” at you.

One solution could be to make the crypto map to insert a route for the remote networks into the local routing table. By doing that we can later on modify our crypto access-list without the need to care about static routes. Let´s do it!


r1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
r1(config)#no ip route 10.3.3.3 255.255.255.255 10.10.11.2
r1(config)#crypto map CMAP 10 ipsec-isakmp
r1(config-crypto-map)#reverse-route static
This will remove previously installed VPN routes and SAs
r1(config-crypto-map)#
r1#
r3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
r3(config)#no ip route 192.168.1.50 255.255.255.255 10.10.30.1
r3(config)#crypto map CMAP 10 ipsec-isakmp
r3(config-crypto-map)#reverse-route static
r3#


The magic is that, in each router, a static route has appeared in the routing-table without a corresponding static route in the config:


r1#sh ip route 10.3.3.3
Routing entry for 10.3.3.3/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.10.30.3
Route metric is 0, traffic share count is 1

r1#sh run | incl ip route
ip route 10.10.30.3 255.255.255.255 10.10.11.2
r1#


So. What is happening on the wire? First we see the ISAKMP-negotiation and then the encrypted ESP-traffic. Here, the output from wireshark placed in-transit between r1 and r3:


No. Time Source Destination Protocol Info
1 2010-03-19 07:44:28.799137 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode)
2 2010-03-19 07:44:28.805942 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode)
3 2010-03-19 07:44:28.810611 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode)
4 2010-03-19 07:44:28.911985 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode)
5 2010-03-19 07:44:29.022719 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode)
6 2010-03-19 07:44:29.027372 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode)
7 2010-03-19 07:44:29.032072 10.10.11.1 10.10.30.3 ISAKMP Quick Mode
8 2010-03-19 07:44:29.037702 10.10.30.3 10.10.11.1 ISAKMP Quick Mode
9 2010-03-19 07:44:29.042142 10.10.11.1 10.10.30.3 ISAKMP Quick Mode
10 2010-03-19 07:44:33.532046 10.10.11.1 10.10.30.3 ESP ESP (SPI=0x9793dfcd)
11 2010-03-19 07:44:33.533282 10.10.30.3 10.10.11.1 ESP ESP (SPI=0x43fe1aba)
12 2010-03-19 07:44:34.533694 10.10.11.1 10.10.30.3 ESP ESP (SPI=0x9793dfcd)
..
..


A key to success in configuring VPN is to interprete the debug output. The most common debug-commands are “debug crypto isakmp” and “deb crypto ipsec”. But the output is massive and it takes some exercise to learn to read it. Here is the output from r1 in our example above when establishing the VPN. Let´s see what happens:

r1#clear crypto session
r1#deb crypto isakmp
Crypto ISAKMP debugging is on
r1#deb crypto ipsec
Crypto IPSEC debugging is on
r1#
r1#
*Mar 19 08:50:47.623: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 10.10.11.1, remote= 10.10.30.3,
local_proxy= 192.168.1.50/255.255.255.255/0/0 (type=1),
remote_proxy= 10.3.3.3/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

Above we see that our ping triggered a request to setup a VPN (

*Mar 19 08:50:47.623: ISAKMP:(0): SA request profile is (NULL)
*Mar 19 08:50:47.623: ISAKMP: Created a peer struct for 10.10.30.3, peer port 500
*Mar 19 08:50:47.623: ISAKMP: New peer created peer = 0x840A5978 peer_handle = 0x80000008
*Mar 19 08:50:47.623: ISAKMP: Locking peer struct 0x840A5978, refcount 1 for isakmp_initiator
*Mar 19 08:50:47.623: ISAKMP: local port 500, remote port 500
*Mar 19 08:50:47.623: ISAKMP: set new node 0 to QM_IDLE
*Mar 19 08:50:47.623: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 8515F140
*Mar 19 08:50:47.623: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
*Mar 19 08:50:47.623: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-07 ID
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-03 ID
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-02 ID
*Mar 19 08:50:47.623: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
*Mar 19 08:50:47.623: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1
Going into the next state…IKE_I_MM1 is “we are sending main mode msg 1″
*Mar 19 08:50:47.623: ISAKMP:(0): beginning Main Mode exchange
*Mar 19 08:50:47.623: ISAKMP:(0): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_NO_STATE
*Mar 19 08:50:47.623: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.627: ISAKMP (0): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_NO_STATE
*Mar 19 08:50:47.627: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Mar 19 08:50:47.627: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2
Going into the next state…IKE_I_MM2 means “we got a reply on our first message”
*Mar 19 08:50:47.627: ISAKMP:(0): processing SA payload. message ID = 0
*Mar 19 08:50:47.627: ISAKMP:(0): processing vendor id payload
*Mar 19 08:50:47.627: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
*Mar 19 08:50:47.627: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Mar 19 08:50:47.627: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3
We have a pre-shared key configured for remote peer. That´s good…
*Mar 19 08:50:47.627: ISAKMP:(0): local preshared key found
*Mar 19 08:50:47.627: ISAKMP : Scanning profiles for xauth ...
*Mar 19 08:50:47.627: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
*Mar 19 08:50:47.627: ISAKMP: encryption AES-CBC
*Mar 19 08:50:47.627: ISAKMP: keylength of 128
*Mar 19 08:50:47.627: ISAKMP: hash SHA
*Mar 19 08:50:47.631: ISAKMP: default group 5
*Mar 19 08:50:47.631: ISAKMP: auth pre-share
*Mar 19 08:50:47.631: ISAKMP: life type in seconds
*Mar 19 08:50:47.631: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Mar 19 08:50:47.631: ISAKMP:(0):atts are acceptable. Next payload is 0
We have match on ISAKMP policies. This example is simple since both peers has only one isakmp policy defined so the first try is a match. Remember, both peers try to find a match among all their localy configured isakmp policies and their buddies. In more complex configurations or when dealing with vpn-clients it´s not uncommon to see tenths of policies from each end. Then the previous lines will be repeated for all attempts.
*Mar 19 08:50:47.631: ISAKMP:(0):Acceptable atts:actual life: 0
*Mar 19 08:50:47.631: ISAKMP:(0):Acceptable atts:life: 0
*Mar 19 08:50:47.631: ISAKMP:(0):Fill atts in sa vpi_length:4
*Mar 19 08:50:47.631: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
*Mar 19 08:50:47.631: ISAKMP:(0):Returning Actual lifetime: 86400
*Mar 19 08:50:47.631: ISAKMP:(0)::Started lifetime timer: 86400.
*Mar 19 08:50:47.631: ISAKMP:(0): processing vendor id payload
*Mar 19 08:50:47.631: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
*Mar 19 08:50:47.631: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Mar 19 08:50:47.631: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Mar 19 08:50:47.631: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM2
*Mar 19 08:50:47.631: ISAKMP:(0): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_SA_SETUP
*Mar 19 08:50:47.631: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.631: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Mar 19 08:50:47.631: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM3
Ok. IKE_I_MM3 means that we send the third packet (our second as a sender)

*Mar 19 08:50:47.731: ISAKMP (0): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_SA_SETUP
*Mar 19 08:50:47.731: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Mar 19 08:50:47.731: ISAKMP:(0):Old State = IKE_I_MM3 New State = IKE_I_MM4
And we got a reply. The fourth packet in the 6-packet main-mode flow

*Mar 19 08:50:47.827: ISAKMP:(2007):Send initial contact
*Mar 19 08:50:47.827: ISAKMP:(2007):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
*Mar 19 08:50:47.827: ISAKMP (2007): ID payload
next-payload : 8
type : 1
address : 10.10.11.1
protocol : 17
port : 500
length : 12
*Mar 19 08:50:47.827: ISAKMP:(2007):Total payload length: 12
*Mar 19 08:50:47.827: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_KEY_EXCH
*Mar 19 08:50:47.827: ISAKMP:(2007):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.827: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Mar 19 08:50:47.827: ISAKMP:(2007):Old State = IKE_I_MM4 New State = IKE_I_MM5
So. the fifth packet is where we send our pre-shared key
*Mar 19 08:50:47.831: ISAKMP (2007): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_KEY_EXCH
*Mar 19 08:50:47.831: ISAKMP:(2007): processing ID payload. message ID = 0
*Mar 19 08:50:47.831: ISAKMP (2007): ID payload
next-payload : 8
type : 1
address : 10.10.30.3
protocol : 17
port : 500
length : 12
*Mar 19 08:50:47.831: ISAKMP:(0):: peer matches *none* of the profiles
*Mar 19 08:50:47.831: ISAKMP:(2007): processing HASH payload. message ID = 0
*Mar 19 08:50:47.831: ISAKMP:(2007):SA authentication status:
authenticated
*Mar 19 08:50:47.831: ISAKMP:(2007):SA has been authenticated with 10.10.30.3
*Mar 19 08:50:47.831: ISAKMP: Trying to insert a peer 10.10.11.1/10.10.30.3/500/, and inserted successfully 840A5978.
*Mar 19 08:50:47.831: ISAKMP:(2007):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Mar 19 08:50:47.831: ISAKMP:(2007):Old State = IKE_I_MM5 New State = IKE_I_MM6
We got a reply, the sixth (and last) packet of Main mode phase 1

*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_I_MM6 New State = IKE_I_MM6
*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_I_MM6 New State = IKE_P1_COMPLETE
So. Phase 1 is completed.
*Mar 19 08:50:47.835: ISAKMP:(2007):beginning Quick Mode exchange, M-ID of -1445410418
Quick mode = Phase 1
*Mar 19 08:50:47.835: ISAKMP:(2007):QM Initiator gets spi
*Mar 19 08:50:47.835: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) QM_IDLE
*Mar 19 08:50:47.835: ISAKMP:(2007):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.835: ISAKMP:(2007):Node -1445410418, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_QM_READY New State = IKE_QM_I_QM1
IKE_QM_I_QM1 means that we´ve sent our first phase 2 packet
*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE

*Mar 19 08:50:47.843: ISAKMP (2007): received packet from 10.10.30.3 dport 500 sport 500 Global (I) QM_IDLE
We got an answer. The reply is the second of three packets in phase 2. The content of this received packet is SA-data for ipsec SA:s. Which traffic to protect (proxies), encryption parameters and so on. What happens next is that this information is compared to our local configuration to make sure that it matches. Then the SA:s are being setup…

*Mar 19 08:50:47.843: ISAKMP:(2007): processing HASH payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): processing SA payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007):Checking IPSec proposal 1
*Mar 19 08:50:47.843: ISAKMP: transform 1, ESP_AES
*Mar 19 08:50:47.843: ISAKMP: attributes in transform:
*Mar 19 08:50:47.843: ISAKMP: encaps is 1 (Tunnel)
*Mar 19 08:50:47.843: ISAKMP: SA life type in seconds
*Mar 19 08:50:47.843: ISAKMP: SA life duration (basic) of 3600
*Mar 19 08:50:47.843: ISAKMP: SA life type in kilobytes
*Mar 19 08:50:47.843: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
*Mar 19 08:50:47.843: ISAKMP: authenticator is HMAC-SHA
*Mar 19 08:50:47.843: ISAKMP: key length is 128
*Mar 19 08:50:47.843: ISAKMP:(2007):atts are acceptable.
*Mar 19 08:50:47.843: IPSEC(validate_proposal_request): proposal part #1
*Mar 19 08:50:47.843: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 10.10.11.1, remote= 10.10.30.3,
local_proxy= 192.168.1.50/255.255.255.255/0/0 (type=1),
remote_proxy= 10.3.3.3/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Mar 19 08:50:47.843: Crypto mapdb : proxy_match
src addr : 192.168.1.50
dst addr : 10.3.3.3
protocol : 0
src port : 0
dst port : 0
*Mar 19 08:50:47.843: ISAKMP:(2007): processing NONCE payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): processing ID payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): processing ID payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): Creating IPSec SAs
*Mar 19 08:50:47.843: inbound SA from 10.10.30.3 to 10.10.11.1 (f/i) 0/ 0
(proxy 10.3.3.3 to 192.168.1.50)
*Mar 19 08:50:47.843: has spi 0xCB15AC0E and conn_id 0
*Mar 19 08:50:47.843: lifetime of 3600 seconds
*Mar 19 08:50:47.843: lifetime of 4608000 kilobytes
*Mar 19 08:50:47.843: outbound SA from 10.10.11.1 to 10.10.30.3 (f/i) 0/0
(proxy 192.168.1.50 to 10.3.3.3)
*Mar 19 08:50:47.843: has spi 0xBA3D8C69 and conn_id 0
*Mar 19 08:50:47.843: lifetime of 3600 seconds
*Mar 19 08:50:47.847: lifetime of 4608000 kilobytes
*Mar 19 08:50:47.847: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) QM_IDLE
We send our third and last packet in phase 2 packet exchange…
*Mar 19 08:50:47.847: ISAKMP:(2007):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.847: ISAKMP:(2007):deleting node -1445410418 error FALSE reason "No Error"
*Mar 19 08:50:47.847: ISAKMP:(2007):Node -1445410418, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*Mar 19 08:50:47.847: ISAKMP:(2007):Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE
*Mar 19 08:50:47.847: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Mar 19 08:50:47.847: Crypto mapdb : proxy_match
src addr : 192.168.1.50
dst addr : 10.3.3.3
protocol : 0
src port : 0
dst port : 0
*Mar 19 08:50:47.847: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 10.10.30.3
*Mar 19 08:50:47.847: IPSEC(rte_mgr): VPN Route Event static keyword or dynamic SA create for 10.10.30.3
*Mar 19 08:50:47.847: IPSEC(policy_db_add_ident): src 192.168.1.50, dest 10.3.3.3, dest_port 0

*Mar 19 08:50:47.847: IPSEC(create_sa): sa created,
(sa) sa_dest= 10.10.11.1, sa_proto= 50,
sa_spi= 0xCB15AC0E(3407195150),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 59
sa_lifetime(k/sec)= (4453107/3600)
*Mar 19 08:50:47.847: IPSEC(create_sa): sa created,
(sa) sa_dest= 10.10.30.3, sa_proto= 50,
sa_spi= 0xBA3D8C69(3124595817),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 60
sa_lifetime(k/sec)= (4453107/3600)
*Mar 19 08:50:47.847: IPSEC(update_current_outbound_sa): updated peer 10.10.30.3 current outbound sa to SPI BA3D8C69
*Mar 19 08:50:48.027: ISAKMP:(2006):purging SA., sa=8515E77C, delme=8515E77C
r1#


Voila!

And just to make sure all looks good let´s check our SA:s:


r1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.10.30.3 10.10.11.1 QM_IDLE 2007 ACTIVE
r1#
As you can see there is one isakmp SA created. State QM_IDLE is good, it means that all is fine in isakmp/phase 1
r1#sh crypto ipsec sa

outbound pcp sas:
r1#
There are 2 ipsec SA:s established. One in each direction. That´s just the way it is. Looking at the number of encaps/decaps packets gives us a hint that we are both sending traffic and receiving traffic thru the tunnel.

That´s all for now. This was a massive post. I will use this exampel as a template for the next VPN configurations so hopefully they will not be as massive as this.

Please feel free to comment if there is anything I´ve missed or if I got something the wrong way…

Configs for r1 and r3 here…