CCIE Security Lab Workbook Volume II for CCIE v3.

Copyright Information
Copyright © 2003 - 2011 Internetwork Expert, Inc. All rights reserved.

The following publication, Internetwork Expert’s CCIE Security Lab Workbook Volume II,
was developed by Internetwork Expert, Inc. All rights reserved. No part of this publication may
be reproduced or distributed in any form or by any means without the prior written permission
of Internetwork Expert, Inc.

Cisco®, Cisco® Systems, CCIE, and Cisco Certified Internetwork Expert, are registered
trademarks of Cisco® Systems, Inc. and/or its affiliates in the U.S. and certain countries.
All other products and company names are the trademarks, registered trademarks, and
service marks of the respective owners. Throughout this manual, Internetwork Expert,
Inc. has used its best efforts to distinguish proprietary trademarks from descriptive
names by following the capitalization styles used by the manufacturer.

Copyright © 2011 Internetwork Expert [Link]

-i-
CCIE Security Lab Workbook Volume II for CCIE v3.0

Copyright © 2011 Internetwork Expert [Link]

- ii -
CCIE Security Lab Workbook Volume II for CCIE v3.0

Disclaimer
The following publication, Internetwork Expert’s CCIE Security Lab Workbook Volume II,
is designed to assist candidates in the preparation for Cisco Systems’ CCIE Security Lab
exam. While every effort has been made to ensure that all material is as complete and
accurate as possible, the enclosed material is presented on an “as is” basis. Neither the
authors nor Internetwork Expert, Inc. assume any liability or responsibility to any person or
entity with respect to loss or damages incurred from the information contained in this
workbook.

This workbook was developed by Internetwork Expert, Inc. and is an original work of the
aforementioned authors. Any similarities between material presented in this workbook
TM
and actual CCIE lab material is completely coincidental.

Copyright © 2011 Internetwork Expert [Link]

- iii -
CCIE Security Lab Workbook Volume II for CCIE v3.0

Copyright © 2011 Internetwork Expert [Link]

- iv -
CCIE Security Lab Workbook Volume II for CCIE v3.0

Table of Contents
IEWB-SC-VOL2 Lab 1 Solutions...................................................... 7
IEWB-SC-VOL2 Lab 2 Solutions.................................................. 131
IEWB-SC-VOL2 Lab 3 Solutions.................................................. 215
IEWB-SC-VOL2 Lab 4 Solutions.................................................. 297
IEWB-SC-VOL2 Lab 5 Solutions.................................................. 403
IEWB-SC-VOL2 Lab 6 Solutions.................................................. 515
IEWB-SC-VOL2 Lab 7 Solutions.................................................. 667
IEWB-SC-VOL2 Lab 8 Solutions.................................................. 755
IEWB-SC-VOL2 Lab 9 Solutions.................................................. 861
IEWB-SC-VOL2 Lab 10 Solutions................................................ 951

Copyright © 2011 Internetwork Expert [Link]

-v-
CCIE Security Lab Workbook Volume II for CCIE v3.0 Lab 10

Copyright © 2011 Internetwork Expert [Link]

-6-
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

IEWB-SC-VOL2 Lab 1 Solutions

Task 1.1 Solution
ASA1:
hostname Rack4ASA
!
interface Ethernet0/0
nameif outside
ip address [Link] [Link]
no shutdown
!
interface Ethernet0/1
nameif inside
ip address [Link] [Link]
no shutdown

Task 1.2 Solution

ASA1:
!
! Default information is only originated if there is
! a default route in the routing table of the firewall
!
router ospf 1
router-id [Link]
network [Link] [Link] area 51
network [Link] [Link] area 51
default-information originate

!
! Create an SLA monitor object to ping R5
!
sla monitor 1
type echo protocol ipIcmpEcho [Link] interface outside
timeout 1000
frequency 1

!
! Start monitoring
!
sla monitor schedule 1 start-time now life forever

Copyright © 2011 Internetwork Expert [Link]

-7-
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

!
! Track the SLA object
!
track 1 rtr 1 reachability

!
! Create a default route tracking the SLA object
!
route outside 0 0 [Link] track 1

Task 1.2 Breakdown

OSPF process will only generate and propagate a default route if this route is
already present in the local routing table. This is a requirement to prevent routing
loops. Therefore, we need to have a default route in R5’s routing table pointing to
R5.

In order to ensure the default gateway rechability a monitoring process need to

track R5’s liveleness. We configure an SLA object that sends ICMP ping every
second and times operation out in one second. Since no specific values are
given in the scenario we use just the values we find “reasonable” to test this
scenario.

The next step is creating a tacking object that reflects the SLA monitor status.
The final step is configuring a static route bound to the tacking object and
configuring the routing process to advertise a default route.

Tasks 1.1-1.2 Verification

Verify OSPF adjacencies in the ASA firewall. You should see both BB2 and
SW2.

Rack4ASA(config)# show ospf neighbor

Neighbor ID Pri State Dead Time Address

Interface
[Link] 1 FULL/DROTHER [Link] [Link]
inside
[Link] 1 FULL/DR [Link] [Link]
inside

Copyright © 2011 Internetwork Expert [Link]

-8-
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Verify the SLA object operational state and track object status. After this, ensure
that the default route is in the routing tables of the ASA and SW2.

Rack4ASA(config)# show sla monitor operational-state 1

Entry number: 1
Modification time: [Link].943 UTC Fri Apr 10 2009
Number of Octets Used by this Entry: 1480
Number of operations attempted: 134
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: FALSE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): 1
Latest operation start time: [Link].945 UTC Fri Apr 10 2009
Latest operation return code: OK
RTT Values:
RTTAvg: 1 RTTMin: 1 RTTMax: 1
NumOfRTT: 1 RTTSum: 1 RTTSum2: 1

Rack4ASA(config)# show track

Track 1
Response Time Reporter 1 reachability
Reachability is Up
2 changes, last change [Link]
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0

Rack4ASA(config)# show route | include [Link]

Gateway of last resort is [Link] to network [Link]
S* [Link] [Link] [1/0] via [Link], outside

Rack4SW2#show ip route ospf | inc [Link]

O*E2 [Link]/0 [110/1] via [Link], [Link], Vlan255

Copyright © 2011 Internetwork Expert [Link]

-9-
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Now shutdown R5’s VLAN125 interface and check that the ASA detects this
event. Since the default route is no longer in the routing table, it is not advertised
via OSPF.

Rack4R5(config)#interface fastEthernet 0/1

Rack4R5(config-if)#shutdown

Rack4ASA(config)# show track

Track 1
Response Time Reporter 1 reachability
Reachability is Down
3 changes, last change [Link]
Latest operation return code: Timeout
Tracked by:
STATIC-IP-ROUTING 0

Rack4ASA(config)# show route | inc [Link]

Rack4SW2#sh ip route ospf

[Link]/32 is subnetted, 1 subnets
O E2 [Link] [110/20] via [Link], [Link], Vlan255

Copyright © 2011 Internetwork Expert [Link]

- 10 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.3 Solution

SW2:
vlan 199
!
! Connect E0/2 ports of the ASAs using a new VLAN
!
interface range FastEthernet 0/13 , FastEthernet 0/15
switchport host
switchport access vlan 199

ASA1:
!
! Enable physical failover link
!
interface ethernet 0/2
no shutdown

!
! Configure standby IP addresses
!
interface Ethernet 0/0
ip address [Link] [Link] standby [Link]
!
interface Ethernet 0/1
ip address [Link] [Link] standby [Link]

!
! Designate unit as primary and name failover interface
!
failover lan unit primary
failover lan interface failover Ethernet0/2

!
! Enable stateful faiolver on the same link
!
failover link failover Ethernet0/2

!
! Configure failover addressing
!
failover interface ip failover [Link] [Link] standby
[Link]

!
! Set interface polling timers to minimum
!
failover polltime interface msec 500 holdtime 5

!
! Disable the inside interface monitoring
!
no monitor-interface inside

Copyright © 2011 Internetwork Expert [Link]

- 11 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

!
! Enable failover
!
failover

ASA2:
interface ethernet 0/2
no shutdown
!
failover lan interface failover Ethernet0/2
!
failover link failover Ethernet0/2
!
failover interface ip failover [Link] [Link] stan
[Link]
!
failover

Task 1.3 Breakdown

The task requires configuring a failover pair. At the very least we need to enable
a failover interface, but the task asks for stateful failover. This means we need to
set up an additional stateful failover link. In our case, the simples solution would
be reusing the same interface used for basic failover.

By default all interfaces on the unit are monitored. This means we need to
explicitly disable inside interface monitoring to satisfy the scenario requirements.
Additonally, the requirement to respond to an interface failure in the shortest
amount of time translates into using shortest polling timers for the interfaces.
Notice that this does not affect the failover link polling – detecting failover link
issues is separate from detecting the physical interface failures.

Task 1.4 Solution

ASA1: (The active failover unit)
nat (inside) 1 0 0
global (outside) 1 interface

Tasks 1.3 – 1.4 Verification

Verify failover status in ASA1 first. Check the failover interface polling timers.
Notice that only one interface is being monitored. Ensure the other unit is in
standby ready state.

After this, ensure that only the outside interface is monitored by the firewall.

Copyright © 2011 Internetwork Expert [Link]

- 12 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Rack4ASA(config)# show failover

Failover On
Failover unit Primary
Failover LAN Interface: failover Ethernet0/2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 500 milliseconds, holdtime 5 seconds
Interface Policy 1
Monitored Interfaces 1 of 250 maximum
Version: Ours 8.0(4), Mate 8.0(4)
Last Failover at: [Link] UTC Apr 10 2009
This host: Primary - Active
Active time: 160 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.0(4)) status (Up Sys)
Interface outside ([Link]): Normal (Waiting)
Interface inside ([Link]): Normal (Not-
Monitored)
slot 1: empty
Other host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.0(4)) status (Up Sys)
Interface outside ([Link]): Normal (Waiting)
Interface inside ([Link]): Normal (Not-
Monitored)
slot 1: empty

Stateful Failover Logical Update Statistics

Link : failover Ethernet0/2 (up)
Stateful Obj xmit xerr rcv rerr
General 4 0 0 0
sys cmd 0 0 0 0
up time 0 0 0 0
RPC services 0 0 0 0
TCP conn 0 0 0 0
UDP conn 0 0 0 0
ARP tbl 4 0 0 0
Xlate_Timeout 0 0 0 0
VPN IKE upd 0 0 0 0
VPN IPSEC upd 0 0 0 0
VPN CTCP upd 0 0 0 0
VPN SDI upd 0 0 0 0
VPN DHCP upd 0 0 0 0
SIP Session 0 0 0 0

Logical Update Queue Information

Cur Max Total
Recv Q: 0 2 0
Xmit Q: 0 26 37

Copyright © 2011 Internetwork Expert [Link]

- 13 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Rack4ASA(config)# show monitor-interface

This host: Primary - Active
Interface outside ([Link]): Normal
Other host: Secondary - Standby Ready
Interface outside ([Link]): Normal

Now simulate an interface failure by shutting down the switch port connected to
the primary unit’s outside interface. Check the failover status again.

Rack4SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack4SW2(config)#interface fastEthernet 0/12
Rack4SW2(config-if)#shutdown
Rack4SW2(config-if)#

Rack4ASA(config)# show failover

Failover On
Failover unit Primary
Failover LAN Interface: failover Ethernet0/2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 500 milliseconds, holdtime 5 seconds
Interface Policy 1
Monitored Interfaces 1 of 250 maximum
Version: Ours 8.0(4), Mate 8.0(4)
Last Failover at: [Link] UTC Apr 10 2009
This host: Primary - Failed
Active time: 439 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.0(4)) status (Up Sys)

Interface outside ([Link]): No Link (Waiting)

Interface inside ([Link]): Normal (Not-
Monitored)
slot 1: empty
Other host: Secondary - Active
Active time: 7 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.0(4)) status (Up Sys)
Interface outside ([Link]): Normal (Waiting)
Interface inside ([Link]): Normal (Not-
Monitored)
slot 1: empty
<snip>

Copyright © 2011 Internetwork Expert [Link]

- 14 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Rack4ASA(config)# show monitor-interface

This host: Primary - Failed
Interface outside ([Link]): No Link (Waiting)
Other host: Secondary - Active
Interface outside ([Link]): Normal (Waiting)

Confirm that you may still reach R5 from SW2, even with the primary firewall
failed.

Rack4SW2#telnet [Link]
Trying [Link] ... Open

User Access Verification

Password: cisco
Rack4R5>

Copyright © 2011 Internetwork Expert [Link]

- 15 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.5 Solution

ASA1: (The active failover unit)
!
! Access-list to classify traffic
!
access-list TCP extended permit tcp any any
access-list UDP extended permit udp any any

!
! L3/L4 class-map for UDP traffic
!
class-map UDP_TRAFFIC
match access-list UDP
!
! L3/L4 class-map for TCP traffic
!
class-map TCP_TRAFFIC
match access-list TCP

!
! TCP Inspection Map to permit TCP Option 19 (MD5 Auth)
!
tcp-map OPTION19
tcp-options range 19 19 allow

!
! Apply connection limit & inspection policy
!
policy-map global_policy
!
class TCP_TRAFFIC
set connection conn-max 5000 per-client-max 1000
set connection advanced-options OPTION19
class UDP_TRAFFIC
set connection conn-max 1000 per-client-max 500

!
! By inspecting ICMP we permit the returning packets
!
class inspection_default
inspect icmp

Copyright © 2011 Internetwork Expert [Link]

- 16 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.5 Breakdown

There are two main approaches to permit returning ICMP packets: either use an
access-list on the outside interface or configure ICMP protocol inspection. Since
we are not allowed to use access-lists, ICMP inspection is our only option. Notice
that ICMP is already under the “inspection_default” class so we do not have to
create a separate access-list/class-map to match it.

For adjusting TCP/UDP session parameters we first need MPF classes matching
the respective protocols. We use access-list for matching TCP and UDP packets
and then create the respective class-maps. The last step is configuring the
classes under a policy-map. Since we do not have any specific policy-maps
applied anywhere, we use the default “global_policy” and assign our custom
classes there.

Copyright © 2011 Internetwork Expert [Link]

- 17 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.5 Verification

Issue the command that lists the global inspection policy parameters. Notice the
connection limits set for every class.

Rack4ASA(config)# show service-policy global

Global policy:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns migrated_dns_map_1, packet 0, drop 0, reset-drop 0
Inspect: ftp, packet 0, drop 0, reset-drop 0
Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0
Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0
Inspect: rsh, packet 0, drop 0, reset-drop 0
Inspect: rtsp, packet 0, drop 0, reset-drop 0
Inspect: esmtp _default_esmtp_map, packet 0, drop 0, reset-drop 0
Inspect: sqlnet, packet 0, drop 0, reset-drop 0
Inspect: skinny, packet 0, drop 0, reset-drop 0
Inspect: sunrpc, packet 0, drop 0, reset-drop 0
Inspect: xdmcp, packet 0, drop 0, reset-drop 0
Inspect: sip, packet 0, drop 0, reset-drop 0
Inspect: netbios, packet 0, drop 0, reset-drop 0
Inspect: tftp, packet 0, drop 0, reset-drop 0

Class-map: TCP_TRAFFIC
Set connection policy: conn-max 5000 per-client-max 1000
current conns 0, drop 0
Set connection advanced-options: OPTION19
Retransmission drops: 0 TCP checksum drops : 0
Exceeded MSS drops : 0 SYN with data drops: 0
Out-of-order packets: 0 No buffer drops : 0
Reserved bit cleared: 0 Reserved bit drops : 0
IP TTL modified : 0 Urgent flag cleared: 0
Window varied resets: 0

TCP-options:
Selective ACK cleared: 0 Timestamp cleared : 0
Window scale cleared : 0
Other options cleared: 0
Other options drops: 0
Class-map: UDP_TRAFFIC
Set connection policy: conn-max 1000 per-client-max 500
current conns 0, drop 0

Copyright © 2011 Internetwork Expert [Link]

- 18 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.6 Solution

ASA1: (The active failover unit)
static (inside,outside) [Link] [Link]
!
! By applying inspection to ICMP error messages we hide
! the identity of the host responding to traceroute probes
!
! Therefore, no inside addresses will be visible to the outside
!
policy-map global_policy
class inspection_default
inspect icmp error

!
! Access-list to permit inbound UDP traffic (traceroute ports)
! and ICMP echo messages (pings)
!
access-list OUTSIDE_IN extended permit udp any any range 33434 33524
access-list OUTSIDE_IN extended permit icmp any any echo

!
! Apply the access-list
!
access-group OUTSIDE_IN in interface outside

!
! Access-list to classify ICMP traffic
!
access-list ICMP extended permit icmp any any

!
! L3/L4 class-map for ICMP traffic
!
class-map ICMP_TRAFFIC
match access-list ICMP

!
! Policy-map to rate-limit ICMP traffic
!
policy-map OUTSIDE
class ICMP_TRAFFIC
police input 56000
police output 56000

!
! Apply the service policy
!
service-policy OUTSIDE interface outside

Copyright © 2011 Internetwork Expert [Link]

- 19 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.6 Breakdown

Traceroute and Ping are the most common network testing tools and you need to
understand their work. We are mostly concerned with traceroute as ping is
relatively simple. The UNIX variant of traceroute operates by sending UDP
packets to presumably “unused” UDP ports, starting with port 33434, with
incrementing TTL starting at TTL=1. For every hop, three probes are sent with
incrementing port numbers. That is, for example hop 1 (TTL=1) three probes are
sent to port-numbers: 33434, 33435, 33436 all with TTL=1. The destination
address in all probes is sent to the IP address of the traceroute target, so every
transit hop will attempt to forward the packet. However, if the TTL has fallen to 1,
the transit router has to send back and ICMP “time-exceeded” error message,
with the header of the original UDP packet embedded. Based on the ICMP
unreachable response the probing host may determine the transit gateway IP
address and the original TTL value. As soon soon as the probing packets reach
the destination, the final hop will respond with ICMP port unreachable message
and thus tell the probing host that it probes have reached the final destination.

From the above description we may conclude the following: In order to permit
inbound traceroute we need to allow the UDP port range starting at 33434 and
up till the maximum port number that a traceroute can use. The default hop count
that the UNIX traceroute will use by default is 30, so we need to open the ports
up to 33524. Next, since the task requires hiding the identity of the hosts inside
the firewall, we configure the firewall to inspect the ICMP error messages, such
as ICMP unreachables. By default those do not have their addresses translated
to easy troubleshooting across the firewall, but enabling ICMP inspection for
error messages using the command icmp inspect error will enable
translations.

The next requiremet is permitting the ping operations inbound on the outside
interface: this is accomplished by permitting inbound ICMP echo messages – the
echo-replies from the inside are permitted automatically by the virtue of security-
levels. And the final requirement is limiting the ICMP traffic rate on the outside
interface: this requires an interface-level policy map, since applying policing
globally would affect all interfaces. We create a class-map matching ICMP traffic
and apply a policy-map with policing statements. Since no burst values are
specified we let the firewall pick up the default values for us.

Copyright © 2011 Internetwork Expert [Link]

- 20 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.6 Verification

Traceroute to the outside IP address of SW2. Notice that the real inside IP
address of the switch never shows up in the traceroute output. Also notice that
the ASA firewall does not appear as a hop in the traceroute output – the firewall
does not decrement TTL and remains “invisible” in the traceroute path. Verify that
pings work as well.

Rack4R1#traceroute [Link]

Type escape sequence to abort.

Tracing the route to [Link]

1 [Link] 32 msec 28 msec 32 msec

2 [Link] 56 msec 57 msec 56 msec
3 [Link] 84 msec 84 msec 84 msec
4 [Link] 84 msec * 84 msec

Rack4R1#ping [Link]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/171/173
ms

Copyright © 2011 Internetwork Expert [Link]

- 21 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Verify traffic rate-limiting for ICMP packets. Notice that policing function drops
outbound packets, as the rate exceeds 56Kbps.

Rack4SW2#ping [Link] repeat 1000 size 1500

Type escape sequence to abort.

Sending 1000, 1500-byte ICMP Echos to [Link], timeout is 2
seconds:
!!!!!.!!!!!.!!!!!.!!!!!.!!!!!.
Success rate is 83 percent (25/30), round-trip min/avg/max = 4/5/8 ms

Rack4ASA(config)# show service-policy interface outside

Interface outside:
Service-policy: OUTSIDE
Class-map: ICMP_TRAFFIC
Input police Interface outside:
cir 56000 bps, bc 1750 bytes
conformed 992 packets, 120260 bytes; actions: transmit
exceeded 0 packets, 0 bytes; actions: drop
conformed 0 bps, exceed 0 bps
Output police Interface outside:
cir 56000 bps, bc 1750 bytes
conformed 1003 packets, 121250 bytes; actions: transmit
exceeded 7 packets, 7798 bytes; actions: drop
conformed 0 bps, exceed 0 bps
Rack4ASA(config)#

Copyright © 2011 Internetwork Expert [Link]

- 22 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.7 Solution

ASA1: (the active failover unit)
!
! UNIX traceroute relies on two ICMP message types sent in response to
! UDP probes: ICMP time-exceede and port-unreachable.
!
! An object group is used to create only a single-line ACL entry.
!
object-group icmp-type TRACERT
icmp-object time-exceeded
icmp-object unreachable

!
! A single line ACL entry
!
access-list OUTSIDE_IN permit icmp any any object-group TRACERT

Task 1.7 Breakdown

Permitting outbound traceroute requires allowing the returing traffic to come back
through the firewall. In our case, UNIX traceroute variant is in use and thus the
returning traffic consist of ICMP messages. Specifically, the two message types
being used are “time-exceeded” and “port-unreachable”. However, ASA CLI
syntax does not distinguish various unreachable messages (e.g. port-
unreachable, host-unreachable and so on) so we need to permit all
“unreachable” message types. The next question is how to do this using an ACL.

A common requirement “use the minimum amount of ACL lines” typically

translates into using object groups for say multiple port of ICMP types. This is the
case in our scenario, where combinging the ICMP message types into an object
group allows us using a single ACL line as opposed to two lines we would need
otherwise.

Copyright © 2011 Internetwork Expert [Link]

- 23 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.7 Verification

Traceroute from SW2 to R1, check the access-list hit counters.

Rack4SW2#traceroute [Link]

Type escape sequence to abort.

Tracing the route to [Link]

1 [Link] 4 msec 4 msec 4 msec

2 [Link] 32 msec 32 msec 28 msec
3 [Link] 60 msec 60 msec 56 msec
4 [Link] 84 msec * 84 msec
Rack4SW2#

Rack4ASA(config)# show access-list OUTSIDE_IN

access-list OUTSIDE_IN; 5 elements
access-list OUTSIDE_IN line 1 extended permit udp any any range 33434
33464 (hitcnt=39) 0x061e01ad
access-list OUTSIDE_IN line 2 extended permit icmp any any echo
(hitcnt=5) 0x869bdf05
access-list OUTSIDE_IN line 3 extended permit icmp any any object-group
TRACERT 0xd559d01e
access-list OUTSIDE_IN line 3 extended permit icmp any any time-
exceeded (hitcnt=12) 0x00c3b80d
access-list OUTSIDE_IN line 3 extended permit icmp any any
unreachable (hitcnt=4) 0xec6c9a23

Copyright © 2011 Internetwork Expert [Link]

- 24 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.8 Solution

ASA1:
!
! Port redirection from outside interface to BB2
!
static (inside,outside) tcp interface telnet [Link] telnet

!
! Permission for port redirection
!
access-list OUTSIDE_IN extended permit tcp any host [Link] eq
telnet

Task 1.8 Breakdown

Port redirection is normally configured using static NAT entries. The delicacy of
the situation is that we need to use the ASA’s own IP address for redirection.
This could only be done by creating an static NAT entry with the “interface”
keyword. The static NAT entry must be accompanied by an access-list entry
permitting packets to the ASA’s outside interface on the given port.

Task 1.8 Verification

Telnet to the outside interface of the ASA and ensure the session actually
terminates on BB2.

Rack4R5#telnet [Link]
Trying [Link] ... Open

+-----------------------------------------------------------------------+
| |
| Welcome to BB2. These commands are available for use at privilege 0 |
| |
| ping show ip bgp |
| telnet show ip bgp neighbors |
| traceroute show ip bgp summary |
| show ip route show ip interface brief |
| show ip protocols |
| |
| The reference configuration for this device is available at: |
| [Link] |
| |
+-----------------------------------------------------------------------+

BB2>

Copyright © 2011 Internetwork Expert [Link]

- 25 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 1.9 Solution

ASA1: (the active firewall unit)
!
! Destination NAT setup
!
alias (inside) [Link] [Link]

Task 1.9 Breakdown

The alias command has two functions: firstly, it performs the destination NAT
function by rewriting the destination IP and secondly it may be used to rewrite the
DNS responses. In our case, the only requirement is redirecting the traffic, so we
bind an alias on the inside interface, redirecting packets going to .20 into the host
with the IP .200. The firewall will proxy-ARP for the IP address .20 and then
translate the destination IP address to the correct one.

Task 1.9 Verification

Start pinging the incorrect IP address from SW2 while having ICMP trace
debugging enabled in the ASA. Notice that you will also see ICMP packets
generated by the SLA probe in the debugging output. Pay attention to the fact
that packets destined to the IP address [Link] are redirected to
[Link].

Rack4SW2#ping [Link] repeat 100

Type escape sequence to abort.

Sending 100, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
...

Rack4ASA(config)# debug icmp trace

ICMP echo request untranslating inside:[Link] to

outside:[Link]
ICMP echo request from inside:[Link] to outside:[Link] ID=14
seq=4 len=72
ICMP echo request translating inside:[Link] to outside:[Link]
ICMP echo request untranslating inside:[Link] to
outside:[Link]

Copyright © 2011 Internetwork Expert [Link]

- 26 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 2.1 Solution

R1:
!
! Security zones
!
zone security OUTSIDE
zone security INSIDE

!
! Traceroute responses ACL and Class-Map
!
ip access-list extended TRACEROUTE_RESPONSES_ACL
permit icmp any any time-exceed
permit icmp any any port-unreach
!

class-map type inspect match-all TRACEROUTE_RESPONSES_CMAP

match access-group name TRACEROUTE_RESPONSES_ACL

!
! Traffic to the inside HTTP server
!
ip access-list extended INSIDE_HTTP_SERVER_ACL
permit tcp any host [Link] eq 80
permit tcp any host [Link] eq 443
!
class-map type inspect match-all INSIDE_HTTP_SERVER_CMAP
match access-group name INSIDE_HTTP_SERVER_ACL
match protocol tcp
!
class-map type inspect match-any ALLOWED_TRAFFIC_CMAP
match protocol tcp
match protocol icmp
match protocol udp

!
! Policy for the inside->outside traffic
!
policy-map type inspect INSIDE_TO_OUTSIDE_PMAP
class type inspect ALLOWED_TRAFFIC_CMAP
inspect
class class-default
drop

!
! Policy for the outside->inside traffic
!
policy-map type inspect OUTSIDE_TO_INSIDE_PMAP
class type inspect INSIDE_HTTP_SERVER_CMAP
inspect
class TRACEROUTE_RESPONSES_CMAP
pass
class class-default
drop

Copyright © 2011 Internetwork Expert [Link]

- 27 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

!
! Define a zone pair and apply the policy
!
zone-pair security INSIDE_TO_OUTSIDE source INSIDE destination OUTSIDE
service-policy type inspect INSIDE_TO_OUTSIDE_PMAP

!
! Define a zone pair and apply the policy
!
zone-pair security OUTSIDE_TO_INSIDE source OUTSIDE destination INSIDE
service-policy type inspect OUTSIDE_TO_INSIDE_PMAP

!
! Assign the zones to the interfaces
!
interface Serial 0/0.123
zone-member security INSIDE
!
interface FastEthernet 0/0
zone-member security OUTSIDE

Task 2.1 Breakdown

This is a relatively simple ZBFW example, with only a couple of security zones
defined. Start your ZBFW configurations making a simple diagram of the security
zones and outline the traffic flows between the zones. In our case, there are two
zones: INSIDE and OUTSIDE (the names could be any at your choice).

The traffic going INSIDE to OUTSIDE includes TCP, UDP and ICMP protocols –
no other specifics have been defined. The traffic in opposite direction includes
HTTP and HTTPS sessions to a pre-defined IP as well as “traceroute return
traffic” which included ICMP port-unreachcale and ICMP time-exceeded
messages.

Traffic going from INSIDE to outside could be matching using “match protocol”
statement:

class-map type inspect match-any ALLOWED_TRAFFIC_CMAP

match protocol tcp
match protocol icmp
match protocol udp

However, matching the HTTP and HTTPS traffic to the internat server could be
accomplished in multiple ways. The solution matches an access-list allowing just
HTTP and HTTPs traffic to the server and then combines this match with “match
protocol tcp” which is sufficient to inspect HTTP and HTTPs sessions. This,
however, does not allows for deep session inspection in HTTP. But since we are
not required to do so, we could just stay with this configurartion:

Copyright © 2011 Internetwork Expert [Link]

- 28 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

ip access-list extended INSIDE_HTTP_SERVER_ACL

permit tcp any host [Link] eq 80
permit tcp any host [Link] eq 443
!
class-map type inspect match-all INSIDE_HTTP_SERVER_CMAP
match access-group name INSIDE_HTTP_SERVER_ACL
match protocol tcp

An alternative configuration would look something like following:

class-map type inspect match-any PROTOCOLS_FOR_HTTP_SERVER_CMAP

match protocol http
match protocol https
!
ip access-list extended INSIDE_HTTP_SERVER_ACL
permit tcp any host [Link]
!
class-map type inspect match-all INSIDE_HTTP_SERVER_CMAP
match class PROTOCOLS_FOR_HTTP_SERVER_CMAP
match access-group name INSIDE_HTTP_SERVER_ACL

In this situation, bot solutions work, but you should prefer the second one if deep
packet inspection has been requested. Finally, the traceroute “returning” traffic
includes two ICMP message types, and these could not be allowed by inspecting
traffic going from inside to outside. So we create an access-list matching these
messages, envelop it into a class-map and finally attach this to a policy-map, with
a pass statement – the ICMP error messages could not be inspected. Notice that
this implies that there is no corellatio among the returning ICMP error messages
and outgoing UDP probes sent by traceroute utility.

Copyright © 2011 Internetwork Expert [Link]

- 29 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 2.1 Verification

Generate some test traffic from a host on the inside zone.

Rack4R2#traceroute [Link]

Type escape sequence to abort.

Tracing the route to [Link]

1 [Link] 28 msec 32 msec 28 msec

2 [Link] 32 msec * 32 msec

Rack4R2#ping [Link]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/64 ms

Rack4R2#telnet [Link]
Trying [Link] ... Open

BB3>exit

[Connection to [Link] closed by foreign host]

Copyright © 2011 Internetwork Expert [Link]

- 30 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Check the inspection policy maps statistics.

Rack4R1#show policy-map type inspect zone-pair

Zone-pair: INSIDE_TO_OUTSIDE

Service-policy inspect : INSIDE_TO_OUTSIDE_PMAP

Class-map: ALLOWED_TRAFFIC_CMAP (match-any)

Match: protocol tcp
1 packets, 24 bytes
30 second rate 0 bps
Match: protocol icmp
1 packets, 80 bytes
30 second rate 0 bps
Match: protocol udp
3 packets, 24 bytes
30 second rate 0 bps
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:34]
udp packets: [0:3]
icmp packets: [0:10]

Session creations since subsystem startup or last reset 5

Current session counts (estab/half-open/terminating) [Link]
Maxever session counts (estab/half-open/terminating) [Link]
Last session created [Link]
Last statistic reset never
Last session creation rate 3
Maxever session creation rate 5
Last half-open session total 0

Copyright © 2011 Internetwork Expert [Link]

- 31 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Class-map: class-default (match-any)

Match: any
Drop (default action)
0 packets, 0 bytes
Zone-pair: OUTSIDE_TO_INSIDE

Service-policy inspect : OUTSIDE_TO_INSIDE_PMAP

Class-map: INSIDE_HTTP_SERVER_CMAP (match-all)

Match: access-group name INSIDE_HTTP_SERVER_ACL
Match: protocol tcp
Inspect
Session creations since subsystem startup or last reset 0
Current session counts (estab/half-open/terminating) [Link]
Maxever session counts (estab/half-open/terminating) [Link]
Last session created never
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 0
Last half-open session total 0

Class-map: TRACEROUTE_RESPONSES_CMAP (match-all)

Match: access-group name TRACEROUTE_RESPONSES_ACL
Pass
2 packets, 72 bytes

Class-map: class-default (match-any)

Match: any
Drop
21 packets, 1020 bytes

Routing traffic (BGP) is not affected by the zone-based firewall configuration, as

by default traffic to the “self” zone is permitted. Next, telnet to BB3 and try pinging
any inside host (notice that in the real exam you don’t have access to the
backbone routers):

BB3>ping [Link]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

BB3>ping [Link]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Copyright © 2011 Internetwork Expert [Link]

- 32 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

 Note

You can ping R1 since the traffic is classified as destined to the firewall itself
(zone self), not as transit.

Task 2.2 Solution

SW1:
access-list 160 deny tcp any any eq 139
access-list 160 permit ip any any

interface FastEthernet0/24
ip access-group 160 in

Task 2.2 Breakdown

Lateral thinking is part of the CCIE exam challenge. It is common to see a series
of requirements accompanied by some restrictions, which commonly excluded
the most obvious configuration option. Use system-thinking and keep in mind the
whole path that traffic in question may take. This often includes various layer2-
only paths, such as VLANs that may cross multiple switches. Every such
“transparent” node could be used for traffic filtering as well, leveraging port or
VLAN ACLs.

Task 2.3 Solution

R6:
!
! Reflexive ACL
!
ip access-list extended TO_BB1
permit tcp any any reflect MIRROR
permit udp any any reflect MIRROR
permit icmp any any

!
! Permit BGP & ICMP response to R6
!
ip access-list extended FROM_BB
permit tcp host [Link] eq bgp host [Link]
permit tcp host [Link] host [Link] eq bgp
permit icmp any any echo-reply
evaluate MIRROR
!
interface Virtual-Template 1
ip access-group FROM_BB1 in
ip access-group TO_BB1 out

!
! Reflexive ACL expiration timeout
!
ip reflexive-list timeout 120

Copyright © 2011 Internetwork Expert [Link]

- 33 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 2.3 Breakdown

Reflexive ACLs were the first “pseudo-stateful” firewall technique introduced into
IOS, if you don’t count the “established” option as stateful inspection. While it is
not very popular due to very limited scalability it is still a candidate to testing in
the exam. Keep in mind that there is no way to really “inspect” local traffic with
reflexive ACLs. You either need to open explicit pin-holes in the inbound ACL for
returning local packets or use a local policy-map redirecting all local traffic to a
loopback interface: this make the locally-originated traffic re-appear as transit. Be
careful with the PBR trick though as any local traffic with TTL of 1 (e.g.
PIM/OSPF hello packets) will be dropped once it re-enters the router via a
Loopback. Always use an access-list combined with the local-policy route-map.

Task 2.3 Verification

Sessions from the “inside” of R6 are permitted across the filtering device:

Rack4R3#ping [Link]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/28 ms

Rack4R3#telnet [Link]
Trying [Link] ... Open
BB1>

Notice how the temporary access-list entries are created to allow the returning
traffic.

Rack4R6#show ip access-lists
...
Reflexive IP access list MIRROR
permit tcp host [Link] eq telnet host [Link] eq 11024 (230
matches) (time left 113)
Extended IP access list FROM_BB1
permit tcp host [Link] eq bgp host [Link] (3 matches)
permit tcp host [Link] host [Link] eq bgp
permit icmp any any echo-reply (5 matches)
evaluate MIRROR
Extended IP access list TO_BB1
permit tcp any any reflect MIRROR
permit udp any any reflect MIRROR
permit icmp any any (5 matches)

Copyright © 2011 Internetwork Expert [Link]

- 34 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Now verify that connections initiated from BB1 are blocked by the inbound
access list on the Virtual-Access interface.

BB1>ping [Link]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

BB1>telnet [Link]
Trying [Link] ...
% Destination unreachable; gateway or host down

Copyright © 2011 Internetwork Expert [Link]

- 35 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 3.1 Solution

R3:
!
! Enable NAT
!
interface FastEthernet0/1
ip nat inside
!
interface Serial1/1.345
ip nat outside

!
! Static route for the new network
!
ip route [Link] [Link] Null0

!
! ‘Create’ a new network to translate the local subnet
! and advertise it into OSPF to provide connectivity
!
router ospf 1
redistribute static subnets
!
ip nat inside source static network [Link] [Link] /24

R4:
interface Serial0/0.345
ip nat outside
!
interface Serial0/1
ip nat outside
!
interface FastEthernet0/1
ip nat inside

!
! Static route for the new network
!
ip route [Link] [Link] Null0

!
! We ‘create’ a new network to translate the local subnet
! and advertise it into OSPF to provide connectivity
!
router ospf 1
redistribute static subnets
!
ip nat inside source static network [Link] [Link] /24

Copyright © 2011 Internetwork Expert [Link]

- 36 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 3.1 Breakdown

Overlapping address spaces are common when connecting two private networks
to for an extra-net for example. There are two solutions to this problem: re-
numbering one of the sites or using NAT to create non-overlapping address
ranges. We use static network-based NAT, which is an equivalent of static NAT
mappings but covers network ranges as a whole. The overlapping network is
[Link]/24 and we create two different networks to mask the prefix at different
sites: [Link]/24 and [Link]/24. It would be enough to create just one extra
network, but it looks more symmetric to have two, one per site. The static NAT
entries are accompanied by static routes on every router, used to advertise newly
created subnets into OSPF – static network NAT statement does not create a
local static route by default. The overlapping subnets are never advertised in
OSPF and only the “masqueraded” networks are visible.

Task 3.1 Verification

Ping from SW1 to the translated network to verify connectivity:

Rack4SW1#ping [Link] source [Link]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
Packet sent with a source address of [Link]
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/102/104 ms

Rack4R3#show ip nat translations

Pro Inside global Inside local Outside local Outside global
icmp [Link]:2 [Link]:2 [Link]:2 [Link]:2
--- [Link] [Link] --- ---
--- [Link] [Link] --- ---

Rack4R4#show ip nat translations

Pro Inside global Inside local Outside local Outside global
icmp [Link]:2 [Link]:2 [Link]:2 [Link]:2
--- [Link] [Link] --- ---
--- [Link] [Link] --- ---

Copyright © 2011 Internetwork Expert [Link]

- 37 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 3.2 Solution

R5:
!
! PKI CA should be have its time synchronized with PKI clients
!
ntp master
!
! Enable PKI server on R5
!
crypto pki server INE1
issuer-name cn=INE,ou=Security
grant auto
no shutdown
%Some server settings cannot be changed after CA certificate
generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password: cisco1234

!
! The password above is arbitrary
!

R3 & R4: (shared configuration)

!
! Synchronize clocks on R3/R4 with R5 server
! in order for certificates to be valid:
!
ntp server [Link]

!
! Create RSA keys: configure domain-name first
!
ip domain-name [Link]
crypto key generate rsa general modulus 512

!
! Configure & authenticate the trustpoint for AAA/CA server
!
crypto ca trustpoint INE1
enrollment url [Link]
enrollment mode ra
crl optional
!
crypto ca authenticate INE1
crypto ca enroll INE1

!
! Common ISAKMP & IPsec settings
!
crypto isakmp policy 10
encr 3des
hash md5
!
crypto ipsec transform-set AES256 ah-md5-hmac esp-aes 256

Copyright © 2011 Internetwork Expert [Link]

- 38 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

R3:
!
! Traffic to encrypt
!
ip access-list extended VLAN41_TO_VLAN4
permit ip [Link] [Link] [Link] [Link]

!
! By using the looback interface as the source for ISAKMP exchange
! and IPSec packets tunneling
! we protect the communication against local physical
! interface failure
!
crypto map VPN local-address Loopback0
crypto map VPN 10 ipsec-isakmp
set peer [Link]
set transform-set AES256
match address VLAN41_TO_VLAN4
!
interface Serial1/1.345 point-to-point
crypto map VPN

R4:
!
! Traffic to encrypt
!
ip access-list extended VLAN4_TO_VLAN41
permit ip [Link] [Link] [Link] [Link]

!
! By using the Looback interface for ISAKMP exchange
! and IPSec packets tunneling
! we protect the communication against local physical
! interface failure
!
crypto map VPN local-address Loopback0
crypto map VPN 10 ipsec-isakmp
set peer [Link]
set transform-set AES256
match address VLAN4_TO_VLAN41
!
interface Serial0/0.345 point-to-point
crypto map VPN
!
interface Serial0/1
crypto map VPN

Copyright © 2011 Internetwork Expert [Link]

- 39 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 3.2 Breakdown

There are two options for creating the VPN here: using crypto maps that filter
traffic to encrypt or using Virtual Tunnel Interfaces between R3 and R4. We use
the crypto maps, even though the VTIs would be simpler. The reason being is the
fact that VTIs would require using an additional routing protocol to route the
protected networks over the VTI interface, or resorting to static routes. Using the
same protocol for VPN and underlying routing is also possible but not
recommended for healthy designs, as extra care need to be taken to protect
against routing loops.

The use of crypto-maps implies configuring access-lists to match the protected

traffic. In the IOS, NAT feature applies prior to encryption, so we match the post-
NAT “unique” networks. Notice that the use of VTIs make this order of operations
more clear: the traffic is first NAT’ed if NAT is enabled on the VTI and then
encapsulated in the tunnel.

The configurations are very symmetric on both R3 and R4, so you may
effectively use a notepad application to create one config, then copy it and
modify to match another router. In fact this is the recommended approach for
configuration almost anything in the CCIE exam.

By default, ISAKMP messages are sourced off the interface where the crypto-
map applies to. The same IP address is used in the outer header of the ESP-
encapsulated traffic. Of course, thie makes the whole configuration rely on the
interace status. Using the command crypto map <XXX> local-address
allows for changing the source for ISKAMP/ESP [Link] making IPsec
configuration independent of the point of attachment. This achieves the
necessary level of the IPsec redundancy.

Once again, we would like to point out the advantage of VTI-based configuration:
they are easier to read and understand, the could be bound to a logical interface,
and they offer significantly more logical approach to configuring IPsec. However,
still many deployments are based on “legacy” crypto-map syntax and therefore
you need to know it. Not to mention that the ASA firewall still does not support
the concept of VTI tunnel.

Lastly, a few words on digital-certificates based authentication. This is the most

scalable authentication technique, provided that PKI infrastructure is in place.
The lab exam only tests your knowledge of IOS PKI, which is straight-forward to
set up. A common mistake though is forgetting to synchronize time between the
CA and its clients. In the exam you may have various clock discrepancies –
either intentaional or non-international and they may affect proper authentication.
Always looks out for possible firewall fitering that may break SCEP
communications. Even if you have already requested certificates, make sure you
have opening for the SCEP when applying any possible firewall rules later.

Copyright © 2011 Internetwork Expert [Link]

- 40 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 3.2 Verification

Here is a sample dialog demonstrating the CA enrollment procedure.

Rack4R4(config)#crypto ca enroll INE1

%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the
configuration.
Please make a note of it.

Password: cisco
Re-enter password: cisco

% The fully-qualified domain name in the certificate will be:

[Link]
% The subject name in the certificate will be: [Link]
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the
fingerprint.

Rack4R4(config)#
Fingerprint: AE11D86D 62E91A73 5C430955 739EC1A3
%CRYPTO-6-CERTRET: Certificate received from Certificate Authority

Rack4R4#show crypto ca certificates

Certificate
Status: Available
Certificate Serial Number: 0x3
Certificate Usage: General Purpose
Issuer:
cn=INE
ou=Security
Subject:
Name: [Link]
hostname=[Link]
Validity Date:
start date: [Link] UTC Jul 31 2010
end date: [Link] UTC Jul 31 2011
Associated Trustpoints: INE1

Copyright © 2011 Internetwork Expert [Link]

- 41 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

CA Certificate
Status: Available
Certificate Serial Number: 0x1
Certificate Usage: Signature
Issuer:
cn=INE
ou=Security
Subject:
cn=INE
ou=Security
Validity Date:
start date: [Link] UTC Jul 31 2010
end date: [Link] UTC Jul 30 2013
Associated Trustpoints: INE1

Now check that protected network may ping each other and that traffic is actually
encrypted:

Rack4SW1#ping [Link] source vlan41

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
Packet sent with a source address of [Link]
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 209/209/210
ms

Rack4R3#show ip nat translations

Pro Inside global Inside local Outside local Outside
global
--- [Link] [Link] --- ---

Subnet translation:
Inside global Inside local Outside local Outside global /prefix
[Link] [Link] --- --- /24

Copyright © 2011 Internetwork Expert [Link]

- 42 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Rack4R3#show cry isakmp sa

dst src state conn-id slot
[Link] [Link] QM_IDLE 1 0

Rack4R3#show cry 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

C-id Local Remote I-VRF Encr Hash Auth DH

Lifetime Cap.
1 [Link] [Link] 3des md5 rsig 1
[Link]

Rack4R3#show cry ipsec sa

interface: Serial1/1.345
Crypto map tag: VPN, local addr. [Link]

protected vrf:
local ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
remote ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
current_peer: [Link]:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 5, #recv errors 0

local crypto endpt.: [Link], remote crypto endpt.: [Link]

path mtu 1500, media mtu 1500
current outbound spi: 43910448
<snip>

Copyright © 2011 Internetwork Expert [Link]

- 43 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

Task 3.3 Solution

R2:
!
! Enable AAA and configure AAA list
! to prevent authentication on the console line.
!
aaa new-model
aaa authentication login CONSOLE none

!
! AAA list for local network authorizaion
! Required to apply ISAKMP authorization via
! local database
!
aaa authorization network EZVPN local

!
! Authentication list: ezVPN auth is local by default, but it does
! not hurt defining and using this list.
!
aaa authentication login EZVPN local

!
! Apply AAA list to the console
!
line console 0
login authentication CONSOLE

!
! ISAKMP policy to support Cisco VPN Clients
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2

!
! DPD Keepalives, enabled periodically
!
crypto isakmp keepalive 10 periodic

!
! Pool to allocate addresses for remote clients
!
ip local pool EZVPN_POOL [Link] [Link]

!
! Assign this pool to ISAKMP process, so that mode config may work
! with address assignment
!
crypto isakmp client configuration address-pool local VPN_POOL

Copyright © 2011 Internetwork Expert [Link]

- 44 -
CCIE Security Lab Workbook Vol II Solutions Guide for CCIEv3.0 Lab 1

!
! Split-tunneling Access-List
!
ip access-list extended SPLIT_TUNNEL
permit ip [Link] [Link] any

!
! Client configuration group
!
crypto isakmp client configuration group IELAB
key CISCO
dns [Link]
wins [Link]
domain [Link]
pool EZVPN_POOL
acl SPLIT_TUNNEL
!