ipexpert security volume 1 dsg v5.0 labs 1 4 decrypted

IPexpert’s Detailed Solution Guide

Volume 1: Labs 1-4for the Cisco® CCIE™ Security v3.0 Lab Exam

IPexpert Detailed Solution Guide for the Cisco® CCIETM

Security v3.0 Lab Exam Volume 1 – Introduction

V1800 Copyright © 2010 by IPexpert, Inc. All Rights Reserved. 1

IPexpert’s Detailed Solution Guide for the Cisco® CCIE

TM Security v3.0 Lab Exam

Volume 1: Labs 1-4

Before We Begin This product is part of the IPexpert "Blended Learning Solution™" that provides CCIE candidates with a comprehensive training program. For information about the full solution, contact an IPexpert Training Advisor today. Telephone: +1.810.326.1444 Email: [email protected] Congratulations! You now possess one of the ULTIMATE CCIE

TM Security Lab preparation

resources available today! This resource was produced by senior engineers, technical instructors, and authors boasting decades of internetworking experience. Although there is no way to guarantee a 100% success rate on the CCIE

TM Security Lab exam, we feel VERY confident that your chances of passing the

Lab will improve dramatically after completing this industry-recognized Workbook! At the beginning of each section, you will be referred to a diagram of the network topology. All sections utilize the same physical topology, which can be rented at www.ProctorLabs.com.

Technical Support from IPexpert and your CCIE community!

IPexpert is proud to lead the industry with multiple support options at your disposal free of charge. Our online communities have attracted a membership of nearly 20,000 of your peers from around the world! At CCIEBlog.com you can keep up to date with everything IPExpert does, as well as start your own CCIE-focused blog or simply add your existing blog to our directory so your peers can find you. At OnlineStudyList.com, you may subscribe to multiple “SPAM-free”, CCIE-focused email lists.

mailto:[email protected]

http://www.proctorlabs.com/

http://blog.ipexpert.com

http://www.ccieblog.com/

http://www.onlinestudylist.com/

Volume 1 – Introduction IPexpert Detailed Solution Guide for the Cisco® CCIETM

Security v3.0 Lab Exam

2 Copyright © 2010 by IPexpert, Inc. All Rights Reserved. V1800

Feedback Do you have a suggestion or other feedback regarding this book or other IPexpert products? At IPexpert, we look to you – our valued clients – for the real world, frontline evaluation that we believe is necessary to improve continually. Please send an email with your thoughts to [email protected] or call 1.866.225.8064 (international callers dial +1.810.326.1444). In addition, when you pass the CCIE

TM Lab exam, we want to hear about it! Email your CCIE

TM number to

[email protected] and let us know how IPexpert helped you succeed. We would like to send you a gift of thanks and congratulations.

Additional CCIETM Preparation Material IPexpert, Inc. is committed to developing the most effective Cisco CCIE

TM R&S, Security, Service

Provider, and Voice Lab certification preparation tools available. Our team of certified networking professionals develops the most up-to-date and comprehensive materials for networking certification, including self-paced workbooks, online Cisco hardware rental, classroom training, online (distance learning) instructor-led training, audio products, and video training materials. Unlike other certification-training providers, we employ the most experienced and accomplished team of experts to create, maintain, and constantly update our products. At IPexpert, we are focused on making your CCIE

TM Lab

preparation more effective.

A message from the Author(s): The scenarios covered in this workbook were developed by Security CCIEs to help you prepare for the Cisco CCIE Security laboratory. It is strongly recommended that you use other reading materials in addition to this workbook. Training is not the CCIE Security workbook objective. The intent of these labs is to test your knowledge and ability of implementing Cisco Enterprise Voice Solutions. Time management is very important, if you get stuck on a lab scenario be sure to write it down. Formulate a Checklist for skipped sections and then return to those sections once you have gone through the entire lab. Be sure to revisit the questions that you do not understand. For more information on the CCIE Security lab, please visit http://www.cisco.com/go/ccie and click on the link for Voice on the top-right of the page. Helpful Hints

Keep It Simple, try to avoid any extra work (example: adding descriptions)

Always reference everything from the Documentation Website: http://www.cisco.com/web/psa/products/index.html

Save your router configurations often (wr is the quickest command)

When you complete major sections test your work. No one is perfect and we all forget to enter a command here and there.



http://www.cisco.com/go/ccie

http://www.cisco.com/web/psa/products/index.html


Security v3.0 Lab Exam Volume 1 – EULA


IPEXPERT END-USER LICENSE AGREEMENT

END USER LICENSE FOR ONE (1) PERSON ONLY

IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS,

DO NOT OPEN OR USE THE TRAINING MATERIALS.

This is a legally binding agreement between you and IPEXPERT, the “Licensor,” from whom you have licensed the IPEXPERT training materials (the “Training Materials”). By using the Training Materials, you agree to be bound by the terms of this License, except to the extent these terms have been modified by a written agreement (the “Governing Agreement”) signed by you (or the party that has licensed the Training Materials for your use) and an executive officer of Licensor. If you do not agree to the License terms, the Licensor is unwilling to license the Training Materials to you. In this event, you may not use the Training Materials, and you should promptly contact the Licensor for return instructions. The Training Materials shall be used by only ONE (1) INDIVIDUAL who shall be the sole individual authorized to use the Training Materials throughout the term of this License.

Copyright and Proprietary Rights

The Training Materials are the property of IPEXPERT, Inc. ("IPEXPERT") and are protected by United States and International copyright laws. All copyright, trademark, and other proprietary rights in the Training Materials and in the Training Materials, text, graphics, design elements, audio, and all other materials originated by IPEXPERT at its site, in its workbooks, scenarios and courses (the "IPEXPERT Information") are reserved to IPEXPERT.

The Training Materials cannot be used by or transferred to any other person. You may not rent, lease, loan, barter, sell or time-share the Training Materials or accompanying documentation. You may not reverse engineer, decompile, or disassemble the Training Materials. You may not modify, or create derivative works based upon the Training Materials in whole or in part. You may not reproduce, store, upload, post, transmit, download or distribute in any form or by any means, electronic, mechanical, recording or otherwise any part of the Training Materials and IPEXPERT Information other than printing out or downloading portions of the text and images for your own personal, non-commercial use without the prior written permission of IPEXPERT.

You shall observe copyright and other restrictions imposed by IPEXPERT. You may not use the Training Materials or IPEXPERT Information in any manner that infringes the rights of any person or entity.

Exclusions of Warranties

THE TRAINING MATERIALS AND DOCUMENTATION ARE PROVIDED “AS IS.” LICENSOR HEREBY DISCLAIMS ALL OTHER WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW THE LIMITATION OF INCIDENTAL DAMAGES OR LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY LASTS, SO THE ABOVE LIMITATIONS OR EXCLUSIONS MAY NOT APPLY TO YOU. This agreement gives you specific legal rights, and you may have other rights that vary from state to state.

Choice of Law and Jurisdiction

This Agreement shall be governed by and construed in accordance with the laws of the State of Michigan, without reference to any conflict of law principles. You agree that any litigation or other proceeding between you and Licensor in connection with the Training Materials shall be brought in the Michigan state or courts located in Port Huron, Michigan, and you consent to the jurisdiction of such courts to decide the matter. The parties agree that the United Nations Convention on Contracts for the International Sale of Goods shall not apply to this License. If any provision of this Agreement is held invalid, the remainder of this License shall continue in full force and effect.

Limitation of Claims and Liability

ANY ACTION ON ANY CLAIM AGAINST IPEXPERT MUST BE BROUGHT BY THE USER WITHIN ONE (1) YEAR FOLLOWING THE DATE THE CLAIM FIRST ACCRUED, OR SHALL BE DEEMED WAIVED. IN NO EVENT WILL THE LICENSOR‟S LIABILITY UNDER, ARISING OUT OF, OR RELATING TO THIS AGREEMENT EXCEED THE AMOUNT PAID TO LICENSOR FOR THE TRAINING MATERIALS. LICENSOR SHALL NOT BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, REGARDLESS OF WHETHER LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. WITHOUT LIMITING THE FOREGOING, LICENSOR WILL NOT BE LIABLE FOR LOST PROFITS, LOSS OF DATA, OR COSTS OF COVER.

Volume 1 – EULA IPexpert Detailed Solution Guide for the Cisco® CCIETM



Entire Agreement

This is the entire agreement between the parties and may not be modified except in writing signed by both parties.

U.S. Government - Restricted Rights

The Training Materials and accompanying documentation are “commercial computer Training Materials” and “commercial computer Training Materials documentation,” respectively, pursuant to DFAR Section 227.7202 and FAR Section 12.212, as applicable. Any use, modification, reproduction release, performance, display, or disclosure of the Training Materials and accompanying documentation by the U.S. Government shall be governed solely by the terms of this Agreement and shall be prohibited except to the extent expressly permitted by the terms of this Agreement.

IF YOU DO NOT AGREE WITH THE ABOVE TERMS AND CONDITIONS, DO NOT OPEN OR USE THE TRAINING MATERIALS AND CONTACT LICENSOR FOR INSTRUCTIONS ON RETURN OF THE TRAINING MATERIALS.


Security v3.0 Lab Exam Volume 1 – Table of Contents


IPexpert’s Detailed Solution Guide for the Cisco® CCIE

TM Security v3.0 Lab Exam

Volume 1: Labs 1-4

NOTE

You are encouraged to take advantage of the knowledge and support from your peers around the globe. Join ccieblog.com to journal your progress. And join onlinestudylist.com to get more community support and also official support from IPexpert.

Table of Contents

IPEXPERT END-USER LICENSE AGREEMENT........................................................... 3

Lab 1A: Configure Secure Networks using Cisco ASA Firewalls ............................. 7

Lab 1A Detailed Solutions ......................................................................................................................... 8

Lab 1B: Troubleshoot Cisco ASA Firewalls .............................................................. 55

Lab 1B Detailed Solutions ....................................................................................................................... 56

Lab 2A: Configure Secure Networks using Cisco IOS Firewalls........................... 113

Lab 2A Detailed Solutions ..................................................................................................................... 114

Lab 2B: Troubleshoot Cisco IOS Firewalls ............................................................. 193

Lab 2B Detailed Solutions ..................................................................................................................... 194

Lab 3A: Configure IPS to Mitigate Network Threats ............................................... 273

Lab 3A Detailed Solutions ..................................................................................................................... 274

Lab 3B: Troubleshoot IPS Configuration ................................................................ 363

Lab 3B Detailed Solutions ..................................................................................................................... 364

Lab 4A: Configure Cisco VPN Solutions ................................................................. 415

Lab 4A Detailed Solutions – Part I ........................................................................................................ 416 Lab 4A Detailed Solutions – Part II ....................................................................................................... 463

Lab 4B: Troubleshoot Virtual Private Networks ..................................................... 529

Lab 4B Detailed Solutions – Part I ........................................................................................................ 530 Lab 4B Detailed Solutions – Part II ....................................................................................................... 573

http://www.ccieblog.com/


Volume 1 – Table of Contents IPexpert Detailed Solution Guide for the Cisco® CCIETM



This page left intentionally blank.


Security v3.0 Lab Exam Volume 1 – Lab 1A - Solutions


Lab 1A: Configure Secure Networks using

Cisco ASA Firewalls

Estimated Time to Complete: 4 Hours

NOTE: Please reference your Security Workbook for all diagrams and tables.

Volume 1 – Lab 1A - Solutions IPexpert Detailed Solution Guide for the Cisco® CCIETM



1.0 Cisco ASA Configuration Detailed Solutions

Lab 1A Detailed Solutions

1.1 Basic ASA Configuration

Create 2 subinterfaces off of E0/0, E0/0.7 and E0/0.8. VLAN24 is the primary untagged VLAN.

Assign them names and security levels as follows:

Eth0/0.8 – DMZ8 – 50 Eth0/0.7 – DMZ7 - 25

Configure the switch port to allow VLAN7 and VLAN8 to communicate to the rest of the network.

Assign the following addresses to the ASA and bring all interfaces up:

Inside – 10.2.2.10/24 Outside – 192.1.24.10/24 DMZ7 – 10.7.7.10/24 DMZ8 – 10.8.8.10/24

Configuration

ASA1

hostname asa

!

interface Ethernet0/1

nameif inside

ip address 10.2.2.10 255.255.255.0 standby 10.2.2.11

no shutdown

!


nameif outside


no shutdown

!

interface Ethernet0/0.7

vlan 7

nameif DMZ7

security-level 50


no shutdown

!


vlan 8

nameif DMZ8

security-level 50


no shutdown

Although not required here, we will include the standby address for the failover section later on.




Cat3

interface FastEthernet0/10

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 7,8,24

switchport trunk native vlan 24

switchport mode trunk

spanning-tree portfast trunk

!


switchport access vlan 2

switchport mode access

spanning-tree portfast

Verification

We can test connectivity with simple ping tests. Keep in mind here that you don‟t have any routing enabled, so keep it simple and just test to what is directly connected.

asa(config-subif)# ping 10.2.2.5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.2.2.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms




!!!!!





!!!!!


asa(config-if)# ping 192.1.24.4



!!!!!


asa(config-if)#

End Verification

1.2 Routing with RIP

Run RIP version 2 as your routing protocol on R5 and the ASA.

Configure authentication using a key of 1 and key-string of ipexpert.

Inject a default route to R5.

RIP should receive routes from R5. Make sure you can ping the ACS Server

Do not send RIP updates out any other interface.

Configuration




ASA1

router rip

version 2

net 10.0.0.0

default-information originate

passive-interface default

no passive-interface inside

no auto-summary


rip authentication mode md5

rip authentication key ipexpert key_id 1

R5

router rip

version 2

network 10.0.0.0


no passive-interface FastEthernet0/1.2

no auto-summary

!

key chain RIP

key 1

key-string ipexpert

interface FastEthernet0/1.2

ip rip authentication mode md5

ip rip authentication key-chain RIP

Verification

You can verify on R5 by looking at the routing table:

R5#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.2.2.10 to network 0.0.0.0

55.0.0.0/24 is subnetted, 1 subnets

C 55.55.55.0 is directly connected, Loopback1

C 5.0.0.0/8 is directly connected, Loopback0


R 10.99.99.0 [120/1] via 10.2.2.10, 00:00:02, FastEthernet0/1.2



C 10.2.2.0 is directly connected, FastEthernet0/1.2


R* 0.0.0.0/0 [120/1] via 10.2.2.10, 00:00:04, FastEthernet0/1.2

R5#

End Verification




1.3 Running OSPF as the Routing Protocol on the ASA

Run OSPF as your routing protocol between the ASA and R8. Advertise all networks.

Inject a Default Route to R8

Configure authentication using a key of 1 and key-string of ipexpert. Do not use the AREA authentication command under the ospf process on either.

Configuration

ASA1

router ospf 1

network 10.8.8.10 255.255.255.255 area 0

default-information originate always

!


ospf authentication message-digest

ospf message-digest-key 1 md5 ipexpert

R8


ip ospf message-digest-key 1 md5 ipexpert

ip ospf authentication message-digest

Verification

You can verify on R8 by looking at the routing table for the “O*E2” route. This is what is injected with the default information originate command. When you use this command without the “always” keyword there must be a default route configured on the ASA in order to allow OSPF to inject one into the routing process. With the “always” option the route is sent even if the ASA doesn‟t have a default route configured.

R8#sh ip route






ia - IS-IS inter area, * - candidate default, U - per-user static

route





C 10.8.8.0 is directly connected, FastEthernet0/1

O*E2 0.0.0.0/0 [110/1] via 10.8.8.10, 00:00:02, FastEthernet0/1

R8#

End Verification




1.4 Run EIGRP on the ASA

Configure EIGRP 200 on the ASA and R7.

Make sure R7 can reach the rest of the Topology.


Configuration

ASA1

router eigrp 200

no auto-summary

network 10.7.7.0 255.255.255.0

!


summary-address eigrp 200 0.0.0.0 0.0.0.0

authentication key eigrp 200 ipexpert key-id 1

authentication mode eigrp 200 md5

R7

key chain eigrp

key 1

key-string ipexpert


ip authentication mode eigrp 200 md5

ip authentication key-chain eigrp 200 eigrp

Verification

To verify here you simply want to view the routing table. If you don‟t see any routes, then I would start looking for EIGRP neighbors. If you did this the other way around, you would check for neighbors then routes, adding a second command. To save time I look for routes and if they are there I move on. We won‟t be able to do connectivity connection tests yet as NAT, ACL‟s, and complete routing aren‟t ready.

R7(config-router)#do sh ip route







route





C 10.7.7.0 is directly connected, FastEthernet0/1

D* 0.0.0.0/0 [90/28416] via 10.7.7.10, 03:48:08, FastEthernet0/1

R7(config-router)#

End Verification




1.5 Static Default Routes

Configure a default route to R2.

If R2 is unavailable R4 should be used as a backup.

The Target should be GigabitEthernet0/1 interface of R2 This should run indefinitely The timeout should be 1000 MS The operation should repeat every three seconds.

Configuration

ASA

sla monitor 1

type echo protocol ipIcmpEcho 192.1.24.2 interface outside

timeout 1000

frequency 3

!

sla monitor schedule 1 life forever start-time now

track 1 rtr 1 reachability

route outside 0 0 192.1.24.2 track 1

route outside 0 0 192.1.24.4 5

Solution Explanation and Clarifications

The configuration seen here uses the Static Route Tracking, Service Level Agreement (SLA) monitor process. The ASA associates a static route with a target that you define and then it monitors it using ICMP. If an echo reply is not received, the object is considered down, and the associated route is removed from the routing table. Then the previously configured “backup” route is used in place of the route that is removed. While the backup route is in use, the SLA monitor operation continues to try to reach the monitoring target. Once the target is available again, the first route is replaced in the routing table, and the backup route is removed. This doesn‟t require any special configuration to replace the primary route because its chosen based on its metric, which is why the secondary route uses a metric that is higher. If they were the same you would load balance rather than chose a primary.

When you access the sla monitor you configure the timeout and frequency before you schedule it. Once its scheduled you have to stop it to change the timers. Refer to the http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806e880b.shtml for more information.

Verification

You can verify that the proper route is installed by looking at the routing table, in this case the default route is to R2 and that‟s what you want. To verify the SLA will function you could fail the interface of R2 by shutting it down.

Tip: Configure timeout and frequency before scheduling.

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/ip.html#wp1090243

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806e880b.shtml

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806e880b.shtml




asa(config)# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP



E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, 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


R 5.0.0.0 255.0.0.0 [120/1] via 10.2.2.5, 0:00:02, inside

C 192.1.24.0 255.255.255.0 is directly connected, outside

D 7.0.0.0 255.0.0.0 [90/131072] via 10.7.7.7, 0:01:33, DMZ7

O 8.0.0.0 255.0.0.0 [110/11] via 10.8.8.8, 0:00:40, DMZ8

R 10.1.1.0 255.255.255.0 [120/1] via 10.2.2.5, 0:00:01, inside

C 10.8.8.0 255.255.255.0 is directly connected, DMZ8


C 10.2.2.0 255.255.255.0 is directly connected, inside

C 10.99.99.0 255.255.255.0 is directly connected, FAILINT

S* 0.0.0.0 0.0.0.0 [1/0] via 192.1.24.2, outside

asa(config)#

Then look at the configuration of the SLA Monitor. The timeout defaults to 5000 and the frequency is 60 seconds. Here we can see that it has been modified to meet the requirements.

asa(config)# sh sla monitor configuration

SA Agent, Infrastructure Engine-II

Entry number: 1

Owner:

Tag:

Type of operation to perform: echo

Target address: 192.1.24.2

Interface: outside

Number of packets: 1

Request size (ARR data portion): 28

Operation timeout (milliseconds): 1000

Type Of Service parameters: 0x0

Verify data: No

Operation frequency (seconds): 3

Next Scheduled Start Time: Start Time already passed

Group Scheduled : FALSE

Life (seconds): Forever

Entry Ageout (seconds): never

Recurring (Starting Everyday): FALSE

Status of entry (SNMP RowStatus): Active

Enhanced History:

By viewing the Operational State you can see operational state is “OK.”




asa(config)# sh sla monitor operational-state

Entry number: 1

Modification time: 23:03:01.903 UTC Tue Apr 7 2009

Number of Octets Used by this Entry: 1480

Number of operations attempted: 3

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: 23:05:01.904 UTC Tue Apr 7 2009

Latest operation return code: OK

RTT Values:

RTTAvg: 1 RTTMin: 1 RTTMax: 1

NumOfRTT: 1 RTTSum: 1 RTTSum2: 1

Finally fail R2‟s interface by shutting it down and then view the routing table and operation-state of the static route tracking on the ASA:

R2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R2(config)#int Gi0/1

R2(config-if)#shut

R2(config-if)#

*Apr 8 05:28:49.891: %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed

state to administratively down

*Apr 8 05:28:50.891: %LINEPROTO-5-UPDOWN: Line protocol on Interface

GigabitEthernet0/1, changed state to down

Go back to the ASA and verify the tracked route has changed.







area




R 5.0.0.0 255.0.0.0 [120/1] via 10.2.2.5, 0:00:02, inside


D 7.0.0.0 255.0.0.0 [90/131072] via 10.7.7.7, 0:42:15, DMZ7

O 8.0.0.0 255.0.0.0 [110/11] via 10.8.8.8, 1:04:16, DMZ8

R 10.1.1.0 255.255.255.0 [120/1] via 10.2.2.1, 0:00:24, inside




S* 0.0.0.0 0.0.0.0 [5/0] via 192.1.24.4, outside




asa(config)# sh sla monitor operational-state

Entry number: 1

Modification time: 23:08:22.129 UTC Tue Apr 7 2009




Current seconds left in Life: Forever

Operational state of entry: Active



Timeout occurred: TRUE


Latest RTT (milliseconds): NoConnection/Busy/Timeout

Latest operation start time: 23:22:58.130 UTC Tue Apr 7 2009

Latest operation return code: Timeout

RTT Values:

RTTAvg: 0 RTTMin: 0 RTTMax: 0

NumOfRTT: 0 RTTSum: 0 RTTSum2: 0

asa(config)#

Don‟t forget to “no shut” R2 before moving on.

End Verification

1.6 Configure ASA2 for failover

Configure ASA2 as the failover unit for ASA1.

ASA1 is the primary Use interface Ethernet0/3 Use message encryption with a key of ipexpert If a failover occurs don‟t drop the users http connections If a switch needs configured do so. You may use any IP addressing you want for the failover interface as long as it

doesn‟t overlap with another IP range that is in use.

Make sure interface states are monitored.

Configuration

ASA1

failover lan unit primary

failover lan interface FAILINT Ethernet0/3

failover interface ip FAILINT 10.99.99.10 255.255.255.0 standby

10.99.99.20

failover key ipexpert

failover link FAILINT

failover replication http

!


no shut

monitor DMZ7

monitor DMZ8

failover

By Default only physical interfaces are monitored for state. We need to add the sub-interfaces to meet the requirements.




Cat3





!

Cat4






!





!





ASA2

failover lan unit secondary


failover key ipexpert

failover interface ip FAILINT 10.99.99.10 255.255.255.0 standby

10.99.99.20


no shutdown

!

failover


Configuring failover is a very common practice to provide redundancy and a very probable test subject.

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/failover.html




Verification

asa(config)#show failover

Failover On

Failover unit Primary

Failover LAN Interface: FAILINT Ethernet0/3 (up)

Unit Poll frequency 1 seconds, holdtime 15 seconds

Interface Poll frequency 5 seconds, holdtime 25 seconds

Interface Policy 1

Monitored Interfaces 2 of 250 maximum


Version: Ours 8.0(4), Mate 8.0(4)

Last Failover at: 23:49:20 UTC Apr 7 2009

This host: Primary - Active

Active time: 65 (sec)

slot 0: ASA5510 hw/sw rev (1.1/8.0(4)) status (Up Sys)

Interface outside (192.1.24.10): Normal (Waiting)

Interface DMZ7 (10.7.7.10): Normal (Not-Monitored)


Interface inside (10.2.2.10): Normal (Waiting)

slot 1: empty

Other host: Secondary - Standby Ready







slot 1: empty

Stateful Failover Logical Update Statistics

Link : FAILINT Ethernet0/3 (up)

Stateful Obj xmit xerr rcv rerr

General 16 0 8 0

sys cmd 8 0 8 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 8 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 7 8

Xmit Q: 0 26 103

asa(config)#




Then by pinging thru the ASA from R5 to R2 and failing it. To do this you can turn on ICMP inspect, do the ping, shut the inside interface of the ASA, and then view the ping to see if its still going. Also, because R2 doesn‟t know how to get to R5 you can create a temorary static route on R2.

asa(config)# fixup proto icmp

INFO: converting 'fixup protocol icmp ' to MPF commands

asa(config)#

R2(config)# ip route 10.2.2.0 255.255.255.0 192.1.24.10

R2(config)#

R5#ping 10.2.2.10 repeat 100000000



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Now go reload the primary:

asa(config-if)# reload

System config has been modified. Save? [Y]es/[N]o:

Cryptochecksum: 884c10be 9f86efb1 35ccd3f9 d0f2d6dc

3494 bytes copied in 3.380 secs (1164 bytes/sec)

Proceed with reload? [confirm]

And check the ping again. You should see a few timeouts. Be careful or you might miss them!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

You can also do a show failover on the Secondary (ASA2):

asa(config)#

Switching to Active

Tip: A Number of MPF commands can be configured for you by using the old fixup command.




asa(config)# show failover

Failover On

Failover unit Secondary




Interface Policy 1





This host: Secondary - Active







slot 1: empty

Other host: Primary - Failed


slot 0: ASA5510 hw/sw rev (1.1/8.0(4)) status

(Unknown/Unknown)

Interface outside (0.0.0.0): Unknown (Waiting)

Interface DMZ7 (0.0.0.0): Unknown (Not-Monitored)


Interface inside (0.0.0.0): Unknown (Waiting)

<--- More --->

Remove the static route from R2:

R2(config)#no ip route 10.2.2.0 255.255.255.0 192.1.24.10

Restore the Primary to active state:

asa> en

Password:

asa# conf t

**** WARNING ****

Configuration Replication is NOT performed from Standby unit to Active unit.

Configurations are no longer synchronized.

asa(config)#

asa(config)# failover active

Switching to Active

asa(config)#

asa(config)#

asa(config)#

Leave the ICMP because it will be called for in a later task.

End Verification




1.7 Translations and Connections with inbound ACLs

Use a NAT/PAT combination to allow inside networks to outside using the following range of address: 192.1.24.51 – 192.1.24.150.

Configure the pool such that if all addresses in the pool are exhausted translations will still occur.

R2 should be able to Manage R7 using Telnet. R2 should see R7 as 192.1.24.7. Allow the appropriate filtering on the ASA.


R4 should be able to web browse to 192.1.24.8.

R4 should be able to web browse to 192.1.24.8 on port 8080. This should direct the connection to R8‟s loopback address.

If an outside user SSHs or HTTPs‟ (SSL) to 192.1.24.10, he should be redirected to 10.7.7.7. Allow the appropriate entries in your access-list.

R7 should be able to ping R2 and R4‟s Loopback addresses using its own IP Address 10.7.7.7. You cannot use the static command to accomplish this. You are allowed to create 2 routes each on R2 and R4.

Configuration

ASA1

nat (i) 1 0 0

global (o) 1 192.1.24.51-192.1.24.149

global (o) 1 192.1.24.150

static (DMZ7,o) 192.1.24.7 10.7.7.7

static (DMZ8,o) tcp 192.1.24.8 80 10.8.8.8 80

static (DMZ8,o) tcp 192.1.24.8 23 10.8.8.8 23

static (DMZ8,o) tcp 192.1.24.8 8080 8.8.8.8 80

!

static (DMZ7,o) tcp interface 443 10.7.7.7 443

static (DMZ7,o) tcp interface 22 10.7.7.7 22

!

access-l NAT_EXEMPT permit ip host 10.7.7.7 host 4.4.4.4

access-l NAT_EXEMPT permit ip host 10.7.7.7 host 2.2.2.2

!

nat (DMZ7) 0 access-list NAT_EXEMPT

!

access-l out_in permit tcp host 192.1.24.2 host 192.1.24.7 eq 23




access-l out_in permit tcp any host 192.1.24.10 eq 22

access-l out_in permit tcp any host 192.1.24.10 eq 443

!

access-group out_in in int outside

R2

ip route 10.7.7.7 255.255.255.255 192.1.24.10

ip route 4.4.4.4 255.255.255.255 192.1.24.4




R4

ip route 2.2.2.2 255.255.255.255 192.1.24.2

ip route 10.7.7.7 255.255.255.255 192.1.24.10

R7

crypto key generate rsa general modulus 1024

!

username ipexpert privilege 15 password ipexpert

!

ip http server

ip http secure-server

!

line vty 0 15

login local

R8

ip http server

!

line vty 0 15

privilege level 15

password ipexpert


This task is testing your ability to configure NAT in various ways. There is a combo of NAT, saving the last address of a Pool for use with PAT as well as Static translations with port redirection in use. You‟ll want to pay attention to when port redirection is used as it will scream at you if you try to create on after a standard static is configured. Never-the-less it still takes the command. I recommend paying special attention to the NAT that you are asked to configure.

Verification

Lets Test R2 to R7

R2(config)#do telnet 192.1.24.7

Trying 192.1.24.7 ... Open

User Access Verification

Username: ipexpert

Password:

R7#q

[Connection to 192.1.24.7 closed by foreign host]

R2(config)#do ssh -l ipexpert 192.1.24.10

Password:

R7#q


R2(config)#

SSH requires a username and password to login. So be sure to Create one on R7 to allow authentication.




R7(config)#access-list 101 permit tcp any host 10.7.7.7 eq 443

R7(config)#do debug ip packet 101

IP packet debugging is on for access list 101

R7(config)#

R2(config)#do telnet 192.1.24.10 443

Trying 192.1.24.10, 443 ... Open


R2(config)#

R7# *May 1 15:15:15.533: IP: tableid=0, s=192.1.24.2 (FastEthernet0/1), d=10.7.7.7 (FastEthernet0/1), routed via RIB

*May 1 15:15:15.533: IP: s=192.1.24.2 (FastEthernet0/1), d=10.7.7.7 (FastEthernet0/1), len 44, rcvd 3

*May 1 15:15:15.537: IP: tableid=0, s=192.1.24.2 (FastEthernet0/1), d=10.7.7.7 (FastEthernet0/1), routed via RIB










R7#

And R4 to R8

R4#telnet 192.1.24.8

Trying 192.1.24.8 ... Open


Password:

R8#q


R4#



R8(config)#do debug ip packet 101

IP packet debugging is on for access list 101

R8(config)#

R8#q


R4#telnet 192.1.24.8 80

Trying 192.1.24.8, 80 ... Open

get

HTTP/1.1 400 Bad Request

Date: Fri, 01 May 2009 15:46:00 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request





R4#

R8# *May 1 15:44:52.865: IP: s=192.1.24.4 (FastEthernet0/1), d=10.8.8.8, len 44, input feature, MCI Check(59), rtype 0, forus FALSE,

sendself FALSE, mtu 0



*May 1 15:44:52.869: IP: s=192.1.24.4 (FastEthernet0/1), d=10.8.8.8, len 44, stop process pak for forus packet

*May 1 15:44:52.869: IP: s=192.1.24.4 (FastEthernet0/1), d=10.8.8.8, len 40, input feature, MCI Check(59), rtype 0, forus FALSE,










R8#

R4#telnet 192.1.24.8 8080

Trying 192.1.24.8, 8080 ... Open

get


Date: Fri, 01 May 2009 15:47:07 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request


R4#

R8(config)# *May 1 15:47:05.521: IP: s=192.1.24.4 (FastEthernet0/1), d=8.8.8.8, len 44, input feature, MCI Check(59), rtype 0, forus FALSE,


*May 1 15:47:05.521: IP: tableid=0, s=192.1.24.4 (FastEthernet0/1), d=8.8.8.8 (Loopback0), routed via RIB

*May 1 15:47:05.521: IP: s=192.1.24.4 (FastEthernet0/1), d=8.8.8.8, len 44, rcvd 4



















R8(config)#

To verify you can enable debugs on R4 and then ping from R7. You‟ll want to make sure the source is 10.7.7.7 by looking at the debug output.

R4#debug ip icmp

ICMP packet debugging is on

R4#

Over to R7:




R7#ping 4.4.4.4



!!!!!


R7#

And Back to R4:

R4#

*Apr 8 07:13:39.610: ICMP: echo reply sent, src 4.4.4.4, dst 10.7.7.7




End Verification

1.8 Access List and Object Groups on the ASA

Your company will be putting in application servers. One of the application servers will be in DMZ7 with an IP Address of 10.7.7.21, and the other will be in DMZ8 with an IP Address of 10.8.8.22.

Create a static translation for them on the outside so that 10.7.7.21 is seen as 192.1.24.21 on the outside and 10.8.8.22 is seen as 192.1.24.22 on the outside.

These servers are going to be accessed by partner organizations. The IP Addresses of these partner organizations are as follows:

205.15.25.0/24 207.215.1.0/24 210.208.15.16/28 211.0.15.32/27 192.1.150.112/28

The applications on the servers are as follows:

TFTP FTP HTTP SMTP DNS Custom Application at UDP 50000 ICMP

Allow all of the partner organizations access to all the applications on the 2 servers. You are allowed to add 1 line in the Access List to accomplish this.




Configuration

ASA1

static (DMZ7,out) 192.1.24.21 10.7.7.21

static (DMZ8,out) 192.1.24.22 10.8.8.22

!

object-group network DMZ_Servers

network-object host 192.1.24.22


!

object-group network Partners

network-object 205.15.25.0 255.255.255.0

network-object 207.215.1.0 255.255.255.0

network-object 210.208.15.16 255.255.255.240

!

network-object 211.0.15.32 255.255.255.224

network-object 192.1.150.112 255.255.255.240

!

object-group service ALL_SVC

service-object tcp eq 21



service-object udp eq 69




service-object icmp

!

access-list out_in extended permit object-group ALL_SVC object-group

Partners object-group DMZ_Servers


This is one of those tasks that appear to be more work than it is. The test here is using object groups to keep ACL configurations to a minimum. You can configure Object-Groups and insert them into an ACL simplifying the ACL configuration. You can create objects for Services, Protocols, Networks, and ICMP types. Recently the ability to create a Service object group was introduced that allows the combination of TCP/UDP and ICMP-type objects all under one group name. This is an effective way to add multiple services of different types to the ACL with very few statements, which is what this task is looking for.

Verification

You can verify that it allowed exactly what you wanted with a show access-list command. Since the servers are not actually there you can try to access them but it will fail. Just be sure that the entries meet the requirements of the task.

End Verification

Tricky: You have ICMP traffic, TCP traffic, and UDP traffic. You could use an icmp-type object-group as well as a service type for TCP and UDP but you can only create one entry in the ACL. For this use the new service-type object group.

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/traffic.html#wp1053224

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/traffic.html#wp1053224




1.9 Authentication Proxy

The AAA server is located at 10.1.1.100. Configure the AAA server to communicate with the ASA using TACACS+ and a key of ipexpert. Configure a user named ASAuser with a password of ipexpert.

All outbound Telnet and HTTP Requests have to authenticate against the AAA server. The Username to use is ASAuser with a password of ipexpert. Use the same username and password for all authentication passwords.

Enable Telnet on R5 with a password of ipexpert.

Make R5 appear as 192.1.24.15 on the outside. Allow R4 FastEthernet0/1 as well as Loopback0 to telnet into R5 through the ASA. Make the ACL as specific as possible.

All Inbound Telnet to R5 should be authenticated. Explicitly exclude the Loopback of R4.

All outbound TFTP and RSH traffic should be authenticated against the AAA server. Use 192.1.24.9 for the virtual address and telnet as the authentication protocol.

R2 should be able to Telnet into 192.1.24.15 (R5‟s translated address). Configure R5 to allow R2 to telnet into port 3025. Configure the ACL as needed to allow communication.

Authenticate all Telnet traffic to port 3025 from R2 to R5 using the AAA Server.

Note: Use Clear uauth on the ASA after every authentication step to clear the authentication.

Configuration

Make Sure you have a route on the ACS Server: Start > Run > type cmd

Check routes using the command route print.




Once you know you can get there go into ACS and add the ASA: Network Configuration > AAA Clients > Add Add ASA as a AAA Client Add the IP address of the ASA Use the shared secret key of ipexpert. Click Submit and Restart

Now configure the user under the User Setup page: User Setup>Add/Edit Enter a Username Enter a Password Click Submit




Now you can configure the ASA to communicate to the ACS server and test it:

ASA1

aaa-server AAA protocol tacacs+

aaa-server AAA (inside) host 10.1.1.100 ipexpert

!

access-list outbound_aaa permit tcp any any eq 23


access-list outbound_aaa permit udp any any eq 69


!

aaa authentication match outbound_aaa inside AAA

!

static (i,o) 192.1.24.15 10.2.2.5

!





!

access-l outside_AAA_in deny tcp host 4.4.4.4 host 192.1.24.15 eq 23

access-l outside_AAA_in permit tcp any host 192.1.24.15 eq 3025



!

aaa authentication match outside_AAA_in outside AAA

!

virtual telnet 192.1.24.9

!

static (i,o) 192.1.24.9 192.1.24.9

R5

line vty 0 4

password ipexpert

login

line vty 5

rotary 25

password ipexpert

login




Verification

Test the AAA Authentication of http traffic first using the web browser on the ACS Server. To test, turn on the HTTP server of R2 and browse to it from the ACS Server. Watch the routes on the ACS Server you may need to add a static route to the 192.1.24.0/24 network on the ACS Server:

In this example you can see the HTTP Authentication from the ASA. Once you authenticate here it is normal to see a second authentication prompt asking for the level_15 access the the router. We are not worries about that here so just check that the user was authenticated on the ASA using the show uauth command.

asa(config)# sh uauth

Current Most Seen

Authenticated Users 1 1

Authen In Progress 0 1

user 'ASAuser' at 10.1.1.100, authenticated

absolute timeout: 0:05:00

inactivity timeout: 0:00:00

asa(config)#

Test the inbound AAA authentication by performing telnet from R4‟s loopback and R4‟s F0/1 interfaces.

R4#telnet 192.1.24.15

Trying 192.1.24.15 ... Open

Username: ASAuser

Password:


Password:

R5>




Check it on the ASA:

asa(config)# sh uauth

Current Most Seen






asa(config)#

Clear uauth to test the loopback:

asa(config)# clear uauth

Telnet from the loopback:

R4#telnet 192.1.24.15 /source-interface L0

Trying 192.1.24.15 ... Open


Password:

R5>

To test the RSH and TFTP authentication you will need to setup a TFTP server.

Setup R2 to serve the file:

R2(config)#do copy run flash:tftp.txt

Destination filename [tftp.txt]?


R2(config)#tftp-server flash:tftp.txt

R2(config)#

Then turn loggin on for the ASA:

asa(config)# logging on

asa(config)# logging console 7

Then TFTP from R5:

Note: this should fail. The reason it fails is explained next.

R5#copy tftp flash:tftp.txt

Address or name of remote host []? 192.1.24.2

Source filename []? tftp.txt


Accessing tftp://192.1.24.2/tftp.txt...

%Error opening tftp://192.1.24.2/tftp.txt (Timed out)

By examining the ASA logging output you can see that AAA was started for user “???”, but R5 was never prompted:

%ASA-6-302015: Built outbound UDP connection 3145 for outside:192.1.24.2/69

(192.1.24.2/69) to inside:10.2.2.5/56632 (192.1.24.15/56632)

Tip: Sometimes debugging on a device in the path can answer questions you would otherwise not get.




%ASA-6-109001: Auth start for user '???' from 10.2.2.5/56632 to 192.1.24.2/69

%ASA-3-109023: User from 10.2.2.5/56632 to 192.1.24.2/69 on interface inside

using udp must authenticate before using this service

From R5, telnet to the virtual telnet address and authenticate. Once authenticated try the tftp again and it should succeed:

R5#telnet 192.1.24.9

Trying 192.1.24.9 ... Open

LOGIN Authentication

Username: ASAuser

Password: ipexpert

Authentication Successful


R5#


Address or name of remote host [192.1.24.2]?

Source filename [tftp.txt]?



Loading tftp.txt from 192.1.24.2 (via FastEthernet0/1): !

[OK - 1973 bytes]


R5#

To test the authentication for port 3025 on R5 first try to telnet directly to R5 on port 3025 from R2.

R2#telnet 192.1.24.15 3025

Trying 192.1.24.15, 3025 ... Open

Error: Must authenticate before using this service.


Then do the virtual telnet first, followed by the telnet to R5.

Note: If you have misconfigured virtual telnet this will fail. You need a static for the virtual telnet address in order for this to work properly. Because the earlier task was an outbound connection you wouldn‟t have noticed this. Add the following if you haven‟t already:

asa(config)#static (i,o) 192.1.24.9 192.1.24.9

Then test:

Now that the Authentication is Successful you should be able to do your TFTP.




R2#telnet 192.1.24.9

Trying 192.1.24.9 ... Open


Username: ASAuser

Password: ipexpert



R2#telnet 192.1.24.15 3025

Trying 192.1.24.15, 3025 ... Open


Password:

R5>

End Verification

1.10 Configure Filtering on the ASA

You want to block Java and ActiveX applets from anyone.

Ensure that the ACS is never filtered.

There is a WebSense server located at 10.1.1.101.

Before a HTTP request is allowed to go out, the ASA should verify with the WebSense server if the website is allowed or not. Configure the ASA such that traffic will be allowed to pass if the WebSense server is down.

Also use this WebSense server to filter FTP traffic from the 10.1.1.0/24 network to the Loopback network of R4. Don‟t allow FTP in any interactive FTP applications.

Configuration

ASA1

url-server (inside) host 10.1.1.101

filter activex except 10.1.1.100 255.255.255.255 0 0

filter activex 80 0 0 0 0

filter java except 10.1.1.100 255.255.255.255 0 0

filter java 80 0 0 0 0

filter url http 0 0 0 0 allow

filter ftp 21 10.1.1.0 255.255.255.0 4.4.4.4 255.255.255.255

interact-block




Verification

You could get creative in testing this task. Anything that has a java applet on port 80 could be accessed through the ASA to test. As for the url filtering, you could download a trial of Wensense and install it on the ACS Server. If you have handy with Websense you could blacklist the loopback of R2. In this case, we will simply verify the confugration. Sometimes, because of time, the best verification is just viewing what you have configured and then moving on.

asa(config)# sh run filter

filter java except 10.1.1.100 255.255.255.255 0.0.0.0 0.0.0.0

filter activex except 10.1.1.100 255.255.255.255 0.0.0.0 0.0.0.0

filter activex 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

filter java 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow

filter ftp 21 10.1.1.0 255.255.255.0 4.4.4.4 255.255.255.255 interact-block

asa(config)#

End Verification

1.11 Using the Modular Policy Framework

Partner Networks will be accessing SMTP Services on the DMZ. Create a policy such that SMTP is checked for the domain badspammer.com. If this domain is found reset the connection. Do not log.

Ensure that R4 and R5 can establish an authenticated BGP connection thru the ASA.

In the future the router team will enable BGP authentication. Use the MPF to make sure that TCP option 19 is not cleared. Disable Random Sequence Numbering of BGP traffic. Note: Do Not Change the default BGP configuration on R4 and R5.

There is a new IP telephony deployment that will be installed between the private network and a new branch that has not been deployed yet. The tunnel-group for the branch is IPXPRT_BRANCH_A. Ensure that traffic destine for this branch that is VoIP traffic receives the lowest latency possible as it leave the ASA. Set the queue-limit to twice the default and the tx-ring limit to three.

In addition to the configured QOS policy you have applied, policy ICMP traffic in such a way that icmp is not allowed more than 56 Kbps on the outside interface.

Configuration

ASA1

regex BADSPAMMER "badspammer.com"

!

access-l SMTP permit tcp any any eq smtp

:

class smtp

match access-l SMTP

:

policy-map type inspect esmtp SMTP_INSPECT

parameters

match sender-address regex BADSPAMMER

reset




:

policy-map OUTSIDE

class smtp

inspect esmtp SMTP_INSPECT

!

static (i,o) 5.5.5.5 5.5.5.5 netmask 255.255.255.255

:

tcp-map BGP

tcp-options range 19 19 allow

:

access-list BGP permit tcp any any eq 179

class BGP

match access-list BGP

:

policy-map global_policy

class BGP

set connection advanced-options BGP

set connection random-sequence-number disable

:


!

!

priority-queue outside

:

queue-limit 2048

:

tunnel-g IPXPRT_BRANCH_A type ipsec-l2l

:

class VOIP

match tunnel-group IPXPRT_BRANCH_A

match dscp ef

:

policy-map OUTSIDE

class VOIP

priority

!

access-l ICMP_POLICY permit icmp any any

:

class ICMP_POLICY

match access-l ICMP_POLICY

:

policy-map OUTSIDE

class ICMP_POLICY

inspect icmp

police output 56000


There is a lot going on in this task. You are asked to configure the SMTP filtering using the Modular Policy Framework. To match “badspammer” you will need to create a regular expression. An example of regualr expressions can be found in Cisco Document ID 100535. While this page is geared towards filtering URLs you can still use if to create regular expressions.

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/inspect.html#wp1224614

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/inspect.html#wp1224614

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080940e04.shtml




This task also requires the use of MPF to allow BGP through the ASA. You can find an explaination of that in Document 6500. The thing to remember here is that with BGP using MD5 authenticaiton you must disable random-sequencing and allow TCP option 19.

When asked to priority queue for voice you are supposed to match against traffic for a specific tunnel-group. This tunnel-group doesn‟t exist so you have to create it. Under normal circumstances they tunnel-group would be there if you actually had a branch. Creating a tunnel-group so that you can enter the commands nessecary to fulfill the requirements of the task is perfectly fine. You don‟t have to build a VPN. Once the tunnel-group is there you can match on it in the class-map. When you configure the policy-map and add the command to priority-queue on the outside, you may get an error message indicating that you don‟t have priority queueing enabled. You simply need to enable it and come back into the Policy-map. If you remember to enable priority queueing first your ok. That is where you would modify the queue limit and tx-ring.

The tx-ring-limit and the queue-limit that you specify affect both the higher priority low-latency queue and the best-effort queue. The tx-ring-limit is the number of either type of packets allowed into the driver before the driver pushes back to the queues sitting in front of the interface to let them buffer packets until the congestion clears. In general, you can adjust these two parameters to optimize the flow of low-latency traffic. The default tx-ring-limit is 128 packets. The default queue-limit is 1024

Because queues are not of infinite size, they can fill and overflow. When a queue is full, any additional packets cannot get into the queue and are dropped. This is tail drop. To avoid having the queue fill up, you can use the queue-limit command to increase the queue buffer size.

Rate-limiting ICMP is also tested in this section. Simply create and ACL to match ICMP, match it in a class-map and in the policy-map have it policed.

Verification

To verify the SMTP configuration you can ensure that it is enabled in the policy:

asa(config-pmap-c)# sh service-policy int OUTSIDE

Interface outside:

Service-policy: OUTSIDE

Class-map: smtp

Inspect: esmtp SMTP_INSPECT, packet 0, drop 0, reset-drop 0

Class-map: ICMP_POLICY

Output police Interface outside:

cir 56000 bps, bc 1750 bytes

If you want to go to the trouble to verify this is working you can install http://www.softstack.com/freesmtp.html which is a free SMTP server onto the ACS Server and setup Outlook express on XP Workstation and send an email from XP Workstation.

Add the following on ASA1

static (inside,outside) 192.1.24.25 10.1.1.100 netmask 255.255.255.255

access-list out-in permit tcp host 192.1.24.100 host 192.1.24.25 eq 25

Change the XP IP address to 192.1.24.100.

From the XP Windows Command Prompt type:

netsh interface ip set address name="Student NIC - ok to change - watch

routes!" static 192.1.24.100 255.255.255.0

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a008009487d.shtml

http://www.softstack.com/freesmtp.html




To install freesmtp server on ACS just go through the installation process you don‟t need to setup anything. It is just important for ACS to listen on the port.

To setup outlook setup an email account. Display name doesn‟t matter. Set the email address to [email protected] and incoming POP3 server is 192.1.24.25 and outgoing SMTP server is 192.1.24.25. Username and password again don‟t matter as we don‟t actually need to send the email.

Now create a message and send it to an address, for example [email protected]

You will get the following output on ASA1 if it working properly.

asa# debug esmtp 255

SMTP: Initial state:1




SMTP: State changed to:5

SMTP: REPLY - Reply len:4, match_len:4, reply_re_state:31

SMTP: REPLY - match id:28





SMTP: VERB - Match_len:4, cmd_re_state:51

SMTP: VERB - match id:5

SMTP: VERB - Cmd len:4


SMTP: CMD PARAM - Cmd len:10, match_len:6, cmd_re_state:4

SMTP: CMD PARAM - match id:27






SMTP: CHECK EHLO REPLY - eid:8

SMTP: REPLY DONE - eid: 8
































Reset connection

asa#

If it is not working you will get the following output showing that it allows the traffic thru.

asa#





















































SMTP: State kept, no EID to use!!!











































SMTP: HDR SIG - hdr len:61, line len:61, match_len:61,cmd_re_state:1

SMTP: HDR - match id:50


























































SMTP: DATA SIG - data len:473, line len:6, match_len:6, cmd_re_state:0




SMTP: DATA SIG - data len:475, line len:8, match_len:2, cmd_re_state:1

SMTP: DATA SIG - match id:55

















ciscoasa(config)#

BGP should be easily verifiable via the BGP state on R4 and R5.

R4(config-router)#do show ip bgp summary

BGP router identifier 4.4.4.4, local AS number 1

BGP table version is 3, main routing table version 3

2 network entries using 234 bytes of memory

2 path entries using 104 bytes of memory

3/2 BGP path/bestpath attribute entries using 372 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 710 total bytes of memory

BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

5.5.5.5 4 1 28 30 3 0 0 00:18:58 1

R4(config-router)#do sh ip bgp

BGP table version is 3, local router ID is 4.4.4.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 44.44.44.0/24 0.0.0.0 0 32768 i

*>i55.55.55.0/24 5.5.5.5 0 100 0 i

R4(config-router)#

R5(config)#do show ip bgp summary








Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory



Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

4.4.4.4 4 1 27 27 3 0 0 00:18:30 1

R5(config)#do sh ip bgp


Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,




*>i44.44.44.0/24 4.4.4.4 0 100 0 i

*> 55.55.55.0/24 0.0.0.0 0 32768 i

R5(config)#




There are two ways that we could have created the BGP class map. One was to use “match protocol tcp eq bgp” or by using the ACL as we did. The nice thing about using the ACL is that we can see when packets are being matched.

asa(config-cmap)# show access-list BGP

access-list BGP; 1 elements

access-list BGP line 1 extended permit tcp any any eq bgp (hitcnt=1) 0xc8d9833d

asa(config-cmap)#

To verify the priority queueing view the service policy:

asa(config-pmap-c)# sh service-policy int OUTSIDE

Interface outside:


Class-map: smtp





conformed 99 packets, 11286 bytes; actions: transmit

exceeded 1 packets, 114 bytes; actions: drop

conformed 0 bps, exceed 0 bps

Class-map: VOIP

Priority:

Interface outside: aggregate drop 0, aggregate transmit 0

Class-map: class-default

Default Queueing

asa(config-pmap-c)#

To verify the ICMP policing, ping from R5 with a repeat count of 100. You should see some drops:

R5#ping 192.1.24.4 re 100



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!.!!!!!!!!!!!!!!!!


R5#

Then view the service-policy on the outside interface to verify that they were policed:




asa(config)# show service-policy interface outside

Interface outside:


Class-map: smtp








Class-map: VOIP

Priority:



Default Queueing

asa(config-pmap-c)#

End Verification

1.12 Remote Management of the ASA

Allow the ACS Server to Manage the ASA Firewall. The ACS Server should be able to use either ssh or telnet for management.

The user authentication should be done based on TACACS+

The ACS Server should be already setup for some of this communication. You may modify whatever is necessary to accomplish this task.

The username for ssh management is SSHuser with a password of ipexpert.

Ensure that the SSH idle time is as low as possible.

The username for telnet management is 23user with a password of ipexpert.

Configuration

Start by configuring the ASA for SSH and Telnet. ASA1

domain-name ipexpert.com

cry key gen rsa

ssh 10.1.1.100 255.255.255.255 inside

telnet 10.1.1.100 255.255.255.255 inside

ssh timeout 1

aaa authentication ssh console AAA

aaa authentication telnet console AAA

Next configure the AAA Server with the required usernames:




User Setup>Add/Edit Add the user SSHuser Add the user 23user




Verification

Use Putty to test both SSH and Telnet to the ASA:




End Verification

1.13 Enabling the ASA firewall as a DHCP Server

Configure the ASA firewall as a DHCP Server.

Assign IP configuration on the inside interface based on the following information:

IP ADDRESS : 10.2.2.51 – 10.2.2.100 WINS ADDRESS : 10.2.2.135 DNS ADDRESS : 150.50.24.53 DEFAULT GATEWAY : 10.2.2.10 LEASE TIME : 3 Days

Add the XP Workstation to VLAN2 to Test.

Note: I recommend you add a persistent route back to yourself on the XP workstation to make sure you don‟t lose connectivity due to two default gateways.




Configuration

ASA1

dhcpd address 10.2.2.51-10.2.2.100 inside

dhcpd wins 10.2.2.135

dhcpd dns 150.50.24.53

dhcpd lease 259200

dhcpd enable inside

Cat3



Verification

asa(config)# sh dhcpd state

Context Configured as DHCP Server

Interface outside, Not Configured for DHCP

Interface DMZ7, Not Configured for DHCP


Interface inside, Configured for DHCP SERVER

asa(config)#

Next connect to the XP Workstation and test to see if it can get a DHCP address. As the note states you can add a persistent route back to yourself to make sure you don‟t loose connectivity.

C:\Documents and Settings\Administrator>route add –p <your public IP address>

mask 255.255.255.255 10.200.5.254

C:\Documents and Settings\Administrator>netsh interface ip show address

Configuration for interface "OUTSIDE NIC - DO NOT CHANGE!!!"

DHCP enabled: No

IP Address: 10.200.5.12

SubnetMask: 255.255.255.0

Default Gateway: 10.200.5.254

GatewayMetric: 0

InterfaceMetric: 0

Configuration for interface "Student NIC - ok to change - watch routes!"

DHCP enabled: No

IP Address: 192.1.49.100


InterfaceMetric: 0

C:\Documents and Settings\Administrator>netsh interface ip set address

name="Student NIC - ok to change - watch routes!" source=dhcp

Ok.






DHCP enabled: No

IP Address: 10.200.5.12



GatewayMetric: 0

InterfaceMetric: 0


DHCP enabled: Yes

InterfaceMetric: 0

C:\Documents and Settings\Administrator>ipconfig

Windows IP Configuration

Ethernet adapter OUTSIDE NIC - DO NOT CHANGE!!!:

Connection-specific DNS Suffix . :

IP Address. . . . . . . . . . . . : 10.200.5.12

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.200.5.254

Ethernet adapter Student NIC - ok to change - watch routes!:


IP Address. . . . . . . . . . . . : 10.2.2.51

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.2.2.10

C:\Documents and Settings\Administrator>

asa(config)# show dhcpd binding

IP address Hardware address Lease expiration Type

10.2.2.51 0100.0c29.960f.ac 259010 seconds Automatic

asa(config)#

End Verification




1.14 Controlling Threats

An administrator has recently determined that the network is subject to a nasty Scan attack. Enable the ASA to detect scan attacks and automatically shun the identified attackers.

Do not shun the ACS Server.

Configuration

ASA1

threat-detect scanning-thre shun except ip 10.1.1.100 255.255.255.255


Basic Threat Detection is turned on by default. This task is specific to configuring threat detection to identify scanning threats. This means you will have to do a little work. The command to start with is:

threat-detection scanning-threat [shun [except {ip-address ip_address

mask | object-group network_object_group_id}]]

Notice from the syntax there is an “except” option, which works out great since you were told not to shun the ACS Server. Configure the ASA as follows:

The shun keyword automatically terminates a host connection when the security appliance identifies the host as an attacker, in addition to sending the system log message. The default is 3600 seconds (1 hour).

Verification

You can use the show threat-detection shun command to verify that the ACS is not shunned.

asa(config)# show threat-detection shun

Shunned Host List:

asa(config)#

You can view devices that have been identified using the show threat-detection scanning-threat attacker command.

Also, you can view the threat detection statistics:

asa(config)# show threat-detection statistics

Top Name Id Average(eps) Current(eps) Trigger Total

events

asa(config)#

End Verification




1.15 Application-Aware Inspection

IM is becoming an issue in the workplace. Specifically a host 10.1.1.86 has been leaking confidential information via yahoo messenger. Create a policy that will reset the connection for this host only if Yahoo Messenger is used. Do not allow ANY yahoo services. Apply this policy to the Inside interface.

Watch HTTP connections to the ACS. If there are any protocol violations you should reset the connection. Also, ensure that the ACS server appears to be an Apache 1.1 server regardless of what it really is.

Configuration

ASA1

access-l NO_IM permit ip host 10.1.1.86 any

!

class-map imblock

match access-l NO_IM

!

policy-map type inspect im impolicy

parameters

match protocol yahoo-im

reset

!

policy-map IM

class imblock

inspect im impolicy

!

service-policy IM in inside

!

!

access-l HTTP_TO_ACS permit tcp any host 192.1.24.100 eq www

!

class-map type inspect http POST_METHOD

match request method post

!

policy-map type inspect http MY_HTTP_MAP

parameters

protocol-violation action drop-connection

spoof-server "Apache 1.1"

class POST_METHOD

drop-connection log

!

class-map HTTP_TO_ACS

match access-list HTTP_TO_ACS

!

policy-map OUTSIDE

class HTTP_TO_ACS

inspect http MY_HTTP_MAP


Start with the policy for IM. You need to create an ACL to match the 10.1.1.86 address since it was the one specified in the task. Next create a class-map to match that user. Create a Layer 7 policy-map to inspect im traffic, specifically the yahoo-im protocol. When you match this protocol use the reset command under the parameters option. You could also use a drop-connection and




log option but the task asked us to reset. Next create a Layer 3/4 policy-map to match the user in the class imblock. When matched, inspect the traffic with the impolicy. Assign it to the interface using the service-policy command.

You would next apply a policy for the HTTP to ACS.

Verification

After the IM policy is applied verify with a show service-policy command:

asa(config)# show service-policy interface inside

Interface inside:

Service-policy: IM

Class-map: imblock

Inspect: im impolicy, packet 0, drop 0, reset-drop 0

asa(config)#

To Verify the HTTP Inspection you applied use the show-service-policy command also. You can be specific to the interface:

asa(config-pmap-c)# show service-policy interface outside

Interface outside:


Class-map: smtp








Class-map: VOIP

Priority:


Class-map: HTTP_TO_ACS

Inspect: http MY_HTTP_MAP, packet 0, drop 0, reset-drop 0


Default Queueing

asa(config-pmap-c)#

End Verification




Technical Verification and Support

To verify your configurations please review the Volume 1 Detailed Solution Guide that you received along with this Workbook. You can also find this document in the eBook section of your www.IPexpert.com account.

Support is also available in the following ways:

IPexpert Support: www.OnlineStudyList.com

IPexpert Blog: blog.ipexpert.com

ProctorLabs Hardware Support: [email protected]

http://www.ipexpert.com/


http://ipexpert.ccieblog.com/



Security v3.0 Lab Exam Volume 1 – Lab 1B - Solutions


Lab 1B: Troubleshoot

Cisco ASA Firewalls



Volume 1 – Lab 1B - Solutions IPexpert Detailed Solution Guide for the Cisco® CCIETM



1.0 Cisco ASA Troubleshooting Detailed Solutions

Lab 1B Detailed Solutions

Pre-Configuration Troubleshooting

We are given basic layer 2 connectivity, IP addressing, and routing preconfigured in this lab. Let‟s first check on the configuration for these things to make sure they are working as they should be. My suggestion is to start from the layer2 up.

Sw3 looks a little funny:

Sw3#sh vlan brief

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Fa0/1, Fa0/3, Fa0/6, Fa0/7

Fa0/8, Fa0/9, Fa0/12, Fa0/16

Fa0/17, Fa0/18, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Gi0/1, Gi0/2

2 VLAN0002 active Fa0/11, Fa0/15

24 VLAN0024 active Fa0/4, Fa0/10

99 VLAN0099 active Fa0/13

1002 fddi-default act/unsup

1003 token-ring-default act/unsup

1004 fddinet-default act/unsup

1005 trnet-default act/unsup

Sw3#

Here fa0/10 is assigned to vlan 24. Taking a look at the interface configuration you can see that it is an access-port, but in our first task we are to create subinterfaces on the ASA e0/0. If we do that, this port will need to be a dot1q trunk, not an access-port. Let‟s change that now:

Sw3#conf t


Sw3(config)#int fa0/10

Sw3(config-if)#swi trun encaps dot1q

Sw3(config-if)#swi mo tr

Sw3(config-if)#

*Mar 1 02:15:58.072: %LINEPROTO-5-UPDOWN: Line protocol on Interface

FastEthernet0/10, changed state to down

Sw3(config-if)#

*Mar 1 02:16:01.100: %LINEPROTO-5-UPDOWN: Line protocol on Interface

FastEthernet0/10, changed state to up

This is good but later we will run into a problem with the main e0/0 interface of the ASA. The main interface of the ASA is on the same subnet as R2 and R4. These routers are on vlan 24, therefore the native vlan on Sw3 interface fa0/10 needs to be vlan 24.




Sw3(config-if)#

Sw3(config-if)#swi trunk native vlan 24

Sw3(config-if)#do sh int trunk

Port Mode Encapsulation Status Native vlan

Fa0/5 on 802.1q trunking 1






Port Vlans allowed on trunk

Fa0/5 2

Fa0/10 24

Fa0/19 1-4094

Fa0/20 1-4094

Fa0/23 1-4094

Fa0/24 1-4094

Port Vlans allowed and active in management domain

Fa0/5 2

Fa0/10 24

Fa0/19 1-2,24,99

Fa0/20 1-2,24,99

Fa0/23 1-2,24,99

Fa0/24 1-2,24,99

Port Vlans in spanning tree forwarding state and not pruned

Fa0/5 2

Fa0/10 24

Fa0/19 1-2,24,99


Fa0/20 none

Fa0/23 1-2,24,99

Fa0/24 none

Sw3(config-if)#

Now E0/0 on the ASA should have no problems communicating with the Routers on the outside interface.

Next, it would be good to check Sw4:

Sw4#sh vlan brief


---- -------------------------------- --------- -------------------------------

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4

Fa0/5, Fa0/6, Fa0/9, Fa0/12

Fa0/14, Fa0/15, Fa0/16, Fa0/17

Fa0/18, Fa0/19, Fa0/20, Fa0/21

Fa0/22, Gi0/1, Gi0/2

2 VLAN0002 active Fa0/11

24 VLAN0024 active

99 VLAN0099 active

1002 fddi-default act/unsup

1003 token-ring-default act/unsup

1004 fddinet-default act/unsup

1005 trnet-default act/unsup

Sw4#




Sw4#sh run int f0/13

Building configuration...

Current configuration : 109 bytes

!





end

Sw4#

What we find on Sw4 is that there is a vlan we don‟t see in the diagram, vlan 19. Researching the port configuration you see that the port it is assigned to goes to port e0/3 on ASA2. The same port on Sw3 goes to e0/3 on ASA1. These two ASAs are going to be configured for failover on this interface. Looking back to the output from Sw3, port fa0/13 is in vlan 99 and this port is in vlan 19. This will break our failover configuration so lets change this to VLAN 99 like Sw3:

Sw4#conf t


Sw4(config)#int f0/13

Sw4(config-if)#swi acc vlan 99

Sw4(config-if)#

Now that Layer 2 looks ok we can move on to the Basic configuration.

End Pre-Configuration Troubleshooting

1.1 Basic ASA Configuration

Create 2 subinterfaces off of E0/0, E0/0.7 and E0/0.8. VLAN24 is the primary untagged VLAN.

Assign them names and security levels as follows:

Eth0/0.8 – DMZ8 – 50 Eth0/0.7 – DMZ7 - 25

Configure the switch port to allow VLAN7 and VLAN8 to communicate to the rest of the network.

Assign the following addresses to the ASA and bring all interfaces up:

Inside – 10.2.2.10/24 Outside – 192.1.24.10/24 DMZ7 – 10.7.7.10/24 DMZ8 – 10.8.8.10/24

Verification/Troubleshooting

For verification of this task simply check the interfaces of the ASA to ensure they are properly addressed, then ping the connected devices.




asa(config)# sh ip

System IP Addresses:

Interface Name IP address Subnet mask Method

Ethernet0/0 outside 192.1.24.10 255.255.255.0 manual

Ethernet0/0.7 DMZ7 10.7.7.10 255.255.255.0 manual


Ethernet0/1 inside 10.2.2.10 255.255.255.0 manual

Ethernet0/3 FAILINT 10.99.99.10 255.255.255.0 unset

Current IP Addresses:

Interface Name IP address Subnet mask Method

Ethernet0/0 outside 192.1.24.10 255.255.255.0 manual



Ethernet0/1 inside 10.2.2.10 255.255.255.0 manual

Ethernet0/3 FAILINT 10.99.99.10 255.255.255.0 unset

asa(config)#

According to this the IP addresses are correct. Let‟s ping the connected devices:

asa(config)# ping 192.1.24.2



No route to host 192.1.24.2

Success rate is 0 percent (0/1)

asa(config)#

Uh, oh! No route to host. Lets look at the interface:

asa(config)# sh int e0/0

Interface Ethernet0/0 "outside", is administratively down, line protocol is

up

Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec

Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)

MAC address 0017.9527.51e0, MTU 1500

IP address 192.1.24.10, subnet mask 255.255.255.0

4136 packets input, 614882 bytes, 251 no buffer

Received 464 broadcasts, 0 runts, 0 giants

228 input errors, 0 CRC, 0 frame, 228 overrun, 0 ignored, 0 abort

0 L2 decode drops

3963 packets output, 812262 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collisions, 0 deferred

0 lost carrier, 0 no carrier

input queue (curr/max packets): hardware (0/9) software (0/0)

output queue (curr/max packets): hardware (0/17) software (0/0)

Traffic Statistics for "outside":

0 packets input, 0 bytes

0 packets output, 0 bytes

0 packets dropped

1 minute input rate 0 pkts/sec, 0 bytes/sec

1 minute output rate 0 pkts/sec, 0 bytes/sec

1 minute drop rate, 0 pkts/sec




asa(config)#




So there is a problem. Let‟s enable the port and test ping again. To play it safe, better check e0/1 as well. If it‟s down, enable it.


Interface Ethernet0/1 "inside", is administratively down, line protocol is up



asa(config)#

asa(config)# int e0/0

asa(config-if)# no shut

asa(config-if)# int e0/1


asa(config-if)#

asa(config-if)#




?????


asa(config-if)#

asa(config-if)#




!!!!!





?????





?????


asa(config-if)#

As you can tell, R1 appears to be ok, but R2, R7 and R8 cant be reached. Test R2 to R4 first. If they can ping each other then look at the vlans again:

R2#ping 192.1.24.4



.!!!!

Since R2 can ping R4 it would lead me to believe that the issue is a vlan problem. First look at Switch 3, where ASA1 is connected. Notice that f0/10 is a trunk:




Sw3#sh int status

Port Name Status Vlan Duplex Speed Type

Fa0/1 notconnect 2 auto auto 10/100BaseTX









Fa0/10 connected trunk a-full a-100 10/100BaseTX

Fa0/11 connected 2 a-full a-100 10/100BaseTX










Fa0/21 disabled 1 auto auto 10/100BaseTX

Fa0/22 disabled 1 auto auto 10/100BaseTX



Sw3#

Next look at the configuration on the port:

Sw3#sh run int f0/10 | begin Fast






end

Sw3#

This is accurate. How about the trunks to the other switches?

Sw3#sh int fa0/19 trun

Port Mode Encapsulation Status Native vlan


Port Vlans allowed on trunk

Fa0/19 1-4094

Port Vlans allowed and active in management domain

Fa0/19 1-2,24,99


Fa0/19 1-2,24,99




Well, that looks to be good. What else would cause communication problems between devices on the same switch?

R4#sh ip arp

Protocol Address Age (min) Hardware Addr Type Interface

Internet 192.1.24.10 0 Incomplete ARPA

Internet 192.1.24.2 0 Incomplete ARPA

Internet 192.1.24.4 - 000a.b81a.5179 ARPA FastEthernet0/1

R4#

It looks like we are having problems resolving IP to MAC in ARP requests.

R4#debug arp

ARP packet debugging is on

R4#ping 192.1.24.2 repeat 3



*Apr 30 20:12:42.466: IP ARP: creating incomplete entry for IP address:

192.1.24.2 interface FastEthernet0/1

*Apr 30 20:12:46.466: IP ARP: sent req src 192.1.24.4 000a.b81a.5179,

dst 192.1.24.2 0000.0000.0000 FastEthernet0/1.






R4#

My first guess would be something has been done at Layer 2.

Sw3(config)#do sh run


<output truncated>

!

mac access-list extended HMM

permit any any 0x806 0x0

spanning-tree mode pvst

spanning-tree extend system-id

!

!

vlan access-map ARG 10

action drop

match mac address HMM

vlan access-map ARG 20

action forward

!

vlan filter ARG vlan-list 24

vlan internal allocation policy ascending

!

!

Sw3(config)#

Well that is a dirty trick…But it is a very plausable tactic to do for causing you a headache in the test. So the problem is that ARP (Ethertype 0x806) is being filtered with a vlan filter.




Sw3#conf t


Sw3(config)#no vlan filter ARG vlan-list 24

Sw3(config)#end

Sw3#

*Mar 1 01:48:52.225: %SYS-5-CONFIG_I: Configured from console by console

Now try the ping again from the ASA:




?!!!!


asa(config-if)#

Success.

You may have also noticed here that vlans 7 and 8, which are required for R7 and R8 are not configured on cat 3 and cat 4. You also need to test connectivity to R7 and R8 so you need to add these vlans before you move on. You may have caught this in the L2 verification.

Sw3(config)#vlan 7

Sw3(config-vlan)#vlan 8

Sw3(config-vlan)#exit




!!!!!





!!!!!





!!!!!





!!!!!





!!!!!


asa(config-if)#

End Verification/Troubleshooting




1.2 Routing with RIP

Run RIP version 2 as your routing protocol on R5 and the ASA.


Inject a default route to R5.

RIP should receive routes from R5.

Do not send RIP updates out any other interface.


R5#show ip route







route


Gateway of last resort is not set







R5#

R5#show ip protocol

Routing Protocol is "rip"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Sending updates every 30 seconds, next due in 15 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Redistributing: rip

Default version control: send version 2, receive version 2

Interface Send Recv Triggered RIP Key-chain

FastEthernet0/1.2 2 2 RIP

Automatic network summarization is not in effect

Maximum path: 4

Routing for Networks:

5.0.0.0

10.0.0.0

Passive Interface(s):

FastEthernet0/0

FastEthernet0/1

FastEthernet0/1.10

Serial0/1/0

Serial0/2/0

SSLVPN-VIF0

Loopback0

Passive Interface(s):

VoIP-Null0




Routing Information Sources:

Gateway Distance Last Update

Distance: (default is 120)

Routing Protocol is "bgp 1"



IGP synchronization is disabled

Automatic route summarization is disabled

Neighbor(s):

Address FiltIn FiltOut DistIn DistOut Weight RouteMap

4.4.4.4

Maximum path: 1



Distance: external 20 internal 200 local 200

R5#

asa(config-if)# sh run router rip

!

router rip

network 10.0.0.0


no passive-interface inside

default-information originate

version 2

no auto-summary

!

asa(config-if)#

asa(config-if)# debug rip

asa(config-if)#

RIP: received packet with MD5 authentication

RIP: ignored v2 packet from 10.2.2.5 (invalid authentication)

RIP: sending v2 update to 224.0.0.9 via inside (10.2.2.10)

RIP: build update entries

0.0.0.0 0.0.0.0 via 0.0.0.0, metric 1, tag 0

10.7.7.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0

10.8.8.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0

RIP: Update contains 3 routes

RIP: Update queued

RIP: Update sent via inside rip-len:112

asa(config-if)#

R5#debug ip rip

RIP protocol debugging is on

R5#

*Apr 23 04:07:40.429: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1.2

(10.2.2.5)

*Apr 23 04:07:40.429: RIP: build update entries

*Apr 23 04:07:40.429: 10.1.1.0/24 via 0.0.0.0, metric 1, tag 0

*Apr 23 04:07:44.077: 10.2.2.0/24 via 0.0.0.0, metric 1, tag 0

*Apr 23 04:07:50.441: RIP: received packet with MD5 authentication

*Apr 23 04:07:50.441: RIP: ignored v2 packet from 10.2.2.10 (invalid authentication)

R5#




R5#sh run | s 0/1.2


encapsulation dot1Q 2

ip address 10.2.2.5 255.255.255.0

ip rip authentication mode md5

ip rip authentication key-chain RIP

no passive-interface FastEthernet0/1.2

R5#

R5#sh run | s key chain

key chain RIP

key 1

key-string ipexpert

R5#

asa(config-if)# sh run int e0/1

!


nameif inside

security-level 100

ip address 10.2.2.10 255.255.255.0

rip authentication mode md5

rip authentication key <removed> key_id 1

asa(config-if)#

Well, we know the password is wrong on one side or the other. Since we can‟t see the ASA let‟s start there.

asa(config-if)# int e0/1

asa(config-if)# rip authentication key ipexpert key 1

asa(config-if)# debug ip rip

asa(config-if)#


RIP: ignored v2 packet from 10.2.2.5 (invalid authentication)

RIP: sending v2 update to 224.0.0.9 via inside (10.2.2.10)

RIP: build update entries

0.0.0.0 0.0.0.0 via 0.0.0.0, metric 1, tag 0

10.7.7.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0

10.8.8.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0

RIP: Update contains 3 routes

RIP: Update queued

RIP: Update sent via inside rip-len:112

asa(config-if)#

We are still getting invalid authentication. R5 Looks good and we know asa is good. Hmmm…Let‟s just fix R5 for the fun of it.

R5#conf t


R5(config)#key chain RIP

R5(config-keychain)# key 1

R5(config-keychain-key)# key-string ipexpert

R5(config-keychain-key)#end

R5#

add 5.0.0.0 255.0.0.0 via 10.2.2.5, rip metric [120/1]

add 10.1.1.0 255.255.255.0 via 10.2.2.5, rip metric [120/1]





RIP: received v2 update from 10.2.2.5 on inside

5.0.0.0255.0.0.0 via 0.0.0.0 in 1 hops

RIP-DB: network_update with 5.0.0.0 255.0.0.0 succeeds

RIP-DB: adding 5.0.0.0 255.0.0.0 (metric 1) via 10.2.2.5 on Ethernet0/1 to RIP

database

RIP-DB: rip_create_ndb create 5.0.0.0 255.0.0.0, (best metric 4294967295)

RIP-DB: rip_create_rdb Create 5.0.0.0 255.0.0.0, (metric 1) via 10.2.2.5, Ethernet0/1

RIP-DB: add 5.0.0.0 255.0.0.0 (metric 1) via 10.2.2.5 on Ethernet0/1

RIP-DB: Adding new rndb entry 5.0.0.0 255.0.0.0


RIP-DB: rip_create_rdb Create 5.0.0.0 255.0.0.0, (metric 1) via 0.0.0.0,

Null0(permanent)

RIP-DB: Created rip ndb summary entry for 5.0.0.0 255.0.0.0


10.1.1.0255.255.255.0 via 0.0.0.0 in 1 hops

RIP-DB: network_update with 10.1.1.0 255.255.255.0 succeeds

RIP-DB: adding 10.1.1.0 255.255.255.0 (metric 1) via 10.2.2.5 on Ethernet0/1 to RIP

database


RIP-DB: rip_create_rdb Create 10.1.1.0 255.255.255.0, (metric 1) via 10.2.2.5,

Ethernet0/1

RIP-DB: add 10.1.1.0 255.255.255.0 (metric 1) via 10.2.2.5 on Ethernet0/1


Okay, so we had a problem on R5 as well. When looking at the configuration it looked good, so why didn‟t it work? A Space at the end of the password. This can be one of the most common headaches you create for yourself when copying and pasting passwords without being careful.

R5#show ip route


















R* 0.0.0.0/0 [120/1] via 10.2.2.10, 00:00:15, FastEthernet0/1.2

R5#

We have one more problem that you may or may not have picked up on initially. The question states all interfaces should be passive unless actively participating. Well, in the startup configuration Loopback1 also had been activated. We need to make sure that we meet all requirements of the question.

R5(config)#router rip

R5(config-router)#passive lo1

R5(config-router)#





1.3 Running OSPF as the Routing Protocol on the ASA

Run OSPF as your routing protocol between the ASA and R8. Advertise all networks.

Inject a Default Route to R8.

Configure authentication using a key of 1 and key-string of ipexpert. Do not use the AREA authentication command under the ospf process on either.


So first on R8 you will see that the protocol is running on the correct interfaces but no routes are being learned.

R8#sh ip proto

Routing Protocol is "ospf 1"



Router ID 8.8.8.8

Number of areas in this router is 1. 1 normal 0 stub 0 nssa

Maximum path: 4


8.8.8.8 0.0.0.0 area 0

10.8.8.8 0.0.0.0 area 0

Reference bandwidth unit is 100 mbps



Distance: (default is 110)

R8#sh ip route ospf

R8#

So lets check the asa to see if we can spot a problem there.

asa# sh run router ospf

!

router ospf 1

network 10.7.7.10 255.255.255.255 area 0

log-adj-changes

default-information originate always

!

asa# conf t

asa(config)# router ospf 1

asa(config-router)# no network 10.7.7.10 255.255.255.255 area 0

asa(config-router)# net 10.8.8.10 255.255.255.255 area 0

asa(config-router)#

Going back to R8.

R8#sh ip route ospf

R8#

R8#debug ip ospf adj

OSPF adjacency events debugging is on

R8#

*Apr 23 06:00:51.049: OSPF: Send with youngest Key 1




*Apr 23 06:00:53.093: OSPF: Rcv pkt from 10.8.8.10, FastEthernet0/1 :

Mismatch Authentication Key - Message Digest Key 1


*Apr 23 06:01:03.093: OSPF: Rcv pkt from 10.8.8.10, FastEthernet0/1 :

Mismatch Authentication Key - Message Digest Key 1

asa(config-router)# debug ospf

asa(config-router)#

OSPF: Rcv pkt from 10.8.8.8, DMZ8 : Mismatch Authentication Key - Message

Digest Key 1

OSPF: Send with youngest Key 1un all

asa(config-router)# un all

asa(config-router)#

R8#sh run int f0/1




!


ip address 10.8.8.8 255.255.255.0

ip ospf authentication message-digest

ip ospf message-digest-key 1 md5 ipexpert

duplex auto

speed auto

end

R8#

asa(config-router)# sh run int e0/0.8

!


vlan 8

nameif DMZ8

security-level 0

ip address 10.8.8.10 255.255.255.0

ospf message-digest-key 1 md5 <removed>

ospf authentication message-digest

asa(config-router)#

asa(config-subif)# no ospf message-digest-key 1 md5 removed

asa(config-subif)# ospf message-digest-key 1 md5 ipexpert

asa(config-subif)# debug ospf

asa(config-subif)#

OSPF: running SPF for area 0

OSPF: Initializing to run spf

OSPF: No new path to 192.1.24.10

It is a router LSA 192.1.24.10. Link Count 1

Processing link 0, id 10.8.8.10, link data 10.8.8.10, type 2

Add better path to LSA ID 10.8.8.10, gateway 10.8.8.10, dist 10

Add path: next-hop 10.8.8.10, interface DMZ8

OSPF: delete lsa id 10.8.8.10, type 2, adv rtr 192.1.24.10 from delete list

OSPF: insert route list LS ID 10.8.8.10, type 2, adv rtr 192.1.24.10




It is a network LSA 10.8.8.10. Router Count 2

Processing router id 192.1.24.10

New newdist 10 olddist 0

Processing router id 8.8.8.8



It is a router LSA 8.8.8.8. Link Count 2





Ignore newdist 11 olddist 10

OSPF: Adding Stub nets

OSPF: Add Network Route to 8.8.8.8 mask 255.255.255.255. Metric: 11, Next

Hop: 10.8.8.8

OSPF: insert route list LS ID 8.8.8.8, type 0, adv rtr 8.8.8.8

OSPF: Entered old delete routine

OSPF: running spf for summaries area 0

OSPF: sum_delete_old_routes area 0

OSPF: Started Building Type 5 External Routes

OSPF: ex_delete_old_routes

OSPF: Started Building Type 7 External Routes

OSPF: ex_delete_old_routes

OSPF: rcv. v:2 t:1 l:48 rid:8.8.8.8

aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x49f001e8 from DMZ8

OSPF: Rcv hello from 8.8.8.8 area 0 from DMZ8 10.8.8.8

OSPF: End of hello processing

OSPF: Send with youngest Key 1un all

asa(config-subif)#

R8

*Apr 23 06:03:33.109: OSPF: Rcv DBD from 192.1.24.10 on FastEthernet0/1 seq

0xB7E opt 0x2 flag 0x1 len 32 mtu 1500 state EXCHANGE

*Apr 23 06:03:33.109: OSPF: Exchange Done with 192.1.24.10 on FastEthernet0/1

*Apr 23 06:03:33.109: OSPF: Send LS REQ to 192.1.24.10 length 24 LSA count 2


*Apr 23 06:03:33.109: OSPF: Send DBD to 192.1.24.10 on FastEthernet0/1 seq

0xB7E opt 0x52 flag 0x0 len 32


*Apr 23 06:03:33.109: OSPF: Rcv LS UPD from 192.1.24.10 on FastEthernet0/1

length 100 LSA count 2

*Apr 23 06:03:33.113: OSPF: Synchronized with 192.1.24.10 on FastEthernet0/1,

state FULL

*Apr 23 06:03:33.113: %OSPF-5-ADJCHG: Process 1, Nbr 192.1.24.10 on

FastEthernet0/1 from LOADING to FULL, Loading Done

*Apr 23 06:03:33.597: OSPF: Reset old DR on FastEthernet0/1


*Apr 23 06:03:33.597: OSPF: Build router LSA for area 0, router ID 8.8.8.8,

seq 0x80000012, process 1




*Apr 23 06:03:43.097: OSPF: Neighbor change Event on interface

FastEthernet0/1

*Apr 23 06:03:43.097: OSPF: DR/BDR election on FastEthernet0/1

*Apr 23 06:03:43.097: OSPF: Elect BDR 8.8.8.8




*Apr 23 06:03:43.097: OSPF: Elect DR 192.1.24.10

*Apr 23 06:03:43.097: DR: 192.1.24.10 (Id) BDR: 8.8.8.8 (Id)




*Apr 23 06:04:13.109: OSPF: FastEthernet0/1 Nbr 192.1.24.10: Clean-up dbase

exchange


*Apr 23 06:04:29.325: OSPF: Send with youngest Key 1in all


R8#sh ip route ospf

O*E2 0.0.0.0/0 [110/1] via 10.8.8.10, 00:01:35, FastEthernet0/1

R8#

asa(config-subif)# sh route






area




R 5.0.0.0 255.0.0.0 [120/1] via 10.2.2.5, 0:00:14, inside


O 8.0.0.0 255.0.0.0 [110/11] via 10.8.8.8, 0:01:35, DMZ8

R 10.1.1.0 255.255.255.0 [120/1] via 10.2.2.1, 0:00:01, inside




asa(config-subif)#


1.4 Run EIGRP on the ASA

Configure EIGRP 200 on the ASA and R7.

Make sure R7 can reach the rest of the Topology.



R7#sh ip proto

Routing Protocol is "eigrp 200"



Default networks flagged in outgoing updates

Default networks accepted from incoming updates

EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

EIGRP maximum hopcount 100




EIGRP maximum metric variance 1

Redistributing: eigrp 200

EIGRP NSF-aware route hold timer is 240s

Automatic network summarization is not in effect

Maximum path: 4


7.0.0.0

10.7.7.0/24



Distance: internal 90 external 170

R7#

R7#sh ip route eigrp

R7#

asa(config-subif)# sh run router eigrp

!

router eigrp 200

no auto-summary

network 10.8.8.0 255.255.255.0

!

asa(config-subif)# router eigrp 200

asa(config-router)# no network 10.8.8.0 255.255.255.0

asa(config-router)# net 10.7.7.0 255.255.255.0

asa(config-router)#


R7#sh ip eigrp neig

IP-EIGRP neighbors for process 200

R7#

asa(config-router)# debug eigrp pack

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, HELLO, PROBE, ACK, STUB, SIAQUERY,

SIAREPLY)

asa(config-router)# EIGRP: Sending HELLO on Ethernet0/0.7

AS 13107202, Flags 0x0, Seq 0/0 interfaceQ 3/1 iidbQ un/rely 0/0

EIGRP: Ethernet0/0.7: ignored packet from 10.7.7.7, opcode = 5 (missing

authentication)

EIGRP: Sending HELLO on Ethernet0/0.7



authentication)




authentication)







authentication)




authentication)




authentication)



Looks like we have another authentication problems.

R7#debug eigrp packets


(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,

SIAQUERY, SIAREPLY)

R7#

*Apr 23 06:10:18.537: EIGRP: interface FastEthernet0/1, No live

authentication keys

*Apr 23 06:10:18.537: EIGRP: FastEthernet0/1: ignored packet from 10.7.7.10,

opcode = 5 (invalid authentication)

*Apr 23 06:10:19.029: EIGRP: Sending HELLO on Loopback0

*Apr 23 06:10:19.029: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

*Apr 23 06:10:19.029: EIGRP: Received HELLO on Loopback0 nbr 7.7.7.7

*Apr 23 06:10:19.029: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0

*Apr 23 06:10:19.029: EIGRP: Packet from ourselves ignored


authentication keys

*Apr 23 06:10:21.841: EIGRP: Sending HELLO on FastEthernet0/1



authentication keys









authentication keys




authentication keys







*Apr 23 06:10:28.757: EIGRP: Packet from ourselves ignoredu


authentication keys







authentication keys


opcode = 5 (invalid authentication)n all

All possible debugging has been turned off

asa(config-router)# sh run int e0/0.7

!


vlan 7

nameif DMZ7

security-level 50

ip address 10.7.7.10 255.255.255.0

authentication key eigrp 200 <removed> key-id 1


asa(config-router)#

R7#sh run int f0/0



!


ip address 10.7.7.7 255.255.255.0


ip authentication key-chain eigrp 200 eigrp

duplex auto

speed auto

end

R7#sh run | sec key chain

R7#

So the key chain is missing on R7.

R7(config)#key chain eigrp

R7(config-keychain)#key 1

R7(config-keychain-key)#key-string ipexpert

R7(config-keychain-key)#

R7#debug eigrp packets


(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,

SIAQUERY, SIAREPLY)

R7#








*Apr 23 06:13:58.757: EIGRP: pkt key id = 1, authentication mismatch












Again, since we can‟t read the password on the ASA let‟s re-apply the key there.

asa(config-router)# int e0/0.7

asa(config-subif)# no authentication key eigrp 200 ipexpert key 1

asa(config-subif)# authentication key eigrp 200 ipexpert key 1

asa(config-subif)#

R7#

*Apr 23 06:15:02.917: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 10.7.7.10

(FastEthernet0/1) is up: new adjacency

R7#

R7#sh ip route eigr

D* 0.0.0.0/0 [90/28416] via 10.7.7.10, 00:00:32, FastEthernet0/1

R7#

asa(config-subif)# sh route






area




R 5.0.0.0 255.0.0.0 [120/1] via 10.2.2.5, 0:00:08, inside


D 7.0.0.0 255.0.0.0 [90/131072] via 10.7.7.7, 0:00:40, DMZ7

O 8.0.0.0 255.0.0.0 [110/11] via 10.8.8.8, 0:12:17, DMZ8

R 10.1.1.0 255.255.255.0 [120/1] via 10.2.2.1, 0:00:08, inside




asa(config-subif)#





1.5 Static Default Routes

Configure a default route to R2.

If R2 is unavailable R4 should be used as a backup.

The Target should be GigabitEthernet0/1 interface of R2 This should run indefinitely The timeout should be 1000 MS The operation should repeat every three seconds.


So we should have static routes pointing to the outside and the static route to R2 should be using reachability tracking to verify reachability.

asa(config)# sh run | incl route out

route outside 0.0.0.0 0.0.0.0 19.1.24.2 1 track 1

route outside 0.0.0.0 0.0.0.0 19.1.24.4 5

asa(config)# show sla monitor operational-state

Entry number: 1

Modification time: 21:43:09.081 UTC Thu Apr 30 2009




Current seconds left in Life: 0

Operational state of entry: Inactive



Timeout occurred: FALSE


Latest RTT (milliseconds) : Unknown

Latest operation return code: Unknown

Latest operation start time: Unknown

asa(config)#

At first glance the static routes appear to be correct, but looking at the first octet shows we mis-typed it. Also the Operational state of the sla monitor is inactive. This means it has not been applied to run.

asa(config)# sla monitor schedule 1 start-time now life forever

asa(config)# sh run | incl route out


route outside 0.0.0.0 0.0.0.0 19.1.24.4 5

asa(config)# no route outside 0.0.0.0 0.0.0.0 19.1.24.2 1 track 1

asa(config)# no route outside 0.0.0.0 0.0.0.0 19.1.24.4 5

asa(config)# route out 0 0 192.1.24.2 1 track 1

asa(config)# route out 0 0 192.1.24.4 5

ERROR: Cannot add route entry, conflict with existing routes

What does that error mean? That is a strange error?

asa(config)# sh run | incl route outside



ERROR: Cannot add route entry, conflict with existing routes










area




R 5.0.0.0 255.0.0.0 [120/1] via 10.2.2.5, 0:00:21, inside


D 7.0.0.0 255.0.0.0 [90/131072] via 10.7.7.7, 19:48:23, DMZ7

O 8.0.0.0 255.0.0.0 [110/11] via 10.8.8.8, 19:47:30, DMZ8

R 10.1.1.0 255.255.255.0 [120/1] via 10.2.2.5, 0:00:21, inside





D* 0.0.0.0 0.0.0.0 is a summary, 0:01:09, Null0

asa(config)# sh run int e0/0.7

!


vlan 7

nameif DMZ7

security-level 50


authentication key eigrp 200 <removed> key-id 1


summary-address eigrp 200 0.0.0.0 0.0.0.0 5

asa(config)# int e0/0.7

So our summary route for eigrp is causing us a bit of problems here. Looks like we are going to need to edit that to fix this error.

asa(config-subif)# no summary-address eigrp 200 0.0.0.0 0.0.0.0 5

asa(config-subif)# exit


asa(config)# int e0/0.7

asa(config-subif)# summary-address eigrp 200 0.0.0.0 0.0.0.0 5

asa(config-subif)# exit







area







R 5.0.0.0 255.0.0.0 [120/1] via 10.2.2.5, 0:00:01, inside


D 7.0.0.0 255.0.0.0 [90/131072] via 10.7.7.7, 0:00:07, DMZ7

O 8.0.0.0 255.0.0.0 [110/11] via 10.8.8.8, 19:48:35, DMZ8

R 10.1.1.0 255.255.255.0 [120/1] via 10.2.2.5, 0:00:01, inside





S* 0.0.0.0 0.0.0.0 [5/0] via 192.1.24.4, outside

asa(config)#

So the SLA is still not working but we have routing working to R4.

asa(config)# show track 1

Track 1

Response Time Reporter 1 reachability

Reachability is Down

1 change, last change 00:40:53

Latest operation return code: Unknown

Tracked by:

STATIC-IP-ROUTING 0

asa(config)# sh run | incl track


track 1 rtr 1 reachability

asa(config)# no track 1 rtr 1 reachability

asa(config)# track 1 rtr 1 reachability

asa(config)# show track 1

Track 1

Response Time Reporter 1 reachability

Reachability is Up

1 change, last change 00:00:02

Latest operation return code: OK

Latest RTT (millisecs) 1

Tracked by:

STATIC-IP-ROUTING 0

asa(config)#

So, there wasn‟t particularly anything wrong with the configuration but because the sla monitor had not been activated the tracking configuration needed to be removed and re-applied.


1.6 Configure ASA2 for failover

Configure ASA2 as the failover unit for ASA1.

ASA1 is the primary. Use interface Ethernet0/3. Use message encryption with a key of ipexpert. If a failover occurs don‟t drop the users http connections. If a switch needs configured do so. You may use any IP addressing you want for the failover interface as long as it

doesn‟t overlap with another IP range that is in use.

Make sure interface states are monitored.





asa(config)# sh fail

Failover On


Failover LAN Interface: FAILINT Ethernet0/3 (Failed - No Switchover)



Interface Policy 1












slot 1: empty

Other host: Secondary - Failed


slot 0: ASA5510 hw/sw rev (1.1/8.0(4)) status (Unknown/Unknown)

Interface outside (0.0.0.0): Unknown (Waiting)



Interface inside (0.0.0.0): Unknown (Waiting)

slot 1: empty


Link : FAILINT Ethernet0/3 (Failed)


General 313 0 313 0

sys cmd 313 0 313 0

up time 0 0 0 0


TCP conn 0 0 0 0

UDP conn 0 0 0 0

ARP tbl 0 0 0 0


VPN IKE upd 0 0 0 0



VPN SDI upd 0 0 0 0


SIP Session 0 0 0 0


Cur Max Total

Recv Q: 0 8 313

Xmit Q: 0 26 2698

asa(config)#




ciscoasa(config)# sh fail

Failover On





Interface Policy 1





This host: Secondary - Active



slot 1: empty

Other host: Primary - Not Detected


slot 0: ASA5510 hw/sw rev (1.1/8.0(4)) status (Unknown/Unknown)

slot 1: empty




General 313 0 313 0

sys cmd 313 0 313 0

up time 0 0 0 0


TCP conn 0 0 0 0

UDP conn 0 0 0 0

ARP tbl 0 0 0 0


VPN IKE upd 0 0 0 0



VPN SDI upd 0 0 0 0


SIP Session 0 0 0 0


Cur Max Total

Recv Q: 0 7 2692

Xmit Q: 0 1 313

ciscoasa(config)#

asa(config)# sh run failover

failover



failover key *****


failover link FAILINT Ethernet0/3

failover interface ip FAILINT 10.99.99.10 255.255.255.0 standby 10.99.99.20

asa(config)#




ciscoasa(config)# sh run failover

failover

failover lan unit secondary


failover key *****





Interface Ethernet0/3 "FAILINT", is administratively down, line protocol is

up



Description: LAN/STATE Failover Interface

MAC address 0017.9527.51e3, MTU 1500





0 L2 decode drops






output queue (curr/max packets): hardware (0/0) software (0/0)

Traffic Statistics for "FAILINT":

0 packets input, 0 bytes

16 packets output, 448 bytes

0 packets dropped






asa(config)#

ciscoasa(config)# sh int e0/3

Interface Ethernet0/3 "FAILINT", is up, line protocol is up



Description: LAN/STATE Failover Interface

MAC address 0018.7317.9a63, MTU 1500





0 L2 decode drops






output queue (curr/max packets): hardwar




asa(config)# int e0/3


asa(config-if)#

WARNING: Failover message decryption failure. Please make sure

both units have the same failover shared key and crypto license

or system is not out of memory

Failover LAN became OK

Switchover enabled

ciscoasa#

ciscoasa# fover_ip: fover_ip(): ifc 1 got Fover Msg 10.99.99.10 ->

10.99.99.20

fover_ip: Invalid fover msg hash detected

asa(config-if)# sh run failover

failover



failover key *****




asa(config-if)# failover key ipexpert

asa(config)# Beginning configuration replication: Sending to mate.

End Configuration Replication to mate

ciscoasa#

State check detected an Active mate

sBeginning configuration replication from mate.

Allowing OSPF process to run for a while to complete config sync.

WARNING: L2L tunnel-groups that have names which are not an IP

address may only be used if the tunnel authentication

method is Digitial Certificates and/or The peer is

configured to use Aggressive Mode

End configuration replication from mate.

Switching to Standby




asa(config)# sh failover

Failover On





Interface Policy 1












slot 1: empty

Other host: Secondary - Standby Ready







slot 1: empty




General 11 0 6 0

sys cmd 6 0 6 0

up time 0 0 0 0


TCP conn 0 0 0 0

UDP conn 0 0 0 0

ARP tbl 5 0 0 0


VPN IKE upd 0 0 0 0



VPN SDI upd 0 0 0 0


SIP Session 0 0 0 0


Cur Max Total

Recv Q: 0 7 6

Xmit Q: 0 26 98

asa(config)#




ASA2

asa# sh fail

Failover On





Interface Policy 1





This host: Secondary - Standby Ready







slot 1: empty

Other host: Primary - Active







slot 1: empty




General 323 0 328 0

sys cmd 323 0 323 0

up time 0 0 0 0


TCP conn 0 0 0 0

UDP conn 0 0 0 0

ARP tbl 0 0 5 0


VPN IKE upd 0 0 0 0



VPN SDI upd 0 0 0 0


SIP Session 0 0 0 0


Cur Max Total

Recv Q: 0 7 2818

Xmit Q: 0 1 323

asa#





1.7 Translations and Connections with inbound ACLs

Use a NAT/PAT combination to allow inside networks to outside using the following range of address: 192.1.24.51 – 192.1.24.150.

Configure the pool such that if all addresses in the pool are exhausted translations will still occur.



R4 should be able to web browse to 192.1.24.8.

R4 should be able to web browse to 192.1.24.8 on port 8080. This should direct the connection to R8‟s loopback address.

If an outside user SSHs or HTTPs‟ (SSL) to 192.1.24.10, he should be redirected to 10.7.7.7. Allow the appropriate entries in your access-list.

R7 should be able to ping R2 and R4‟s Loopback addresses using its own IP Address 10.7.7.7. You cannot use the static command to accomplish this. You are allowed to create 2 routes each on R2 and R4.


asa(config)# sh run nat

nat (DMZ7) 0 access-list NAT_EXEMPT

nat (inside) 1 0.0.0.0 0.0.0.0

asa(config)# sh run global

global (outside) 1 192.1.24.51-192.1.24.150

asa(config)#

NAT is correct except that the last address has not been set aside for PAT.

asa(config)# clear conf global

asa(config)# global (outside) 1 192.1.24.51-192.1.24.149

asa(config)# global (outside) 1 192.1.24.150

INFO: Global 192.1.24.150 will be Port Address Translated

asa(config)#

asa(config)# sh run global

global (outside) 1 192.1.24.51-192.1.24.149

global (outside) 1 192.1.24.150

asa(config)#

Now test the Requirements for R7 and R8. You will probably need to re-create the RSA key on R7 as this is not stored in the startup configuration.

R7(config)#crypto key gen rsa gen mod 1024

% You already have RSA keys defined named R7.ipexpert.com.

% They will be replaced.

% The key modulus size is 1024 bits

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

R7(config)#

R7(config)#do sh run | incl username

username ipexpert privilege 15 password 0 ipexpert




R7(config)#do sh run | incl http

no ip http server

no ip http secure-server

R7(config)#ip http server

R7(config)#ip http secure-server

R7(config)#

*May 1 14:38:22.385: %PKI-6-AUTOSAVE: Running configuration saved to NVRAM

R7(config)#do wr


[OK]

R7(config)#do sh run | section line vty

line vty 0 4

login

R7(config)#line vty 0 4

R7(config-line)#login local

R7(config-line)#

Looks like some of the basic configuration was missing on R7. Lets check R8 to make sure it is okay.

R8(config)#do sh run | s line v

line vty 0 4

privilege level 15

password ipexpert

login

line vty 5 15

privilege level 15

password ipexpert

login

R8(config)#do sh run | inc http

ip http server

no ip http secure-server

R8(config)#

Okay. R8 doesn‟t have any errors. We can either check the ASA right now or test. Let‟s double check the ASA before testing.

asa(config)# sh run static

static (DMZ8,outside) tcp 192.1.24.8 www 10.8.8.8 www netmask 255.255.255.255

static (DMZ8,outside) tcp 192.1.24.8 8088 8.8.8.8 www netmask 255.255.255.255

static (DMZ7,outside) tcp interface https 10.7.7.10 http netmask 255.255.255.255

static (DMZ7,outside) tcp interface ssh 10.7.7.10 ssh netmask 255.255.255.255

static (DMZ8,outside) 192.1.24.8 10.8.8.8 netmask 255.255.255.255







asa(config)#

asa(config)# sh run access-list out_in

access-list out_in extended permit tcp host 192.1.24.4 host 192.1.24.7 eq telnet


access-list out_in extended permit tcp host 192.1.24.4 host 192.1.24.8 eq www

access-list out_in extended permit tcp host 192.1.24.4 host 192.1.24.8 eq 8080

access-list out_in extended permit tcp any host 192.1.24.10 eq ssh

access-list out_in extended permit tcp any host 192.1.24.10 eq https




access-list out_in extended permit object-group ALL_SVC object-group Partners object-

group DMZ_Servers



access-list out_in extended permit tcp host 192.1.24.2 host 192.1.24.15 eq 3025


access-list out_in extended permit tcp host 4.4.4.4 host 5.5.5.5 eq bgp

asa(config)#

Looks like one error in the ACL and a couple errors in the STATIC NAT.

asa(config)# clear configure static

asa(config)# static (DMZ8,outside) tcp 192.1.24.8 www 10.8.8.8 www netmask

255.255.255.255

asa(config)# static (DMZ8,outside) tcp 192.1.24.8 8080 8.8.8.8 www netmask

255.255.255.255

asa(config)# static (DMZ7,outside) tcp interface https 10.7.7.7 https netmask

255.255.255.255

asa(config)# static (DMZ7,outside) tcp interface ssh 10.7.7.7 ssh netmask

255.255.255.255

asa(config)# static (DMZ8,outside) 192.1.24.8 10.8.8.8 netmask 255.255.255.255




asa(config)# static (inside,outside) 192.1.24.15 10.2.2.5 netmask 255.255.255.255



asa(config)# sh access-list out_in | incl line 1

access-list out_in line 1 extended permit tcp host 192.1.24.4 host 192.1.24.7 eq

telnet (hitcnt=3) 0x4beb9cc1

asa(config)# no access-list out_in line 1 extended permit tcp host 192.1.24.4 host

192.1.24.7 eq telnet

asa(config)# access-list out_in line 1 extended permit tcp host 192.1.24.2 host

192.1.24.7 eq telnet

asa(config)#

Now I should be able to test to R7 and R8.


Trying 192.1.24.7 ... Open


Username: ipexpert

Password:

R7#q


R2(config)#


Password:

R7#q


R2(config)#





Trying 192.1.24.10, 443 ... Open

g


R2(config)#

That all looks good.

R4#telnet 192.1.24.8

Trying 192.1.24.8 ... Open


Password:

R8#q


R4#telnet 192.1.24.8 8080

Trying 192.1.24.8, 8080 ... Open

get


Date: Mon, 04 May 2009 20:46:57 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request


R4#telnet 192.1.24.8 80

Trying 192.1.24.8, 80 ... Open

get


Date: Mon, 04 May 2009 20:47:02 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request


R4#

This looks good. too. Most of the mistakes in this section were simulations of the good old fat finger mistakes the majority of us do so hopefully you are doublechecking your own work and running tests on the technologies.





1.8 Access List and Object Groups on the ASA

Your company will be putting in application servers. One of the application servers will be in DMZ7 with an IP Address of 10.7.7.21, and the other will be in DMZ8 with an IP Address of 10.8.8.22.

Create a static translation for them on the outside so that 10.7.7.21 is seen as 192.1.24.21 on the outside and 10.8.8.22 is seen as 192.1.24.22 on the outside.

These servers are going to be accessed by partner organizations. The IP Addresses of these partner organizations are as follows:

205.15.25.0/24 207.215.1.0/24 210.208.15.16/28 211.0.15.32/27 192.1.150.112/28

The applications on the servers are as follows:

TFTP FTP HTTP SMTP DNS Custom Application at UDP 50000 ICMP

Allow all of the partner organizations access to all the applications on the 2 servers. You are allowed to add 1 line in the Access List to accomplish this.


Since we really can‟t test this, as these devices are not live on the network, we need to make sure there are no mistakes in the Configuration.

asa(config)# sh run object-group

object-group network DMZ_Servers



object-group network Partners

network-object 205.15.25.0 255.255.255.0

network-object 207.215.1.0 255.255.255.0

network-object 210.208.15.16 255.255.255.240

network-object 211.0.15.32 255.255.255.224

network-object 192.1.150.112 255.255.255.240

object-group service ALL_SVC

service-object tcp eq ftp

service-object tcp eq www

service-object tcp eq smtp

service-object udp eq tftp

service-object udp eq domain

service-object tcp eq domain


service-object icmp

asa(config)#

The Object-Groups are correct.




asa(config)# sh run static | incl 24.2



asa(config)#

The statics are correct.

asa(config)# sh run access-list out_in | incl object

access-list out_in extended permit object-group ALL_SVC object-group Partners

object-group DMZ_Servers

asa(config)#

And the ACL is correct. Looks like nothing needs to be done here.


1.9 Authentication Proxy

The AAA server is located at 10.1.1.100. Configure the AAA server to communicate with the ASA using TACACS+ and a key of ipexpert. Configure a user named ASAuser with a password of ipexpert.

All outbound Telnet and HTTP Requests have to authenticate against the AAA server. The Username to use is ASAuser with a password of ipexpert. Use the same username and password for all authentication passwords.

Enable Telnet on R5 with a password of ipexpert.

Make R5 appear as 192.1.24.15 on the outside. Allow R4 FastEthernet0/1 as well as Loopback0 to telnet into R5 through the ASA. Make the ACL as specific as possible.

All Inbound Telnet to R5 should be authenticated. Explicitly exclude the Loopback of R4.

All outbound TFTP and RSH traffic should be authenticated against the AAA server. Use 192.1.24.9 for the virtual address and telnet as the authentication protocol.

R2 should be able to Telnet into 192.1.24.15 (R5‟s translated address). Configure R5 to allow R2 to telnet into port 3025. Configure the ACL as needed to allow communication.

Authenticate all Telnet traffic to port 3025 from R2 to R5 using the AAA Server.

Note: Use Clear uauth on the ASA after every authentication step to clear the authentication.


First test to see if we can authenticate against ACS.

asa(config)# test aaa authentication AAA host 10.1.1.100 user ASAUser pass

ipexpert

INFO: Attempting Authentication test to IP address <10.1.1.100> (timeout: 12

seconds)

ERROR: Authentication Rejected: Unspecified

asa(config)#

Hmm…Rejected. Let‟s look at the configuration on ACS.




ASA looks okay in ACS. And the User.




User is okay, as we didn‟t do any major changes to the user configuration but we re-did the password just incase that was a problem. Maybe a problem on the ASA. Let‟s go back there.

asa(config)# show run aaa-server

aaa-server AAA protocol radius

aaa-server AAA (inside) host 10.1.1.100

key ipxpert

asa(config)#

Okay, the protocol is wrong and the key is wrong. We will need to fix that.

asa(config)# no aaa-server AAA protocol radius

ERROR: aaa-server group <AAA> is in use by the aaa subsystem. Please remove

the relevant configuration before removing the aaa-server group.

asa(config)#

Great!

asa(config)# sh run aaa


aaa authentication ssh console AAA



asa(config)# no aaa authentication match outbound_aaa inside AAA

asa(config)# no aaa authentication ssh console AAA

asa(config)# no aaa authentication telnet console AAA

asa(config)# no aaa authentication match outside_AAA_in outside AAA

asa(config)# no aaa-server AAA protocol radius

asa(config)# aaa-server AAA protocol tacacs+

asa(config-aaa-server-group)# aaa-server AAA (inside) host 10.1.1.100

asa(config-aaa-server-host)# key ipexpert

asa(config-aaa-server-host)# aaa authentication match outbound_aaa inside AAA

asa(config)# aaa authentication ssh console AAA

asa(config)# aaa authentication telnet console AAA

asa(config)#

Okay, that is fixed. Let‟s test the AAA server again. (You may want to note one of the match commands is missing up above for later in the task.)

asa(config)# test aaa authentication AAA host 10.1.1.100 user ASAUser pass

ipexpert


seconds)

ERROR: Authentication Rejected: Unspecified

asa(config)#

Hmm…It looks to still be rejecting the connection. The config looked good in ACS. We may want to check the logs but for kicks lets make sure we can ping it.




?????


asa(config)#




So we cannot even ping ACS. That is strange that we are getting a rejected when testing AAA but we need to find out why we can‟t ping it.

asa(config)# show route inside






area




R 5.0.0.0 255.0.0.0 [120/1] via 10.2.2.5, 0:00:15, inside

R 10.1.1.0 255.255.255.0 [120/1] via 10.2.2.5, 0:00:15, inside


asa(config)#

The route is there. Can we ping 10.2.2.5?




!!!!!





!!!!!


asa(config)#

We can even ping R5‟s interface to VLAN 10. Can we ping ACS from the default gateway for it?

R5(config)#do ping 10.1.1.100



.....


R5(config)#

We are unable to ping it from the default gateway. We need to go down to Layer 2.

Sw3#sh vlan id 10

VLAN id 10 not found in current VLAN database

Sw3#

Sw3#conf t


Sw3(config)#vlan 10

Sw3(config-vlan)#exit




Sw3(config)#do sh vlan id 10


---- -------------------------------- --------- -------------------------------

10 VLAN0010 active Fa0/5, Fa0/14, Fa0/23, Fa0/24

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

10 enet 100010 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

Sw3(config)#

So the VLAN is now active. It is on the trunk and R5 and ACS ports are active in the VLAN. Test again.




!!!!!


R5(config)#

We are now good from R5. And ASA1?




?????


asa(config)#

Still no good. Maybe the route is missing on ACS.

C:\Documents and Settings\Administrator>route print 10.2.2.0

IPv4 Route Table

===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x10003 ...00 0c 29 5a 13 14 ...... VMware Accelerated AMD PCNet Adapter

0x10004 ...00 0c 29 5a 13 1e ...... VMware Accelerated AMD PCNet Adapter #2

===========================================================================

===========================================================================

Active Routes:

Network Destination Netmask Gateway Interface Metric

10.2.2.0 255.255.255.0 10.1.1.1 10.1.1.100 1


===========================================================================

Persistent Routes:

Network Address Netmask Gateway Address Metric

10.2.2.0 255.255.255.0 10.1.1.1 1





C:\Documents and Settings\Administrator>ping 10.2.2.10

Pinging 10.2.2.10 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 10.2.2.10:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),



Reply from 10.2.2.5: bytes=32 time=1ms TTL=255

Reply from 10.2.2.5: bytes=32 time<1ms TTL=255


Reply from 10.2.2.5: bytes=32 time<1ms TTL=255



Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 1ms, Average = 0ms


Okay, a ping to ASA fails but to R5 VLAN 2 works fine. What else can we check here? Logs are always helpful.

asa(config)# sh logg | incl 10.1.1.100

%ASA-4-401004: Shunned packet: 10.1.1.100 ==> 10.2.2.10 on interface inside

%ASA-4-401004: Shunned packet: 10.1.1.100 ==> 10.2.2.10 on interface inside

%ASA-5-111008: User 'enable_15' executed the 'ping 10.1.1.100' command.

asa(config)#

Shunned? What‟s up with that. We do have a later section for threat detection. Is that the problem?

asa(config)# show threat-detection shun

Shunned Host List:

asa(config)#

Nothing there.

asa(config)# show shun

shun (inside) 10.1.1.100 0.0.0.0 0 0 0

asa(config)#

But it is in there. Clear that out.

asa(config)# clear shun




asa(config)# test aaa authent AAA host 10.1.1.100 user ASAuser pass ipexpert


seconds)

INFO: Authentication Successful

asa(config)#

So this problem had no direct correlation to the section, but is a good example of things they can do in the test to make your life miserable

Now we need to test to make sure the proxy is working. First inside to outside.

asa(config)# sh run access-list outbound_aaa

access-list outbound_aaa extended permit tcp any any eq telnet

access-list outbound_aaa extended permit tcp any any eq www

access-list outbound_aaa extended permit udp any any eq tftp

access-list outbound_aaa extended permit udp any any eq syslog

asa(config)#

Syslog is definitely wrong. (Right port wrong protocol.)

asa(config)# no access-list outbound_aaa extended permit udp any any eq

syslog

asa(config)# access-list outbound_aaa extended permit tcp any any eq rsh

asa(config)# sh run aaa authentication



asa(config)#

asa(config)# sh run | incl 24.9

access-list out_in extended permit tcp host 192.1.24.2 host 192.1.24.9 eq

telnet

access-list outside_AAA_in extended permit tcp any host 192.1.24.9 eq telnet


virtual telnet 192.1.24.9

asa(config)#

We aren‟t testing inbound yet, but the match statement for inbound is missing. Everything else for outbound looks good.

asa(config)# aaa authentication match outside_AAA_in outside AAA

asa(config)#


Trying 4.4.4.4 ... Open

Username: ASAuser

Password:

Password required, but none set


R5(config)#

asa(config)# clear uauth

asa(config)#




And From ACS:

asa(config)# show uauth

Current Most Seen



user 'ASAUser' at 10.1.1.100, authenticated



asa(config)#

Telnet and WWW are good. How about the Virtual telnet?


Trying 192.1.24.9 ... Open


Username: ASAuser

Password:



R5(config)#




asa(config)# show uauth

Current Most Seen






asa(config)#

Setup R2 to serve the file:

R2(config)#do copy run flash:tftp.txt



R2(config)#tftp-server flash:tftp.txt

R2(config)#

Then TFTP from R5:


Address or name of remote host [192.1.24.2]?

Source filename [tftp.txt]?



Loading tftp.txt from 192.1.24.2 (via FastEthernet0/1): !

[OK - 1973 bytes]


R5#

Cool. We are good there. We aren‟t going to test RSH as TFTP worked.

R4#telnet 192.1.24.15 /source lo0

Trying 192.1.24.15 ... Open


Password:

R5>q


R4#telnet 192.1.24.15

Trying 192.1.24.15 ... Open

Username: ASAuser

Password:


Password:

R5>q


R4#




R4 is all correct. R2.


Trying 192.1.24.9 ... Open


Username: ASAuser

Password:




Trying 192.1.24.15, 3025 ... Open


Password:

R5>q


R2(config)#

Finally finished with this Task.


1.10 Configure Filtering on the ASA

You want to block Java and ActiveX applets from anyone.

Ensure that the ACS is never filtered.

There is a WebSense server located at 10.1.1.101.

Before a HTTP request is allowed to go out, the ASA should verify with the WebSense server if the website is allowed or not. Configure the ASA such that traffic will be allowed to pass if the WebSense server is down.

Also use this WebSense server to filter FTP traffic from the 10.1.1.0/24 network to the Loopback network of R4. Don‟t allow FTP in any interactive FTP applications.


There are no issues with this task.





1.11 Using the Modular Policy Framework

Partner Networks will be accessing SMTP Services on the DMZ. Create a policy such that SMTP is checked for the domain badspammer.com. If this domain is found reset the connection. Do not log.

Ensure that R4 and R5 can establish an authenticated BGP connection thru the ASA.

In the future the router team will enable BGP authentication. Use the MPF to make sure that TCP option 19 is not cleared. Disable Random Sequence Numbering of BGP traffic.

Note: Do Not Change the default BGP configuration on R4 and R5.

There is a new IP telephony deployment that will be installed between the private network and a new branch that has not been deployed yet. The tunnel-group for the branch is IPXPRT_BRANCH_A. Ensure that traffic destine for this branch that is VoIP traffic receives the lowest latency possible as it leave the ASA. Set the queue-limit to twice the default and the tx-ring limit to three.

In addition to the configured QOS policy you have applied, policy ICMP traffic in such a way that icmp is not allowed more than 56 Kbps on the outside interface.


asa(config)# show service-policy interface outside

Interface outside:


Class-map: smtp








Class-map: VOIP

Priority:


Class-map: HTTP_TO_ACS

Inspect: http MY_HTTP_MAP, packet 0, drop 0, reset-drop 0


Default Queueing

asa(config)#




asa(config)# sh run class-map

!

class-map VOIP

match tunnel-group IPXPRT_BRANCH_A

class-map ICMP_POLICY

match access-list ICMP_POLICY

class-map HTTP_TO_ACS

match access-list HTTP_TO_ACS

class-map type inspect http match-all POST_METHOD

match request method post

class-map smtp

match access-list SMTP

class-map inspection_default

match default-inspection-traffic

class-map imblock

match access-list NO_IM

class-map bgp

match access-list BGP

!

asa(config)# sh run policy-map

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 512

policy-map type inspect im impolicy

parameters

match protocol yahoo-im

reset

policy-map IM

class imblock

inspect im impolicy

policy-map type inspect http MY_HTTP_MAP

parameters

spoof-server "Apache 1.1"

protocol-violation action drop-connection

class POST_METHOD

drop-connection log

policy-map type inspect esmtp SMTP_INSPECT

parameters

match sender-address regex BADSPAMMER

reset

policy-map global_policy

class bgp

set connection random-sequence-number disable

set connection advanced-options BGP-MD5

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp




inspect sip

inspect netbios

inspect tftp

policy-map OUTSIDE

class smtp

inspect esmtp SMTP_INSPECT

class ICMP_POLICY

police output 56000

class VOIP

priority

class HTTP_TO_ACS

inspect http MY_HTTP_MAP

!

asa(config)#

asa(config)# class-map VOIP

asa(config-cmap)# match dscp ef

asa(config-cmap)#

BGP seems to be working fine.

R5(config)#do sh ip bgp sum










Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down

State/PfxRcd

4.4.4.4 4 1 6062 6017 2 0 0 00:00:09 1

R5(config)#do sh ip bgp


Status codes: s suppressed, d damped, h history, * valid, > best, i -

internal,




*>i44.44.44.0/24 4.4.4.4 0 100 0 i

R5(config)#





1.12 Remote Management of the ASA

Allow the ACS Server to Manage the ASA Firewall. The ACS Server should be able to use either ssh or telnet for management.

The user authentication should be done based on TACACS+.

The ACS Server should be already setup for some of this communication. You may modify whatever is necessary to accomplish this task.

The username for ssh management is SSHuser with a password of ipexpert.

Ensure that the SSH idle time is as low as possible.

The username for telnet management is 23user with a password of ipexpert.


asa(config)# test aaa authentication AAA host 10.1.1.100 username ASAuser

pass$


seconds)

INFO: Authentication Successful

asa(config)#

So, ACS is still working as we had to fix all the problems in the Auth-Proxy Section. Let‟s test the connectivity.




Hmm…That didn‟t work. Check the ASA.

asa(config)# sh run telnet

telnet 10.1.1.100 255.255.255.255 outside

telnet timeout 5

asa(config)#

asa(config)# no telnet 10.1.1.100 255.255.255.255 outside

asa(config)# telnet 10.1.1.100 255.255.255.255 inside

asa(config)#







asa(config)# sh run access-l outbound_aaa

access-list outbound_aaa extended permit tcp any any eq telnet

access-list outbound_aaa extended permit tcp any any eq www

access-list outbound_aaa extended permit udp any any eq tftp

access-list outbound_aaa extended permit tcp any any eq rsh

asa(config)# aaa authentication telnet console AAA




asa(config)# sh run ssh

ssh 10.1.1.100 255.255.255.255 outside

ssh timeout 1

asa(config)#

asa(config)# ssh 10.1.1.100 255.255.255.255 inside

asa(config)#








asa(config)#

asa(config)# aaa authentication ssh console AAA

asa(config)#





1.13 Enabling the ASA firewall as a DHCP Server

Configure the ASA firewall as a DHCP Server.

Assign IP configuration on the inside interface based on the following information:

IP ADDRESS : 10.0.0.51 – 10.2.2.100 WINS ADDRESS : 10.2.2.135 DNS ADDRESS : 150.50.24.53 DEFAULT GATEWAY : 10.2.2.10 LEASE TIME : 3 Days

Add the XP Workstation to VLAN2 to Test.

Note: I recommend you add a persistent route back to yourself on the XP workstation to make sure you don‟t lose connectivity due to two default gateways.


First check the running configuration on ASA.

asa(config)# sh run dhcpd

dhcpd dns 150.50.24.53

dhcpd wins 10.2.2.135

dhcpd lease 259200

!

dhcpd address 10.2.2.50-10.2.2.100 inside

!

asa(config)#

DNS is correct, WINS is correct and lease is correct (259200 seconds = 3 days). But it looks like the address range is incorrect and the dhcp server has not been enabled on the inside interface.

asa(config)# dhcpd address 10.2.2.51-10.2.2.100 inside

asa(config)# dhcpd enable inside

asa(config)# show dhcpd state

Context Configured as DHCP Server

Interface inside, Configured for DHCP SERVER

Interface outside, Not Configured for DHCP



asa(config)#

Okay, it now looks good. Lets test again using the XP workstation. Connect to the XP Workstation and test to see if it can get a DHCP address. As the note states, you can add a persistent route back to yourself to make sure you don‟t loose connectivity.

C:\Documents and Settings\Administrator>route add –p <your public IP address>

mask 255.255.255.255 10.200.5.254



DHCP enabled: No

IP Address: 10.200.5.12



GatewayMetric: 0

InterfaceMetric: 0





DHCP enabled: No

IP Address: 192.1.49.100


InterfaceMetric: 0

C:\Documents and Settings\Administrator>netsh interface ip set address

name="Student NIC - ok to change - watch routes!" source=dhcp

Ok.



DHCP enabled: No

IP Address: 10.200.5.12



GatewayMetric: 0

InterfaceMetric: 0


DHCP enabled: Yes

InterfaceMetric: 0





IP Address. . . . . . . . . . . . : 10.200.5.12

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.200.5.254



IP Address. . . . . . . . . . . . : 10.2.2.51

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.2.2.10


asa(config)# show dhcpd binding

IP address Hardware address Lease expiration Type

10.2.2.51 0100.0c29.960f.ac 259010 seconds Automatic

asa(config)#





1.14 Controlling Threats

An administrator has recently determined that the network is subject to a nasty Scan attack. Enable the ASA to detect scan attacks and automatically shun the identified attackers.

Do not shun the ACS Server.


Well, you may have already caught this in the Auth-Proxy section but if you didn‟t in the startup configuration ACS has been shun, not by the threat detection but plain old shunning.

asa(config)# show shun

shun (inside) 10.1.1.100 0.0.0.0 0 0 0

asa(config)#

Probably want to clear that out if you haven‟t already.

asa(config)# clear shun

asa(config)#

asa# show threat-detection shun

Shunned Host List:

asa(config)# sh run threat-detection

threat-detection basic-threat

threat-detection scanning-threat shun

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

asa(config)# threat-detection scanning-threat shun except ip-address

10.1.1.100 255.255.255.255





1.15 Application-Aware Inspection.

IM is becoming an issue in the workplace. Specifically a host 10.1.1.86 has been leaking confidential information via yahoo messenger. Create a policy that will reset the connection for this host only if Yahoo Messenger is used. Do not allow ANY yahoo services. Apply this policy to the Inside interface.

Watch HTTP connections to the ACS. If there are any protocol violations you should reset the connection. Also, ensure that the ACS server appears to be an Apache 1.1 server regardless of what it really is.


There are no issues with this Task.















Lab 2A: Configure Secure Networks using Cisco IOS

Firewalls






2.0 Cisco IOS Firewall Configuration Detailed Solutions


2.1 Base Configuration

Configure R9 as an NTP master. Configure the Clock and Time zone on all the routers/switches based on EST (-5 GMT), account for daylight savings time. Make sure the clocks of all the routers/switches are synchronized to R9.

Use the Loopback0 address of each router as the source for NTP requests, except R9 source from Fa0/1, R8 BVI1, and the Catalysts source from their VLAN interface. Authenticate all NTP Associations using password “ipexpert.”

In this lab you should allow ICMP echo, echo-reply and traceroute even when not specified by a task for firewall or filtering rules. No other ICMP traffic should be allowed. If a task requires logging, make sure to send the logs to ACS.

Configuration

R9

clock timezone EST -5

clock summer-time EDT recurring

!

ntp authentication-key 1 md5 ipexpert

ntp trusted-key 1

ntp source FastEthernet0/1

ntp master 2

R1 – R7



!


ntp trusted-key 1

ntp source Loopback0

ntp server 9.9.156.9 key 1

ntp authenticate

R8



!


ntp trusted-key 1

ntp source BVI1


ntp authenticate

Cat2 – Cat4






!


ntp authenticate

ntp trusted-key 1


Cat2

ntp source VLAN12

Cat3

ntp source VLAN13

Cat4

ntp source VLAN146


In this lab, you will find it important to have first enabled NTP as we are doing a few features on the devices, such as time based ACL‟s on R5, that require accurate time. R8 has not yet been configured so you may want to configure the briding on R8 so that you can finish the NTP configuration or leave it for the transparent firewall task.

The last bullet point is informational for us for future tasks. We should allow only echo, echo-reply, and unreachables when requested in future tasks. It ends up being that we will need to add additional information to our access-lists as you can only specify the ICMP protocol and not the more specific types when doing inspection.

Verification

NTP association using 12.4T code seems to have become quite slow at finishing the synchronization phase. If you can get the command show ntp association detail to show that it is configured and authenticated then move on to something else. Sometimes it can take a great deal of time to finish synchronization.

R6(config)#do sh ntp ass detail

9.9.156.9 configured, authenticated, insane, invalid, unsynced, stratum 16

ref ID .INIT., time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)

our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 1024

root delay 0.00 msec, root disp 0.00, reach 0, sync dist 16.00

delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00

precision 2**24, version 4

org time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)

rec time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)

xmt time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)

filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filterror = 16.00 16.00 16.00 16.00 16.00 16.00 16.00 16.00

minpoll = 6, maxpoll = 10

R6(config)#

It is getting closer now as it now accepts the stratum level from R9





9.9.156.9 configured, authenticated, insane, invalid, stratum 2

ref ID 127.127.7.1 , time CDB4C0A5.A54770B6 (23:44:37.645 EDT Tue May 12 2009)

our mode client, peer mode server, our poll intvl 64, peer poll intvl 64




org time CDB4C0AD.52916ACD (23:44:45.322 EDT Tue May 12 2009)

rec time CDB4C0AD.51267EE1 (23:44:45.316 EDT Tue May 12 2009)

xmt time CDB4C0AD.50916C6A (23:44:45.314 EDT Tue May 12 2009)

filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filterror = 0.00 0.00 0.00 16.00 16.00 16.00 16.00 16.00


R6(config)#

And finally:


9.9.156.9 configured, authenticated, our_master, sane, valid, stratum 2

ref ID 127.127.7.1 , time CDB4C2E5.A54507FB (23:54:13.645 EDT Tue May 12

2009)





org time CDB4C2F6.52527876 (23:54:30.321 EDT Tue May 12 2009)

rec time CDB4C2F6.50F16E9C (23:54:30.316 EDT Tue May 12 2009)

xmt time CDB4C2F6.5059CA95 (23:54:30.313 EDT Tue May 12 2009)

filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filterror = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00


R6(config)#

Check R1, R2, R4, R5, and Cat2 that don‟t require additional configuration at this time for this to work.

R1(config)#do sh ntp ass detail | incl auth|mode|127


ref ID 127.127.7.1 , time CDB4C325.A544A4DD (23:55:17.645 EDT Tue May 12

2009)


R1(config)#

R2(config-router)# do sh ntp ass detail | incl auth|mode|127


ref ID 127.127.7.1 , time CDB4C365.A54474D8 (23:56:21.645 EDT Tue May 12

2009)


R2(config-router)#

R4(config-if)# do sh ntp ass detail | incl auth|mode|127


ref ID 127.127.7.1, time CDB4C465.A543375F (00:00:37.645 EDT Wed May 13 2009)


R4(config-if)#




R5(config-router)# do sh ntp ass detail | incl auth|mode|127

9.9.156.9 configured, authenticated, insane, invalid, stratum 2

ref ID 127.127.7.1 , time CDB4C465.A543375F (00:00:37.645 EDT Wed May 13

2009)


R5(config-router)#

R5 still hasn‟t synchronized but it will.

Cat2(config-router)# do sh ntp ass detail | incl auth|mode|127


ref ID 127.127.7.1, time CDB4C225.A545E3C6 (23:51:01.645 EDT Tue May 12 2009)


Cat2(config-router)#

End Verification

2.2 NAT

Configure R5 to NAT 10.0.45.4 to 9.4.45.4. Configure a pool using 9.4.45.0/24 for the rest of the devices on 10.0.45.0/24.

Configure R2 to hide the private addresses 10.1.1.0/24 and 10.0.13.0/24. ACS should appear to the outside as 9.2.1.100 but if attempting to connect to a device on VLAN 12 or a device on VLAN 12 attempts to connect to ACS, it should appear as 192.1.49.150.

Cat3 should appear to the outside as 9.2.13.13 but if attempting to connect to devices on VLAN 45 or devices on VLAN 45 attempting to connect to Cat3, it should appear as 9.9.156.13.

Allow the rest of the IP‟s in VLAN10 and VLAN13 to be translated to R2 Gi0/1.1256.

Configure R2 to keep these PAT translations for ICMP traffic for 3 seconds, UDP for 60 seconds, and TCP for 40 seconds. If a TCP packet doesn‟t complete communication for either FIN or SYN state R2 should remove the translation after 20 seconds.

On R7 configure NAT support. Don not specify an inside our outside for NAT.

Configure R7 to NAT 10.0.7.100 to 9.7.7.100 and 10.0.7.10 to 9.7.7.10. NAT the rest of the 10.0.7.0/24 to 9.7.7.101-9.7.7.250. If addresses are exhausted allow for PAT.

Limit the maximum number of NAT translations for any given host on R7 to 25 translations.

Do not add any static routes to complete this section using the command “ip route…”

The private address space behind these routers should not be advertised to any other outside router unless required by a future task.

Configuration

R5


ip nat inside


ip nat outside

access-list 105 permit ip 10.0.45.0 0.0.0.255 any

ip nat pool POOL 9.4.45.5 9.4.45.254 netmask 255.255.255.0 add-route




ip nat inside source static 10.0.45.4 9.4.45.4

ip nat inside source list 105 pool POOL

R2

interface Gi0/1

ip nat inside

interface Gi0/1.12

ip nat outside

interface Gi0/1.13

ip nat inside

interface Gi0/1.1256

ip nat outside

!

ip nat pool POOL1 9.2.1.150 9.2.1.150 prefix-length 24 add-route


ip nat translation tcp-timeout 40

ip nat translation udp-timeout 60

ip nat translation finrst-timeout 20

ip nat translation syn-timeout 20

ip nat translation icmp-timeout 3

!

ip access-list extended NAT

deny ip host 10.1.1.100 any


permit ip 10.1.1.0 0.0.0.255 any

permit ip 10.0.13.0 0.0.0.255 any

ip access-list extended REST

deny ip host 10.1.1.100 192.1.49.0 0.0.0.255

deny ip host 10.0.13.13 9.4.45.0 0.0.0.255

permit ip host 10.1.1.100 any

permit ip host 10.0.13.13 any

ip access-list extended VLAN12

permit ip host 10.1.1.100 192.1.49.0 0.0.0.255


permit ip host 10.0.13.13 9.4.45.0 0.0.0.255

!

route-map REST permit 10

match ip address REST

route-map VLAN45 permit 10

match ip address VLAN45

route-map VLAN12 permit 10

match ip address VLAN12

!

ip nat inside source list NAT interface Gi0/1.1256 overload

ip nat inside source static 10.1.1.100 9.2.1.100 route-map REST reversible


ip nat inside source static 10.0.13.13 9.9.156.13 route-map VLAN45 reversible

ip nat ins source static 10.1.1.100 192.1.49.150 route-map VLAN12 reversible

R7


ip nat enable


ip nat enable

Altough the task did not require a pool on R2 using a pool with the add-route option will add the route to the routing table without using the command “ip route…”

Timeout parameters for NAT are configured globally under the translation options. These timeouts are for the use of the overload option on a nat statement.

The reversible keyword allows for inside to outside and outside to inside translation.




ip nat translation max-entries all-host 25

ip nat pool POOL 9.7.7.101 9.7.7.250 prefix-length 24 add-route

ip nat source list NAT_DHCP pool POOL overload

ip nat source static 10.0.7.10 9.7.7.10

ip nat source static 10.0.7.100 9.7.7.100

!

ip access-list extended NAT_DHCP



permit ip 10.0.7.0 0.0.0.255 any


NAT configuration guide and command reference are the best resources for NAT configuration options. NAT is definitely a very useful tool for both real world implementations and for getting around requirements in the lab.

When configuring route-map support on static translations with multi-direction NAT rules it is important to add the reversible keyword to allow inbound connection from external networks.

Be sure to be familiar with the global settings with NAT. What protocols can be tuned for translations, etc. On R7 we limited the max NAT entries permited per host which can be useful in a network attack scenario.

On R7 the task states to not define an inside or outside network. This is accomplished using the command ip nat enable. This is a good way to do NAT on routers as it doesn‟t matter for direction any more. Traffic is translated based on rules you define in your NAT entries. The shortcomings to this method is at this time Zone Based Firewall does not work with this NAT technique. As well, you cannot generate traffic on the router and test NAT translations. Traffic needs to be generated by a device beyond the router. This method should be used when configuring VRF aware NAT. But VRF NAT is beyond the scope of the Security lab at this time.

In this task there were restrictions on using static routes to announce networks. When static entries are created these networks are not added to the router if the networks are not tied to a physical interface. By creating a pool with the “add-route” option a static route is created to the NVI0 interface allowing for redistribution into the routing protocols.

Verification

R5 is pretty basic, so we can just do a ping from R4 to R9 and make sure it works.

R4(config-if)#do ping 9.9.156.9



!!!!!


R4(config-if)#

R5(config)#do sh ip nat tr

Pro Inside global Inside local Outside local Outside global

icmp 9.4.45.4:2 10.0.45.4:2 9.9.156.9:2 9.9.156.9:2

--- 9.4.45.4 10.0.45.4 --- ---

R5(config)#

Good. Now test to see if the translations for ACS are working correctly based on destination/source.

http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_natrodmap_ps6441_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/docs/ios/ipaddr/command/reference/iad_nat.html

http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iadnat_addr_consv.html#wp1086004



http://www.cisco.com/en/US/docs/ios/ipaddr/command/reference/iad_nat.html#wp1011476

http://www.cisco.com/en/US/docs/ios/ipaddr/command/reference/iad_nat.html#wp1026252















And the Translation:

R2(config-ext-nacl)#do sh ip nat tr


icmp 192.1.49.150:768 10.1.1.100:768 192.1.49.12:768 192.1.49.12:768

--- 9.2.1.100 10.1.1.100 --- ---

--- 9.2.13.13 10.0.13.13 --- ---

--- 9.9.156.13 10.0.13.13 --- ---

--- 192.1.49.150 10.1.1.100 --- ---

R2(config-ext-nacl)#

Okay. And out to something else:














icmp 9.2.1.100:768 10.1.1.100:768 9.9.156.9:768 9.9.156.9:768

--- 9.2.1.100 10.1.1.100 --- ---

--- 9.2.13.13 10.0.13.13 --- ---

--- 9.9.156.13 10.0.13.13 --- ---

--- 192.1.49.150 10.1.1.100 --- ---


Cool. Now test the other direction to make sure it is bi-directional:




R9(config-router)#do ping 9.2.1.100 repeat 10



!!!!!!!!!!


R9(config-router)#



icmp 9.2.1.100:30 10.1.1.100:30 9.9.156.9:30 9.9.156.9:30

--- 9.2.1.100 10.1.1.100 --- ---

--- 9.2.13.13 10.0.13.13 --- ---

--- 9.9.156.13 10.0.13.13 --- ---

--- 192.1.49.150 10.1.1.100 --- ---


We can see the timeouts we configured on R2 are working by sending a ping from Vlan10 interface.

R2#ping 4.4.4.4 sou Gi0/1



Packet sent with a source address of 10.1.1.1

!!!!!


R2#sh ip nat tr ver


udp 9.2.13.13:123 10.0.13.13:123 9.9.156.9:123 9.9.156.9:123

create 00:48:05, use 00:03:15 timeout:300000, left 00:01:44,

flags:

extended, use_count: 0, entry-id: 3, lc_entries: 0

--- 9.2.13.13 10.0.13.13 --- ---

create 00:48:23, use 00:48:05 timeout:0,

flags:

static, use_count: 1, entry-id: 2, lc_entries: 0

icmp 9.9.156.2:7 10.1.1.1:7 4.4.4.4:7 4.4.4.4:7

create 00:00:01, use 00:00:01 timeout:3000, left 00:00:01, Map-Id(In): 1,

flags:

extended, use_count: 0, entry-id: 5, lc_entries: 0

--- 9.2.1.100 10.1.1.100 --- ---

create 00:50:48, use 00:50:48 timeout:0,

flags:

static, use_count: 0, entry-id: 1, lc_entries: 0

R2#

Above you notice the timeout is 3000ms or 3 seconds.

Make sure the NAT Networks are getting into the routing table on R2

R2#sh ip route static

9.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

S 9.2.13.0/24 [0/0] via 0.0.0.0, NVI0

S 9.2.1.0/24 [0/0] via 0.0.0.0, NVI0

R2#




R2#show ip bgp



internal,




*> 1.0.0.0 9.9.156.11 0 1256 16 i

*> 2.0.0.0 0.0.0.0 0 32768 i

*> 4.0.0.0 9.9.156.5 0 1256 5 i

*> 5.0.0.0 9.9.156.5 0 1256 5 i

*> 6.0.0.0 9.9.156.6 0 1256 16 i

*> 9.0.0.0 9.9.156.9 0 0 1256 i

*> 9.2.1.0/24 0.0.0.0 0 32768 i

*> 9.2.13.0/24 0.0.0.0 0 32768 i

*> 192.1.49.0 0.0.0.0 0 32768 i

R2#

Note: The tests below are working after having completed the Transparent Firewall Configuration on R8.

Now move on to R7. If you source a ping on R7 from R7 Fa0/1 it will not work as this is locally generated traffic. We can only test from another router to R7 and see if it works for you.

R7(config)#do debug ip nat

IP NAT debugging is on

R7(config)#do ping 9.9.156.5 sour f0/1




.....


R7(config)#

In a later section you will configure Cat1 and XP as a DHCP client on VLAN 7. We will use Cat1 right now to test NAT.

Cat1(config-if)#do ping 9.9.156.9



!!!!!


Cat1(config-if)#

Cat1(config-if)#do ping 9.9.156.5



!!!!!


Cat1(config-if)#

R7(config)#

*May 13 19:14:52.185: NAT*: s=10.0.7.10->9.7.7.10, d=9.9.156.5 [24]

*May 13 19:14:52.189: NAT*: s=9.9.156.5, d=9.7.7.10->10.0.7.10 [24]

*May 13 19:14:52.193: NAT*: s=10.0.7.10->9.7.7.10, d=9.9.156.5 [25]

*May 13 19:14:52.193: NAT*: s=9.9.156.5, d=9.7.7.10->10.0.7.10 [25]




*May 13 19:14:52.193: NAT*: s=10.0.7.10->9.7.7.10, d=9.9.156.5 [26]

*May 13 19:14:52.197: NAT*: s=9.9.156.5, d=9.7.7.10->10.0.7.10 [26]

*May 13 19:14:52.197: NAT*: s=10.0.7.10->9.7.7.10, d=9.9.156.5 [27]

*May 13 19:14:52.201: NAT*: s=9.9.156.5, d=9.7.7.10->10.0.7.10 [27]

*May 13 19:14:52.205: NAT*: s=10.0.7.10->9.7.7.10, d=9.9.156.5 [28]

R7(config)#

R7(config)#do sh ip nat nvi translation

Pro Source global Source local Destin local Destin global

--- 9.7.7.10 10.0.7.10 --- ---

--- 9.7.7.100 10.0.7.100 --- ---

icmp 9.7.7.10:4 10.0.7.10:4 9.9.156.9:4 9.9.156.9:4

icmp 9.7.7.10:5 10.0.7.10:5 9.9.156.5:5 9.9.156.5:5

R7(config)#

Note the difference when checking for translations when doing this newer command. You need to add the “nvi” option.

End Verification

2.3 Legacy Resource Protection

On R5 allow HTTP and HTTPS destined to a Web Server located at 9.9.45.4 from anywhere coming in through Fa0/1.1256. Traffic Filtering should be done on this external facing interface.

To protect this web server from TCP SYN attacks configure R5 to protect this server against attacks. R5 should begin to drop connections if the amount of half open connections exceeds 300. It should return to normal after this number falls below 150. When the router does enter aggressive mode change the default behavior for half open sessions. Exclude the PAT‟ed devices behind R2.

The above mentioned Web Server will be taken down for Maintenance and Backups between 1:00 AM and 3:00 AM every Wednesday. The Maintenance schedule will come into effect on the 1st of the month for the next 6 months. Do not allow communication to it during these maintenance windows.

Configuration

R4

ip domain-name ipexpert.com

crypto key generate rsa general-keys modulus 1024

ip http server


do write memory

R5

time-range WEB-MAINT

absolute start 00:00 01 June 2009 end 23:59 30 November 2009

periodic Wednesday 1:00 to 2:59

!

ip access-list extended IN-FILTER

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any unreachable




deny tcp any host 9.4.45.4 eq www time-range WEB-MAINT

deny tcp any host 9.4.45.4 eq https time-range WEB-MAINT

permit tcp any host 9.4.45.4 eq www

permit tcp any host 9.4.45.4 eq https

permit tcp host 9.9.156.9 eq 179 host 9.9.156.5 gt 1024

permit tcp host 9.9.156.9 gt 1024 host 9.9.156.5 eq 179

permit udp host 9.9.156.9 eq 123 host 4.4.4.4 eq 123


!


ip access-group IN-FILTER in

!

ip tcp intercept list WEB_SERVER

ip tcp intercept max-incomplete low 150 high 300

ip tcp intercept mode watch

ip tcp intercept drop-mode random

!

ip access-list extended WEB_SERVER

deny tcp host 9.9.156.2 host 10.0.45.4

permit tcp any host 10.0.45.4

!

logging on

logging host 9.2.1.100


Time Ranges allow the application of rules based on date and time. It is important to note if it states to end a time range at 5:00 PM you actually need to set it to 16:59 which causes the time range to go to 16:59:59 and end at 5:00 PM. Finding the documentation is also not intuitive. Since time ranges are for extended ACL‟s you would think they documentation would be under the security documentation but it is under Network Management > Performing Basic System Management.

In our access-list we went ahead and included a few extra lines that we would need to include for the next section as we need to maintain connectivity.

TCP intercept in watch mode can be useful to help protect devices behind a router. With an access list applied to the intercept process any deny statements will not be checked by the router. They will continue directly to the Server. The reason it becomes important to test though is due to NAT occurring on R5. Traffic from ACS will be destined to 9.4.45.4 but through order of operations when tcp intercept sees the traffic it will have been translated to the inside local address. Be sure to test as much as possible when configuring tasks for labs and the real test.

The default behavior for half open sessions for TCP intercept is oldest. In this question we are requested to change the default behavior so it was changed to random. Don‟t forget the Base Configuration task required us to enable logging to ACS when we enabled a logging feature.

Verification

First we can test this configuration on R5 by using ACS to connect to R4 Web Ports. You can test both https and http. Then we can disable NTP and change the clock on R5 to test the time-range to make sure the time-range is working correctly.

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_basic_sys_manage_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1001647

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_tcp_intercpt.html#wp1001032




R5#show tcp intercept connections

Incomplete:

Client Server State Create Timeout Mode

9.2.1.100:4827 10.0.45.4:443 SYNSENT 00:00:04 00:00:25 W

9.2.1.100:4828 10.0.45.4:80 SYNSENT 00:00:01 00:00:28 W

Established:


R5#

R5#clock set 1:38:00 24 June 2009

R5#

.Jun 24 05:38:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from

10:43:37 EDT Thu Jun 25 2009 to 01:38:00 EDT Wed Jun 24 2009, configured from

console by console.

R5#show clock

.01:38:29.432 EDT Wed Jun 24 2009

R5#show time-range

time-range entry: WEB-MAINT (active)



used in: IP ACL entry


R5#

R5#show ip access-list IN-FILTER

Extended IP access list IN-FILTER

10 permit icmp any any echo

20 permit icmp any any echo-reply

30 permit icmp any any unreachable

40 deny tcp any host 9.4.45.4 eq www time-range WEB-MAINT (active) (6 matches)

50 deny tcp any host 9.4.45.4 eq 443 time-range WEB-MAINT (active) (6 matches)

60 permit tcp any host 9.4.45.4 eq www

70 permit tcp any host 9.4.45.4 eq 443

80 permit tcp host 9.9.156.9 eq bgp host 9.9.156.5 gt 1024

90 permit tcp host 9.9.156.9 gt 1024 host 9.9.156.5 eq bgp (9 matches)

100 permit udp host 9.9.156.9 eq ntp host 4.4.4.4 eq ntp (1 match)

110 permit udp host 9.9.156.9 eq ntp host 5.5.5.5 eq ntp

R5#

And last we can change it back and see the time-range change to inactive and the ACL entries will no longer be matched.

R5#show ip access-list IN-FILTER





40 deny tcp any host 9.4.45.4 eq www time-range WEB-MAINT (inactive) (6 matches)

50 deny tcp any host 9.4.45.4 eq 443 time-range WEB-MAINT (inactive) (6 matches)

60 permit tcp any host 9.4.45.4 eq www (7 matches)

70 permit tcp any host 9.4.45.4 eq 443 (11 matches)



100 permit udp host 9.9.156.9 eq ntp host 4.4.4.4 eq ntp (2 matches)


R5#

End Verification




2.4 Legacy Traffic Control

On R5 allow users on 10.0.45.0 network to reach external networks. Allow the following:

SSH to the Catalyst Switches listed in the Topology SMTP DNS HTTP HTTPS

The return entries should be automatically created for the above mentioned traffic. These entries should expire after 3 minutes for TCP based protocols. DNS entries should expire after 1 minute. Use minimum configuration lines to accomplish this without the use of anything newer than 12.1 Mainline.

Only allow SSH on the VTY lines for the Catalyst switches. The user should be automatically put into level 15. Do not use AAA.

In Addition users from the 10.0.45.0 network should be able to go to the outside networks and return for other TCP based traffic without the use of reflexive ACL‟s or CBAC.

Only allow DNS queries to be sent to ACS. The ACL entry should be as specific as possible.

Users on the 10.0.45.0 network are only allowed to browse the Web during the following times:

12:00 to 1:00 PM on Weekdays 5:00 PM to Midnight on Weekdays All day on Saturday and Sunday

Filter all RFC 1918 addresses without these being logged. Also block any address that should never be in the source address field. But do log this specific traffic; include with this log the source MAC.

You cannot use CBAC to accomplish the tasks in this section. Allow relevant traffic coming in. Make sure Routing is still working after you are done with this task. Be sure to log any additional traffic that violates these rules.

Configuration

R5

time-range WEB-ACCESS

periodic weekdays 12:00 to 12:59


periodic weekend 0:00 to 23:59

!

ip access-list extended OUT-FILTER




permit tcp 9.4.45.0 0.0.0.255 host 192.1.49.12 eq 22 ref REF-ACL timeout 180



permit tcp 9.4.45.0 0.0.0.255 any eq smtp reflect REF-ACL timeout 180

permit tcp 9.4.45.0 0.0.0.255 any eq www ref REF-ACL timeo 180 time-r WEB-

ACCESS

permit tcp 9.4.45.0 0.0.0.255 any eq 443 ref REF-ACL timeo 180 time-r WEB-

ACCESS

deny tcp 9.4.45.0 0.0.0.255 any eq www log

deny tcp 9.4.45.0 0.0.0.255 any eq 443 log




permit tcp any any

permit udp 9.4.45.0 0.0.0.255 host 9.2.1.100 eq 53 reflect REF-ACL time 60



250 deny ip any any log

!

no ip access-list extended IN-FILTER

!


deny ip 10.0.0.0 0.255.255.255 any

deny ip 172.16.0.0 0.15.255.255 any

deny ip 192.168.0.0 0.0.255.255 any

deny ip host 0.0.0.0 any log

deny ip 127.0.0.0 0.255.255.255 any log-input



deny ip host 255.255.255.255 any log-input




deny tcp any host 9.4.45.4 eq www time-range WEB-MAINT

deny tcp any host 9.4.45.4 eq 443 time-range WEB-MAINT

permit tcp any host 9.4.45.4 eq www

permit tcp any host 9.4.45.4 eq 443

permit tcp host 9.9.156.9 eq bgp host 9.9.156.5 gt 1024

permit tcp host 9.9.156.9 gt 1024 host 9.9.156.5 eq bgp

permit udp host 9.9.156.9 eq ntp host 4.4.4.4 eq ntp


eval REF-ACL

permit tcp any 10.0.45.0 0.0.0.255 established


!


ip access-group OUT-FILTER out

Cat2, Cat3, and Cat4



!

username ipexpert privilege 15 pass ipexpert

!

line vty 0 15

login local

transport input ssh


Time Ranges allow the application of rules based on date and time. It is important to note if it states to end a time range at 5:00 PM you actually need to set it to 16:59 which causes the time range to go to 16:59:59 and end at 5:00 PM. Finding the documentation is also not intuitive. Since time ranges are for extended ACL‟s you would think they documentation would be under the security documentation but it is under Network Management > Performing Basic System Management.

NAT can really throw a wrench into your work with all of these rules and such. Remember that traffic coming from VLAN 45 to Cat2 is going to be destined to 9.9.156.13. Also the outbound

Be cautious blocking 0.0.0.0 as DHCP clients will send traffic from this source when doing the initial request to 255.255.255.255. There should be no DHCP requests going into R5 though

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_basic_sys_manage_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1001647




filter takes place after NAT so you need to specify the global IP of VLAN 45It is important that all the deny statements for the RFC 1918 and invalid source addresses are denied before any other statements in the ACL with any as the source. In the lab we stated you can permit ICMP, echo, echo-reply, and unreachables but these should not be allowed from the networks that should never have access. If you didn‟t want to remove the access-list but instead modify the ACL and insert the lines into your ACL before the previous line you could have modified the ACL using resequencing. ACL Modification can be important when you forget to add a line before a deny statement and you don‟t want to remove an ACL and re-apply. You can simply add the entry into the ACL where required.

In the task we were also told that we need to allow TCP connections coming back in from external that have already been allowed out. This is accomplished using the keyword “established.”

Reflexive ACL‟s are not supported with numbered ACLs on the ISR routers. If you had attempted to create a Reflexive ACL with a numbered ACL you would not have found the option available. By adding the timeout option to the ACLs above we have defined the absolute length of time, in seconds, that ther reflexive ACL list entry can remain in a dynamic access list. 180 seconds for the TCP sessions and 60 seconds for UDP, DNS.

Verification

Test the reflexive entries by sending traffic from R4. Remember to change the clock on R5 again to test the Web access.

R5#show ip access-lists REF-ACL

Reflexive IP access list REF-ACL

R5#

R4#ssh -l ipexpert 9.16.146.14

Password:

Cat4#


Password:

Cat3#


Password:

Cat2#

R4#

R5#sh ip access-list REF-ACL


permit tcp host 9.16.146.14 eq 22 host 9.4.45.4 eq 50111 (1 match) (time

left 25)

R5#



permit tcp host 9.9.156.13 eq 22 host 9.4.45.4 eq 31833 (38 matches)

(time left 176)

R5#

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_refine_IP_al.html

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_ip_filter.html







(time left 175)

R5#

Now for web browsing. Currently the traffic will not be allowed based on the time of day.

R4#telnet 9.2.1.100 80

Trying 9.2.1.100, 80 ...

% Destination unreachable; gateway or host down

R4#

R5#

May 14 19:07:48.558: %SEC-6-IPACCESSLOGP: list OUT-FILTER denied tcp

9.4.45.4(36971) -> 9.2.1.100(80), 1 packet

R5#

Let‟s change the time and retest:

R5#clock set 17:38:00 14 May 2009

R5#

.May 14 21:38:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from

15:09:09 EDT Thu May 14 2009 to 17:38:00 EDT Thu May 14 2009, configured from

console by console.

R5(config)#no ntp server 9.9.156.9

R5(config)#end

R5#

.May 14 21:38:27.884: %SYS-5-CONFIG_I: Configured from console by console

R5#show clock

.17:38:32.352 EDT Thu May 14 2009

R5#show time-range WEB-ACCESS

time-range entry: WEB-ACCESS (active)






R5#

And again from R4:

R4#telnet 9.2.1.100 80

Trying 9.2.1.100, 80 ... Open

Get


Content-Type: text/html

Date: Thu, 14 May 2009 18:14:45 GMT

Connection: close

Content-Length: 35

<h1>Bad Request (Invalid Verb)</h1>


R4#




R5#show ip access-list OUT-FILTER

Extended IP access list OUT-FILTER 10 permit icmp any any echo (10 matches)

20 permit icmp any any echo-reply (5 matches)


40 permit tcp 9.4.45.0 0.0.0.255 host 192.1.49.12 eq 22 reflect REF-ACL (58 matches)



70 permit tcp 9.4.45.0 0.0.0.255 any eq smtp reflect REF-ACL

80 permit tcp 9.4.45.0 0.0.0.255 any eq www time-range WEB-ACCESS (active) reflect REF-ACL (9

matches)

90 permit tcp 9.4.45.0 0.0.0.255 any eq 443 time-range WEB-ACCESS (active) reflect REF-ACL

100 deny tcp 9.4.45.0 0.0.0.255 any eq www log (1 match)

110 deny tcp 9.4.45.0 0.0.0.255 any eq 443 log

120 permit tcp any any (3 matches)

130 permit udp 9.4.45.0 0.0.0.255 eq domain host 9.2.1.100 eq domain reflect REF-ACL



160 deny ip any any log (6 matches)

R5#

End Verification

2.5 Lock and Key Access Lists

You need to allow access to a web server at 4.4.4.4 but not without authenticated access. Configure R5 to authenticate users prior to allowing access to a web server located at 4.4.4.4. After authentication all TCP traffic from the authenticated host should be allowed. This should not affect normal VTY access.

Use username and password “ccie.” This user should not be allowed to login to R5 for local access.

The session should be open at most for 100 minutes. Unless the user authenticates again during the active session. If this does occur it should then be extended for an additional 6 minutes. Force an idle session to timeout after 10 minutes.

Authenticated users should be able to SSH into R4 and R5 for Management access.

Create username ipexpert and password ipexpert on R4 and R5. Log the user to privilege 15 using local AAA authentication and authorization.

Neither of these usernames or passwords should be sent in clear text.

Configuration

R4

aaa new-model

aaa authentication login default none

aaa authentication login VTY local

aaa authorization exec VTY local

!


!

line vty 0 4

login authentication VTY

authorization exec VTY

transport input ssh




R5

ip domain name ipexpert.com

crypto key generate rsa general modulus 1024

aaa new-model


aaa authentication login VTY local

aaa authentication login LOCK-KEY local

aaa authorization exec VTY local

!

username ccie password ccie

username ccie autocommand access-enable host timeout 10


!

access-list dynamic-extended

!



222 dynamic DYN-LIST timeout 100 permit tcp any any

!

line vty 0 4



transport input ssh


Lock and Key access-lists are an older method but still works very well. It prevents access to network resources until a user has successfully authenticated to a host. In the task we are told a few requirements that should be completed for this task.

First AAA should not affect console access so make sure you either set the default login method to none or that you created a named authentication list with the authentication group none and applied it to the line console.

The command access-list dynamic-extended is supposed to allow a user to re-authenticate during an active session to increase the absolute timeout by 6 minutes. I am not sure of a verification method for this other than waiting around for 106 minutes. This may be more of a task of completing the requirement for this particular requirement.

To put a user into a privilege level it requires exec authorization. To prevent user ccie from gaining local shell access the autocommand is applied to the username. Thus anytime the user attempts to access to the device the command is automatically sent and the user is disconnected from the VTY. By applying the autocommand to the user instead of the VTY line, as shown in the examples for Lock and key access-lists examples in Cisco Documenation, it allows the VTY lines to still be used for user access.

Additional options that were applied to the autocommand are “host” and “timeout.” By putting in the host option we meet the requirement to only allow access to the authenticated host. Without this option when the dynamic entry is created, whatever you have defined for the dynamic ACL is allowed. Thus in the instance of what was configured above a source of any would have been allowed.

The timeout option on autocommand is for idle-timeout. The absolute timeout was applied to the dynamic ACL entry. Without this timeout option the default is indefinite.

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_lock_key_secrty.html#wp1001063

http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_cfg_authentifcn_ps6441_TSD_Products_Configuration_Guide_Chapter.html




Last the question stated we should not allow these passwords to be sent in clear text. To prevent this telnet must be disabled. This was accomplished by restricting the transport input to SSH.

Verification

Test by connecting to R5 from R9. We should be able to Connect to any resources behind R5 after successful authentication.

R9#ssh -l ccie 9.9.156.5

Password:


R9(config)#


Trying 4.4.4.4, 80 ... Open

get


Date: Thu, 14 May 2009 21:51:00 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request



Password:

R4#

R5#sh ip access-list IN-FILTER | incl 156.9|DYN

170 permit tcp host 9.9.156.9 eq bgp host 9.9.156.5 gt 1024 (380 matches)




222 Dynamic DYN-LIST permit tcp any any

permit tcp host 9.9.156.9 any (18 matches) (time left 548)

R5#

End Verification

2.6 IOS Stateful Firewall

R1 and R6 will be running as a stateful failover pair. Configure HSRP on Fa0/1.146 and Fa0/1.1256. Use the address of x.x.x.1 as the HSRP address for each interface and the standby group number should be the same as the IP address third octet. Configure redundancy using the external standby group.

Authenticate the standby groups using password ipexpert. Make sure the password is sent encrypted.

R1 should be configured as the active router unless one of the interfaces IP routing is not functioning, if it can‟t ping R9, or if R1 goes offline. If R1 does go down make sure it




waits at least 30 seconds before becoming the active router after a failure but 60 seconds if it is after a reload. R6 should become the active router in the event of a failure after 4 lost hellos and in less than 1 second. Configure the priority on R6 as 60 and R1 priority should be 110.

Make sure that future tasks which require configuration on R1 or R6, the same tasks are completed on the stateful pair even if the question doesn‟t specify to do so.

You have noticed when the connection table runs over 3000 connection entries, you experience performance problems. Correct this problem.

Configuration

R1

redundancy inter-device

scheme standby REDUNDANCY

!

ipc zone default

association 1

no shutdown

protocol sctp

local-port 50001

local-ip 9.9.156.11

remote-port 55001

remote-ip 9.9.156.6

!

ip sla 3

icmp-echo 9.9.156.9 source-ip 9.9.156.11

timeout 300

frequency 1

ip sla schedule 3 life forever start-time now

!

track 1 interface FastEthernet0/1.146 ip routing


track 3 ip sla 3

track 5 list boolean and

object 1

object 2

object 3

!

ip inspect name FW udp router-traffic

ip inspect name FW tcp router-traffic

!


ip virtual-reassembly

standby version 2

standby 146 ip 10.0.146.1

standby 146 timers msec 200 msec 800

standby 146 priority 110

standby 146 preempt delay minimum 30 reload 60 sync 30

standby 146 authentication md5 key-string ipexpert

standby 146 name INSIDE

standby 146 track 5 decrement 60

!





ip inspect FW out redundancy stateful REDUNDANCY


standby version 2

standby 156 ip 9.9.156.1





standby 156 name REDUNDANCY


R6

redundancy inter-device

scheme standby REDUNDANCY

!

ipc zone default

association 1

no shutdown

protocol sctp

local-port 55001

local-ip 9.9.156.6

remote-port 50001

remote-ip 9.9.156.11

!

ip sla 3

icmp-echo 9.9.156.9 source-ip 9.9.156.6

timeout 300

frequency 1

ip sla schedule 3 life forever start-time now

!



track 3 ip sla 3

track 5 list boolean and

object 1

object 2

object 3

!



!



standby version 2

standby 146 ip 10.0.146.1





standby 146 name INSIDE


!







standby version 2

standby 156 ip 9.9.156.1







!

R1 and R6

ip inspect hash table 2048


In the previous tasks we worked a lot with advanced access-list features. In this section we have begun to work on some of the newer technologies. Context Based Access Control (CBAC) allows the dynamic creation of rules based on outbound traffic that is inspected. In this task the actual CBAC configuration was pretty basic as we concentrated more on the Stateful Failover feature introduced in 12.4(6)T.

Stateful failover relies on HSRP. At this current time it does not support VRRP for redundancy. When configuring HSRP it is important to make sure that all interface HSRP groups are active on the primary router. This makes it important to configure the interfaces to track interface states or the ability to maintain contact to an external source. If you do not employ tracking you can have a router become a black hole for traffic in your network.

HSRP by default runs version 1. Version 1 does not support the advertisement or learning msec hello timers. You can configure the lower hello times for HSRP version 1 but you are likely to run into issues with communication.

The default hello time is 3 seconds and the hold time is 3 times the hello. In this question we are asked to change the active router to R6 if there are 4 hellos lost in less than 1 second. So by changing the version to 2 and setting the hello interval to 200 milliseconds and the hold time to 800 milliseconds we meet the requirement of 4 lost hellos in less than 1 second. We could have used other numbers but 200 divides nicely into 800 4 times.

I recommend to name your standby groups when doing any type of feature that needs to call the group name. You can choose not to but the standby name by default is a little complex. I.E. “hsrp-Fa0/1.146-146.”

To encrypt authentication between the peers for HSRP you need to have selected MD5. The other option is to send the passwords in plain text.

Object Tracking can be done directly from HSRP configuration when doing simple interface or ip route tracking. But in the question we are asked to monitor three things for operation. This requires a little more advanced functionality that is only available from global configuration. That is the Boolean option. With the Boolean list we created in this task we did an and list. By doing this all three tracking objects must be operation for the track group to be considered up and operational. If one of the three tracked objects becomes inoperable the Boolean list will be considered down and the HSRP priority will be decremented by the given value. Be mindful in this task the priority of R1 is 110 and R6 is 60 se we need to decrement by at least 51 to decrease it less than R6.

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_content_ac.html

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_fwall_state_fov.html

http://www.cisco.com/en/US/docs/ios/ipapp/configuration/guide/ipapp_hsrp_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1056205

http://www.cisco.com/en/US/docs/ios/ipapp/configuration/guide/ipapp_eot_ps6441_TSD_Products_Configuration_Guide_Chapter.html




With the SLA configuration we needed to have it check for connectivity to R9 every second. This is the lowest interval you can configure but to have state changes for HSRP as soon after a failure we need to reduce this to the lowest denominator. This requires the timeout to be less than the interval.

In this task it was required to make R1 the active router and R6 the standby. In the configuration tasks it was also required to control the state changes of HSRP. When sharing session detail for CBAC the two routers need to be synchronized properly before a router becomes the active HSRP router. Above you can see the requirements being met by setting the failure times to 30 seconds and in the event of a reload the time was set to 60 seconds.

Both the configuration guides for these technologies are very useful, so I recommend reading the content from these links provided.

Lastly, it is recommended that when the number of connections exceeds twice the size of the hash table the size of the table should be increased. The default size of the hash table is 1024. When the number of sessions exceeds twice the size of the hash table it is likely to experience performance problems.

Verification

When configuring the redundancy configuration the active router will take the configuration without any problems. But the standby HSRP router will not allow the redundancy configuration to become active until after the first reload. I highly recommend to configure all your configuration on the active router first and then the standby router. If not you run into multiple reboots and it becomes annoying after a while. (You will figure this out pretty quickly after configuring inter-device redundancy a few times.)

R1#show redundancy inter-device

Redundancy inter-device state: RF_INTERDEV_STATE_ACT

Scheme: Standby

Groupname: REDUNDANCY Group State: Active

Peer present: RF_INTERDEV_PEER_NO_COMM

Security: Not configured

R1#


Redundancy inter-device state: RF_INTERDEV_STATE_INIT

Pending Scheme: Standby (Will not take effect until next reload)

Pending Groupname: REDUNDANCY

Scheme: <NOT CONFIGURED>

Peer present: UNKNOWN


R6#

After rebooting R6:



Scheme: Standby


Peer present: RF_INTERDEV_PEER_COMM


R1#

We are being told here that inter-device redunadcy is configured but the peer is not accepting connections

http://www.cisco.com/en/US/docs/ios/ipsla/configuration/guide/12_4t/sla_12_4t_book.html





Redundancy inter-device state: RF_INTERDEV_STATE_STDBY

Scheme: Standby

Groupname: REDUNDANCY Group State: Standby



R6#

You can see by interpreting the output above that R1 shows as the active router and R6 shows it is in standby state.

Communication between devices uses protocl SCTP. So checking the output of SCTP will show you the communication occurring and the sessions being shared between routers.

R1#show sctp instances

** SCTP Instances **

Instance ID: 1 Local port: 50002 State: available

Local addrs: 9.9.156.11

Default streams inbound: 2 outbound: 2

Adaption layer indication is not set

Current associations: (max allowed: 200)

AssocID: 1285510864 State: ESTABLISHED Remote port: 55002

Dest addrs: 9.9.156.6








R1#show sctp statistics

** SCTP Overall Statistics **

Control Chunks

Sent: 9133 Rcvd: 8990

Data Chunks Sent

Total: 1869 Retransmitted: 0

Ordered: 1869 Unordered: 0

Total Bytes: 345751

Data Chunks Rcvd

Total: 1156 Discarded: 0

Ordered: 1156 Unordered: 0

Total Bytes: 74184

Out of Seq TSN: 0

SCTP Dgrams

Sent: 9847 Rcvd: 8996

ULP Dgrams

Sent: 1869 Ready: 1156 Rcvd: 1156

Additional Stats

Instances Currently In-use: 2

Assocs Currently Estab: 2




Active Estab: 0 Passive Estab: 2

Aborts: 118 Shutdowns: 0

T1 Expired: 848 T2 Expired: 0

R1#

Lastly, we can check to make sure the session information is actually being shared among the routers. We can open an ssh session from Cat4 to R4. (The traffic is going thru R1 by default so we are looking for the sessions to be synchronized to R6.)

R1#show ip inspect sessions

Established Sessions

Session 48A9A828 (10.0.146.14:24707)=>(9.9.156.5:22) tcp SIS_OPEN

Session 48A9A560 (10.0.146.14:123)=>(9.9.156.9:123) udp SIS_OPEN

Session 48A9AAF0 (9.9.156.11:15555)=>(9.9.156.6:15555) udp SIS_OPEN

Session 48A9A298 (1.1.1.1:123)=>(9.9.156.9:123) udp SIS_OPEN

Half-open Sessions

Session 48A9ADB8 (9.9.156.11:1985)=>(224.0.0.102:1985) udp SIS_OPENING

R1#

R6#show ip inspect sessions


Session 48E682CC (10.0.146.14:24707)=>(9.9.156.5:22) tcp SIS_OPEN

Session 48E68594 (10.0.146.14:123)=>(9.9.156.9:123) udp SIS_OPEN

Session 48E6885C (1.1.1.1:123)=>(9.9.156.9:123) udp SIS_OPEN

Half-open Sessions

Session 48E68B24 (9.9.156.6:1985)=>(224.0.0.102:1985) udp SIS_OPENING

R6#

R6#show ip inspect ha sessions detail

Sess_ID (src_addr:port)=>(dst_addr:port) proto sess_state ha_state


48DBCC6C (10.0.146.14:59626)=>(9.9.156.5:00022) tcp SIS_OPEN HA_STANDBY

Created 00:00:26, Last heard never

Bytes sent (initiator:responder) [0:0]

In SID 9.9.156.5[22:22]=>9.16.146.14[59626:59626] on ACL FW

HA state: HA_STANDBY

Half-open Sessions

R6#

Cool. So, the session for Cat4 to R5 is shared between both devices. We could go thru the process of failing the devices to make sure everything is correct but having this information here tells us it is working. Now we can cause a failure to one of the interfaces on R1 and watch it fail to R6. We can do this by performing a shutdown on Cat2 Fa0/1. When this occurs R1 will reboot so that R6 can become the active HSRP router. When R1 becomes operational again R6 will reboot to let R1 again become the active router.

R1(config)#

May 15 02:14:51.208: %TRACKING-5-STATE: 1 interface Fa0/1.146 ip routing Up->Down


May 15 02:14:51.208: %TRACKING-5-STATE: 5 list boolean and Up->Down

May 15 02:14:51.968: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,

changed state to down

May 15 02:14:51.968: %HSRP-5-STATECHANGE: FastEthernet0/1.146 Grp 146 state Active ->

Init


Init




May 15 02:14:51.980: %RF_INTERDEV-4-RELOAD: % RF induced self-reload. my state =

ACTIVE peer state = STANDBY HOT

R1(config-subif)#

May 15 02:14:52.352: %RF-5-RF_RELOAD: Peer reload. Reason:

May 15 02:14:52.376: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 146: Neighbor 10.0.146.6

(FastEthernet0/1.146) is down: interface down



May 15 02:14:52.384: %BGP-5-ADJCHANGE: neighbor 9.9.156.9 Down Interface flap

R1(config-subif)#

Notice these changes on R6 as well:

R6(config-subif)#

*May 15 01:25:29.568: %HSRP-5-STATECHANGE: FastEthernet0/1.146 Grp 146 state Standby -

> Active

*May 15 01:25:29.616: %HSRP-5-STATECHANGE: FastEthernet0/1.1256 Grp 156 state Standby

-> Active

*May 15 01:25:29.624: %RF-5-RF_RELOAD: Peer reload. Reason:

*May 15 01:25:29.624: %FW_HA-6-AUDIT_TRAIL_STDBY_TO_ACT: Sessions matching HSRP group

REDUNDANCY are being transitioned from Standby to Active state

*May 15 01:25:41.440: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 146: Neighbor 10.0.146.11

(FastEthernet0/1.146) is down: holding time expired

*May 15 01:27:30.032: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down BGP Notification sent

*May 15 01:27:30.032: %BGP-3-NOTIFICATION: sent to neighbor 1.1.1.1 4/0 (hold time

expired) 0 bytes

R6(config-subif)#

End Verification

2.7 Stateful NAT

Configure R1 and R6 for stateful NAT. Use the external HSRP group for redundancy.

10.0.146.14 should be translated to 9.16.146.14. In addition configure R1 and R6 to NAT the rest of the 10.0.146.0/24 network to 9.16.146.0/24. This should all be completed in as few commands as possible and should support inbound connections.

Add one static route on R1 and R6 to get this working. Do not use the same feature as the previous NAT task.

Configuration

R1


ip nat inside

!


ip nat outside

!

!

ip nat Stateful id 1

redundancy REDUNDANCY

mapping-id 10

protocol udp

ip nat inside source static network 10.0.146.0 9.16.146.0 /24 mapping-id 10

ip route 9.16.146.0 255.255.255.0 FastEthernet0/1.146




R6


ip nat inside

!


ip nat outside

!



mapping-id 10

protocol udp


!

ip route 9.16.146.0 255.255.255.0 FastEthernet0/1.146


Luckily Stateful NAT is actually a pretty simple configuration for redundancy. Stateful NAT provides protection against failures in a network topology. If you are familiar with configuring basic NAT configuration this will be pretty intuitive for you. As was the case with Stateful Firewall, Stateful NAT can rely on HSRP redundancy for basic failover setup. We had already completed all the HSRP configuration in the previous task so no need to modify the configuration for this task.

In addition Stateful NAT can be configured without HSRP as well. You can configure communication between the two peers in a primary/backup configuration solution. And it can also support asynchronous path support for outside-to-inside NAT when used in Customer Edge Multipath ALG configuration scenarios.

For the NAT statement the task requested that we complete the entries in as few lines as possible while still allowing inbound connections to the devices. The easiest way to complete this is using a static NAT with the network statement allowing for a one to one translation. In the lab we have all the address space we want to work with but in the real world you typically would not NAT if you already have a one to one conversion available for Public address space.

In the first task where we configured NAT we relied on the “add-route” feature of a NAT pool to add the routes to the routing table. In this task we were told that we were not allowed to complete this task using the same method. This requires that we add a static route on the routers. The static route needs to point either to an interface or to another device. If you made the mistake of pointing the static route to Null0 the router will drop the traffic.

For the most part in this lab all the routing has already been completed for us so by adding the static route the route is added to the BGP process and forwarded throughout the network.

Verification

Open an outbound connection on Cat4 to R5 and check R6 to make sure he receives the SNAT entries.

http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iadnat_cfg_ha_ps6441_TSD_Products_Configuration_Guide_Chapter.html




R1#sh ip snat distributed

Stateful NAT Connected Peers

SNAT: Mode IP-REDUNDANCY :: ACTIVE

: State READY

: Local Address 9.9.156.11

: Local NAT id 1

: Peer Address 9.9.156.6

: Peer NAT id 0

: Mapping List 10

R1#

R1#sh ip nat tr


udp 9.16.146.14:123 10.0.146.14:123 9.9.156.9:123 9.9.156.9:123

tcp 9.16.146.14:14847 10.0.146.14:14847 9.9.156.5:22 9.9.156.5:22

udp 9.16.146.14:32929 10.0.146.14:32929 9.9.156.5:33438 9.9.156.5:33438

udp 9.16.146.14:32986 10.0.146.14:32986 9.9.156.5:33437 9.9.156.5:33437

udp 9.16.146.14:33728 10.0.146.14:33728 9.9.156.5:33437 9.9.156.5:33437

udp 9.16.146.14:38515 10.0.146.14:38515 9.9.156.5:33439 9.9.156.5:33439

udp 9.16.146.14:39610 10.0.146.14:39610 9.9.156.5:33438 9.9.156.5:33438

udp 9.16.146.14:41749 10.0.146.14:41749 9.9.156.5:33439 9.9.156.5:33439

tcp 9.16.146.14:46020 10.0.146.14:46020 9.9.156.5:22 9.9.156.5:22

--- 9.16.146.14 10.0.146.14 --- ---

--- 9.16.146.0 10.0.146.0 --- ---

R1#

We can see the same entries are created on both R1 and R6. The traffic by default is flowing thru R1.

R6#sh ip nat translations


udp 9.16.146.14:123 10.0.146.14:123 9.9.156.9:123 9.9.156.9:123

tcp 9.16.146.14:14847 10.0.146.14:14847 9.9.156.5:22 9.9.156.5:22

udp 9.16.146.14:32929 10.0.146.14:32929 9.9.156.5:33438 9.9.156.5:33438

udp 9.16.146.14:32986 10.0.146.14:32986 9.9.156.5:33437 9.9.156.5:33437

udp 9.16.146.14:33728 10.0.146.14:33728 9.9.156.5:33437 9.9.156.5:33437

udp 9.16.146.14:38515 10.0.146.14:38515 9.9.156.5:33439 9.9.156.5:33439

udp 9.16.146.14:39610 10.0.146.14:39610 9.9.156.5:33438 9.9.156.5:33438

udp 9.16.146.14:41749 10.0.146.14:41749 9.9.156.5:33439 9.9.156.5:33439

tcp 9.16.146.14:46020 10.0.146.14:46020 9.9.156.5:22 9.9.156.5:22

--- 9.16.146.14 10.0.146.14 --- ---

R6#

And we can see that R6 has received 5435 translations from R1.

R6#sh ip snat distributed verbose


SNAT: Mode IP-REDUNDANCY :: STANDBY

: State READY


: Local NAT id 1


: Peer NAT id 1

: Mapping List 10

: InMsgs 5435, OutMsgs 0, tcb 0xB8898888, listener 0x0

R6#




If we cause a failure on R1 We can see syslog messages on R1 and R6 letting us know the failover is about to occur as well.

R1(config-subif)#

SNAT: interface FastEthernet0/1.146 with address 10.0.146.11 is down








Init


Init

May 15 02:14:51.976: %SNAT-5-PROCESS: Id 1, System starts converging



May 15 02:14:52.348: %SNAT-5-PROCESS: Id 1, System fully converged







R1(config-subif)#

Notice these changes on R6 as well.

R6(config-subif)#


> Active


-> Active

*May 15 01:25:29.616: %SNAT-5-PROCESS: Id 1, System starts converging

*May 15 01:25:29.620: %SNAT-5-PROCESS: Id 1, System fully converged








expired) 0 bytes

R6(config-subif)#

End Verification




2.8 CBAC

Allow all TCP and UDP based traffic to go out and return from the External networks on R1.

For web traffic, only allow Java applets to be downloaded from Web servers 9.2.1.100 and 9.4.45.4. Make sure the ACS login application window is included in this inspection, only 9.2.1.100.

Configure R1 to inspect pop3. Make sure the firewall requires secure-authentication by the clients.

Create an inbound filter on the External interface. Log all the Denies. Only permit traffic as required by the lab.

Configuration

R1

access-list 7 permit 9.2.1.100

!



!

ip port-map http port tcp 2002 list 7

!



ip inspect name FW http java-list 16

ip inspect name FW pop3 secure-login

!

logging on


!

ip access-list extended FW






permit 132 host 9.9.156.6 host 9.9.156.11

permit udp host 9.9.156.6 eq 1985 15555 host 224.0.0.102 eq 1985 15555




deny ip any any log

R6


!



!

ip port-map http port tcp 2002 list 7

!






ip inspect name FW http java-list 16

ip inspect name FW pop3 secure-login

!

logging on


!









permit 132 host 9.9.156.11 host 9.9.156.6





deny ip any any log


This is a task of paying attention to the details. We need to make sure all the traffic is being allowed in that is required and that we are inspecting the traffic as required by the task.

So we have already tested the basic TCP and UDP inspection in the previous task. Here we need to take one additional step and inspect http and pop3.

For http the task stated we needed to inspect http and only allow java applets from 9.2.1.100 and 9.4.45.4. In addition the ACS application login screen is also supposed to be included in these rules. ACS application login screen is run over TCP port 2002. So we needed to create an application port-map to associate TCP port 2002 to http. The question also stated that only 9.2.1.100 should be associated with this port map. Access-list 7 completed this requirement and it was tied to the port map.

Access-list 16 is used to only allow the two servers for java applets.

By adding the secure-login option to pop3 inspection the router will prevent unsecure authentation.

Just a few notes on the ACL‟s as well to explain the reasoning for each entry.

We cannot inspect ICMP due to the rules in the first task that we should only allow three types of ICMP.

BGP can originate from either R9 or R1/R6. So we need to allow BGP in both directions.

IP port 132 is SCTP which is used for Stateful Firewall

UDP port 1985 is HSRP and 15555 is Stateful NAT

In a previous task we were required to allow SSH from R4 to all the Catalyst Switches. Don‟t forget to allow SSH to Cat4 in the ACL.

Don‟t forget to log to 9.2.1.100 as the first task required logging to it for any task that requires logging.

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_port_app_map.html

http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_i2.html#wp1049229




Verification

For verification of the access-lists you should not have permitted anything more than what is shown above. If there is anything else that we have forgotten we will be able to catch it by the “deny ip any any log” at the end of the ACL.

We can test the Java list by putting XP workstation on VLAN 146 and connecting to the ACS application.

To test that the java applet will actually filter java-applet remove 9.2.1.100 from the ACL you configured for the java-list. If it is working when you open the Webpage you should see the following in the log of R1.

May 15 19:27:38.692: %FW-3-HTTP_JAVA_BLOCK: JAVA applet is blocked from

(9.2.1.100:2002) to (10.0.146.100:1569).

May 15 19:27:38.704: %FW-3-HTTP_JAVA_BLOCK: JAVA applet is blocked from

(9.2.1.100:2002) to (10.0.146.100:1570).

This tells you that both the java-filter is working at that port 2002 has been tied to the HTTP port-map. “Notice the error in the lower right hand corner of the IE window. So now by adding 9.2.1.100 back to the ACL you will see the following.




If we cause a failure on R1 We can see syslog messages on R1 and R6 letting us know the failover is about to occur as well.

R1(config-subif)#









Init


Init

May 15 02:14:51.976: %SNAT-5-PROCESS: Id 1, System starts converging



May 15 02:14:52.348: %SNAT-5-PROCESS: Id 1, System fully converged







R1(config-subif)#

Notice these changes on R6 as well:

R6(config-subif)#


> Active


-> Active

*May 15 01:25:29.616: %SNAT-5-PROCESS: Id 1, System starts converging

*May 15 01:25:29.620: %SNAT-5-PROCESS: Id 1, System fully converged











expired) 0 bytes

R6(config-subif)#

End Verification

2.9 Controlling Half Open Connections

Configure R6 to protect the internal network against SYN-floods. It should start deleting half open sessions if they are at 800. It should stop deleting half open connections when they reach 600. This should occur for both UDP and TCP Connections.

It should further protect the internal network by starting to delete half-open connections if there have been 600 new connections created within the last one minute and stop deleting at 400.

Configure the Router to delete TCP connections if the connection has been idle for 10 minutes.

Configuration

R1

ip inspect max-incomplete high 800

ip inspect max-incomplete low 600

ip inspect one-minute low 400

ip inspect one-minute high 600

ip inspect tcp idle-time 600

R6

ip inspect max-incomplete high 800

ip inspect max-incomplete low 600

ip inspect one-minute low 400

ip inspect one-minute high 600

ip inspect tcp idle-time 600


The difference between TCP intercept as was configured on R5 and the configuration applied to the CBAC policy is the addition of UDP protection by CBAC as well. Both TCP and UDP are checked for half open connectivity when applied to ip inspect max-incomplete or ip inspect one-minute. This is a loose definition as UDP does not perform a handshake like TCP but is considered a half open connection by the firewall when it has seen traffic in one direction but no return traffic in the other direction.

An unusually high number of half-open sessions with the same destination host address could indicate that a denial-of-service attack is being launched against the host. For TCP, "half-open" means that the session has not reached the established state. Whenever the numbers of half-open sessions with the same destination host address rises above a threshold, the software will delete half-open sessions.

http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_i2.html

http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_i2.html




When the software detects a valid UDP packet, if CBAC inspection is configured for the packet's protocol, the software establishes state information for a new UDP "session." Because UDP is a connectionless service, there are no actual sessions, so the software approximates sessions by examining the information in the packet and determining if the packet is similar to other UDP packets and if the packet was detected soon after another similar UDP packet. If the software detects no UDP packets for the UDP session for a period of time defined by the UDP idle timeout, the software will not continue to manage state information for the session.

Verification

R6#show ip inspect config

Session audit trail is disabled

Session alert is enabled

one-minute (sampling period) thresholds are [400 : 600] connections

max-incomplete sessions thresholds are [600 : 800]

max-incomplete tcp connections per host is unlimited. Block-time 0 minute.

tcp synwait-time is 30 sec -- tcp finwait-time is 10 sec

tcp idle-time is 600 sec -- udp idle-time is 100 sec

tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 kilo bytes

dns-timeout is 5 sec

HA update interval is 10 sec

Inspection Rule Configuration

Inspection name FW

udp alert is on audit-trail is off timeout 100

inspection of router local traffic is enabled

tcp alert is on audit-trail is off timeout 600


http java-list 16 alert is on audit-trail is off timeout 600

pop3 secure-login is on alert is on audit-trail is off timeout 600

R6#

End Verification

2.10 Firewall Tuning

On R1, if traffic sourced from RFC 3330 address space attempts to come in block it but do not log this traffic.

Turn on audit trail messages which will be displayed on the console after each CBAC session stops except for UDP traffic.

Globally specify the TCP session will still be managed after the firewall detects a FIN-exchange to be 10 seconds for all TCP sessions.

Change the max-incomplete host number to 35 half-open sessions, and changes the block-time timeout to 3 minutes.

Set the global UDP idle timeout to 100 seconds

Prevent IP Spoofing using Reverse Path Forwarding. Make sure it only accepts routes learned on that interface but R1 should still be able to ping its own interface.




Configuration

R1

ip inspect audit-trail

ip inspect name FW udp audit-trail off router-traffic

ip inspect udp idle-time 100

ip inspect tcp finwait-time 10

ip inspect tcp max-incomplete host 35 block-time 3

!

no ip access-list extended FW


deny ip 0.0.0.0 0.255.255.255 any

deny ip 10.0.0.0 0.255.255.255 any

deny ip 127.0.0.0 0.255.255.255 any

deny ip 169.254.0.0 0.0.255.255 any

deny ip 172.16.0.0 0.15.255.255 any

deny ip 192.0.2.0 0.0.0.255 any

deny ip 192.18.0.0 0.1.255.255 any

deny ip 192.88.99.0 0.0.0.255 any

deny ip 192.168.0.0 0.0.255.255 any

deny ip 224.0.0.0 15.255.255.255 any

deny ip 240.0.0.0 15.255.255.255 any






permit 132 host 9.9.156.6 host 9.9.156.11





deny ip any any log

!


ip verify unicast source reachable-via rx allow-self-ping

ip access-group FW in

R6

ip inspect audit-trail

ip inspect name FW udp audit-trail off router-traffic

ip inspect udp idle-time 100

ip inspect tcp finwait-time 10

ip inspect tcp max-incomplete host 35 block-time 3

!

no ip access-list extended FW


deny ip 0.0.0.0 0.255.255.255 any

deny ip 10.0.0.0 0.255.255.255 any

deny ip 127.0.0.0 0.255.255.255 any

deny ip 169.254.0.0 0.0.255.255 any

deny ip 172.16.0.0 0.15.255.255 any

deny ip 192.0.2.0 0.0.0.255 any

deny ip 192.18.0.0 0.1.255.255 any

deny ip 192.88.99.0 0.0.0.255 any




deny ip 192.168.0.0 0.0.255.255 any

deny ip 224.0.0.0 15.255.255.255 any

deny ip 240.0.0.0 15.255.255.255 any








permit 132 host 9.9.156.11 host 9.9.156.6





deny ip any any log

!


ip verify unicast source reachable-via rx allow-self-ping



Don‟t forget to Add the filter for RFC 3330 before the old rules. We have only chosen to filter networks that are not either public address space or currently have no plans for future allocation. I believe this is what you should be concerned with in the lab as well.

RFC 3330 is a very lengthy amount of address space that is being blocked when first looking at the RFC. It can seem rather overwhelming. But it is easy to memorize once you break it into the networks classifications by remembering what is class A, B, C, D, and E.

Class A is 0.0.0.0 – 127.255.255.255 Class B is 128.0.0.0 – 191.255.255.255 Class C is 192.0.0.0 – 223.255.255.255 Class D is 224.0.0.0 – 239.255.255.255 Class E is 240.0.0.0 – 255.255.255.255 So first we can easily take out the RFC 1918 addresses.

10.0.0.0/8 172.16.0.0/12 192.168.0/16

Next are the auto-net and Loopback address space.

169.254.0.0/16 127.0.0.0/8

Alll of the Class D and E address space is filtered.

224.0.0.0/4 240.0.0.0/4

Now the part that becomes more clear when you break it apart to the address space. RFC 3330 filters the first and last address of each block.

http://www.faqs.org/rfcs/rfc3330.html




0.0.0.0/8 127.0.0.0/8 (Already covered earlier) 128.0.0.0/16 191.255.0.0/16 192.0.0.0/24 223.255.255.0/24

The last four of these have been released by IANA and can be allocated thus we chose not to filter them.

It is only the last portion of addresses that require a small amount of memorization.

39.0.0.0/8 192.0.2.0/24 192.18.0.0/15 192.88.99.0/24

39.0.0.0/8 has been allocated for future use so in my opinion only three are necessary but you may as well memorize all four. 192.88.99.0/24 could possibly be seen if you are doing 6to4 tunnels to Internet2 but you would know it if you were. So RFC 3330 is only a memorization of four additional address blocks over RFC 1918 if you can simply remember the classful breakdown of IPv4 from the CCNA days.

Verification

I think looking at the configuration of this second should suffice for verification.

R1(config-ext-nacl)#do sh ip inspect config

Session audit trail is enabled




max-incomplete tcp connections per host is 35. Block-time 3 minutes.







Inspection name FW



tcp alert is on audit-trail is on timeout 600


http java-list 16 alert is on audit-trail is on timeout 600

pop3 secure-login is on alert is on audit-trail is on timeout 600


May 15 21:33:43.553: %FW-6-SESS_AUDIT_TRAIL_START: Start pop3 session:

initiator (10.0.146.100:1588) -- responder (9.2.1.100:110)

May 15 21:33:43.945: %FW-6-SESS_AUDIT_TRAIL: Stop pop3 session: initiator

(10.0.146.100:1588) sent 0 bytes -- responder (9.2.1.100:110) sent 0 bytes


End Verification




2.11 Transparent Zone Based Firewall

Configure R8 as a zone based transparent firewall. Allow users on R7 to go out to the external networks using the following protocols:

Bootps DNS HTTP HTTPS SMTP SSH

The return entries should be automatically created on the return. No other protocol traffic should be inspected for this task.

The return entries should expire after 4 minutes for TCP based protocols. DNS entries should expire after 2 minute.

Only permit necessary traffic for routing or other tasks.

Use two zones; INSIDE for Fa0/1.78 and OUTSIDE for Fa0/1.1256 on R8

Make sure Routing is still working after you are done with this section. Be sure to log any traffic that violates these rules.

Configuration

R8

ip inspect log drop-pkt

!

bridge irb

!

zone security INSIDE

zone security OUTSIDE

!


bridge-group 1

zone-member security INSIDE

!


bridge-group 1

zone-member security OUTSIDE

!

interface BVI1

ip address 9.9.156.8 255.255.255.0

!

bridge 1 protocol ieee

bridge 1 route ip

!

ip access-list extended FW-IN






!

ip access-list extended ICMP





ip access-list extended IN->OUT


!

class-map type inspect match-all IN->OUT-ICMP-REPLY

match access-group name IN->OUT

class-map type inspect match-any IN->OUT-PROTO

match protocol ssh

match protocol http

match protocol https

match protocol dns

match protocol smtp

match protocol bootps

class-map type inspect match-all OUT->IN

match access-group name FW-IN

class-map type inspect match-any IN->OUT-ICMP

match access-group name ICMP

!

policy-map type inspect FW-OUT->IN

class type inspect OUT->IN

pass

class class-default

drop

policy-map type inspect FW-IN->OUT

class type inspect IN->OUT-PROTO

inspect

class type inspect IN->OUT-ICMP

inspect

class type inspect IN->OUT-ICMP-REPLY

pass

class class-default

pass

!

zone-pair security IN->OUT source INSIDE destination OUTSIDE

service-policy type inspect FW-IN->OUT

zone-pair security OUT->IN source OUTSIDE destination INSIDE

service-policy type inspect FW-OUT->IN

!

logging on



For the most part, Transparent Zone Based Firewall and ZFW implementation are very similar. You won‟t be able to do traffic termination on the Firewall like with consent proxy but you will be able to filter traffic as necessary thru it, except for P2P traffic as the firewall relies on NBAR for packet recognition and NBAR is not available for bridged packets.

It is an important note that in the configuration guide for transparent zone based firewall there is not a good explanation of how to configure a bridge group. So, if you do find it required on the lab to do transparent ZFW make sure to look at the CBAC Transparent firewall configuration guide for how to setup the bridge group. This is the easiest place to find it will working on the Security lab. Instead of having to look it up in the Bridging and IBM Networking configuration guide.

We didn‟t apply the DNS and TCP timeouts here in this section. That will be taken care of in the firewall tuning question next.

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_zone_polcy_firew.html#wp1054865

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_trans_ios_fwall.html




Verification

We have opened an SSH session from R7 to R9 to show the inspection of traffic.

R8#show policy-map type inspect zone-pair sessions

policy exists on zp IN->OUT

Zone-pair: IN->OUT

Service-policy inspect : FW-IN->OUT

Class-map: IN->OUT-PROTO (match-any)

Match: protocol ssh

1 packets, 24 bytes

30 second rate 0 bps

Match: protocol http

0 packets, 0 bytes


Match: protocol https

0 packets, 0 bytes


Match: protocol dns

0 packets, 0 bytes


Match: protocol smtp

0 packets, 0 bytes


Match: protocol bootps

2 packets, 1168 bytes


Inspect

Number of Established Sessions = 1


Session 48D1F460 (9.9.156.7:43735)=>(9.9.156.9:22) ssh:tcp SIS_OPEN

Created 00:02:06, Last heard 00:01:23


Class-map: IN->OUT-ICMP (match-any)

Match: access-group name ICMP

0 packets, 0 bytes


Inspect

Class-map: IN->OUT-ICMP-REPLY (match-all)

Match: access-group name IN->OUT

Pass

0 packets, 0 bytes

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

Match: any

Pass





policy exists on zp OUT->IN

Zone-pair: OUT->IN

Service-policy inspect : FW-OUT->IN

Class-map: OUT->IN (match-all)

Match: access-group name FW-IN

Pass



Match: any

Drop


R8#

Now if I try to telnet to R9 from R7 we will find the connection to be dropped by the firewall as we were instructed to only inspect traffic specifically defined by the question.

May 27 02:42:30.528: %FW-6-DROP_PKT: Dropping tcp session 9.9.156.9:23

9.9.156.7:43051 on zone-pair OUT->IN class class-default due to DROP action

found in policy-map with ip ident 0

May 27 02:42:31.896: %FW-6-LOG_SUMMARY: 1 packet were dropped from

9.9.156.9:23 => 9.9.156.7:43051 (target:class)-(OUT->IN:class-default)

End Verification

2.12 DHCP and a Transparent ZFW

R9 has been configured as a DHCP server for 10.0.7.0/24. Configure R8 and R7 to allow DHCP requests to R9.

Connect the XP Workstation to VLAN 7 and make sure it is assigned IP 10.0.7.100/24.

Connect Cat1 Fa0/19 to VLAN 7 and configure it to receive IP 10.0.7.10.

R7 has been configured to advertise 10.0.7.0/24 via BGP to R9. Make sure R9 doesn‟t advertise this network beyond its own local AS. This configuration should be applied on R7.

Configuration

R7

ip dhcp relay information trust-all

!


ip helper-address 9.9.156.9

!

ip prefix-list FILTER permit 10.0.7.0/24

!

route-map FILTER permit 10

match ip address prefix-list FILTER

set community no-export

route-map FILTER permit 20

!




router bgp 7

neighbor 9.9.156.9 send-community

neighbor 9.9.156.9 route-map FILTER out

R8

ip inspect L2-transparent dhcp-passthrough


permit udp host 9.9.156.9 eq 67 10.0.7.0 0.0.0.255 eq 68

R9

ip dhcp pool XP

host 10.0.7.100 255.255.255.0

client-identifier 0100.0c29.960f.ac

ip dhcp pool Cat1

host 10.0.7.10 255.255.255.0

client-identifier

0063.6973.636f.2d30.3031.392e.3036.3063.2e35.6563.312d.4661.302f.3139

Cat1


no switchport

ip address dhcp

Cat4





no shutdown


Without the command “ip inspect L2-transparent dhcp-passthrough” DHCP requests will not be passed thru the firewall and you will have no indication as to why it is not working unless you have the command debug policy-firewall l2-transparent enabled. But if you didn‟t already know the ip inspect l2-transparent you probably wouldn‟t have found the debug command either. Not the nicest section, but good for learning.

Route filtering is listed under Control Plane and Management Plane Security. Will they do something as hard as filtering with BGP? I hope the answer to that is a negative. But as it is a tested topic I want to introduce some basic features of BGP to you to make you aware of them, and hopefully you won‟t have to go much deeper into the protocol.

In the example above we have used a well known community string of “no-export” being applied to R7 advertisements of VLAN 7 to R9. As this is a community value you have to make sure to use the send-community on the neighbor statements so R7 will send the community applied in the route-map to R9.

There are two methods for making sure the XP workstation is assigned the correct IP. The shortcut is to exclude all other addresses except .100. The more realistic method as typically you

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_trans_ios_fwall.html#wp1051581




would still want to allow other devices to receive a DHCP IP is to use the host assignment in a sub pool. Any parameter not assigned by the host pool will be assigned from the network pool.

We are not warned about the NAT on R7 breaking DHCP. DHCP packets as they go thru R7 to R9 are going to be NAT‟ed to 9.9.7.X. When R9 recieves the request it will take the packet data and respond to the requester which will be the real IP address. There are two ways to overcome this problem; You can either do policy NATing or allow the traffic thru the firewall as shown in our configuration. Policy NAT would probably be the more secure way of making sure it is actually a response to a request but there were no restrictions on the question.

Verification

Verify that R9 is receiving the advertisement for VLAN 7 and that it is not being advertised to other neighbors.

R9#show ip route 10.0.7.0

Routing entry for 10.0.7.0/24

Known via "bgp 1256", distance 20, metric 0

Tag 7, type external

Last update from 9.9.156.7 17:05:37 ago

Routing Descriptor Blocks:

* 9.9.156.7, from 9.9.156.7, 17:05:37 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 7

R9#sho ip bgp | incl 10.0

*> 10.0.7.0/24 9.9.156.7 0 0 7 i

R9#show ip bgp neighbor 9.9.156.5 advertised-routes



internal,




*> 1.0.0.0 9.9.156.11 0 0 16 i

*> 2.0.0.0 9.9.156.2 0 0 2 i

*> 4.0.0.0 9.9.156.5 1 0 5 i

*> 5.0.0.0 9.9.156.5 0 0 5 i

*> 6.0.0.0 9.9.156.11 0 16 i

*> 9.0.0.0 0.0.0.0 32768 i

*> 192.1.49.0 9.9.156.2 0 0 2 i

Total number of prefixes 7

R9#

R9#show ip bgp neighbor 9.9.156.11 advertised-routes



internal,




*> 1.0.0.0 9.9.156.11 0 0 16 i

*> 2.0.0.0 9.9.156.2 0 0 2 i

*> 4.0.0.0 9.9.156.5 1 0 5 i




*> 5.0.0.0 9.9.156.5 0 0 5 i

*> 6.0.0.0 9.9.156.11 0 16 i

*> 9.0.0.0 0.0.0.0 32768 i

*> 192.1.49.0 9.9.156.2 0 0 2 i

Total number of prefixes 7

R9#

So, the routing tables are correct. Now for DHCP. Before making the correction on R8 for the DHCP requests coming back you may see messages similar to the following:

R8#

May 27 03:53:31.932: %FW-6-LOG_SUMMARY: 2 packets were dropped from


R8#

May 27 03:54:31.933: %FW-6-LOG_SUMMARY: 1 packet were dropped from


R8#

May 27 03:56:12.734: %FW-6-DROP_PKT: Dropping udp session 9.9.156.9:67

10.0.7.100:68 on zone-pair OUT->IN class class-default due to DROP action


R8#

May 27 03:56:31.934: %FW-6-LOG_SUMMARY: 3 packets were dropped from


Let‟s test XP requesting a DHCP address and then gather the client identifier and configure the host pool.





IP Address. . . . . . . . . . . . : 10.200.5.12

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.200.5.254


Connection-specific DNS Suffix . : ipexpert.com

IP Address. . . . . . . . . . . . : 10.0.7.101

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . :


R9#sh ip dhcp bind

Bindings from all pools not associated with VRF:

IP address Client-ID/ Lease expiration Type

Hardware address/

User name

10.0.7.101 0100.0c29.960f.ac May 27 2009 11:46 PM Automatic

R9#




R9#config t


R9(config)#do clear ip dhcp bind *

R9(config)#ip dhcp pool XP

R9(dhcp-config)#host 10.0.7.100 /24

R9(dhcp-config)#client-id 0100.0c29.960f.ac

R9(dhcp-config)#end

R9#

C:\Documents and Settings\Administrator>ipconfig /release




IP Address. . . . . . . . . . . . : 10.200.5.12

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.200.5.254



IP Address. . . . . . . . . . . . : 0.0.0.0

Subnet Mask . . . . . . . . . . . : 0.0.0.0

Default Gateway . . . . . . . . . :

C:\Documents and Settings\Administrator>ipconfig /renew




IP Address. . . . . . . . . . . . : 10.200.5.12

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.200.5.254


Connection-specific DNS Suffix . : ipexpert.com

IP Address. . . . . . . . . . . . : 10.0.7.100

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.0.7.7


Verify that Cat1 Also receives an IP address as well.

Cat1(config-if)#

*Mar 2 09:47:54.968: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/19

assigned DHCP address 10.0.7.10, mask 255.255.255.0, hostname Cat1

Cat1(config-if)#




R9#sh ip dhcp bind

Bindings from all pools not associated with VRF:

IP address Client-ID/ Lease expiration Type

Hardware address/

User name

10.0.7.10 0063.6973.636f.2d30. Infinite Manual

3031.392e.3036.3063.

2e35.6563.312d.4661.

302f.3139

10.0.7.100 0100.0c29.960f.ac Infinite Manual

R9#



Zone-pair: IN->OUT



Match: protocol ssh

1 packets, 24 bytes



0 packets, 0 bytes



0 packets, 0 bytes


Match: protocol dns

0 packets, 0 bytes



0 packets, 0 bytes





Inspect

Number of Half-open Sessions = 1

Half-open Sessions

Session 48D20660 (9.7.7.100:68)=>(9.9.156.9:67) bootps:udp SIS_OPENING





0 packets, 0 bytes


Inspect



Pass




0 packets, 0 bytes


Match: any

Pass



Zone-pair: OUT->IN




Pass



Match: any

Drop


R8#

End Verification

2.13 Transparent ZFW Tuning

Specify that TCP sessions will still be managed after the firewall detects a FIN-exchange for 12 seconds and the SYN-exchange to be 20 seconds for all TCP sessions.


Set the UDP idle timeout to 90 seconds. Do not perform these changes globally.

Configuration

R8

parameter-map type inspect PAR-MAP

udp idle-time 90

dns-timeout 180

tcp idle-time 240

tcp finwait-time 12

tcp synwait-time 20

tcp max-incomplete host 25 block-time 10

policy-map type inspect FW-IN->OUT

class type inspect IN->OUT-PROTO

inspect PAR-MAP


These settings can either be applied globally or under a Parameter Map. This question stated we were not allowed to apply these setting globally. Be aware that if you don‟t specify a parameter map the default parameter map is applied.

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_zone_polcy_firew.html#wp1060210




Verification

I think looking at the configuration of this second should suffice for verification.

R8#show parameter-map type inspect


audit-trail off

alert on

max-incomplete low unlimited

max-incomplete high unlimited

one-minute low unlimited

one-minute high unlimited

udp idle-time 90

icmp idle-time 10

dns-timeout 180

tcp idle-time 240

tcp finwait-time 12

tcp synwait-time 20


sessions maximum 2147483647

R8#

R8#show parameter-map type inspect default

audit-trail off

alert on

max-incomplete low unlimited

max-incomplete high unlimited

one-minute low unlimited

one-minute high unlimited

udp idle-time 30

icmp idle-time 10

dns-timeout 5

tcp idle-time 3600

tcp finwait-time 5

tcp synwait-time 30

tcp max-incomplete host unlimited block-time 0

sessions maximum 2147483647

R8#show policy-map type inspect FW-IN->OUT

Policy Map type inspect FW-IN->OUT

Class IN->OUT-PROTO

Inspect PAR-MAP

Class IN->OUT-ICMP

Inspect

Class IN->OUT-ICMP-REPLY

Pass

Class class-default

Pass

R8#

End Verification




2.14 Auth-Proxy

Create an Access-list inbound on R7 Fa0/1.78 denying 9.2.1.0/24 to 9.7.7.0/24. Permit all other traffic.

Allow users from 9.2.1.0/24 to access the 9.7.7.0/24 network after successful authentication against R7. They should only be allowed to come in for TCP based protocols. Only authenticate if there is a web session to 9.7.7.7. Make sure the password is sent encrypted.

If the session is inactive for more than 15 minutes or has been active for more than 90 minutes the session should be disconnected.

ACS has been pre-configured for you with R7 and Cat1 setup with TACACS+ and key ipexpert.

Username auth-proxy and password ipexpert is allowed for authentication. This username and password is only allowed to authenticate to R7 and Cat1.

The user should also be allowed full shell access to R7 and Cat1 via SSH without an enable password.

Configuration unfinished on ACS – Once successfully authenticated ACS should download an ACL to R7 permitting this TCP traffic from the authenticated host to 9.7.7.0/24.

Users should be able to connect to Cat1 from 9.2.1.0/24 via HTTP Port 80, 8080, HTTPS, and SSH.

Configuration

R7

ip access-list extended INBOUND

permit tcp 9.2.1.0 0.0.0.255 host 9.7.7.7 eq www

permit tcp 9.2.1.0 0.0.0.255 host 9.7.7.7 eq 443

deny tcp 9.2.1.0 0.0.0.255 9.7.7.0 0.0.0.255 log

permit ip any any

!



permit tcp 9.2.1.0 0.0.0.255 host 9.7.7.7 eq www

!

aaa new-model

aaa authentication login default group tacacs+

aaa authentication login CONSOLE none

aaa authorization exec default group tacacs+

aaa authorization auth-proxy default group tacacs+

!

ip domain name ipexpert.com


!

ip auth-proxy name APROXY http inactivity-time 15 absolute-timer 90

list VLAN10

!


ip access-group INBOUND in

ip auth-proxy APROXY

!

ip http server

Don‟t forget the timers and the list. We are only supposed to authenticate traffic from VLAN 10 to web services for 9.7.7.7




ip http authentication aaa


!

ip nat source static tcp 10.0.7.10 80 9.7.7.10 8080 extendable

tacacs-server host 9.2.1.100 key ipexpert

!

line con 0

login authentication CONSOLE

line vty 0 4

transport input ssh

R8


permit tcp host 9.2.1.100 eq tacacs host 7.7.7.7 gt 1024

permit tcp host 9.2.1.100 eq tacacs host 9.7.7.10 gt 1024

!


permit ip 9.2.1.0 0.0.0.255 9.7.7.0 0.0.0.255


!

class-map type inspect match-all OUT->IN-PROTO

match protocol tcp

match access-group name VLAN10

!

policy-map type inspect FW-OUT->IN

class type inspect OUT->IN-PROTO

inspect

Cat1

aaa new-model

!


aaa authentication login VTY group tacacs+


!



!

ip http server


!

tacacs-server host 9.2.1.100 key ipexpert

!

line vty 0 15


transport input ssh

Port 8080 needs to be redirected to 80 on Cat1 as you can only specify a single http port to listen to on Cat1.

Here we limit only 9.2.1.0/24 to be inspected




ACS

We need to enable Auth-Proxy configuration under Interface Configuration > TACACS+ > New Services. Add auth-proxy. Click Submit.

Click User Setup > Find > Click the auth-proxy user. Check auth-proxy and custom attributes and add “priv-lvl=15” and “proxyacl#1=permit tcp any 9.7.7.0 0.0.0.255. Click Submit.





Hopefully this is one of the most difficult Authentication Proxy scenarios you should see in a practice lab or on the real thing. This should prepare you for anything that comes your way in relation to auth-proxy.

So the first part of the question is that we are to permit VLAN 10 to access VLAN 7 after first authenticating to R7. This is why the INBOUND ACL denies traffic from VLAN 10 to make sure they actually do authenticate. As R7 isn‟t really the firewall for controlled access to the network we don‟t need to be specific on the rest of the ACL. R8 is filtering all the traffic.

On R8 though we need to inspect the traffic coming from VLAN 10 to go thru to R7. If you don‟t inspect the traffic you can work around the problems you may run into with the return traffic by restricting it from the outbound inspection rules but it is easier to just inspect it from the OUTSIDE zone to prevent the problems you may run into.

Verification

Check to make sure all the authenticated access is working. From ACS.

You will get a message letting you know you have successfully authenticated. I was unable to capture it as it goes away too quickly for the screen shot.

http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_cfg_authen_prxy_ps6441_TSD_Products_Configuration_Guide_Chapter.html




7.7.7.7 PUTTY

login as: auth-proxy

[email protected]'s password:

R7#sh ip int brief

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 unassigned YES NVRAM administratively down down

FastEthernet0/1 10.0.7.7 YES NVRAM up up

FastEthernet0/1.78 9.9.156.7 YES NVRAM up up

Serial0/0/0 unassigned YES NVRAM administratively down down

NVI0 unassigned YES unset administratively down down

Loopback0 7.7.7.7 YES NVRAM up up

R7#




Now Cat1

9.7.7.10 PUTTY

login as: auth-proxy

Using keyboard-interactive authentication.

Password:

Cat1#sh dhcp lease

Temp IP addr: 10.0.7.10 for peer on Interface: FastEthernet0/19

Temp sub net mask: 255.255.255.0

DHCP Lease server: 9.9.156.9, state: 5 Bound

DHCP transaction id: 24B4

Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs

Temp default-gateway addr: 10.0.7.7

Next timer fires after: 08:25:16

Retry count: 0 Client-ID: cisco-0019.060c.5ec1-Fa0/19

Client-ID hex dump: 636973636F2D303031392E303630632E

356563312D4661302F3139

Hostname: Cat1

Cat1#

Port 80




Port 8080.

R7#sh ip nat nvi translations

Pro Source global Source local Destin local Destin global

tcp 9.7.7.10:8080 10.0.7.10:80 --- ---

--- 9.7.7.10 10.0.7.10 --- ---

--- 9.7.7.100 10.0.7.100 --- ---

R7#

End Verification




2.15 ZFW URL Filtering

Configure R2 to filter URL‟s from EXEC and User to OUTSIDE.

You will use a trend micro server filter.trendmicro.com (68.9.10.1) HTTPS port 6895. R2 should keep responses from the server in cache for 10 hours. Make sure the cache doesn‟t use more than 1 MB of memory.

If the filter server is down you should allow the EXEC zone to continue to access the internet but the User zone should not be allowed and should be redirected to http://10.1.1.100:2002.

During normal business hours, 8 AM to 5 PM, you don‟t want to allow users to go to sites that are Social Networking or Job-Search-Career related.

Always permit traffic to www.cisco.com, www.onlinestudylist.com, and www.ipexpert.com without requiring a response from the filter server.

Always deny traffic to *.example.com or that has URI information with blackmarket.

If a user attempts to connect to a website that contains Weapons, Violence-Hate-Racism, Pornography, Adult-Mature-Content, Nudity, Gambling, or is known to have PHISHING, ADWARE, or SPYWARE make sure to reset these connections.

Configuration

R2

ip host filter.trendmicro.com 68.9.10.1

parameter-map type trend-global TREND

server filter.trendmicro.com https-port 6895

cache-size maximum-memory 1024

cache-entry-lifetime 10

!

parameter-map type urlfpolicy trend EXEC

allow-mode on

parameter-map type urlfpolicy trend User

allow-mode off

block-page redirect-url http://192.1.49.150:2002

!

time-range BUSINESS-HOURS


ip access-list extended BUSSINESS-HOURS

permit ip any any time-range BUSINESS-HOURS

!

!

class-map type urlfilter trend match-any FILTER-TIME

match url category Job-Search-Career

match url category Social-Networking

!

class-map type inspect match-all FILTER-BUSINESS-HOURS

match protocol http

match access-group name BUSINESS-HOURS

!

policy-map type inspect urlfilter FILTER-TIME-EXEC

parameter type urlfpolicy trend EXEC

class type urlfilter trend FILTER-TIME

reset

!

Create the Filter for Social Networking and Job searches during business hours. We want to reset the traffic during business.

We used a local host DNS entry for the server name. and create the Vendor Server Parameter Map

Next create the maps for EXEC and User to allow traffic or block traffic when the Trend Micro server is Unreachable.

Be sure to match-all as this should only affect HTTP during business hours

Do one policy for EXEC and another for User as only EXEC should allow traffic when the TM server is down.

http://10.1.1.100:2002/

http://www.cisco.com/



http://www.nortel.com/

http://192.1.49.150:2002/




policy-map type inspect urlfilter FILTER-TIME-User

parameter type urlfpolicy trend User

class type urlfilter trend FILTER-TIME

reset

!

policy-map type inspect EXEC->OUTSIDE

class type inspect FILTER-BUSINESS-HOURS

inspect

service-policy urlfilter FILTER-TIME-EXEC

policy-map type inspect User->OUTSIDE

class type inspect FILTER-BUSINESS-HOURS

inspect

service-policy urlfilter FILTER-TIME-User

!

!## Next we do the LOCAL Rules ##

!

parameter-map type urlf-glob LOCAL-FILTER

pattern *.example.com

parameter-map type urlf-glob LOCAL-PERMIT

pattern www.cisco.com

pattern www.onlinestudylist.com

pattern www.ipexpert.com

parameter-map type urlf-glob LOCAL-KEYWORD

pattern backmarket

!

class-map type urlfilter match-any LOCAL-FILTER

match server-domain urlf-glob LOCAL-FILTER

class-map type urlfilter match-any LOCAL-PERMIT

match server-domain urlf-glob LOCAL-PERMIT

class-map type urlfilter match-any LOCAL-KEYWORD

match url-keyword urlf-glob LOCAL-KEYWORD

!

policy-map type inspect urlfilter EXEC

parameter type urlfpolicy trend EXEC

class type urlfilter LOCAL-PERMIT

allow

log

class type urlfilter LOCAL-FILTER

reset

log

class type urlfilter LOCAL-KEYWORD

reset

log

!

policy-map type inspect urlfilter User

parameter type urlfpolicy trend User

class type urlfilter LOCAL-PERMIT

allow

log

class type urlfilter LOCAL-FILTER

reset

log

class type urlfilter LOCAL-KEYWORD

reset

log

Now apply the class-maps to the urlfilter policy, (which are the same ones as before), and we define the action of each class

Last apply the URL Filter policies to the zone-pair policy that will be used.

Notice the server-domain and url-keyword that differientiates the two types




class-map type inspect HTTP-CM

Match protocol http

!


class type inspect HTTP-CM

inspect

service-policy urlfilter EXEC

!



inspect

service-policy urlfilter User

!

!## Now filter the Category and Reputation content as specified by the question ##

class-map type urlfilter trend match-any FILTER-CONTENT

match url category Weapons

match url category Violence-hate-racism

match url category Pornography

match url category Adult-Mature-Content

match url category Nudity

match url category Gambling

match url reputation ADWARE

match url reputation SPYWARE

match url reputation PHISHING

!

policy-map type inspect urlfilter EXEC

class type urlfilter FILTER-CONTENT

reset

!

policy-map type inspect urlfilter User

class type urlfilter FILTER-CONTENT

reset


Honestly, Subscription Based Content Filtering can be rather confusing. The granularity and extent of features available now with the service are so extensive it is hard to follow the configuration process from beginning to end at first. It becomes very important to have a plan together from beginning to end of what you will be doing. If you can have that plan together than piecing together the process becomes much easier as you logically flow thru it.

The redirect was also tricky in that you needed to remember that ACS has a NAT statement to VLAN 12 that is different than the rest of the network.

You can see the parameter maps that you need to first create. Then applying the local parameter maps either to the class-maps for LOCAL parameters or to the policy-map for subscription based settings. Then creating the class-map url-filter rules of what types of traffic you are going to match and applying these matched traffic to the url-filter policies for the actions you will take on each traffic match.

It is important to understand that all Layer 7 protocol policies must then be nested to a L3/4 policy. You cannot use a Layer 7 policy directly in a zone-pair. The policy applied to the zone pair will be a layer 3/4 policy.

And we last attach the URL filter policy to the zone-pair policy-map again.

Now apply the class-maps to the urlfilter policy, (which are the same ones as before), and we define the action of each class

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_url_filtering.html#wp1057835




This question is also an example of how extensive the policies can become when working with Zone Based Firewall policies on the router. Begin to double and triple check your work to make sure you haven‟t forgotten something.

I expect that if you did see url-filtering on the test this would be for sure more extensive of a policy than I would expect for you to see on lab day, but should prepare you for anything they throw your way. This could be considered to be a 30 minute to 1 hour for just this one question and that, in my opinion, is just too much for the test. So don‟t feel discouraged by this question. Again we are trying to push a rather extensive in-depth view of the technologies at you in a rather quick pace with this workbook. So know that you should feel pretty comfortable in deep water when you are finished with all of these labs.

Verification

Well, it seems we would be getting more information from the show output then we are. We can do some basic testing for all the local settings. Obviously we can‟t test all the trend Micro stuff, as we don‟t actually have a trend Micro server but we can test the local settings that were put up above.

On XP workstation I have edited the hosts file to mimic some of the websites we have setup for local settings.

To edit the hosts file go to C:\Windows\System32\drivers\etc\ . Open the hosts file with notepad. Add the following lines:

9.9.156.9 www.example.com 4.4.4.4 www.cisco.com 4.4.4.4 www.ipexpert.com 4.4.4.4 www.awsome.com Note: You will need to complete the next task to apply the policies to the zone-pairs before completing the testing in this question. You will also need to authenticate to R5 for the Lock and Key to do these tests for R4 Loopback0.

Now we can do some ping tests.

C:\Documents and Settings\Administrator>ping www.example.com

Pinging www.example.com [9.9.156.9] with 32 bytes of data:










http://www.example.com/



http://www.awsome.com/




C:\Documents and Settings\Administrator>ping www.cisco.com

Pinging www.cisco.com [4.4.4.4] with 32 bytes of data:










So we know the local host file is properly translating the DNS settings.

So now open the browser and attempt to connect to these two websites. You will notice below that the URL has been redirected to ACS. (I have tested this after doing the JAVA filtering so the applet isn‟t loading.)

And on R2 we can see what happened to the packets.

R2(config-pmap)#

May 30 15:32:58.620: %URLF-4-SITE_BLOCKED: (target:class)-(User-OUT:HTTP-

CM):Access denied for the site 'www.example.com', client 192.1.49.100:1405

server 9.9.156.9:80


9.9.156.9:80 with ip ident 0

R2(config-pmap)#




OK that worked just as expected. How about www.cisco.com?

R2(config-pmap)#

May 30 15:37:43.717: %URLF-6-SITE_ALLOWED: (target:class)-(User-OUT:HTTP-

CM):Client 192.1.49.100:1416 accessed server 4.4.4.4:80

R2(config-pmap)#

For www.awsome.com:

R2(config-pmap)#


4.4.4.4:80 with ip ident 0

R2(config-pmap)#

And www.ipexpert.com:

R2(config-pmap)#

May 30 15:41:38.141: %URLF-6-SITE_ALLOWED: (target:class)-(User-OUT:HTTP-

CM):Client 192.1.49.100:1423 accessed server 4.4.4.4:80

R2(config-pmap)#

So we were allowed to go to www.cisco.com and www.ipexpert.com as that was a locally permitted site. You can do many other sites to test this but anything that is not locally permitted should be redirected to ACS as the allow_mode is off for the User subnet. Be aware the output of zone pair urlfilter shows “URL Filtering is in ALLOW_MODE”. This means the process is running in ALLOW_MODE not that allow mode is on. I got caught up by this at first. We are always going to be in ALLOW_MODE as the trend micro server doesn‟t exist for us.









R2(config-pmap)#do zp User-OUT urlfilter

policy exists on zp User-OUT

Zone-pair: User-OUT

Service-policy inspect : User->OUTSIDE

Class-map: FILTER-BUSINESS-HOURS (match-all)


Match: access-group name BUSINESS-HOURS

Inspect

Session creations since subsystem startup or last reset 0

Current session counts (estab/half-open/terminating) [0:0:0]

Maxever session counts (estab/half-open/terminating) [0:0:0]

Last session created never

Last statistic reset never

Last session creation rate 0

Maxever session creation rate 0

Last half-open session total 0

URL Filtering is in ALLOW_MODE

Trend server : filter.trendmicro.com(port: 6895)

Current requests count: 0

Current packet buffer count(in use): 0

Maxever request count: 0

Maxever packet buffer count: 0

Total cache hit count: 0

Total requests sent to URL Filter Server :0

Total responses received from URL Filter Server :0

Total error responses received from URL Filter Server :0

Total requests allowed: 0

Total requests blocked: 0

1min/5min Avg Round trip time to URLF Server: 0/0 millisecs

Last req round trip time to URLF Server: 0 millisecs

Class-map: HTTP-CM (match-all)


Inspect

Packet inspection statistics [process switch:fast switch]

tcp packets: [9:63]




Last session created 00:04:08





URL Filtering is in ALLOW_MODE

The processed switched packets are the redirects to ACS.




Trend server : filter.trendmicro.com(port: 6895)

Current requests count: 0

Current packet buffer count(in use): 0

Maxever request count: 0

Maxever packet buffer count: 0

Total cache hit count: 0

Total requests sent to URL Filter Server :0

Total responses received from URL Filter Server :0

Total error responses received from URL Filter Server :0

Total requests allowed: 0

Total requests blocked: 0

1min/5min Avg Round trip time to URLF Server: 0/0 millisecs

Last req round trip time to URLF Server: 0 millisecs

Class-map: TCP-UDP (match-any)

Match: protocol tcp

2 packets, 56 bytes


Match: protocol udp



Inspect


tcp packets: [0:80]

udp packets: [0:22]









Class-map: ICMP (match-all)

Match: protocol icmp


Pass



Match: any

Drop

0 packets, 0 bytes

R2(config-pmap)#




Moving XP Workstation to the VLAN 13 by changing the VLAN on Cat3 Fa0/15 to VLAN 13 and re-addressing XP to 10.0.13.100. We can re-test going to www.awsome.com and it should work from there. Don‟t forget to re-authenticate with R5.

For one Last test we can change the parameter map for EXEC to allow-mode off and see the change.

R2(config-pmap)#parameter-map type urlfpolicy trend EXEC

R2(config-profile)#allow-mode off

End Verification





2.16 Zone Based Firewall

Configure R2 with four zones: DC, EXEC, OUTSIDE, and User.

Inspect TCP and UDP traffic from DC to OUTSIDE and User.

Inspect TCP and UDP traffic from User and EXEC to OUTSIDE.

There is a corporate application to backup user data over TCP Port 9001. Configure R2 to inspect this traffic from DC to EXEC. Do not use an ACL to accomplish this.

Configuration

R2

ip inspect log drop-pkt

!

zone security DC

zone security EXEC

zone security OUTSIDE

zone security User

!

ip access-list extended ICMP




!

class-map type inspect match-all ICMP

match protocol icmp


!

class-map type inspect match-any TCP-UDP

match protocol tcp

match protocol udp

!

policy-map type inspect DC->User

class type inspect TCP-UDP

inspect

class type inspect ICMP

pass

class class-default

drop

policy-map type inspect DC->OUTSIDE


inspect


pass



inspect


pass

policy-map type inspect EXEC->User


pass

policy-map type inspect User->EXEC


pass

Remember the First task that we should only permit 3 types of ICMP

I would suggest this is your most important friend when doing Zone Based Firewall

The class-default is actually created by default. When you create a class for inspect it will add the class-default with action drop. To simply the PG we will only show it on the first policy-map.






inspect


pass

policy-map type inspect OUTSIDE->DC


pass

policy-map type inspect OUTSIDE->EXEC


pass

policy-map type inspect OUTSIDE->User


pass

!

zone-pair security DC-OUT source DC destination OUTSIDE

service-policy type inspect DC->OUTSIDE

zone-pair security DC-User source DC destination User

service-policy type inspect DC->User

zone-pair security EXEC-OUT source EXEC destination OUTSIDE

service-policy type inspect EXEC->OUTSIDE

zone-pair security EXEC-User source EXEC destination User

service-policy type inspect EXEC->User

zone-pair security User-EXEC source User destination EXEC

service-policy type inspect User->OUTSIDE

zone-pair security User-OUT source User destination OUTSIDE

service-policy type inspect User->OUTSIDE

zone-pair security OUT-DC source OUTSIDE destination DC

service-policy type inspect OUTSIDE->DC

zone-pair security OUT-EXEC source OUTSIDE destination EXEC

service-policy type inspect OUTSIDE->EXEC

zone-pair security OUT-User source OUTSIDE destination User

service-policy type inspect OUTSIDE->User

!

interface Gi0/1

zone-member security DC

interface Gi0/1.12

zone-member security User

interface Gi0/1.13

zone-member security EXEC

interface Gi0/1.1256


!## For the Corporate Backup Application ##

ip port-map user-BACKUPS port tcp 9001

!

class-map type inspect match-all BACKUP-APP

match protocol user-BACKUPS

!

policy-map type inspect DC->EXEC

class type inspect BACKUP-APP

inspect


pass

class class-default

drop

Assign each interface to the respective zone

With a classic class-maps in correlation to the MQC you would expect to use ip nbar port-map custom-XX. But remember this is for firewall features so we are using PAM.




policy-map type inspect EXEC->DC


pass

!

zone-pair security DC-EXEC source DC destination EXEC

service-policy type inspect DC->EXEC

zone-pair security EXEC-DC source EXEC destination DC

service-policy type inspect EXEC->DC


This is a pretty typical Zone Based Policy Firewall configuration. We have some basic protocols to be inspected by each policy. As we are using allowing the same protocols between zones we were able to utilize the same class-map for each zone-pair.

As shown above the first command implemented is the ip inspect log drop-pkt. This is your friend, don‟t forget it.

So some basic steps for ZFW:

1. Define classes of traffic you want to match. If it is only traffic that should be match based on source or destination don‟t forget to include the class map.

2. Remember, the difference between match-any and match-all on the class-map. If you want to match a single protocol when it is from a specific source and destination then you should use match-all. If it is to match a group of protocols remember to use the match-any. Without remembering these important rules you will get caught up trying to troubleshoot why your policies are not working.

3. If it is a layer 3/4 protocol apply this class-map traffic to a inspection policy-map. If it a layer 7 class-map with extended features you will apply this to a layer 3/4 inspection to be serviced for deeper packet inspection.

4. What will you do with the class map: drop, log, reset, inspect pass? 5. By default the parameter-map default is applied to all inspection rules. If you need to change

the default parameters such as max-incomplete TCP timeouts, ICMP timeouts, etc you will need to define a new parameter map and apply this to the inspect action.

You will notice up above that we created a zone-pair for all zones. In the first question of this Lab we were requested to make sure ICMP echo, echo-reply, and unreachables are permited. You can inspect ICMP from one zone to another but you will find that echo-reply will be denied if you are also inspecting in the opposite direction as well. You could either do what we did or make sure to only inspect ICMP excluding echo reply in one direction and then in the other direction permit the traffic with an ACL. Either way will work.

Verification

We know there should be some ntp traffic by default going from the catalyst switches to R9. So, lets check that traffic.

Note: I got tired of typing “show policy-map type inspect zone-pair” so I used the command, “alias exec zp show policy-map type inspect zone-pair” to save myself time in typing this. I would suggest there are a few alias commands that would save you time in your studies as well.

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_zone_polcy_firew.html




R2(config)#do zp User-OUT sessions


Zone-pair: User-OUT





Inspect


Match: protocol tcp

0 packets, 0 bytes


Match: protocol udp

1 packets, 76 bytes


Inspect




Pass

0 packets, 0 bytes


Match: any

Drop

0 packets, 0 bytes

R2(config)#do zp EXEC-OUT sessions

policy exists on zp EXEC-OUT

Zone-pair: EXEC-OUT

Service-policy inspect : EXEC->OUTSIDE




Inspect


Match: protocol tcp

0 packets, 0 bytes


Match: protocol udp

1 packets, 76 bytes


Inspect







Pass

0 packets, 0 bytes


Match: any

Drop

0 packets, 0 bytes

R2(config)#

Okay. We can see the UDP traffic is being match and inspected so we know our inspect policies are working. We can configure Cat3 for http and change the default port to 9001. If this was a router, we could configure SSH rotary on one of the VTY lines.

Cat3(config)#ip http server

Cat3(config)#ip http port 9001

Cat3(config)#

I needed to add a route on ACS to test this.

route add -p 10.0.0.0 mask 255.255.0.0 10.1.1.1


R2(config)#do zp DC-EXEC

policy exists on zp DC-EXEC

Zone-pair: DC-EXEC

Service-policy inspect : DC->EXEC

Class-map: BACKUP-APP (match-all)

Match: protocol user-BACKUPS

Inspect


tcp packets: [0:185]










Match: any

Drop

0 packets, 0 bytes

R2(config)#

And we can definitely see the traffic being matched by the correct class and we were able to establish a connection with Cat3.




Now we haven‟t gotten to this yet, but don‟t forget we are going to need to allow the inbound traffic that we have configured in all the previous sections. I noticed some interesting things in the logs right now.


10.1.1.100:514 due to policy match failure with ip ident 0

R2(config)#



R2(config)#



We will take care of this all at the end of the lab to make sure we cover everything.

End Verification




2.17 User to DC zone

For HTTP traffic, this should include the ACS application, from zone User to zone DC do not allow java-applets to be downloaded.

Do not allow Users to send for requests for HTTP data with a URI greater than 300 bytes. Make sure to log any violations.

Inspect TCP and UDP traffic from User zone to DC.

Configuration

R2

ip port-map http port tcp 2002

!

!

class-map type inspect http match-any JAVA-URI

match response body java-applet

match request uri length gt 300

!

policy-map type inspect http JAVA-URI

class type inspect http JAVA-URI

reset

log

!

policy-map type inspect User->DC


inspect

service-policy http JAVA-URI


inspect


pass

class class-default

drop

!

zone-pair security User-DC source User destination DC

service-policy type inspect User->DC


In this question we have implemented an example of a Layer 7 inspection rule. The task requires any http session that includes java-applets or has a URI request greater than 30 bytes to be reset. It also states ACS should be included in this rule so we need to apply PAM to filter these responses.

With http class-maps, you will find that there are three options for match; request, response, and req-resp. Each of them are required for different actions. Here a java-applet is an application sent to the user from the server. So we used the response tag. For URI this is a request as it is either going to be manually entered into the address bar by the user or will be sent to the server after the user clicks a link somewhere on a webpage.

Verification

First, by removing the port-map we can verify we are able to browse to ACS and that the java applet loads. To remove the port-map or to get it working with the configuration we have done above you will

We only need to include 2002 to consider ACS because if a user can‟t get past the login screen we don‟t need to worry about all the other ports.




need to re-configure the class-map type inspect HTTP-CM. Remove and re-add the “match protocol http.”

Any time you create a PAM it must be applied before applying the protocol to a class-map or the configuration will not take effect.

So the first request was successful. Now we can break it and see the applet fail.




Notice the message in the lower left hand corner and that the Login dialoge box is no longer there. And on R2 we receive a log message.

R2(config-pmap-c)#

May 30 04:12:27.963: %APPFW-4-HTTP_JAVA_APPLET: HTTP Java Applet detected -

resetting session 10.1.1.100:2002 192.1.49.100:1296 on zone-pair User-DC

class HTTP-CM appl-class JAVA-URI

R2(config-pmap-c)#

Now to test the URI. We can type in a really long URI string on to the end for ACS and watch it fail.

Here is the string used for testing.

http://192.1.49.150/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help/help

And on R2

R2(config-pmap-c)#

May 30 04:20:16.002: %APPFW-4-HTTP_URI_LENGTH: HTTP URI length (340) out of

range - resetting session 192.1.49.100:1299 10.1.1.100:80 on zone-pair User-

DC class HTTP-CM appl-class JAVA-URI

R2(config-pmap-c)#

Now we haven‟t gotten to this yet, but don‟t forget we are going to need to allow the inbound traffic that we have configured in all the previous sections. I notice some interesting things in the logs right now:



R2(config)#










R2(config)#



But we will take care of this later after we finish.

End Verification

2.18 Mail Filtering

From User to DC make sure that POP3 users have configured mail clients to use secure-passwords.

Also, if an invalid command is sent to the server, reset the connection.

Configuration

R2

class-map type inspect pop3 match-any POP3

match login clear-text

match invalid-command

!

class-map type inspect match-any MAIL

match protocol pop3

!

policy-map type inspect pop3 POP3

class type inspect pop3 POP3

reset

log

!


no class type inspect TCP-UDP

class type inspect MAIL

inspect

service-policy pop3 POP3


inspect


The features supported by POP3 and IMAP are very similar so if you can feel comfortable to complete this task you would be able to do the same for IMAP.

Verification

In the CBAC Task we had setup ACS as a Mail Server for XP workstation. We can move XP workstation to VLAN 12 for this task and retest the mail client from this location.

Change the settings on it to have the server now be 192.1.49.150 and then try a send receive from XP. From the client you will see.

You should see the following message on R2.




R2(config)#

May 30 05:52:16.485: %FW-5-POP3_INVALID_COMMAND: (target:class)-(User-DC:MAIL):Invalid

POP3 command from initiator (192.1.49.100:1315): Invalid verb

May 30 05:52:16.485: %FW-5-POP3_NON_SECURE_LOGIN: (target:class)-(User-DC:MAIL):LOGON

POP3 command from initiator (192.1.49.100:1315): Cleartext logon not allowed while

secure-login is configured

R2(config)#


10.1.1.100:110 with ip ident 0

R2(config)#

Next, we can open a command prompt and send an invalid command to the server. telnet to 192.1.49.150 port 110 and send the command “what” as we did in this example.

R2(config)#

May 30 05:54:31.853: %FW-5-POP3_INVALID_COMMAND: (target:class)-(User-DC:MAIL):Invalid

POP3 command from initiator (192.1.49.100:1316): Invalid verb

R2(config)#


10.1.1.100:110 with ip ident 0

R2(config)#

End Verification




Clean-UP Configuration

We need to make sure that everything that has been requested in earlier sections is still working. We have all sorts of firewalls in this topology, so I recommend re-testing everything.

So, first to fix the things we know.

We need to allow SYSLOG to ACS from the Routers:

R1 R2 R5 R6 R7

logging source-interface Loopback0

R2

object-group network ROUTERS

host 1.1.1.1

host 5.5.5.5

host 6.6.6.6

host 7.7.7.7

host 9.9.156.8

!

ip access-list extended OUTSIDE->DC

permit udp any host 10.1.1.100 eq domain

permit udp object-group ROUTERS host 10.1.1.100 eq syslog

permit tcp 9.4.45.0 0.0.0.255 host 10.1.1.100 eq smtp pop3 2002

permit tcp 9.4.45.0 0.0.0.255 host 10.1.1.100 range 1024 65535

permit tcp 9.4.45.0 0.0.0.255 10.1.1.0 0.0.0.255 eq www 443

permit tcp 9.16.146.0 0.0.0.255 10.1.1.0 0.0.0.255 eq www 443

permit tcp 9.16.146.0 0.0.0.255 host 10.1.1.100 eq smtp pop3 2002

permit tcp 9.16.146.0 0.0.0.255 host 10.1.1.100 range 1024 65535

permit tcp host 7.7.7.7 host 10.1.1.100 eq tacacs

permit tcp host 9.7.7.10 host 10.1.1.100 eq tacacs

!

class-map type inspect match-all OUTSIDE->DC

match class-map TCP-UDP

match access-group name OUTSIDE->DC

!

policy-map type inspect OUTSIDE->DC

class type inspect OUTSIDE->DC

inspect

ip access-list extended OUTSIDE->EXEC




!

class-map type inspect match-all OUTSIDE->EXEC


match access-group name OUTSIDE->EXEC

!

policy-map type inspect OUTSIDE->EXEC

class type inspect OUTSIDE->EXEC

inspect




ip access-list extended OUTSIDE->User




!

class-map type inspect match-all OUTSIDE->User


match access-group name OUTSIDE->User

!

policy-map type inspect OUTSIDE->User

class type inspect OUTSIDE->User

inspect

So, we should be working now. Go through and test things out.


Password:

Cat3#q



Password:

Cat2#q


R4(config)#

Make sure to test the Auth Proxy from ACS to R7 and if that works we should be good at this point.

End Of Lab














Lab 2B: Troubleshoot Cisco

IOS Firewalls






2.0 Cisco IOS Firewall Troubleshooting Detailed Solutions


2.1 Base Configuration

Configure R9 as an NTP master. Configure the Clock and Time zone on all the routers/switches based on EST (-5 GMT), account for daylight savings time. Make sure the clocks of all the routers/switches are synchronized to R9.

Use the Loopback0 address of each router as the source for NTP requests, except R9 source from Fa0/1, R8 BVI1, and the Catalysts source from their VLAN interface. Authenticate all NTP Associations using password “ipexpert”.

In this lab you should allow ICMP echo, echo-reply and traceroute even when not specified by a task for firewall or filtering rules. No other ICMP traffic should be allowed. If a task requires logging make sure to send the logs to ACS.


The approach I will take to the following sections relates simply to testing the section tasks. Since we are not told there is something wrong here we have nothing better to go on other than testing the task and then if something doesn‟t work we can look to see why. Here are some things to keep in mind for this task. According to Cisco Documentation, reasons why NTP may not work include:

Access control lists that do not permit UDP port 123 packets to come through

Misconfiguration in the routers, such as the clock timezone and clock summer-time commands are absent on the routers

Public time server is down NTP server software on NT or UNIX is misconfigured

More traffic is on the router and more traffic on the way to the server NTP master lost sync and router loses sync periodically

High CPU utilization

High offset and more between the server and the router (use the show ntp association detail command to check for this)

Again we don‟t know what is wrong (if anything) so lets just test.

R1:

R1#sh ntp status

Clock is synchronized, stratum 3, reference is 9.9.156.9

nominal freq is 250.0000 Hz, actual freq is 250.0033 Hz, precision is 2**24

reference time is CEFE3D07.AB70108C (20:51:03.669 EST Sun Jan 17 2010)

clock offset is -0.0101 msec, root delay is 0.00 msec

root dispersion is 0.01 msec, peer dispersion is 0.00 msec

loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000013228 s/s

system poll interval is 64, last update was 217 sec ago.

R1#




R1#show ntp association

address ref clock st when poll reach delay offset disp

*~9.9.156.9 127.127.1.1 2 42 64 377 0.000 -10.167 3.981

* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R1#

R2:

R2#show ntp status



reference time is CEFE3D7E.48346EE6 (20:53:02.282 EST Sun Jan 17 2010)





R2#show ntp associations


*~9.9.156.9 127.127.1.1 2 56 64 377 0.000 -0.373 4.898


R2#

R4:

R4#show ntp status



reference time is CEFE3E02.3B8F1251 (20:55:14.232 EST Sun Jan 17 2010)

clock offset is 0.0043 msec, root delay is 0.00 msec




R4#show ntp association


*~9.9.156.9 127.127.1.1 2 4 64 377 0.000 4.329 1.753


R4#

R5:

R5#show ntp status



reference time is CEFE3E8C.F604505C (20:57:32.961 EST Sun Jan 17 2010)










*~9.9.156.9 127.127.1.1 2 11 64 377 0.000 -0.585 1.774


R5#

R6:

R6#show ntp status

Clock is unsynchronized, stratum 16, no reference clock


reference time is 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)



loopfilter state is 'FSET' (Drift set from file), drift is 0.000012794 s/s

system poll interval is 64, never updated.



~9.9.156.9 .INIT. 16 - 1024 0 0.000 0.000 15937.


R6#

R7:

R7#show ntp status






loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000015032 s/s




~9.9.156.9 .AUTH. 16 2730 64 0 0.000 0.000 16000.


R7#

R8:

R8#show ntp status



reference time is CEFE3F34.1276AC12 (21:00:20.072 EST Sun Jan 17 2010)



loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000006098

s/s


Notice here that R6 is not synchronized. Remember that it‟s in a standby group with R1.

Again we are not in sync with the server.

Notice the ref clock shows “AUTH”

Notice the ref clock here is “INIT”




R8#show ntp assoc


*~9.9.156.9 127.127.1.1 2 29 64 377 0.000 6.877 2.735


R8#

R9:

R9#show ntp status



reference time is CEFE3F50.998CB318 (21:00:48.599 EST Sun Jan 17 2010)





R9#show ntp assoc


*~127.127.1.1 .LOCL. 1 11 16 377 0.000 0.000 0.243


R9#

Cat2:

Cat2#show ntp status



reference time is CEFE3F54.C15EA439 (21:00:52.755 EST Sun Jan 17 2010)



Cat2#show ntp assoc


*~9.9.156.9 127.127.1.1 2 31 64 377 3.3 0.07 0.3

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

Cat2#

Cat3:




reference time is CEFE3F61.50E01A5E (21:01:05.315 EST Sun Jan 17 2010)



Cat3#show ntp assoc


*~9.9.156.9 127.127.1.1 2 30 64 377 3.3 0.28 0.5


Cat3#




Cat4:




reference time is CEFE3F5A.E7C0B424 (21:00:58.905 EST Sun Jan 17 2010)



Cat4#show ntp assoc


*~9.9.156.9 127.127.1.1 2 46 64 377 4.0 -0.04 0.6


Cat4#

So everything looks ok except for R6 and R7. Lets begin with R7. I have a feeling this is going to be fairly easy since the reference clock shows a status of “AUTH”. Let‟s look at the NTP configuration on R7:

R7(config)#do sh run | sect ntp

ntp authentication-key 1 md5 045802150C2E 7

ntp authenticate

ntp trusted-key 1



R7(config)#

Everything that should be in the configuration is. We are sourced from Loopback0. We have a key configured. We are using R9 as our NTP Server. Lets debug NTP all on R7:

R7(config)#do debug ntp all

NTP events debugging is on

NTP core messages debugging is on

NTP clock adjustments debugging is on

NTP reference clocks debugging is on

NTP packets debugging is on

R7(config)#

As we wait we begin to see NTP messages start to come in:

R7(config)#

*Jan 18 02:23:56.614: NTP message sent to 9.9.156.9, from interface

'Loopback0' (7.7.7.7).

*Jan 18 02:23:56.614: NTP message received from 9.9.156.9 on interface

'Loopback0' (7.7.7.7).

*Jan 18 02:23:56.614: NTP Core(DEBUG): ntp_receive: message received

*Jan 18 02:23:56.614: NTP Core(DEBUG): ntp_receive: peer is 0x473B6D68, next

action is 1.

*Jan 18 02:23:56.614: NTP Core(NOTICE): ntp_receive: dropping message:

crypto-NAK.

R7(config)#




Notice that we are dropping NTP because of crypto. What‟s happening here? The key has an issue. Lets reconfigure the key and see what we come up with:

R7(config)#ntp authentication-key 1 md5 ipexpert

R7(config)#

Again we wait and now we notice a change in the debug:

R7(config)#


'Loopback0' (7.7.7.7).


'Loopback0' (7.7.7.7).


*Jan 18 02:28:31.618: NTP Core(DEBUG): ntp_receive: peer is 0x473B6D68, next

action is 1.

*Jan 18 02:28:31.618: NTP Core(DEBUG): receive: packet given to

process_packet

*Jan 18 02:28:31.618: NTP Core(DEBUG): Peer becomes reachable, poll set to 6.

*Jan 18 02:28:31.618: NTP Core(INFO): peer 9.9.156.9 event 'event_reach'

(0x84) status 'unreach, conf, auth, 2 events, event_reach' (0xE024)

R7(config)#

Now lets look at the ntp association and ntp status:

R7(config)#do sh ntp assoc


~9.9.156.9 127.127.1.1 2 12 64 3 0.000 0.845 3937.7


R7(config)#do sh ntp status








R7(config)#

Notice that in the show ntp status the stratum is 16 however in the show ntp association the stratum is 2. For some reason in IOS 12.4 it takes a really long time to synchronize so we‟ll leave it at this for now and come back to it later. For now lets move on to R6.

R6 is going to be a little more complex because the status show “INIT.” This tells us that we have tried to sync- it‟s configured, but we don‟t hear anything from the NTP server. Lets see if the NTP Server is sending us time:

R9#debug ntp all






R9#




Jan 18 02:34:46.075: NTP message received from 9.9.156.8 on interface

'FastEthernet0/1' (9.9.156.9).

Jan 18 02:34:46.075: NTP Core(DEBUG): ntp_receive: message received

Jan 18 02:34:46.075: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is

3.

Jan 18 02:34:46.075: NTP Core(DEBUG): ntp_receive: doing fast answer to client.

Jan 18 02:34:46.075: NTP message sent to 9.9.156.8, from interface 'FastEthernet0/1'

(9.9.156.9).

R9#

Jan 18 02:34:52.623: NTP message received from 7.7.7.7 on interface 'FastEthernet0/1'

(9.9.156.9).



3.



(9.9.156.9).

R9#


(9.9.156.9).



3.



(9.9.156.9).

R9#





3.



(9.9.156.9).

R9#


(9.9.156.9).



3.



(9.9.156.9).

R9#





3.



(9.9.156.9).

R9#


(9.9.156.9).



3.



(9.9.156.9).




R9#





3.



(9.9.156.9).

R9#


(9.9.156.9).



3.



(9.9.156.9).

R9#





3.



(9.9.156.9).

R9#

What we can tell here is that every device except for R6 (6.6.6.6) is sending NTP requests and getting a response. Let‟s see if we can kick NTP on R6 into sending a request:

R6(config)#do sh run | sect ntp

ntp authentication-key 1 md5 121015120A1B09163E 7

ntp authenticate

ntp trusted-key 1




R6(config)#do debug ntp all






R6(config)#ntp server 9.9.156.9 key 1

R6(config)#ntp aut


'Loopback0' (6.6.6.6).

R6(config)#

Look over on R9:

R9#







Jan 18 02:48:34.367: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next

action is 3.

Jan 18 02:48:34.367: NTP Core(DEBUG): ntp_receive: doing fast answer to

client.

Jan 18 02:48:34.367: NTP message sent to 6.6.6.6, from interface


Well we see that R9 received the NTP request and sent it back to R6 but even with the debug on R6 we see nothing. How does R9 get to 6.6.6.6?

R9#show ip route 6.6.6.6






* 9.9.156.11, from 9.9.156.11, 01:40:18 ago


AS Hops 1

Route tag 16

R9#

That‟s interesting. R9 is sending traffic destine for 6.0.0.0/8 over to R1. Let‟s see what‟s going on with R1:

R1#

Jan 18 02:49:30.108: %SEC-6-IPACCESSLOGP: list FW denied udp 9.9.156.9(123) -

> 6.6.6.6(123), 1 packet

R1#

Well we now start to see what‟s going on. R6 is sending the NTP request to R9. R9 responds via R1 and R1 drops because it‟s not allowed in the ACL FW. We can either allow the traffic through the ACL FW or modify the BGP configuration. Lets look at the ACL on R1:

R1(config)#do sh access-l FW

Extended IP access list FW

10 deny ip 0.0.0.0 0.255.255.255 any

20 deny ip 10.0.0.0 0.255.255.255 any

30 deny ip 127.0.0.0 0.255.255.255 any

40 deny ip 169.254.0.0 0.0.255.255 any

50 deny ip 172.16.0.0 0.15.255.255 any

60 deny ip 192.0.2.0 0.0.0.255 any

70 deny ip 192.18.0.0 0.1.255.255 any

80 deny ip 192.88.99.0 0.0.0.255 any

90 deny ip 192.168.0.0 0.0.255.255 any

100 deny ip 224.0.0.0 15.255.255.255 any

110 deny ip 240.0.0.0 15.255.255.255 any





160 permit tcp host 9.9.156.9 gt 1024 host 9.9.156.11 eq bgp

170 permit 132 host 9.9.156.6 host 9.9.156.11

180 permit udp host 9.9.156.6 eq 1985 15555 host 224.0.0.102 eq 1985

15555 (34655 matches)

190 permit udp host 9.9.156.6 eq 15555 host 9.9.156.11 eq 15555







R1(config)#

Lets add a line for the 6.6.6.6 interface NTP:

R1(config)#

R1(config)#ip access-l ext FW

R1(config-ext-nacl)#201 permit udp host 9.9.156.9 eq ntp host 6.6.6.6 eq ntp



Recall that we left the debug ntp all on R6 enabled:

R6(config)#


'Loopback0' (6.6.6.6).


'Loopback0' (6.6.6.6).


*Jan 18 03:05:00.929: NTP Core(DEBUG): ntp_receive: peer is 0x473B8FC8, next

action is 1.

*Jan 18 03:05:00.929: NTP Core(DEBUG): receive: packet given to

process_packet

*Jan 18 03:05:00.929: NTP Core(DEBUG): Peer becomes reachable, poll set to 6.

*Jan 18 03:05:00.929: NTP Core(INFO): peer 9.9.156.9 event 'event_reach'

(0x84) status 'unreach, conf, auth, 1 event, event_reach' (0xE014)

R6(config)#

And now lets look at our NTP association on R6:

R6(config)#do sh ntp assoc


~9.9.156.9 127.127.1.1 2 16 64 7 0.000 -211545 1938.0


R6(config)#

R6(config)#







loopfilter state is 'FSET' (Drift set from file), drift is 0.000012794 s/s


R6(config)#

Now the Association shows a stratum of 2, whereas the “status” shows a stratum of 16. Let‟s go back to R7 and verify the ntp status there while we give this router time to sync:

Back on R7:







reference time is CEFE4C15.A543222A (21:55:17.645 EST Sun Jan 17 2010)





R7(config)#

And after some time we check R6 again:


2.2 NAT

Configure R5 to NAT 10.0.45.4 to 9.4.45.4. Configure a pool using 9.4.45.0/24 for the rest of the devices on 10.0.45.0/24.

Configure R2 to hide the private addresses 10.1.1.0/24 and 10.0.13.0/24. ACS should appear to the outside as 9.2.1.100 but if attempting to connect to a device on VLAN 12 or a device on VLAN 12 attempts to connect to ACS, it should appear as 192.1.49.150.

Cat3 should appear to the outside as 9.2.13.13 but if attempting to connect to devices on VLAN 45 or devices on VLAN 45 attempting to connect to Cat3, it should appear as 9.9.156.13.

Allow the rest of the IP‟s in VLAN10 and VLAN13 to be translated to R2 Gi0/1.1256.

Configure R2 to keep these PAT translations for ICMP traffic for 3 seconds, UDP for 60 seconds, and TCP for 40 seconds. If a TCP packet doesn‟t complete communication for either FIN or SYN state R2 should remove the translation after 20 seconds.

On R7 configure NAT support. Don not specify an inside our outside for NAT.

Configure R7 to NAT 10.0.7.100 to 9.7.7.100 and 10.0.7.10 to 9.7.7.10. NAT the rest of the 10.0.7.0/24 to 9.7.7.101-9.7.7.250. If addresses are exhausted allow for PAT.

Limit the maximum number of NAT translations for any given host on R7 to 25 translations.

Do not add any static routes to complete this section using the command “ip route…”

The private address space behind these routers should not be advertised to any other outside router unless required by a future task.


Lets test R5:




!!!!!


R4(config)#




R5#sh ip nat tr


icmp 9.4.45.4:5 10.0.45.4:5 9.9.156.9:5 9.9.156.9:5

--- 9.4.45.4 10.0.45.4 --- ---

R5#

Looks good there. Moving on to test the configuration on R2 we test from ACS:

That ping looks good. Let‟s look at the translation on R2:

R2#sh ip nat tra


icmp 192.1.49.150:768 10.1.1.100:768 192.1.49.12:768 192.1.49.12:768

--- 9.2.1.100 10.1.1.100 --- ---

--- 9.2.13.13 10.0.13.13 --- ---

--- 9.9.156.13 10.0.13.13 --- ---

--- 192.1.49.150 10.1.1.100 --- ---

R2#

Ok so that NAT translation works. Let‟s ping from ACS to R9.




Ping fails so let‟s check the translation on R2:

R2#sh ip nat tra


icmp 9.2.1.100:768 10.1.1.100:768 9.9.156.9:768 9.9.156.9:768

--- 9.2.1.100 10.1.1.100 --- ---

--- 9.2.13.13 10.0.13.13 --- ---

--- 9.9.156.13 10.0.13.13 --- ---

--- 192.1.49.150 10.1.1.100 --- ---

Now in the output we can see that it is creating the translation. Let‟s look over on R9 and see how it handles the reply.

R9(config)#do sho ip route 9.2.1.100


Known via "bgp 1256", distance 200, metric 0, type locally generated


* directly connected, via Null0


AS Hops 0

R9(config)#

R9 believes the network to be learned via BGP and it points to null0. That‟s not getting back. Also, the route we are using to get to 9.2.1.100 is represented by a /8 route in the routing table on R9. There should be a more specific route than that. The problem is that the lab never mentiones that we need to do anything with routing but if we don‟t then nobody on the outside can reach the ACS server. So, there are two things we can do. We can create a loopback interface for the 9.2.1.0 network and redistribute that into our EIGRP Process or we can use an option in our nat command that advertises the route for us. Lets see if that‟s been don‟t on R2:

R2(config)#do sh run | in ip nat

ip nat inside

ip nat outside

ip nat inside

ip nat outside

ip nat translation tcp-timeout 40

ip nat translation udp-timeout 60

ip nat translation finrst-timeout 20

ip nat translation syn-timeout 20

ip nat translation icmp-timeout 3


ip nat pool POOL1 9.2.1.150 9.2.1.150 prefix-length 24

ip nat inside source list NAT interface Vlan1256 overload





Notice that the nat pool called POOL2 has the option add-route at the end. This would advertise that route. Let‟s see what our routing table on R9 shows for the 9.2.13 network.




R9(config)#do sh ip route 9.2.13.0






* 9.9.156.2, from 9.9.156.2, 01:40:58 ago


AS Hops 1

Route tag 2

R9(config)#

Notice that we have learned this via R2. Let‟s add the “add-route” option to the other Pool.

R2(config)#ip nat pool POOL1 9.2.1.150 9.2.1.150 prefix-length 24 add-route

Then let‟s look at the route on R9 again:

R9(config)#do sho ip route 9.2.1.100






* 9.9.156.2, from 9.9.156.2, 00:00:32 ago


AS Hops 1

Route tag 2

R9(config)#

Now we are looking better. Lets test the connectivity now:

Now that that‟s good to go we know the task functions as far as the NAT goes. We know there is an issue with the Zone-Based firewall but we will address that in a later task.





2.3 Legacy Resource Protection

On R5 allow HTTP and HTTPS destined to a Web Server located at 9.4.45.4 from anywhere coming in through Fa0/1.1256. Traffic Filtering should be done on this external facing interface.

To protect this web server from TCP SYN attacks configure R5 to protect this server against attacks. R5 should begin to drop connections if the amount of half open connections exceeds 300. It should return to normal after this number falls below 150. When the router does enter aggressive mode change the default behavior for half open sessions. Exclude the PAT‟ed devices behind R2.

The above mentioned Web Server will be taken down for Maintenance and Backups between 1:00 AM and 3:00 AM every Wednesday. The Maintenance schedule will come into effect on the 1st of the month for the next 6 months. Do not allow communication to it during these maintenance windows.


Start by connecting to R4‟s web ports from ACS. This traffic will pass through R5 and we can verify the configuration from there:

We can see that the connection is established because we are presented with the Security Alert regarding the SSL certificate on R4. Lets see the TCP intercept stats on R5:

R5#show tcp intercept connections

Incomplete:


Established:





TCP intercept is not seeing this traffic. Here we need to think of the pieces that come together here. First off, there should be a time-range for these web ports that is only be active the first of the month for the next 6 months.

Let‟s take a look at the time-range on R5:

R5#show time-range

time-range entry: WEB-ACCESS (inactive)






time-range entry: WEB-MAINT (inactive)





R5#

Looks like the time-range WEB-MAINT is the one we want and its used in an ACL. We want to note that it‟s inactive right now and check our clocks. Remember we have NTP configured. Aside from that fact that its inactive, which is not necessarily bad, it‟s configured correctly so let‟s see how the ACL looks:

R5#sh access-l IN-FILTER


10 deny ip 10.0.0.0 0.255.255.255 any

20 deny ip 172.16.0.0 0.15.255.255 any

30 deny ip 192.168.0.0 0.0.255.255 any

40 deny ip host 0.0.0.0 any log

50 deny ip 127.0.0.0 0.255.255.255 any log-input



80 deny ip host 255.255.255.255 any log-input

90 permit icmp any any echo (5 matches)


110 permit icmp any any unreachable (380 matches)

120 deny tcp any host 9.4.45.4 eq www time-range WEB-MAINT (inactive)

130 deny tcp any host 9.4.45.4 eq 443 time-range WEB-MAINT (inactive)

140 permit tcp any host 9.4.45.4 eq www




200 permit udp host 9.9.156.9 host 5.5.5.5 eq ntp (4022 matches)


210 permit tcp any 10.0.45.0 0.0.0.255 established




250 evaluate REF-ALC

R5#

The ACL is ok so let‟s verify that clock. This should have been checked in task 2.1 but it doesn‟t hurt to verify again:




R5#sh ntp status



reference time is CEFE5D9C.EE328674 (23:10:04.930 EST Sun Jan 17 2010)




s/s


R5#

R5#show clock

23:13:22.022 EST Sun Jan 17 2010

R5#

And again, ACS has no problem connecting to R4 but examining the TCP intercept on R5 we see that it‟s not even picking up the port 80 and port 443 connections from ACS to R4:

R5#sh tcp int conn

Incomplete:


Established:


R5#

So Let‟s verify the configuration:

R5#sh run | in tcp intercept

ip tcp intercept list WEB_SERVER

ip tcp intercept max-incomplete low 150 high 300

ip tcp intercept mode watch

ip tcp intercept drop-mode random

R5#

R5#sh access-l WEB_SERVER

Extended IP access list WEB_SERVER

10 deny tcp host 9.9.156.2 host 9.4.45.4

20 permit tcp any host 9.4.45.4

R5#

The Access-list WEB_SERVER is configured incorrectly. The destination host should be the “real” address of R4.

R5#conf t


R5(config)#ip access-l ext WEB_SERVER

R5(config-ext-nacl)#no 10

R5(config-ext-nacl)#10 permit tcp host 9.9.156.2 host 10.0.45.4


R5(config-ext-nacl)#20 permit tcp any host 10.0.45.4


Now test again and verify on R5:




R5(config-ext-nacl)#do sh tcp in conn

Incomplete:


9.2.1.100:4169 10.0.45.4:443 SYNSENT 00:00:29 00:00:00 W

9.2.1.100:4168 10.0.45.4:443 SYNSENT 00:00:29 00:00:00 W

9.2.1.100:4170 10.0.45.4:443 SYNSENT 00:00:27 00:00:02 W

9.2.1.100:4171 10.0.45.4:80 SYNSENT 00:00:14 00:00:15 W

Established:



Time is correct, ACL is correct, time-range is applied, and TCP intercept is providing the protection required. If you want to take it a step further you could change the clock and see if the time-range kicks in and blocks the connection. Here I don‟t think we need to but again- you can if you want. I‟m assuming that if you are actually in the lab exam you are limited in the time you can spend on troubleshooting.


2.4 Legacy Traffic Control

On R5 allow users on 10.0.45.0 network to reach external networks. Allow the following:

SSH to the Catalyst Switches listed in the Topology SMTP DNS HTTP HTTPS

The return entries should be automatically created for the above mentioned traffic. These entries should expire after 3 minutes for TCP based protocols. DNS entries should expire after 1 minute. Use minimum configuration lines to accomplish this without the use of anything newer than 12.1 Mainline.

Only allow SSH on the VTY lines for the Catalyst switches. The user should be automatically put into level 15. Do not use AAA.

In Addition users from the 10.0.45.0 network should be able to go to the outside networks and return for other TCP based traffic without the use of reflexive ACL‟s or CBAC.

Only allow DNS queries to be sent to ACS. The ACL entry should be as specific as possible.

Users on the 10.0.45.0 network are only allowed to browse the Web during the following times:

12:00 to 1:00 PM on Weekdays 5:00 PM to Midnight on Weekdays All day on Saturday and Sunday.

Filter all RFC 1918 addresses without these being logged. Also block any address that should never be in the source address field. But do log this specific traffic; include with this log the source MAC.

You cannot use CBAC to accomplish the tasks in this section. Allow relevant traffic coming in. Make sure Routing is still working after you are done with this task. Be sure to log any additional traffic that violates these rules.





In this task the main section to verify is the reflexive access-list. There is also some ACL configuration that you would want to verify but let‟s check the reflexive ACL.


R4#

No good there let‟s see R5:

R5#sh ip access-l REF-ACL


R5#

Jan 13 17:37:40.433: %SEC-6-IPACCESSLOGP: list IN-FILTER denied tcp

9.16.146.14(22) -> 9.4.45.4(31789), 1 packet

R5#

IN-FILTER is dropping the return SSH traffic. Let‟s look at IN-FILTER:

R5#sh access-l IN-FILTER


10 deny ip 10.0.0.0 0.255.255.255 any

20 deny ip 172.16.0.0 0.15.255.255 any

30 deny ip 192.168.0.0 0.0.255.255 any

40 deny ip host 0.0.0.0 any log




80 deny ip host 255.255.255.255 any log-input




120 deny tcp any host 9.4.45.4 eq www time-range WEB-MAINT (inactive)

130 deny tcp any host 9.4.45.4 eq 443 time-range WEB-MAINT (inactive)

140 permit tcp any host 9.4.45.4 eq www (9 matches)






210 permit tcp any 10.0.45.0 0.0.0.255 established




250 evaluate REF-ALC

There is a deny ip any any that comes before the evaulate statement. Let‟s correct that.

R5#conf t


R5(config)#ip access-l ext IN-FILTER


R5(config-ext-nacl)#deny ip any any log

Also you can resequence the ACL after the changes if it makes you feel good:




R5(config)#ip access-l resequence IN-FILTER 10 10

Test again from R4:


Password:

Cat3#


Password:

Cat2#


Password:

Cat4#

And verify on R5:

R5(config)#do sh ip access-l REF-ACL



(time left 177)


(time left 140)


(time left 111)

R5(config)#

Perfect! Now we need to verify that the Web browsing with the time-range functions. Let‟s look at it now:

R5(config)#do sh time

time-range entry: WEB-ACCESS (active)






As of right now it‟s active. Let‟s test.

R4#telnet 9.2.1.100 80

Trying 9.2.1.100, 80 ... Open

And look at the ACL on R5:

R5(config)#do sh access-l OUT-FILTER

Extended IP access list OUT-FILTER




40 permit tcp 9.4.45.0 0.0.0.255 host 192.1.49.12 eq 22 reflect REF-ACL

(12 matches)





(12 matches)


(32 matches)

70 permit tcp 9.4.45.0 0.0.0.255 any eq smtp reflect REF-ACL

80 permit tcp 9.4.45.0 0.0.0.255 any eq www time-range WEB-ACCESS

(active) reflect REF-ACL (3 matches)

90 permit tcp 9.4.45.0 0.0.0.255 any eq 443 time-range WEB-ACCESS

(active) reflect REF-ACL

100 deny tcp 9.4.45.0 0.0.0.255 any eq www log (1 match)

110 deny tcp 9.4.45.0 0.0.0.255 any eq 443 log

120 permit tcp any any (87 matches)

130 permit udp 9.4.45.0 0.0.0.255 host 9.2.1.100 eq domain reflect REF-

ACL




R5(config)#

OUT-FILTER matched the outbound packet on line 80 because the time-range is active. This entry is also configured to reflect to REF-ACL for the return traffic so we should see and entry there as well.

R5(config)#do sh ip access-l REF-ACL


permit tcp host 9.2.1.100 eq www host 9.4.45.4 eq 33904 (4 matches)

(time left 163)


(time left 150)

Requirements are now met.


2.5 Lock and Key Access Lists

You need to allow access to a web server at 4.4.4.4 but not without authenticated access. Configure R5 to authenticate users prior to allowing access to a web server located at 4.4.4.4. After authentication all TCP traffic from the authenticated host should be allowed. This should not affect normal VTY access.

Use username and password “ccie”. This user should not be allowed to login to R5 for local access.

The session should be open at most for 100 minutes. Unless the user authenticates again during the active session. If this does occur it should then be extended for an additional 6 minutes. Force an idle session to timeout after 10 minutes.

Authenticated users should be able to SSH into R4 and R5 for Management access.

Create username ipexpert and password ipexpert on R4 and R5. Log the user to privilege 15 using local AAA authentication and authorization.

Neither of these usernames or passwords should be sent in clear text.





Task 2.5 is straight forward and should be easy to test. We SSH into R5 and authenticate with the username “ccie” which should activate the access-enable option thus allowing TCP traffic from our host through R5. Then we should be able to gain SSH access into 4.4.4.4. The next test would be to verify that we can SSH into R5 and get a CLI using the username “ipexpert.”

We will begin by testing the SSH into R5 to set the access-enable. We can SSH from R9.

R9#ssh -l ccie 9.9.156.5

% Connection refused by remote host

Now this initial connection failed so Ill make sure I can ping R5 from R9:

R9#ping 9.9.156.5



!!!!!


Since that works let‟s make sure that SSH is enabled on R5:

R5(config)#do sh run | section vty

line vty 0 4



autocommand access-enable

transport input ssh

SSH is configured for the VTYs so let‟s make sure we have a key:

R5(config)#cry key gen rsa mod 1024

The name for the keys will be: R5.ipexpert.com



R5(config)#

Jan 18 04:40:40.328: %SSH-5-ENABLED: SSH 1.99 has been enabled

R5(config)#

This is much better! Let‟s go SSH again:

R9#ssh -l ccie 9.9.156.5

Password:


R9#

Here we wanted to be disconnected because this would be the norm for access-enable. Let‟s see if we can in fact get to 4.4.4.4 port 80”




R9#telnet 4.4.4.4 80

Trying 4.4.4.4, 80 ... Open

get


Date: Wed, 13 Jan 2010 22:14:02 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request


R9#

The SSH works so now we look at the access-list.

R5(config)#do sh ip access-l IN-FILTER | in 156.9|DYN






That looks good. Now let‟s try the SSH from R9 to R5 and R4 to gain CLI access:


Password:

% List#IN-FILTER-DYN-LIST absolute timer is extended


R9#

There is a problem with getting CLI access. Rather than accessing the CLI the access-list is being extended. This should only happen when ccie logs in, not ipexpert so let‟s look at the VTYs:

R5(config)#do sh run | section line vty 0 4

line vty 0 4

password cisco



autocommand access-enable

transport input ssh

R5(config)#

Right away we spot the issue. The autocommand access-enable is applied to the VTYs which makes it apply to anyone that makes an SSH session into the router. We want this to only work for the user ccie. We can add the autocommand to the user directly.

R5(config)#do sh run | in username

username ipexpert privilege 15 password 0 ipexpert

username ccie privilege 15 password 0 ccie

R5(config)#username ccie autocommand access-enable


R5(config-line)#no autocommand access-enable

R5(config-line)#exit

R5(config)#exit

R5#




Now we can try the SSH again. First we need to SSH to R5. If that works we should then SSH to R4.


Password:

R5#

R5#

R5#


Password:

Password:

% Password: timeout expired!

[Connection to 4.4.4.4 aborted: error status 0]

Looks like R4 is having some issues with SSH. We need to make sure that SSH has been properly configured:

R4#sh run | sect line vty 0 4

line vty 0 4

privilege level 15

password ipexpert

login

transport input telnet ssh

The login method is not configured for local login.

R4#conf t




Low test again from R9:


Password:

R4#





2.6 IOS Stateful Firewall

R1 and R6 will be running as a stateful failover pair. Configure HSRP on Fa0/1.146 and Fa0/1.1256. Use the address of x.x.x.1 as the HSRP address for each interface and the standby group number should be the same as the IP address third octet. Configure redundancy using the external standby group.

Authenticate the standby groups using password ipexpert. Make sure the password is sent encrypted.

R1 should be configured as the active router unless one of the interfaces IP routing is not functioning, if it can‟t ping R9, or if R1 goes offline. If R1 does go down make sure it waits at least 30 seconds before becoming the active router after a failure but 60 seconds if it is after a reload. R6 should become the active router in the event of a failure after 4 lost hellos and in less than 1 second. Configure the priority on R6 as 60 and R1 priority should be 110.

Make sure that future tasks which require configuration on R1 or R6, the same tasks are completed on the stateful pair even if the question doesn‟t specify to do so.

You have noticed when the connection table runs over 3000 connection entries, you experience performance problems. Correct this problem.


R1 and R6 should be configured for Stateful Failover. Begin by checking that state of inter-device redundancy:

R1#sh red inter-device







R1#

And R6:

R6#sh red int







R6#

Interesting that both devices say they are in standby. Lets reload R1 and see if they start talking.

And as soon as R1 was reloaded we see the following on R6:

R6#

Jan 18 05:42:09.371: %HSRP-5-STATECHANGE: FastEthernet0/1.1256 Grp 156 state

Standby -> Active

Jan 18 05:42:09.371: %SNAT-5-PROCESS: Id 1, System starts converging

Jan 18 05:42:09.375: %SNAT-5-PROCESS: Id 1, System fully converged


Standby -> Active





Active -> Speak


Active -> Speak

Jan 18 05:42:10.083: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down Peer closed the

session

R6#


Standby -> Active




Standby -> Active

R6#

Jan 18 05:42:27.272: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 146: Neighbor 10.0.146.11


R6#

After R1 is back up we look at R1 again:

R1#sh red inter

Redundancy inter-device state: RF_INTERDEV_STATE_DELAY_PNC_ACT

Scheme: Standby




R1#

And we also see that it has become HSRP active.

R1#

*Jan 18 05:55:37.394: %HSRP-5-STATECHANGE: FastEthernet0/1.146 Grp 146 state

Standby -> Active

*Jan 18 05:55:37.570: %HSRP-5-STATECHANGE: FastEthernet0/1.1256 Grp 156 state

Standby -> Active

But notice that R6 still seems off:

R6#sh red inter







R6#

We reload R6:

R6#wr


[OK]

R6#reload

Proceed with reload? [confirm]




Jan 18 05:49:28.902: %SYS-5-RELOAD: Reload requested by console. Reload

Reason: Reload Command.


Standby -> Init


Standby -> Init

Jan 18 05:49:28.918: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down Peer closed the

session

Jan 18 05:49:28.922: %BGP-5-ADJCHANGE: neighbor 9.9.156.9 Down Peer closed

the session Let’s Reload R6.

After R6 comes back up we look at both R1 and R6 again:

R1#sh red inter


Scheme: Standby




R1#

And R6:

R6#sh red int

Redundancy inter-device state: RF_INTERDEV_STATE_HSRP_STDBY_PNC

Scheme: Standby




R6#

Again these routers don‟t look right. They are both in standby and the peer is unknown. We need to look at the ipc zone configuration:

R1#sh run | section ipc zone

ipc zone default

association 1

no shutdown

protocol sctp

local-port 50001

remote-port 55001

remote-ip 9.9.156.6

R1#

And R6

R6#sh run | section ipc zone

ipc zone default

association 1

no shutdown

protocol sctp

local-port 55001

remote-port 50001

remote-ip 9.9.156.11

R6#




Here the local-port is defined but not the local IP. That needs to be corrected so the peers will talk:

R1

R1#conf t


R1(config)#ipc zone default

R1(config-ipczone)# association 1

R1(config-ipczone-assoc)# no shutdown

R1(config-ipczone-assoc)# protocol sctp

R1(config-ipc-protocol-sctp)# local-port 50001

R1(config-ipc-local-sctp)#loca

R1(config-ipc-local-sctp)#local-ip 9.9.156.11

R1(config-ipc-local-sctp)#end

R1#

R6

R6#conf t


R6(config)#ipc zone default

R6(config-ipczone)# association 1

R6(config-ipczone-assoc)# no shutdown

R6(config-ipczone-assoc)# protocol sctp

R6(config-ipc-protocol-sctp)# local-port 55001

R6(config-ipc-local-sctp)#local

R6(config-ipc-local-sctp)#local-ip 9.9.156.6

R6(config-ipc-local-sctp)#

Jan 18 06:01:34.585: %FW_HA-6-AUDIT_TRAIL_STDBY_START: Start tcp standby

session: initiator (9.9.156.11:56424) -- responder (9.9.156.9:179)

R6(config-ipc-local-sctp)#end

R6#

As soon as R6 is configured we see the session is initiated.

Now we look at the state:

R1#sh red inter


Scheme: Standby




R1#

R6#sh red int

Redundancy inter-device state: RF_INTERDEV_STATE_STDBY

Scheme: Standby




R6#

And we test to verify that sessions are going to be replicated.




Cat4#ssh -l ipexpert 9.9.156.5

Password:

R5#

R5#

Now lets see the session on R1:




49268348 (9.9.156.11:56424)=>(9.9.156.9:00179) tcp SIS_OPEN HA_ACTIVE



In SID 9.9.156.9[179:179]=>9.9.156.11[56424:56424] on ACL FW (32 matches)

HA state: HA_ACTIVE

49267DB8 (9.9.156.11:00123)=>(9.9.156.9:00123) udp SIS_OPEN HA_ACTIVE




HA state: HA_ACTIVE

49268080 (10.0.146.14:53088)=>(9.9.156.5:00022) tcp SIS_OPEN HA_ACTIVE




HA state: HA_ACTIVE

Half-open Sessions

49267AF0 (9.9.156.11:01985)=>(224.0.0.102:01985) udp SIS_OPENING HA_ACTIVE



In SID 224.0.0.102[1985:1985]=>9.9.156.11[1985:1985] on ACL FW

HA state: HA_ACTIVE

R1#

And over on R6 we need to see the same session:




495DD138 (9.9.156.11:56424)=>(9.9.156.9:00179) tcp SIS_OPEN HA_STANDBY



In SID 9.9.156.9[179:179]=>9.9.156.11[56424:56424] on ACL FW


495DC618 (9.9.156.11:00123)=>(9.9.156.9:00123) udp SIS_OPEN HA_STANDBY



In SID 9.9.156.9[123:123]=>9.9.156.11[123:123] on ACL FW


495DC350 (10.0.146.14:53088)=>(9.9.156.5:00022) tcp SIS_OPEN HA_STANDBY



In SID 9.9.156.5[22:22]=>9.16.146.14[53088:53088] on ACL FW


Half-open Sessions

R6#




Looks Great! We can also verify the SCTP instances but at this point we know it‟s working.

R1#sh sctp instances
















R1#

R6#sh sctp instances
















R6#

We also want to check the tracking:

R1# show track brie

Track Object Parameter Value Last Change

1 interface FastEthernet0/1.146 ip routing Up 00:26:49


3 ip sla 3 state Up 00:26:49

5 list boolean Up 00:26:48

R1#




R1 is up, let‟s see R6:

R6#sh track brie




3 ip sla 3 state Down 00:19:56

5 list boolean Down 00:19:56

R6#

This is a problem. The interfaces show up but the ip sla shows down. It‟s a Boolean operation so if one of them is down the entire operation is down. Let‟s look at the SLA configuration:

R1#show ip sla config

IP SLAs Infrastructure Engine-II

Entry number: 3

Owner:

Tag:

Type of operation to perform: icmp-echo

Target address/Source address: 9.9.156.9/9.9.156.11

Type Of Service parameter: 0x0

Request size (ARR data portion): 28

Operation timeout (milliseconds): 300

Verify data: No

Vrf Name:

Schedule:

Operation frequency (seconds): 1 (not considered if randomly scheduled)

Next Scheduled Start Time: Start Time already passed

Group Scheduled : FALSE

Randomly Scheduled : FALSE

Life (seconds): Forever

Entry Ageout (seconds): never

Recurring (Starting Everyday): FALSE

Status of entry (SNMP RowStatus): Active

Threshold (milliseconds): 5000 (not considered if react RTT is configured)

Distribution Statistics:

Number of statistic hours kept: 2

Number of statistic distribution buckets kept: 1

Statistic distribution interval (milliseconds): 20

History Statistics:

Number of history Lives kept: 0

Number of history Buckets kept: 15

History Filter Type: None

Enhanced History:

R1#

R1‟s SLA is ok but what about R6?

R6#sh ip sla configuration

R6#

That‟s interesting. It appears the IP SLA configuration is not present. Let‟s look at the config.




R6#show run | section ip sla

track 3 ip sla 3

R6#

Lets build the SLA:

R6#conf t


R6(config)#ip sla 3

R6(config-ip-sla)# icmp-echo 9.9.156.9 source-ip 9.9.156.6

R6(config-ip-sla-echo)#timeout 300

R6(config-ip-sla-echo)# frequency 1

R6(config-ip-sla-echo)#ip sla schedule 3 life forever start-time now

R6(config)#

Now we verify on R6:

R6#sh track brie




3 ip sla 3 state Up 00:00:23

5 list boolean Up 00:00:23

R6#


2.7 Stateful NAT

Configure R1 and R6 for stateful NAT. Use the external HSRP group for redundancy.

10.0.146.14 should be translated to 9.16.146.14. In addition configure R1 and R6 to NAT the rest of the 10.0.146.0/24 network to 9.16.146.0/24. This should all be completed in as few commands as possible and should support inbound connections.

Add one static route on R1 and R6 to get this working. Do not use the same feature as the previous NAT task.


We had an open connection from Cat4 to R5 in the last section. That should create a snat entry:


Password:

R5#

R1#sh ip snat dist


R1#




R6#sh ip snat dist


SNAT: Mode IP-REDUNDANCY :: STANDBY

: State READY


: Local NAT id 1


: Peer NAT id 0

: Mapping List 10

R6#

It looks like R6 is ready but R1 is not. Let‟s verify the configuration:

R1#sh run | section ip nat

ip nat inside

ip nat outside



mapping-id 10

protocol udp


R6#sh run | sec ip nat

ip nat outside

ip nat inside

ip nat inside

ip nat outside



mapping-id 10

protocol udp


ip nat inside source static network 10.4.4.0 10.40.40.0 /24

The ip nat Stateful is identical but they still don‟t want to talk. This could be a side effect of the HSRP/SLA issue we corrected in the last task. Since the configuration is very simple lets remove it and reconfigure.

R1#conf t


R1(config)#no ip nat Stateful id 1

R1(config)#

Jan 15 06:53:52.244: SNAT(conn): SNAT clean up to be done

Jan 15 06:53:52.244: SNAT (Delete): All type entry, from distributed list of

Router-Id 1

Jan 15 06:53:52.244: SNAT (D-dist): Router-id 1 has no entry

Jan 15 06:53:52.244: SNAT (): delete_all_config_bloc

Jan 15 06:53:52.248: SNAT (cleanup): snat global destroyed

R1(config)#ip nat Stateful id 1

R1(config-ipnat-snat)# redundancy REDUNDANCY

R1(config-ipnat-snat-red)# mapping-id 10

R1(config-ipnat-snat-red)# protocol udp

R1(config-ipnat-snat-red)#end

R1#

Jan 15 06:54:11.595: SNAT (conn): HSRP state changes, peer disconnected




Jan 15 06:54:11.595: SNAT Redundancy (init): My Stat: ACTIVE; Group

REDUNDANCY: ACTIVE 9.9.156.11; STANDBY 9.9.156.6

Jan 15 06:54:11.595: SNAT (dscov): Peer NAT id send SYNC message

Jan 15 06:54:11.595: SNAT (Sending): Enqueued SYNC Message of Router-Id 1 for

Router-Id 0

Jan 15 06:54:11.595: SNAT (init): Initialized Peer block for 9.9.156.6

Jan 15 06:54:11.595: SNAT (mapp): Add mapping-id 10 to list

Jan 15 06:54:11.595: SNAT Redundancy (cfg): snat-Mode: IP-REDUNDANCY

Jan 15 06:54:11.595: SNAT Redundancy (cfg): snat-stat: ACTIVE

Jan 15 06:54:11.595: SNAT Redundancy (cfg): actve-add: 9.9.156.11

Jan 15 06:54:11.595: SNAT Redundancy (cfg): stdby-add: 9.9.156.6

Jan 15 06:54:11.595: SNAT Peer block (cfg): Mode : ACTIVE

Jan 15 06:54:11.595: SNAT Peer block (cfg): State: IDLE

Jan 15 06:54:11.595: SNAT Peer block (cfg): laddr: 9.9.156.11

R1# 15 06:54:11.595: SNAT Peer block (cfg): Raddr: 9.9.156.6

Jan 15 06:54:11.595: SNAT (state): Put peer_status back to SNAT_READY, send

new SYN msg


Router-Id 0

Jan 15 06:54:11.595: SNAT (state): 9.9.156.11 <--> 9.9.156.6 went from IDLE

to READY

Jan 15 06:54:11.595: SNAT (State): Hold on sending DUMP_REQUEST msg

Jan 15 06:54:12.311: %SYS-5-CONFIG_I: Configured from console by console

R1#

Jan 15 06:54:12.651: SNAT (Process): Received SYNC message of Router-Id 1

R1#

Jan 15 06:54:15.491: SNAT (Timer): DUMP-REQ ready to be sent out !

Jan 15 06:54:15.491: SNAT (req msg): Built DUMP-REFRESH-REQ of Router-Id 1

Jan 15 06:54:15.491: SNAT (Sending): Enqueued DUMP-REQUEST Message of Router-

Id 1 for Router-Id 1

R1#

Jan 15 06:54:16.651: SNAT (ReadIP): A: notification receiving 0 msgs (0)

Jan 15 06:54:16.651: SNAT (Systm): Increment Convergence level to 1

R1#


Jan 15 06:54:17.595: SNAT (alias): Increase Convergence to 1

Jan 15 06:54:17.595: SNAT (alias): Activate ager timer process send msg.

Jan 15 06:54:17.595: SNAT (conn): increment the counter, Qsize = 0

Jan 15 06:54:17.595: SNAT (Systm): Decrement Convergence level to 0

Jan 15 06:54:17.595: SNAT (Sending): Enqueued CONVERGENCE Message of Router-

Id 1 for Router-Id 1

R1#


Now we test again from Cat4:


Password:

And we see the session begin created on R1:

R1#


Router-Id 1

R1#





R1#

Jan 15 06:54:27.287: SNAT (sndmsg): ADD new entry from router-id 1

Jan 15 06:54:27.287: (SNAT): Got Id:1 for NAT Entry (1,410)

Jan 15 06:54:27.287: SNAT (Sending): Add-Entry(1,410) Fl:4000020 M-Fl:0 L:0

A-Type:0 A-Fl:0 id 1

Jan 15 06:54:27.287: SNAT (Sending): Enqueued ADD Message of Router-Id 1 for

Router-Id 1

Jan 15 06:54:27.287: SNAT (sndmsg): UPDATE entry from router-id 1

Jan 15 06:54:27.287: SNAT (Send): Update Msg: Sub_opcode:0x8000

Jan 15 06:54:27.287: SNAT (Send): Lock-Parent TLV built. msg_len = 64


Jan 15 06:54:27.287: SNAT (Sending): Enqueued UPDATE Message of Router-Id 1

for Router-Id 1

Jan 15 06:54:27.287: SNAT (sndmsg): ADD new entry from router-id 1


Jan 15 06:54:27.291: SNAT (Sending): Add-Entry(1,411) Fl:2 M-Fl:0 L:0 A-

Type:0 A-Fl:0 id 1

Jan 15 06:54:27.291: SNAT (Sending): Enqueued ADD Message of Router-Id 1 for

Router-Id 1

Jan 15 06:54

R1#:27.291: SNAT (sndmsg): UPDATE entry from router-id 1


Jan 15 06:54:27.291: SNAT (Send): Lock-Parent TLV built. msg_len = 64



for Router-Id 1



Jan 15 06:54:27.291: SNAT (Send): Upd-Entry(1,411) Fl:2 M-Fl:0 L:0 A-Type:0

A-Fl:0, SBC-L3:0.0.0.0 SBC-L4: 0

Jan 15 06:54:27.291: SNAT (Send): NAT-Entry-Update TLV built. msg_len = 72



for Router-Id 1

Jan 15 06:54:27.295: %FW-6-SESS_AUDIT_TRAIL_START: Start tcp session:

initiator (10.0.146.14:41184) -- responder (9.9.156.5:22)



Jan 15 06:54:27.299: SNAT (Send): Upd-Entry(1,411) Fl:2 M-Fl:0 L:1 A-Type:0

A-Fl:0, SBC-L3:0.0.0.0 SBC-L4: 0

Jan 15 06:54:27.299: SNAT (Send): NAT-Entry-Update TLV built. msg_len = 72



for Router-Id 1

R1#

R1#


Router-Id 1

R1#


R1#


Router-Id 1

R1#





Look at R1 again:

R1#sh ip snat dist


SNAT: Mode IP-REDUNDANCY :: ACTIVE

: State READY


: Local NAT id 1


: Peer NAT id 1

: Mapping List 10

R1#

Look at the nat table on R1:

R1#sh ip nat trans


tcp 9.16.146.14:41184 10.0.146.14:41184 9.9.156.5:22 9.9.156.5:22

--- 9.16.146.14 10.0.146.14 --- ---

--- 9.16.146.0 10.0.146.0 --- ---

R1#

And compare it to R6:

R6#sh ip nat trans


tcp 9.16.146.14:41184 10.0.146.14:41184 9.9.156.5:22 9.9.156.5:22

--- 9.16.146.14 10.0.146.14 --- ---

--- 9.16.146.0 10.0.146.0 --- ---

--- 10.40.40.0 10.4.4.0 --- ---

And now we are in business. I will say that I have had situations where I have had to remove the configuration on both sides. In this case I didn‟t have to but had removing the configuration on R1 not cause a sync I would have removed it on R6 as well.


2.8 CBAC

Allow all TCP and UDP based traffic to go out and return from the External networks on R1.

For web traffic, only allow Java applets to be downloaded from Web servers 9.2.1.100 and 9.4.45.4. Make sure the ACS login application window is included in this inspection, only 9.2.1.100.

Configure R1 to inspect pop3. Make sure the firewall requires secure-authentication by the clients.

Create an inbound filter on the External interface. Log all the Denies. Only permit traffic as required by the lab.





There are a number of details to verify here. Begin by testing the Java Applet. Note how we can move the XP workstation s we need to for testing.

Cat3#conf t


Cat3(config)#int f0/15

Cat3(config-if)#do sh run int f0/15



!



end

Cat3(config-if)#swi acc vlan 146

Cat3(config-if)#




And we test to ACS:

Note that the Java Applet was allowed. This shouldn‟t be the case. We need to see why this was allowed on R1:

When we move to the console of R1 we see the following:

R1#

Jan 18 06:40:47.280: %FW-6-SESS_AUDIT_TRAIL: Stop tcp session: initiator

(10.0.146.100:1082) sent 227 bytes -- responder (9.2.1.100:2002) sent 9039

bytes



bytes



bytes



bytes

R1#



bytes

R1#




Note that this is showing the session as TCP but not HTTP.

R1#sho ip inspect config












Inspection name FW







R1#

Two things to point out here. 1- Pop3 is being inspected and requiring secure login. 2- http is inspected using java-list 16. We need to see that ACS is in the java-list.

R1# show access-l 16

Standard IP access list 16

10 permit 9.4.45.4

20 permit 9.2.1.100

R1#

So we can see that R1 knows it should look at ACS against the java-list but in the log output we don‟t see ACS being known as http traffic, rather it shows up as TCP. But http is port 80 and ACS is port 2002 so really the router is doing things right. So how do we get the router to think that port 2002 is HTTP and inspect it against the right rule? That‟s right- a port map. Let‟s see:

R1#sh run | in port-map

R1#conf t

R1(config)#ip port-map http port ?

<1-65535> Port number

tcp Specify a TCP Port

udp Specify a UDP Port

R1(config)#ip port-map http port tcp 2002 list 7

R1(config)#end

R1#




And we test again.

Note: It‟s best to close out the browser and start from scratch.

And after this connection R1 reports that it inspected HTTP:

R1(config)#

Jan 18 06:52:42.645: %FW-6-SESS_AUDIT_TRAIL: Stop http session: initiator


bytes



bytes



bytes

R1(config)#



bytes




Also lets check the ACL on the outside that should be logging denies:

R1(config)#do sh access-l FW


10 deny ip 0.0.0.0 0.255.255.255 any

20 deny ip 10.0.0.0 0.255.255.255 any

30 deny ip 127.0.0.0 0.255.255.255 any

40 deny ip 169.254.0.0 0.0.255.255 any

50 deny ip 172.16.0.0 0.15.255.255 any

60 deny ip 192.0.2.0 0.0.0.255 any

70 deny ip 192.18.0.0 0.1.255.255 any

80 deny ip 192.88.99.0 0.0.0.255 any

90 deny ip 192.168.0.0 0.0.255.255 any

100 deny ip 224.0.0.0 15.255.255.255 any

110 deny ip 240.0.0.0 15.255.255.255 any






170 permit 132 host 9.9.156.6 host 9.9.156.11 (5978 matches)


15555 (22036 matches)

190 permit udp host 9.9.156.6 eq 15555 host 9.9.156.11 eq 15555 (219

matches)





R1(config)#do sh run int fa0/1.1256 | begin Fast



ip address 9.9.156.11 255.255.255.0


ip verify unicast source reachable-via rx

ip nat outside



standby version 2

standby 156 ip 9.9.156.1







end

R1(config)#

At this point I would recommend you verify the configuration is identical on R6. If not and there is failover then this task would not function and you would probably lose the points.





2.9 Controlling Half Open Connections

Configure R6 to protect the internal network against SYN-floods. It should start deleting half open sessions if they are at 800. It should stop deleting half open connections when they reach 600. This should occur for both UDP and TCP Connections.

It should further protect the internal network by starting to delete half-open connections if there have been 600 new connections created within the last one minute and stop deleting at 400.

Configure the Router to delete TCP connections if the connection has been idle for 10 minutes.


All we should need to do here is verify the configuration:

R1(config)#do sh ip inspect config Session audit trail is enabled











Inspection name FW







R1(config)#

R6# sh ip inspect config












Inspection name FW







R6#





2.10 Firewall Tuning

On R1, if traffic sourced from RFC 3330 address space attempts to come in block it but do not log this traffic.

Turn on audit trail messages which will be displayed on the console after each CBAC session stops except for UDP traffic.

Globally specify the TCP session will still be managed after the firewall detects a FIN-exchange to be 10 seconds for all TCP sessions.


Set the global UDP idle timeout to 100 seconds

Prevent IP Spoofing using Reverse Path Forwarding. Make sure it only accepts routes learned on that interface but R1 should still be able to ping its own interface.


Just a few show commands here to verify:

R1#sh ip inspect config

Dropped packet logging is enabled












Inspection name FW







R1#

R6# sh ip inspect config















Inspection name FW







Now let‟s find the ACL and make sure it covers the RFC 3330 addresses and also verify that we are doing an RPF check and can still ping ourselves.

R1#sh run interface FastEthernet0/1.1256 | begin Fast



ip address 9.9.156.11 255.255.255.0


ip verify unicast source reachable-via rx

ip nat outside



standby version 2

standby 156 ip 9.9.156.1







end

R1#show access-l FW


10 deny ip 0.0.0.0 0.255.255.255 any

20 deny ip 10.0.0.0 0.255.255.255 any

30 deny ip 127.0.0.0 0.255.255.255 any

40 deny ip 169.254.0.0 0.0.255.255 any

50 deny ip 172.16.0.0 0.15.255.255 any

60 deny ip 192.0.2.0 0.0.0.255 any

70 deny ip 192.18.0.0 0.1.255.255 any

80 deny ip 192.88.99.0 0.0.0.255 any

90 deny ip 192.168.0.0 0.0.255.255 any

100 deny ip 224.0.0.0 15.255.255.255 any

110 deny ip 240.0.0.0 15.255.255.255 any




150 permit tcp host 9.9.156.9 eq bgp host 9.9.156.11 gt 1024 (1 match)


170 permit 132 host 9.9.156.6 host 9.9.156.11 (78751 matches)


15555 (3393770 matches)



15555 (3602 matches)






The ACL looks ok. It covers everything except the addresses in the RFC that are subject to allocation. This is a judgment call. We chose not to include them but you can. For reference see RFC1330.

Next let‟s make sure we can ping ourselves:

R1#ping 9.9.156.11



.....


Nope. It‟s because we are missing the option to allow self-ping.

R1#conf t


R1(config)#interface FastEthernet0/1.1256

R1(config-subif)#ip verify unicast source reachable-via rx allow-self-ping

R1(config-subif)#

R1(config-subif)#end

Test again:

R1#ping 9.9.156.11


R1#ping 9.9.156.11



!!!!!


Don‟t forget about R6:

R6(config)#int f0/1.1256

R6(config-subif)#ip verify unicast source reachable-via rx allow-self-ping


R6#


R6#ping 9.9.156.6



!!!!!


R6#

Watch for subtle configuration options that may be missed. Much of the CCIE exam is paying attention to detail.


http://www.rfc-editor.org/rfc/rfc3330.txt




2.11 Transparent Zone Based Firewall

Configure R8 as a zone based transparent firewall. Allow users on R7 to go out to the external networks using the following protocols:

Bootps DNS HTTP HTTPS SMTP SSH

The return entries should be automatically created on the return. No other protocol traffic should be inspected for this task.

The return entries should expire after 4 minutes for TCP based protocols. DNS entries should expire after 2 minute.

Only permit necessary traffic for routing or other tasks.

Use two zones; INSIDE for Fa0/1.78 and OUTSIDE for Fa0/1.1256 on R8

Make sure Routing is still working after you are done with this section. Be sure to log any traffic that violates these rules.


Here we have a transparent firewall. Let‟s test the firewall by pinging R5 from R7:




!!!!!


R7(config)#

Ping looks ok. Let‟s do an SSH session to R9:


Password:

Password:

R9#

Note: You may need to generate RSA key pairs on R9.

Now look at R8 for the sessions:



Zone-pair: IN->OUT



Match: protocol ssh




0 packets, 0 bytes



0 packets, 0 bytes


Match: protocol dns

0 packets, 0 bytes



0 packets, 0 bytes






0 packets, 0 bytes


Inspect



0 packets, 0 bytes


Inspect



Pass

0 packets, 0 bytes


Match: any

Pass



Zone-pair: OUT->IN




Pass



Match: any

Drop


It‟s peculiar that we did a ping and an SSH and no packets matched the firewall policy. Notice that it says:





Zone-pair: IN->OUT

What is zp IN->OUT?

R8#show run | section zone-pair

zone-pair security IN->OUT source INSIDE destination OUTSIDE

service-policy type inspect FW-IN->OUT

zone-pair security OUT->IN source OUTSIDE destination INSIDE

service-policy type inspect FW-OUT->IN

alias exec pzp show policy-map type inspect zone-pair

R8#

Where are these zones applied?

R8#sh run int f0/1.78



!



zone-member security INSIDE

bridge-group 1

end




!




bridge-group 1

end

R8#

So we actually have the policy applied correctly. With what I am seeing here I would have to ask if we are actually passing traffic through R8? Let‟s shutdown the interface of R8 to quickly verify:

R8#sh ip int brie


FastEthernet0/0 unassigned YES manual administratively down down

FastEthernet0/1 unassigned YES manual up up

FastEthernet0/1.78 unassigned YES unset up up


Serial0/0/0 unassigned YES manual administratively down down

BVI1 9.9.156.8 YES manual up up

R8#conf t


R8(config)#int f0/1

R8(config-if)#shut

R8(config-if)#end




R8#sh ip int brie




FastEthernet0/1.78 unassigned YES unset administratively down down

FastEthernet0/1.1256 unassigned YES unset administratively down down


BVI1 9.9.156.8 YES manual down down

R8#


Password:

R9#

R9#

R9#exit





!!!!!


R7(config)#

Oh no- looks like we are bypassing R8. Interface fa0/1.78 is the interface that should be on vlan 78. Let‟s verify the configuration on R7:

R7(config)#do sh run int f0/1.78



!



ip address 9.9.156.7 255.255.255.0



ip nat enable

end

R7(config)#

The VLAN assigned here is the same VLAN as R5 and R9. This would cause us to bypass R8. Lets correct the vlan by verifying what VLAN R8‟s inside interface is on.




!



bridge-group 1

end




Lets put R7 in the correct vlan.


R7(config-subif)#encaps dot 78

R7(config-subif)#

Make sure we bring the interface on R8 back up:

R8(config)#int f0/1

R8(config-if)#no shut

R8(config-if)#do sh ip int brie



FastEthernet0/1 unassigned YES manual up up




BVI1 9.9.156.8 YES manual up up

R8(config-if)#

Test our Ping and SSH and make sure the counters are incrementing on the R8 firewall:


R7#con


R7#conf t





!!!!!



Password:

R9#

Verify on R8:



Zone-pair: IN->OUT



Match: protocol ssh

1 packets, 24 bytes



0 packets, 0 bytes


Match: protocol dns

0 packets, 0 bytes



0 packets, 0 bytes









0 packets, 0 bytes


Inspect



Session 4874C020 (9.9.156.7:59096)=>(9.9.156.9:22) ssh:tcp SIS_OPEN





1 packets, 80 bytes


Inspect



Pass

0 packets, 0 bytes


Match: any

Pass



Zone-pair: OUT->IN




Pass


Class-map: OUT->IN-PROTO (match-all)

Match: protocol tcp

Match: access-group name VLAN10

Inspect


Match: any

Drop


R8#





2.12 DHCP and a Transparent ZFW

R9 has been configured as a DHCP server for 10.0.7.0/24. Configure R8 and R7 to allow DHCP requests to R9.

Connect the XP Workstation to VLAN 7 and make sure it is assigned IP 10.0.7.100/24.

Connect Cat1 Fa0/19 to VLAN 7 and configure it to receive IP 10.0.7.10.

R7 has been configured to advertise 10.0.7.0/24 via BGP to R9. Make sure R9 doesn‟t advertise this network beyond its own local AS. This configuration should be applied on R7.


R9 is the DHCP server and we have R7 and R8 in the path between it and the XP workstation that‟s on vlan 7. We used the XP workstation earlier to test the java-list so we need to move it back to vlan 7 and then configure it for DHCP to see if its getting an address.

Cat3(config-if)#int fa0/15


No address is being handed out. Remember that R7 and R8 are in the path. You need to make sure we have an ip helper command on R7:




R7#show run | section interface

interface Loopback0

ip address 7.7.7.7 255.0.0.0


no ip address

shutdown

duplex auto

speed auto


ip address 10.0.7.7 255.255.255.0

ip nat enable

duplex auto

speed auto



ip address 9.9.156.7 255.255.255.0


ip helper-address 9.9.156.9


ip nat enable

interface Serial0/0/0

no ip address

shutdown

clock rate 2000000

ip tacacs source-interface Loopback0

logging source-interface Loopback0

alias exec sri show run interface

alias exec siib show ip interface brief

R7#

The problem here is that at quick glance you may think that the ip-helper is configured. It‟s not. It‟s on the wrong interface. The helper needs to be on the side that the DHCP client is on.

R7(config)#int f0/1

R7(config-if)#ip helper-address 9.9.156.9

R7(config-if)#interface FastEthernet0/1.78

R7(config-subif)#no ip helper-address 9.9.156.9

R7(config-subif)#

And debug the DHCP server to see if it gets the request:

R9#debug ip dhcp server events

DHCP server event debugging is on.

R9#

R9#

R9#conf t


R9(config)#logging con 7

Debug also on R8 since it‟s a layer 2 device in the path:

R8#debug policy-firewall l2-transparent

Policy-Firewall L2 transparent debugging is on

R8#

R9 shows no request being seen on the server:




R9(config)#

Jan 15 08:39:01.437: DHCPD: checking for expired leases.

R9(config)#

Jan 15 08:41:01.437: DHCPD: checking for expired leases.

R9(config)#

The only device in between is R8. Since it‟s a transparent firewall it needs an extra bit of configuration on it. It will not forward DHCP without the command: ip inspect L2-transparent dhcp-passthrough. Let‟s look for it:

R8#

R8#sh run | in ip inspect L2-transparent dhcp-passthrough

R8#

Nothing there so we‟ll add it:

R8(config)#ip inspect L2-transparent dhcp-passthrough

R8(config)#

Renew again and we have an IP address.





2.13 Transparent ZFW Tuning

Specify that TCP sessions will still be managed after the firewall detects a FIN-exchange for 12 seconds and the SYN-exchange to be 20 seconds for all TCP sessions.


Set the UDP idle timeout to 90 seconds. Do not perform these changes globally.


Here we just need to verify tuning parameters:

R8#sh run | sec parameter-map type inspect PAR-MAP


udp idle-time 90

dns-timeout 180

tcp idle-time 240

tcp finwait-time 12

tcp synwait-time 20


R8#


2.14 Auth-Proxy

Create an Access-list inbound on R7 Fa0/1.78 denying 9.2.1.0/24 to 9.7.7.0/24. Permit all other traffic.

Allow users from 9.2.1.0/24 to access the 9.7.7.0/24 network after successful authentication against R7. They should only be allowed to come in for TCP based protocols. Only authenticate if there is a web session to 9.7.7.7. Make sure the password is sent encrypted.

If the session is inactive for more than 15 minutes or has been active for more than 90 minutes the session should be disconnected.

ACS has been pre-configured for you with R7 and Cat1 setup with TACACS+ and key ipexpert.

Username auth-proxy and password ipexpert is allowed for authentication. This username and password is only allowed to authenticate to R7 and Cat1.

The user should also be allowed full shell access to R7 and Cat1 via SSH without an enable password.

Configuration unfinished on ACS – Once successfully authenticated ACS should download an ACL to R7 permitting this TCP traffic from the authenticated host to 9.7.7.0/24.

Users should be able to connect to Cat1 from 9.2.1.0/24 via HTTP Port 80, 8080, HTTPS, and SSH.





First verify the interface ACL as well as Auth-Proxy Rule on the interface:

R7(config-if)#do sh run int f0/1.78



!



ip address 9.9.156.7 255.255.255.0



ip nat enable

end

R7(config-if)#

Check the ACL to make sure it matches the required statements:

R7(config-if)#do sh access-l INBOUND

Extended IP access list INBOUND

10 permit tcp 9.2.1.0 0.0.0.255 host 9.7.7.7 eq www

20 permit tcp 9.2.1.0 0.0.0.255 host 9.7.7.7 eq 443

30 deny tcp 9.2.1.0 0.0.0.255 9.7.7.0 0.0.0.255 log

40 permit ip any any (34100 matches)

R7(config-if)#

Now look at the Auth-Proxy configuration:

R7(config-if)#do sh run | in auth

aaa authentication login default group tacacs+

aaa authentication login HTTP group tacacs+

aaa authentication login VTY group tacacs+


aaa authorization auth-proxy default group tacacs+

ip auth-proxy name APROXY http inactivity-time 15 absolute-timer 90 list VLAN10

ntp authentication-key 1 md5 04521B031731495C1D 7

ntp authenticate

multilink bundle-name authenticated


ip http authentication aaa


R7(config-if)#

And the VLAN10 ACL:

R7(config-if)#do sh access-l VLAN10

Extended IP access list VLAN10

10 permit tcp 9.2.1.0 0.0.0.255 host 9.7.7.7 eq 443

20 permit tcp 9.2.1.0 0.0.0.255 host 9.7.7.7 eq www

R7(config-if)#




Test from ACS:




Lets look at the failed attempts log in ACS:

We are being told that the service is denied. Let‟s see why.




The Auth-Proxy Server is missing. Lets add it.

Now let‟s look at the user:




We can see the auth-proxy configuration is missing. Let‟s add it and test again:

Test again:




Also- we must test to port 8080. This is not so much a test of auth-proxy, however we are using a switch to test. The Switch is using port 80 for http. If we want to test port 8080 we need to modify our nat configuration to make this possible.

R7(config-if)#do sh run | in ip source static

R7(config-if)#ip nat source static tcp 10.0.7.10 80 9.7.7.10 8080 extendable

Now we test to port 8080 and it functions as planned.


2.15 ZFW URL Filtering

Configure R2 to filter URL‟s from EXEC and User to OUTSIDE.

You will use a trend micro server filter.trendmicro.com (68.9.10.1) HTTPS port 6895. R2 should keep responses from the server in cache for 10 hours. Make sure the Cache doesn‟t use more than 1 MB of memory.

If the filter server is down you should allow the EXEC zone to continue to access the internet but the User zone should not be allowed and should be redirected to http://10.1.1.100:2002.

during normal business hours, 8 AM to 5 PM, you don‟t want to allow users to go to sites that are Social Networking or Job-Search-Career related.

Always permit traffic to www.cisco.com, www.onlinestudylist.com, and www.ipexpert.com without requiring a response from the filter server.

Always deny traffic to *.example.com or that has URI information with blackmarket.

If a user attempts to connect to a website that contains Weapons, Violence-hate-racism, Pornography, Adult-Mature-Content, Nudity, Gambling, or is known to have PHISHING, ADWARE, or SPYWARE make sure to reset these connections.

http://10.1.1.100:2002/




http://www.nortel.com/





Move ACS to vlan 12 and change its ip settings to match the subnet on vlan 12.



Cat3(config-if)#

To start testing we need the XP workstation to access some URLs. Modify the host file:

Ping example.com

C:\Documents and Settings\Administrator>ping www.example.com

Pinging www.example.com [9.9.156.9] with 32 bytes of data:










Next ping Cisco.com

C:\Documents and Settings\Administrator>ping www.cisco.com

Pinging www.cisco.com [4.4.4.4] with 32 bytes of data:













Browse to these sites:

As we can see its just kinda hanging. Look at R2:

R2#

Jan 18 09:06:25.356: %FW-6-DROP_PKT: Dropping tcp session 192.1.49.101:1167

9.9.156.9:80 with ip ident 0

R2#192.1.49.4

Jan 18 09:06:35.500: %URLF-4-SITE_BLOCKED: (target:class)-(User-OUT:HTTP-


server 9.9.156.9:80

R2#

This is expected based on the zone we are in and since the trend server is really not there, however we should have been redirected to ACS. Let‟s see why that didn‟t happen.

R2#sh run | in redirect


R2#




Again at first glance this looks like its correct, but we are on VLAN 12 and ACS is not 9.2.1.100. ACS should be 192.1.49.150. Lets correct that.

R2#conf t


R2(config)#parameter-map type urlfpolicy trend User

R2(config-profile)#block-page redirect-url http://192.1.49.150:2002

R2(config-profile)#end

R2#dh


R2#sh run | sect parameter-map type urlfpolicy trend User

parameter-map type urlfpolicy trend User


R2#

Test again and we get ACS:

And on R2:

R2#

Jan 18 09:16:46.922: %URLF-4-SITE_BLOCKED: (target:class)-(User-OUT:HTTP-


server 9.9.156.9:80

R2#


9.9.156.9:80 with ip ident 0

R2#

Now how about cisco.com?




I‟ll authenticate to R5 first- this is the lock and key.

And then to Cisco.com

And it‟s good to go. Now to be complete you technically should move the XP Workstation to other VLANS and test. This should at least get you on the right track to accomplish those verifications on your own.





2.16 Zone Based Firewall

Configure R2 with four zones: DC, EXEC, OUTSIDE, and User.

Inspect TCP and UDP traffic from DC to OUTSIDE and User.

Inspect TCP and UDP traffic from User and EXEC to OUTSIDE.

There is a corporate application to backup user data over TCP Port 9001. Configure R2 to inspect this traffic from DC to EXEC. Do not use an ACL to accomplish this.


Start by checking for traffic moving through the firewall.

R2(config)#do sh policy-map ty ins zone-pair User-OUT sessions


Zone-pair: User-OUT





Inspect



Inspect



Session 68F70520 (192.1.49.101:1205)=>(4.4.4.4:80) http:tcp SIS_OPEN




Match: protocol tcp

2 packets, 56 bytes


Match: protocol udp



Inspect



Session 68F72B20 (192.1.49.12:123)=>(9.9.156.9:123) ntp:udp SIS_OPEN









Pass



Match: any

Drop

0 packets, 0 bytes

R2(config)#

R2(config)#do sh policy-map ty ins zone-pair EXEC-OUT sessions

policy exists on zp EXEC-OUT

Zone-pair: EXEC-OUT

Service-policy inspect : EXEC->OUTSIDE




Inspect



Inspect


Match: protocol tcp

0 packets, 0 bytes


Match: protocol udp



Inspect




Pass

0 packets, 0 bytes


Match: any

Drop

0 packets, 0 bytes

R2(config)#

Change Cat3‟s http port to 9001 to test the backup app.

Cat3(config-if)#ip http server

Cat3(config)#ip http port 9001

Cat3(config)#




Add a route on ACS:

C:\Documents and Settings\Administrator>route add 10.0.0.0 mask 255.255.0.0

10.1.1.1

Test from ACS but it fails.

Look at R2:

R2(config)#


10.0.13.13:9001 on zone-pair DC-EXEC class class-default due to DROP action


R2(config)#

Jan 18 09:33:28.351: %FW-6-LOG_SUMMARY: 2 packets were dropped from

10.1.1.100:1416 => 10.0.13.13:9001 (target:class)-(DC-EXEC:class-default)

R2(config)#

Jan 18 09:34:28.351: %FW-6-LOG_SUMMARY: 1 packet were dropped from


R2(config)#

This traffic is ending up in the class-default but it should match the policy that was created for the backup-app. Verify the policy:




R2(config)#do sh policy-map ty ins zone-pair DC-EXEC sessions

policy exists on zp DC-EXEC

Zone-pair: DC-EXEC

Service-policy inspect : DC->EXEC

Class-map: BACKUP-APP (match-all)

Match: protocol

Inspect




Pass

0 packets, 0 bytes


Match: any

Drop

3 packets, 84 bytes

R2(config)#

There is something missing from the class-map.

R2(config)#do sh run | section class-map type inspect match-all BACKUP-APP


match protocol

R2(config)#

We should be matching the backup-app protocol. That protocol is tcp port 9001 which would require a port-map. Check for a port map:

R2(config)#do sh run | in port-map

ip nbar port-map custom-01 tcp 9001

R2(config)#

There is the port-map but the zone-based firewall doesn‟t use NBARs port-mappings. We need to correct the port-map and apply it to the class-map.

R2(config)#ip port-map user-BACKUPS port tcp 9001

Here is where you have to be very careful. The class-map is a match-all. Watch what happens when I modify it:

R2(config)#class-map type inspect match-all BACKUP-APP

R2(config-cmap)#mathc

R2(config-cmap)#no match protocol

% Incomplete command.

R2(config-cmap)#no match protocol

% Incomplete command.

R2(config-cmap)#match protocol user-BACKUPS

R2(config-cmap)#end

R2#





R2#conf t


R2(config)#do sh run | section class-map type inspect match-all BACKUP-APP


match protocol


R2(config)#

This will still fail because we are not matching both. So this is the fun part. This is where we backtrack.

R2(config-pmap-c)#do sh run | sect class-map type ins.* match-all BACKUP-APP


match protocol


R2(config-pmap-c)#no class-map type inspect match-all BACKUP-APP

% Class-map BACKUP-APP is being used

R2(config)#policy-map type inspect DC->EXEC

R2(config-pmap)#

Jan 18 09:51:28.349: %FW-6-LOG_SUMMARY: 3 packets were dropped from


R2(config-pmap)#no class type inspect BACKUP-APP

R2(config-pmap)#no class type inspect ICMP

R2(config-pmap)#no class class-default

R2(config-pmap)#no class-map type inspect match-all BACKUP-APP

R2(config)#class-map type inspect match-all BACKUP-APP

R2(config-cmap)#match protocol user-BACKUPS

R2(config-cmap)#policy-map type inspect DC->EXEC

R2(config-pmap)# class type inspect BACKUP-APP

R2(config-pmap-c)# inspect

R2(config-pmap-c)# class type inspect ICMP

R2(config-pmap-c)# pass

R2(config-pmap-c)# class class-default

R2(config-pmap-c)# drop

R2(config-pmap-c)#




Test again:





2.17 User to DC zone

For HTTP traffic, this should include the ACS application, from zone User to zone DC do not allow java-applets to be downloaded.

Do not allow Users to send for requests for HTTP data with a URI greater than 300 bytes. Make sure to log any violations.

Inspect TCP and UDP traffic from User zone to DC.


Browse from for XP workstation to ACS. The Java should be blocked.

Ok so that didn‟t work. Why not?

R2(config)#do sh policy-map ty ins zone-pair User-DC sessions

policy exists on zp User-DC

Zone-pair: User-DC

Service-policy inspect : User->DC



Inspect







Pass


Class-map: MAIL (match-any)

Match: protocol pop3

0 packets, 0 bytes


Pass

0 packets, 0 bytes


Match: protocol tcp



Match: protocol udp

0 packets, 0 bytes


Inspect


Match: any

Drop

0 packets, 0 bytes

R2(config)#

The class-map for http is not matched. Lets check it out.

R2(config)# do sh run | sect class-map type inspect


match protocol pop3


match protocol icmp



match protocol tcp

match protocol udp

class-map type inspect match-all HTTP-CM

match protocol http





match protocol http



















R2(config)#

The class-map we are working with here is matching http. Http is port 80 and we need to also map port 2002.

R2(config)#ip port-map http port tcp 2002

R2(config)#

Test to ACS again:

And look at R2:

R2(config)#

Jan 18 10:06:40.950: %APPFW-4-HTTP_JAVA_APPLET: HTTP Java Applet detected -




192.1.49.101:1284 with ip ident 0

R2(config)#




Jan 18 10:06:40.958: %APPFW-4-HTTP_JAVA_APPLET: HTTP Java Applet detected -



R2(config)#

Finally test the URL size:

R2(config)#

Jan 18 10:09:34.086: %APPFW-4-HTTP_URI_LENGTH: HTTP URI length (397) out of

range - resetting session 192.1.49.101:1288 10.1.1.100:80 on zone-pair User-

DC class HTTP-CM appl-class JAVA-URI


2.18 Mail Filtering

From User to DC make sure that POP3 users have configured mail clients to use secure-passwords.

Also if an invalid command is sent to the server reset the connection.


Here we are just going to verify. It‟s unlikely you‟ll have a mail server to configure in the lab so we‟ll treat this task as such. Look at the policy again:




R2(config)#do sh policy-map ty ins zone-pair User-DC sessions


Zone-pair: User-DC




Inspect




Pass




0 packets, 0 bytes


Pass

0 packets, 0 bytes


Match: protocol tcp



Match: protocol udp

0 packets, 0 bytes


Inspect


Match: any

Drop

0 packets, 0 bytes

Now check out the class-map MAIL:

R2(config)# do sh run | sect class-map type inspect


match protocol pop3


match protocol icmp



match protocol tcp

match protocol udp

class-map type inspect match-all HTTP-CM

match protocol http








match protocol http
















Ok so MAIL simply matches pop3. We need more information:

R2(config)#do sh run | sect policy-map type inspect User->DC



inspect



pass


pass


inspect

class class-default

drop

R2(config)#

Pass is not what we are required to do with mail. Mail is supposed to be using secure-login and preventing invalid commands. We‟ll need to correct this. We also need to nest a policy within Mail that

R2(config-pmap-c)#do sh run | sect policy-map type inspect User->DC



inspect



pass


pass


inspect

class class-default

drop

R2(config-pmap-c)#no class type inspect HTTP-CM

R2(config-pmap)#no class type inspect ICMP

R2(config-pmap)#no class type inspect MAIL

R2(config-pmap)#no class type inspect TCP-UDP

R2(config-pmap)#no class class-default

R2(config-pmap)#class type inspect HTTP-CM





R2(config-pmap-c)# service-policy http JAVA-URI

R2(config-pmap-c)#class type inspect MAIL

R2(config-pmap-c)#inspect

R2(config-pmap-c)#service-policy pop3 POP3

R2(config-pmap-c)#class type inspect ICMP

R2(config-pmap-c)# pass

R2(config-pmap-c)#class type inspect TCP-UDP


R2(config-pmap-c)# class class-default

R2(config-pmap-c)# drop

R2(config-pmap-c)#

Now look at the policy one more time.

R2(config-pmap-c)#do sh policy-map ty ins zone-pair User-DC sessions


Zone-pair: User-DC




Inspect



0 packets, 0 bytes


Inspect




Pass

0 packets, 0 bytes


Match: protocol tcp

0 packets, 0 bytes


Match: protocol udp

0 packets, 0 bytes


Inspect


Match: any

Drop

0 packets, 0 bytes

R2(config-pmap-c)#


Notice now we are inspecting whereas before the traffic was just being passed.




Lab 3A: Configure IPS to Mitigate

Network Threats

Estimated Time to Complete: 3-4 Hours





3.0 Cisco IPS Configuration Detailed Solutions


3.1 Sensor Setup and Administration

Before you begin erase the current configuration on the sensor using „erase current-config.‟

From the console, configure the hostname as „IPS‟ and the command-and-control interface of the sensor with an IP address of 10.1.1.15/24 and a default gateway of 10.1.1.1

Configure the sensor to listen for HTTPS requests on port 10443 instead of the default of 443.

Allow HTTPS access to the sensor only from the ACS server at 10.1.1.100.

From this point on, you may use either the command-line or IDS Device Manager (IDM) to configure the sensor. Note that IDM is specifically mentioned in the Blueprint, so you should be familiar with its use.

Configuration

IPS

When using the remote rack sessions before you start configuring the sensor, doing a quick erase current-config will ensure any previoulsy configured virtual sensors, etc., have all been removed.

sensor# erase current-config

Warning: Removing the current-config file will result in all configuration

being reset to default, including system information such as IP address.

User accounts will not be erased. They must be removed manually using the "no

username" command.

Continue? []: yes

sensor#

sensor# show conf

! ------------------------------

! Current configuration last modified Mon Sep 14 11:10:09 2009

! ------------------------------

! Version 6.1(1)

! Host:

! Realm Keys key1.0

! Signature Definition:

! Signature Update S365.0 2008-10-31

! Virus Update V1.4 2007-03-02

! ------------------------------

service interface

exit

! ------------------------------

service authentication

exit

! ------------------------------

service event-action-rules rules0

exit

! ------------------------------

service host

exit




! ------------------------------

service logger

exit

! ------------------------------

service network-access

exit

! ------------------------------

service notification

exit

! ------------------------------

service signature-definition sig0

exit

! ------------------------------

service ssh-known-hosts

exit

! ------------------------------

service trusted-certificates

exit

! ------------------------------

service web-server

exit

! ------------------------------

service anomaly-detection ad0

exit

! ------------------------------

service external-product-interface

exit

! ------------------------------

service health-monitor

exit

! ------------------------------

service analysis-engine

exit

sensor#

Type the setup command to begin the initial setup wizard.

sensor# setup

--- Basic Setup ---

--- System Configuration Dialog ---

At any point you may enter a question mark '?' for help.

User ctrl-c to abort configuration dialog at any prompt.

Default settings are in square brackets '[]'.

Current time: Mon Sep 14 11:39:28 2009

Setup Configuration last modified: Mon Sep 14 11:10:09 2009

Enter host name[sensor]: IPS

Enter IP interface[192.168.1.2/24,192.168.1.1]: 10.1.1.15/24,10.1.1.1

Modify current access list?[no]: yes

Current access list entries:

No entries

Permit: 10.1.1.100/32

Permit:

Modify system clock settings?[no]:




The following configuration was entered.

service host

network-settings

host-ip 10.1.1.15/24,10.1.1.1

host-name IPS

telnet-option disabled

access-list 10.1.1.100/32

ftp-timeout 300

no login-banner-text

exit

time-zone-settings

offset 0

standard-time-zone-name UTC

exit

summertime-option disabled

ntp-option disabled

exit

[0] Go to the command prompt without saving this config.

[1] Return to setup without saving this config.

[2] Save this configuration and exit setup.

[3] Continue to Advanced setup.

Enter your selection[3]:

Enter telnet-server status[disabled]:

Enter web-server port[443]: 10443

Modify interface/virtual sensor configuration?[no]:

Modify default threat prevention settings?[no]:

The following configuration was entered.

service host

network-settings

host-ip 10.1.1.15/24,10.1.1.1

host-name IPS

telnet-option disabled


ftp-timeout 300

no login-banner-text

exit

time-zone-settings

offset 0

standard-time-zone-name UTC

exit

summertime-option disabled

ntp-option disabled

exit

service web-server

port 10443

exit


overrides

override-item-status Enabled

risk-rating-range 90-100

exit




exit

[0] Go to the command prompt without saving this config.

[1] Return to the Advance setup without saving this config.

[2] Save this configuration and exit setup.

Enter your selection[2]:

Configuration Saved.

sensor#

Cat4





The bulk of these tasks will be completed through the initial setup wizard.

Log into the sensor on the console port. If the initial setup wizard is already in progress, type Control-C to exit to the sensor# command prompt.

The first section of the wizard allows the configuration of the hostname, ip address and management access list. Continuing to the advanced setup using option 3 will allow you to pre configure the web servers listening port to 10443 as requested in the task.

Finally, don‟t forget to configure the switchport for the command and control interface. Cat 4 F0/14 needs to be an access port in vlan 10.

Verification

First confirm your IPS configuration is as required:

sensor# show configuration

! ------------------------------

! Current configuration last modified Mon Sep 14 11:40:56 2009

! ------------------------------

! Version 6.1(1)

! Host:

! Realm Keys key1.0




! ------------------------------

service interface

exit

! ------------------------------

service authentication

exit

! ------------------------------


exit

! ------------------------------

service host

network-settings

host-ip 10.1.1.15/24,10.1.1.1

host-name IPS





exit

exit

! ------------------------------

service logger

exit

! ------------------------------

service network-access

exit

! ------------------------------

service notification

exit

! ------------------------------

service signature-definition sig0

exit

! ------------------------------

service ssh-known-hosts

exit

! ------------------------------

service trusted-certificates

exit

! ------------------------------

service web-server

port 10443

exit

! ------------------------------

service anomaly-detection ad0

exit

! ------------------------------

service external-product-interface

exit

! ------------------------------

service health-monitor

exit

! ------------------------------

service analysis-engine

exit

sensor#

If you‟re happy that this is correct, then open a web browser session to the IPS sensor from the ACS server, using the newly defined port 10443.




Accept the security warnings and click on the „Run IDM‟ button to start the Device Manager.




Login when requested using the credentials „cisco‟ password „proctorlabs‟.

End Verification




3.2 Password Protection

Your corporate security policy states that all passwords must be at least 10 characters in length, and must contain at least one uppercase letter, one non-alphanumeric character (such as # or $), and at least two numbers. The previous 2 passwords should also be remembered. Configure the sensor to enforce this policy.

Your corporate security policy requires that accounts be locked after 5 invalid login attempts. Configure the sensor to implement this requirement.

The operations team needs read-only access to the sensor to view events. Create a new user for their use called “nocadmin” with password “NOCread123#.”

Configuration

IPS

Password policy is configured in IDM at Sensor Management > Passwords.

Invalid login attempts are also configured on the same screen in IDM as the password requirement policy.




Sensor users can be configured on the Sensor Setup > Users screen in IDM.


This task included some simple user based security features, around role based access and password complexity requirements.

One thing to remember for role based access is that if the requirement is for the user not to make any changes then the it must use the viewer role, as the operator role does have access to tune signatures and make minor changes to configurations.

Verification

The password policy can be tested by creating a test user with a non compliant password. If the password strength does not comply then the following message is displayed:

Login into the sensors cli to test the new nocadmin account. Issue a show privilege command to ensure the viewer role has been assigned.




sensor# exit

IPS login: nocadmin

Password:

***NOTICE***

This product contains cryptographic features and is subject to United States

and local country laws governing import, export, transfer and use. Delivery

of Cisco cryptographic products does not imply third-party authority to import,

export, distribute or use encryption. Importers, exporters, distributors and

users are responsible for compliance with U.S. and local country laws. By using

this product you agree to comply with applicable laws and regulations. If you

are unable to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to

[email protected].

***LICENSE NOTICE***

There is no license key installed on the IPS-4240.

The system will continue to operate with the currently installed

signature set. A valid license must be obtained in order to apply

signature updates. Please go to http://www.cisco.com/go/license

to obtain a new license or install a license.

IPS#

IPS# show privilege

Current privilege level is viewer

IPS#

End Verification

3.3 Network Time Protocol

Configure R1 to act as an NTP master.

Set the time zone to EST (GMT -5) and account for daylight saving.

Configure NTP authentication with MD5 key #1 and value “ipexpert.”

Configure the sensor to sync its clock to R1 using NTP.

Configuration

R1



ntp master 1

ntp authenticate


ntp trusted-key 1




IPS

NTP is configured under Sensor Setup > Time.


Another fairly straight forward task to carry out. Configure NTP master on R1.

When configuring the IPS for NTP, the key ID and key string must match what was configured on R1, the same as IOS clients. Enable/configure summer time settings and set the timezone.

The sensor will need to be rebooted for NTP to be enabled successfully.




Verification

Verify that the R1 is running as a master server.

R1#sh ntp ass det

127.127.1.1 configured, our_master, sane, valid, stratum 0

ref ID .LOCL., time CE59340F.8F7E9ECF (17:28:47.560 EDT Mon Sep 14 2009)

our mode active, peer mode passive, our poll intvl 16, peer poll intvl 16




org time CE59340F.8F7E9ECF (17:28:47.560 EDT Mon Sep 14 2009)

rec time CE59340F.8F7F739C (17:28:47.560 EDT Mon Sep 14 2009)

xmt time CE59340F.8F7E25EF (17:28:47.560 EDT Mon Sep 14 2009)

filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filterror = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00


Once the sensor has reloaded, login to the cli and issue the „show clock detail‟ command.

IPS# sh clock detail

.17:46:15 GMT-05:00 Mon Sep 14 2009

Time source is NTP

Summer time starts 03:00:00 GMT-05:00 Sun Mar 08 2009

Summer time stops 01:00:00 GMT-05:00 Sun Nov 01 2009

IPS#

End Verification

3.4 Miscellaneous Configuration

Although telnet is an inherently insecure protocol, the NOC requires it to be enabled for management purposes. The NOC will connect to the sensor from R1. Configure the sensor to allow this.

Configure the sensor to allow SNMP management using the read-only community string “IPSro” and the read-write community string “IPSwr.” Set the system location to “IPexpert HQ” and the system contact to [email protected]. Traps should also be enabled to the ACS server using read only community.

When users log into the sensor, they should see a login banner indicating that access is restricted to authorized personnel only.

Configuration





IPS

Telnet access is configured under Sensor Setup > Network.

SNMP configuration is carried out under Sensor Management > SNMP > General Configuration.




SNMP traps are enabled from System Management > SNMP > Trap Configuration.

Use the Add button to include the ACS Server as a Trap destination. The login banner can only be configured from the command-line in the current version of the sensor software. IPS# conf t

IPS(config)# service host

IPS(config-hos)# network-settings

IPS(config-hos-net)# login-banner-text *** Access is restricted to

authorized personnel only! ***

IPS(config-hos-net)#

IPS(config-hos-net)# show set

network-settings

-----------------------------------------------

host-ip: 10.1.1.15/24,10.1.1.1 default: 192.168.1.2/24,192.168.1.1

host-name: IPS default: sensor

telnet-option: enabled default: disabled

access-list (min: 0, max: 512, current: 1)

-----------------------------------------------

network-address: 10.1.1.100/32

-----------------------------------------------

-----------------------------------------------

ftp-timeout: 300 seconds <defaulted>

login-banner-text: *** Access is restricted to authorized personnel

only! *** default:

-----------------------------------------------

IPS(config-hos-net)#

IPS(config-hos-net)# exit

IPS(config-hos)# exit

Apply Changes?[yes]: yes

IPS(config)# exit

IPS#





If you read the entire lab before starting, enabling telnet could have been completed in the initial setup wizard saving yourself a little time.

Verification

SNMP traps can be confirmed after the next task. The ACS server has a trap receiver installed. Open the trap receiver from the desktop shortcut, and configure the trap community, via Configure > Trap Data > Specify Variables.

Once you create the virtual sensors in the next section, traps will be fired and sent to the ACS as above.

Confirm the banner is displayed from the CLI, by exiting your current session, and re-logon.




IPS# exit

*** Access is restricted to authorized personnel only! ***

IPS login: cisco

Password:

Last login: Tue Sep 15 16:10:50 on ttyS0

End Verification

3.5 Creating Virtual Sensors

Create a new virtual sensor, vs1.

Set the description to “Inline Pair IPS monitoring for R6 and R7.”

Create new policy objects for vs1, sig1, rules1, and ad1. These should be exact copies of the policy objects in vs0.


Set the description to “VLAN Pair IPS monitoring for R8 and R9.”


Configuration

First create your policy objects for both vs1 and vs2, starting cloning the signature defintions.




Carry out the same clone task for sig2.

Then move Event action rules and create noth rules1 and rules2.




The final policy objects required are anomaly detection. Select Policies > Anomoly detections and clone ad0 to create both ad1 and ad2.

From Policies > IPS Policies click the Add Virtual Sensor Sensor button and define the vs1 virtual sensor, set the description and assign the newly created policy objects sig1, rules1 & ad1 to vs1.




Duplicate the above task to create vs2, remembering to assign sig2,rules2 and ad2, and setting the description for the new virtual sensor.

If you havent jumped ahead and configured the interfaces for each virtual sensor you will see a warning message. This will be rectified in the upcoming tasks.


In this section we are asked to create virtual sensors on the appliance. This gives us the advantage of being able to apply different policies for different traffic flows types throughout the network. Version 6.x code gives us the ability to create upto 4 virtual sensors on the appliance.

Each IPS Policy is made up of 3 policy objects: Signature definitions, Event Actions Rules and Anomaly Detection. We need to create and assign a new set of these objects for each virtual sensor.

As we are asked to create exact copies of the vs0 objects for both vs1 and vs2 we need to Clone the existing sig, rules and ad, renaming accordingly.




Verification

This section has concentrated on the creation of the virtual sensors so not much to verify for this until the next sections.

End Verification

3.6 Monitoring Traffic with IDS

Configure Cat3 and Cat4 to copy all traffic between VLAN 4 and VLAN 5 to the Gi0/0 interface on the IPS sensor. You may create VLAN 450 to complete this task.

The sensor should be able to send TCP resets to VLAN 45.

Configure interface Gi0/0 on the sensor to monitor traffic in promiscuous mode.

Add this interface to virtual sensor to vs0.

Set the description to “IDS monitoring for R4 and R5.”

Enable the IP Echo Request and IP Echo Reply signatures under the default Signature Definition Policy.

Tune the above two signatures so that they produce a medium-severity alert.

Verify that pings between R4 & R5 generate events.

Configuration

Cat2

Cat2(config)#vlan 450

Cat2(config-vlan)#remote-span

Cat2(config-vlan)#end

Cat3

monitor session 1 source vlan 45

monitor session 1 destination remote vlan 450

Cat4

monitor session 1 source vlan 45 , 450

monitor session 1 destination interface Fa0/15 ingress vlan 45




IPS

From the IDM, enable G0/0 by going to Configuration > Interfaces > Interfaces, select interface G0/0 and click the enable button.

We now need to assign the interface to vs0. Do this by going to Policies > IPS Policies and editing vs0. Click the checkbox next to G0/0 and click the Assign button, then apply.




Search for the ICMP signatures, 2000 & 2004, under sig0 and set them to enabled and medium severity.


In this question we have implemented IDS promiscuous monitoring using remote span sessions between Cat 3 and 4, and the G0/0 interface of the appliance.

Adding the „ingress vlan‟ keywords to the monitor session destination allows us to send traffic back from the sensor via interface G0/0 to the specified vlan. This satisfies our requirement for sending TCP resets back to vlan 45.

Verification

The command below highlights that vlan 450 has been successfully assigned to be a remote span vlan for Cat3 and Cat4.

Cat2#sh vlan remote-span

Remote SPAN VLANs

-----------------------------------------------------------------------------

450

Cat2#

We can also check the span session configuration as per bleow:




Cat3#sh monitor session all

Session 1

---------

Type : Remote Source Session

Source VLANs :

Both : 45

Dest RSPAN VLAN : 450

Cat3#

Cat4#sh mon ses all

Session 1

---------

Type : Local Session

Source VLANs :

Both : 45,450

Destination Ports : Fa0/15

Encapsulation : Native

Ingress : Enabled, default VLAN = 45

Ingress encap : Untagged

Cat4#

Cat4‟s F0/15 interface should now be showing as being in a promiscuous monitoring state:

Cat4#sh int f0/15

FastEthernet0/15 is up, line protocol is down (monitoring)

Hardware is Fast Ethernet, address is 001b.d4c8.0a91 (bia 001b.d4c8.0a91)

MTU 1508 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

As requested in the task, use icmp ping to verify that alerts are generated in the IDM event viewer.

Do this by pinging across vlan 45 from R5 to R4 (or vice versa).

R5#ping 192.1.45.4



!!!!!


R5#




You should then see alerts appear in the event viewer for both the echo and reply. Note that the severity is equal to medium.

End Verification

3.7 Monitoring Traffic with an IPS Inline Interface Pair

Create a new inline interface on the sensor called INLINE67.

Set the description to “R6 and R7 Monitoring Interface.”

Add the ge0/1 and ge0/2 interfaces.

R7 should belong to VLAN 670.

Add the new interface to virtual sensor vs1.

Verify that you can ping from R6 to R7.


Configuration

Cat2



Cat4











Cat4(config-if)#switchport trunk allowed vlan add 670

Cat4(config-if)#switchport trunk allowed vlan remove 67

R7


R7(config-subif)#encapsulation dot1Q 670


IPS

Enable the interfaces before attempting to create the Interface pair.




Create the Inline Interace Pair using G0/1 & G0/2.

Edit virtual sensor vs1 and assign the new inline pair to it.




As before, enable the icmp echo and echo reply signatures so we can verify the task has been completed successfully.


This task moves us into configuring the the first of our virtual sensors, and utilizing the inline IPS functionality of the appliance. As we are using inline mode, we need to create a new vlan to insert the IPS inline between R6 and R7. First, Vlan 670 needs to be created on Cat2 (the VTP server). On Cat4 we then define F0/16 & 17 as access ports and assign them to vlans 67 and 670 respectively to bring the IPS inline. To ensure the traffic flows through the IPS the last thing we need to change R7‟s vlan to 670, on both the switchport and the vlan 67 sub interface on the router.

We then need to proceed to the IDM to enable the interfaces and create the Interface Pair, ensuring that it gets assigned to the correct virtual sensor (vs1).

Verification

The IPS sensor in Inline mode transparently bridges traffic between VLANs 67 and 670 allowing traffic to pass.

As the IPS interfaces are enabled you should see the state transition to up for their respective switchports.

Cat4#

6d00h: %LINK-3-UPDOWN: Interface FastEthernet0/16, changed state to up

6d00h: %LINK-3-UPDOWN: Interface FastEthernet0/17, changed state to up




6d00h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/16,

changed state to up

6d00h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,

changed state to up

Double check that the correct vlans are now being trunked to R7 and that R7‟s Vlan 67 interface is reconfigured accordingly.

Cat4#sh run int f0/7



!


description R7 F0/1


switchport trunk allowed vlan 7,670


end




!



ip address 192.1.67.7 255.255.255.0


ip authentication key-chain eigrp 100 EIGRP

end

A good sign that things are configured correctly will appear once the interfaces are enabled on the IPS, as the EIGRP adjacency will re-establish between R6 and R7.

R7#

*Sep 16 21:18:46.528: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.1.67.6

(FastEthernet0/1.67) is up: new adjacency

As per the task requirements, verify that alerts are generated by pinging across the IPS interface pair.

R7#ping 192.1.67.6



!!!!!


R7#




Note that the alert is informational as per the default setting, the interface it was received on, and that the interfacegroup shows the correct virtual sensor, in this case vs1.

End Verification

3.8 Monitoring Traffic with an IPS Inline VLAN Pair

Configure the port on Cat4 connecting to the sensor‟s ge0/3 interface to be a dot1q trunk.

Configure this trunk port to only permit VLANs 89 and 890.

Create a new sub-interface on the sensor‟s ge0/3 interface. Use sub-interface #89.





Configuration

Cat2



Cat4


Cat4(config-if)#sw tru enc do

Cat4(config-if)#sw mode trun

Cat4(config-if)#sw trun all vl 89,890

Cat4(config-if)#exit

Cat4(config)#interface FastEthernet0/9

Cat4(config-if)#sw trun all vla remove 89

Cat4(config-if)#sw trun all vla add 890

Cat4(config-if)#end




R9

R9(config)#interface FastEthernet0/1.89

R9(config-subif)# encapsulation dot1Q 890

R9(config-subif)#exit

IPS

Enable Interface G0/3 as before and create a new Inline VLAN Pair, via Configuration > Interfaces > Vlan Pairs. Click Ok and apply to added the new trunk interface.

Next you assign the vlan pair to the sensor vs2.




Under Signature Definitions > sig2 enable the ICMP Echo and Echo Reply signatures.


This section included the secondary method for Inline IPS configuration using Vlan Pairs.

To bring the IPS inline between R8 & R9 we need to once again create another vlan to use on R9‟s side of the IPS and reconfigure Cat4 interfaces F0/9 & F0/18, and R9‟s F0/1.89 to utilize the newly created vlan 890.

We then need to enable interface g0/3 on the IPS and use it to create the Vlan pair. As per the question the description should be added as well as using 89 for the sub interface number.

Remember when adding the interface that it is assigned to the vs2 sensor.

Finally enable ICMP Echo and Echo Reply signatures under vs2 to confirm connectivity and alerts are being received.

Verification

Confirm that the IPS has successfully been placed between R8 and R9 and that communication is working.

R8#ping 192.1.89.9



!!!!!


R8#




Check that the event has been triggered on the IDM, noting that the events show up under virtual sensor vs2.

End Verification

3.9 Tuning Signatures & Variables

For each of the Virtual Sensors make sure that the networks behind the ASA are viewed with the highest priority.

In the previous sections, you tuned the signatures for ICMP Pings. For traffic between VLAN 6 and VLAN 7 only, tune the Echo Request signature to generate a high-severity event, and for Echo Replies to not generate an event at all.

Configure an existing signature that will fire a high severity alert when ICMP packets with a size of between 8000-50000 bytes, are detected between R8 & R9. Drop the packet inline. The alert should fire every 4

th event, and be summarized every 5

th event.

Configure the sensor to block traffic between R7 and R8 if it detects the Code Red Worm traffic hitting a web server on VLAN 8. For the purpose of this task, consider URLs containing any of the following, to be Code Red traffic: “cmd.exe” “default.ida” or “root.exe”. This task should account for the URL‟s using any case. Send an SNMP trap when this event is generated.

Configure the sensor to alert when it detects a file being deleted on the FTP server at 10.4.4.100 from Vlan 5. A low-priority IPS event should also be logged.

A custom TCP application is running in Vlan 5 on port 40004. This application should only be accessed from Vlan 7. An SNMP trap should be sent to the ACS Server in Vlan 10 if this traffic is detected being sourced from any other location. Standard severity and Risk Ratings should be used. Do not use IP or IP ranges for defining Vlan 7 when configuring this task.

Configuration




IPS

Tuning signatures on a per-interface basis is easy when the interfaces in question belong to different virtual sensors. This allows each interface to be governed by a different detection/prevention policy.

Here we set the networks behind the ASA, Vlans 10 & 20, a Target Value Rating of Mission Critical. This needs to be repeated for rules1 and rules2.




For the second bullet point task, to disable the echo reply alerts we need to create two event action filters for bidirectional traffic between vlan 6 & 7, under vs1. The action will be to remove Produce Alert.

Under sig1 definitions find Sig 2004 ICMP Echo request and change the severity to High.




So, looking through the available ICMP signatures in vs2‟s signature definitions, we see that Large ICMP Sig 2151, seems a perfect fit for our requirements. Note the green ticks represent the settings we have changed. Here you see we have set the severity to high, event action to include Deny Packet Inline, and the IP Payload Length to the specified requirements.

Scrolling down the edit signature window, we modify the event count to 4, the summary threshold to 5 and enable the signature.




Code Red

Here we need to create a new custom signature, within vs1. This is done using the Signature Wizard in the top right corner of sig1 > All Signatures.

Select String TCP as the engine.

Give the new signature a meaningful name.




Add the required actions, service port of 80 for http and the regex string to match on. [Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][Tt]\.[Ii][Dd][Aa]|[Rr][Oo][Oo][Tt]\.[Ee][Xx][Ee]

From the advanced wizard settings select to Alert on every fired event. Accept all other defaults and click finish and apply.




FTP

Search the FTP signatures on vs0 and edit the existing Sig for the FTP Delete command. As the alert is already a low severity all we need to do is remove the Deny action and enable it.

Hopefully you noticed that the engine was AIC FTP which requires FTP inspection to be enabled to function. This is achieved via the Advanced button at the bottom of the Signature Defintion window.




Custom TCP Application

Start the Signature Wizard for vs0.

Select the Atomic IP engine.

Name the sig.




Add the Request SNMP trap action. Select TCP as the protocol and 40004 as the destination port. Accept all remaining defaults, click finish then apply.

Under Event Action Rules > Rules0 > Event Variables create a new entry for vlan 7.

Create a new Event Action Filter to prevent the actions being applied when accessed from Vlan 7. Subtract all the actions for sig 60000. Use the variable to define VLAN7 in the fillter.





This is a mammoth task, with quite a lot going on.

Target Values

To adjust the IPS‟s perceived priority of a particular network or host, we need to adjust its target value rating. This can be manually achieved by modifying the rules policy for the virtual sensor.

The task requires us to have the IPS rate the networks behind the ASA (Vlan 10 & 20) with the highest priority which is Mission Critical, this effectively applies a maximum risk rating of 100 to any events triggered for these networks.

ICMP Tuning

For the second bullet task, we need to do a couple things. First it‟s asking for echo requests to trigger high alerts, meaning the severity needs to be changed. Second, we need to not produce alerts for echo replies between Vlan 6 & 7. This is done using event actions filters which allows you to selectively subtract certain actions from events, based on customized traffic flows. This requires us to create 2 filters, one from vlan 6 to vlan 7, and the other from vlan 7 to vlan 6, subtracting the produce alert action in the process. As we have high severity enabled for icmp echo the ping will now fail, based on the high risk rating being applied, which by default applies the deny packet inline action.

Large ICMP

The third sub task sees us utilizing the existing Large ICMP signature. We need to modify a few settings here. A couple to mention are: The event count which sets our trigger interval to only fire every four events, and the summary threshold which summarizes the alerts every five triggered




events. So in our case, the IPS would need to detect four large icmp packets before the first event was fired and 20 large icmp packets for the first summary alert.

When presented with these packet size task requirements be sure to choose the right setting. For instance if asked to check on a variable packet length, set the range value under the „IP Payload Length.‟ It‟s easy to get confused and choose the „Total Length‟ setting, which only matches on the exact value specified, not greater than or equal to the value.

The final little gotcha here is remembering that we are matching on the IP PAYLOAD length, so when pinging across the IPS to trigger the event remember to include the IP header length of 20 in the byte size. So the minimum size would be 8020.

Code Red

This task calls for a custom string based signature using a regex string to match on the required URL contents. As we are required to match on any case for the urls we need to enclose each characters upper and lower case form within square brackets, i.e. [Aa]. We also need to include the pipe „|‟ between each of the three defined strings. This does make the string quite long and introduces the possibility for mistakes.

To save time troubleshooting the regex side test the string on the ASA prior to creating the signature.

** When testing this signature ensure that the HTTP server is enabled on R8.

FTP

This is a fairly straight forward task, utilizing an existing FTP signature 12907, which detects the use of the FTP delete command. The only potential gotcha is to remember to enable the AIC FTP inspection engine, which is disabled by default.


A short task utilizing the Atomic IP engine and Event Variables. If asked not to use any attacker or victim IP‟s while defining events / signatures, use Event Variables to define them under the Event Action Rules section, so you can call on them later. One thing to remember is that when you are call a variable you need to prepend the variable name with the $ sign.

I.e $Variable1 – where Variable1 is the name.




Verification

Target Values

Ping R1 from R5, R7 or R9 to confirm that the Target Value Rating is in effect.

Note that it‟s now showing as mission critical, with a risk rating of 100.

ICMP Tuning

To test the next sub task ping both ways between vlan 6 & 7.

R6#ping 10.7.7.7 sou f0/1.6




.....


R6#

R7#ping 10.6.6.6 sou f0/1.7




.....


R7#




Note that when we ping between Vlan 6 & 7 ( and vice versa), the pings now fail and we now get a high-priority event for the Echo Request, and no event at all for the Echo Reply. Due to the event action override a high risk rating will automatically apply a Deny Packet Inline action to the triggered event.

Pings between VLANs 4 and 5 and VLANs 8 and 9 will continue to generate events as before, since they belong to different virtual sensors.

Now, let‟s ping from VLAN 8 to VLAN 9 and see what happens.

R8#ping 10.9.9.9



!!!!!


R8#




As you can see, our original event tuning is still in effect. The echo request has an informational severity and echo replies are being triggered as required.

Large ICMP

Ping from R8 to R9 to test the large ICMP signature fires as required.

R8#ping 10.9.9.9 size 8000 repeat 50



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


R8#

Whoa! What‟s going on is not working! The ping is succeeding and I have no alerts in the IDM!

Remember, you have used the ip payload length setting which means we need to add 20 bytes to the packet size for the IP header.







!!!..!!.!.!.!!..!!!..!!.!.!.!!..!!!..!!.!.!.!!..!!


R8#

That‟s better.

As we can see the alert is successfully fired as is the summary.

Code Red

When using regular expressions I find it easier to first test my regex string on the ASA to confirm they are correct.

ASA# test regex cMd.Exe

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][Tt$

INFO: Regular expression match succeeded.




ASA# test regex c.Exe

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][Tt]\$

INFO: Regular expression match failed.

ASA# test regex rOOt.Exe

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][T$


ASA# test regex default.ida

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll$


So from R7 do a simple http copy to verify the sig is working. The first copy is an example of a non IPS blocked test.

R7#copy http://192.1.24.8/test null0

Destination filename [null0]?

%Error opening http://192.1.24.8/test (No such file or directory)

R7#

R7#copy http://192.1.24.8/cmd.exe null0


%Error opening http://192.1.24.8/cmd.exe (I/O error)

R7#

R7#copy http://192.1.24.8/rOoT.exe null0


%Error opening http://192.1.24.8/rOoT.exe (I/O error)

R7#

R7#

R7#copy http://192.1.24.8/defAUlt.IDA null0


%Error opening http://192.1.24.8/defAUlt.IDA (I/O error)

R7#




The alert is created in the IDM, the flow is denied and an Snmp trap is sent to the ACS.

This is the SNMP trap received by the ACS.


To test enable the HTTP Server on R5 and set the port to 40004.


R5(config)#ip http port 40004

Test using a telnet connection to R5 on port 40004.




R8#telnet 5.5.5.5 40004

Trying 5.5.5.5, 40004 ... Open

adf


Date: Mon, 21 Sep 2009 07:48:28 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request


R8#

The alert will be generated by the IPS, the TCP Connection Reset, and an SNMP trap sent to the ACS.

To finish carry out the same task from R7 to ensure that an alert and Snmp trap is not generated.

End Verification




3.10 Advanced IPS & Anomaly Detection

Due to potential asymmetric traffic flows for VLAN 5 disable AD for Sensor vs0, and set the Normalizer mode accordingly.

AD for Virtual Sensor 2 should be set to learning mode, the learning period should be 72 hours. The learning action should be so that after the learning period the new Knowledge Base is saved and loaded, replacing the initial KB.

Ensure that Vlan 6 and 8 are seen as the Internal networks in their respective AD policies.

You have some unallocated dark ip that will eventually be reachable via R6, 10.16.16.0/24, 10.66.66.0/24 & 10.166.166.0/24, these subnets should not be present in any traffic flows and should be handled accordingly. The scanner thresholds should be reduced to 100 for both TCP and UDP.

In vs1 restrict the OS fingerprinting to the 10.0.0.0/8 network. Add two mappings one for the ACS server, so it is always seen as type WinNT, and one for a Linux Server called RedHat1 with an ip of 10.7.7.100.

Configuration

IPS

Goto Configuration > IPS Policies and edit vs0. Change the AD Operational Mode to „Inactive.‟ Collapse the Advanced options section and change the Normalizer mode to „Asymmetric Mode Protection.‟ This requires a reboot of the sensor.




Goto Configuration > IPS Policies and edit vs2. Change the AD Operational Mode to „Learn.‟

Go to the Learning Accept Mode tab under ad2 to modify the Learning Period. The default action of Rotate should be left as is.




Internal trusted networks should be assigned to the Internal zone, goto ad2 and add vlan 8.

Repeat the previous task for Vlan 6 in ad1 policy.

Any unallocated space should be protected using the illegal zone, add the R6 subnets here.




Tweak the Scanner thresholds in the illegal zone, under the Default Thresholds tab for each protocol. Repeat the same task for the UDP protocol.

Use the Add button under the Configured OS Maps in Event Actions Rules, specifying the name ip address and OS type.

Repeat the task for the ACS server, while also the 10/8 network in the Restrict field above.





I‟m not sure of the possibilities of these topics showing up in the lab, but as everything seems to be fair game, and we have an ambiguous Advanced Features section in the blueprint, though it was worth a mention.

The section touches on some advanced features, in terms of Anomaly Detection and OS identification. AD is used to classify and detect dynamic attacks such as scanning threats and worms, based on deviations from normal traffic pattern behavior, which would be too difficult to detect using signatures.

As AD expects to see the normal bidirectional flow of traffic, if you have an asymmetric environment, AD should be disabled, as it will detect incomplete connections, causing the sensor to classify normal traffic as scanning threats etc.

The default behavior of AD is detect mode which starts of in Learning mode for the first 24 hrs, and once complete saves and loads the KB, automatically switching to detect mode. Best practice is to run learning mode for a week or more to allow the sensor to fully gauge the normal legitimate traffic flows.

By default all network ranges are assigned to the external zone. The internal zone in AD should be used to define all your trusted networks on the insisde of the sensor. The illegal zone allows you to define dark or unallocated IP, as you should never see traffic flowing to these IP ranges you can be aggressive with your thresholds and policies.

We finish the task with OS identification. This is a handy addition that allows learning the OS type of hosts on the network, by inspecting the TCP handshake. Static mappings can also be set, as we have done here. These mappings are then used by the sensor to determine the relevance of the attack according to the OS and Associated Risk Rating.

Verification

Not a whole lot to verify in this section.




From the Monitoring Screen, we move down to Dynamic Data > Anomaly Detection.

Here we can view the state of the knowledge bases for each virtual sensor. Here we can also compare them to earlier saves of the KB.

Use the show thresholds to see that our previous changes to the illegal zone have taken effect.




One below AD in the Monitoring screen, we have OS ID‟s. The learned OS will be stored for each host, after its initial inspection. Any static mappings will override these learned these types. Note the dynamic OS type here for 10.1.1.100.

After pinging the ACS from R7 the echo request was dropped, note the target os type is WIN-NT, which is what we statically mapped to this host.

End Verification




3.11 Blocking using the Security Appliance

A host on VLAN 5 is carrying out an access attack on R1 using telnet with a username of „Admin.‟

Make sure this attack is detected as high severity, and the triggered event contains as much information as possible.

When the event is triggered the IPS should connect to the ASA using SSH and perform a shun.

Use the ASA local database for authentication with user „IPS_Admin‟ and password „ipexpert.‟ Enable password should also be „ipexpert.‟

Configuration

ASA

ASA(config)# username IPS_Admin password ipexpert

ASA(config)# ssh 10.1.1.15 255.255.255.255 inside

ASA(config)# aaa authentication ssh con LOCAL

ASA(config)# ena pass ipexpert

IPS

Create a new custom signature, using the signature wizard for vs0.

Select the String TCP engine. Click „Next‟.




Name the Signature. Click „Next‟.

Add Produce Verbose Alert & Request Block Host as event actions. The username Admin should be added to regex field. As it was not requested to include upper and lower case, an exact match would be sufficient. The Service port should be equal to telnet (23).




Change the Severity to „High‟. Click „Next,‟ then „Finish‟.

Now we need to add the blocking configuration. Use the the Sensor Management > SSH > Known Host Keys to add the ASA‟s SSH keys.




Add a login profile for the ASA under the Sensor Management > Blocking > Device Login Profiles.

Add the ASA as a blocking device under the Sensor Management > Blocking > Blocking Devices.


This task focuses on Host blocking or shunning using the ASA.

To achieve these we need to create a custom signature, which Request a Block Host action to the ASA. We are asked to ensure that the event contains as much info as possible, which requires a verbose alert.

For configuring Host Blocking on the IPS we need to do a few things. First is add the RSA keys from the ASA. We then need to add a login profile including the IPS_Admin user account details and the enable password.

Finally, add the ASA as a blocking device, ensuring the ASA Login Profile and device type are set correctly.

Verification

Confirm rsa keys are present on the ASA. If not you will need to create them with:

„crypto key generate rsa modulus 1024‟




ASA# sh crypto key mypubkey rsa

Key pair was generated at: 05:34:50 UTC May 18 2009

Key name: <Default-RSA-Key>

Usage: General Purpose Key

Modulus Size (bits): 1024

Key Data:

30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00cef145

29a87a61 5b917614 5d680627 40862d58 bb06013f 832ba983 1fc7befc ca7f0916

a8feda09 ec0b8304 0c22e369 5d93fada b588d0ca 3b4cda1b 8ee5315d 0df412e3

e9ec337b 8344272b dbccf3f3 054b2720 50d8f64d e5247c72 da0058e0 c05a246d

03facae3 3cf704c6 195494dc 8fe8637b 22733935 05c71b0e ae4ab751 23020301

0001


Key name: <Default-RSA-Key>.server

Usage: Encryption Key


Key Data:

307c300d 06092a86 4886f70d 01010105 00036b00 30680261 00960150 f09b948e

d4ff4c9a b58619a7 b0930038 6746b639 4bbb22ac 2cdd058c adda0459 b9bb2aa0

30b85222 46bc312d f367ccce 6c9e9cce 2969a1c1 141013b2 4aa163a4 898abbd0

17d86d54 c319cd5f 8e4aa4dc dea1e72d 06ffdcc0 aafd93fc 69020301 0001

ASA#

Telnet to R1 from R5, and type Admin.

R5#telnet 10.2.2.1 /source-interface f0/1.5



Password:

R1>

R1>

R1>Admin

The connection should hang due to being shunned by the ASA.

ASA# sh shun

shun (outside) 10.5.5.5 0.0.0.0 0 0 0

ASA#




Check the event has been fired and that it has verbose output, and shun Requested true.

From the Monitoring tab, navigate to Time Based Actions > Host Blocks to see the host address entries currently blocked by the IPS. Use the delete button to clear the block.

End Verification

3.12 Blocking using IOS Devices

FTP & HTTP traffic is required to be inspected on vs1.

If malicious traffic is tunneled through HTTP from Vlan 4 to Vlan 7 a block should placed on R6‟s f0/1.24 interface, and all the traffic should be logged.

Use SSH to connect to R6 from the IPS.

R6 should have a local user „R6Admin‟ with password „ipexpert.‟




Configuration

R6

Create RSA keys for use with SSH, remembering to add a domain name prior to generating them.

R6(config)#ip domain name ipexpert.com

R6(config)#cry key generate rsa general-keys modulus 1024




R6(config)#

*Sep 23 17:32:21.027: %SSH-5-ENABLED: SSH 1.99 has been enabled

R6(config)#username R6Admin password ipexpert

R6(config)#ena sec ipexpert



IPS

From sig1 > All Signatures click the Advanced button at the bottom of the page. Enable the AIC Engine for FTP and HTTP Inspection.




Use the existing Alarm on Non-HTTP traffic signature for this task. Enable it. Remove the Deny Connection Inline action and replace it with Request Block Connection. Also add the Log Pair packets to capture all the traffic.




Retrieve R6‟s RSA keys.

Add the login profile for R6.

R6 then needs configuring as a blocking device.

Add R6‟s F0/1.24 as a blocking interface as requested in the task.





This task moves us to blocking using an IOS router, where the IPS creates an ACL and applies it to the specified interface.

The process here is fairly similar to the ASA blocking but with an additional step. For IOS devices we also need to create a Router Blocking Device Interface, to tell the IPS which interface the block will be applied to.

Note: If you already had an ACL assigned to the specified interface you would need to specify the pre and post block acls under the Router Blocking device Interface settings.

The signature we used for this task id# 12674 „Alarm on non-http traffic‟ uses the AIC engine to inspect inside the HTTP traffic to ensure it conforms to RFCs etc. The AIC HTTP or FTP inspection are disabled by default, so needs to be enabled from the advanced signature settings.

If you‟re unsure of the signature to use in a task, try changing the Filter menu to Sig Name and use the filter field to search for potential signatures, you may find an existing one matches your requirements.

Verification

Test SSH Login to R6.

R7#ssh -l R6Admin 192.1.67.6

Password:

R6>en

Password:

R6#

Enable the HTTP Server on R7.


Test by connecting via telnet to the HTTP server on R7.

R4#telnet 10.7.7.7 80 /source-interface f0/1.4

Trying 10.7.7.7, 80 ... Open

jkhg


Date: Wed, 23 Sep 2009 19:07:45 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request


R4#




The non http alert is created.

On R6 we can see that the IPS has logged in a made changes to the configuration.

A new ACL has been created and applied to the selected interface. Not that the first entry in the ACL is a permit any for the Sensor.

*Sep 23 19:05:29.010: %SYS-5-CONFIG_I: Configured from console by R6Admin on

vty0 (10.1.1.15)




!



ip address 192.1.24.6 255.255.255.0

ip access-group IDS_fastethernet0/1.24_in_1 in



end

R6#sh access-list

Extended IP access list IDS_fastethernet0/1.24_in_1

10 permit ip host 10.1.1.15 any (38 matches)

20 deny tcp host 10.4.4.4 host 10.7.7.7 eq www


R6#




We can see from the Host Blocks screen that a block is in place for R4 to R7 on port 80.

Subsequent connections on port 80 from R4 are blocked by the ACL.


Trying 10.7.7.7, 80 ...


R4#

R6#sh access-list



20 deny tcp host 10.4.4.4 host 10.7.7.7 eq www (1 match)


R6#

Final verification is to check that the IP logging is taking place. This is done by navigating to IP Logging secion within Sensor Monitoring. These logs can downloaded for viewing in capture utilities such as Wireshark.

End Verification

3.13 Rate Limiting

An ICMP Flood is being generated by multiple hosts on Vlan 6 destined for Vlan 9.

Tune an existing signature in vs2 to place a rate limit on R8‟s F0/1.24 interface.

Login to R8 using Telnet and the local user „R8Admin‟ password „ipexpert.‟

The rate limit should be set to 2% when more than 25 pings occur within a 1 second period.




Configuration

R8


IPS

Search for the icmp flood in the filter field for vs2 sig definitions.

Edit the exisitng sig id 2152 ICMP Flood. Add the Request Rate Limit action and modify the both the rate limit percentage to 2 and the rate to 25.

Create a new profile for R8. Login password should be cisco as this is already configured on the Line of R8, with an enable of ipexpert.




Add R8 as a blocking device this time using Telnet for communication and checking rate limit instead of blocking.

As we did with blocking on the IOS device, we need to enable rate limiting by create a Router Blocking Interface for R8.


The final task for the IPS appliance in this lab is to apply a rate limit to an IOS device. Configuration for this very similar to the blocking section earlier. The one thing which has caught me out in the past is an error saying that rate limiting is not enabled. This was basically due to not having a blocking interface configured for the device. Don‟t be fooled by the title Router Blocking Device Interface. This is actually required to enable the rate limiting functions. Logically thinking, how would it know where to apply the rate limit without this?

One key point to mention with Rate Limiting is how the rate limit is applied. The IPS dynamically creates a classed based policy to apply the rate limit to the devices interface.

For instance:

class-map match-any IDS_RL_CLASS_MAP_icmp-xxBx-8-2_1

match access-group name IDS_RL_ACL_icmp-xxBx-8-2_1

!

policy-map IDS_RL_POLICY_MAP_1

class IDS_RL_CLASS_MAP_icmp-xxBx-8-2_1

police cir percent 2

!


service-policy input IDS_RL_POLICY_MAP_1

The key thing to remember here is that when applying rate limits via the IPS, if you already have a service policy applied in the same direction on the devices interface then the IPS rate limit policy will override any existing policies.

So be mindful of the lab task or network design when using this feature.




Verification

Ensure you can access R8 using telnet.

R9#telnet 192.1.89.8

Trying 192.1.89.8 ... Open


Password:

R8>en

Password:

R8#

R8#exit


R9#

Ping Vlan 9 interface on R9 from Vlan 6.

R6#ping 10.9.9.9 source f0/1.6 size 5000 rep 300




!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!

!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!

!!!!!!.!!!!!!!!!!!!!


R6#

The IPS logs into R8 and applies the Rate limit to R8, to the specified interface.

R8#

*Sep 23 19:48:25.166: %SYS-5-CONFIG_I: Configured from console by vty0

(10.1.1.15)

R8#




!



ip address 192.1.24.8 255.255.255.0




end

R8#

As you can see, a service policy is used for rate limiting, so you can check the statistics output for the interface.




R8#sh policy-map interface

FastEthernet0/1.24

Service-policy input: IDS_RL_POLICY_MAP_1

Class-map: IDS_RL_CLASS_MAP_icmp-xxBx-8-2_1 (match-any)


5 minute offered rate 41000 bps, drop rate 2000 bps

Match: access-group name IDS_RL_ACL_icmp-xxBx-8-2_1


5 minute rate 41000 bps

police:

cir 2 %


conformed 1038 packets, 1364124 bytes; actions:

transmit

exceeded 12 packets, 16776 bytes; actions:

drop





Match: any

R8#

Check the event has been correctly fired on the IPS.

You should also have an entry for rate limit under the Sensor Monitoring > Rate Limits section.

End Verification




3.14 ASA IPS

Configure the ASA to enable the IPS feature set on both interfaces.

Informational and Attack signatures defaults should be set to alarm.

Attack signatures should be set to drop and close the connection on the outside.

Disable the ICMP Echo & Echo Reply signatures.

You are receiving a large number false positive alerts, tune the following signatures to prevent these alerts:

Timestamp Options RPC proxy Calls to the Remote Execution Daemon

Configuration

ASA

ASA(config)# ip audit info action alarm

ASA(config)# ip audit attack action alarm

ASA(config)# ip audit name INFO info

ASA(config)# ip audit name ATTACK attack

ASA(config)# ip audit name ATTACKOUT attack action alarm reset

ASA(config)# ip audit interface inside INFO

ASA(config)# ip audit interface outside INFO

ASA(config)# ip audit interface inside ATTACK

ASA(config)# ip audit interface outside ATTACKOUT

ASA(config)# ip audit signature 1002 disable






Default IPS functionality on the ASA is pretty basic without the addition of the IPS module.

So expect any tasks around ASA IPS to be pretty straight forward.

Here we get a little creative with how we apply ip audit and its actions. Default settings can be applied for info and attack individually. This is done either globally or when defining the audit policy. Setting the actions on the policy line will override the default settings for the info and attack policies.

Info and attack policies need to be defined, and applied to interfaces separately. In this task we first set the default actions globally for info and attack policies. We then define both an info and attack policy using default settings to be assigned to the inside interface. A second attack policy is defined with an override action of reset, which drops the packet and closes the connection, to meet the requirements of the outside interface.

The only signature tuning that can be done with ip audit is to disable the signature.




When asked to disable signatures simply using the „show ip audit count‟ command may help to identify the required sigs, i.e:

ASA# sh ip aud count

IP AUDIT GLOBAL COUNTERS

1000 I Bad IP Options List 0

1001 I Record Packet Route 0

1002 I Timestamp 0

1003 I Provide s,c,h,tcc 0

1004 I Loose Source Route 0

1005 I SATNET ID 0

1006 I Strict Source Route 0

1100 A IP Fragment Attack 0

1102 A Impossible IP Packet 0

1103 A IP Teardrop 0

2000 I ICMP Echo Reply 0

2001 I ICMP Unreachable 0

2002 I ICMP Source Quench 0

For this task we made things a little more interesting by introducing a couple of ambiguous sigs, that you may not be able identify using the show command alone. If in doubt refer to the doc cds ASA command reference, which holds a more detailed list of the signatures.

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/i3.html#wp1837790

Verification

Pinging from the ACS server to R8 we can trigger the Fragmented ICMP attack signature.

ASA# sh ip aud count

IP AUDIT GLOBAL COUNTERS

2150 A Fragmented ICMP 171

IP AUDIT INTERFACE COUNTERS: outside


IP AUDIT INTERFACE COUNTERS: inside


##OUTPUT TRUNCATED##

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/i3.html#wp1837790




ASA# sh log | i IDS

Sep 23 2009 20:43:29: %ASA-4-400023: IDS:2150 ICMP fragment from 10.1.1.100

to 192.1.24.8 on interface inside


to 192.1.24.8 on interface inside


to 10.1.1.100 on interface outside


to 10.1.1.100 on interface outside

The ICMP is being permitted through to R8 but being dropped on its return, by the attack action on the outside interface.

To check that our defined signatures are disabled, we can do a quick test using icmp timestamp.

R8#ping

Protocol [ip]:

Target IP address: 10.1.1.100

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]: t

Number of timestamps [ 9 ]:

Loose, Strict, Record, Timestamp, Verbose[TV]:

Sweep range of sizes [n]:



Packet has IP options: Total option bytes= 40, padded length=40

Timestamp: Type 0. Overflows: 0 length 40, ptr 5

>>Current pointer<<

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Time= 00:00:00.000 UTC (00000000)

Request 0 timed out

Request 1 timed out

Request 2 timed out

Request 3 timed out

Request 4 timed out


R8#




ASA# sh ip audit count




1002 I Timestamp 0


Doing a show ip audit count tells us that the signature did not fire, but the pings were unsuccessful??? This is because the ASA is dropping the timestamp option by default. Check your logs for clues.

ASA# sh log

Sep 23 2009 20:51:20: %ASA-6-106012: Deny IP from 192.1.24.8 to 10.1.1.100,

IP options: "Timestamp"


IP options: "Timestamp"

Verify that the outside interface attack policy is dropping other IP option traffic, by pinging using the source router option.

R8#ping

Protocol [ip]:

Target IP address: 10.1.1.100

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]: S

Source route: 192.1.24.10

Loose, Strict, Record, Timestamp, Verbose[SV]:

Sweep range of sizes [n]:



Packet has IP options: Total option bytes= 7, padded length=8

Strict source route: <*>

(192.1.24.10)

Request 0 timed out

Request 1 timed out

Request 2 timed out

Request 3 timed out

Request 4 timed out


R8#

ASA# sh log

Sep 23 2009 20:59:28: %ASA-4-400006: IDS:1006 IP Options Strict Source Route

from 192.1.24.8 to 192.1.24.10 on interface outside


IP options: "Strict Src Routing"

Sep 23 2009 20:59:28: %ASA-3-313001: Denied ICMP type=8, code=0 from

192.1.24.8 on interface outside




ASA# sh ip audit count interface outside




1002 I Timestamp 0


1004 I Loose Source Route 0

1005 I SATNET ID 0

1006 I Strict Source Route 5

1100 A IP Fragment Attack 0

End Verification

3.15 IOS IPS Setup

Configure R1 to enable the IPS feature set inbound on vlan 10 and 20 interfaces.

The IPS v5 signature package is contained in the path: flash:/IOS-Sxxx-CLI.pkg.

Be sure to follow the documented prerequisites.

Once completed enable ICMP Echo Request signature and ensure that the IPS is monitoring successfully.

Configuration

R1

Add a domain name and create an rsa key pair.

R1(config)#ip domain name ipexpert.com

R1(config)#cry key gen rsa gen mod 1024




R1(config)#

Sep 24 18:04:21.874: %SSH-5-ENABLED: SSH 1.99 has been enabled

As per the pre-requisites, add the public key to decrypt the signatures.

R1(config)#crypto key pubkey-chain rsa

R1(config-pubkey-chain)#named-key realm-cisco.pub signature

Translating "realm-cisco.pub"

R1(config-pubkey-key)#key-string

Enter a public key as a hexidecimal number ....

R1(config-pubkey)#$64886 F70D0101 01050003 82010F00 3082010A 02820101

R1(config-pubkey)#$C7A24 5097A975 206BE3A2 06FBA13F 6F12CB5B 4E441F16

R1(config-pubkey)#$BE27F 37FDD9C8 11FC7AF7 DCDD81D9 43CDABC3 6007D128

R1(config-pubkey)#$FADC1 359C189E F30AF10A C0EFB624 7E0764BF 3E53053E

R1(config-pubkey)#$8AF03 DED7A5B8 9479039D 20F30663 9AC64B93 C0112A35

R1(config-pubkey)#$AE74C FA9E481D F65875D6 85EAF974 6D9CC8E3 F0B08B85




R1(config-pubkey)#$189FF CC189CB9 69C46F9C A84DFBA5 7A0AF99E AD768C36

R1(config-pubkey)#$3FB1F 9FB7B3CB 5539E1D1 9693CCBB 551F78D2 892356AE

R1(config-pubkey)#$A4F4D 87BFCA3B BFF668E9 689782A5 CF31CB6E B4B094D3

R1(config-pubkey)#F3020301 0001

R1(config-pubkey)#quit

R1(config-pubkey-key)#

R1(config-pubkey-key)#end

R1#wr

Verify the IPS version running in IOS (Version 3.xxx.xxx denotes IPS version 5).

R1#show subsys name ips

Name Class Version

ips Protocol 3.001.002

R1#

Retire all signature categories:

R1(config)#ip ips signature-category

R1(config-ips-category)#category all

R1(config-ips-category-action)#retired true

R1(config-ips-category-action)#exit

R1(config-ips-category)#exit

Do you want to accept these changes? [confirm]

R1(config)#

Sep 24 18:22:08.267: Applying Category configuration to signatures

R1(config)#

Un-retire the ios basic signature category:


R1(config-ips-category)#category ios_ips basic

R1(config-ips-category-action)#retired false

R1(config-ips-category-action)#end


R1#


Sep 24 18:25:05.701: %SYS-5-CONFIG_I: Configured from console by

console

R1#wr


[OK]

R1#

Make a new directory in flash for the IPS files.

R1#mkdir flash:/ips5

Create directory filename [ips5]?

Created dir flash:/ips5

R1#




R1#dir

Directory of flash:/

1 -rw- 58246016 Oct 11 2008 13:20:50 -04:00 c2800nm-

adventerprisek9-mz.124-22.T.bin

2 -rw- 33730764 Oct 7 2005 13:08:52 -04:00 c2800nm-

adventerprisek9-mz.124-3a.bin

3 -rw- 7187712 Jan 26 2009 11:01:50 -05:00 IOS-S376-CLI.pkg

4 drw- 0 Sep 24 2009 14:34:56 -04:00 ips5

255565824 bytes total (156389376 bytes free)

R1#

Configure IPS on R1, applying it inbound on both Fa0/1.10 & Fa0/1.20.

R1#cc


R1(config)#ip ips name MYIPS

R1(config)#ip ips config location flash:/ips5


R1(config-subif)#ip ips MYIPS in

R1(config-subif)#int f0/1.20

Sep 24 18:42:10.038: %IPS-6-ENGINE_BUILDS_STARTED: 14:42:10 EDT Sep 24 2009

Sep 24 18:42:10.038: %IPS-6-ENGINE_BUILDING: atomic-ip - 3 signatures - 1 of

13 engines

Sep 24 18:42:10.050: %IPS-6-ENGINE_READY: atomic-ip - build time 12 ms -

packets for this engine will be scanned

Sep 24 18:42:10.050: %IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 12 ms



R1#wr


[OK]

R1#

Load the signature file in flash into the IPS.

R1#copy flash:IOS-S376-CLI.pkg idconf


Sep 24 18:54:20.041: %IPS-6-ENGINE_BUILDING: multi-string - 12 signatures - 1

of 13 engines

Sep 24 18:54:20.073: %IPS-6-ENGINE_READY: multi-string - build time 32 ms -


Sep 24 18:54:20.093: %IPS-6-ENGINE_BUILDING: service-http - 667 signatures -

2 of 13 engines

Sep 24 18:54:28.201: %IPS-6-ENGINE_READY: service-http - build time 8108 ms -


Sep 24 18:54:28.233: %IPS-6-ENGINE_BUILDING: string-tcp - 1211 signatures - 3

of 13 engines

Sep 24 18:54:58.249: %IPS-6-ENGINE_READY: string-tcp - build time 30016 ms -


Sep 24 18:54:58.253: %IPS-6-ENGINE_BUILDING: string-udp - 75 signatures - 4

of 13 engines

Sep 24 18:54:58.885: %IPS-6-ENGINE_READY: string-udp - build time 632 ms -


Sep 24 18:54:58.889: %IPS-6-ENGINE_BUILDING: state - 31 signatures - 5 of 13

engines

Sep 24 18:54:58.961: %IPS-6-ENGINE_READY: state - build time 72 ms - packets

for this engine will be scanned




Sep 24 18:54:59.025: %IPS-6-ENGINE_BUILDING: atomic-ip - 307 signatures - 6

of 13 engines



Sep 24 18:55:00.365: %IPS-6-ENGINE_BUILDING: string-icmp - 3 signatures - 7

of 13 engines

Sep 24 18:55:00.405: %IPS-6-ENGINE_READY: string-icmp - build time 40 ms -


Sep 24 18:55:00.409: %IPS-6-ENGINE_BUILDING: service-ftp - 3 signatures - 8

of 13 engines

Sep 24 18:55:00.429: %IPS-6-ENGINE_READY: service-ftp - build time 20 ms -


Sep 24 18:55:00.429: %IPS-6-ENGINE_BUILDING: service-rpc - 75 signatures - 9

of 13 engines

Sep 24 18:55:00.753: %IPS-6-ENGINE_READY: service-rpc - build time 324 ms -


Sep 24 18:55:00.753: %IPS-6-ENGINE_BUILDING: service-dns - 38 signatures - 10

of 13 engines

Sep 24 18:55:00.821: %IPS-6-ENGINE_READY: service-dns - build time 68 ms -


Sep 24 18:55:00.821: %IPS-6-ENGINE_BUILDING: normalizer - 9 signatures - 11

of 13 engines

Sep 24 18:55:00.877: %IPS-6-ENGINE_READY: service-smb-advanced - build time

52 ms - packets for this engine will be scanned

Sep 24 18:55:00.877: %IPS-6-ENGINE_BUILDING: service-msrpc - 29 signatures -

13 of 13 engines

Sep 24 18:55:00.949: %IPS-6-ENGINE_READY: service-msrpc - build time 68 ms -



R1#

Enable and un-retire the ICMP Echo Request signature 2004.

R1#conf t


R1(config)#ip ips signature-definition

R1(config-sigdef)#signature 2004

R1(config-sigdef-sig)#status

R1(config-sigdef-sig-status)#enabled true

R1(config-sigdef-sig-status)#retired false

R1(config-sigdef-sig-status)#end


R1#



of 13 engines




Sep 24 19:09:12.099: %SYS-5-CONFIG_I: Configured from console by console

R1#wr


[OK]

R1#





The pre-requisites in the config guide link below need to be followed for deploying IPS Feature set on an IOS Router.

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_ips5_sig_fs_ue.html#wp1049428

Although this may seem like a simple task on the surface, the ips (IPS?) behavior in IOS has changed dramatically in the version 5 format. I would recommend following this config guide when you deploy IOS IPS v5, just to ensure things go smoothly.

The pre-requisites start with creating an rsa key pair on R1 and installing the public key to enable the signature package to be decrypted. This public key is found at the beginning of the guide above.

The next step is critical to ensuring this task is successful, all signatures must be retired prior to enabling the IPS. If you do not retire all the sigs, there is a large probability that your device will run out of resources and die, due to the large amount of signatures it will have to compile. If this happens your going to be in a world of hurt trying to regain access your device.

Once you have retired all the categories, un-retire a small subset of signatures. We have followed the guide and enabled the ios (IOS?) basic category.

We are then safe to enable the IPS feature set on the device. To enable the IPS we need to define a policy, giving it a name, and a stored config location in flash. Once this is done apply the policy to your interface/s.

The final stage to enabling the IPS is the loading and compiling of the signatures.

Use the „copy flash:/IOS-Sxxx-CLI.pkg idconf‟ command to load the signature package from flash into the IPS, and compile all the non-retired signatures. This can take some time depending on how many signatures/categories are enabled.

All that‟s left is to start tuning any required signatures. The task asks for ICMP Echo Request signature to be enabled, the ID is the same as on the IPS appliance so is sig id 2004. Just remember when doing the task, ensure that the signature is both in an enabled state of true and a retired state of false.






Verification

Once you are happy that the IOS IPS is configured, verify your config using the following:

R1#sh ip ips configuration

IPS Signature File Configuration Status

Configured Config Locations: flash:/ips5/

Last signature default load time: 14:55:00 EDT Sep 24 2009

Last signature delta load time: 15:24:05 EDT Sep 24 2009

Last event action (SEAP) load time: -none-

General SEAP Config:

Global Deny Timeout: 3600 seconds

Global Overrides Status: Enabled

Global Filters Status: Enabled

IPS Auto Update is not currently configured

IPS Syslog and SDEE Notification Status

Event notification through syslog is enabled

Event notification through SDEE is disabled

IPS Signature Status

Total Active Signatures: 339

Total Inactive Signatures: 2167

IPS Packet Scanning and Interface Status

IPS Rule Configuration

IPS name MYIPS

IPS fail closed is disabled

IPS deny-action ips-interface is false

Interface Configuration

Interface FastEthernet0/1.10

Inbound IPS rule is MYIPS

Outgoing IPS rule is not set




IPS Category CLI Configuration:

Category all:

Retire: True

Category ios_ips basic:

Retire: False

R1#

Check the IPS signature count will show you what categories are enabled, compiled or retired:




R1#sh ip ips signature count

Cisco SDF release version S376.0

Trend SDF release version V0.0

Signature Micro-Engine: multi-string: Total Signatures 12

multi-string enabled signatures: 10

multi-string retired signatures: 12

Signature Micro-Engine: service-http: Total Signatures 667

service-http enabled signatures: 164

service-http retired signatures: 570

service-http compiled signatures: 97

service-http obsoleted signatures: 2

**OUTPUT TRUNCATED**

Signature Micro-Engine: atomic-ip: Total Signatures 307

atomic-ip enabled signatures: 100

atomic-ip retired signatures: 285

atomic-ip compiled signatures: 22

Total Signatures: 2506

Total Enabled Signatures: 1117

Total Retired Signatures: 2167

Total Compiled Signatures: 339

Total Obsoleted Signatures: 25

R1#

The „show ip ips signature sigid‟ gives you detailed information about the signatures. Note from the output below that in this instance the sig2004 was successfully enabled, but the compiled state is „Nr‟ or not compiled due to sig being retired. If the signature is not compiled, it is not yet in use, so will not generate any alarms. As you can see this gives some handy info regarding what each column is related to.

R1#sh ip ips signature sigid 2004 subid 0

En - possible values are Y, Y*, N, or N*

Y: signature is enabled

N: enabled=false in the signature definition file

*: retired=true in the signature definition file

Cmp - possible values are Y, Ni, Nr, Nf, or No

Y: signature is compiled

Ni: signature not compiled due to invalid or missing parameters

Nr: signature not compiled because it is retired

Nf: signature compile failed

No: signature is obsoleted

Action=(A)lert, (D)eny, (R)eset, Deny-(H)ost, Deny-(F)low

Trait=alert-traits EC=event-count AI=alert-interval

GST=global-summary-threshold SI=summary-interval SM=summary-mode

SW=swap-attacker-victim SFR=sig-fidelity-rating Rel=release

SigID:SubID En Cmp Action Sev Trait EC AI GST SI SM SW SFR Rel

----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---

2004:0 Y* Nr A INFO 0 1 0 200 30 FA N 100 S1




Here is the output for a successfully enabled Echo request signature, both enabled and compiled.




----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---

2004:0 Y Y A INFO 0 1 0 200 30 FA N 100 S1

sig-name: ICMP Echo Request

Confirm that R1‟s IPS is now functioning as expected by pinging the ACS from R4.

R4#ping 10.1.1.100 repeat 100



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


R4#

R1#

Sep 24 20:17:05.588: %IPS-4-SIGNATURE: Sig:2004 Subsig:0 Sev:25 ICMP Echo

Request [192.1.24.4:8 -> 10.1.1.100:0] VRF:NONE RiskRating:25



R1#sh ip ips statistics

Signature statistics [process switch:fast switch]

signature 2004:0: packets checked [0:1204] alarmed [0:400] dropped [0:0]

Interfaces configured for ips 2






TCP reassembly statistics

received 0 packets out-of-order; dropped 0

peak memory usage 0 KB; current usage: 0 KB

peak queue length 0

R1#

Everything looks happy!!

End Verification




3.16 IOS IPS Tuning

Set the event notification method to syslog.

Create the ACS as a mission critical device.

Configure Sig ID 2150 to drop and alarm on receipt of the fragmented icmp traffic.

Enable the ICMP Flood category.

Configuration

R1

Configure event notifications using syslog.

R1(config)#ip ips notify log

Configure the IPS so that it see the ACS Server as a mission critical device:

R1(config)#ip ips event-action-rules

R1(config-rul)#target-value mission-critical target-address

10.1.1.100

R1(config-rul)#end


R1#

Configure signature 2150 to drop and alarm:





R1(config-sigdef-sig-status)#exit

R1(config-sigdef-sig)#engine

R1(config-sigdef-sig-engine)#event-action produce-alert deny-packet-

inline

R1(config-sigdef-sig-engine)#end


R1#



of 13 engines





R1#

Enable the ICMP Flood Category.


R1(config-ips-category)#category dos icmp_floods


R1(config-ips-category-action)#enabled true









of 13 engines




2 of 13 engines



R1#


of 13 engines




of 13 engines




engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines





R1#


We finish off this lab with tuning the signatures on the IOS IPS. Due to the shear amount of signatures available to the new v5 IPS its now a little more difficult to search for signature types, etc. The documentation also seems a little light in detail, so be prepared for some digging around. To save a little time you might do a quick search on the IPS Sensor, if you are having a hard time finding a particular signature, etc.

Some of the features available on the sensor are also now available in IOS, although behavior does not seem entirely consistent between the two. For instance, here we use the Event action rules, target value rating to classify the ACS with mission critical priority.




We also need to enable the ICMP Fragmented traffic signature and apply a drop action to the traffic, it wasn‟t specified but we chose to use deny packet inline. Remember to include the produce-alert in the event action, or it will be removed.

Finally we enable another signature category. ICMP Floods is located under the dos category and needs setting to both enabled true and retired false.

Don‟t forget that a lot of these sigs will have been retired, so remember to check their state, once configured.

Verification

Check the status of your configuration on R1.






Last event action (SEAP) load time: 17:07:53 EDT Sep 24 2009














IPS name MYIPS











Category all:

Retire: True


Retire: False

Category dos icmp_floods:

Retire: False

Enable: True

R1#




Verify the addition of the target value rating for the ACS Server.

R1#sh ip ips event-action-rules target-value-rating

Target Value Ratings

Target Value Setting IP range

mission-critical 10.1.1.100-10.1.1.100

R1#

Confirm that the ICMP Fragment signature is configured as expected, and that the alarms are fired, after pinging from the ACS Server.

R1(config)#do sh ip ips sig sig 2150 sub 0



----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---

2150:0 Y Y AD INFO 0 1 0 200 30 FA N 100 S2

sig-name: Fragmented ICMP Traffic

sig-string-info: My Sig Info

sig-comment: Sig Comment

Engine atomic-ip params:

regex-string :

address-with-localhost :

dst-ip-addr :

dst-port :

exact-match-offset :

fragment-status : want-fragments

R1#

Sep 24 22:26:33.023: %IPS-4-SIGNATURE: Sig:2150 Subsig:0 Sev:25 Fragmented

ICMP Traffic [10.1.1.100:0 -> 192.1.24.4:0] VRF:NONE RiskRating:25

Sep 24 22:26:38.479: %IPS-4-SIGNATURE: Sig:2150 Subsig:0 Sev:25 Fragmented

ICMP Traffic [10.1.1.100:8 -> 192.1.24.4:0] VRF:NONE RiskRating:25



















peak queue length 0

R1#

R1#sh ip ips category dos icmp_floods config


Retire: False

Enable: True

R1#

End Verification














Lab 3B: Troubleshoot IPS

Configuration

Estimated Time to Complete: 3-4 Hours





3.0 Cisco IPS Troubleshooting Detailed Solutions


3.1 Sensor Setup and Administration

From the console, configure the hostname as „IPS‟ and the command-and-control interface of the sensor with an IP address of 10.1.1.15/24 and a default gateway of 10.1.1.1.

Configure the sensor to listen for HTTPS requests on port 10443 instead of the default of 443.

Allow HTTPS access to the sensor only from the ACS server at 10.1.1.100.

From this point on, you may use either the command-line or IDS Device Manager (IDM) to configure the sensor. Note that IDM is specifically mentioned in the Blueprint, so you should be familiar with its use.

Configuration

IPS

service web-server

port 10433

exit

service host

network-settings

no access-list 10.1.1.0/24



These tasks will need to be completed through the CLI in order to provide web access to the IPS.

Typo issues like this are very likely to appear in troubleshooting sections on the lab.


First confirm your IPS configuration is as required:

IPS# show conf

! ------------------------------

! Current configuration last modified Mon Oct 12 10:33:37 2009

! ------------------------------

! Version 6.1(3)

! Host:

! Realm Keys key1.0




! ------------------------------

! ------------------------------

service host

network-settings




host-ip 10.1.1.15/24,10.1.1.1

host-name IPS

telnet-option enabled


login-banner-text *** Access is restricted to authorized personnel only! ***

exit

! ------------------------------

service web-server

port 10433

exit

! ------------------------------

As we can see we have a couple of issues here the first is the web server port has a typo, and should be 10443 not 10433. So your web sessions to the IPS would have failed.

Hopefully you spotted that the access-list was not also as per the task requirements, as it should have accessible from the ACS Server only.

When you‟re happy that this is correct then open a web browser session to the IPS sensor from the ACS server, using the correctly defined port of 10443.




Accept the security warnings and click on the „Run IDM‟ button to start the Device Manager.

Login when requested using the credentials „cisco‟ password „proctorlabs.‟





3.2 Password Protection

Your corporate security policy states that all passwords must be at least 10 characters in length, and must contain at least one uppercase letter, one non-alphanumeric character (such as # or $), and at least two numbers. The previous 2 passwords should also be remembered. Configure the sensor to enforce this policy.

Your corporate security policy requires that accounts be locked after 5 invalid login attempts. Configure the sensor to implement this requirement.

The operations team needs read-only access to the sensor to view events. Create a new user for their use called “nocadmin” with password “NOCread123#.”

Configuration

IPS

Password policy is configured in IDM at Sensor Management > Passwords.




Invalid login attempts is also configured on the same screen in IDM as the password requirement policy. Sensor users can be configured on the Sensor Setup > Users screen in IDM.





A couple of issues here the first are password related. The attempt limit and historical password limit has been accidentally reversed. Attempt should be 5 not 2, and historical password storage should be set to 2.

The second issue, is that the nocadmin user account is missing.

This task included some simple user based security features, around role based access and password complexity requirements.

One thing to remember for role based access is that if the requirement is for the user not to make any changes then the it must use the viewer role, as the operator role does have access to tune signatures and make minor changes to configurations.


Always double check small settings like this if they are pre-configured.

Checking the user accounts section shows that the nocadmin account is missing.

Once the errors have been corrected, the password policy and user accounts can be tested by creating a test user with a non compliant password. If the password strength does not comply then the following message is displayed.




Login into the sensors cli to test the new nocadmin account. Issue a show privilege command to ensure the viewer role has been assigned.

sensor# exit

IPS login: nocadmin

Password:

***NOTICE***

This product contains cryptographic features and is subject to United States

and local country laws governing import, export, transfer and use. Delivery

of Cisco cryptographic products does not imply third-party authority to import,

export, distribute or use encryption. Importers, exporters, distributors and

users are responsible for compliance with U.S. and local country laws. By using

this product you agree to comply with applicable laws and regulations. If you

are unable to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to

[email protected].

***LICENSE NOTICE***

There is no license key installed on the IPS-4240.

The system will continue to operate with the currently installed

signature set. A valid license must be obtained in order to apply

signature updates. Please go to http://www.cisco.com/go/license

to obtain a new license or install a license.

IPS#

IPS# show privilege

Current privilege level is viewer

IPS#


3.3 Network Time Protocol

Configure R1 to act as an NTP master.

Set the time zone to EST (GMT -5) and account for daylight saving.

Configure NTP authentication with MD5 key #1 and value “ipexpert.”

Configure the sensor to sync its clock to R1 using NTP.




Configuration

IPS

NTP is configured under Sensor Setup > Time.


Checking R1 the NTP configuration looks fine and is synced to its own loopback address.

The same cannot be said for the IPS though. The timezone and summertime setting are correct but the NTP server settings are missing.

The sensor will need to be rebooted for NTP to be enabled successfully.


Under the sensor setup -> time screen confirm that you timezone, ntp server and summertime settings are as per the requirements.

Checking we find that the NTP server settings are incomplete.




Verify that the R1 is running as a master server.

R1#sh ntp ass det

127.127.1.1 configured, our_master, sane, valid, stratum 0

ref ID .LOCL., time CE59340F.8F7E9ECF (17:28:47.560 EDT Mon Sep 14 2009)

our mode active, peer mode passive, our poll intvl 16, peer poll intvl 16




org time CE59340F.8F7E9ECF (17:28:47.560 EDT Mon Sep 14 2009)

rec time CE59340F.8F7F739C (17:28:47.560 EDT Mon Sep 14 2009)

xmt time CE59340F.8F7E25EF (17:28:47.560 EDT Mon Sep 14 2009)

filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filterror = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00


Once the sensor has reloaded, login to the cli and issue the „show clock detail‟ command.

IPS# sh clock detail

.17:46:15 GMT-05:00 Mon Sep 14 2009

Time source is NTP

Summer time starts 03:00:00 GMT-05:00 Sun Mar 08 2009

Summer time stops 01:00:00 GMT-05:00 Sun Nov 01 2009

IPS#





3.4 Miscellaneous Configuration

Although telnet is an inherently insecure protocol, the NOC requires it to be enabled for management purposes. The NOC will connect to the sensor from R1. Configure the sensor to allow this.

Configure the sensor to allow SNMP management using the read-only community string “IPSro” and the read-write community string “IPSwr”. Set the system location to “IPexpert HQ” and the system contact to [email protected]. Traps should also be enabled to the ACS server using read only community.

When users log into the sensor, they should see a login banner indicating that access is restricted to authorized personnel only.

Configuration


This section is okay and requires no changes to any device.


No Verification required.


3.5 Creating Virtual Sensors


Set the description to “Inline Pair IPS monitoring for R6 and R7.”



Set the description to “VLAN Pair IPS monitoring for R8 and R9.”


Configuration

The description for vs1 is incorrect.





Ensure the description is as per the task requests, as above.


A very small but important task.

It is key to remember when taking the lab that if a task states specific instructions for naming objects, interfaces or applying descriptions, that you follow the instructions to the letter (no pun intended ). Even ensure that the case of the characters match the output required.

Verification

No Verification required.





3.6 Monitoring Traffic with IDS

Configure Cat3 and Cat4 to copy all traffic between VLAN 4 and VLAN 5 to the Gi0/0 interface on the IPS sensor. You may create VLAN 450 to complete this task.

The sensor should be able to send TCP resets to VLAN 45.

Configure interface Gi0/0 on the sensor to monitor traffic in promiscuous mode

Add this interface to virtual sensor to vs0.

Set the description to “IDS monitoring for R4 and R5.”

Enable the IP Echo Request and IP Echo Reply signatures under the default Signature Definition Policy.

Tune the above two signatures so that they produce a medium-severity alert.


Configuration

Cat2


Cat2(config-vlan)#remote-span


Cat4

no monitor session 1 source vlan 45

monitor session 1 source vlan 45 , 450

ICMP Signatures should be set to medium severity.


In this question, we must implement IDS promiscuous monitoring using remote span sessions between Cat 3 and 4, and the G0/0 interface of the appliance.




As you may quickly find out there are a few issues in this task, but nothing that can‟t quickly be resolved. Checking the requirements for Cat3 we see that although the span sessions look okay, Vlan 450 is present but not configured as a Remote-Span Vlan.


Remote SPAN VLANs

-----------------------------------------------------------------------

Cat3#

As Cat2 is the VTP server you will need to create the remote-span vlan on here.

In rectifying this though, we still have an issue, the IPS is still not inspecting any traffic, so let‟s check Cat4. Vlan 450 is there and set to remote span but an issue lies with the span session. Vlan 450 is missing as a source vlan so we won‟t be seeing any traffic originating on Cat3 to the RSPAN Vlan.

Cat4#sh run | i mon

monitor session 1 source vlan 45

monitor session 1 destination interface Fa0/15 ingress untagged vlan 45

Cat4#

Once this is done, you should now be able to see ICMP traffic across vlan 45 being detected by the IPS sensor. The last issue with this task is simply the severity of Sig 2000, which is set incorrectly to default of Informational.

You may encounter an issue where the spanning tree is blocking the trunk ports between Cat3 and Cat4, due to Cat1 becoming the Root Bridge, shutting the trunk interfaces to Cat1 will resolve this.


The command below highlights that vlan 450 has been successfully assigned to be a remote span vlan for Cat3 and Cat4.


Remote SPAN VLANs

-----------------------------------------------------------------------------

450

Cat2#

We can also check the span session configuration as per below:

Cat3#sh monitor session all

Session 1

---------

Type : Remote Source Session

Source VLANs :

Both : 45

Dest RSPAN VLAN : 450

Cat3#




Cat4#sh mon ses all

Session 1

---------

Type : Local Session

Source VLANs :

Both : 45,450

Destination Ports : Fa0/15

Encapsulation : Native

Ingress : Enabled, default VLAN = 45

Ingress encap : Untagged

Cat4#

Cat4‟s F0/15 interface should now be showing as being in a promiscuous monitoring state:

Cat4#sh int f0/15

FastEthernet0/15 is up, line protocol is down (monitoring)

Hardware is Fast Ethernet, address is 001b.d4c8.0a91 (bia 001b.d4c8.0a91)

MTU 1508 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

As requested in the task use, icmp ping to verify that alerts are generated in the IDM event viewer.

Do this by pinging across vlan 45 from R5 to R4 (or vice versa).

R5#ping 192.1.45.4



!!!!!


R5#

You should then see alerts appear in the event viewer for both the echo and reply. Note that the severity is equal to medium.





3.7 Monitoring Traffic with an IPS Inline Interface Pair

Create a new inline interface on the sensor called INLINE67.


Add the ge0/1 and ge0/2 interfaces.

R7 should belong to VLAN 670.




Configuration

Cat4



R7


R7(config-subif)#encapsulation dot1Q 670


IPS

Ensure you enable the interfaces.





This task moves us into troubleshooting the the first of our virtual sensors, and utilizing the inline IPS functionality of the appliance. First, we need to ensure that Vlan 670 has been created and that Cat4 F0/16 & 17 has been assigned their respective access vlans. F0/16 is correctly assigned to vlan 67 but so is F0/17, meaning the IPS is not actually functioning as an inline device at this point. Interface F0/17 needs to become an access port in Vlan 670.




!




end

Cat4#

Checking the status of the interfaces also shows that F0/17 is in a down state but is not shutdown on the switch.

Cat4#sh int f0/17

FastEthernet0/17 is down, line protocol is down (notconnect)

Hardware is Fast Ethernet, address is 0018.b996.0b13 (bia

0018.b996.0b13)

Check the interface configuration screens in IDM, shows the interface G0/2 has not yet been enabled.

Communication between R6 and R7 will still be failing at this point though, due to the configuration of R7‟s F0/1.67 interface. Looking closely we see that it should belong in vlan 670 not 67.




To verify that Pings are successful between R6 & R7 you will need to temporarily disable the ICMP signatures, as the later task has set a high severity that causes the packet to be dropped.


The IPS sensor in Inline mode transparently bridges traffic between VLANs 67 and 670 allowing traffic to pass.

Double check that the correct vlans are now being trunked to R7 and that R7‟s Vlan 67 interface is reconfigured accordingly.







!


description R7 F0/1


switchport trunk allowed vlan 7,670


end




!



ip address 192.1.67.7 255.255.255.0



end

A good sign that things are configured correctly will appear once the interfaces are enabled on the IPS, as the EIGRP adjacency will re-establish between R6 and R7.

R7#

*Sep 16 21:18:46.528: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.1.67.6

(FastEthernet0/1.67) is up: new adjacency

As per the task requirements, verify that alerts are generated by pinging across the IPS interface pair.

R7#ping 192.1.67.6



!!!!!


R7#




Note that the alert is informational as per the default setting, the interface it was received on and that the interfacegroup shows the correct virtual sensor, in this case vs1.


3.8 Monitoring Traffic with an IPS Inline VLAN Pair

Configure the port on Cat4 connecting to the sensor‟s ge0/3 interface to be a dot1q trunk.

Configure this trunk port to only permit VLANs 89 and 890.

Create a new sub-interface on the sensor‟s ge0/3 interface. Use sub-interface #89.





Configuration

Cat4


Cat4(config-if)#sw trunk allow vlan 89,890

Cat4(config-if)#exit

IPS

The Virtual Sensor should be configured with the vs2 policy objects.





This section included the secondary method for Inline IPS configuration using Vlan Pairs.

To bring the IPS inline between R8 & R9 we need to once again create another vlan to use on R9‟s side of the IPS and reconfigure Cat4 interfaces F0/9 & F0/18, and R9‟s F0/1.89 to utilize the newly created vlan 890.

A couple of problems have been introduced here; the first is more cosmetic in nature. The trunk port on Cat4 (F0/18) has not had the vlans pruned as requested. Use the switchport trunk allowed vlan command to ensure that only vlans 89 & 890 are active on the trunk to the IPS.

Our next problem could potentially cause us a few headaches. The signature definitions for the virtual sensor has been left configured as sig0 instead of sig2. The problem here is that it may not have been detected unless looking carefully at either the vs configuration or the alerts. As we have already configured icmp alerts in sig0, it could have been wrongly assumed that the task requirements were complete. We would definitely see issues later on in the lab, if configuring sig2 as those alerts would not have been generated.


The above screenshot shows the incorrect assignment of the default definitions sig0, to vs2. The policy objects sig2, rules2 and ad2 should be assigned and used with vs2.

Confirm that the IPS has successfully been placed between R8 and R9 and that communication is working.

R8#ping 192.1.89.9



!!!!!


R8#




Check that the event has been triggered on the IDM, noting that the events show up under virtual sensor vs2.


3.9 Tuning Signatures & Variables

For each of the Virtual Sensors, make sure that the networks behind the ASA are viewed with the highest priority.

In the previous sections you tuned the signatures for ICMP Pings. For traffic between VLAN 6 and VLAN 7 only, tune the Echo Request signature to generate a high-severity event, and for Echo Replies to not generate an event at all.

Configure an existing signature that will fire a high severity alert when ICMP packets with a size of between 8000-50000 bytes, are detected between R8 & R9. Drop the packet inline. The alert should fire every fourth event, and be summarized every fifth event.

Configure the sensor to block traffic between R7 and R8 if it detects the Code Red Worm traffic hitting a web server on VLAN 8. For the purpose of this task, consider URLs containing any of the following, to be Code Red traffic: “cmd.exe” “default.ida” or “root.exe.” This task should account for the URL‟s using any case. Send an SNMP trap when this event is generated.

Configure the sensor to alert when it detects a file being deleted on the FTP server at 10.4.4.100 from Vlan 5. A low-priority IPS event should also be logged.

A custom TCP application is running in Vlan 5 on port 40004. This application should only be accessed from Vlan 7. An SNMP trap should be sent to the ACS Server in Vlan 10 if this traffic is detected being sourced from any other location. Standard severity and Risk Ratings should be used. Do not use IP or IP ranges for defining Vlan 7 when configuring this task.




Configuration

IPS

Tuning signatures on a per-interface basis is easy when the interfaces in question belong to different virtual sensors. This allows each interface to be governed by a different detection/prevention policy. Large ICMP

So looking through the available ICMP signatures in vs2‟s signature definitions we see that Large ICMP Sig 2151, seems a perfect fit for our requirements. Here we set the IP Payload Length to the specified range of 8000-50000.




Scrolling down the edit signature window, we modify the event count to 4 and enable the signature. Code Red

Here we used the custom signature, sig 60000 within vs1. Ensure the required actions and the service port of 80 for http are set and the regex string to match on is added. [Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][Tt]\.[Ii][Dd][Aa]|[Rr][Oo][Oo][Tt]\.[Ee][Xx][Ee]


Target Values

The target value ratings section is fine, and requires no changes.

ICMP Tuning

Nothing needs resolving here either, so far so good.

Large ICMP

The third sub task sees us utilizing the existing Large ICMP signature. And this is where we start to encounter a few issues.

There are two issues with this task. Both are located in the signature definition for the sig2151. The layer 4 protocol field is incorrect, as the Total length of the ICMP packet has been specified to 8000. As the task requires us to match on any ICMP packet with size of 8000 bytes or greater the correct method is to specify the IP Payload Length in range format.




The second problem is the event count value has been left at its default of 1. This should be set to 4 as specified in the task. See below screenshot.

Should look like the shot below:

The final little gotcha here is remembering that we are matching on the IP PAYLOAD Length, so when pinging across the IPS to trigger the event remember to include the IP header length of 20 in the byte size. So the minimum size would be 8020.

Code Red

This task call for a custom string based signature using a regex string to match on the required URL contents. As we are required to match on any case for the urls we need to enclose each characters upper and lower case form within square brackets. i.e. [Aa]. We also need to include the pipe „|‟ between each of the three defined strings. This does make the string quite long and introduces the possibility for mistakes. Which is exactly where we have introduced an error for this task. The regex string is incorrect we have a close square bracket „]‟ missing from the L in default and an OR pipe „|‟ missing between ida & root.

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll[Tt]\.[Ii][Dd][Aa]

[Rr][Oo][Oo][Tt]\.[Ee][Xx][Ee]




Just in case you didn‟t spot it, the signature is also disabled.

To save time troubleshooting the regex side test the string on the ASA prior to creating the signature.

** When testing this signature ensure that the HTTP server is enabled on R8.

FTP

All is fine here.


No problems here either.


Large ICMP

Ping from R8 to R9 to test the large ICMP signature fires as required.




!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


R8#

Whoa! What‟s going on? It‟s not working! The ping is succeeding and I have no alerts in the IDM!

Remember, you have used the IP payload length setting which means we need to add 20 bytes to the packet size for the IP header.







!!!..!!.!.!.!!..!!!..!!.!.!.!!..!!!..!!.!.!.!!..!!


R8#

That‟s better!

As we can see the alert is successfully fired, as is the summary.




Code Red

When using regular expressions I find it easier to first test my regex string on the ASA to confirm they are correct.

ASA# test regex cMd.Exe

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][Tt$


ASA# test regex c.Exe

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][Tt]\$

INFO: Regular expression match failed.

ASA# test regex rOOt.Exe

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll][T$


ASA# test regex default.ida

[Cc][Mm][Dd]\.[Ee][Xx][Ee]|[Dd][Ee][Ff][Aa][Uu][Ll$


So, from R7 do a simple http copy to verify the sig is working. The first copy is an example of a non-IPS blocked test.

R7#copy http://192.1.24.8/test null0


%Error opening http://192.1.24.8/test (No such file or directory)

R7#

R7#copy http://192.1.24.8/cmd.exe null0


%Error opening http://192.1.24.8/cmd.exe (I/O error)

R7#

R7#copy http://192.1.24.8/rOoT.exe null0


%Error opening http://192.1.24.8/rOoT.exe (I/O error)

R7#

R7#

R7#copy http://192.1.24.8/defAUlt.IDA null0


%Error opening http://192.1.24.8/defAUlt.IDA (I/O error)

R7#




The alert is created in the IDM, the flow is denied and an Snmp trap is sent to the ACS.

This is the SNMP trap received by the ACS.





3.10 Advanced IPS & Anomaly Detection

Due to potential asymmetric traffic flows for VLAN 5 disable AD for Sensor vs0, and set the Normalizer mode accordingly.

AD for Virtual Sensor 2 should be set to learning mode, the learning period should be 72 hours. The learning action should be so that after the learning period the new Knowledge Base is saved and loaded, replacing the initial KB.

Ensure that Vlan 6 and 8 are seen as the Internal networks in their respective AD policies.

You have some unallocated dark ip that will eventually be reachable via R6, 10.16.16.0/24, 10.66.66.0/24 & 10.166.166.0/24, these subnets should not be present in any traffic flows and should be handled accordingly. The scanner thresholds should be reduced to 100 for both TCP and UDP.

In vs1 restrict the OS fingerprinting to the 10.0.0.0/8 network. Add two mappings one for the ACS server, so it is always seen as type WinNT, and one for a Linux Server called RedHat1 with an ip of 10.7.7.100.

Configuration

This section has no notable problems so we progress to the next task.


Moving On



3.11 Blocking using the Security Appliance

A host on VLAN 5 is carrying out an access attack on R1 using telnet with a username of „Admin.‟

Make sure this attack is detected as high severity, and the triggered event contains as much information as possible.

When the event is triggered the IPS should connect to the ASA using SSH and perform a shun.

Use the ASA local database for authentication with user „IPS_Admin‟ and password „ipexpert.‟ Enable password should also be „ipexpert.‟

Configuration

ASA

router rip

redistribute eigrp 100 metric 1

No failover




IPS

Enable Blocking globally on the IPS.

The host keys for the ASA are missing, use the the Sensor Management > SSH > Known Host Keys to add the ASA‟s SSH keys.

Ensure that the passwords are configured in the ASA‟s Device Login Profile.





This task focuses on Host blocking or shunning using the ASA.

The signature itself for this task is configured correctly but there are a few issues to rectify. For starters, blocking is disabled globally, so we need to enable that under the Blocking Properties screen.

For the Host Blocking to work correctly we also need the RSA keys of the ASA and a valid login profile. As there are no host keys present we need to retrieve the ASA‟s keys as per the configuration above. Finally, we see that although we have a login profile for the ASA, it is incomplete. The user and enable passwords are missing, so these need edding also.

Depending on the success of the pre-staging of the lab configs, you may encounter routing issues on the ASA. Failover is enabled but not configured correctly or sync‟d, this will cause EIGRP not to form its neighbor adjacencies, so will need to be disabled. You may also need to redistribute eigrp routes into rip.


Confirm rsa keys are present on the ASA. If not you will need to create them with: „crypto key generate rsa modulus 1024‟

ASA# sh crypto key mypubkey rsa


Key name: <Default-RSA-Key>



Key Data:

30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00cef145

29a87a61 5b917614 5d680627 40862d58 bb06013f 832ba983 1fc7befc ca7f0916

a8feda09 ec0b8304 0c22e369 5d93fada b588d0ca 3b4cda1b 8ee5315d 0df412e3

e9ec337b 8344272b dbccf3f3 054b2720 50d8f64d e5247c72 da0058e0 c05a246d

03facae3 3cf704c6 195494dc 8fe8637b 22733935 05c71b0e ae4ab751 23020301

0001


Key name: <Default-RSA-Key>.server



Key Data:

307c300d 06092a86 4886f70d 01010105 00036b00 30680261 00960150 f09b948e

d4ff4c9a b58619a7 b0930038 6746b639 4bbb22ac 2cdd058c adda0459 b9bb2aa0

30b85222 46bc312d f367ccce 6c9e9cce 2969a1c1 141013b2 4aa163a4 898abbd0

17d86d54 c319cd5f 8e4aa4dc dea1e72d 06ffdcc0 aafd93fc 69020301 0001

ASA#

Telnet to R1 from R5, and type Admin.




R5#telnet 10.2.2.1 /source-interface f0/1.5



Password:

R1>

R1>

R1>Admin

The connection should hang due to being shunned by the ASA.

ASA# sh shun

shun (outside) 10.5.5.5 0.0.0.0 0 0 0

ASA#

Check the event has been fired and that it has verbose output, and shunRequested true.

From the Monitoring tab, navigate to Time Based Actions > Host Blocks to see the host address entries currently blocked by the IPS. Use the delete button to clear the block.





3.12 Blocking using IOS Devices

FTP & HTTP traffic is required to be inspected on vs1.

If malicious traffic is tunneled through HTTP from Vlan 4 to Vlan 7 a block should placed on R6‟s f0/1.24 interface, and all the traffic should be logged.

Use SSH to connect to R6 from the IPS.

R6 should have a local user „R6Admin‟ with password „ipexpert.‟

Configuration

IPS

From sig1 > All Signatures click the Advanced button at the bottom of the page. Enable the AIC Engine for FTP and HTTP Inspection.

Retrieve R6‟s RSA keys.




Add the login profile passwords for R6. R6

R6(config)#cry key gen rsa g m 1024




R6(config)#


no ip access-group ACL1 out


This task moves us to blocking using an IOS router, where the IPS creates an ACL and applies it to the specified interface.

The task here once again has some minor problems. The signature uses the HTTP AIC engine so we need to ensure that HTTP Inspection is enabled under vs1‟s advanced options.

Similar to the previous task, there are issues with both the host key being missing from R6, as well as the passwords need adding to R6‟s login profile. We need to generate the rsa keys on R6 before we can import them.

One issue still remains. The HTTP traffic is not able to reach R7, thus no alerts are being generated. It‟s mainly due to this nasty little access list that is applied outbound on R6‟s F0/1.67 interface. Removing the access-group from the interface should resolve all issues for this task.

R6#sh access-list

Extended IP access list ACL1

10 deny tcp any any eq www

20 permit ip any any





Test SSH Login to R6.

R7#ssh -l R6Admin 192.1.67.6

Password:

R6>en

Password:

R6#

Test by connecting via telnet to the HTTP server on R7.


Trying 10.7.7.7, 80 ... Open

jkhg


Date: Wed, 23 Sep 2009 19:07:45 GMT

Server: cisco-IOS

Accept-Ranges: none

400 Bad Request


R4#




The non-http alert is created.

On R6 we can see that the IPS has logged in a made changes to the configuration.

A new ACL has been created and applied to the selected interface. Not that the first entry in the ACL is a permit any for the Sensor.

*Sep 23 19:05:29.010: %SYS-5-CONFIG_I: Configured from console by R6Admin on

vty0 (10.1.1.15)




!



ip address 192.1.24.6 255.255.255.0

ip access-group IDS_fastethernet0/1.24_in_1 in



end

R6#sh access-list



20 deny tcp host 10.4.4.4 host 10.7.7.7 eq www


R6#

We can see from the Host Blocks screen that a block is in place for R4 to R7 on port 80.

Subsequent connections on port 80 from R4 are blocked by the ACL.


Trying 10.7.7.7, 80 ...


R4#

R6#sh access-list



20 deny tcp host 10.4.4.4 host 10.7.7.7 eq www (1 match)


R6#




Final verification is to check that the IP logging is taking place. This is done by navigating to IP Logging secion within Sensor Monitoring. These logs can be downloaded for viewing in capture utilities such as Wireshark.


3.13 Rate Limiting

An ICMP Flood is being generated by multiple hosts on Vlan 6 destined for Vlan 9.

Tune an existing signature in vs2 to place a rate limit on R8‟s F0/1.24 interface.

Login to R8 using Telnet and the local user „R8Admin‟ password „ipexpert.‟

The rate limit should be set to 2% when more than 25 pings occur within a 1 second period.

Configuration

R8


IPS

Login password should be cisco as this is already configured on the Line of R8, with an enable of ipexpert.




We need to enable rate limiting by creating a Router Blocking Interface for R8.


The final troubleshooting task for the IPS appliance in this lab is to repair a rate-limit configuration to an IOS device. Again, all issues are present on the IPS sensor.

Checking the Login Profile would be a great start due to the issues with the previous tasks, and what do you know, the passwords are missing here also. R8 is using telnet, and as we already have a line password configured we‟ll use that along with the enable password to complete the profile.

Finally, how would we apply a rate limit if we have no interface to apply it to? Create the new blocking interface for R8, under Router Blocking Device Interfaces, while ensuring you use the f0/1.24 interface in an inbound direction.


Ensure you can access R8 using telnet.

R9#telnet 192.1.89.8

Trying 192.1.89.8 ... Open


Password:

R8>en

Password:

R8#

R8#exit


R9#

Ping Vlan 9 interface on R9 from Vlan 6.

R6#ping 10.9.9.9 source f0/1.6 size 5000 rep 300




!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!

!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!

!!!!!!.!!!!!!!!!!!!!


R6#




The IPS logs into R8 and applies the Rate limit to R8, to the specified interface.

R8#

*Sep 23 19:48:25.166: %SYS-5-CONFIG_I: Configured from console by vty0

(10.1.1.15)

R8#




!



ip address 192.1.24.8 255.255.255.0




end

R8#

As you can see, a service policy is used for rate limiting, so you can check the statistics output for the interface.

R8#sh policy-map interface

FastEthernet0/1.24

Service-policy input: IDS_RL_POLICY_MAP_1

Class-map: IDS_RL_CLASS_MAP_icmp-xxBx-8-2_1 (match-any)



Match: access-group name IDS_RL_ACL_icmp-xxBx-8-2_1


5 minute rate 41000 bps

police:

cir 2 %


conformed 1038 packets, 1364124 bytes; actions:

transmit

exceeded 12 packets, 16776 bytes; actions:

drop





Match: any

R8#




Check that the event has been correctly fired on the IPS.

You should also have an entry for rate limit under the Sensor Monitoring > Rate Limits section.

End Verification

3.14 ASA IPS

Configure the ASA to enable the IPS feature set on both interfaces.

Informational and Attack signatures defaults should be set to alarm.

Attack signatures should be set to drop and close the connection on the outside.

Disable the ICMP Echo & Echo Reply signatures.

You are receiving a large number false positive alerts, tune the following signatures to prevent these alerts:

Timestamp Options RPC proxy Calls to the Remote Execution Daemon

Configuration

Nothing wrong here, so we move on.





3.15 IOS IPS Setup

Configure R1 to enable the IPS feature set inbound on vlan 10 and 20 interfaces.

The IPS v5 signature package is contained in the path: flash:/IOS-Sxxx-CLI.pkg.

Be sure to follow the documented prerequisites.

Once completed enable ICMP Echo Request signature and ensure that the IPS is monitoring successfully.

Configuration

R1

Create an rsa key pair.

R1(config)#cry key gen rsa gen mod 1024




R1(config)#

Sep 24 18:04:21.874: %SSH-5-ENABLED: SSH 1.99 has been enabled

Verify the IPS version running in IOS (Version 3.xxx.xxx denotes IPS version 5).

R1#show subsys name ips

Name Class Version

ips Protocol 3.001.002

R1#

Retire all signature catrgories:


R1(config-ips-category)#category all

R1(config-ips-category-action)#retired true

R1(config-ips-category-action)#exit

R1(config-ips-category)#exit


R1(config)#


R1(config)#

Un-retire the ios basic signature category:


R1(config-ips-category)#category ios_ips basic




R1#



R1#wr


[OK]

R1#




Make a new directory in flash for the IPS files.

R1#mkdir flash:/ips5

Create directory filename [ips5]?

Created dir flash:/ips5

R1#

R1#dir

Directory of flash:/

1 -rw- 58246016 Oct 11 2008 13:20:50 -04:00 c2800nm-

adventerprisek9-mz.124-22.T.bin

2 -rw- 33730764 Oct 7 2005 13:08:52 -04:00 c2800nm-

adventerprisek9-mz.124-3a.bin

3 -rw- 7187712 Jan 26 2009 11:01:50 -05:00 IOS-S376-CLI.pkg

4 drw- 0 Sep 24 2009 14:34:56 -04:00 ips5

255565824 bytes total (156389376 bytes free)

R1#

Configure IPS on R1, applying it inbound on both Fa0/1.10 & Fa0/1.20.

R1#cc




R1(config-subif)#int f0/1.20


Sep 24 18:42:10.038: %IPS-6-ENGINE_BUILDING: atomic-ip - 3 signatures - 1 of

13 engines






R1#wr


[OK]

R1#

Load the signature file in flash into the IPS.

R1#copy flash:IOS-S376-CLI.pkg idconf



of 13 engines




2 of 13 engines




of 13 engines




of 13 engines







engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines

Sep 24 18:55:00.877: %IPS-6-ENGINE_READY: service-smb-advanced - build time

52 ms - packets for this engine will be scanned

Sep 24 18:55:00.877: %IPS-6-ENGINE_BUILDING: service-msrpc - 29 signatures -

13 of 13 engines




R1#

Enable and un-retire the ICMP Echo Request signature 2004.

R1#conf t




R1(config-sigdef-sig)#status



R1(config-sigdef-sig-status)#end


R1#



of 13 engines





R1#wr


[OK]

R1#





Bad news here, I‟m afraid. Someone has accidently deleted the ips directory from flash that stored all the configuration and signature files, meaning we‟re going to have to reconfigure the IOS IPS.

Some of the configuration is still intact so these stages can be omitted.

The pre-requisites in the config guide link below need to be followed for deploying IPS Feature set on an IOS Router.


Although this may seem like a simple task on the surface, the ips behavior in IOS has changed dramatically in the version 5 format. I would recommend following this config guide when you deploy IOS IPS v5, just to ensure things go smoothly.

The pre-requisites start with creating an rsa key pair on R1 and installing the public key to enable the signature package to be decrypted. This public key is found at the beginning of the guide above.

The next step is critical to ensuring this task is successful, all signatures must be retired prior to enabling the IPS. If you do not retire all the sigs, theres is a large probability that your device will run out of resources and die, due to the large amount of signatures it will have to compile. If this happens your going to be in a world of hurt trying to regain access your device.

Once you have retired all the categories un-retire a small subset of signatures, we have followed the guide and enabled the ios basic category.

We are then safe to enable the IPS feature set on the device. To enable the IPS we need to define a policy, giving it a name, and a stored config location in flash. Once this is done apply the policy to your interface/s.

The final stage to enabling the IPS is the loading and compiling of the signatures.

Use the „copy flash:/IOS-Sxxx-CLI.pkg idconf‟ command to load the signature package from flash into the IPS, and compile all the non-retired signatures. This can take some time depending on how many signatures/categories are enabled.

All that‟s left is to start tuning any required signatures. The task asks for ICMP Echo Request signature to be enabled, the ID is the same as on the IPS appliance so is sig id 2004. Just remember when doing the task to ensure that the signature is both in an enabled state of true and a retired state of false.

Note: The issue with IOS IPS is that the configuration is mainly stored in files within flash not the running config. So if loading the final configs, be aware that without these files and directory, you will not see a functioning pre-configured IPS feature on R1. These files are not installed as part of the load configs pre staging.


Once you are happy that the IOS IPS is configured, verify your config using the following:











Last event action (SEAP) load time: -none-














IPS name MYIPS











Category all:

Retire: True


Retire: False

R1#

Checking the IPS signature count will show you what categories are enabled, compiled or retired:

R1#sh ip ips signature count

Cisco SDF release version S376.0

Trend SDF release version V0.0

Signature Micro-Engine: multi-string: Total Signatures 12

multi-string enabled signatures: 10

multi-string retired signatures: 12

Signature Micro-Engine: service-http: Total Signatures 667

service-http enabled signatures: 164




service-http retired signatures: 570

service-http compiled signatures: 97

service-http obsoleted signatures: 2


Signature Micro-Engine: atomic-ip: Total Signatures 307

atomic-ip enabled signatures: 100

atomic-ip retired signatures: 285

atomic-ip compiled signatures: 22

Total Signatures: 2506

Total Enabled Signatures: 1117

Total Retired Signatures: 2167

Total Compiled Signatures: 339

Total Obsoleted Signatures: 25

R1#

Note: The signature counts maybe different with older or newer versions of the signature packages.

The „show ip ips signature sigid‟ gives you detailed information about the signatures. Note from the output below that in this instance the sig2004 was successfully enabled, but the compiled state is „Nr‟ or not compiled due to sig being retired. If the signature is not compiled, it is not yet in use, so will not generate any alarms. As you can see this gives some handy info regarding what each column is related to.


En - possible values are Y, Y*, N, or N*

Y: signature is enabled

N: enabled=false in the signature definition file

*: retired=true in the signature definition file

Cmp - possible values are Y, Ni, Nr, Nf, or No

Y: signature is compiled

Ni: signature not compiled due to invalid or missing parameters

Nr: signature not compiled because it is retired

Nf: signature compile failed

No: signature is obsoleted

Action=(A)lert, (D)eny, (R)eset, Deny-(H)ost, Deny-(F)low

Trait=alert-traits EC=event-count AI=alert-interval

GST=global-summary-threshold SI=summary-interval SM=summary-mode

SW=swap-attacker-victim SFR=sig-fidelity-rating Rel=release


----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---

2004:0 Y* Nr A INFO 0 1 0 200 30 FA N 100 S1

Here is the output for a successfully enabled Echo request signature, both enabled and compiled:




----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---

2004:0 Y Y A INFO 0 1 0 200 30 FA N 100 S1

sig-name: ICMP Echo Request




Confirm that R1‟s IPS is now functioning as expected by pinging the ACS from R4.

R4#ping 10.1.1.100 repeat 100



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


R4#

R1#

















peak queue length 0

R1#

Everything looks happy!!!


3.16 IOS IPS Tuning

Set the event notification method to syslog.

Create the ACS as a mission critical device.

Configure Sig ID 2150 to drop and alarm on receipt of the fragmented icmp traffic.

Enable the ICMP Flood category.

Configuration

R1

Unfortunately, due to the directory removal we will need to configure this task in its entirety.

Configure event notifications using syslog.




R1(config)#ip ips notify log

Configure the IPS so that it see the ACS Server as a mission critical device:

R1(config)#ip ips event-action-rules

R1(config-rul)#target-value mission-critical target-address

10.1.1.100

R1(config-rul)#end


R1#

Configure signature 2150 to drop and alarm:





R1(config-sigdef-sig-status)#exit

R1(config-sigdef-sig)#engine

R1(config-sigdef-sig-engine)#event-action produce-alert deny-packet-

inline

R1(config-sigdef-sig-engine)#end


R1#

Sep 24 21:38:47.626: %IPS-6-ENGINE_BUILDS_STARTED: 17:38:47 EDT Sep

24 2009

Sep 24 21:38:47.986: %IPS-6-ENGINE_BUILDING: atomic-ip - 307

signatures - 1 of 13 engines

Sep 24 21:38:48.650: %IPS-6-ENGINE_READY: atomic-ip - build time 664

ms - packets for this engine will be scanned

Sep 24 21:38:48.990: %IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time

1364 ms

Sep 24 21:38:49.394: %SYS-5-CONFIG_I: Configured from console by

console

R1#

Enable the ICMP Flood Category:


R1(config-ips-category)#category dos icmp_floods


R1(config-ips-category-action)#enabled true



Sep 24 21:56:10.019: Applying Category configuration to signatures ...



of 13 engines




2 of 13 engines



R1#


of 13 engines







of 13 engines




engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines




of 13 engines





R1#


We finish off this lab with tuning the signatures on the IOS IPS. Due to the shear amount of signatures available to the new v5 IPS it‟s now a little more difficult to search for signature types, etc. The documentation also seems a little light in detail, so be prepared for some digging around. To save a little time you might do a quick search on the IPS Sensor, if you are having a hard time finding a particular signature, etc.

Some of the features available on the sensor are also now available in IOS, although behavior does not seem entirely consistent between the two. For instance, here we use the Event action rules, target value rating to classify the ACS with mission critical priority.

We also need to enable the ICMP Fragmented traffic signature and apply a drop action to the traffic, it wasn‟t specified but we chose to use deny packet inline. Remember to include the produce-alert in the event action, or it will be removed.

Finally we enable another signature category. ICMP Floods is located under the dos category and needs setting to both enabled true and retired false.

Don‟t forget that a lot of these sigs will have been retired, so remember to check their state, once configured.





Check the status of your configuration on R1.






Last event action (SEAP) load time: 17:07:53 EDT Sep 24 2009














IPS name MYIPS











Category all:

Retire: True


Retire: False


Retire: False

Enable: True

R1#

Verify the addition of the target value rating for the ACS Server.

R1#sh ip ips event-action-rules target-value-rating

Target Value Ratings

Target Value Setting IP range

mission-critical 10.1.1.100-10.1.1.100

R1#




Confirm that the ICMP Fragment signature is configured as expected, and that the alarms are fired, after pinging from the ACS Server.

R1(config)#do sh ip ips sig sig 2150 sub 0



----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---

2150:0 Y Y AD INFO 0 1 0 200 30 FA N 100 S2

sig-name: Fragmented ICMP Traffic

sig-string-info: My Sig Info

sig-comment: Sig Comment

Engine atomic-ip params:

regex-string :

address-with-localhost :

dst-ip-addr :

dst-port :

exact-match-offset :

fragment-status : want-fragments

R1#

Sep 24 22:26:33.023: %IPS-4-SIGNATURE: Sig:2150 Subsig:0 Sev:25 Fragmented ICMP

Traffic [10.1.1.100:0 -> 192.1.24.4:0] VRF:NONE RiskRating:25

Sep 24 22:26:38.479: %IPS-4-SIGNATURE: Sig:2150 Subsig:0 Sev:25 Fragmented ICMP

Traffic [10.1.1.100:8 -> 192.1.24.4:0] VRF:NONE RiskRating:25

Sep 24 22:26:38.479: %IPS-4-SIGNATURE: Sig:2004 Subsig:0 Sev:25 ICMP Echo Request

[10.1.1.100:8 -> 192.1.24.4:0] VRF:NONE RiskRating:25














peak queue length 0

R1#




R1#sh ip ips category dos icmp_floods config


Retire: False

Enable: True

R1#















Lab 4A: Configure Cisco VPN Solutions






4.0 Virtual Private Networks Configuration Detailed Solutions

Lab 4A Detailed Solutions – Part I

4.1 IOS CA

Make R2 start acting as IOS CA.

Use key-pair IOS_CA for that purpose.

Make sure CA key can be further archived.

Automatically rollover Root Certificate 30 days prior to expiration.

Certificates should be granted automatically.

Non-SCEP CRL requests should use R2 as CDP Server.

Configure R2 as a NTP Server.

Synchronize R5 and R6 with the NTP Server.

R2, R5 and R6 should be in time zone GMT+1.

Use the domain name of ipexpert.com.

Configuration

R2, R5, R6

clock timezone GMT+1 +1


R2

Configure the time on R2 to be the same as on Test PC.

clock …

ntp master 2

cry key gen rsa label IOS_CA exportable

crypto pki server IOS_CA

database archive pem password ipexpert

grant auto

cdp-url http://8.9.50.2/cgi-bin/pkiclient.exe?operation=GetCRL

auto-rollover

ip http server

R5, R6

ntp server 8.9.50.2


NTP configuration should be performed as soon as possible. This is because it may take some significant amount of time for the devices to synchronize. Keep in mind that usually it is a good




idea to set the same time zone on all the devices (unless stated otherwise). If in doubt, go ahead and ask the proctor for clarification.

To force IOS to use the specific RSA Key Pair for IOS CA give it a name which is exactly the same as the Key Pair label. The other solution would be to create IOS CA but without issuing “no shut” command and then moving to the CA‟s trustpoint which has been automatically created. There we could assign an arbitrary Key Pair. Note that so CA‟s Key Pair could be archived, keys have to be marked as “exportable.”

CRL syntax for IOS CA can be found here : CRL

Note that after 12.3(11)T, when the certificate server is turned on the first time, the CA certificate and CA key will be generated. It will be marked as “noexportable,” however If automatic archive is also enabled (and by default it is) the CA certificate and the CA key will be exported (archived) to the server database. The archive can be in PKCS12 or privacy-enhanced mail (PEM) format. The default file storage location is flash.

Auto-Rollover feature allows certificates that are about to expire to be reissued automatically. When the CA certificate is expiring it must generate a new certificate and possibly a new key pair. This allows for continuous operation of the network while clients and the certificate server are switching from an expiring CA certificate to a new CA certificate. To use this feature, CA certificate and key archive format and password has to be specified.

One important thing I did not mention before is that to start IOS CA service, HTTP server has to be enabled.

Verification

We can test if IOS CA and NTP are working with commands shown below:




reference time is CE9BBDCF.8E396F19 (09:46:07.555 GMT+1 Wed Nov 4 2009)




s/s


R2(config)#do sh cry pki ser

Certificate Server IOS_CA:

Status: enabled

State: enabled

Server's configuration is locked (enter "shut" to unlock it)

Issuer name: CN=IOS_CA

CA cert fingerprint: 69A69682 7CCC611F 3C0E3C07 F31A7BA9

Granting mode is: auto

Last certificate issued serial number (hex): 1

CA certificate expiration timer: 09:35:19 GMT+1 Nov 3 2012

CRL NextUpdate timer: 15:35:26 GMT+1 Nov 4 2009

Current primary storage dir: nvram:

Database Level: Minimum - no cert data written to storage

Auto-Rollover configured, overlap period 30 days

Autorollover timer: 09:35:19 GMT+1 Oct 4 2012

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_mng_cert_serv_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1193861




R2(config)#do sh cry key my rsa

% Key pair was generated at: 09:27:29 GMT+1 Nov 4 2009

Key name: IOS_CA

Storage Device: not specified


Key is exportable.

Key Data:

-- Output omitted --

R2#sh cry pki tru status

Trustpoint IOS_CA:

Issuing CA certificate configured:

Subject Name:

cn=IOS_CA

Fingerprint MD5: 69A69682 7CCC611F 3C0E3C07 F31A7BA9

Fingerprint SHA1: 8AC4CA41 4487EEBF A4819EBA 45543480 AB983F19

State:

Keys generated ............. Yes (General Purpose, exportable)

Issuing CA authenticated ....... Yes

Certificate request(s) ..... None




reference time is CE9BBEA4.7C23CCAA (09:49:40.484 GMT+1 Wed Nov 4 2009)








reference time is CE9BBC73.033C9FDB (09:40:19.012 GMT+1 Wed Nov 4 2009)




system poll interval is 64, last update was 69 sec ago.Sending 5, 100-byte

ICMP Echos to 192.1.24.4, timeout is 2 seconds:

!!!!!


End Verification




4.2 IOS L2L

Configure Site-to-Site VPN between R5 and R6. Secure traffic between VLANs 5 and 6.

Use digital certificates as the authentication method.

For Phase I use AES 128 encryption and SHA-1 hash algo.

Phase II should use 3DES and MD-5.

Enroll for identity certificate on R5 and R6 using CN set to their respective FQDNs.

Use OU value of CCIE and set country to PL.

Set revocation check to CRL on R5 and R6.

Make sure R5‟s identity certificate is excluded from CRL validation on R6.

You are not allowed to use static routes, policy routing, or any routing protocols for this task.

Configuration

R5

crypto pki trustpoint CA

enrollment url http://8.9.50.2:80

subject-name cn=R5.ipexpert.com, ou=CCIE, c=PL

revocation-check crl

crypto isakmp policy 20

encr aes

crypto ipsec transform-set SET2 esp-3des esp-md5-hmac

access-list 120 permit ip 10.5.5.0 0.0.0.255 10.6.6.0 0.0.0.255

crypto map MAP1 10 ipsec-isakmp

set peer 8.9.50.6

set transform-set SET2

match address 120

reverse-route static

int s0/1/0

crypto map MAP1

R6

crypto pki certificate map CER_MAP 10

subject-name co cn = r5.ipexpert.com



subject-name cn=R6.ipexpert.com, ou=CCIE, c=PL


match certificate CER_MAP skip revocation-check


encr aes







set peer 8.9.50.5


match address 120


int s0/1/0

crypto map MAP1

R5, R6

cry pki authe CA

cry pki enro CA


VPN tunnel establishment consists of two phases – IKE Phase I where the “management” connection is established and IKE Phase II which is “data” connection. Phase I is required to protect Phase II information, so the encryption and authentication keys for the data connection can be exchanged securely. This connection uses UDP on port 500 and is bidirectional which means that traffic flowing in both directions uses the same socket. Three things always occur in during ISAKMP/IKE Phase I :

1. The cryptographic algorithms to secure the connection are negotiated. 2. Diffie-Hellman exchange occurs to derive a shared secret over an insecure medium. 3. Peers authenticate each other. Possible authentication methods are : Pre-Shared Key, Digital

Certificates and RSA-nonces (this is available only on IOS).

Phase 1 consists of Main Mode or Aggressive Mode. Main Mode performs three two-packet exchanges which totals to six packets. The advantage of Main Mode over Aggressive Mode is that authentication stage is performed across the already secured connection. Identity information (IKE ID) that two peers exchange is protected from eavesdropping attacks. Main Mode is the default when digital certificates are used for authentication for both – site-to-site and remote access VPNs. Aggressive Mode will be described later in this lab.

IKE Phase 2 has one mode, called Quick mode. Quick mode occurs after IKE has established the secure tunnel in Phase 1. It negotiates a shared IPSec transform, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs. IPSec SAs are unidirectional. This plays an important role if there is a device which may filter AH/ESP packets in the path between the security gateways.

To trigger the IPSec negotiation process the router will consult the SPD to see if there is a policy match for a packet. The SPD is built based on the access-list defined for interesting traffic. As the access-list includes the packet's source and destination address, the router will decide that the traffic needs to be IPSec protected. The next step is to see if an IKE or IPSec SA is already established to the IPsec peer. Because this is the first packet to this destination, there will be no SA existing in the SADB. All packets that match this policy can be queued or dropped until the IKE and IPsec SA are established. IOS IPSec drops all packets while waiting for IKE and IPSec SAs to be established. That's why if you ping, you will first see some one- or two-packet loss.

For the negotiation to be successful, a few requirements have to be met. For ISAKMP phase I authentication method, encryption and integrity algorithms, and DH group must match, and the initiator's lifetime must be less then or equal to the lifetime in the policy being compared (in some implementations lifetime must also match). For phase II, IPSec security protocols (ESP, AH), encryption and integrity algorithms, transport/tunnel mode and Proxy ACLs must match. (ACLs don‟t not have to match completely but for the exam purpose I would assume they have to, unless otherwise stated.)




In this particular task we are asked to perform digital certificate authentication. It is good to know how the X.509 v3 digital certificate structure looks like:

Version Serial Number Issuer Validity Subject (unstructured and structured portions) Subject Public Key Info Extensions (Optional) Certificate Signature Algorithm Certificate Signature

Structured portion of the certificate‟s Subject field is called Distinguish Name (DN). It has its own attributes like CN, O, OU, C, L and so on. Unstructured portion consists of FQDN which is always present plus it may also contain the IP address and serial number.

Now, a few words about certificate validation process performed on the peer's identity certificate. After the trustpoint has been found (the one which contains the appropriate Root CA Certificate), certificate validation is performed. The signature, CRL list and validity dates are checked on the certificate (and possibly authorization is performed). If the certificate is verified, then it will be cached in the Public Key keyring. Certificate Maps (Certificate ACLs) can be used to perform an additional check or to skip some of the validation steps mentioned above. If the certificate of the peer matches the certificate ACL, or a certificate map is not associated with the trustpoint used to verify the certificate of the peer, the certificate of the peer is considered valid. The validation steps which can be omitted are CRL and authorization check plus we can allow also the expired certificates. Note that cached certificates (which were previously successfully verified) are not subject to the validation process again until they time out. More information about this feature can be found here. To manage the Public Keyring (you can clear the cache there) use “crypto key pubkey-chain rsa” command.

Finally, to meet the last requirement we can use “reverse-route static” option. It creates a route for the destination network from the Proxy ACL when the crypto map is applied to an interface.

Verification

Trigger the VPN tunnel establishment pinging R5‟s F0/1 sourcing traffic from F0/1:

R6#ping 10.5.5.5 so f0/0




.!!!!


R6#

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_ircec.html




R5#sh cry pki ce

Certificate

Status: Available

Certificate Serial Number (hex): 02

Certificate Usage: General Purpose

Issuer:

cn=IOS_CA

Subject:

Name: R5.ipexpert.com

hostname=R5.ipexpert.com

cn=R5.ipexpert.com

ou=CCIE

c=PL

CRL Distribution Points:

http://8.9.50.2/cgi-bin/pkiclient.exe?operation=GetCRL

Validity Date:

start date: 10:17:37 GMT+1 Nov 4 2009

end date: 10:17:37 GMT+1 Nov 4 2010

Associated Trustpoints: CA

CA Certificate

Status: Available


Certificate Usage: Signature

Issuer:

cn=IOS_CA

Subject:

cn=IOS_CA

Validity Date:


end date: 09:35:19 GMT+1 Nov 3 2012


R6(config)#do sh cry pki ce

Certificate

Status: Available


Certificate Usage: General Purpose

Issuer:

cn=IOS_CA

Subject:

Name: R6.ipexpert.com

hostname=R6.ipexpert.com

cn=R6.ipexpert.com

ou=CCIE

c=PL

CRL Distribution Points:

http://8.9.50.2/cgi-bin/pkiclient.exe?operation=GetCRL

Validity Date:


end date: 10:20:26 GMT+1 Nov 4 2010


CA Certificate

Status: Available


Certificate Usage: Signature




Issuer:

cn=IOS_CA

Subject:

cn=IOS_CA

Validity Date:


end date: 09:35:19 GMT+1 Nov 3 2012


R6#sh cry pki tru

Trustpoint CA:

Subject Name:

cn=IOS_CA

Serial Number (hex): 01

Certificate configured.

SCEP URL: http://8.9.50.2:80/cgi-bin

R6# debug cry pki validation

R6# debug cry pki transaction

After clearing the tunnel and issuing ping from R5‟s F0/1 to R6‟s F0/0:

R5# clear crypto session

R6# clear crypto session

R6#

Nov 4 09:46:32.049: CRYPTO_PKI: Identity not specified for session 10007

Nov 4 09:46:32.153: CRYPTO_PKI: Trust-Point CA picked up

Nov 4 09:46:32.153: CRYPTO_PKI: Identity selected (CA) for session 20008

Nov 4 09:46:32.153: CRYPTO_PKI: unlocked trustpoint CA, refcount is 0

Nov 4 09:46:32.153: CRYPTO_PKI: locked trustpoint CA, refcount is 1

Nov 4 09:46:32.153: CRYPTO_PKI: Identity bound (CA) for session 10007

Nov 4 09:46:32.369: CRYPTO_PKI: Adding peer certificate

Nov 4 09:46:32.373: CRYPTO_PKI: Added x509 peer certificate - (567) bytes

Nov 4 09:46:32.373: CRYPTO_PKI: validation path has 1 certs

Nov 4 09:46:32.373: CRYPTO_PKI: Check for identical certs

Nov 4 09:46:32.373: CRYPTO_PKI: Create a list of suitable trustpoints

Nov 4 09:46:32.373: CRYPTO_PKI: Found a issuer match

Nov 4 09:46:32.373: CRYPTO_PKI: Suitable trustpoints are: CA,

Nov 4 09:46:32.373: CRYPTO_PKI: Attempting to validate certificate using CA

Nov 4 09:46:32.373: CRYPTO_PKI: Using CA to va

R6#lidate certificate

Nov 4 09:46:32.385: CRYPTO_PKI: Certificate is verified

Note that CRL check has been bypassed:

Nov 4 09:46:32.385: CRYPTO_PKI: Certificate validated without revocation check

Nov 4 09:46:32.385: CRYPTO_PKI: Selected AAA username: 'R5.ipexpert.com'

Nov 4 09:46:32.385: CRYPTO_PKI: chain cert was anchored to trustpoint CA, and chain

validation result was: CRYPTO_VALID_CERT_WITH_WARNING

Nov 4 09:46:32.385: CRYPTO_PKI: Validation TP is CA

Nov 4 09:46:32.385: CRYPTO_PKI: Certificate validation succeeded

Nov 4 09:46:32.417: CRYPTO_PKI: unlocked trustpoint CA, refcount is 0




R6#sh cry isa pe

Peer: 8.9.50.5 Port: 500 Local: 8.9.50.6

Phase1 id: R5.ipexpert.com

R6#sh cry sess de

Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection

K - Keepalives, N - NAT-traversal, T - cTCP encapsulation

X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Serial0/1/0

Uptime: 00:02:48

Session status: UP-ACTIVE

Peer: 8.9.50.5 port 500 fvrf: (none) ivrf: (none)

Phase1_id: R5.ipexpert.com

Desc: (none)

IKE SA: local 8.9.50.6/500 remote 8.9.50.5/500 Active

Capabilities:(none) connid:1004 lifetime:23:57:11

IPSEC FLOW: permit ip 10.6.6.0/255.255.255.0 10.5.5.0/255.255.255.0

Active SAs: 2, origin: crypto map

Inbound: #pkts dec'ed 4 drop 0 life (KB/Sec) 4509504/3431

Outbound: #pkts enc'ed 4 drop 0 life (KB/Sec) 4509504/3431

End Verification

4.3 IOS-ASA L2L

Create loopback 3 on R2. Assign it an IP address of 192.168.3.2/24.

Create a VPN Tunnel on ASA1 and R2 protecting all IP traffic between VLAN100 and newly created loopback network.

For Phase I, create ISAKMP policy 30 on ASA and use its default values. Use PSK of “ipexpert.” For Phase II use 3DES and SHA algorithms.

On the ASA1, ensure that ICMP traffic is not allowed across the tunnel.

Create an additional loopback 30 on R2. Assign it an IP address of 192.168.30.2/24.

Add traffic from this newly created loopback to VLAN 100 to the existing tunnel.

Give priority treatment to all telnet packets flowing between Loopback 3 and VLAN100 across the VPN tunnel on R2 and restrict this traffic to 200Kbps. Loopback 30 traffic should not be subject to this policy.

You are allowed to use three static routes in this task.

Configuration

R2



access-list 150 permit tcp 192.168.3.0 0.0.0.255 10.1.1.0 0.0.0.255 eq telnet

access-list 150 permit tcp 192.168.3.0 0.0.0.255 eq telnet 10.1.1.0 0.0.0.255

interface Loopback3

ip address 192.168.3.2 255.255.255.0




interface Loopback30

ip address 192.168.30.2 255.255.255.0


encr 3des

authentication pre-share

group 2

crypto isakmp key ipexpert address 8.9.2.10

crypto ipsec transform-set SET3 esp-3des esp-sha-hmac


set peer 8.9.2.10


match address 120

qos pre-classify

class-map match-all VPN_QOS_CLASS

match access-group 150

policy-map VPN_QOS

class VPN_QOS_CLASS

priority 200

interface GigabitEthernet0/1

crypto map MAP1

service-policy output VPN_QOS

ip route 10.1.1.0 255.255.255.0 8.9.2.10

ASA1

crypto ipsec transform-set SET3 esp-3des esp-sha-hmac



encryption 3des

hash sha

group 2

lifetime 86400

access-list PROXY_ACL extended permit ip 10.1.1.0 255.255.255.0

192.168.3.0 255.255.255.0

access-list PROXY_ACL extended permit ip 10.1.1.0 255.255.255.0

192.168.30.0 255.255.255.0

access-list VPN_FILTER extended deny icmp any any

access-list VPN_FILTER extended permit ip any any

group-policy L2L_POL internal

group-policy L2L_POL attributes

vpn-filter value VPN_FILTER

tunnel-group 8.9.2.2 type ipsec-l2l

tunnel-group 8.9.2.2 general-attributes

default-group-policy L2L_POL

tunnel-group 8.9.2.2 ipsec-attributes

pre-shared-key ipexpert

crypto map MAP1 10 match address PROXY_ACL

crypto map MAP1 10 set peer 8.9.2.2




crypto map MAP1 10 set transform-set SET3

crypto map MAP1 interface outside

route outside 192.168.3.0 255.255.255.0 8.9.2.2 1

route outside 192.168.30.0 255.255.255.0 8.9.2.2 1

cry isa ena outside

sysopt connection permit-vpn


So the interesting traffic could trigger IPSec process it has to be routed through the interface which has the crypto map or tunnel protection applied. This is why you should always check routing configuration before you proceed to the IPSec related tasks. The other thing you should check is IP reachability towards the other VPN endpoint.

You don‟t have to create ACL entries on the ASA for the IPSec traffic destined to it. However, if “sysopt connection permit-vpn” was turned off, you would have to create entries for the tunneled traffic. With this option set, however, all tunneled traffic is automatically allowed. To filter VPN traffic on the ASA use “vpn-filter” command which works for tunneled traffic only.

IPSec processing happens before QoS on the IOS Routers. It means that if you were trying to match traffic for QoS classification, the only traffic you could match would be the IPSec protected traffic (AH or ESP). To match the unencrypted traffic, use “qos pre-classify” command. In our case this allows you to choose which exact traffic you want to prioritize.

One more thing regarding ASA ISAKMP Policy. Even if you are asked to use the default values, hardcode them because otherwise the negotiation process may not work properly.

Verification

Add routes on ACS for 192.168.3.0/24 and 192.168.30.0/24 via ASA1:

route add 192.168.3.0 mask 255.255.255.0 10.1.1.10

route add 192.168.30.0 mask 255.255.255.0 10.1.1.10

Initiate a telnet session to 192.168.3.2 from the ACS:




R2#sh cry isa pe

Peer: 8.9.2.10 Port: 500 Local: 8.9.2.2

Phase1 id: 8.9.2.10

R2#sh cry sess de





Interface: GigabitEthernet0/1

Uptime: 00:04:24



Phase1_id: 8.9.2.10

Desc: (none)











R2#sh policy-map int Gi0/1

GigabitEthernet0/1

Service-policy output: VPN_QOS

queue stats for all priority classes:

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 18/2028

Class-map: VPN_QOS_CLASS (match-all)



Match: access-group 150

Priority: 200 kbps, burst bytes 5000, b/w exceed drops: 0




Match: any

Then generate telnet to Loopback 30 and notice that this traffic is not prioritized (only the class-default will show the packet counter increased). ICMP across the tunnel is not allowed:




R2#ping 10.1.1.100 so l3




.....


ASA1(config)# sh vpn-sessiondb l2l

Session Type: LAN-to-LAN

Connection : 8.9.2.2

Index : 4 IP Addr : 192.168.3.0

Protocol : IKE IPsec

Encryption : 3DES Hashing : SHA1

Bytes Tx : 2761 Bytes Rx : 2936

Login Time : 18:22:54 UTC Sun Oct 25 2009

Duration : 0h:07m:53s

ASA1(config)# sh access-list VPN_FILTER

access-list VPN_FILTER; 2 elements

access-list VPN_FILTER line 1 extended deny icmp any any (hitcnt=8) 0xaa736064

access-list VPN_FILTER line 2 extended permit ip any any (hitcnt=5) 0xf5f7769f

End Verification

4.4 L2L Aggressive Mode with PSK

Protect the traffic between VLAN 5 and VLAN 2; use R5 and R2 as the VPN endpoints.

For this task assume that R5‟s external IP address is dynamically assigned and may change over the time. You are not allowed to use wildcard PSK on R2.

Use AES 192 encryption and SHA-1 hashing for both phases. Use PSK of “ipexpert” for authentication.

VPN traffic should be only initiated by R5.

Test by pinging R2‟s Gi0/1 interface; you are allowed one static route to get this working.

Configuration

R2


encr aes 192



crypto isakmp key ipexpert hostname R5.ipexpert.com

crypto ipsec transform-set SET4 esp-aes 192 esp-sha-hmac

crypto dynamic-map DYN_MAP 10


match address 140




crypto map MAP2 10 ipsec-isakmp dynamic DYN_MAP

ip route 10.5.5.0 255.255.255.0 8.9.50.5


crypto map MAP2

R5


encr aes 192




crypto isakmp profile ISA_PROF

keyring default

self-identity fqdn

initiate mode aggressive

crypto ipsec transform-set SET4 esp-aes 192 esp-sha-hmac


set peer 8.9.50.2


set isakmp-profile ISA_PROF

match address 140


Aggressive Mode is the default for Remote Access VPN connections when Pre-Shared Key is used for authentication. It is quicker in establishing the secure management connection. However, the downside is that any identity information is sent in clear text. Most commonly IKE ID values used are : IP address, FQDN, Group Name and DN. Aggressive Mode allows us to use IKE ID in the authentication stage of Phase I when Pre-Shared Key is used as the authentication method. This is because DH exchange is not completed before IKE IDs are exchanged. When Main Mode is used with Pre-Shared Key, DH happens before authentication stage and because it uses Pre-Shared Key in it‟s own calculations, only the peer‟s source ISAKMP packet IP address can be used to find it.

ISAKMP Profile is a new feature that can be used to set some additional Phase I negotiation parameters either when initiating VPN traffic or responding to it. There are two types ISAKMP Profiles : Request (which is used at the beginning of the negotiation) and Respond (which is used when IKE ID of the peer is received). Request Profile does not contain “match” command set, but it has to be applied either to a crypto map or tunnel protection. Respond Profile must contain “match” option but it does not have to be applied to any crypto map or tunnel protection. In our case only one side may initiate the connection, thus we don‟t have to worry about the Respond Profile (note that then the Request Profile would be also the Respond Profile). We use ISAKMP Request Profile to set negotiation mode and IKE ID. One important thing to note here is whenever ISAKMP Profiles are used with PSK, they should always have a KeyRing configured.

The other end cannot initiate the VPN traffic because it uses a dynamic map, which does not contain “set peer” option. It used when the remote end‟s IP address is not known in advantage – like when it is dynamically assigned. This is reflects Remote Access VPN scenario.




Verification

Turn on ISAKMP debug on R5 and ping R2‟s Gi0/1 (source the traffic from F0/1) so you could see that ISAKMP Profile we created is used as the Request Profile and that Phase I mode being used is AM. Don‟t ping ASAs because they don‟t have route to 10.5.5.0/24:

R5#deb cry isa

Crypto ISAKMP debugging is on

R5#ping 8.9.2.2 so f0/1




Nov 4 14:40:58.042: ISAKMP:(0): SA request profile is ISA_PROF

Nov 4 14:40:58.042: ISAKMP: Created a peer struct for 8.9.50.2, peer port 500

Nov 4 14:40:58.042: ISAKMP: New peer created peer = 0x490550A8 peer_handle =

0x80000011

Nov 4 14:40:58.042: ISAKMP: Locking peer struct 0x490550A8, refcount 1 for

isakmp_initiator

Nov 4 14:40:58.042: ISAKMP: local port 500, remote port 500

Nov 4 14:40:58.046: ISAKMP: set new node 0 to QM_IDLE

Nov 4 14:40:58.046: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert

sa = 49493AF0

Nov 4 14:40:58.046: ISAKMP:(0):Found ADDRESS key in keyring default

Nov 4 14:40:58.046: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

Nov 4 14:40:58.046: ISAKMP:(0): constructed NAT-T vendor-07 ID



Nov 4 14:40:58.046: ISAKMP:(0):SA is doing pre-shared key authentication using id

type ID_FQDN

Nov 4 14:40:58.046: ISAKMP (0): ID payload

next-payload : 13

type : 2

FQDN name : R5.ipexpert.com

protocol : 17

port : 0

length : 23

Nov 4 14:40:58.046: ISAKMP:(0):Total payload length: 23

Nov 4 14:40:58.046: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_AM

Nov 4 14:40:58.046: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_AM1

Nov 4 14:40:58.046: ISAKMP:(0): beginning Aggressive Mode exchange

Nov 4 14:40:58.046: ISAKMP:(0): sending packet to 8.9.50.2 my_port 500 peer_port 500

(I) AG_INIT_EXCH

Nov 4 14:40:58.046: ISAKMP:(0):Sending an IKE IPv4 Packet.

Nov 4 14:40:58.126: ISAKMP (0): received packet from 8.9.50.2 dport 500 sport 500

Global (I) AG_INIT_EXCH

Nov 4 14:40:58.126: ISAKMP:(0): processing SA payload. message ID = 0

Nov 4 14:40:58.126: ISAKMP:(0): processing ID payload. message ID = 0

Nov 4 1.!!!!


R5#4:40:58.126: ISAKMP (0): ID payload

next-payload : 10

type : 1

address : 8.9.50.2

protocol : 0

port : 0

length : 12

Nov 4 14:40:58.126: ISAKMP:(0): processing vendor id payload

Nov 4 14:40:58.126: ISAKMP:(0): vendor ID is Unity





Nov 4 14:40:58.126: ISAKMP:(0): vendor ID is DPD


Nov 4 14:40:58.126: ISAKMP:(0): speaking to another IOS box!


Nov 4 14:40:58.130: ISAKMP:(0): local preshared key found

Nov 4 14:40:58.130: ISAKMP : Looking for xauth in profile ISA_PROF

Nov 4 14:40:58.130: ISAKMP:(0):Checking ISAKMP transform 1 against priority 20 policy

Nov 4 14:40:58.130: ISAKMP: encryption AES-CBC

Nov 4 14:40:58.130: ISAKMP: keylength of 192

Nov 4 14:40:58.130: ISAKMP: hash SHA

Nov 4 14:40:58.130: ISAKMP: default group 1

Nov 4 14:40:58.130: ISAKMP: auth pre-share

Nov 4 14:40:58.130: ISAKMP: life type in seconds

Nov 4 14:40:58.130: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

Nov 4 14:40:58.130: ISAKMP:(0):Authentication method offered does not match policy!

Nov 4 14:40:58.130: ISAKMP:(0):atts are not acceptable. Next payload is 0









Nov 4 14:40:58.130: ISAKMP:(0):atts are acceptable. Next payload is 0

Nov 4 14:40:58.130: ISAKMP:(0):Acceptable atts:actual life: 86400

Nov 4 14:40:58.130: ISAKMP:(0):Acceptable atts:life: 0

Nov 4 14:40:58.130: ISAKMP:(0):Fill atts in sa vpi_length:4

Nov 4 14:40:58.130: ISAKMP:(0):Fill atts in sa life_in_seconds:86400

Nov 4 14:40:58.130: ISAKMP:(0):Returning Actual lifetime: 86400

Nov 4 14:40:58.130: ISAKMP:(0)::Started lifetime timer: 86400.

Nov 4 14:40:58.130: ISAKMP (0): vendor ID is NAT-T RFC 3947

Nov 4 14:40:58.130: ISAKMP:(0): processing KE payload. message ID = 0

Nov 4 14:40:58.162: ISAKMP:(0): processing NONCE payload. message ID = 0


Nov 4 14:40:58.162: ISAKMP:(1013): processing HASH payload. message ID = 0

Nov 4 14:40:58.162: ISAKMP:received payload type 20

Nov 4 14:40:58.162: ISAKMP (1013): His hash no match - this node outside NAT

Nov 4 14:40:58.162: ISAKMP:received payload type 20

Nov 4 14:40:58.162: ISAKMP (1013): No NAT Found for self or peer

Nov 4 14:40:58.162: ISAKMP:(1013):SA authentication status:

authenticated

Nov 4 14:40:58.162: ISAKMP:(1013):SA has been authenticated with 8.9.50.2

Nov 4 14:40:58.162: ISAKMP: Trying to insert a peer 8.9.50.5/8.9.50.2/500/, and

inserted successfully 490550A8.

Nov 4 14:40:58.166: ISAKMP:(1013):Send initial contact

Nov 4 14:40:58.166: ISAKMP:(1013): sending packet to 8.9.50.2 my_port 500 peer_port

500 (I) AG_INIT_EXCH


Nov 4 14:40:58.166: ISAKMP:(1013):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH

Nov 4 14:40:58.166: ISAKMP:(1013):Old State = IKE_I_AM1 New State = IKE_P1_COMPLETE

Nov 4 14:40:58.166: ISAKMP:(1013):beginning Quick Mode exchange, M-ID of 1930782236

Nov 4 14:40:58.166: ISAKMP:(1013):QM Initiator gets spi


500 (I) QM_IDLE


Nov 4 14:40:58.170: ISAKMP:(1013):Node 1930782236, Input = IKE_MESG_INTERNAL,

IKE_INIT_QM

Nov 4 14:40:58.170: ISAKMP:(1013):Old State = IKE_QM_READY New State = IKE_QM_I_QM1

Nov 4 14:40:58.170: ISAKMP:(1013):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE

Nov 4 14:40:58.170: ISAKMP:(1013):Old State = IKE_P1_COMPLETE New State =

IKE_P1_COMPLETE





Global (I) QM_IDLE

Nov 4 14:40:58.218: ISAKMP:(1013): processing HASH payload. message ID = 1930782236


Nov 4 14:40:58.218: ISAKMP:(1013):Checking IPSec proposal 1

Nov 4 14:40:58.218: ISAKMP: transform 1, ESP_AES

Nov 4 14:40:58.218: ISAKMP: attributes in transform:

Nov 4 14:40:58.218: ISAKMP: encaps is 1 (Tunnel)

Nov 4 14:40:58.218: ISAKMP: SA life type in seconds

Nov 4 14:40:58.218: ISAKMP: SA life duration (basic) of 3600

Nov 4 14:40:58.218: ISAKMP: SA life type in kilobytes

Nov 4 14:40:58.218: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0

Nov 4 14:40:58.218: ISAKMP: authenticator is HMAC-SHA

Nov 4 14:40:58.218: ISAKMP: key length is 192

Nov 4 14:40:58.218: ISAKMP:(1013):atts are acceptable.

Nov 4 14:40:58.218: ISAKMP:(1013): processing NONCE payload. message ID = 1930782236



Nov 4 14:40:58.222: ISAKMP:(1013): Creating IPSec SAs

Nov 4 14:40:58.222: inbound SA from 8.9.50.2 to 8.9.50.5 (f/i) 0/ 0

(proxy 8.9.2.0 to 10.5.5.0)

Nov 4 14:40:58.222: has spi 0xB6142905 and conn_id 0

Nov 4 14:40:58.222: lifetime of 3600 seconds

Nov 4 14:40:58.222: lifetime of 4608000 kilobytes

Nov 4 14:40:58.222: outbound SA from 8.9.50.5 to 8.9.50.2 (f/i) 0/0

(proxy 10.5.5.0 to 8.9.2.0)

Nov 4 14:40:58.222: has spi 0xA5FC67AF and conn_id 0

Nov 4 14:40:58.222: lifetime of 3600 seconds

Nov 4 14:40:58.222: lifetime of 4608000 kilobytes


500 (I) QM_IDLE


Nov 4 14:40:58.222: ISAKMP:(1013):deleting node 1930782236 error FALSE reason "No

Error"

Nov 4 14:40:58.226: ISAKMP:(1013):Node 1930782236, Input = IKE_MESG_FROM_PEER,

IKE_QM_EXCH

Nov 4 14:40:58.226: ISAKMP:(1013):Old State = IKE_QM_I_QM1 New State =

IKE_QM_PHASE2_COMPLETE

R5#

R5#

Nov 4 14:41:08.050: ISAKMP:(1013): no outgoing phase 1 packet to retransmit. QM_IDLE

R2#sh cry isa pe

Peer: 8.9.50.5 Port: 500 Local: 8.9.50.2


R2#sh cry sess de | be 0/1/0


Uptime: 00:03:26




Desc: (none)




Active SAs: 2, origin: dynamic crypto map



End Verification




4.5 L2L Overlapping Subnets


Use PSK “cisco” for Phase I and 3DES and MD-5 for Phase II.

Make VLAN 4 visible as 10.44.44.0/24 to R6.


You may create loopback interfaces and use EIGRP as the routing protocol (AS 46).

You are not allowed to use any static routes.

Use 172.16.46.0/24 for the tunnel network.

Make sure the EIGRP routing protocol updates are not leaking to any other device.

You are not allowed to use either GRE or crypto map as part of the solution for this task.

Configuration

R4



crypto isakmp key cisco address 8.9.50.6


crypto ipsec profile IPSEC_PROF5



ip address 10.44.44.4 255.255.255.0


ip nat inside


interface Tunnel46

ip address 172.16.46.4 255.255.255.0

ip nat outside


tunnel source Serial0/0/0

tunnel destination 8.9.50.6

tunnel mode ipsec ipv4

tunnel protection ipsec profile IPSEC_PROF5

router eigrp 46


no passive-interface Tunnel46

network 10.44.44.4 0.0.0.0

network 172.16.46.4 0.0.0.0

no auto-summary




R6








ip address 10.40.40.6 255.255.255.0


ip nat inside


interface Tunnel46

ip address 172.16.46.6 255.255.255.0

ip nat outside






router eigrp 46



network 10.40.40.6 0.0.0.0

network 172.16.46.6 0.0.0.0

no auto-summary


Let‟s start with Overlapping Subnets. Typically when there is a NAT configuration on the VPN device we want to exclude interesting traffic from the NAT process. This is because NAT happens before IPSec – this holds true on both ASA and IOS Routers as well. In our particular case we must use NAT because the IP ranges which are to communicate overlap with each other. Moreover, we don‟t exclude them from the NAT process because we want to have the VPN interesting traffic to be NATed.

We are told we cannot use any static routes or GRE or crypto maps. It looks like the only things which left are GET VPNs and…SVTI. SVTI can be used for site-to-site connectivity in which a tunnel provides always-on access between two sites (it's a point-to-point connection). The advantage of using SVTIs as opposed to crypto map configurations is that users can enable dynamic routing protocols (packet are just blidnly encapsulated – it's a point-to-point tunnel) on the tunnel interface without the extra 24 bytes required for GRE headers (no additional overhead), thus reducing the bandwidth for sending encrypted data. Additionally, multiple Cisco IOS software features can be configured directly on the tunnel interface and on the physical egress interface of the tunnel interface. Note that in our example part of the NAT configuration has been made on the tunnel interface (SVTI). Traffic from VLAN 4 will be NATed only when it goes to VLAN 40 and vice-versa. More information about VTIs (SVTI and DVTI used in the next task) can be found here.

To make sure EIGRP updates are not leaking to any other device we ensured that the only interface which can send EIGRP Hello packets is the SVTI tunnel interface.

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_ipsec_virt_tunnl_ps6441_TSD_Products_Configuration_Guide_Chapter.html




Verification

Start with IPSec verification. If tunnel is up, check the routing:

R4#sh cry isa sa

IPv4 Crypto ISAKMP SA

dst src state conn-id status

8.9.50.6 8.9.50.4 QM_IDLE 1002 ACTIVE

R4#sh cry sess de





Interface: Tunnel46

Uptime: 00:01:21



Phase1_id: 8.9.50.6

Desc: (none)







R4#sh ip eigrp ne


H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 172.16.46.6 Tu46 13 00:01:45 32 2187 0 16



D 10.40.40.0 [90/27008000] via 172.16.46.6, 00:01:46, Tunnel46



D 10.44.44.0 [90/27008000] via 172.16.46.4, 00:02:20, Tunnel46

R4#sh ip route 10.40.40.6


Known via "eigrp 46", distance 90, metric 27008000, type internal

Redistributing via eigrp 46

Last update from 172.16.46.6 on Tunnel46, 00:02:58 ago


* 172.16.46.6, from 172.16.46.6, 00:02:58 ago, via Tunnel46


Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit

Reliability 255/255, minimum MTU 1443 bytes

Loading 1/255, Hops 1















So the NATed networks are reachable via the Tunnel interfaces, as we expected. Now let‟s take a closer look how this is working here:

R4#deb ip nat de

IP NAT detailed debugging is on

R6#deb ip nat de

IP NAT detailed debugging is on

R4#ping 10.40.40.6 rep 2

R6#

Nov 5 09:51:37.352: NAT*: o: icmp (172.16.46.4, 3) -> (10.40.40.6, 3) [11]

Nov 5 09:51:37.352: NAT*: o: icmp (172.16.46.4, 3) -> (10.40.40.6, 3) [11]

Nov 5 09:51:37.352: NAT*: s=172.16.46.4, d=10.40.40.6->10.4.4.6 [11]

Nov 5 09:51:37.352: NAT: i: icmp (10.4.4.6, 3) -> (172.16.46.4, 3) [11]

Nov 5 09:51:37.352: NAT: s=10.4.4.6->10.40.40.6, d=172.16.46.4 [11]

Nov 5 09:51:37.380: NAT*: o: icmp (172.16.46.4, 3) -> (10.40.40.6, 3) [12]

Nov 5 09:51:37.380: NAT*: s=172.16.46.4, d=10.40.40.6->10.4.4.6 [12]

Nov 5 09:51:37.380: NAT: i: icmp (10.4.4.6, 3) -> (172.16.46.4, 3) [12]

Nov 5 09:51:37.380: NAT: s=10.4.4.6->10.40.40.6, d=172.16.46.4 [12]

R6#sh ip nat tra


icmp 10.40.40.6:4 10.4.4.6:4 172.16.46.4:4 172.16.46.4:4

--- 10.40.40.6 10.4.4.6 --- ---

--- 10.40.40.0 10.4.4.0 --- ---

R6#ping 10.44.44.4 rep 2

R4#

*Nov 5 09:57:22.246: NAT*: o: icmp (172.16.46.6, 15) -> (10.44.44.4, 15) [61]

*Nov 5 09:57:22.246: NAT*: o: icmp (172.16.46.6, 15) -> (10.44.44.4, 15) [61]

*Nov 5 09:57:22.246: NAT*: s=172.16.46.6, d=10.44.44.4->10.4.4.4 [61]

*Nov 5 09:57:22.246: NAT: i: icmp (10.4.4.4, 15) -> (172.16.46.6, 15) [61]

*Nov 5 09:57:22.246: NAT: s=10.4.4.4->10.44.44.4, d=172.16.46.6 [61]

*Nov 5 09:57:22.274: NAT*: o: icmp (172.16.46.6, 15) -> (10.44.44.4, 15) [62]

*Nov 5 09:57:22.274: NAT*: s=172.16.46.6, d=10.44.44.4->10.4.4.4 [62]

*Nov 5 09:57:22.274: NAT: i: icmp (10.4.4.4, 15) -> (172.16.46.6, 15) [62]

R4#sh ip nat tra


icmp 10.44.44.4:15 10.4.4.4:15 172.16.46.6:15 172.16.46.6:15

icmp 10.44.44.4:16 10.4.4.4:16 172.16.46.6:16 172.16.46.6:16

--- 10.44.44.4 10.4.4.4 --- ---

--- 10.44.44.0 10.4.4.0 --- ---

End Verification




4.6 Easy VPN Server (IOS)

Configure R4 as Easy VPN Server.

Use Digital Certificates for authentication. Use 3DES and MD-5 algorithms for both phases.

Perform local authentication and authorization for remote users. Use the following parameters:

Username “ipexpert” with password “ipexpert” Assign the users IP address pool 8.9.100.0/24 Use the group name CCIE R4 should see the route to remote client with distance of 15 Make sure Cat2 can reach the remote clients Use RRI to accomplish this

Enroll Test PC and R4 with R2 to obtain an identity certificate.

Users should only access VLAN 4 through the tunnel.

Use domain name ipexpert.com on R4. Change the time zone to GMT+1.

Use DVTI as part of your solution.

Configuration

Test PC

Route add 8.9.50.0 mask 255.255.255.0 8.9.2.2

Enroll with the R2 in order to obtain identity certificate. Fill the CA URL exactly as shown below:




OU must be set to “CCIE”:

Create the connection entry:

R4

aaa new-model

aaa authentication login NO none

aaa authentication login XAUTH local

aaa authorization network EZ_POL local

!

username ipexpert password ipexpert

!

line con 0

login authentication NO

!

clock timezone GMT+1 1





!



subject-name cn=R4.ipexpert.com

revocation-check none

!

cry pki authe CA

cry pki enroll CA

!


encr 3des

hash md5

group 2

crypto isakmp identity dn

!

ip local pool EZPOOL 8.9.100.1 8.9.100.254


!

crypto isakmp client configuration group CCIE

pool EZPOOL

acl 170

!


match identity group CCIE

client authentication list XAUTH

isakmp authorization list EZ_POL

client configuration address respond

virtual-template 2

!


!



set reverse-route distance 15


!

interface Virtual-Template2 type tunnel

ip unnumbered Serial0/0/0



!

router rip

redistribute static


Easy VPN is an example of Remote Access VPNs. They are different from site-to-site tunnels for a couple of reasons. First of all – we don‟t know in advance the Remote Peer‟s IP address. The other things, which are additional to L2L VPNs, are called Phase 1.5 and are as follows:

1. XAUTH - User authentication. This is different then device authentication performed in Phase I.

2. Mode Config - If the Cisco IOS VPN device indicates that authentication was successful, the client requests further configuration parameters from the peer. The remaining system parameters (for example, IP address, DNS, and split tunnel attributes) are pushed to the client.




3. After each client is assigned an internal IP address via Mode Configuration, it is important that the Cisco IOS VPN device knows how to route packets through the appropriate VPN tunnel. Reverse route injection (RRI) will ensure that a static route is created on the Cisco IOS VPN device for each client internal IP address.

Easy VPN configuration leverages AAA for authentication and group authorization. Always remember to safeguard the console, even if you are not using a default list for authentication. In some cases you might get yourself lock out of the console, which on the real exam is one of those things we definitely would not like to run into.

One important thing when configuring Easy VPN is that most of the security policies use DH group 2. If AES is used, group 5 might be needed. Remember to always hardcode one of those groups in the ISAKMP Policy on the server. The other thing we related to the ISAKMP negotiation we set there is IKE ID. Setting IKE ID to DN allows the VPN Client to compare CN from the certificate with the device‟s FQDN. If we did not set this, VPN Client would see the whole certificate‟s DN as “Null” which breaks the negotiation.

DVTI feature (part of the VTI solution described in the previous lab) uses ISAKMP Profiles to, among other things, specify extended authentication (XAUTH) and group authorization methods. Make sure that identity group you are matching is what is set in the OU field of the Peer‟s Identity Certificate. When Pre-Shared Key authentication is used, it should be the same as the VPN group name.

For Split Tunneling configuration on IOS always remember to use extended ACLs (on ASA you may use a standard ACL). Note that syntax is a bit confusing - the source IP part of the ACL is used to specify the VPN destination network which should be reachable through the tunnel.

Finally, whenever you are using RRI routes as part of your solution, always remember to redistribute them. Instead of setting a specific distance for RRI routes, we could tag them and further redistribute only those tagged routes using route-maps to match them.

Verification

Use the VPN Client to initiate the connection from VLAN 2. In the debug observe that ISA_PROF has been matched as the Respond Profile :

R4#deb cry isa

I *Nov 5 12:25:28.621: ISAKMP (0): received packet from 8.9.2.200 dport 500 sport

1251 Global (N) NEW SA

*Nov 5 12:25:28.621: ISAKMP: Created a peer struct for 8.9.2.200, peer port 1251

*Nov 5 12:25:28.621: ISAKMP: New peer created peer = 0x479C99AC peer_handle =

0x80000022

*Nov 5 12:25:28.621: ISAKMP: Locking peer struct 0x479C99AC, refcount 1 for

crypto_isakmp_process_block

*Nov 5 12:25:28.621: ISAKMP: local port 500, remote port 1251

*Nov 5 12:25:28.621: ISAKMP: Find a dup sa in the avl tree during calling

isadb_insert sa = 4A32C1F8

*Nov 5 12:25:28.621: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

*Nov 5 12:25:28.621: ISAKMP:(0):Old State = IKE_READY New State = IKE_R_MM1

*Nov 5 12:25:28.625: ISAKMP:(0): processing SA payload. message ID = 0

*Nov 5 12:25:28.625: ISAKMP:(0): processing vendor id payload

*Nov 5 12:25:28.625: ISAKMP:(0): vendor ID seems Unity/DPD but major 215 mismatch

*Nov 5 12:25:28.625: ISAKMP:(0): vendor ID is XAUTH


*Nov 5 12:25:28.625: ISAKMP:(0): vendor ID is DPD


*Nov 5 12:25:28.625: ISAKMP:(0): processing IKE frag vendor id payload

*Nov 5 12:25:28.625: ISAKMP:(0):Support for IKE Fragmentation not enabled






*Nov 5 12:25:28.625: ISAKMP:(0): vendor ID is NAT-T v2


*Nov 5 12:25:28.625: ISAKMP:(0): vendor ID is Unity

*Nov 5 12:25:28.625: ISAKMP:(0):No pre-shared key with 8.9.2.200!

*Nov 5 12:25:28.625: ISAKMP : Scanning profiles for xauth ... ISA_PROF

-- Output omitted -

R4#sh cry isa pe

Peer: 8.9.2.200 Port: 1283 Local: 8.9.50.4

Phase1 id: cn=Leve,ou=CCIE,o=IPExpert

Peer: 8.9.50.6 Port: 500 Local: 8.9.50.4

Phase1 id: 8.9.50.6

R4#sh cry sess de | be Virtual

Interface: Virtual-Access2

Username: ipexpert

Profile: ISA_PROF

Group: CCIE

Assigned address: 8.9.100.13

Uptime: 00:00:17



Phase1_id: cn=Leve,ou=CCIE,o=IPExpert

Desc: (none)


Capabilities:CX connid:1021 lifetime:23:59:39

IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 8.9.100.13




Now ping R4‟s F0/1 interface from Test PC:




R4#sh cry sess de | be Access


Username: ipexpert

Profile: ISA_PROF

Group: CCIE


Uptime: 00:04:54




Desc: (none)







End Verification




4.7 Easy VPN Client (IOS)

Configure R8 as a hardware client. Create Loopback 8 (8.8.8.8/24) interface which will emulate the inside network.

Make sure your credentials are stored on the device so you don‟t have to type them whenever you connect.

R4 is the Easy VPN Server.

Use 3DES and MD-5 algorithms for both phases.


Username “cciesec” with password “cisco” Assign the users IP address pool 8.9.200.0/24 Use the group name REMOTE with PSK “ipexpert”


Configuration

R8


ip unnumbered FastEthernet0/1


!

crypto ipsec client ezvpn EZCLIENT

connect manual

group REMOTE key ipexpert

mode client

peer 8.9.50.4

virtual-interface 1

username cciesec password cisco

xauth userid mode local

!

interface Loopback8

ip address 8.8.8.8 255.255.255.0

crypto ipsec client ezvpn EZCLIENT inside

!

int f0/1


R4


!


encr 3des

hash md5


group 2

!

ip local pool EZPOOL2 8.9.200.1 8.9.200.254


!




crypto isakmp client configuration group REMOTE

key ipexpert

pool EZPOOL2

acl 171

save-password

!

crypto isakmp profile ISA_PROF2

self-identity address

match identity group REMOTE

client authentication list XAUTH

isakmp authorization list EZ_POL


virtual-template 3

!




set isakmp-profile ISA_PROF2

!






Hardware Easy VPN client configuration is pretty straightforward. I decided to ask for DVTI because it has some advantages over a standard crypto map - features that are applied to the traffic going into the tunnel can be separate from the features that are applied to traffic that is not going through the tunnel (for example, split-tunnel traffic and traffic leaving the device when the tunnel is not up). Note that the Split Tunneling networks will be reachable via that Virtual Interface.

The Cisco Easy VPN Remote feature supports three modes of operation: client, network extension, and network extension plus:

Client - Specifies that NAT or PAT be done so that the PCs and other hosts at the remote end of the VPN tunnel form a private network that does not use any IP addresses in the IP address space of the destination server. An enhancement has been made so that the IP address that is received via mode configuration is automatically assigned to an available loopback interface. The IPsec Security Associations (SAs) for this IP address are automatically created by Easy VPN Remote. The IP address is typically used for troubleshooting (using ping, Telnet, and Secure Shell). Network extension - Specifies that the PCs and other hosts at the client end of the VPN tunnel should be given IP addresses that are fully routable and reachable by the destination network over the tunneled network so that they form one logical network. PAT is not used, which allows the client PCs and hosts to have direct access to the PCs and hosts at the destination network. Network extension plus (mode network-plus) - Identical to network extension mode with the additional capability of being able to request an IP address via mode configuration and automatically assign it to an available loopback interface. The IPsec SAs for this IP address are automatically created by Easy VPN Remote. The IP address is typically used for troubleshooting (using ping, Telnet, and Secure Shell).




All modes of operation also optionally support split tunneling, which allows secure access to corporate resources through the VPN tunnel while also allowing Internet access through a connection to an Internet service provider (ISP) or other service - thereby eliminating the corporate network from the path for web access.

In this example the server‟s ISAKMP Profile used acts as a Request and Respond profile in the same time. We had to set IKE ID to IP address for this connection because PSK configured on the hardware client is matched based on the IP address.

Finally, “save-password” option has to be set on the server to allow clients to store their credentials locally.

Verification

Manually bring the VPN tunnel up on the hardware client: R8#cry ipsec client ezvpn connect

R8#

*Nov 5 15:32:41.375: %CRYPTO-6-EZVPN_CONNECTION_UP: (Client) User=cciesec

Group=REMOTE Server_public_addr=8.9.50.4 Assigned_client_addr=8.9.200.6

*Nov 5 15:32:41.383: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up

*Nov 5 15:32:43.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2,

changed state to up

*Nov 5 15:32:43.299: %LINK-3-UPDOWN: Interface Loopback10000, changed state to up

*Nov 5 15:32:44.299: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10000,

changed state to up

R8#sh cry ipsec client ezvpn

Easy VPN Remote Phase: 8

Tunnel name : EZCLIENT

Inside interface list: Loopback8

Outside interface: Virtual-Access2 (bound to FastEthernet0/1)

Current State: IPSEC_ACTIVE

Last Event: MTU_CHANGED

Address: 8.9.200.6 (applied on Loopback10000)

Mask: 255.255.255.255

Save Password: Allowed

Split Tunnel List: 1

Address : 10.4.4.0

Mask : 255.255.255.0

Protocol : 0x0

Source Port: 0

Dest Port : 0

Current EzVPN Peer: 8.9.50.4




R8#sh ip route







route



C 192.168.8.0/24 is directly connected, FastEthernet0/1

8.0.0.0/8 is variably subnetted, 3 subnets, 2 masks


S 8.9.50.4/32 [1/0] via 192.168.8.20



S 10.4.4.0 [1/0] via 0.0.0.0, Virtual-Access2

S* 0.0.0.0/0 [1/0] via 192.168.8.20

R8#ping 10.4.4.4 so l8




!!!!!


R8#sh ip nat tra


icmp 8.9.200.6:4 8.8.8.8:4 10.4.4.4:4 10.4.4.4:4

R8#sh cry isa pe

Peer: 8.9.50.4 Port: 4500 Local: 192.168.8.8

Phase1 id: 8.9.50.4

R8#sh cry sess de






Uptime: 00:01:09



Phase1_id: 8.9.50.4

Desc: (none)


Capabilities:CXN connid:1004 lifetime:23:58:48








R4#sh cry isa pe

Peer: 8.9.2.8 Port: 4500 Local: 8.9.50.4

Phase1 id: REMOTE

Peer: 8.9.2.200 Port: 1315 Local: 8.9.50.4


Peer: 8.9.50.6 Port: 500 Local: 8.9.50.4

Phase1 id: 8.9.50.6

R4#sh cry isa pe config

Client-Public-Addr=8.9.2.8:4500; Client-Assigned-Addr=8.9.200.6; Client-

Group=REMOTE; Client-User=cciesec; Client-Hostname=R8.; Client-Platform=Cisco

2811; Client-Serial=FTX1123A033; Client-Flash=255565824; Client-Available-

Flash=156372992; Client-Memory=228589568; Client-Free-Memory=72668288;

Client-Image=flash:c2800nm-adventerprisek9-mz.124-22.T.bin

R4#sh cry sess br

Status: A- Active, U - Up, D - Down, I - Idle, S - Standby, N - Negotiating

K - No IKE

ivrf = (none)

Peer I/F Username Group/Phase1_id Uptime

Status

8.9.50.6 Tu46 8.9.50.6 00:36:00

UA

8.9.2.200 Vi3 ipexpert CCIE 00:35:39

UA

8.9.2.8 Vi2 cciesec REMOTE 00:01:40

UA

R4#sh cry sess remote 8.9.2.8 de






Username: cciesec

Profile: ISA_PROF2

Group: REMOTE


Uptime: 00:02:12



Phase1_id: REMOTE

Desc: (none)







End Verification




4.8 Easy VPN with External Group Authorization and XAUTH

Change configuration for task 4.7 to use RADIUS support.

Make ACS visible to the public network as 8.9.2.100.

R4 should communicate with RADIUS using key value of “ipexpert.”

Perform external group authorization for remote users. Follow the same directions for this as in task 4.7

Perform external authentication for remote users. User “cciesec” should have an IP address 8.9.200.100.

Test this configuration with R8 Easy VPN hardware client.

Configuration

R4

aaa authentication login XAUTH_EXT group radius

aaa authorization network EZ_EXT group radius

radius-server host 8.9.2.100 auth-port 1645 acct-port 1646 key

ipexpert


no client authentication list XAUTH

client authentication list XAUTH_EXT

no isakmp authorization list EZ_POL

isakmp authorization list EZ_EXT

ACS

Go to the Network Configuration and add R4 as NAS:




Then we need to enable Per-User attributes. Go to Interface Configuration -> Advanced Options:

Go to Interface Configuration -> RADIUS IETF. Enable attributes 6, 64 and 69 for Group (you don‟t have to do it also for User, however this feature can also work with user as the VPN group name but only if same group authorization is performed). In our case we want to assign the IP address to the specific user which is a Per-User attribute so we have to configure IETF attributes for Group:




Go to Interface Configuration -> RADIUS (Cisco IOS/PIX 6.x). Enable Cisco AV-Pair:

Create a Group for remote users which will store the necessary attributes. Go to Group Setup, choose an unused group, rename it and edit. Assign it the attributes as shown below:




-- Omitted --

Add user REMOTE with password ”cisco” (this password is a must). Assign it to the newly created Group:




Add user cciesec with password ”cisco” (this password could be different – depends on what we set). Also assign him to newly created Group:

ASA1


access-list OUTSIDE_IN extended permit udp host 8.9.50.4 host

8.9.2.100 eq radius

access-list OUTSIDE_IN extended permit udp host 8.9.50.4 host

8.9.2.100 eq radius-acct

access-list NAT_EXEMPT extended permit ip host 10.1.1.100 192.168.3.0

255.255.255.0

access-list NAT_EXEMPT extended permit ip host 10.1.1.100

192.168.30.0 255.255.255.0

nat (inside) 0 access-list NAT_EXEMPT





Easy VPN Server configuration does not need many modifications. The only thing we need to do here is to change the authentication and authorization method lists to point to the RADIUS server.

ACS configuration is more complicated. Always start with adding the NAS to AAA clients. Once you are done with this, you will have few more configuration options available in other parts of the ACS menu. Per-User attributes are needed, as well as RADIUS attributes 6, 64 and 69. Cisco AV-Pair should be also enabled. Group Profile should has those attributes configured, according to this document. Tunnel-Password attribute is the actual Pre-Shared Key for this connection. Now we need to configure an user whose name must be the same as the VPN Group name. In our case this is “REMOTE”. Users who reflect the VPN Group names should always have a password set to “cisco.” We add this user to the Group Profile (ACS Group created in previous step). Finally, we need to create a user for XAUTH. We were asked to name that user “cciesec” so it has to be also reflected in the ACS User configuration. Password for this user does not necessarily have to be set to “cisco,” but this is what we were asked in our case. Note that this user is also a member of the Group Profile ACS Group, but it has user-specific IP address set. This feature is called RADIUS Support for User Profile (or Per-User attributes based on XAUTH).

ASA configuration had to be adjusted to exempt ACS traffic going to VLAN 3 or 30 from the NAT process. Otherwise task 4.3 would be broken.

Verification

Turn on “debug radius,” “debug aaa authentication” and “debug aaa authorization” on R4:

R4#debug aaa authentication

AAA Authentication debugging is on

R4#debug aaa authorization

AAA Authorization debugging is on

R4#debug radius

Radius protocol debugging is on

Radius protocol brief debugging is off

Radius protocol verbose debugging is off

Radius packet hex dump debugging is off

Radius packet protocol debugging is on

Radius elog debugging debugging is off

Radius packet retransmission debugging is off

Radius server fail-over debugging is off

Radius elog debugging debugging is off

Bring the VPN tunnel up on R8 and observe the debugs on R4:

R8#cry ipsec client ezvpn connect

R4#

*Nov 6 10:16:56.228: AAA/BIND(0000005B): Bind i/f

*Nov 6 10:16:56.276: AAA/AUTHOR (0x5B): Pick method list 'EZ_EXT'

*Nov 6 10:16:56.280: RADIUS/ENCODE(0000005B):Orig. component type = VPN_IPSEC

*Nov 6 10:16:56.280: RADIUS: AAA Unsupported Attr: interface [175] 8

*Nov 6 10:16:56.280: RADIUS: 38 2E 39 2E 35 30

[8.9.50]

*Nov 6 10:16:56.280: RADIUS(0000005B): Config NAS IP: 0.0.0.0

*Nov 6 10:16:56.280: RADIUS/ENCODE(0000005B): acct_session_id: 89

*Nov 6 10:16:56.280: RADIUS(0000005B): sending

*Nov 6 10:16:56.280: RADIUS/ENCODE: Best Local IP-Address 8.9.50.4 for Radius-Server

8.9.2.100

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_easy_vpn_srvr_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1516834




*Nov 6 10:16:56.280: RADIUS(0000005B): Send Access-Request to 8.9.2.100:1645 id

1645/33, len 89

*Nov 6 10:16:56.284: RADIUS: authenticator 8A 4E A6 D9 23 3B 6A DC - 50 8C A7 A3 F6

BA CC E7

Here starts the group authorization process. ”REMOTE” is the actual group name the users are connecting to. At this stage the most important is the “Tunnel-Password” attribute because it used during DH exchange. The rest of the attributes may be lost at this point.

4#

*Nov 6 11:11:31.052: AAA/BIND(00000071): Bind i/f

*Nov 6 11:11:31.100: AAA/AUTHOR (0x71): Pick method list 'EZ_EXT'

*Nov 6 11:11:31.100: RADIUS/ENCODE(00000071):Orig. component type = VPN_IPSEC


*Nov 6 11:11:31.104: RADIUS: 38 2E 39 2E 35 30

[8.9.50]

*Nov 6 11:11:31.104: RADIUS(00000071): Config NAS IP: 0.0.0.0

*Nov 6 11:11:31.104: RADIUS/ENCODE(00000071): acct_session_id: 111

*Nov 6 11:11:31.104: RADIUS(00000071): sending


8.9.2.100

*Nov 6 11:11:31.104: RADIUS(00000071): Send Access-Request to 8.9.2.100:1645 id

1645/63, len 89

*Nov 6 11:11:31.104: RADIUS: authenticator E4 2B 19 D8 E4 53 CA 18 - 03 7D 2F 9B 15

B7 E8 4A

*Nov 6 11:11:31.104: RADIUS: User-Name [1] 8 "REMOTE"

*Nov 6 11:11:31.104: RADIUS: User-Password [2] 18 *

*Nov 6 11:11

R4#:31.104: RADIUS: Calling-Station-Id [31] 9 "8.9.2.8"

*Nov 6 11:11:31.104: RADIUS: NAS-Port-Type [61] 6 Virtual

[5]

*Nov 6 11:11:31.104: RADIUS: NAS-Port [5] 6 3

*Nov 6 11:11:31.104: RADIUS: NAS-Port-Id [87] 10 "8.9.50.4"

*Nov 6 11:11:31.104: RADIUS: Service-Type [6] 6 Outbound

[5]

*Nov 6 11:11:31.108: RADIUS: NAS-IP-Address [4] 6 8.9.50.4

*Nov 6 11:11:31.116: RADIUS: Received from id 1645/63 8.9.2.100:1645, Access-Accept,

len 224

*Nov 6 11:11:31.116: RADIUS: authenticator 88 9D 41 8D 54 13 08 42 - 78 F2 91 0D 6E

1E 8C A1

*Nov 6 11:11:31.116: RADIUS: Vendor, Cisco [26] 29

*Nov 6 11:11:31.116: RADIUS: Cisco AVpair [1] 23 "ipsec:tunnel-type=ESP"


*Nov 6 11:11:31.116: RADIUS: Cisco AVpair [1] 24 "ipsec:key-exchange=ike"


*Nov 6 11:11:31.116: RADIUS: Cisco AVpair [1] 17 "ipsec:inacl=170"


*Nov 6 11:11:31.116: RADIUS: Cisco AVpair [1] 23 "ipsec:save-password=1"


*Nov 6 11:11:31.116: RADIUS: Cisco AVpair [1] 25 "ipsec:addr-pool=EZPOOL2"


[5]

*Nov 6 11:11:31.116: RADIUS: Tunnel-Type [64] 6 01:ESP

[9]

*Nov 6 11:11:31.116: RADIUS: Tunnel-Password [69] 21 01:*

*Nov 6 11:11:31.120: RADIUS: Framed-IP-Address [8] 6 255.255.255.255

*Nov 6 11:11:31.120: RADIUS: Class [25] 23

*Nov 6 11:11:31.120: RADIUS: 43 41 43 53 3A 30 2F 32 61 65 63 2F 38 30 39 33

[CACS:0/2aec/8093]

*Nov 6 11:11:31.120: RADIUS: 32 30 34 2F 33

[204/3]




Now XAUTH is performed. Attributes from the Group will be also assigned to the user:

*Nov 6 11:11:31.120: RADIUS(00000071): Received from id 1645/63


*Nov 6 11:11:31.192: AAA/AUTHEN/LOGIN (00000072): Pick method list 'XAUTH_EXT'

*Nov 6 11:11:31.192: RADIUS/ENCODE(00000072):Orig. component type = VPN_IPSEC


*Nov 6 11:11:31.196: RADIUS: 38 2E 39 2E 35 30

[8.9.50]

*Nov 6 11:11:31.196: RADIUS/ENCODE(00000072): dropping service type, "radius-server

attribute 6 on-for-login-auth" is off

*Nov 6 11:11:31.196: RADIUS(00000072): Config NAS IP: 0.0.0.0

*Nov 6 11:11:31.196: RADIUS/ENCODE(00000072): acct_session_id: 112

*Nov 6 11:11:31.196: RADIUS(00000072): sending


8.9.2.100

*Nov 6 11:11:31.196: RADIUS(00000072): Send Access-Request to 8.9.2.100:1645 id

1645/64, len 84

*Nov 6 11:11:31.196: RADIUS: authenticator 34 18 E0 66 EB 2E 72 9D - 37 3B 36 78 FB

74 8C 92

*Nov 6 11:11:31.196: RADIUS: User-Name [1] 9 "cciesec"


*Nov 6 11:11:31.196: RADIUS: Calling-Station-Id [31] 9 "8.9.2.8"


[5]





len 224

*Nov 6 11:11:31.208: RADIUS: authenticator 7D CC 56 E2 80 FE E0 57 - 15 88 CD 16 B7

FA F2 31


*Nov 6 11:11:31.208: RADIUS: Cisco AVpair [1] 23 "ipsec:tunnel-type=ESP"


*Nov 6 11:11:31.208: RADIUS: Cisco AVpair [1] 24 "ipsec:key-exchange=ike"




*Nov 6 11:11:31.208: RADIUS: Cisco AVpair [1] 23 "ipsec:save-password=1"


*Nov 6 11:11:31.208: RADIUS: Cisco AVpair [1] 25 "ipsec:addr-pool=EZPOOL2"


[5]

*Nov 6 11:11:31.208: RADIUS: Tunnel-Type [64] 6 01:ESP

[9]

*Nov 6 11:11:31.208: RADIUS: Tunnel-Password [69] 21 01:*


*Nov 6 11:11:31.208: RADIUS: Class [25] 23

*Nov 6 11:11:31.208: RADIUS: 43 41 43 53 3A 30 2F 32 61 65 64 2F 38 30 39 33

[CACS:0/2aed/8093]

*Nov 6 11:11:31.208: RADIUS: 32 30 34 2F 33

[204/3]

*Nov 6 11:11:31.212: RADIUS(00000072): Received from id 1645/64


changed state to up [204/3]




R8#sh cry ipse cl ez








Mask: 255.255.255.255



Address : 10.4.4.0

Mask : 255.255.255.0

Protocol : 0x0

Source Port: 0

Dest Port : 0


R8#ping 10.4.4.20 so l8




!!!!!


R8#sh cry isa pe

Peer: 8.9.50.4 Port: 4500 Local: 192.168.8.8

Phase1 id: 8.9.50.4

R8#sh cry sess de






Uptime: 00:03:37



Phase1_id: 8.9.50.4

Desc: (none)










R4#sh cry session remote 8.9.2.8 de






Username: cciesec

Profile: ISA_PROF2

Group: REMOTE


Uptime: 00:04:54



Phase1_id: REMOTE

Desc: (none)







End Verification

4.9 Easy VPN PKI-based Per-User Attributes


Group authorization should be performed locally and should be the same as in task 4.6.

In addition to this, users should be authorized based on the CN field from the certificate.

Assign a specific user IP address 8.9.100.100 and allow him to only reach CAT2.

Test this configuration with VPN Client installed on Test PC.

Configuration

R4

access-list 172 permit ip host 10.4.4.20 any

aaa authorization network EZ_PKI group radius


no client authentication list XAUTH

client pki authorization list EZ_PKI


authorization username subjectname commonname




ACS

Configure a user whose name matches the CN field on the certificate. In our case, it will be „Leve.‟ Again, password „cisco‟ is necessary. Assign him the static IP address and the new Split Tunneling list:





The prerequisite to this feature is disabling Revocation Check on the trustpoint.

PKI-based Per-User attributes are a similar feature to Per-User XAUTH-based attributes. The difference here is that the username is chosen from the Identity Certificate of the client. To specify which attribute of the DN‟s field will be used for this purpose use the “authorization username” command under the trustpoint. A separate AAA list is also needed under the ISAKMP Profile.

When this feature is used, XAUTH should be disabled. This is because XAUTH attributes may take precedence over what was set for the user based on Certificate Profile.

Verification

On R4 turn on some debug commands:

R4#deb cry pki val

Crypto PKI Validation Path debugging is on

R4#deb cry pki tra

Crypto PKI Trans debugging is on

R4#deb radius

R4#


*Nov 6 12:40:32.175: CRYPTO_PKI: Identity not specified for session 10033

*Nov 6 12:40:32.299: CRYPTO_PKI: Adding peer certificate

*Nov 6 12:40:32.303: CRYPTO_PKI: Added x509 peer certificate - (717) bytes

*Nov 6 12:40:32.303: CRYPTO_PKI: validation path has 1 certs

*Nov 6 12:40:32.303: CRYPTO_PKI: Check for identical certs

*Nov 6 12:40:32.303: CRYPTO_PKI: Create a list of suitable trustpoints

*Nov 6 12:40:32.303: CRYPTO_PKI: Found a issuer match

*Nov 6 12:40:32.303: CRYPTO_PKI: Suitable trustpoints are: CA,

*Nov 6 12:40:32.303: CRYPTO_PKI: Attempting to validate certificate using CA

*Nov 6 12:40:32.303: CRYPTO_PKI: Using CA to validate certificate

*Nov 6 12:40:32.311: CRYPTO_PKI: Certificate is verified

*Nov 6 12:40:32.311: CRYPTO_PKI: Certificate validated without revocation check

*Nov 6 12:40:32.311: CRYPTO_PKI: Selected AAA username: 'Leve'

*Nov 6 12:40:32.311: CRYPTO_PKI: ch

R4#ain cert was anchored to trustpoint CA, and chain validation result was:

CRYPTO_VALID_CERT_WITH_WARNING

*Nov 6 12:40:32.311: CRYPTO_PKI: Validation TP is CA

*Nov 6 12:40:32.311: CRYPTO_PKI: Certificate validation succeeded

*Nov 6 12:40:32.315: CRYPTO_PKI: Trust-Point CA picked up

*Nov 6 12:40:32.315: CRYPTO_PKI: Identity selected (CA) for session 20034

*Nov 6 12:40:32.315: CRYPTO_PKI: unlocked trustpoint CA, refcount is 0

*Nov 6 12:40:32.315: CRYPTO_PKI: locked trustpoint CA, refcount is 1

*Nov 6 12:40:32.315: CRYPTO_PKI: Identity bound (CA) for session 10033


*Nov 6 12:40:32.407: RADIUS/ENCODE(0000007C):Orig. component type = VPN_IPSEC





*Nov 6 12:40:32.407: RADIUS: 38 2E 39 2E 35 30

[8.9.50]

*Nov 6 12:40:32.407: RADIUS(0000007C): Config NAS IP: 0.0.0.0

*Nov 6 12:40:32.407: RADIUS/ENCODE(0000007C): acct_session_id: 122

*Nov 6 12:40:32.407: RADIUS(0000007C): sending


8.9.2.100

*Nov 6 12:40:32.407: RADIUS(0000007C): Send Access-Request to 8.9.2.100:1645 id

1645/69, len 78

*Nov 6 12:40:32.411: RADIUS: authenticator 89 66 16 CA A2 CD B5 EF - 41 D1 50 8C 90

D6 36 DB

*Nov 6 12:40:32.411: RADIUS: User-Name [1] 6 "Leve"



[5]




[5]



len 72

*Nov 6 12:40:32.419: RADIUS: authenticator 58 30 30 36 2D 8E 2D FE - A3 8B 4B F8 07

0E 6E 3A




*Nov 6 12:40:32.419: RADIUS: Class [25] 23

*Nov 6 12:40:32.419: RADIUS: 43 41 43 53 3A 30 2F 32 62 33 64 2F 38 30 39 33

[CACS:0/2b3d/8093]

*Nov 6 12:40:32.419: RADIUS: 32 30 34 2F 30

[204/0]

*Nov 6 12:40:32.423: RADIUS(0000007C): Received from id 1645/69


changed state to up

Try to ping CAT2 from Test PC:




R4#sh cry isa pe

Peer: 8.9.2.8 Port: 4500 Local: 8.9.50.4

Phase1 id: REMOTE

Peer: 8.9.2.200 Port: 1406 Local: 8.9.50.4


Peer: 8.9.50.6 Port: 500 Local: 8.9.50.4

Phase1 id: 8.9.50.6

R4#sh cry sess username Leve de






Username: Leve

Profile: ISA_PROF

Group: CCIE


Uptime: 00:05:17




Desc: (none)










R4#sh cry sess br


K - No IKE

ivrf = (none)

Peer I/F Username Group/Phase1_id Uptime Status

8.9.50.6 Tu46 8.9.50.6 01:47:26 UA

8.9.2.8 Vi3 cciesec REMOTE 01:36:38 UA

8.9.2.200 Vi2 Leve CCIE 00:05:22 UA

End Verification

End of Part I

You should now move to the Troubleshooting section Part I.




Lab 4A Detailed Solutions – Part II

4.10 ASA Easy VPN Server with External Per-User attributes

Configure ASA1 to accept remote VPN connections.

Use R8 as the Easy VPN Client. Set group name to “REMOTE.” Create Loopback 8 (8.8.8.8 /24) interface to emulate the inside network.

Use 3DES encryption and MD-5 HMAC for both phases. Set PSK to “cisco.”

Group authorization should be performed locally.

Use the following parameters for authorization:

Assign the users DNS and WINS server 10.1.1.50. The domain sent should be ipexpert.com. Use address pool 10.80.80.0/24 to allocate IP addresses. Packets to networks other then 10.1.1.0/24 should be sent in clear-text form. VPN connection should be terminated after 10 minutes of inactivity.

Create user “VPNUSER” with password “ipexpert” and authenticate him to RADIUS server at 10.1.1.100. Use shared secret “CISCO” for RADIUS communication.

Make sure that user can only use the “REMOTE” VPN group.

Configuration

R8


connect manual

group REMOTE key cisco

mode client

peer 8.9.2.10

xauth userid mode interactive

interface Loopback8

ip address 8.8.8.8 255.255.255.0



ip address 192.168.8.8 255.255.255.0


ASA1



encryption 3des

hash md5

group 2

lifetime 86400


access-list SPLIT standard permit 10.1.1.0 255.255.255.0

ip local pool EZPOOL 10.80.80.1-10.80.80.254

group-policy EZGROUP internal

group-policy EZGROUP attributes




wins-server value 10.1.1.50

dns-server value 10.1.1.50

vpn-idle-timeout 10

split-tunnel-policy tunnelspecified

split-tunnel-network-list value SPLIT

default-domain value ipexpert.com

address-pools value EZPOOL

aaa-server RAD protocol radius

aaa-server RAD (inside) host 10.1.1.100

key CISCO

tunnel-group REMOTE type remote-access

tunnel-group REMOTE general-attributes

default-group-policy EZGROUP

authentication-server-group RAD

tunnel-group REMOTE ipsec-attributes

pre-shared-key cisco

crypto dynamic-map DYNMAP 10 set transform-set SET1

crypto map MAP1 10 ipsec-isakmp dynamic DYNMAP


crypto isakmp enable outside


vpn-addr-assign local




ACS

Add new NAS. Use RADIUS as shown below.




Go to “Interface” -> “RADIUS (Cisco VPN 3000/ASA/PIX 7.x+)”. Enable per-user attribute for Group-Lock feature.




Add new user “VPNUSER.” Set password to “ipexper.t. Enable the Group-Lock feature.

Add route for the VPN Pool : route add 10.80.80.0 mask 255.255.255.0 10.1.1.0


Groups and users are core concepts in managing the security of virtual private networks (VPNs) and in configuring the security appliance. They specify attributes that determine user access to and use of the VPN. A group is a collection of users treated as a single entity. Users get their attributes from group policy. Connection profiles (tunnel groups) identify the group policy for a specific connection. If you do not assign a particular group policy to a user, the default group policy for the connection applies.

Tunnel group consists of a set of records that determines tunnel connection policies. These records identify the servers to which the tunnel user is authenticated, as well as the accounting servers, if any, to which connection information is sent. They also identify a default group policy for the connection, and they contain protocol-specific connection parameters. When digital certificates are used, ASA matches a tunnel group based on OU attribute of certificate‟s DN by default. If you want to match it based on other attributes, you can use Certificate ACL rules and then associate each rule with the desired tunnel group.

Connection profiles include a small number of attributes that pertain to creating the tunnel itself. Connection profiles include a pointer to a group policy that defines user-oriented attributes. Attributes are applied to the users according to the following hierarchy:




1. Dynamic Access Policy (DAP) record 2. Username 3. Group policy (IETF-Class-25 attribute) 4. Group policy for the connection profile 5. Default group policy

More information about the available VPN attributes can be found here.

To authenticate VPN users via RADIUS we have to first configure basic AAA support. Authorization in RADIUS happens along with authentication, the attributes will be downloaded from the user profile. The full list of RADIUS Authorization attributes for ASA can be found in the documentation.

Verification

Connect the VPN Client. Turn on RADIUS debug on ASA1:

ASA1(config)# deb radius


R8#

*Nov 9 20:50:06.319: EZVPN(EZCLIENT): Pending XAuth Request, Please enter

the following command:

*Nov 9 20:50:06.319: EZVPN: crypto ipsec client ezvpn xauth

R8#cry ipsec client ezvpn xauth

Username: VPNUSER

Password:

ASA1(config)#

radius mkreq: 0x1a

alloc_rip 0xd5b1a8a8

new request 0x1a --> 8 (0xd5b1a8a8)

got user ''

got password

add_req 0xd5b1a8a8 session 0x1a id 8

RADIUS_REQUEST

radius.c: rad_mkpkt

RADIUS packet decode (authentication request)

--------------------------------------

Raw packet data (length = 133).....

01 08 00 85 69 ee 8f 1c 25 fa ab 08 a1 c6 87 b4 | ....i...%.......

dd 52 23 20 01 09 56 50 4e 55 53 45 52 02 12 20 | .R# ..VPNUSER..

62 0f e7 5d 25 a3 bb 6f d1 7d 1d f5 0c 1a 2f 05 | b..]%..o.}..../.

06 00 01 00 00 06 06 00 00 00 02 07 06 00 00 00 | ................

01 1e 0a 38 2e 39 2e 32 2e 31 30 1f 09 38 2e 39 | ...8.9.2.10..8.9

2e 32 2e 38 3d 06 00 00 00 05 42 09 38 2e 39 2e | .2.8=.....B.8.9.

32 2e 38 04 06 0a 01 01 0a 1a 1c 00 00 00 09 01 | 2.8.............

16 69 70 3a 73 6f 75 72 63 65 2d 69 70 3d 38 2e | .ip:source-ip=8.

39 2e 32 2e 38 | 9.2.8

Parsed packet data.....

Radius: Code = 1 (0x01)

Radius: Identifier = 8 (0x08)

Radius: Length = 133 (0x0085)

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/vpngrp.html#wp1134642

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/extsvr.html#wp1605508




Radius: Vector: 69EE8F1C25FAAB08A1C687B4DD522320

Radius: Type = 1 (0x01) User-Name


Radius: Value (String) =

56 50 4e 55 53 45 52 | VPNUSER

Radius: Type = 2 (0x02) User-Password



20 62 0f e7 5d 25 a3 bb 6f d1 7d 1d f5 0c 1a 2f | b..]%..o.}..../

Radius: Type = 5 (0x05) NAS-Port


Radius: Value (Hex) = 0x10000

Radius: Type = 6 (0x06) Service-Type



Radius: Type = 7 (0x07) Framed-Protocol



Radius: Type = 30 (0x1E) Called-Station-Id

Radius: Length = 10 (0x0A)


38 2e 39 2e 32 2e 31 30 | 8.9.2.10

Radius: Type = 31 (0x1F) Calling-Station-Id



38 2e 39 2e 32 2e 38 | 8.9.2.8

Radius: Type = 61 (0x3D) NAS-Port-Type



Radius: Type = 66 (0x42) Tunnel-Client-Endpoint



38 2e 39 2e 32 2e 38 | 8.9.2.8

Radius: Type = 4 (0x04) NAS-IP-Address


Radius: Value (IP Address) = 10.1.1.10 (0x0A01010A)

Radius: Type = 26 (0x1A) Vendor-Specific

Radius: Length = 28 (0x1C)

Radius: Vendor ID = 9 (0x00000009)

Radius: Type = 1 (0x01) Cisco-AV-pair



69 70 3a 73 6f 75 72 63 65 2d 69 70 3d 38 2e 39 | ip:source-ip=8.9

2e 32 2e 38 | .2.8

send pkt 10.1.1.100/1645

rip 0xd5b1a8a8 state 7 id 8

rad_vrfy() : response message verified

rip 0xd5b1f1c8

: chall_state ''

: state 0x7

: timer 0x0

: reqauth:

69 ee 8f 1c 25 fa ab 08 a1 c6 87 b4 dd 52 23 20

: info 0x1a

session_id 0x1a

request_id 0x8

user 'VPNUSER'




response '***'

app 0

reason 0

skey 'CISCO'

sip 10.1.1.100

type 1

RADIUS packet decode (response)

--------------------------------------


02 08 00 43 ef e9 a2 56 78 b0 1b 6b 3b 83 10 4f | ...C...Vx..k;..O

7f c2 e4 a3 08 06 ff ff ff ff 1a 0e 00 00 0c 04 | ...............

55 08 52 45 4d 4f 54 45 19 1b 43 41 43 53 3a 30 | U.REMOTE..CACS:0

2f 33 65 33 32 2f 61 30 31 30 31 30 61 2f 36 35 | /3e32/a01010a/65

35 33 36 | 536



Radius: Identifier = 8 (0x08)


Radius: Vector: EFE9A25678B01B6B3B83104F7FC2E4A3

Radius: Type = 8 (0x08) Framed-IP-Address


Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF)


Radius: Length = 14 (0x0E)

Radius: Vendor ID = 3076 (0x00000C04)

Radius: Type = 85 (0x55) The tunnel group that tunnel must be associated with



%ASA-3-216001: internal error in es_PostEvent: event argument tag is unknown

52 45 4d 4f 54 45 | REMOTE

Radius: Type = 25 (0x19) Class

Radius: Length = 27 (0x1B)


43 41 43 53 3a 30 2f 33 65 33 32 2f 61 30 31 30 | CACS:0/3e32/a010

31 30 61 2f 36 35 35 33 36 | 10a/65536

rad_procpkt: ACCEPT

RADIUS_ACCESS_ACCEPT: normal termination

RADIUS_DELETE

remove_req 0xd5b1a8a8 session 0x1a id 8

free_rip 0xd5b1a8a8

radius: send queue empty





Outside interface: FastEthernet0/1




Mask: 255.255.255.255

DNS Primary: 10.1.1.50

NBMS/WINS Primary: 10.1.1.50




Default Domain: ipexpert.com

Save Password: Disallowed


Address : 10.1.1.0

Mask : 255.255.255.0

Protocol : 0x0

Source Port: 0

Dest Port : 0


R8#ping 10.1.1.100 so l8




!!!!!


ASA1(config)# sh vpn-sessiondb re

Session Type: IPsec

Username : VPNUSER Index : 16

Assigned IP : 10.80.80.1 Public IP : 8.9.2.8

Protocol : IKE IPsecOverNatT

License : IPsec

Encryption : 3DES Hashing : MD5


Group Policy : EZGROUP Tunnel Group : REMOTE

Login Time : 15:52:56 UTC Sat Oct 31 2009


NAC Result : Unknown

VLAN Mapping : N/A VLAN : none

Now turn down the IPSec tunnel, go to the ACS and change the group VPNUSER may connect to. Turn on ISAKMP debug on ASA1 and connect again:

R8#clear cry sess

ASA1# deb cry isa 7



Username: VPNUSER

Password:

ASA1#


Oct 31 16:13:08 [IKEv1 DEBUG]: IP = 8.9.2.8, Received xauth V6 VID

Oct 31 16:13:08 [IKEv1 DEBUG]: IP = 8.9.2.8, processing VID payload

Oct 31 16:13:08 [IKEv1 DEBUG]: IP = 8.9.2.8, Claims to be IOS but failed

authentication

Oct 31 16:13:08 [IKEv1 DEBUG]: IP = 8.9.2.8, processing VID payload

Oct 31 16:13:08 [IKEv1 DEBUG]: IP = 8.9.2.8, Received Cisco Unity client VID

Oct 31 16:13:08 [IKEv1]: IP = 8.9.2.8, Connection landed on tunnel_group REMOTE

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, processing IKE SA payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, IKE SA Proposal # 1,

Transform # 14 acceptable Matches global IKE entry # 1




Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing ISAKMP SA

payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing ke payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing nonce

payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, Generating keys for

Responder...

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing ID payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing hash payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, Computing hash for ISAKMP

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing Cisco Unity

VID payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing xauth V6 VID

payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing dpd vid

payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing NAT-

Traversal VID ver 02 payload


Discovery payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, computing NAT Discovery

hash


Discovery payload


hash

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing

Fragmentation VID + extended capabilities payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing VID payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, Send Altiga/Cisco

VPN3000/Cisco ASA GW VID

Oct 31 16:13:08 [IKEv1]: IP = 8.9.2.8, IKE_DECODE SENDING Message (msgid=0) with

payloads : HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + HASH (8) + VENDOR (13) +

VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + VENDOR (13) +

VENDOR (13) + NONE (0) total length : 428

Oct 31 16:13:08 [IKEv1]: IP = 8.9.2.8, IKE_DECODE RECEIVED Message (msgid=0) with

payloads : HDR + HASH (8) + NAT-D (130) + NAT-D (130) + NOTIFY (11) + NONE (0) total

length : 116

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, processing hash payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, Computing hash for ISAKMP

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, processing NAT-Discovery

payload


hash

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, processing NAT-Discovery

payload


hash

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, processing notify payload

Oct 31 16:13:08 [IKEv1]: Group = REMOTE, IP = 8.9.2.8, Automatic NAT Detection Status:

Remote end IS behind a NAT device This end IS behind a NAT device

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing blank hash

payload

Oct 31 16:13:08 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, constructing qm hash

payload

Oct 31 16:13:08 [IKEv1]: IP = 8.9.2.8, IKE_DECODE SENDING Message (msgid=343d44cf)

with payloads : HDR + HASH (8) + ATTR (14) + NONE (0) total length : 68

Oct 31 16:13:12 [IKEv1]: IP = 8.9.2.8, IKE_DECODE RECEIVED Message (msgid=343d44cf)

with payloads : HDR + HASH (8) + ATTR (14) + NONE (0) total length : 83

Oct 31 16:13:12 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, process_attr(): Enter!

Oct 31 16:13:12 [IKEv1 DEBUG]: Group = REMOTE, IP = 8.9.2.8, Processing MODE_CFG Reply

attributes.




%ASA-3-713060: Group = REMOTE, Username = VPNUSER, IP = 8.9.2.8, Tunnel Rejected: User

(VPNUSER) not member of group (REMOTE), group-lock check failed.

Oct 31 16:13:12 [IKEv1 DEBUG]: Group = REMOTE, Username = VPNUSER, IP = 8.9.2.8,

IKEGetUserAttributes: primary DNS = 10.1.1.50


IKEGetUserAttributes: secondary DNS = cleared


IKEGetUserAttributes: primary WINS = 10.1.1.50

-- Output omitted –

End Verification

4.11 ASA Easy VPN Server with External Group Authorization and PKI-Based Per-User Attributes

Change ASA1 configuration to use external group policy on the ACS.

Use R2 as the NTP and CA server. Synchronize time on ASA with R2.

Enroll VPN Client and ASA1 for certificate with R2.

Client‟s certificate should have CN set to “IP Expert” and OU set to “CCIE.”

Use 3DES encryption and MD-5 HMAC for both phases.

Name the policy “EXTERNAL” and store the following parameters on RADIUS server:

Use address pool 10.200.200.0/24 to allocate IP addresses. Tunnel only packets sent to 10.1.1.0/24.

Only the user “IP Expert” should receive a banner message saying, “You are now connected to the internal network” after the VPN connection has been established.

Configuration

R2

Set the time to match time on the Test PC. ntp master 2

ip http sever


crypto pki server CA_SERVER

grant auto

no sh

ASA1

ntp server 8.9.2.2

domain-name ipexpert.com


authentication rsa-sig

encryption 3des

hash md5

group 2

lifetime 86400




crypto ca trustpoint CA


subject-name cn=ASA1.ipexpert.com

crl configure

crypto ca authenticate CA

crypto ca enroll CA

group-policy EXTERNAL external server-group RAD password GRPASS

tunnel-group CCIE type remote-access

tunnel-group CCIE general-attributes

authorization-server-group RAD

default-group-policy EXTERNAL

authorization-required

username-from-certificate CN

tunnel-group CCIE ipsec-attributes

trust-point CA

isakmp ikev1-user-authentication none

ip local pool EZPOOL2 10.200.200.1-10.200.200.254

Test PC




ACS

Add route to the VPN pool and enable the necessary RADIUS attributes for the user:

route add 10.200.200.0 mask 255.255.255.0 10.1.1.10

-- omitted --

-- omitted--




Add new user “EXTERNAL” with password set to “GRPASS.” Set the Group Policy attributes as shown below:




Add user “IP Expert.” Set password the same as the username. This is different than on the IOS where you use “cisco” group password. Fill the banner attribute.


External group policies take their attribute values from the external server that you specify. For an external group policy, you must identify the AAA server group that the security appliance can query for attributes and specify the password to use when retrieving attributes from the external AAA server group. External group names on the security appliance refer to user names on the RADIUS server. In other words, if you configure external group X on the security appliance, the RADIUS server sees the query as an authentication request for user X. So external groups are really just user accounts on the RADIUS server that have special meaning to the security appliance.

When certificate-based authorization is configured, XAUTH should be disabled (isakmp ikev1-user-authentication none) because if both authentication and authorization are enabled, the security appliance uses the user login credentials for both user authentication and authorization. To specify which Subject Name‟s attribute should be used as the username for authorization, use the “username-from-certificate” command. The important thing to remember here is that ASA




expects the password to be the same as the username, whereas IOS uses always “cisco” as the password for authorization.

Verification

Connect the VPN Client. Turn on RADIUS debug on ASA1:

ASA1(config)# deb radius

ASA1(config)# radius mkreq: 0x22


new request 0x22 --> 13 (0xd5b1a8a8)

got user ''

got password

add_req 0xd5b1a8a8 session 0x22 id 13

RADIUS_REQUEST

radius.c: rad_mkpkt


--------------------------------------


01 0d 00 8e 0e 2f 3c c5 1a 4b 28 41 e6 27 d4 7d | ...../<..K(A.'.}

72 c3 40 79 01 0b 49 50 20 45 78 70 65 72 74 02 | [email protected] Expert.

12 32 55 a9 6f 09 17 45 68 4c 2a 61 5b ac cc 4a | .2U.o..EhL*a[..J

5f 05 06 00 01 40 00 06 06 00 00 00 02 07 06 00 | _....@..........

00 00 01 1e 0a 38 2e 39 2e 32 2e 31 30 1f 0b 38 | .....8.9.2.10..8

2e 39 2e 32 2e 32 30 30 3d 06 00 00 00 05 42 0b | .9.2.200=.....B.

38 2e 39 2e 32 2e 32 30 30 04 06 0a 01 01 0a 1a | 8.9.2.200.......

1f 00 00 00 09 01 19 69 70 3a 73 6f 75 72 63 65 | .......ip:source

2d 69 70 3d 38 2e 39 2e 32 2e 32 30 30 02 | -ip=8.9.2.200.



Radius: Identifier = 13 (0x0D)


Radius: Vector: 0E2F3CC51A4B2841E627D47D72C34079




49 50 20 45 78 70 65 72 74 | IP Expert




32 55 a9 6f 09 17 45 68 4c 2a 61 5b ac cc 4a 5f | 2U.o..EhL*a[..J_













38 2e 39 2e 32 2e 31 30 | 8.9.2.10







38 2e 39 2e 32 2e 32 30 30 | 8.9.2.200







38 2e 39 2e 32 2e 32 30 30 | 8.9.2.200





Radius: Length = 31 (0x1F)






2e 32 2e 32 30 30 02 | .2.200.

send pkt 10.1.1.100/1645



rip 0xd5b1f1c8

: chall_state ''

: state 0x7

: timer 0x0

: reqauth:

0e 2f 3c c5 1a 4b 28 41 e6 27 d4 7d 72 c3 40 79

: info 0x22

session_id 0x22

request_id 0xd

user 'IP Expert'

response '***'

app 0

reason 0

skey 'CISCO'

sip 10.1.1.100

type 1


--------------------------------------


02 0d 00 6b e6 88 71 3c e6 1a 75 a9 95 75 bb 7b | ...k..q<..u..u.{

9c da 42 16 08 06 ff ff ff ff 1a 36 00 00 0c 04 | ..B........6....

0f 30 59 6f 75 20 61 72 65 20 6e 6f 77 20 63 6f | .0You are now co

6e 6e 65 63 74 65 64 20 74 6f 20 74 68 65 20 69 | nnected to the i

6e 74 65 72 6e 61 6c 20 6e 65 74 77 6f 72 6b 2e | nternal network.

19 1b 43 41 43 53 3a 30 2f 33 66 31 38 2f 61 30 | ..CACS:0/3f18/a0

31 30 31 30 61 2f 38 31 39 32 30 | 1010a/81920



Radius: Identifier = 13 (0x0D)





Radius: Vector: E688713CE61A75A99575BB7B9CDA4216







Radius: Type = 15 (0x0F) Banner



59 6f 75 20 61 72 65 20 6e 6f 77 20 63 6f 6e 6e | You are now conn

65 63 74 65 64 20 74 6f 20 74 68 65 20 69 6e 74 | ected to the int

65 72 6e 61 6c 20 6e 65 74 77 6f 72 6b 2e | ernal network.




43 41 43 53 3a 30 2f 33 66 31 38 2f 61 30 31 30 | CACS:0/3f18/a010

31 30 61 2f 38 31 39 32 30 | 10a/81920

rad_procpkt: ACCEPT


RADIUS_DELETE

remove_req 0xd5b1a8a8 session 0x22 id 13

free_rip 0xd5b1a8a8

radius mkreq: 0x23


new request 0x23 --> 14 (0xd5b1a8a8)

got user ''

got password

add_req 0xd5b1a8a8 session 0x23 id 14

RADIUS_REQUEST

radius.c: rad_mkpkt


--------------------------------------


01 0e 00 8c be 1f 6c 35 ca 3b 58 b1 96 17 04 ed | ......l5.;X.....

22 b3 70 e9 01 0a 45 58 54 45 52 4e 41 4c 02 12 | ".p...EXTERNAL..

d8 8a e0 85 2d 02 ad 5e 6f a3 4b 4a 9e ca 9b fd | ....-..^o.KJ....

05 06 00 00 00 00 06 06 00 00 00 02 07 06 00 00 | ................

00 01 1e 0a 38 2e 39 2e 32 2e 31 30 1f 0b 38 2e | ....8.9.2.10..8.

39 2e 32 2e 32 30 30 3d 06 00 00 00 05 42 0b 38 | 9.2.200=.....B.8

2e 39 2e 32 2e 32 30 30 04 06 0a 01 01 0a 1a 1e | .9.2.200........

00 00 00 09 01 18 69 70 3a 73 6f 75 72 63 65 2d | ......ip:source-

69 70 3d 38 2e 39 2e 32 2e 32 30 30 | ip=8.9.2.200



Radius: Identifier = 14 (0x0E)


Radius: Vector: BE1F6C35CA3B58B1961704ED22B370E9




45 58 54 45 52 4e 41 4c | EXTERNAL







d8 8a e0 85 2d 02 ad 5e 6f a3 4b 4a 9e ca 9b fd | ....-..^o.KJ....













38 2e 39 2e 32 2e 31 30 | 8.9.2.10




38 2e 39 2e 32 2e 32 30 30 | 8.9.2.200







38 2e 39 2e 32 2e 32 30 30 | 8.9.2.200











2e 32 2e 32 30 30 | .2.200

send pkt 10.1.1.100/1645



rip 0xd5b1f1c8

: chall_state ''

: state 0x7

: timer 0x0

: reqauth:

be 1f 6c 35 ca 3b 58 b1 96 17 04 ed 22 b3 70 e9

: info 0x23

session_id 0x23

request_id 0xe

user 'EXTERNAL'

response '***'

app 0

reason 0

skey 'CISCO'

sip 10.1.1.100

type 1





--------------------------------------


02 0e 00 59 50 2c c4 6c 4d e7 d2 5f af 3a b6 b8 | ...YP,.lM.._.:..

4a d7 97 f8 08 06 ff ff ff ff 1a 0f 00 00 0c 04 | J...............

d9 09 45 5a 50 4f 4f 4c 32 1a 0d 00 00 0c 04 1b | ..EZPOOL2.......

07 53 50 4c 49 54 1a 0c 00 00 0c 04 37 06 00 00 | .SPLIT......7...

00 01 19 17 43 41 43 53 3a 30 2f 33 66 31 39 2f | ....CACS:0/3f19/

61 30 31 30 31 30 61 2f 30 | a01010a/0



Radius: Identifier = 14 (0x0E)


Radius: Vector: 502CC46C4DE7D25FAF3AB6B84AD797F8





Radius: Length = 15 (0x0F)


Radius: Type = 217 (0xD9) List of address pools to assign addresses from



45 5a 50 4f 4f 4c 32 | EZPOOL2


Radius: Length = 13 (0x0D)


Radius: Type = 27 (0x1B) Split-Tunnel-Inclusion-List



53 50 4c 49 54 | SPLIT




Radius: Type = 55 (0x37) Split-Tunneling-Policy


Radius: Value (Integer) = 1 (0x0001)




43 41 43 53 3a 30 2f 33 66 31 39 2f 61 30 31 30 | CACS:0/3f19/a010

31 30 61 2f 30 | 10a/0

rad_procpkt: ACCEPT


RADIUS_DELETE

remove_req 0xd5b1a8a8 session 0x23 id 14

free_rip 0xd5b1a8a8

radius: send queue empty




This would show up if turned on Passed Authentication logging:

ASA1(config)# sh vpn-sessiondb remote

Session Type: IPsec

Username : IP Expert Index : 20



License : IPsec

Encryption : 3DES Hashing : MD5


Group Policy : EXTERNAL Tunnel Group : CCIE

Login Time : 15:12:17 UTC Tue Nov 10 2009




End Verification




4.12 DMVPN Phase I

Configure DMVPN between R5, R6 and R7.

R7 should be seen as 8.9.2.7 on VLAN 2 and should act as a Hub in this configuration.

Traffic between VLAN 5 and VLAN 6 should be switched by the Hub.

Only one tunnel network is allowed for this task – 172.16.100.0/24.

Use AES 192 and SHA-1 for Phase I. Use 3DES and MD5 for Phase II. PSK “cisco” should be used for authentication.

Run EIGRP process to advertise both private networks to the Hub. Use AS 100.

You may create a static route on R7 for 8.9.50.0/24 network.

Configuration

ASA1

static (DMZ,outside) 8.9.2.7 10.7.7.7 netmask 255.255.255.255

access-l OUTSIDE_IN permit udp host 8.9.50.6 host 8.9.2.7 eq isakmp

access-l OUTSIDE_IN permit udp host 8.9.50.6 host 8.9.2.7 eq 4500

access-l OUTSIDE_IN permit udp host 8.9.50.5 host 8.9.2.7 eq isakmp

access-l OUTSIDE_IN permit udp host 8.9.50.5 host 8.9.2.7 eq 4500

access-group OUTSIDE_IN in interface outside

R7

ip route 8.9.50.0 255.255.255.0 10.7.7.10

cry isa key 0 cisco address 8.9.50.0 255.255.255.0


encr aes 192

hash sha



mode transport



interface Tunnel100

ip address 172.16.100.7 255.255.255.0

no ip redirects

ip nhrp map multicast dynamic

ip nhrp network-id 1

tunnel source FastEthernet0/1

tunnel mode gre multipoint

tunnel key 1

no ip split-horizon eigrp 100


router eigrp 100

network 172.16.100.7 0.0.0.0

no auto-summary




R5


encr aes 192




mode transport



interface Tunnel100

ip address 172.16.100.5 255.255.255.0

ip nhrp map 172.16.100.7 8.9.2.7

ip nhrp map multicast 8.9.2.7


ip nhrp nhs 172.16.100.7



tunnel key 1


router eigrp 100

network 10.5.5.0 0.0.0.255

network 172.16.100.5 0.0.0.0

no auto-summary

R6


encr aes 192




mode transport



interface Tunnel100

ip address 172.16.100.6 255.255.255.0

ip nhrp map 172.16.100.7 8.9.2.7



ip nhrp nhs 172.16.100.7



tunnel key 1


router eigrp 100

network 10.6.6.6 0.0.0.0

network 172.16.100.6 0.0.0.0

no auto-summary





The Dynamic Multipoint VPN (DMVPN) feature combines GRE tunnels, IPsec encryption, and NHRP routing to provide users an ease of configuration via crypto profiles - which override the requirement for defining static crypto maps - and dynamic discovery of tunnel endpoints. This feature relies on the following technologies:

1. GRE – A tunneling protocol which is designed to encapsulate IP unicast, multicast and broadcast traffic.

2. Multipoint GRE (mGRE) – Allows a single GRE interface to support multiple IPSec tunnels and simplifies the size and complexity of the configuration.

3. NHRP – A client-server resolution protocol used to map tunnel IP address to an NBMA address (maps L3 to another L3 address). Each spoke registers its real address when it boots and queries the NHRP database for real addresses of the destination spokes to build direct tunnels.

4. IPSec – Used to protect tunnels in the DMVPN solution.

DMVPN was introduced in multiple phases to address various topological needs. Phase I was designed mainly for hub to spoke communication where spoke to spoke traffic traverses the hub (hub routes spoke-to-spoke traffic). Spokes are configured with plain point-to-point GRE tunnel to the hub whereas the hub is configured with mGRE interface to accommodate multiple spoke connections. The “ip nhrp map multicast dynamic” command tells the hub how it should proceed with multicast/broadcast traffic for which it does not have a mapping available – all registered spokes will receive it. Note that spokes also have a static NHRP mapping configured – this is to register their public IP address on the hub.

Verification

Check the tunnel, NHRP and routing:

R7#sh cry isa pe

Peer: 8.9.50.5 Port: 4500 Local: 10.7.7.7

Phase1 id: 8.9.50.5

Peer: 8.9.50.6 Port: 4500 Local: 10.7.7.7

Phase1 id: 8.9.50.6

R7#sh cry sess br


K - No IKE

ivrf = (none)


8.9.50.5 Tu100 8.9.50.5 1d05h UA

8.9.50.6 Tu100 8.9.50.6 1d05h UA

R7#sh ip nhrp br

Target Via NBMA Mode Intfc Claimed

172.16.100.5/32 172.16.100.5 8.9.50.5 dynamic Tu100 < >

172.16.100.6/32 172.16.100.6 8.9.50.6 dynamic Tu100 < >

R7#sh ip route eig


D 10.6.6.0 [90/26882560] via 172.16.100.6, 1d05h, Tunnel100

D 10.5.5.0 [90/26882560] via 172.16.100.5, 1d05h, Tunnel100

R6#sh ip route ei


D 10.5.5.0 [90/28162560] via 172.16.100.7, 1d05h, Tunnel100




R5#sh ip route ei


D 10.6.6.0 [90/28162560] via 172.16.100.7, 1d05h, Tunnel100

Now make sure that packets are switched by the Hub. Turn off CEF on the tunnel interface and start the debug:

R7(config)#int tu 100

R7(config-if)#no ip route-cache

R7(config)#access-list 100 permit icmp host 172.16.100.5 host 10.6.6.6


R7#deb ip pac de 100

R5#ping 10.6.6.6



!!!!!


R5#

R7#

*Nov 13 17:21:26.192: IP: s=172.16.100.5 (Tunnel100), d=10.6.6.6, len 100, input

feature

*Nov 13 17:21:26.192: ICMP type=8, code=0, MCI Check(59), rtype 0, forus FALSE,


*Nov 13 17:21:26.192: FIBipv4-packet-proc: route packet from Tunnel100 src

172.16.100.5 dst 10.6.6.6

*Nov 13 17:21:26.192: FIBipv4-packet-proc: packet routing succeeded

*Nov 13 17:21:26.192: IP: s=172.16.100.5 (Tunnel100), d=10.6.6.6 (Tunnel100),

g=172.16.100.6, len 100, forward

*Nov 13 17:21:26.192: ICMP type=8, code=0

*Nov 13 17:21:26.192: IP: s=172.16.100.5 (Tunnel100), d=10.6.6.6 (Tunnel100), len 100,

post-encap feature

*Nov 13 17:21:26.192: ICMP type=8, code=0, IPSEC Post-encap output

classification(12), rtype 0, forus FALSE, sendself FALSE, mtu 0


sending full packet


*Nov 13 17:21:26.224: IP: s=10.6.6.6 (Tunnel100), d=172.16.100.5, len 10

R7#0, input feature

*Nov 13 17:21:26.224: ICMP type=0, code=0, MCI Check(59), rtype 0, forus FALSE,


*Nov 13 17:21:26.224: FIBipv4-packet-proc: route packet from Tunnel100 src 10.6.6.6

dst 172.16.100.5


*Nov 13 17:21:26.224: IP: s=10.6.6.6 (Tunnel100), d=172.16.100.5 (Tunnel100),

g=172.16.100.5, len 100, forward



post-encap feature

*Nov 13 17:21:26.224: ICMP type=0, code=0, IPSEC Post-encap output

classification(12), rtype 0, forus FALSE, sendself FALSE, mtu 0


sending full packet


Remember to remove any configuration you used for testing and turn off debugs.

End Verification




4.13 DMVPN Phase II

Change the existing configuration from Task 4.12 to enable Spoke-To-Spoke tunnels.

Traffic from R5 to R6 should not flow across the Hub.

Configuration

R7

interface Tunnel100

no ip next-hop-self eigrp 100

R5, R6

interface Tunnel100

no tunnel destination


R5

cry isa key 0 cisco ad 8.9.50.6

R6

cry isa key 0 cisco add 8.9.50.5


Phase II introduced the ability for dynamic spoke-to-spoke tunnels without having the traffic to go through the hub. Spokes are also configured with mGRE interface to emulate a multi-access network.

For spoke-to-spoke to work correctly, the hub must preserve and advertise the private network's next hop as advertised by the spokes themselves (as the tunnel interface IP address). Different routing protocols behave differently in terms of preserving the next-hop information:

1. EIGRP – Next-Hop preservation is not default. Turn it on using “no ip next-hop-self eigrp <AS>” command. Also remember to turn off Split Horizion.

2. RIP – Keeps the next-hop information by default. 3. OSPF – Next-Hop preservation happens naturally except in point-to-multipoint mode. 4. BGP – Next-Hop preservation is a default (within the same AS). Hub must be configured

as a route reflector.

Verification

Note that now R6 is shown as the Next-Hop for VLAN 6 network:

R5#sh ip route ei


D 10.6.6.0 [90/28162560] via 172.16.100.6, 01:06:42, Tunnel100

R5#sh ip nhrp br


172.16.100.7/32 172.16.100.7 8.9.2.7 static Tu100 < >




R5#sh cry sess br


K - No IKE

ivrf = (none)


8.9.2.7 Tu100 10.7.7.7 01:08:02 UA

Try to ping VLAN 6 interface. Note that additional logical to physical mapping has been added.

R5#ping 10.6.6.6 so f0/1




!!!!!


R5#sh ip nhrp br


172.16.100.5/32 172.16.100.5 8.9.50.5 dynamic Tu100 < >

172.16.100.6/32 172.16.100.6 8.9.50.6 dynamic Tu100 < >

172.16.100.7/32 172.16.100.7 8.9.2.7 static Tu100 < >

R5#sh ip cef 10.6.6.6

10.6.6.0/24

nexthop 172.16.100.6 Tunnel100

R5#sh cry sess br


K - No IKE

ivrf = (none)


8.9.2.7 Tu100 10.7.7.7 01:11:40 UA

8.9.50.6 Tu100 8.9.50.6 00:00:02 UA

8.9.50.6 Tu100 8.9.50.6 00:00:02 UA

R5#sh cry isa pe

Peer: 8.9.2.7 Port: 4500 Local: 8.9.50.5

Phase1 id: 10.7.7.7

Peer: 8.9.50.6 Port: 500 Local: 8.9.50.5

Phase1 id: 8.9.50.6

R5#sh cry sess remote 8.9.50.6 detail | begin Tunnel


Interface: Tunnel100

Uptime: 00:01:37



Phase1_id: 8.9.50.6

Desc: (none)





IPSEC FLOW: permit 47 host 8.9.50.5 host 8.9.50.6




End Verification




4.14 DMVPN Phase III

Change the existing configuration from Task 4.12 and Task 4.13.

Force EIGRP on R7 to change the Next-Hop information.


Configuration

R7

interface tunnel 100

ip next-hop eigrp 100

ip nhrp redirect

R5


ip nhrp shortcut

ip nhrp redirect

R6


ip nhrp shortcut

ip nhrp redirect


In a DMVPN Phase 2 network, each DMVPN network is independent and causes traffic between spokes in different regions to have to traverse through the regional hubs (didn't have to go through the central hubs). In a DMVPN Phase 3 network, all the regional DMVPN networks are "glued" together into a single hierarchical DMVPN network (including the central hubs) and spokes in different regions can build direct spoke-to-spoke tunnels with each other, bypassing both the regional and central hubs.

Our example shows that this feature, among other things, allows data packets to be Cisco Express Forwarding switched along the routed path until a spoke-to-spoke tunnel is established. More over, although the spokes use routes with the IP next-hop set to the hub router, traffic will bypass the hub. This is because this feature forces NHRP entries to overwrite CEF. To enable NHRP shortcut switching, all spokes need to have the commands “ip nhrp shortcut” and the “ip nhrp redirect” added to their tunnel interfaces. For the hubs use only “ip nhrp redirect.”

Verification

Make sure that the Next-Hop is set to R7. CEF confirms that.

R5#sh ip nhrp br


172.16.100.5/32 172.16.100.5 8.9.50.5 dynamic Tu100 < >

172.16.100.7/32 172.16.100.7 8.9.2.7 static Tu100 < >

R5#sh ip route ei


D 10.6.6.0 [90/28162560] via 172.16.100.7, 00:14:54, Tunnel100

R5#sh ip cef 10.6.6.6

10.6.6.0/24










R5#ping 10.6.6.6 so f0/1 rep 2




!!


R7#

*Nov 13 20:39:26.927: NHRP: Send Traffic Indication via Tunnel100 vrf 0, packet size:

84

*Nov 13 20:39:26.927: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Nov 13 20:39:26.927: shtl: 4(NSAP), sstl: 0(NSAP)

*Nov 13 20:39:26.927: pktsz: 84 extoff: 68

*Nov 13 20:39:26.927: (M) traffic code: redirect(0)

*Nov 13 20:39:26.927: src NBMA: 10.7.7.7

*Nov 13 20:39:26.927: src protocol: 172.16.100.7, dst protocol: 10.5.5.5

*Nov 13 20:39:26.927: Contents of nhrp traffic indication packet:

*Nov 13 20:39:26.927: 45 00 00 64 00 21 00 00 FE 01 9D 62 0A 05 05 05

*Nov 13 20:39:26.927: 0A 06 06 06 08 00 73 7D 00 09 00

*Nov 13 20:39:26.959: NHRP: Send Traffic Indication via Tunnel100 vrf 0, packet size:

84



*Nov 13 20:39:26.959: pktsz: 84 extoff: 68

*Nov 13 20:39:26.959: (M) traffic code: redirect(0)

*Nov 13 20:39:26.959: src NBMA: 10.7.7.7


*Nov 13 20:39:26.959: Contents of nhrp traffic indication packet:

*Nov 13 20:39:26.959: 45 00 00 64 00 21 00 00 FE 01 9D 62 0A 06 06 06

*Nov 13 20:39:26.959: 0A 05 05 05 00 00 7B 7D 00 09 00

Now make sure that packets are not switched by the Hub. Turn off CEF on the tunnel interface and start the debug:






R5#ping 10.6.6.6




!!!!!





No packets are flowing through the Hub:

R7#



D 10.6.6.0 [90/28162560] via 172.16.100.7, 01:10:15, Tunnel100

R5#sh ip cef 10.6.6.6

10.6.6.0/24


Note that even CEF points to the Hub, NHRP overwrites it:

R5#sh ip nhrp brief


10.6.6.0/24 172.16.100.6 8.9.50.6 dynamic Tu100 < >

172.16.100.7/32 172.16.100.7 8.9.2.7 static Tu100 < >

R5#sh cry isa pe

Peer: 8.9.2.7 Port: 4500 Local: 8.9.50.5

Phase1 id: 10.7.7.7

Peer: 8.9.50.6 Port: 500 Local: 8.9.50.5

Phase1 id: 8.9.50.6

R5#sh cry sess de






Uptime: 00:01:46



Phase1_id: 10.7.7.7

Desc: (none)


Capabilities:N connid:1013 lifetime:23:58:13






Uptime: 00:01:35



Phase1_id: 8.9.50.6

Desc: (none)







End Verification




4.15 Redundant GET VPN

Configure GET VPN between R2, R5 and R6.

R2 should act as primary KS.

Protect the ICMP traffic between GMs.

Use AES 192 and SHA-1 for both phases. Use pre-shared key “ipexpert” for authentication.

Rekey messages should be sent as multicast to 239.5.5.5.

Secure the re-key transmission.

Configure R4 as redundant KS.

Configuration

R2

ip multicast-routing

!

inteface Serial0/1/0

ip pim sparse-mode

ip pim nbma

ip pim dr-priority 250

!

ip pim rp-address 8.9.50.2

!


encr aes 192

hash sha





!

cry isa keepalive 10 periodic

!

access-list 150 permit icmp host 8.9.50.5 host 8.9.50.6


!

ip access-list extended REKEY


!

crypto ipsec transform-set GETSET esp-aes 192 esp-sha-hmac

crypto ipsec profile IPSEC_GET_PROF

set transform-set GETSET

!

crypto key generate rsa label GETKEY exportable

!




crypto gdoi group GR1

identity number 1

server local

rekey address ipv4 REKEY

rekey retransmit 10 number 2

rekey authentication mypubkey rsa GETKEY

sa ipsec 1

profile IPSEC_GET_PROF

match address ipv4 150

replay counter window-size 64

address ipv4 8.9.50.2

redundancy

local priority 15

peer address ipv4 8.9.50.4

!

cry key export rsa GETKEY pem terminal 3des cisco123

R4


!


ip pim sparse-mode

ip pim nbma

!


!


encr aes 192

hash sha





!

cry isa keepalive 10 periodic

crypto key import rsa GETKEY terminal cisco123

!

!-- Copy&Paste Public and then Private Key -- !



!

ip access-list extended REKEY


crypto ipsec transform-set GETSET esp-aes 192 esp-sha-hmac

crypto ipsec profile IPSEC_GET_PROF

set transform-set GETSET

profile IPSEC_GET_PRO

!





identity number 1

server local

rekey address ipv4 REKEY

rekey retransmit 10 number 2

rekey authentication mypubkey rsa GETKEY

sa ipsec 1

profile IPSEC_GET_PROF

match address ipv4 150

replay counter window-size 64

address ipv4 8.9.50.4

redundancy

local priority 1

peer address ipv4 8.9.50.2

R2 & R4

redundancy

R5, R6


!


ip pim sparse-mode

ip pim nbma

ip pim dr-priority 250

!


!


encr aes 192

hash sha





identity number 1

server address ipv4 8.9.50.2

server address ipv4 8.9.50.4

crypto map MAP1 15 gdoi

set group GR1


crypto map MAP1


GET VPN (tunnel-less VPN) eliminates the need for tunnels. By removing the need for point-to-point tunnels, meshed networks can scale higher while maintaining network-intelligence features critical to voice and video quality. GET VPN offers a new standards-based security model that is based on the concept of "trusted" group members. Trusted member routers use a common security methodology that is independent of any point-to-point IPsec tunnel relationship.

Issue the redundancy command from global configuration and do it after you have both of the Key Servers up and functional.




The Group Member (GM) is the router that registers with the key server to get the IPsec SA to communicate with other devices in the group. During registration, group member provides the group ID and receives the security policy and keys for this group from the server (KS). The registration process consists of ISAKMP Phase I followed by the GDOI exchange – the key server authenticates and authorizes the group members. ISAKMP/GDOI connection works over UDP port 848.

Key Server is the router responsible for maintaining the policy and creating and maintaining the keys for the group. The key server also rekeys the group before existing keys expire. The server can send two types of keys: the traffic encryption key (TEK) and the key encryption key (KEK). The TEK is the shared key used by IPsec SAs to protect data, whereas the KEK is used to encrypt the rekey messages (which mostly contain new TEKs and possibly new KEK) and is used by the group members to decrypt the incoming rekey messages from the key server.

Cooperative key servers (COOP KS) provide redundancy to GET VPN. Multiple key servers are supported by GET VPN to ensure redundancy, high availability, and fast recovery if the primary key server fails. Cooperating GDOI key servers jointly manage the GDOI registrations for the group. Each key server is an active key server, handling GDOI registration requests from group members. Because the key servers are cooperating, each key server distributes the same state to the group members that register with it. Load balancing is achieved because each of the GDOI key servers can service a portion of the GDOI registrations.

Before you start doing any GET VPN configuration make sure to take care of ISAKMP Phase I policy. If pre-shared keys are used for authentication, spokes should have only one key configured – for the KS. GET VPN configuration involves setting the group ID, group ACL, IPSec protection and optionally rekeying and COOP KS.

COOP configuration requires the policy to be the same on both key servers. Higher priority value determines which server will act as primary for the group. RSA keys have to be configured as exportable and copied to the secondary KS. This is because server‟s public key is downloaded during the registration and will be used to authenticate incoming rekey messages.

Verification

After properly configuring KSs and GMs, you should see the following syslog message:

R5(config)#

*Nov 15 20:03:03.637: %GDOI-5-GM_REGS_COMPL: Registration to KS 8.9.50.2

complete for group GR1 using address 8.9.50.5




R2#sh cry gd

GROUP INFORMATION

Group Name : GR1 (Multicast)

Group Identity : 1

Group Members : 2

IPSec SA Direction : Both

Active Group Server : Local

Redundancy : Configured

Local Address : 8.9.50.2

Local Priority : 15

Local KS Status : Alive

Local KS Role : Primary

Group Rekey Lifetime : 86400 secs

Group Rekey

Remaining Lifetime : 86042 secs

Rekey Retransmit Period : 10 secs

Rekey Retransmit Attempts: 2

Group Retransmit

Remaining Lifetime : 0 secs

IPSec SA Number : 1

IPSec SA Rekey Lifetime: 3600 secs

Profile Name : IPSEC_GET_PROF

Replay method : Count Based

Replay Window Size : 64

ACL Configured : access-list 150

Group Server list : Local

R2#sh cry gd ks

Total group members registered to this box: 2

Key Server Information For Group GR1:

Group Name : GR1

Group Identity : 1

Group Members : 2


ACL Configured:

access-list 150



Local Priority : 15



R2#sh cry gd ks mem

Group Member Information :

Number of rekeys sent for group GR1 : 0

Group Member ID : 8.9.50.5

Group ID : 1

Group Name : GR1

Key Server ID : 0.0.0.0

Group Member ID : 8.9.50.6

Group ID : 1

Group Name : GR1

Key Server ID : 0.0.0.0




R2#sh cry gd ks reke

Group GR1 (Multicast)


Number of Rekeys sent : 1

Number of Rekeys retransmitted : 0

KEK rekey lifetime (sec) : 86400

Remaining lifetime (sec) : 85922

Retransmit period : 10

Number of retransmissions : 2

IPSec SA 1 lifetime (sec) : 3600

Number of registrations after rekey : 0

Multicast destination address : 239.5.5.5

R4#sh cry gd ks



Group Name : GR1

Group Identity : 1

Group Members : 2


ACL Configured:

access-list 150



Local Priority : 1


Local KS Role : Secondary

R4#sh cry gd ks coop

Crypto Gdoi Group Name :GR1

Group handle: 2147483650, Local Key Server handle: 2147483650

Local Address: 8.9.50.4

Local Priority: 1

Local KS Role: Secondary , Local KS Status: Alive

Secondary Timers:

Sec Primary Periodic Time: 30

Remaining Time: 25, Retries: 0

Antireplay Sequence Number: 19

Peer Sessions:

Session 1:

Server handle: 2147483651

Peer Address: 8.9.50.2

Peer Priority: 15

Peer KS Role: Primary , Peer KS Status: Alive


IKE status: Established

Counters:

Ann msgs sent: 13

Ann msgs sent with reply request: 6

Ann msgs recv: 28

Ann msgs recv with reply request: 3

Packet sent drops: 0

Packet Recv drops: 0

Total bytes sent: 8806

Total bytes recv: 18436




R5#sh cry gd gm acl

Group Name: GR1

ACL Downloaded From KS 8.9.50.2:

access-list permit icmp host 8.9.50.5 host 8.9.50.6


ACL Configured Locally:

R5#sh cry gdoi gm reke


Number of Rekeys received (cumulative) : 0

Number of Rekeys received after registration : 0

Rekey (KEK) SA information :

dst src conn-id my-cookie his-cookie

New : 239.5.5.5 8.9.50.2 1018 85A2A2B9 2A54FE85

Current : --- --- --- --- ---

Previous: --- --- --- --- ---

R6(config)#do sh cry gd

GROUP INFORMATION

Group Name : GR1

Group Identity : 1

Rekeys received : 0


Active Group Server : 8.9.50.2

Group Server list : 8.9.50.2

8.9.50.4

GM Reregisters in : 3105 secs

Rekey Received : never

Rekeys received

Cumulative : 0

After registration : 0




KEK POLICY:

Rekey Transport Type : Multicast

Lifetime (secs) : 85861

Encrypt Algorithm : 3DES

Key Size : 192

Sig Hash Algorithm : HMAC_AUTH_SHA

Sig Key Length (bits) : 1024

TEK POLICY:

Serial0/1/0:

IPsec SA:

sa direction:inbound

spi: 0x130E9C5A(319724634)

transform: esp-192-aes esp-sha-hmac

sa timing:remaining key lifetime (sec): (44)

Anti-Replay(Counter Based) : 64

IPsec SA:

sa direction:outbound

spi: 0x130E9C5A(319724634)







IPsec SA:


spi: 0x10DE2FD4(282996692)




IPsec SA:


spi: 0x10DE2FD4(282996692)




IPsec SA:


spi: 0x130E9C5A(319724634)




IPsec SA:


spi: 0x130E9C5A(319724634)




IPsec SA:


spi: 0x10DE2FD4(282996692)




IPsec SA:


spi: 0x10DE2FD4(282996692)




R6#sh cry isa sa



8.9.50.2 8.9.50.6 GDOI_IDLE 1018 ACTIVE

8.9.50.6 8.9.2.7 QM_IDLE 1017 ACTIVE

239.5.5.5 8.9.50.2 GDOI_REKEY 1019 ACTIVE

Ping R5 and verify IPSec :




R6#sh cry sessio int s0/1/0 de






Uptime: 00:22:23



Phase1_id: 8.9.50.2

Desc: (none)




Capabilities:(none) connid:1019 lifetime:6w3d









Now shutdown R2‟s serial 0/1/0. Verify R4 is chosen as the KS:

R4#sh cry gd ks



Group Name : GR1

Group Identity : 1

Group Members : 2


ACL Configured:

access-list 150



Local Priority : 1



R4#sh cry gdoi ks coop

Crypto Gdoi Group Name :GR1

Group handle: 2147483650, Local Key Server handle: 2147483650

Local Address: 8.9.50.4

Local Priority: 1

Local KS Role: Primary , Local KS Status: Alive

Primary Timers:

Primary Refresh Policy Time: 20

Remaining Time: 17


Peer Sessions:

Session 1:

Server handle: 2147483651

Peer Address: 8.9.50.2

Peer Priority: 1

Peer KS Role: Secondary , Peer KS Status: Dead





IKE status: In Progress

Counters:

Ann msgs sent: 0

Ann msgs sent with reply request: 0

Ann msgs recv: 0

Ann msgs recv with reply request: 0

Packet sent drops: 19

Packet Recv drops: 0

Total bytes sent: 0

Total bytes recv: 0

R5#sh cry gd

GROUP INFORMATION

Group Name : GR1

Group Identity : 1

Rekeys received : 0




8.9.50.4


Rekey Received : never

Rekeys received

Cumulative : 0





KEK POLICY:

Rekey Transport Type : Multicast

Lifetime (secs) : 86295

Encrypt Algorithm : 3DES

Key Size : 192

Sig Hash Algorithm : HMAC_AUTH_SHA

Sig Key Length (bits) : 1024


End Verification




4.16 ASA WebVPN

ASA2 should allow for WebVPN connections on its outside interface port 1443.

Create user “remote” with password “remote”; that user should authenticate to group WEBGROUP.

Remote users should be able to access R8‟s console after telnetting locally on port 2023.

Disable the ability to enter any HTTP/HTTPS URL on the portal page.

Configuration

ASA2

webvpn

port 1443

enable outside

port-forward PF 2023 192.168.8.8 telnet TELNET TO R8

tunnel-group-list enable

group-policy WEBPOL internal

group-policy WEBPOL attributes

vpn-tunnel-protocol webvpn

webvpn

port-forward enable PF

url-entry disable

username remote password remote

tunnel-group WEBGROUP type remote-access

tunnel-group WEBGROUP general-attributes

default-group-policy WEBPOL

tunnel-group WEBGROUP webvpn-attributes

group-alias WEBGROUP enable


SSL VPN can be deployed in one of the following modes :

1. Clientless – Content can be securely access via a web browser (but only web-based content is accessible).

2. Thin client (Port Forwarding) – This mode provides access to TCP-based services like Telnet or SSH. Thin client is delivered via a Java applet that is dynamically downloaded from the SSL VPN appliance upon session establishment.

3. Thick client (client mode) – remote access is provided by downloading SSL VPN client software such as AnyConnect. This mode delivers L3 access to virtually any application.

WebVPN configuration involves setting some SSL-specific options as well as defining a group policy and a tunnel group. Global “webvpn” mode allows us to choose the port ASA will be accepting the incoming SSL connections on, plus we can also define our Port Forwarding configuration and enable the tunnel group list. The tunnel group list allows the users to select a group for login and authentication.

Clientless SSL VPN attributes and options for tunnel groups and group policies can be looked up here and here, respectively.






Verification

Login to the Portal Page from Test PC:




Now telnet locally on port 2023 and you will get the R8‟s CLI prompt:

ASA2(config)# sh vpn-sessiondb de webvpn

Session Type: WebVPN Detailed

Username : remote Index : 3

Public IP : 8.9.2.200

Protocol : Clientless

License : SSL VPN

Encryption : RC4 Hashing : SHA1


Pkts Tx : 3 Pkts Rx : 0

Pkts Tx Drop : 0 Pkts Rx Drop : 0

Group Policy : WEBPOL Tunnel Group : WEBGROUP

Login Time : 14:45:45 UTC Fri Nov 6 2009




Clientless Tunnels: 1

Clientless:

Tunnel ID : 3.1

Public IP : 8.9.2.200


Encapsulation: SSLv3 TCP Dst Port : 1443

Auth Mode : userPassword

Idle Time Out: 30 Minutes Idle TO Left : 29 Minutes

Client Type : Web Browser

Client Ver : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)


NAC:

Reval Int (T): 0 Seconds Reval Left(T): 0 Seconds

SQ Int (T) : 0 Seconds EoU Age(T) : 24 Seconds

Hold Left (T): 0 Seconds Posture Token:

Redirect URL :

End Verification




4.17 ASA SSL VPN (AnyConnect)

Configure ASA2 to provide SSL client connections for remote users.

Create user “ssluser” with password “remote”; that user should be only able to successfully authenticate to group SSLGROUP.

Use local IP address pool 10.170.170.0/24 for the connecting clients.

ASA should only allow access to 192.168.8.0/24 via the tunnel.

Make sure you can ping R8 from the client‟s Test PC.

For SSL connection use the protocol that avoids latency and bandwidth problems.

Configuration

ASA2

webvpn

svc image disk0:/anyconnect-dart-win-2.4.0202-k9.pkg 1

svc enable

port 443

access-list SSLSPLIT standard permit 192.168.8.0 255.255.255.0

ip local pool SSLPOOL 10.170.170.1-10.170.170.254

username ssluser attributes

group-lock value SSLGROUP

group-policy SSLPOL internal

group-policy SSLPOL attributes

vpn-tunnel-protocol svc


split-tunnel-network-list value SSLSPLIT

address-pools value SSLPOOL

webvpn

svc dtls enable

svc ask none default svc

tunnel-group SSLGROUP type remote-access

tunnel-group SSLGROUP general-attributes

default-group-policy SSLPOL

tunnel-group SSLGROUP webvpn-attributes

group-alias SSLGROUP enable

access-list NATEXEMPT extended permit ip host 192.168.8.8

10.170.170.0 255.255.255.0

nat (inside) 0 access-list NATEXEMPT


Configuring SSL VPN in the ASA is similar to regular WebVPN configuration. In addition to a standard group policy (here “vpn-tunnel-protocol” has to be set to svc) and tunnel group configuration, there are a few steps that are client SSL VPN specific. The port we are using has to be changed back to 443 and SVC image has to be loaded to the appliance. Address pool has to be also configured whereas Split Tunneling is optional.




NAT Exemption is required for R8 to successfully communicate with SSL VPN clients.

Using DTLS, which is UDP-based, reduces the delays associated with stream protocols (delay and latency can result in poor VoIP and other real-time applications quality).

Lastly, whenever you are testing SSL VPN client mode scenario you should use a VNC client instead of RDP to the Test PC.

Verification

Open AnyConnect client on Test PC and log in:




Ping R8:

ASA2(config)# sh webvpn svc

1. disk0:/anyconnect-dart-win-2.4.0202-k9.pkg 1 dyn-regex=/Windows NT/

CISCO STC win2k+

2,4,0202

Fri 10/09/2009 9:17:38.30

1 SSL VPN Client(s) installed

ASA2(config)# sh webvpn group-alias

Tunnel Group: WEBGROUP Group Alias: WEBGROUP enabled

Tunnel Group: SSLGROUP Group Alias: SSLGROUP enabled

ASA2(config)# sh vpn-sessiondb de svc

Session Type: SVC Detailed

Username : ssluser Index : 18


Protocol : Clientless SSL-Tunnel DTLS-Tunnel

License : SSL VPN

Encryption : RC4 AES128 Hashing : SHA1







Group Policy : SSLPOL Tunnel Group : SSLGROUP

Login Time : 13:56:29 UTC Sat Nov 7 2009





SSL-Tunnel Tunnels: 1

DTLS-Tunnel Tunnels: 1

Clientless:

Tunnel ID : 18.1

Public IP : 8.9.2.200






Client Ver : AnyConnect Windows 2.4.0202


SSL-Tunnel:

Tunnel ID : 18.2



Encapsulation: TLSv1.0 TCP Src Port : 1199

TCP Dst Port : 443 Auth Mode : userPassword


Client Type : SSL VPN Client

Client Ver : Cisco AnyConnect VPN Agent for Windows 2.4.0202




DTLS-Tunnel:

Tunnel ID : 18.3


Encryption : AES128 Hashing : SHA1

Encapsulation: DTLSv1.0 UDP Src Port : 1207

UDP Dst Port : 443 Auth Mode : userPassword


Client Type : DTLS VPN Client

Client Ver : AnyConnect Windows 2.4.0202




NAC:




Redirect URL

End Verification




4.18 IOS Clientless SSL VPN

Configure R4 to provide WebVPN connections on s0/0/0 interface port 443.

HTTP connections should be redirected to HTTPS automatically.

Create user “ssluser” with password “remote”; that user should authenticate in domain IPEXPERT.

Remote users should be able to access HTTP on CAT2 through the URL link on the portal page.

Console access to CAT2 should also be available after telnetting locally on port 10023.

Configuration

R4

aaa new-model


aaa authentication login SSLAUTH local

line con 0

login authentication NO

webvpn gateway SSLGW

ip address 8.9.50.4 port 443

http-redirect port 80

inservice

webvpn context SSLCONTEXT

ssl authenticate verify all

url-list "Cat2"

url-text "Cat2_HTTP" url-value "http://10.4.4.20"

port-forward "PF"

local-port 10023 remote-server "10.4.4.20" remote-port 23 description

"Telnet to CAT2"

policy group SSLPOL

url-list "Cat2"

port-forward "PF"


aaa authentication list SSLAUTH

gateway SSLGW domain IPEXPERT

inservice


IOS SSL VPN configuration consists of few components. The gateway is the destination IP endpoint for the user session, and the context is where the policy group is defined and applied to the user session. The policy group determines the parameters of the user session, and how the

session will behave.

General SSL process on IOS can be described in four steps. This applies to all SSL modes:

1. The end user initiates the SSL VPN connection to the WebVPN gateway.




2. The context a user is attempting to connect to is identified by the URL or login information. Now the user must be authenticated under the context they belong to. 3. The secure gateway must determine if it will let this user into the WebVPN context, so it will send the username and password to the AAA server. The method of AAA does not matter, just so authentication can be done. 4. The AAA server authenticates the user and it will indicate this to the context. It may also push down any RADIUS attributes for that user. The WebVPN context will build a user session under the context, and apply the policy group information and RADIUS attributes. Now the workflow changes depending on the policy group parameters applied to the user session.

In Clientless mode, which is the default mode for a context, the process is complete. The WebVPN portal will now be displayed to the end user in the Web browser. The user will have the specified access to the VPN.

In our example the SSL gateway configuration does not have a specific SSL trustpoint assigned. It means that a self-signed certificate is automatically generated when an SSL VPN gateway is put in service and the auto-generated trustpoint will be associated with it. Additionally, remember that whenever you are doing any AAA configuration you should think about safeguarding the console and/or whatever else they ask you to do in that matter in the real exam.

Verification

Login to the Portal from Test PC. The exact URL should contain the context : http://8.9.50.4/IPEXPERT

Make sure there is a separate bookmark and link for CAT2‟s HTTP Server:

http://8.9.50.4/IPEXPERT




Here we enabled our thin client application:

After telnetting locally on 10023 we got CAT2‟s prompt:

R4#sh webvpn context

Codes: AS - Admin Status, OS - Operation Status

VHost - Virtual Host

Context Name Gateway Domain/VHost VRF AS OS

------------ ------- ------------ ------- ---- --------

SSLCONTEXT SSLGW IPEXPERT - up up

R4#




R4#sh webvpn session user ssluser context SSLCONTEXT

WebVPN user name = ssluser ; IP address = 8.9.2.200 ; context = SSLCONTEXT

No of connections: 1

Created 00:00:03, Last-used 00:00:02

Client Port: 1184

User Policy Parameters

Group name = SSLPOL

Group Policy Parameters

url list name = "Cat2"

idle timeout = 2100 sec

session timeout = 43200 sec

port forward name = "PF"

functions =

citrix disabled

dpd client timeout = 300 sec

dpd gateway timeout = 300 sec

keepalive interval = 30 sec

keep sslvpn client installed = disabled

rekey interval = 3600 sec

rekey method =

lease duration = 43200 sec

End Verification

4.19 IOS SSL VPN (AnyConnect)

Configure R4 to provide SSL client connections for remote users.

Create a separate context for domain “SSL” and make sure only AnyConnect clients are allowed to connect to it.

Portal page should contain a black heaading “IPEXPERT ANYCONNECT.”


Tunnel only traffic going to 10.4.4.0/24.

Assign the clients domain-name of “ipexpert.com” and DNS Server of 10.4.4.20.

Configuration

R4

ip local pool ANYPOOL 10.140.140.2 10.140.140.254

int loopback 100

ip address 10.140.140.1 255.255.255.0

webvpn install svc flash:/webvpn/svc_1.pkg sequence 1

webvpn context ANYCONNECT_CONTEXT

title "IPEXPERT ANYCONNECT"

title-color black





policy group ANYCONNECT_POL

functions svc-required

svc address-pool "ANYPOOL"

svc default-domain "ipexpert.com"

svc split include 10.4.4.0 255.255.255.0

svc dns-server primary 10.4.4.20

default-group-policy ANYCONNECT_POL


gateway SSLGW domain SSL

inservice

Test PC

Add route to 8.9.50.0/24 : route add 8.9.50.0 mask 255.255.255.0 8.9.2.2


If the user is going to do Tunnel mode, using function “svc-enabled” or “svc-required” in the group policy or RADIUS attributes, the process to push down the SSL VPN Client will happen next, in addition to the four general steps described in the solution to previous task. This will mean that the SSL VPN Client once installed on the client PC will establish a new SSL session to the context, and the original context will be removed. Furthermore, it will alter the PC routing table to do the specified tunnel function defined in the policy. Now that the user session is established to the WebVPN secure gateway, the backend interfaces handle the access to the inside network. Once a user is authenticated under a given context, the user session is established. This user session will embody the parameters specified globally in the context, the group policy, and any RADIUS attributes pushed down during authentication for that user.

From the configuration standpoint, at least two things have to be added. First is to load the SVC image to the router. The rest is the IP address pool and in our case also the loopback interface which must be configured with an IP address and subnet mask from the address pool. The interface would not be necessary if you used a pool reachable from a directly connected network. Finally, the pool and other task-specific configuration should be added to the new context‟s group policy.

If you experience any problems when connecting using AnyConnect version 2.4 (certificate validation error) it may be a bug with this software version. The workaround to this issue is shown below.

Configure a new trustpoint on R4 setting FQDN&CN to R4.ipexpert.com. Set it for SSL gateway:

crypto pki trustpoint ANYTP

enrollment selfsigned

fqdn R4.ipexpert.com



crypto pki enroll ANYTP

webvpn gateway SSLGW

no inservice

ssl trustpoint ANYTP

inservice

Configure a local DNS mapping in C:\WINDOWS\system32\drivers\etc\hosts:

8.9.50.4 R4.ipexpert.com




Connect via http://R4.ipexpert.com/SSL. When it prompt you about untrusted certificate, click on “Veritfy” and install it.

Verification

Open the following URL in order to download/upgrade the client : http://8.9.50.4/SSL

http://r4.ipexpert.com/SSL

http://8.9.50.4/SSL




Ping CAT2. This should work because RIP advertises whole 10.0.0.0/8 which includes Loopback 100. Check the domain-name and DNS (ipconfig /all):

R4#sh webvpn context ANYCONNECT_CONTEXT

Admin Status: up

Operation Status: up

Error and Event Logging: Disabled

CSD Status: Disabled

Certificate authentication type: All attributes (like CRL) are verified

AAA Authentication List: SSLAUTH

AAA Authorizationtion List not configured

AAA Authentication Domain not configured

Default Group Policy: ANYCONNECT_POL

Associated WebVPN Gateway: SSLGW

Domain Name: SSL

Maximum Users Allowed: 1000 (default)

NAT Address not configured

VRF Name not configured




R4#sh webvpn session user ssluser cont all

WebVPN user name = ssluser ; IP address = 8.9.2.200 ; context =

ANYCONNECT_CONTEXT

No of connections: 1

Created 00:04:32, Last-used 00:00:27

STC IP address 10.140.140.12 netmask 255.255.255.0

CSTP Started 00:02:53, Last-recieved 00:00:27

CSTP DPD-Request sent 0

Client Port: 2010

User Policy Parameters

Group name = ANYCONNECT_POL

Group Policy Parameters



functions =

svc-required

citrix disabled

address pool name = "ANYPOOL"

default domain = "ipexpert.com"






rekey method =


split include = 10.4.4.0 255.255.255.0

DNS primary server = 10.4.4.20

End Verification

4.20 VRF-Aware IPSec

Use IPSec to protect all traffic between Loopback 20 networks on R2 and R7.

Use AES 128 encryption, SHA-1 HMAC, DH group 5 and PSK “IPEXPERT” for Phase I.

Use the same encryption and authentication/integrity algorithms for Phase II and also make sure that any further session keys will not be derived based on previous ones.

You are allowed to configure two static routes in this task.

Configuration

ASA1

access-list OUTSIDE_IN permit udp host 8.9.2.2 host 8.9.2.7 eq isakmp

access-list OUTSIDE_IN permit udp host 8.9.2.2 host 8.9.2.7 eq 4500

R2

crypto keyring KRING

pre-shared-key address 8.9.2.7 key IPEXPERT


encr aes

group 5





vrf VRF

keyring KRING

match identity address 10.7.7.7 255.255.255.255

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


ip route vrf VRF 192.168.70.0 255.255.255.0 8.9.2.7 global


set peer 8.9.2.7


set pfs group5


match address 120


crypto map MAP1

R7

crypto keyring KRING



encr aes

group 5


vrf VRF

keyring KRING

match identity address 8.9.2.2 255.255.255.255

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


ip route vrf VRF 192.168.20.0 255.255.255.0 10.7.7.10 global


set peer 8.9.2.2


set pfs group5


match address 120


crypto map MAP1


A VRF comprises an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table.




From the IPSec perspective, each tunnel is associated with two VRF domains. The outer encapsulated packet belongs to one VRF domain, which we shall call the FVRF, while the inner, protected IP packet belongs to another domain called the IVRF. One or more IPsec tunnels can terminate on a single interface. The FVRF of all these tunnels is the same and is set to the VRF that is configured on that interface. The IVRF of these tunnels can be different and depends on the VRF that is defined in the Internet Security Association and Key Management Protocol (ISAKMP) profile that is attached to a crypto map entry. Note that in our case, FVRF is a global routing table (no VRF).

The configuration involves using ISAKMP Profile and Key Ring. The “vrf” command set under the ISAKMP Profile associates SA with this specific VRF instance. This is needed for the incoming packets when they are decapsulated – so they could be further forwared using the IVRF routing table. The Key Ring is a member of the global routing table so there is no FVRF associated with it. Two static routes we were allowed to configure have to belong to VRF. Note that the Next-Hop is set to the IP address from the global RIB (“global” keyword).

Finally, although ISAKMP packet from R7 has been NAT-translated to 8.9.2.7, IKE ID remained the same. This is why you need to match the un-translated address in the ISAKMP Profile.

Verification

Start with basic VRF and routing check:

R2#sh ip vrf

Name Default RD Interfaces

VRF <not set> Lo20

R2#sh ip route vrf VRF

Routing Table: VRF







route




S 192.168.70.0/24 [1/0] via 8.9.2.7

Bring the tunnel up:

R2#ping vrf VRF 192.168.70.7 so l20




.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 m

R2#sh cry isa pe 8.9.2.7

Peer: 8.9.2.7 Port: 4500 Local: 8.9.2.2

Phase1 id: 10.7.7.7




R2#sh cry sess re 8.9.2.7 de






Profile: ISA_PROF

Uptime: 00:00:42


Peer: 8.9.2.7 port 4500 fvrf: (none) ivrf: VRF

Phase1_id: 10.7.7.7

Desc: (none)


Capabilities:DN connid:1078 lifetime:23:59:16





R7#sh cry session ivrf VRF br


K - No IKE

ivrf = VRF

Peer I/F Username Group/Phase1_id Uptime

Status

8.9.2.2 Fa0/1 8.9.2.2 00:03:20

UA

End Verification

4.21 L2TP

Configure ASA2 for L2TP.

Create a user “l2tp” with password “ipexpert.”

Use MS-CHAP version 2 for authentication.

IP address assigned to the users should belong to 10.250.250.0/24 network.

Use 3DES encryption and SHA-1 HMAC for both phases. Set PSK to “CISCO.”

L2TP Hellos should be sent every 10 seconds.

Configuration

ASA2

ip local pool L2POOL 10.250.250.1-10.250.250.254

username l2tp password ipexpert mschap

crypto ipsec transform-set L2SET esp-3des esp-sha-hmac

crypto ipsec transform-set L2SET mode transport






encryption 3des

hash sha

crypto dynamic-map DYNMAP 2 set transform-set L2SET

l2tp tunnel hello 10

tunnel-group DefaultRAGroup general-attributes

address-pool L2POOL

tunnel-group DefaultRAGroup ipsec-attributes

pre-shared-key CISCO

tunnel-group DefaultRAGroup ppp-attributes

no authentication chap

no authentication ms-chap-v1

authentication ms-chap-v2

crypto map MAP1 10 ipsec-isakmp dynamic DYNMAP



The benefit of using L2TP with IPSec is that the only client requirement for VPN access is the use of Windows 2000 with Microsoft Dial-Up Networking (DUN). No additional client software, such as Cisco VPN client software, is required.

There are two caveats when configuring L2TP with IPSec. First, transport mode has to be used. Second, only default tunnel group and default group policy on the Cisco PIX/ASA should be used. User-defined policies and groups do not work.

For the rest of configuration create the ISAKMP Policy, a dynamic map entry and an IP address pool.

To ensure only MS-CHAP version 2 authentication is performed, turn off other methods. When creating a user in the local database make sure to add “mschap” keyword at the end – this is required for MS-CHAP authentication.




Verification

Open the Control Panel, find Network Connections. Choose “New Connection Wizard”:

Choose “Connect to the network at my workplace”, “Virtual Private Network Connection”, then give it a name, e.g. L2TP. Fill the hostname/IP Address to 8.9.2.10.




Now right-click on that new connection and choose “Properties”. Go to “Security” tab and choose “Settings”. Configure as shown below:

Set the PSK for this connection. This can be done under “Security” tab and “IPSec settings”:

Finally, establish the L2TP session. You will loose RDP connectivity to the Test PC because all traffic goes to the L2TP tunnel. Clear IKE and IPSec SAs in order to regain RDP connectivity:




ASA1(config)# sh vpn-sessiondb de re

Session Type: IPsec Detailed

Username : l2tp Index : 61


Protocol : IKE IPsec L2TPOverIPsec

License : IPsec

Encryption : 3DES Hashing : MD5 SHA1




Group Policy : DfltGrpPolicy Tunnel Group : DefaultRAGroup

Login Time : 14:02:05 UTC Tue Nov 17 2009




IKE Tunnels: 1

IPsec Tunnels: 1

L2TPOverIPsec Tunnels: 1

IKE:

Tunnel ID : 61.1

UDP Src Port : 500 UDP Dst Port : 500

IKE Neg Mode : Main Auth Mode : preSharedKeys


Rekey Int (T): 28800 Seconds Rekey Left(T): 28792 Seconds

D/H Group : 2

Filter Name :

IPsec:

Tunnel ID : 61.2

Local Addr : 8.9.2.10/255.255.255.255/17/1701

Remote Addr : 8.9.2.200/255.255.255.255/17/1701


Encapsulation: Transport

Rekey Int (T): 3600 Seconds Rekey Left(T): 3591 Seconds

Rekey Int (D): 250000 K-Bytes Rekey Left(D): 249990 K-Bytes




L2TPOverIPsec:

Tunnel ID : 61.3

Username : l2tp


Encryption : none Auth Mode : msCHAPV2


Client OS : Microsoft

Client OS Ver: 5.0



NAC:




Redirect URL :

ASA1(config)# clear cry isa sa

ASA1(config)# clear cry ipsec sa

End Verification




Lab 4B: Troubleshoot Virtual Private

Networks






4.0 Virtual Private Networks Troubleshooting Detailed Solutions

Lab 4B Detailed Solutions – Part I

4.1 IOS CA

Make R2 start acting as IOS CA.

Use key-pair IOS_CA for that purpose.

Make sure CA key can be further archived.

Automatically rollover Root Certificate 30 days prior to expiration.

Certificates should be granted automatically.

Non-SCEP CRL requests should use R2 as CDP Server.

Configure R2 as a NTP Server.

Synchronize R5 and R6 with the NTP Server.

R2, R5 and R6 should be in time zone GMT+1.

Use the domain name of ipexpert.com.


For verification of this task simply check the CA status and configuration:

R2(config)#do sh cry pki server


Status: disabled, HTTP Server is disabled

State: check failed













R2(config)#

Nov 8 12:01:25.953: %PKI-6-CS_ENABLED: Certificate server now enabled.




R2(config)#do sh cry pki ser


Status: enabled

State: enabled












Check the trustpoint, key pair and CRL config:

R2(config)#do sh run | se trustpoint

crypto pki trustpoint IOS_CA


rsakeypair IOS_CA

R2(config)#do sh cry key mypubkey rsa


Key name: IOS_CA

Storage Device: private-config


Key is exportable.

Key Data:

30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B0999B

D61EDF7E BA0A8772 3AEAD425 6D07E1E0 4E6BCAF9 666A1495 A58D1A90 F649F934

FDCF71AA 4D969ECB BE2FE5A5 0E27F63F F0AD7AEC 1FD78298 80ECE43E 0F3AACF9

63EC9EC4 D44B9756 1620AB06 20C64626 729AB2E8 8779CB41 F4484FA5 D14F19BD

23A54E54 E8466490 F401B01D 1E2F1D99 AB3B74E2 0DBC25DE D4967C32 A5020301

0001


Key name: IOS_CA.server

Temporary key


Key is not exportable.

Key Data:

307C300D 06092A86 4886F70D 01010105 00036B00 30680261 008F297E 45185872

750C2617 32CDE8CE FA2A8435 B278C992 EA38DBED B47B2267 C5CFE22D 8180C91B

EDD2CFED 52CD9CE8 7DF0DF90 8256DFEC 98EFF3D9 C81A2C02 8C80BA83 AB6AEBD7

3968F3F0 2A070F6D 63CAF024 8450239E 0F777D49 60AB76F1 2F020301 0001

R2(config)#do sh run | se pki server

crypto pki server IOS_CA

database archive pem password 7 14141B180F0B7B7977

grant auto

cdp-url http://8.9.50.2/cgi-bin/pkiclient.exe?operation=GetCRL

auto-rollover





4.2 IOS L2L

Configure Site-to-Site VPN between R5 and R6. Secure traffic between VLANs 5 and 6.

Use digital certificates as the authentication method.

For Phase I use AES 128 encryption and SHA-1 hash algo.

Phase II should use 3DES and MD-5.

Enroll for identity certificate on R5 and R6 using CN set to their respective FQDNs.

Use OU value of CCIE and set country to PL.

Set revocation check to CRL on R5 and R6.

Make sure R5‟s identity certificate is excluded from CRL validation on R6.

You are not allowed to use static routes, policy routing or any routing protocols for this task.


Start with testing basic IP reachability:

R5#sh run | se crypto map


set peer 8.9.50.6


match address 120



set peer 8.9.50.2



match address 140

crypto map MAP1

R5#ping 8.9.50.6



!!!!!


Looks good. Let‟s check routing on R5 :

R5#sh access-list 120

Extended IP access list 120

10 permit ip 10.5.5.0 0.0.0.255 10.6.6.0 0.0.0.255 (107 matches)



Known via "static", distance 1, metric 0


* 8.9.50.6


Great. Try to bring the tunnel up. Remember to source the traffic from F0/1:




R5#ping 10.6.6.6 source f0/1




.....


Oops. Let‟s run some ISAKMP debugs on R5 and try to bring the tunnel up again:

R5#deb cry isa


Do we have console logging enabled at the debugging level?

R5#sh logging

Syslog logging: enabled (0 messages dropped, 1 messages rate-limited,

0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: level debugging, 515 messages logged, xml disabled,

filtering disabled

Monitor logging: level debugging, 0 messages logged, xml disabled,

filtering disabled

Buffer logging: disabled, xml disabled,

filtering disabled

Logging Exception size (4096 bytes)

Count and timestamp logging messages: disabled

Persistent logging: disabled

No active filter modules.

ESM: 0 messages dropped

Trap logging: level informational, 64 message lines logged





.....


So it looks like the interesting traffic does not trigger ISAKMP negotiation at all. We checked the crypto ACL before, when checking routing and it was okay. So it probably means that either the crypto map is not applied or packets are not routed through the interface where it resides.




R5#sh cry map tag MAP1

Crypto Map "MAP1" 10 ipsec-isakmp

Peer = 8.9.50.6



Current peer: 8.9.50.6

Security association lifetime: 4608000 kilobytes/3600 seconds

PFS (Y/N): N

Transform sets={

SET2: { esp-3des esp-md5-hmac } ,

}

Reverse Route Injection Enabled


Peer = 8.9.50.2

ISAKMP Profile: ISA_PROF





PFS (Y/N): N

Transform sets={

SET4: { esp-192-aes esp-sha-hmac } ,

}

Interfaces using crypto map MAP1:

Serial0/1/0

Crypto map is applied as expected. Let‟s check how the routing goes:

R5(config)#do sh access-list 144

R5(config)#access-list 144 permit ip 10.5.5.0 0.0.0.255 10.6.6.0 0.0.0.255


R5#ping 10.6.6.6 so f0/1 rep 2




.Jan 20 00:44:13.156: IP: s=10.5.5.5 (local), d=10.6.6.6 (Null0), len 100,

local feature

.Jan 20 00:44:13.156: ICMP type=8, code=0, Policy Routing(3), rtype 2,

forus FALSE, sendself FALSE, mtu 0

.Jan 20 00:44:13.156: IP: s=10.5.5.5 (local), d=10.6.6.6 (Null0), len 100,

sending

.Jan 20 00:44:13.156: ICMP type=8, code=0..


So Policy Routing is the culprit:

R5#sh ip policy

Interface Route map

local PBR

R5#




R5#sh route-map PBR

route-map PBR, permit, sequence 10

Match clauses:

ip address (access-lists): 150

Set clauses:

interface Null0

Policy routing matches: 27 packets, 2700 bytes

Let‟s fix it and test again :

R5(config)#no ip local policy route-map PBR

R5#deb cry isa

R5#ping 10.6.6.6 so f0/1

.Jan 20 00:48:15.525: ISAKMP:(0): SA request profile is (NULL)

.Jan 20 00:48:15.525: ISAKMP: Created a peer struct for 8.9.50.6, peer port 500

.Jan 20 00:48:15.525: ISAKMP: New peer created peer = 0x490550A8 peer_handle =

0x80000015

.Jan 20 00:48:15.525: ISAKMP: Locking peer struct 0x490550A8, refcount 1 for

isakmp_initiator

.Jan 20 00:48:15.525: ISAKMP: local port 500, remote port 500

.Jan 20 00:48:15.525: ISAKMP: set new node 0 to QM_IDLE

.Jan 20 00:48:15.525: ISAKMP: Find a dup sa in the avl tree during calling

isadb_insert sa = 4930F8C8

.Jan 20 00:48:15.525: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.

.Jan 20 00:48:15.525: ISAKMP:(0):No pre-shared key with 8.9.50.6!

.Jan 20 00:48:15.525: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

.Jan 20 00:48:15.525: ISAKMP:(0): constructed NAT-T vendor-07 ID



.Jan 20 00:48:15.5

R5#29: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM

.Jan 20 00:48:15.529: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1

.Jan 20 00:48:15.529: ISAKMP:(0): beginning Main Mode exchange

.Jan 20 00:48:15.529: ISAKMP:(0): sending packet to 8.9.50.6 my_port 500 peer_port 500

(I) MM_NO_STATE

.Jan 20 00:48:15.529: ISAKMP:(0):Sending an IKE IPv4 Packet.

.Jan 20 00:48:15.585: ISAKMP (0): received packet from 8.9.50.6 dport 500 sport 500

Global (I) MM_NO_STATE

.Jan 20 00:48:15.585: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

.Jan 20 00:48:15.585: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2

.Jan 20 00:48:15.585: ISAKMP:(0): processing SA payload. message ID = 0

.Jan 20 00:48:15.585: ISAKMP:(0): processing vendor id payload

.Jan 20 00:48:15.585: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

.Jan 20 00:48:15.585: ISAKMP (0): vendor ID is NAT-T RFC 3947

.Jan 20 00:48:15.585: ISAKMP:(0):No pre-shared key with 8.9.50.6!

.Jan 20 00:48:15.589: ISAKMP : Scanning profiles for xauth ... ISA_PROF

.Jan 20 00:48:15.589: ISAKMP:(0):Checking ISAKMP transform 1 against priority 20

policy

.Jan 20 00:48:15.589: ISAKMP: encryption AES-CBC

.Jan 20 00:48:15.589: ISAKMP: keylength of 128

.Jan 20 00:48:15.589: ISAKMP: hash SHA

.Jan 20 00:48:15.589: ISAKMP: default group 1

.Jan 20 00:48:15.589: ISAKMP: auth RSA sig

.Jan 20 00:48:15.589: ISAKMP: life type in seconds

.Jan 20 00:48:15.589: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

.Jan 20 00:48:15.589: ISAKMP:(0):atts are acceptable. Next payload is 0

.Jan 20 00:48:15.589: ISAKMP:(0):Acceptable atts:actual life: 0

.Jan 20 00:48:15.589: ISAKMP:(0):Acceptable atts:life: 0

.Jan 20 00:48:15.589: ISAKMP:(0):Fill atts in sa vpi_length:4




.Jan 20 00:48:15.589: ISAKMP:(0):Fill atts in sa life_in_seconds:86400

.Jan 20 00:48:15.589: ISAKMP:(0):Returning Actual lifetime: 86400

.Jan 20 00:48:15.589: ISAKMP:(0)::Started lifetime timer: 86400.


.Jan 20 00:48:15.589: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

.Jan 20 00:48:15.589: ISAKMP (0): vendor ID is NAT-T RFC 3947

.Jan 20 00:48:15.589: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE


.Jan 20 00:48:15.593: ISAKMP (0): constructing CERT_REQ for issuer cn=IOS_CA

.Jan 20 00:48:15.593: ISAKMP:(0): sending packet to 8.9.50.6 my_port 500 peer_port 500

(I) MM_SA_SETUP


.Jan 20 00:48:15.593: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE



Global (I) MM_SA_SETUP



.Jan 20 00:48:15.721: ISAKMP:(0): processing KE payload. message ID = 0

.Jan 20 00:48:15.749: ISAKMP:(0): processing NONCE payload. message ID = 0

.Jan 20 00:48:15.749: ISAKMP:(1017): processing CERT_REQ payload. message ID = 0

.Jan 20 00:48:15.749: ISAKMP:(1017): peer wants a CT_X509_SIGNATURE cert

.Jan 20 00:48:15.749: ISAKMP:(1017): peer wants cert issued by cn=IOS_CA

.Jan 20 00:48:15.749: Choosing trustpoint CA as issuer


.Jan 20 00:48:15.753: ISAKMP:(1017): vendor ID is Unity


.Jan 20 00:48:15.753: ISAKMP:(1017): vendor ID is DPD


.Jan 20 00:48:15.753: ISAKMP:(1017): speaking to another IOS box!

.Jan 20 00:48:15.753: ISAKMP:received payload type 20

.Jan 20 00:48:15.753: ISAKMP (1017): His hash no match - this node outside NAT

.Jan 20 00:48:15.753: ISAKMP:received payload type 20

.Jan 20 00:48:15.753: ISAKMP (1017): No NAT Found for self or peer



.Jan 20 00:48:15.753: ISAKMP:(1017):Send initial contact

.Jan 20 00:48:15.757: ISAKMP:(1017):My ID configured as IPv4 Addr, but Addr not in

Cert!

.Jan 20 00:48:15.757: ISAKMP:(1017):Using FQDN as My ID

.Jan 20 00:48:15.757: ISAKMP:(1017):SA is doing RSA signature authentication using id

type ID_FQDN

.Jan 20 00:48:15.757: ISAKMP (1017): ID payload

next-payload : 6

type : 2


protocol : 17

port : 500

length : 23

.Jan 20 00:48:15.757: ISAKMP:(1017):Total payload length: 23

.Jan 20 00:48:15.765: ISAKMP (1017): constructing CERT payload for

hostname=R5.ipexpert.com,cn=R5.ipexpert.com,ou=CCIE,c=PL

.Jan 20 00:48:15.765: ISAKMP:(1017): using the CA trustpoint's keypair to sign

.Jan 20 00:48:15.781: ISAKMP:(1017): sending packet to 8.9.50.6 my_port 500 peer_port

500 (I) MM_KEY_EXCH


.Jan 20 00:48:15.781: ISAKMP:(1017):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE








Global (I) MM_KEY_EXCH

.Jan 20 00:48:16.045: ISAKMP:(1017): processing ID payload. message ID = 0

.Jan 20 00:48:16.045: ISAKMP (1017): ID payload

next-payload : 6

type : 2


protocol : 17

port : 500

length : 23

.Jan 20 00:48:16.045: ISAKMP:(0):: peer matches *none* of the profiles

.Jan 20 00:48:16.045: ISAKMP:(1017): processing CERT payload. message ID = 0

.Jan 20 00:48:16.045: ISAKMP:(1017): processing a CT_X509_SIGNATURE cert

.Jan 20 00:48:16.049: ISAKMP:(1017): peer's pubkey isn't cached

.Jan 20 00:48:16.057: %PKI-3-CERTIFICATE_INVALID_NOT_YET_VALID: Certificate chain

validation has failed. The certificate (SN: 03) is not yet valid Validity period

starts on 10:20:26 GMT+1 Nov 4 2009

.Jan 20 00:48:16.057: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 8.9.50.6 is

bad: CA request failed!



.Jan 20 00:48:16.057: ISAKMP (1017): incrementing error counter on sa, attempt 1 of 5:

reset_retransmission



.Jan 20 00:48:16.061: ISAKMP (1017): incrementing error counter on sa, attempt 2 of 5:

reset_retransmission

.Jan 20 00:48:16.061: ISAKMP:(1017):Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR


R5#sh clock

.01:51:39.421 GMT+1 Wed Jan 20 1993

R5#sh run | in ntp

R5#

NTP is not set. Fix it (you have to wait for the devices to synchronize):

R5(config)#ntp server 8.9.50.2

R5(config)#do sh ntp stat



reference time is CEA15039.C1476E15 (15:12:09.754 GMT+1 Sun Nov 8 2009)





R5#ping 10.6.6.6 so f0/1




.....





R5#sh cry isa pe

Peer: 8.9.50.6 Port: 500 Local: 8.9.50.5








Uptime: 00:00:59




Desc: (none)







R5#sh cry sess br


K - No IKE

ivrf = (none)


8.9.50.6 Se0/1/0 R6.ipexpert.com 00:01:26 UA

So the tunnel is up, but we are not receiving any packets from 10.6.6.0. Let‟s move to R6:


% Subnet not in table

The other unidirectional IPSec SA may not be created because there is no route to 10.5.5.0/24 network.



set peer 8.9.50.5


match address 120

crypto map MAP1

R6(config)#cry map MAP1 10 ipsec-isa

R6(config-crypto-map)#reverse-route static

R6#ping 10.5.5.5 so f0/0




.!!!!





R6#sh cry sess remo 8.9.50.5 de






Uptime: 00:00:05




Desc: (none)








4.3 IOS-ASA L2L

Create loopback 3 on R2. Assign it an IP address of 192.168.3.2/24.

Create a VPN Tunnel on ASA1 and R2 protecting all IP traffic between VLAN100 and newly created loopback network.

For Phase I, create ISAKMP policy 30 on ASA and use its default values. Use PSK of “ipexpert.” For Phase II use 3DES and SHA algorithms.

On the ASA1, ensure that ICMP traffic is not allowed across the tunnel.

Create an additional loopback 30 on R2. Assign it an IP address of 192.168.30.2/24.

Add traffic from this newly created loopback to VLAN 100 to the existing tunnel.

Give priority treatment to all telnet packets flowing between Loopback 3 and VLAN100 across the VPN tunnel on R2 and restrict this traffic to 200Kbps. Loopback 30 traffic should not be subject to this policy.

You are allowed to use three static routes in this task.


Start with testing basic IP reachability and routing:

R2#sh run int Gi0/1 | begin Gig


ip address 8.9.2.2 255.255.255.0

crypto map MAP1

service-policy output VPN_QOS

duplex auto

speed auto

media-type rj45

end






Peer = 8.9.2.10






PFS (Y/N): N

Transform sets={

SET3: { esp-3des esp-sha-hmac } ,

}

QOS pre-classification


GigabitEthernet0/1



Known via "static", distance 1, metric 0


* 8.9.2.10


R2#ping 8.9.2.10



!!!!!


ASA1(config)# sh run crypto map

crypto map MAP1 10 match address PROXY_ACL

crypto map MAP1 10 set peer 8.9.2.2

crypto map MAP1 10 set transform-set SET3

crypto map MAP1 10 set security-association lifetime seconds 28800

crypto map MAP1 10 set security-association lifetime kilobytes 4608000


ASA1(config)# sh run access-list PROXY_ACL

access-list PROXY_ACL extended permit ip 10.1.1.0 255.255.255.0 192.168.3.0

255.255.255.0

access-list PROXY_ACL extended permit ip 10.1.1.0 255.255.255.0 192.168.30.0

255.255.255.0

ASA1(config)# sh route | in 192.168.3

S 192.168.30.0 255.255.255.0 [1/0] via 8.9.2.2, outside

S 192.168.3.0 255.255.255.0 [1/0] via 8.9.2.2, outside1

Everything looks good now. Initiate the VPN traffic on R2:

R2#telnet 10.1.1.100 /source-interface l3

Trying 10.1.1.100 ...

% Connection timed out; remote host not responding

R2#sh cry isa pe

Peer: 8.9.2.10 Port: 500 Local: 8.9.2.2

Phase1 id: 8.9.2.10




R2#sh cry sess br


K - No IKE

ivrf = (none)


8.9.2.10 Gi0/1 8.9.2.10 00:01:44 UA







Uptime: 00:02:55



Phase1_id: 8.9.2.10

Desc: (none)











So tunnel is up, but we are not receiving any response traffic. Let‟s move to the ASA1:

ASA1(config)# sh cry isa sa de

Active SA: 1

Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1 IKE Peer: 8.9.2.2

Type : L2L Role : responder

Rekey : no State : MM_ACTIVE

Encrypt : 3des Hash : SHA

Auth : preshared Lifetime: 86400

Lifetime Remaining: 86073

ASA1(config)# sh vpn-sessiondb l2l

Session Type: LAN-to-LAN

Connection : 8.9.2.2

Index : 6 IP Addr : 192.168.3.0




Login Time : 20:12:43 UTC Thu Oct 29 2009





ASA1(config)# sh cry ipsec stats

IPsec Global Statistics

-----------------------

Active tunnels: 1


Turn on logging warning and check this again:

ASA1(config)# loggi con wa


Trying 10.1.1.100 ...


ASA1(config)# %ASA-2-106001: Inbound TCP connection denied from

192.168.3.2/19230 to 10.1.1.100/23 flags SYN on interface outside

%ASA-2-106001: Inbound TCP connection denied from 192.168.3.2/19230 to

10.1.1.100/23 flags SYN on interface outside

%ASA-2-106001: Inbound TCP connection denied from 192.168.3.2/19230 to

10.1.1.100/23 flags SYN on interface outside

ASA1(config)# sh run all sysopt

no sysopt connection timewait

sysopt connection tcpmss 1380

sysopt connection tcpmss minimum 0


no sysopt connection reclassify-vpn

no sysopt connection preserve-vpn-flows

no sysopt nodnsalias inbound

no sysopt nodnsalias outbound

no sysopt radius ignore-secret

no sysopt noproxyarp outside

no sysopt noproxyarp inside

no sysopt noproxyarp DMZ

All VPN tunneled traffic should be permitted, it does not matter what is allowed in the outside interface ACL (OUTSIDE_IN in our example). Let‟s check the connection profile on ASA:

ASA1(config)# sh run tunnel-group

tunnel-group 8.9.2.2 type ipsec-l2l

tunnel-group 8.9.2.2 general-attributes

default-group-policy L2L_POL

ASA1(config)# sh run group-policy L2L_POL

group-policy L2L_POL internal

group-policy L2L_POL attributes

vpn-filter value VPN_FILTER

ASA1(config)# sh run access-list VPN_FILTER

access-list VPN_FILTER extended deny icmp any any

Looks like “permit ip any any” at the end is missing. All the tunneled traffic was not allowed to come in. Add this statement and initiate the traffic again on R2:




ASA1(config)# access-list VPN_FILTER extended permit ip any any


Trying 10.1.1.100 ...


Clear the existing tunnel so the new policy may take place and test again:

R2#clear cry sess remote 8.9.2.10


Trying 10.1.1.100 ...


Move back to ASA and look what logs are showing us:

ASA1(config)# %ASA-4-113019: Group = 8.9.2.2, Username = 8.9.2.2, IP =

8.9.2.2, Session disconnected. Session Type: IPsec, Duration: 0h:18m:56s,

Bytes xmt: 0, Bytes rcv: 484, Reason: User Requested

%ASA-4-713903: Group = 8.9.2.2, IP = 8.9.2.2, Freeing previously allocated

memory for authorization-dn-attributes

%ASA-3-305005: No translation group found for tcp src

outside:192.168.3.2/65142 dst inside:10.1.1.100/23

%ASA-3-305005: No translation group found for tcp src

outside:192.168.3.2/65142 dst inside:10.1.1.100/23

What this basically means is that we are trying to reach the untranslated ACS IP address which is shielded by the NAT Process (it has been NATed to 8.9.2.100 which is the only way we can now reach the ACS). So ACS is definitely not exempted from the NAT Process for VPN traffic:

ASA1(config)# sh run nat

ASA1(config)#

ASA1(config)# sh run access-list | in NAT


255.255.255.0


255.255.255.0

ASA1(config)# nat (inside) 0 access-list NAT_EXEMPT


Trying 10.1.1.100 ... Open

Welcome to Microsoft Telnet Service

login:





4.4 L2L Aggressive Mode with PSK


For this task assume that R5‟s external IP address is dynamically assigned and may change over the time. You are not allowed to use wildcard PSK on R2.

Use AES 192 encryption and SHA-1 hashing for both phases. Use PSK of “ipexpert” for authentication.

VPN traffic should be only initiated by R5.

Test by pinging R2‟s Gi0/1 interface; you are allowed one static route to get this working.


As usual, perform some basic connectivity testing and check the routing as well. If everything looks good, try to initiate VPN traffic and turn on ISAKMP debug on R5:

R5#ping 8.9.50.2



!!!!!




set peer 8.9.50.6


match address 120



set peer 8.9.50.2



match address 140

crypto map MAP1

R5#sh access-list 140


10 permit ip 10.5.5.0 0.0.0.255 8.9.2.0 0.0.0.255 (48 matches)





.....

When you move to R2 you see the following syslog messages:

R2#

Nov 8 17:08:40.859: ISAKMP (0): received packet from 8.9.50.5 dport 500

sport 500 Global (N) NEW SA

R2#

Nov 8 17:08:40.859: %CRYPTO-4-IKMP_NO_SA: IKE message from 8.9.50.5 has no

SA and is not an initialization offer




This basically means that there is no existing SA for this IPSec encrypted packet or that it can‟t be recognized as the initialization offer. Check how the crypto map is configured and applied.

R2#sh cry map


Peer = 8.9.2.10






PFS (Y/N): N

Transform sets={

SET3: { esp-3des esp-sha-hmac } ,

}

QOS pre-classification


GigabitEthernet0/1


Dynamic map template tag: DYN_MAP


Here is the culprit. Apply the crypto map and run the test again.

R2(config)#int s0/1/0

R2(config-if)#cry map MAP2





Nov 8 17:11:03.519: ISAKMP:(0): SA request profile is ISA_PROF


Nov 8 17:11:03.519: ISAKMP: New peer created peer = 0x49195C68 peer_handle =

0x80000012

Nov 8 17:11:03.519: ISAKMP: Locking peer struct 0x49195C68, refcount 1 for

isakmp_initiator



Nov 8 17:11:03.519: ISAKMP:(0):insert sa successfully sa = 4870EADC






Nov 8 17:11:03.519: ISAKMP:(0):SA is doing pre-shared key authentication using id

type ID_IPV4_ADDR


next-payload : 13

type : 1

address : 8.9.50.5

protocol : 17

port : 0

length : 12

Nov 8 17:11:03.519: ISAKMP:(0):Total payload length: 12

Nov 8 17:11:03.519: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_AM

Nov 8 17:11:03.519: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_AM1




Nov 8 17:11:03.523: ISAKMP:(0): beginning Aggressive Mode exchange


(I) AG_INIT_EXCH




Nov 8 17:11:03.563: ISAKMP:(0):Notify has no hash. Rejected.

Nov 8 17:11:03.563: ISAKMP (0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY:

s.tate = IKE_I_AM1

Nov 8 17:11:03.563: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY

Nov 8 17:11:03.563: ISAKMP:(0):Old State = IKE_I_AM1 New State = IKE_I_AM1

Nov 8 17:11:03.563: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode

failed with peer at 8.9.50.2....


R5#sh cry sess br


K - No IKE

ivrf = (none)


8.9.50.2 Se0/1/0 DN

8.9.50.6 Se0/1/0 R6.ipexpert.com UI

The tunnel did not come up. At the first glance it looks like there were no authentication payload attached. Let‟s try to bring up the tunnel once again and observe the debugs on R2:

R2#deb cry isa

R5#ping 8.9.2.2 so f0/1


R2#


Global (N) NEW SA


Nov 8 17:15:02.333: ISAKMP: New peer created peer = 0x70F6DF00 peer_handle =

0x80000012

Nov 8 17:15:02.333: ISAKMP: Locking peer struct 0x70F6DF00, refcount 1 for



Nov 8 17:15:02.333: ISAKMP:(0):insert sa successfully sa = 67E1DFEC




next-payload : 13

type : 1

address : 8.9.50.5

protocol : 17

port : 0

length : 12

Nov 8 17:15:02.333: ISAKMP:(0):: peer matches *none* of the profiles


Nov 8 17:15:02.333: ISAKMP:(0): ven

R2#dor ID seems Unity/DPD but major 69 mismatch



Nov 8 17:15:02.333: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch

Nov 8 17:15:02.333: ISAKMP (0): vendor ID is NAT-T v7



Nov 8 17:15:02.333: ISAKMP:(0): vendor ID is NAT-T v3







Nov 8 17:15:02.333: ISAKMP: no pre-shared key based on address 8.9.50.5!

Nov 8 17:15:02.333: ISAKMP:(0):No pre-shared key with 8.9.50.5!


Nov 8 17:15:02.333: ISAKMP : Scanning profiles for xauth ...









Nov 8 17:15:02.333: ISAKMP:(0):Encryption algorithm offered does not match policy!










Nov 8 17:15:02.333: ISAKMP:(0):Proposed key length does not match policy


Nov 8 17:15:02.333: ISAKMP:(0):no offers accepted!

Nov 8 17:15:02.333: ISAKMP:(0): phase 1 SA policy not acceptable! (local 8.9.50.2

remote 8.9.50.5)

Nov 8 17:15:02.333: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5:

construct_fail_ag_init

Nov 8 17:15:02.333: ISAKMP:(0): Failed to construct AG informational message.


R2#sh cry isa key

Keyring Hostname/Address Preshared Key

default 8.9.2.10 ipexpert

R5.ipexpert.com ipexpert

It seems we have a key but the IKE ID sent is not what we expect. Let‟s try to correct this on R5:



Peer = 8.9.50.6





PFS (Y/N): N

Transform sets={

SET2: { esp-3des esp-md5-hmac } ,

}

Reverse Route Injection Enabled





Peer = 8.9.50.2






PFS (Y/N): N

Transform sets={

SET4: { esp-192-aes esp-sha-hmac } ,

}


Serial0/1/0

R5#sh run | be isakmp profile ISA_PROF


! This profile is incomplete (no match identity statement)

keyring default

initiate mode aggressive


R5(config)#cry isa prof ISA_PROF

R5(conf-isa-prof)#self-identity fqdn

Let‟s test again and observe debug on R2:

R2#


Global (N) NEW SA


Nov 8 17:25:10.701: ISAKMP: New peer created peer = 0x70F6DF00 peer_handle =

0x80000014

Nov 8 17:25:10.701: ISAKMP: Locking peer struct 0x70F6DF00, refcount 1 for



Nov 8 17:25:10.701: ISAKMP:(0):insert sa successfully sa = 67E1DFEC




next-payload : 13

type : 2


protocol : 17

port : 0

length : 23

Nov 8 17:25:10.701: ISAKMP:(0):: peer matches *none* of the profiles


Nov 8 17:25:10.701: ISAKMP:(

R2#0): vendor ID seems Unity/DPD but major 69 mismatch














Nov 8 17:25:10.701: ISAKMP:(0):Looking for a matching key for R5.ipexpert.com in

default


Nov 8 17:25:10.701: ISAKMP : Scanning profiles for xauth ...









Nov 8 17:25:10.701: ISAKMP:(0):Encryption algorithm offered does not match policy!










Nov 8 17:25:10.701: ISAKMP:(0):Proposed key length does not match policy


Nov 8 17:25:10.701: ISAKMP:(0):no offers accepted!


remote 8.9.50.5)

Nov 8 17:25:10.701: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5:

construct_fail_ag_init

Nov 8 17:25:10.701: ISAKMP:(0): Failed to construct AG informational message.

We are having a problem with ISAKMP negotiation. Compare the ISAKMP policies on both the endpoints and make them match:

R2#sh run | se isakmp policy


encr 3des


group 2


encr aes 192


R5#sh run | se isakmp policy


encr aes


encr aes


R5(config)#cry isa pol 40

R5(config-isakmp)#enc aes 192

Try to bring the tunnel up again:








.!!!!


R5#sh cry sess br


K - No IKE

ivrf = (none)


8.9.50.2 Se0/1/0 8.9.50.2 00:00:07 UA

8.9.50.2 Se0/1/0 UA


4.5 L2L Overlapping Subnets


Use PSK “cisco” for Phase I and 3DES and MD-5 for Phase II.



You may create loopback interfaces and use EIGRP as the routing protocol (AS 46).

You are not allowed to use any static routes.

Use 172.16.46.0/24 for the tunnel network.

Make sure the EIGRP routing protocol updates are not leaking to any other device.

You are not allowed to use either GRE or crypto map as part of the solution for this task.


Basic connectivity and routing test are always welcome. Note that in this lab we don‟t assume any filters applied (unless they are a part of troubleshooting) so ICMP Echo/Echo Reply should be fine for this:

R4#ping 8.9.50.6



!!!!!


R4#


% Subnet not in table


R4#sh ip eigrp ne


R4#




Check EIGRP config on both the routers:

R4#sh run | se eigrp

router eigrp 46



network 10.44.44.4 0.0.0.0

network 172.16.46.4 0.0.0.0

no auto-summary


router eigrp 46



network 8.9.50.6 0.0.0.0

network 10.40.40.6 0.0.0.0

no auto-summary

Wrong. We are trying to establish the adjacency over the tunnel, not over the physical network. By the way - advertising physical network through the tunnel can in some cases cause routing loops and interface flapping.


R6(config)#router eigrp 46

R6(config-router)#no network 8.9.50.6 0.0.0.0

R6(config-router)#network 172.16.46.6 0.0.0.0

R6#

Nov 8 19:48:51.479: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 8.9.50.4

failed its sanity check or is malformed

No doubt here – Pre-Shared Keys don‟t match.

R6#sh cry isa ke


default 8.9.50.4 cisco

R4#sh cry isa ke


default 8.9.50.6 csico

R4(config)#no cry isa key csico add 8.9.50.6

R4(config)#cry isa key cisco add 8.9.50.6

R4(config)#do clear cry sess

R4(config)#

*Nov 8 19:38:55.490: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 46: Neighbor 172.16.46.6

(Tunnel46) is up: new adjacency



D 10.44.44.0 [90/27008000] via 172.16.46.4, 00:00:20, Tunnel46















Looks like we are good to go now. Try to reach VLAN 40 from R4‟s F0/1:

R4#ping 10.40.40.6 so f0/1




...


Hmm…

R4#sh cry sess detail | begin Tunnel

Interface: Tunnel46

Uptime: 00:07:03



Phase1_id: 8.9.50.6

Desc: (none)







So the tunnel is up and running. Packets are getting encrypted and decrypted – but note it may be only the EIGRP traffic:

R4#sh cry sess de | begin Code




Interface: Tunnel46

Uptime: 00:10:25



Phase1_id: 8.9.50.6

Desc: (none)










Let‟s check if interesting traffic is processed by our SAs:

R4#ping 10.40.40.6 so f0/1 rep 100 timeout 0




......................................................................

..............................


R4#sh cry sess de





Interface: Tunnel46

Uptime: 00:10:55



Phase1_id: 8.9.50.6

Desc: (none)







Okay, it seems one SA is working. Now we should check if the other VPN endpoint also receives this traffic. If it does not receive it, it may get filtered somewhere along the path.






Interface: Tunnel46

Uptime: 00:18:28




Desc: (none)







R6 is receiving this traffic. The respective counters are similar. What about if we try to initiate VPN traffic from R6?




R6#ping 10.44.44.4 so f0/1




!!!!!


So we can reach VLAN 4 from R6‟s VLAN 40, but we can‟t reach VLAN 40 from R4‟s VLAN 4. Are we sure? Remember that this is an overlapping network scenario where we are using NAT to resolve the conflict. What if NAT is not working and we are hitting Loopback 44 on R4 instead of F0/1?

R4#deb ip nat

IP NAT debugging is on

R4#

*Nov 8 20:18:37.529: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [420]

*Nov 8 20:18:37.557: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [421]

*Nov 8 20:18:37.585: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [422]

*Nov 8 20:18:37.613: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [423]

*Nov 8 20:18:37.641: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [424]

R4#sh ip nat tr


icmp 10.44.44.4:31 10.4.4.4:31 10.40.40.6:31 10.40.40.6:31

--- 10.44.44.4 10.4.4.4 --- ---

--- 10.44.44.0 10.4.4.0 --- ---

We are hitting R4‟s F0/1 (VLAN 4). It looks like all is working properly and we can probably start looking for some filtering going on. But before, let‟s check if NAT is also working when we are initiating traffic from R4 (leave the NAT debug on):

R4#ping 10.40.40.6 so f0/1




.....


R4#sh ip nat t


--- 10.44.44.4 10.4.4.4 --- ---

--- 10.44.44.0 10.4.4.0 --- ---

It is not. Don‟t hesitate to check NAT configuration on R4:

R4#sh run | in inside|outside

ip nat inside

ip nat outside


R4#sh run | in interface|nat


interface Tunnel46







ip nat inside


ip nat outside






It makes a bit more sense now, however I am not sure if such NAT processing is what was really intended by the IOS developers. Traffic coming from R6 to R4 was flowing properly – even though packets entering Serial 0/0/0 were IPSec-encapsulated (which means they don‟t match our static NAT statement) they were marked for de-NAT and after decapsulation on the tunnel interface they were untranslated. When traffic is flowing from the NAT outside interface to the NAT inside interface, routing happens after NAT (de-NAT). The reason why it was not working other way is that traffic entering interface marked as “NAT inside” is first routed and if it matches NAT outside interface it gets NATed (routing happens before NAT). Tunnel interface which was the outgoing interface (route recursion) did not have “ip nat outside” so the packets were not NATed and IPSec did not encrypt this traffic. Simply put – fix this.


R4(config-if)#no ip nat o

*Nov 8 20:48:56.467: ip_ifnat_modified: old_if 1, new_if 3

R4(config-if)#int tu 46

R4(config-if)#ip nat o

R4#ping 10.40.40.6 so f0/1




!!!!!


R4#

*Nov 8 20:49:42.515: NAT: s=10.4.4.4->10.44.44.4, d=10.40.40.6 [13]

*Nov 8 20:49:42.543: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [13]

*Nov 8 20:49:42.543: NAT: s=10.4.4.4->10.44.44.4, d=10.40.40.6 [14]

*Nov 8 20:49:42.571: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [14]

*Nov 8 20:49:42.571: NAT: s=10.4.4.4->10.44.44.4, d=10.40.40.6 [15]

*Nov 8 20:49:42.599: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [15]

*Nov 8 20:49:42.603: NAT: s=10.4.4.4->10.44.44.4, d=10.40.40.6 [16]

*Nov 8 20:49:42.631: NAT*: s=10.40.40.6, d=10.44.44.4->10.4.4.4 [16]

*Nov 8 20:49:42.631: NAT: s=10.4.4.4->10.44.44.4, d=10.40.40.6 [17]





4.6 Easy VPN Server (IOS)

Configure R4 as Easy VPN Server.

Use Digital Certificates for authentication. Use 3DES and MD-5 algorithms for both phases.


Username “ipexpert” with password “ipexpert.” Assign the users IP address pool 8.9.100.0/24. Use the group name CCIE. R4 should see the route to remote client with distance of 15. Make sure Cat2 can reach the remote clients. Use RRI to accomplish this.

Enroll VPN Client on Test PC and R4 with R2 to obtain an identity certificate.


Use domain name ipexpert.com on R4. Change the time zone to GMT+1.

Use DVTI as part of your solution.


Troubleshooting for this task is done along with task 4.9.


4.7 Easy VPN Client (IOS)

Configure R8 as a hardware client. Create Loopback 8 (8.8.8.8/24) interface which will emulate the inside network.

Make sure your credentials are stored on the device so you don‟t have to type them whenever you connect.

R4 is the Easy VPN Server.

Use 3DES and MD-5 algorithms for both phases.


Username “cciesec” with password “cisco.” Assign the users IP address pool 8.9.200.0/24. Use the group name REMOTE with PSK “ipexpert.”








4.8 Easy VPN with External Group Authorization and XAUTH


Make ACS visible to the public network as 8.9.2.100.

R4 should communicate with RADIUS using key value of “ipexpert.”

Perform external group authorization for remote users. Follow the same directions for this as in task 4.7.

Perform external authentication for remote users. User “cciesec” should have an IP address 8.9.200.100.

Test this configuration with R8 ezVPN hardware client.


Verify Easy VPN Hardware Client status on R8:






Current State: CONNECT_REQUIRED

Last Event: CONN_DOWN



Before you try to connect, verify if the peer is reachable:

R8#ping 8.9.50.4



.....


Look at the diagram. ASA is in the path between R8 and R4. ICMP is not inspected by default. Try telnet:

R8#telnet 8.9.50.4



Username:

Now you may take a look at the client configuration. Remember to also check the interfaces.




R8#sh run | se ipsec client


connect manual

group REMOTE key ipexpert

mode client

peer 8.9.50.4

virtual-interface 1


xauth userid mode local



R8#sh run int f0/1



!


ip address 192.168.8.8 255.255.255.0

duplex auto

speed auto


end

R8#sh run int l8



!

interface Loopback8

ip address 8.8.8.8 255.255.255.0


R8#sh run int virtual-te 1 | begin Virt


ip unnumbered FastEthernet0/1


end

Try to initiate the connection. If does not work, run the ISAKMP debug and try it again:

R8#cry ips clie ez co






Current State: READY

Last Event: CONNECT



R8#deb cry isa




R8#cry ips clie ez co

*Nov 9 14:59:09.192: ISAKMP:(0): SA request profile is (NULL)


*Nov 9 14:59:09.196: ISAKMP: New peer created peer = 0x486A5598 peer_handle =

0x80000024

*Nov 9 14:59:09.196: ISAKMP: Locking peer struct 0x486A5598, refcount 1 for

isakmp_initiator

*Nov 9 14:59:09.196: ISAKMP:(0):Setting client config settings 494338C4


*Nov 9 14:59:09.196: ISAKMP:(0):insert sa successfully sa = 49430564

*Nov 9 14:59:09.196: ISAKMP:(0): client mode configured.

*Nov 9 14:59:09.196: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

*Nov 9 14:59:09.196: ISAKMP:(0): constructed NAT-T vendor-07 ID



*Nov 9 14:59:09.196: ISKAMP: growing

R8# send buffer from 1024 to 3072

*Nov 9 14:59:09.196: ISAKMP:(0):SA is doing pre-shared key authentication plus XAUTH

using id type ID_KEY_ID

*Nov 9 14:59:09.196: ISAKMP (0): ID payload

next-payload : 13

type : 11

group id : REMOTE

protocol : 17

port : 0

length : 14

*Nov 9 14:59:09.196: ISAKMP:(0):Total payload length: 14

*Nov 9 14:59:09.196: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_AM

*Nov 9 14:59:09.200: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_AM1

*Nov 9 14:59:09.200: ISAKMP:(0): beginning Aggressive Mode exchange

*Nov 9 14:59:09.200: ISAKMP:(0): sending packet to 8.9.50.4 my_port 500 peer_port 500

(I) AG_INIT_EXCH

*Nov 9 14:59:09.200: ISAKMP:(0):Sending an IKE IPv4 Packet.

R8#

*Nov 9 14:59:19.200: ISAKMP:(0): retransmitting phase 1 AG_INIT_EXCH...

We did not learn anything special from this. We sent AM packet to the server but we did not get any response. Let‟s see how it looks on R4:

R4#

*Nov 9 15:17:24.047: ISAKMP (0): received packet from 8.9.2.8 dport 500 sport 500

Global (N) NEW SA


*Nov 9 15:17:24.047: ISAKMP: New peer created peer = 0x4816D5AC peer_handle =

0x80000019

*Nov 9 15:17:24.047: ISAKMP: Locking peer struct 0x4816D5AC, refcount 1 for



*Nov 9 15:17:24.051: ISAKMP:(0):insert sa successfully sa = 498B1048


*Nov 9 15:17:24.051: ISAKMP:(0): processing ID payload. message ID = 0


next-payload : 13

type : 11

group id : REMOTE

protocol : 17

port : 0

length : 14

*Nov 9 15:17:24.051: ISAKMP:(0):: peer matches ISA_PROF2 profile

*Nov 9 15:17:24.051: ISAKMP:(0):Setting client config settings 48ECDD00




*Nov 9 15:17:24.051: I

R4#SAKMP:(0):(Re)Setting client xauth list and state

*Nov 9 15:17:24.051: ISAKMP/xauth: initializing AAA request




*Nov 9 15:17:24.159: ISAKMP:(0):deleting SA reason "IKMP_ERR_NO_RETRANS" state (R)

AG_NO_STATE (peer 8.9.2.8)

*Nov 9 15:17:24.159: ISAKMP: Unlocking peer struct 0x4816D5AC for

isadb_mark_sa_deleted(), count 0

*Nov 9 15:17:24.159: ISAKMP: Deleting peer node by peer_reap for 8.9.2.8: 4816D5AC

*Nov 9 15:17:24.159: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

*Nov 9 15:17:24.159: ISAKMP:(0):Old State = IKE_READY New State = IKE_DEST_SA

So, R4 receives ISAKMP packet but does not respond. Vague. This is a hard case, because we don‟t have much inclination on what might have gone wrong. Normally you could double-check the configuration now, to make sure everything is correct. Recall, however, that Easy VPN uses AAA framework for XAUTH and Group Authorization. Check if AAA is working properly on R4:

R4#un all

R4#debug aaa authentication

R4#debug aaa authorization

R4#


*Nov 9 15:35:47.639: AAA/AUTHOR (0x17): Invalid method list id=0x0

We are having a problem with authorization (Group Policy) list. Verify and amend. Move back to R8 and observe the debug again:

R4#sh run | in aaa

aaa new-model


aaa authentication login XAUTH local

aaa authentication login XAUTH_EXT group radius

aaa authorization network EZ_POL local

aaa authorization network EZ_EXT group radius

aaa authorization network EZ_PKI group radius

aaa session-id common

R4#sh run | se isakmp profile ISA_PROF2


match identity group REMOTE

client authentication list XAUTH_EXT

isakmp authorization list EZ_EX


virtual-template 3

R4(config)#cry isa prof ISA_PROF2

R4(conf-isa-prof)#isakmp authorization list EZ_EXT

R8#un all


R8#deb cry isa





R8#cry ips cl ez co

R8#

EZVPN(EZCLIENT): IPSec connection terminated




0x80000033


isakmp_initiator

*Nov 9 16:01:12.423: ISAKMP:(0):Setting client config settings 494352C0


*Nov 9 16:01:12.423: ISAKMP:(0):insert sa successfully sa = 49430564






*Nov 9 16:01:12.423: ISKAMP: growing send buffer from 1024 to 3072

*Nov 9 16:01:1

R8#2.423: ISAKMP:(0):SA is doing pre-shared key authentication plus XAUTH using id

type ID_KEY_ID


next-payload : 13

type : 11

group id : REMOTE

protocol : 17

port : 0

length : 14






(I) AG_INIT_EXCH







next-payload : 10

type : 2


protocol : 0

port : 0

length : 23

*Nov 9 16:01:12.503: ISAKMP:(0):: peer matches *none* of the profiles






*Nov 9 16:01:12.503: ISAKMP:(0): speaking to another IOS box!

*Nov 9 16:01:12.503: ISAKMP:(0):Looking for a matching key for R4.ipexpert.com in

default

*Nov 9 16:01:12.503: ISAKMP: no pre-shared key based on hostname R4.ipexpert.com!

*Nov 9 16:01:12.503: ISAKMP : Scanning profiles for xauth ...

*Nov 9 16:01:12.503: ISAKMP:(0): Authentication by xauth preshared





R4 uses IKE ID set to DN because VPN Client uses digital certificates for authentication. Change IKE ID to IP address for this connection and verify R8 debugs again:

R4(config)#cry isa prof ISA_PROF2

R4(conf-isa-prof)#self-identity address

R8#




0x80000034


isakmp_initiator

*Nov 9 16:07:50.451: ISAKMP:(0):Setting client config settings 4942E948


*Nov 9 16:07:50.451: ISAKMP:(0):insert sa successfully sa = 48BB14AC






*Nov 9 16:07:50.451: ISKAMP: growing send buffer from 1024 to 3072

*Nov 9 16:07:50.451: ISAKMP:(0):SA is doing pre-shared key a

R8#

EZVPN(EZCLIENT): IPSec connection terminauthentication plus XAUTH using id type

ID_KEY_ID


next-payload : 13

type : 11

group id : REMOTE

protocol : 17

port : 0

length : 14






(I) AG_INIT_EXCH







next-payload : 10

type : 1

address : 8.9.50.4

protocol : 0

port : 0

length : 12

*Nov 9 16:07:50.531: ISAKMP:(0):: peer matches *none* of the profiles







*Nov 9 16:07:50.531: ISAKMP:(0): local preshared key found





*Nov 9 16:07:50.595: ISAKMP:(1033):SA authentication status:

authenticated

*Nov 9 16:07:50.595: ISAKMP:(1033):SA has been authenticated with 8.9.50.4

*Nov 9 16:07:50.595: ISAKMP:(1033):Setting UDP ENC peer struct 0x493DECA0 sa=

0x48BB14AC

*Nov 9 16:07:50.599: ISAKMP: Trying to insert a peer 192.168.8.8/8.9.50.4/4500/, and

inserted successfully 486A5598.

*Nov 9 16:07:50.599: ISAKMP:(1033):Send initial contact

*Nov 9 16:07:50.599: ISAKMP:(1033): sending packet to 8.9.50.4 my_port 4500 peer_port

4500 (I) AG_INIT_EXCH


*Nov 9 16:07:50.599: ISAKMP:(1033):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH

*Nov 9 16:07:50.599: ISAKMP:(1033):Old State = IKE_I_AM1 New State = IKE_P1_COMPLETE

*Nov 9 16:07:50.599: ISAKMP:(1033):Need XAUTH

*Nov 9 16:07:50.599: ISAKMP:(1033):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE

*Nov 9 16:07:50.599: ISAKMP:(1033):Old State = IKE_P1_COMPLETE New State =

IKE_P1_COMPLETE

*Nov 9 16:07:50.607: ISAKMP (1033): received packet from 8.9.50.4 dport 4500 sport

4500 Global (I) CONF_XAUTH

*Nov 9 16:07:50.607: ISAKMP: set new node -1530073162 to CONF_XAUTH

*Nov 9 16:07:50.607: ISAKMP:(1033): processing HASH payload. message ID = -1530073162

*Nov 9 16:07:50.607: ISAKMP:(1033): processing NOTIFY RESPONDER_LIFETIME protocol 1

spi 0, message ID = -1530073162, sa = 48BB14AC


authenticated

*Nov 9 16:07:50.607: ISAKMP:(1033): processing responder lifetime

*Nov 9 16:07:50.607: ISAKMP:(1033): start processing isakmp responder lifetime

*Nov 9 16:07:50.607: ISAKMP:(1033):Returning Actual lifetime: 2147483

*Nov 9 16:07:50.607: ISAKMP:(1033): restart ike sa timer to 86400 secs

*Nov 9 16:07:50.607: ISAKMP:(1033):Started lifetime timer: 0.

*Nov 9 16:07:50.607: ISAKMP:(1033):deleting node -1530073162 error FALSE reason

"Informational (in) state 1"

*Nov 9 16:07:50.611: ISAKMP:(1033):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY


IKE_P1_COMPLETE

This is where Phase 1.5 starts:




*Nov 9 16:07:50.611: ISAKMP:(1033):processing transaction payload from 8.9.50.4.

message ID = -516137857

*Nov 9 16:07:50.611: ISAKMP: Config payload REQUEST

*Nov 9 16:07:50.611: ISAKMP:(1033):checking request:

*Nov 9 16:07:50.611: ISAKMP: XAUTH_USER_NAME_V2

*Nov 9 16:07:50.611: ISAKMP: XAUTH_USER_PASSWORD_V2

*Nov 9 16:07:50.611: ISAKMP:(1033):Xauth process request

*Nov 9 16:07:50.611: ISAKMP:(1033):Input = IKE_MESG_FROM_PEER, IKE_CFG_REQUEST


IKE_XAUTH_REPLY_AWAIT

*Nov 9 16:07:50.615: username: cciesec

*Nov 9 16:07:50.615: password: <omitted>

*Nov 9 16:07:50.615: ISAKMP:(1033): responding to peer config from 8.9.50.4. ID = -

516137857

*Nov 9 16:07:50.615: ISAKMP: Marking node -516137857 for late deletion


4500 (I) CONF_XAUTH


*Nov 9 16:07:50.615: ISAKMP:(1033):Input = IKE_MESG_INTERNAL, IKE_XAUTH_REPLY_ATTR

*Nov 9 16:07:50.615: ISAKMP:(1033):Old State = IKE_XAUTH_REPLY_AWAIT New State =

IKE_XAUTH_REPLY_SENT








message ID = -64380401

*Nov 9 16:07:50.635: ISAKMP: Config payload SET

*Nov 9 16:07:50.635: ISAKMP:(1033):Xauth process set, status = 1

*Nov 9 16:07:50.639: ISAKMP:(1033):checking SET:

*Nov 9 16:07:50.639: ISAKMP: XAUTH_STATUS_V2 XAUTH-OK

*Nov 9 16:07:50.639: ISAKMP:(1033):attributes sent in message:

*Nov 9 16:07:50.639: Status: 1

*Nov 9 16:07:50.639: ISAKMP:(1033):deleting node -516137857 error FALSE reason "Done

with xauth request/reply exchange"

*Nov 9 16:07:50.639: ISAKMP: Marking node -64380401 for late deletion


4500 (I) CONF_XAUTH


*Nov 9 16:07:50.639: ISAKMP:(1033):Input = IKE_MESG_FROM_PEER, IKE_CFG_SET

*Nov 9 16:07:50.639: ISAKMP:(1033):Old State = IKE_XAUTH_REPLY_SENT New State =

IKE_P1_COMPLETE

*Nov 9 16:07:50.639: ISAKMP:(1033):Need config/address

*Nov 9 16:07:50.639: ISAKMP: set new node 940553137 to CONF_ADDR

*Nov 9 16:07:50.643: ISAKMP: Sending APPLICATION_VERSION string: Cisco IOS Software,

2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 12.4(22)T, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2008 by Cisco Systems, Inc.

Compiled Fri 10-Oct-08 00:05 by prod_rel_team

*Nov 9 16:07:50.643: ISAKMP:(1033): initiating peer config to 8.9.50.4. ID =

940553137


4500 (I) CONF_ADDR




IKE_CONFIG_MODE_REQ_SENT


4500 Global (I) CONF_ADDR


message ID = 940553137

*Nov 9 16:07:50.695: ISAKMP: Config payload REPLY

*Nov 9 16:07:50.695: ISAKMP(1033) process config reply

*Nov 9 16:07:50.695: ISAKMP:(1033):deleting node -64380401 error FALSE reason "No

Error"

*Nov 9 16:07:50.695: ISAKMP:(1033):deleting node 940553137 error FALSE reason

"Transaction mode done"

*Nov 9 16:07:50.695: ISAKMP:(1033):Input = IKE_MESG_FROM_PEER, IKE_CFG_REPLY

*Nov 9 16:07:50.695: ISAKMP:(1033):Old State = IKE_CONFIG_MODE_REQ_SENT New State =

IKE_P1_COMPLETE



IKE_P1_COMPLETE

*Nov 9 16:07:50.703: ISAKMP: set new node -1836095884 to QM_IDLE

*Nov 9 16:07:50.703: ISAKMP:(1033): initiating peer config to 8.9.50.4. ID = -

1836095884


4500 (I) QM_IDLE


*Nov 9 16:07:50.703: ISAKMP:(1033):Input = IKE_MESG_INTERNAL, IKE_SEND_MODCFG_MSG_SET





IKE_CONFIG_MODE_SET_SENT


4500 Global (I) QM_IDLE


message ID = -1836095884

*Nov 9 16:07:50.711: ISAKMP: Config payload ACK

*Nov 9 16:07:50.711: ISAKMP:(1033):deleting node -1836095884 error FALSE reason

"Transaction mode done"

*Nov 9 16:07:50.711: ISAKMP:(1033):Talking to a Unity Client

*Nov 9 16:07:50.711: ISAKMP:(1033):Input = IKE_MESG_FROM_PEER, IKE_CFG_ACK

*Nov 9 16:07:50.711: ISAKMP:(1033):Old State = IKE_CONFIG_MODE_SET_SENT New State =

IKE_P1_COMPLETE

*Nov 9 16:07:50.711: EZVPN(EZCLIENT) Server does not allow save password option,


We store our XAUTH credentials locally, however, Easy VPN server does not allow this. Because our Group Policy is stored on the ACS, this is where we should go to check our settings. User REMOTE is a member of “Group Policy” ACS Group:




Set “ipsec:save-password” to 1, click Submit + Restart and test:

R8#un all


R8#cry ips cl ez co

R8#

*Nov 9 16:22:41.207: %CRYPTO-6-EZVPN_CONNECTION_UP: (Client) User=cciesec

Group=REMOTE Server_public_addr=8.9.50.4 Assigned_client_addr=8.9.200.100

R8#

*Nov 9 16:22:41.211: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up

R8#



changed state to up

R8#sh cry ip

*Nov 9 16:22:44.163: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-

Access2, changed state to up

R8#sh cry ipsec clie ez








Mask: 255.255.255.255



Address : 10.4.4.0

Mask : 255.255.255.0

Protocol : 0x0

Source Port: 0

Dest Port : 0


R8#ping 10.4.4.20 so l8




!!!!!


R8#




R8#sh cry sess de






Uptime: 00:01:45



Phase1_id: 8.9.50.4

Desc: (none)








4.9 Easy VPN PKI-based Per-User Attributes


Group authorization should be performed locally and should be the same as in task 4.6.

In addition to this, users should be authorized based on CN field from the certificate.

Assign a specific user IP address 8.9.100.100 and allow him to only reach CAT2.

Test this configuration with VPN Client installed on Test PC.


At the beginning, verify if you can reach the server from the VPN Client:

Not that bad Open the VPN Client, run the ISAKMP debug on R4 and connect:

R4#deb cry isa




R4#


1436 Global (R) MM_NO_STATE


Global (N) NEW SA


*Nov 9 17:20:28.510: ISAKMP: New peer created peer = 0x498B33C0 peer_handle =

0x80000037

*Nov 9 17:20:28.510: ISAKMP: Locking peer struct 0x498B33C0, refcount 1 for




isadb_insert sa = 4983782C


*Nov 9 17:20:28.510: ISAKMP:(0):Old State = IKE_READY New State = IKE_R_MM1




*Nov 9 17:20:28.514: ISAKMP:(0): vendor ID is XAUTH




*Nov 9 17:20:28.514: ISAKMP:(0): processing IKE frag vendor id payload







*Nov 9 17:20:28.514: ISAKMP:(0):No pre-shared key with 8.9.2.200!

*Nov 9 17:20:28.514: ISAKMP : Scanning profiles for xauth ... ISA_PROF ISA_PROF2

*Nov 9 17:20:28.514: ISAKMP:(0): Authentication by xauth preshared


*Nov 9 17:24:20.198: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B

*Nov 9 17:24:20.198: ISAKMP:(0):atts are acceptable. Next payload is 3

*Nov 9 17:24:20.198: ISAKMP:(0):Acceptable atts:actual life: 86400

*Nov 9 17:24:20.198: ISAKMP:(0):Acceptable atts:life: 0

*Nov 9 17:24:20.198: ISAKMP:(0):Fill atts in sa vpi_length:4

*Nov 9 17:24:20.198: ISAKMP:(0):Fill atts in sa life_in_seconds:2147483


*Nov 9 17:24:20.198: ISAKMP:(0)::Started lifetime timer: 86400.





*Nov 9 17:24:20.198: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

*Nov 9 17:24:20.198: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM1

There is no need for Pre-Shared Key since we are using RSA Signatures for authentication. Enable debug on the VPN Client. Set High debugging level for IKE:

Try to connect again.

So, it‟s the server who sends DELETE payload. Reason is “UNSPECIFIED” which obiously does not help us much. ISAKMP packets are exchanged, they are not filtered. It‟s the highest time to take a look at the configuration:




R4#sh cry isa prof

ISAKMP PROFILE ISA_PROF

Ref Count = 3

Identities matched are:

group CCIE

Certificate maps matched are:

keyring(s): <none>

trustpoint(s): <all>

virtual-template: 2

ISAKMP PROFILE ISA_PROF2

Ref Count = 6


group REMOTE


Identity presented is: ip-address

keyring(s): <none>


virtual-template: 3

R4#sh run | se CCIE

crypto isakmp client configuration group CCIE

pool EZPOOL

acl 170

match identity group CCIE

R4#sh run int virtual-tem 2



!




Virtual template interface lacks tunnel protection. Fix this and look at debugs again:

R4(config)#interface Virtual-Template2 type tunnel

R4(config-if)#tunnel protection ipsec profile IPSEC_PROF6




next-payload : 6

type : 9

Dist. name : cn=Leve,ou=CCIE,o=IPExpert

protocol : 17

port : 500

length : 59

*Nov 9 17:51:19.754: ISAKMP:(0):: UNITY's identity group: OU = CCIE

*Nov 9 17:51:19.754: ISAKMP:(0):: peer matches ISA_PROF profile

*Nov 9 17:51:19.754: ISAKMP:(1020):Setting client config settings 4816D0DC

*Nov 9 17:51:19.754: ISAKMP:(1020):(Re)Setting client authorization list EZ_PKI

*Nov 9 17:51:19.754: ISAKMP:(1020): Fetching username from Cert




*Nov 9 17:51:19.754: ISAKMP:(1020): Valid username found in the cert

*Nov 9 17:51:19.758: ISAKMP/xauth: initializing AAA request

*Nov 9 17:51:19.758: ISAKMP:(1020): processing CERT payload. message ID = 0

*Nov 9 17:51:20.010: ISAKMP: Deleting peer node by peer_reap for 8.9.2.200: 498B29BC


*Nov 9 17:51:20.014: ISAKMP:(1020):Old State = IKE_DEST_SA New State = IKE_DEST_SA

Check the PKI authorization process:

R4#deb cry pki tra

Crypto PKI Trans debugging is on

R4#


*Nov 9 17:59:00.702: CRYPTO_PKI: Identity not specified for session 10021

*Nov 9 17:59:00.822: CRYPTO_PKI: Added x509 peer certificate - (717) bytes

*Nov 9 17:59:00.822: CRYPTO_PKI: validation path has 1 certs

*Nov 9 17:59:00.826: CRYPTO_PKI: Found a issuer match

*Nov 9 17:59:00.826: CRYPTO_PKI: Using CA to validate certificate

*Nov 9 17:59:00.830: CRYPTO_PKI: Certificate validated without revocation check

*Nov 9 17:59:00.834: CRYPTO_PKI: Selected AAA username: 'CCIE'

*Nov 9 17:59:00.834: CRYPTO_PKI: chain cert was anchored to trustpoint CA, and chain

validation result was: CRYPTO_VALID_CERT_WITH_WARNING

*Nov 9 17:59:00.834: CRYPTO_PKI: Validation TP is CA

*Nov 9 17:59:00.834: CRYPTO_PKI: Trust-Point CA picked up

*Nov 9 17:59:00.834: CRYPTO_PKI: Identity selected (CA) for session 20022


You could also pen ACS “Failed attempts” log:

We were asked to authorize user based on CN field, not OU. Change the trustpoint configuration to reflect this and verify the connection is working:

R4(config)#do sh run | se trustpoint




revocation-check none

authorization username subjectname organizationalunit

R4(config)#cry pki trust CA

R4(ca-trustpoint)#authorization username subjectname commonname





You should now move to the Configuration section Part II.




Lab 4B Detailed Solutions – Part II

4.10 ASA Easy VPN Server with External Per-User attributes

Configure ASA1 to accept remote VPN connections.

Use R8 as the Easy VPN Client. Set group name to “REMOTE”. Create Loopback 8 (8.8.8.8 /24) interface to emulate the inside network.

Use 3DES encryption and MD-5 HMAC for both phases. Set PSK to “cisco.”

Group authorization should be performed locally.

Use the following parameters for authorization:

Assign the users DNS and WINS server 10.1.1.50. The domain sent should be ipexpert.com. Use address pool 10.80.80.0/24 to allocate IP addresses. Packets to networks other then 10.1.1.0/24 should be sent in clear-text form. VPN connection should be terminated after 10 minutes of inactivity.

Create user “VPNUSER” with password “ipexpert” and authenticate him to RADIUS server at 10.1.1.100. Use shared secret “CISCO” for RADIUS communication.

Make sure that user can only use the “REMOTE” VPN group.


Start verification on R8. Briefly check the config making sure the peer and key are set:

R8#sh run | se ipsec client


connect manual

group REMOTE key cisco

mode client

peer 8.9.2.10

xauth userid mode interactive



Everything looks good. Try to establish the VPN tunnel and ping the ACS if it came up:



Username:



changed state to up

R8#ping 10.1.1.100 so l8




.....





Could be better. Verify both IPSec Phases:

R8#sh cry isa pe

Peer: 8.9.2.10 Port: 500 Local: 192.168.8.8

Phase1 id: 8.9.2.10

R8#sh cry sess de





Interface: FastEthernet0/1

Uptime: 00:02:06



Phase1_id: 8.9.2.10

Desc: (none)



IPSEC FLOW: permit ip host 10.80.80.1 0.0.0.0/0.0.0.0




So, the packets are getting encrypted. Check the other end of the tunnel:

ASA1(config)# sh cry isa sa de

Active SA: 1

Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1 IKE Peer: 8.9.2.8

Type : user Role : responder

Rekey : no State : AM_ACTIVE

Encrypt : 3des Hash : MD5

Auth : preshared Lifetime: 86400

Lifetime Remaining: 86130

ASA1(config)# sh cry ipse sa | in encap|decap

#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5

#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

Now we see that ASA receives the traffic from both R8 and the ACS. Something may be filtering IPSec from ASA to R8. Take a look at ASA2 (turn on console loggin before you check this):

ASA2(config) #

%ASA-3-106010: Deny inbound protocol 50 src outside:8.9.2.10 dst inside:8.9.2.8





Why does it happen? R8 is NATed on ASA2 to 8.9.2.8 in VLAN 2. Re-establish the connection again and take a look at the state table on ASA2:




ASA2(config)# sh conn

5 in use, 12 most used

ESP outside 8.9.2.10 inside 192.168.8.8, idle 0:00:22, bytes 620

UDP outside 8.9.2.10:500 inside 192.168.8.8:500, idle 0:00:47, bytes 4354, flags -

IKE Phase II uses ESP but we know we are using NAT along the path between the peers. Sounds like NAT-T could have been disabled.

R8#sh run | in transparency

no crypto ipsec nat-transparency udp-encaps

R8(config)#crypto ipsec nat-transparency udp-encapsulation

R8(config)#do clear cry sess

R8(config)#do cry ips cl ez co

R8(config)#do cry ips cl ez x

Username: VPNUSER

Password:

R8#sh cry sess de






Uptime: 00:00:22



Phase1_id: 8.9.2.10

Desc: (none)



IPSEC FLOW: permit ip host 10.80.80.1 0.0.0.0/0.0.0.0




R8#ping 10.1.1.100 so l8




!!!!!


Okay, so it is working as intended. Are you sure? Always remember to check all the settings they asked you to configure.












Mask: 255.255.255.255






The only thing which is missing here is Split Tunneling. Verify what happens during the Mode Config phase on the client (clear the session and reconnect again):

R8#clear cry sess

R8#deb cry ipse cl ez


Nov 20 13:09:27.248: EZVPN(EZCLIENT): Event: MODE_CONFIG_REPLY F404C62B D4C65A07

CC8E54F1 D938F7B5

*Nov 20 13:09:27.248: EZVPN(EZCLIENT): ezvpn_parse_mode_config_msg

*Nov 20 13:09:27.248: EZVPN: Attributes sent in m

R8#essage:

*Nov 20 13:09:27.248: Address: 10.80.80.1

*Nov 20 13:09:27.248: DNS Primary: 10.1.1.50

*Nov 20 13:09:27.248: NBMS/WINS Primary: 10.1.1.50

*Nov 20 13:09:27.248: Savepwd off

*Nov 20 13:09:27.248: Default Domain: ipexpert.com

*Nov 20 13:09:27.248: EZVPN: Unknown/Unsupported Attr: APPLICATION_VERSION (0x7)

*Nov 20 13:09:27.248: EZVPN: Unknown/Unsupported Attr: INCLUDE_LOCAL_LAN (0x7006)

*Nov 20 13:09:27.252: EZVPN(EZCLIENT): ezvpn_mode_config

*Nov 20 13:09:27.268: EZVPN(EZCLIENT): ezvpn_nat_config

*Nov 20 13:09:27.276: EZVPN(EZCLIENT): New State: SS_OPEN

*Nov 20 13:09:27.292: EZVPN(EZCLIENT): Current State: SS_OPEN

*Nov 20 13:09:27.292: EZVPN(EZCLIENT): Event: SOCKET_READY

*Nov 20 13:09:27.292: EZVPN(EZCLIENT): No state change

*Nov 20 13:09:27.304: EZVPN(EZCLIENT): Current State: SS_OPEN

*Nov 20 13:09:27.304: EZVPN(EZCLIENT): Event: SOCKET_UP


This is now what we expected to see. Correct this on ASA1:

ASA1(config)# sh run group-policy EZGROUP

group-policy EZGROUP internal

group-policy EZGROUP attributes

wins-server value 10.1.1.50

dns-server value 10.1.1.50

vpn-idle-timeout 10

split-tunnel-policy excludespecified

split-tunnel-network-list value SPLIT

default-domain value ipexpert.com

address-pools value EZPOOL




ASA1(config)# group-policy EZGROUP att

ASA1(config-group-policy)# split-tunnel-policy tunnelspecified

Give it another try and verify Split Tunneling on R8:









Mask: 255.255.255.255






Address : 10.1.1.0

Mask : 255.255.255.0

Protocol : 0x0

Source Port: 0

Dest Port : 0


R8#ping 10.1.1.100 so l 8




!!!!!



4.11 ASA Easy VPN Server with External Group Authorization and PKI-Based Per-User Attributes

Change ASA1 configuration to use external group policy on the ACS.

Use R2 as the NTP and CA server. Synchronize time on ASA with R2.

Enroll VPN Client and ASA1 for certificate with R2.

Client‟s certificate should have CN set to “IP Expert” and OU set to “CCIE.”

Use 3DES encryption and MD-5 HMAC for both phases.

Name the policy “EXTERNAL” and store the following parameters on RADIUS server:

Use address pool 10.200.200.0/24 to allocate IP addresses. Tunnel only packets sent to 10.1.1.0/24.

Only the user “IP Expert” should receive a banner message saying “You are now connected to the internal network.” after the VPN connection has been established.





If you had tried to connect you would have received the following message on the ASA :

ASA1(config)#

%ASA-3-713198: Group = CCIE, Username = CCIE, IP = 8.9.2.200, User Authorization

failed: CCIE

%ASA-3-713902: Group = CCIE, Username = CCIE, IP = 8.9.2.200, Removing peer from peer

table failed, no match!

%ASA-4-713903: Group = CCIE, Username = CCIE, IP = 8.9.2.200, Error: Unable to remove

PeerTblEntry

%ASA-4-113019: Group = , Username = , IP = 0.0.0.0, Session disconnected. Session

Type: , Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown

Nov 20 14:12:00 [IKEv1]: Group = CCIE, Username = CCIE, IP = 8.9.2.200, Removing peer

from peer table failed, no match!

Nov 20 14:12:00 [IKEv1]: Group = CCIE, Username = CCIE, IP = 8.9.2.200, Error: Unable

to remove PeerTblEntry

What this is may be an indication of? Note that we were supposed to use “IP Expert” as the user for authorization. Look at the tunnel configuration on ASA:

ASA1(config)# sh run tunnel-group CCIE

tunnel-group CCIE type remote-access

tunnel-group CCIE general-attributes

authorization-server-group RAD

default-group-policy EXTERNAL

authorization-required

username-from-certificate OU

tunnel-group CCIE ipsec-attributes

trust-point CA

isakmp ikev1-user-authentication none

ASA1(config)# tunnel-group CCIE general-attributes

ASA1(config-tunnel-general)# username-from-certificate cn

Connect again and look into the logs again. Sometimes this is enough to determine the root cause of the problem.

ASA1(config)#

%ASA-4-737019: IPAA: Unable to get address from group-policy or tunnel-group local

pools

%ASA-4-737012: IPAA: Address assignment failed

%ASA-3-713132: Group = CCIE, Username = IP Expert, IP = 8.9.2.200, Cannot obtain an IP

address for remote peer

%ASA-3-713902: Group = CCIE, Username = IP Expert, IP = 8.9.2.200, Removing peer from

peer table failed, no match!

%ASA-4-713903: Group = CCIE, Username = IP Expert, IP = 8.9.2.200, Error: Unable to

remove PeerTblEntry

%ASA-4-113019: Group = , Username = , IP = 0.0.0.0, Session disconnected. Session

Type: , Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown




Check the ACS group profile to find out what was configured there:

Compare this to the ASA config. When fixed, try to bring the tunnel up again:

ASA1(config)# sh run | in local pool

ip local pool EZPOOL 10.80.80.1-10.80.80.254

ip local pool EZPOL2 10.200.200.1-10.200.200.254

ASA1(config)# no ip local pool EZPOL2 10.200.200.1-10.200.200.254

ASA1(config)# ip local pool EZPOOL2 10.200.200.1-10.200.200.254





4.12 DMVPN Phase I

Configure DMVPN between R5, R6 and R7.

R7 should be seen as 8.9.2.7 on VLAN 2 and should act as a Hub in this configuration.

Traffic between VLAN 5 and VLAN 6 should be switched by the Hub

Only one tunnel network is allowed for this task – 172.16.100.0/24.

Use AES 192 and SHA-1 for Phase I. Use 3DES and MD5 for Phase II. PSK “cisco” should be used for authentication.

Run EIGRP process to advertise both private networks to the Hub. Use AS 100.




4.13 DMVPN Phase II

Change the existing configuration from Task 4.12 to enable Spoke-To-Spoke tunnels.





4.14 DMVPN Phase III

Change the existing configuration from Task 4.12 and Task 4.13.

Force EIGRP on R7 to change the Next-Hop information

Traffic from R5 to R6 should not flow across the Hub


This is what we see on R7 which is the DMVPN hub:

R7#

*Nov 21 14:24:49.233: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor

172.16.100.6 (Tunnel100) is down: retry limit exceeded

R7#


172.16.100.6 (Tunnel100) is up: new adjacency

R7#


172.16.100.6 (Tunnel100) is down: retry limit exceeded




R7#sh ip eigrp ne


H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 172.16.100.6 Tu100 10 00:00:09 1 4500 2 0

R6#sh ip eigrp ne


R5#sh ip eigrp ne


So the hub receives EIGRP packets from R6, but it seems that R6 does not:


Peer: 8.9.50.6 Port: 4500 Local: 10.7.7.7

Phase1 id: 8.9.50.6







Uptime: 00:00:23



Phase1_id: 8.9.50.6

Desc: (none)



IKE SA: local 10.7.7.7/4500 remote 8.9.50.6/4500 Inactive

Capabilities:N connid:1069 lifetime:0





You should now check NHRP mappings to see where the packets are being sent to (if at all):

R6#sh ip nhrp br


172.16.100.7/32 172.16.100.7 8.9.2.7 static Tu100 < >

R7#sh ip nhrp br


172.16.100.6/32 172.16.100.6 incomplete

Make sure NHRP packets are sent to the Hub (shut and no shut tunnel interface):

R6#deb nhrp

R6#deb nhrp packet

R6#deb nhrp error




*Nov 21 14:57:46.911: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100,

changed state to up

R6#

*Nov 21 14:57:47.451: NHRP: Setting retrans delay to 4 for nhs dst 8.9.2.7

R6#


R6#


R6#


R6#


R6 only changes the retransmission timer for NHRP. Verify if NHRP configuration is correct on R6:

interface Tunnel100

ip address 172.16.100.6 255.255.255.0

no ip redirects

ip nhrp map 172.16.100.7 8.9.2.7



ip nhrp nhs 8.9.2.7

ip nhrp shortcut

ip nhrp redirect



tunnel key 1


Wrong NHS has been added. Re-configure and observer the debug again:


R6(config-if)#no ip nhrp nhs 8.9.2.7

R6(config-if)#ip nhrp nhs 172.16.100.7

R6(config-if)#

*Nov 21 15:04:56.483: NHRP: Attempting to send packet via DEST 172.16.100.7

*Nov 21 15:04:56.483: NHRP: NHRP successfully resolved 172.16.100.7 to NBMA 8.9.2.7

*Nov 21 15:04:56.483: NHRP: Encapsulation succeeded. Tunnel IP addr 8.9.2.7

*Nov 21 15:04:56.483: NHRP: Send Registration Request via Tunnel100 vrf 0, packet

size: 92



*Nov 21 15:04:56.483: pktsz: 92 extoff: 52

*Nov 21 15:04:56.483: (M) flags: "unique nat ", reqid: 11

*Nov 21 15:04:56.483: src NBMA: 8.9.50.6


*Nov 21 15:04:56.483: (C-1) code: no error(0)

*Nov 21 15:04:56.483: prefix: 32, mtu: 17912, hd_time: 7200

*Nov 21 15:04:56.483: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0,

pref: 0

*Nov 21 15:04:56.483: NHRP: 120 bytes out Tunnel100

*Nov 21 15:04:56.523: NHRP: Rec

R6(config-if)#eive Registration Reply via Tunnel100 vrf 0, packet size: 112



*Nov 21 15:04:56.523: pktsz: 112 extoff: 52


*Nov 21 15:04:56.523: src NBMA: 8.9.50.6








pref: 0

*Nov 21 15:04:56.523: NHRP: netid_in = 0, to_us = 1

*Nov 21 15:04:56.523: NHRP: NHS-UP: 172.16.100.7exi

R6(config)#exi

R6#

*Nov 21 15:04:58.991: %SYS-5-CONFIG_I: Configured from console by console

R6#

*Nov 21 15:05:00.407: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.100.7

(Tunnel100) is up: new adjacency

R6#ping 172.16.100.7



!!!!!


Alright, so R6 registered. What about R5?


R5#sh ip nhrp br


8.9.2.7/32 8.9.2.7 172.16.100.7 static Tu100 < >

This is not what we expected to see. Fix immediately.

R5#sh run int tu 100



!

interface Tunnel100

ip address 172.16.100.5 255.255.255.0

no ip redirects


ip nhrp map 8.9.2.7 172.16.100.7


ip nhrp nhs 172.16.100.7

ip nhrp shortcut

ip nhrp redirect



tunnel key 1


R5(config)#int tunnel 100

R5(config-if)#no ip nhrp map 8.9.2.7 172.16.100.7

R5(config-if)#ip nhrp map 172.16.100.7 8.9.2.7

R5#sh ip nhrp br


172.16.100.7/32 172.16.100.7 8.9.2.7 static Tu100 < >




R7#sh ip nhrp br


172.16.100.6/32 172.16.100.6 8.9.50.6 dynamic Tu100 < >

R7 still does not have a mapping for R5. Check if R5 sends NHRP Registration Requests and if so also check IKE SA:

R5#

*Nov 21 04:19:01.156: NHRP: Send Registration Request via Tunnel100 vrf 0, packet

size: 92



*Nov 21 04:19:01.156: pktsz: 92 extoff: 52


*Nov 21 04:19:01.156: src NBMA: 8.9.50.5





pref: 0


Okay, so let‟s take a look at ISAKMP negotiation:

R5#


*Nov 21 04:28:28.656: %LINK-3-UPDOWN: Interface Tunnel100, changed state to up

*Nov 21 04:28:28.664: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON



*Nov 21 04:28:28.672: ISAKMP: New peer created peer = 0x493FFE10 peer_handle =

0x80000041

*Nov 21 04:28:28.672: ISAKMP: Locking peer struct 0x493FFE10, refcount 1 for

isakmp_initiator


*Nov 21 04:28:28.672: ISAKMP: set new node 0 to QM_IDLE


isadb_insert sa = 493FF654

*Nov 21 04:28:28.672: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.

*Nov 21 04:28:28.672: ISAKMP:(0):found peer pre-shared key matching 8.9.2.7

*Nov 21 04:28:28.672: ISAKMP:(0): constructed NAT-T vendor-rfc

R5#3947 ID




*Nov 21 04:28:28.672: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM

*Nov 21 04:28:28.676: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1

*Nov 21 04:28:28.676: ISAKMP:(0): beginning Main Mode exchange


(I) MM_NO_STATE





*Nov 21 04:28:28.712: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2




*Nov 21 04:28:28.712: ISAKMP (0): vendor ID is NAT-T RFC 3947





*Nov 21 04:28:28.712: ISAKMP:(0): local preshared key found

*Nov 21 04:28:28.712: ISAKMP : Scanning profiles for xauth ...

*Nov 21 04:28:28.712: ISAKMP:(0):Checking ISAKMP transform 1 against priority 12

policy

*Nov 21 04:28:28.712: ISAKMP: encryption AES-CBC

*Nov 21 04:28:28.712: ISAKMP: keylength of 192

*Nov 21 04:28:28.712: ISAKMP: hash SHA

*Nov 21 04:28:28.716: ISAKMP: default group 1

*Nov 21 04:28:28.716: ISAKMP: auth pre-share

*Nov 21 04:28:28.716: ISAKMP: life type in seconds

*Nov 21 04:28:28.716: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

*Nov 21 04:28:28.716: ISAKMP:(0):atts are acceptable. Next payload is 0

*Nov 21 04:28:28.716: ISAKMP:(0):Acceptable atts:actual life: 0

*Nov 21 04:28:28.716: ISAKMP:(0):Acceptable atts:life: 0

*Nov 21 04:28:28.716: ISAKMP:(0):Fill atts in sa vpi_length:4

*Nov 21 04:28:28.716: ISAKMP:(0):Fill atts in sa life_in_seconds:86400


*Nov 21 04:28:28.716: ISAKMP:(0)::Started lifetime timer: 86400.



*Nov 21 04:28:28.716: ISAKMP (0): vendor ID is NAT-T RFC 3947




(I) MM_SA_SETUP


*Nov 21 04:28:28.720: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE



Global (I) MM_SA_SETUP



*Nov 21 04:28:28.800: ISAKMP:(0): processing KE payload. message ID = 0

*Nov 21 04:28:28.828: ISAKMP:(0): processing NONCE payload. message ID = 0








*Nov 21 04:28:28.828: ISAKMP:received payload type 20

*Nov 21 04:28:28.828: ISAKMP (1055): His hash no match - this node outside NAT


*Nov 21 04:28:28.828: ISAKMP (1055): His hash no match - this node outside NAT



*Nov 21 04:28:28.832: ISAKMP:(1055):Send initial contact

*Nov 21 04:28:28.832: ISAKMP:(1055):SA is doing pre-shared key authentication using id

type ID_IPV4_ADDR


next-payload : 8

type : 1

address : 8.9.50.5

protocol : 17

port : 0

length : 12






4500 (I) MM_KEY_EXCH




*Nov 21 04:28:29.656: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100,

changed state to up

*Nov 21 04:28:34.660: ISAKMP:(1051):purging node 867430968

R5#

R5#

*Nov 21 04:28:38.832: ISAKMP:(1055): retransmitting phase 1 MM_KEY_EXCH...

*Nov 21 04:28:38.832: ISAKMP (1055): incrementing error counter on sa, attempt 1 of 5:

retransmit phase 1

*Nov 21 04:28:38.832: ISAKMP:(1055): retransmitting phase 1 MM_KEY_EXCH




R5#

*Nov 21 04:28:44.660: ISAKMP:(1051):purging SA., sa=49316DE4, delme=49316DE4

R5#

*Nov 21 04:28:48.832: ISAKMP:(1055): retransmitting phase 1 MM_KEY_EXCH...


retransmit phase 1

*Nov 21 04:28:48.832: ISAKMP:(1055): retransmitting phase 1 MM_KEY_EXCH




After analyzing the above output we can see that everything looks good until we move on to UDP 4500. This happened because NAT had been detected for R7 (hash mismatch). Re-transmissions may indicate that some packets are getting filtered before they reach the intended destination.

R7#deb crypto condition peer ip 8.9.50.5

R7#deb cry isa




500 (R) MM_KEY_EXCH





4500 Global (R) QM_IDLE

*Nov 21 16:06:00.823: ISAKMP:(1082): phase 1 packet is a duplicate of a previous

packet.

*Nov 21 16:06:00.823: ISAKMP:(1082): retransmitting due to retransmit phase 1


4500 Global (R) MM_KEY_EXCH








Peer: 8.9.50.5 Port: 4500 Local: 10.7.7.7

Phase1 id: 8.9.50.5

R7 sees Phase I as completed, but R5 does not. Looks like packets from R7 don‟t reach R5. There are a lot of things which may drop the packets, but generally you should start verify the packet flow step by step:

ASA1(config)# access-list CAP permit udp host 10.7.7.7 host 8.9.50.5 eq 4500

ASA1(config)# capture CAP interface DMZ access-list CAP real-time

Warning: using this option with a slow console connection may

result in an excessive amount of non-displayed packets

due to performance limitations.

Use ctrl-c to terminate real-time capture

So the packets don‟t even reach ASA1. Check the routing and the interface:

R7(config)#access-list 101 permit udp host 10.7.7.7 host 8.9.50.5 eq 4500



IP packet debugging is on (detailed) for access list 101

R7#

*Nov 21 16:25:08.235: FIBipv4-packet-proc: route packet from (local) src 10.7.7.7 dst

8.9.50.5


*Nov 21 16:25:08.235: IP: s=10.7.7.7 (local), d=8.9.50.5 (FastEthernet0/1), len 124,

sending

*Nov 21 16:25:08.239: UDP src=4500, dst=4500


output feature

*Nov 21 16:25:08.239: UDP src=4500, dst=4500, IPSec output classification(24),

rtype 1, forus FALSE, sendself FALSE, mtu 0


output feature

*Nov 21 16:25:08.239: UDP src=4500, dst=4500, IPSec: to crypto engine(53), rtype

1, forus FALSE, sendself FALSE, mtu 0


output feature

*Nov 21 16:25:08.239: UDP src=4500, dst=4500, Post-encryption output features(54),

rtype 1, forus FALSE, sendself FALSE, mtu 0

*

R7#Nov 21 16:25:08.239: IP: s=10.7.7.7 (local), d=8.9.50.5 (FastEthernet0/1), len 124,

post-encap feature

*Nov 21 16:25:08.239: UDP src=4500, dst=4500, (1), rtype 1, forus FALSE, sendself

FALSE, mtu 0


post-encap feature

*Nov 21 16:25:08.239: UDP src=4500, dst=4500, FastEther Channel(2), rtype 1, forus

FALSE, sendself FALSE, mtu 0


sending full packet

*Nov 21 16:25:08.239: UDP src=4500, dst=4500

*Nov 21 16:25:08.243: FIBipv4-packet-proc: route packet from (local) src 10.7.7.7 dst

8.9.50.5





R7#sh run int f0/1



!


ip address 10.7.7.7 255.255.255.0

duplex auto

speed auto

crypto map MAP1

So, what‟s between the ASA1 and R7? CAT4?




!




ip access-group 100 in


end

Cat4#sh access-list 100


10 deny udp host 10.7.7.7 host 8.9.50.5 eq non500-isakmp

20 permit ip any any


Cat4(config-if)#no ip access-group 100 in

%ASA-4-106023:

1: 16:34:18.069790 10.7.7.7.4500 > 8.9.50.5.4500: udp 80

2: 16:34:18.109079 10.7.7.7.4500 > 8.9.50.5.4500: udp 192

3: 16:34:18.156974 10.7.7.7.4500 > 8.9.50.5.4500: udp 156

4: 16:34:19.606978 10.7.7.7.4500 > 8.9.50.5.4500: udp 100

5: 16:34:19.639172 10.7.7.7.4500 > 8.9.50.5.4500: udp 100

6: 16:34:19.645596 10.7.7.7.4500 > 8.9.50.5.4500: udp 84

7: 16:34:19.654369 10.7.7.7.4500 > 8.9.50.5.4500: udp 116

8: 16:34:19.654781 10.7.7.7.4500 > 8.9.50.5.4500: udp 108

9: 16:34:19.682139 10.7.7.7.4500 > 8.9.50.5.4500: udp 108

R7#ping 172.16.100.5



!!!!!


R5#sh ip route ei


D 10.6.6.0 [90/28162560] via 172.16.100.7, 00:00:50, Tunnel100




R6#sh ip route ei


D 10.5.5.0 [90/28162560] via 172.16.100.7, 00:01:03, Tunnel100

R5#ping 10.6.6.6 so f0/1




!!!!!


R5#

R5#sh cry isa pe

Peer: 8.9.2.7 Port: 4500 Local: 8.9.50.5

Phase1 id: 10.7.7.7

Peer: 8.9.50.2 Port: 848 Local: 8.9.50.5

Phase1 id: 8.9.50.2

Peer: 8.9.50.6 Port: 500 Local: 8.9.50.5

Phase1 id: 8.9.50.6


4.15 Redundant GET VPN

Configure GET VPN between R2, R5 and R6.

R2 should act as primary KS.

Protect the ICMP traffic between GMs.

Use AES 192 and SHA-1 for both phases. Use pre-shared key “ipexpert” for authentication.

Rekey messages should be sent as multicast to 239.5.5.5.

Secure the re-key transmission.

Configure R4 as redundant KS.


Generally, syslog should be your primary troubleshooting tool when available:

R5#

*Nov 23 05:37:38.696: %CRYPTO-5-GM_REGSTER: Start registration to KS 8.9.50.2

for group GR1 using address 8.9.50.5

R5#

*Nov 23 05:38:18.700: %CRYPTO-5-GM_CONN_NEXT_SER: GM is connecting to next

key server from the list

R5#

*Nov 23 05:43:48.708: %GDOI-4-GM_RE_REGISTER: The IPSec SA created for group

GR1 may have expired/been cleared, or didn't go through. Re-register to KS.

From the output above you see that R5 cannot register to R2 which should be our primary KS. Check the reachability and if okay, move to verify R5 and R2:




R5#ping 8.9.50.2



!!!!!


R5#sh cry isa sa



8.9.50.2 8.9.50.5 MM_NO_STATE 0 ACTIVE

R5#sh cry gd

GROUP INFORMATION

Group Name : GR1

Group Identity : 1

Rekeys received : 0




8.9.50.4


Rekey Received(hh:mm:ss) : 01:29:55

Rekeys received

Cumulative : 0



TEK POLICY:

Serial0/1/0:

R2#sh cry gd ks



Group Name : GR1

Group Identity : 1

Group Members : 0


ACL Configured:

access-list 150



Local Priority : 15


Local KS Role : Secondary

First of all, note that R2 is not a primary KS. Other thing is that there are no group members registered. Go to R4 and fix KS role:




R4#sh cry gd ks



Group Name : GR1

Group Identity : 1

Group Members : 0


ACL Configured:

access-list 150



Local Priority : 16



R4(config)#cry gdoi gr GR1

R4(config-gdoi-group)#server local

R4(gdoi-local-server)#redundancy

R4(gdoi-coop-ks-config)#local priority 1

R4#clear cry gd

% The Key Server and Group Member will destroy created and downloaded

policies.

% All Group Members are required to re-register.

Are you sure you want to proceed ? [yes/no]: yes

R2#

Nov 23 17:11:12.600: %GDOI-5-COOP_KS_TRANS_TO_PRI: KS 8.9.50.2 in group GR1

transitioned to Primary (Previous Primary = NONE)

Now try to figure out why the members cannot register to R2. As you have seen before, R5 did not have the Phase I SA built to R2, so the registration did not even started.

R2#sh cry isa sa



8.9.50.2 8.9.50.5 MM_NO_STATE 0 ACTIVE (deleted)

8.9.50.2 8.9.50.4 GDOI_IDLE 1121 ACTIVE

R2#deb cry condition peer ipv4 8.9.50.5

R2#deb cry isa

R5#deb cry isa


R5#clear cry gd


policies.



R5#

*Nov 23 06:04:26.676: %GDOI-4-GM_RE_REGISTER: The IPSec SA created for group GR1 may

have expired/been cleared, or didn't go through. Re-register to KS.

*Nov 23 06:04:26.676: %CRYPTO-5-GM_REGSTER: Start registration to KS 8.9.50.2 for

group GR1 using address 8.9.50.5





*Nov 23 06:04:26.680: ISAKMP: Found a peer struct for 8.9.50.2, peer port 848

*Nov 23 06:04:26.680: ISAKMP: Locking peer struct 0x491BF754, refcount 1 for

isakmp_initiator



*Nov 23 06:04:26.680: ISAKMP:(0):Switching to SW IKE SA: sa is 4903FB2C, ce_id is

80000002

*Nov 23 06:04:26.680: ISAKMP:(0):insert sa successfully sa = 4903FB2C



R5#

R5#









(I) MM_NO_STATE


R5#

R5#

*Nov 23 06:04:36.680: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...


retransmit phase 1

*Nov 23 06:04:36.680: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE


(I) MM_NO_STATE


R5#



retransmit phase 1



(I) MM_NO_STATE


R2#


Nov 23 17:21:34.312: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

Nov 23 17:21:34.312: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM1



(R) MM_SA_SETUP


Nov 23 17:21:34.312: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

Nov 23 17:21:34.312: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2

As you can see, the ISAKMP policy from R2 is not received by R5. Because both the endpoints are connected via the FR cloud, it should be something on the devices themselves preventing the communication. Remember that ISAKMP/GODI runs over UDP 848 and with NAT-T it floats to UDP 4500.




R5#sh access-l


10 deny udp any any eq 848 (233 matches)



10 deny icmp any any

R5#sh ip access-lists interface s0/1/0

Extended IP access list 100 in

10 deny udp any any eq 848 (237 matches)



R5(config-if)#no ip access-group 100 in

R5#clear cry gd


policies.



R5#

R5#



R5#





What about R6?

R6#sh cry gd

GROUP INFORMATION

Group Name : GR1

Group Identity : 2

Rekeys received : 0




8.9.50.4


Rekey Received(hh:mm:ss) : 02:11:14

Rekeys received

Cumulative : 0



TEK POLICY:

Serial0/1/0:




R6(config)#crypto gdoi group GR1

R6(config-gdoi-group)#ide number 1

R6(config-gdoi-group)#







R6#ping 8.9.50.5



*Nov 23 17:50:29.231: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an

IPSEC packet. (ip) vrf/dest_addr= /8.9.50.6, src_addr= 8.9.50.5, prot= 1....


Almost. Verify the IPSec SAs:

R6#sh cry sess de | in 8.9.50.5|pkts


















R5 decapsulates IPSec traffic but responds in clear text. Look at the policy:

R5#sh cry gd gm acl

Group Name: GR1




ACL Configured Locally:

Map Name: MAP1

access-list 150 deny icmp any any


crypto map MAP1 15 gdoi

set group GR1

match address 150

crypto map MAP1




R5(config)#crypto map MAP1 15 gdoi

R5(config-crypto-map)#no match add 150

R6#ping 8.9.50.5



!!!!!












4.16 ASA WebVPN

ASA2 should allow for WebVPN connections on its outside interface port 443.

Create user “remote” with password “remote”; that user should authenticate to group WEBGROUP.

Remote users should be able to access R8‟s console after telnetting locally on port 2023.

Disable the ability to enter any HTTP/HTTPS URL on the portal page.


When you try to use PF to connect to R8, it does not work. You get blank screen and connection is torn down. Take a look at the requests and responses sent over the WebVPN session and try to connect again on port 2023 locally on Test PC:

ASA2(config)# deb webvpn request 100

INFO: debug webvpn request enabled at level 100.

ASA2(config)# deb webvpn response 100

INFO: debug webvpn response enabled at level 100.

ASA2(config)# REMOTE_STATE_HEADER

HTTP Request Headers:

Request Type: TCP

WebVPN Cookie:

'webvpn=3355576584@28672@1258154180@EC1872B03DEB51510F5A56D1C48072AF93282700'

IPADDR: '3355576584', INDEX: '28672', LOGIN: '1258154180'

http_webvpn_send_error(403 Forbidden)




ASA2(config)# sh vpn-sessiondb detail webvpn filter name remote

Session Type: WebVPN Detailed

Username : remote Index : 7

Public IP : 8.9.2.200

Protocol : Clientless

License : SSL VPN





Group Policy : WEBPOL Tunnel Group : WEBGROUP

Login Time : 23:16:20 UTC Fri Nov 13 2009





Clientless:

Tunnel ID : 7.1

Public IP : 8.9.2.200






Client Ver : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)


Filter Name : WEBACL

NAC:




Redirect URL :

ASA2(config)# sh run group-policy WEBPOL

group-policy WEBPOL internal

group-policy WEBPOL attributes

vpn-tunnel-protocol webvpn

webvpn

filter value WEBACL

port-forward enable PF

url-entry disable

ASA2(config)# sh access-list WEBACL

access-list WEBACL; 2 elements

access-list WEBACL line 1 webtype deny tcp any eq telnet (hitcnt=10)

access-list WEBACL line 2 webtype permit tcp any (hitcnt=0)

ASA2(config)# group-policy WEBPOL attributes

ASA2(config-group-webvpn)# no filter value WEBACL





4.17 ASA SSL VPN (AnyConnect)

Configure ASA2 to provide SSL client connections for remote users.

Create user “ssluser” with password “remote”; that user should be only able to successfully authenticate to group SSLGROUP.


ASA should only allow access to 192.168.8.0/24 via the tunnel.

Make sure you can ping R8 from the client‟s Test PC.

For SSL connection use the protocol that avoids latency and bandwidth problems.


After connecting via a browser the client download process does not start:

If you had a client already installed, you would see the following syslog message:

ASA2(config-group-policy)# %ASA-4-722050: Group <SSLPOL> User <ssluser> IP

<8.9.2.200> Session terminated: SVC not enabled for the user

%ASA-4-113019: Group = , Username = , IP = 0.0.0.0, Session disconnected.

Session Type: , Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason:

Unknown

This should give you a clear indication on what‟s going on - SVC is not enabled for users by default.

ASA2(config)# sh run group-policy SSLPOL

group-policy SSLPOL internal

group-policy SSLPOL attributes


split-tunnel-network-list value SSLSPLIT

address-pools value SSLPOOL

webvpn

svc dtls enable

svc ask none default svc

ASA2(config)# group-policy SSLPOL attributes

ASA2(config-group-policy)# vpn-tunnel-protocol svc

Connect and verify :




ASA2(config-group-policy)# sh vpn-sessiondb svc

Session Type: SVC

Username : ssluser Index : 12


Protocol : Clientless SSL-Tunnel DTLS-Tunnel

License : SSL VPN

Encryption : RC4 AES128 Hashing : SHA1


Group Policy : SSLPOL Tunnel Group : SSLGROUP

Login Time : 01:07:13 UTC Sat Nov 14 2009




Split Tunneling (not shown) and statistics on the client look good:





4.18 IOS Clientless SSL VPN

Configure R4 to provide WebVPN connections on s0/0/0 interface port 443.

HTTP connections should be redirected to HTTPS automatically.

Create user “ssluser” with password “remote”; that user should authenticate in domain IPEXPERT.

Remote users should be able to access HTTP on CAT2 through the URL link on the portal page.

Console access to CAT2 should also be available after telnetting locally on port 10023.


After trying SSL to the gateway the following message appears in the browser:

Check the IP reachability, run the debug and try to connect again:

R4#deb webvpn ver

WebVPN debugging is on

R4#

R4#




Still nothing. Try to telnet to the gateway on TCP 443:

It looks like we don‟t even reach the gateway over TCP 443:

R4#sh webvpn gateway

Gateway Name Admin Operation

------------ ----- ---------

SSLGW up up

R4#sh control-plane host open-ports | in 443 tcp *:443 *:0 TCP Listener LISTEN

tcp *:443 *:0 TCP Listener LISTEN








There is no ACLs on R2 and R4 applied (check). You could also look for PBR, MQC, Control Plane etc. but usually it is enough to verify the ACLs and then move into Layer 2. R2 Gi0/1 is also checked for filtering of the return traffic.




!





end

Cat2#sh run int f0/2 | begin Fast





end




No Port ACLs. Check if there are any VLAN ACLs configured. Fix it.

Cat3#sh vlan filter

VLAN Map VACL is filtering VLANs:

2

Cat3#sh vlan access-map VACL

Vlan access-map "VACL" 10

Match clauses:

ip address: 111

Action:

drop

Vlan access-map "VACL" 100

Match clauses:

Action:

Forward

Cat3#sh access-list 111


10 permit tcp any any eq 443

Cat3(config)#no vlan filter VACL vlan-list 2

Now you can connect, but there is no Port Forwarding application available. Check the context and group policy associated with it:

R4#sh webvpn context




------------ ------- ------------ ------- ---- --------


ANYCONNECT_CONTEXT SSLGW SSSL - up up

R4#sh webvpn context SSLCONTEXT

Admin Status: up

Operation Status: up

Error and Event Logging: Disabled

CSD Status: Disabled

Certificate authentication type: All attributes (like CRL) are verified

AAA Authentication List: SSLAUTH

AAA Authorizationtion List not configured

AAA Authentication Domain not configured

Default Group Policy: SSLPOL

Associated WebVPN Gateway: SSLGW

Domain Name: IPEXPERT

Maximum Users Allowed: 1000 (default)

NAT Address not configured

VRF Name not configured




R4#sh webvpn policy group SSLPOL context SSLCONTEXT

WV: group policy = SSLPOL ; context = SSLCONTEXT

url list name = "Cat2"



citrix disabled






rekey method =


The policy does not have PF configured/applied. Make necessary changes and also make sure everything is working:

R4#sh run | se SSLCONTEXT

webvpn context SSLCONTEXT


!

url-list "Cat2"

url-text "Cat2_HTTP" url-value "http://10.4.4.20"

!

!

port-forward "PF"

local-port 10023 remote-server "10.4.4.20" remote-port 23 description

"Telnet to CAT2"

!

policy group SSLPOL

url-list "Cat2"



gateway SSLGW domain IPEXPERT

inservice

R4(config)#webvpn context SSLCONTEXT

R4(config-webvpn-context)#policy group SSLPOL

R4(config-webvpn-group)#port-forward PF





4.19 IOS SSL VPN (AnyConnect)

Configure R4 to provide SSL client connections for remote users.

Create a separate context for domain “SSL” and make sure only AnyConnect clients are allowed to connect to it.

Portal page should contain a black heaading “IPEXPERT ANYCONNECT.”


Tunnel only traffic going to 10.4.4.0/24.

Assign the clients domain-name of “ipexpert.com” and DNS Server of 10.4.4.20.


From the previous task we know that now the server is reachable. Try to connect to the SSL domain:

Interesting. Check if the context is up and running:

R4#sh webvpn cont




------------ ------- ------------ ------- ---- --------


ANYCONNECT_CONTEXT SSLGW SSSL - up up

It seems that domain is misconfigured. Correct this and reconnect:

R4(config)#webvpn context ANYCONNECT_CONTEXT

R4(config-webvpn-context)#no gateway SSLGW domain SSSL

R4(config-webvpn-context)#gateway SSLGW domain SSL




Try to ping CAT2. Check Split Tunneling on the client:

Correct this, reconnect and try to ping again:




R4(config)#webvpn context ANYCONNECT_CONTEXT

R4(config-webvpn-context)# policy group ANYCONNECT_POL

R4(config-webvpn-group)#no svc split include 10.40.40.0 255.255.255.0

R4(config-webvpn-group)#svc split include 10.4.4.0 255.255.255.0

R4#sh webvpn policy group ANYCONNECT_POL context all

WEBVPN: group policy = ANYCONNECT_POL ; context = ANYCONNECT_CONTEXT



functions =

svc-required

citrix disabled

address pool name = "ANYPOOL"

default domain = "ipexpert.com"






rekey method =


split include = 10.4.4.0 255.255.255.0

DNS primary server = 10.4.4.20





4.20 VRF-Aware IPSec

Use IPSec to protect all traffic between Loopback 20 networks on R2 and R7.

Use AES 128 encryption, SHA-1 HMAC, DH group 5 and PSK “IPEXPERT” for Phase I.

Use the same encryption and authentication/integrity algorithms for Phase II and also make sure that any further session keys will not be derived based on previous ones.

You are allowed to configure two static routes in this task.


Start if checking If both interfaces are in VRF:

R7(config)#do sh ip vrf


VRF <not set> Lo20

R2#sh ip vrf


VRF <not set> Lo20

Before you start IPSec verification make sure you can reach R2. Don‟t use ICMP because ASA would block the replies:

R7#telnet 8.9.2.2


Password required, but none set


Try to initiate a tunnel pinging R2‟s Loopback 20 from R7‟s loopback:

R7#ping vrf VRF 192.168.20.2 so l20




....


R7#sh cry isa sa



8.9.50.5 10.7.7.7 QM_IDLE 1048 ACTIVE

10.7.7.7 8.9.50.6 QM_IDLE 1047 ACTIVE

It seems that ISAKMP exchange has not even been triggered. Check if the crypto map is applied:




R7#sh cry map interface f0/1


Peer = 8.9.2.2






PFS (Y/N): Y

DH group: group5

Transform sets={

SET20: { esp-aes esp-sha-hmac } ,

}


FastEthernet0/1

R2#sh run int l 20



!


ip vrf forwarding VRF

ip address 192.168.20.2 255.255.255.0

R7#sh run int l20



!


ip vrf forwarding VRF

ip address 192.168.70.7 255.255.255.0

So, the crypto configuration is applied on F0/1 and proxy ACL matches what we expected. Check the routing configuration for 192.168.20.0/24:

R7#sh ip route vrf VRF

Routing Table: VRF










R7#sh run | in route vrf

ip route vrf VRF 192.168.20.0 255.255.255.0 10.7.7.10




R7(config)#no ip route vrf VRF 192.168.20.0 255.255.255.0 10.7.7.10

R7(config)#ip route vrf VRF 192.168.20.0 255.255.255.0 10.7.7.10 global

R7(config)#do sh ip route vrf VRF

Routing Table: VRF









S 192.168.20.0/24 [1/0] via 10.7.7.10


Turn on debugs on both ends and ping again:

R2#deb cry isa

R2#deb cry condition peer ip 8.9.2.7

R7#deb cry isa

R7#ping vrf VRF 192.168.20.2 so l20 rep 2




..


Although the crypto map is applied and we have correct proxy ACL set, interesting traffic does not trigger the ISAKMP exchange. Take a look if actual SAs have been pre-build based on the SPD content:

R7#sh cry ipse sa map MAP1

PFS (Y/N): N, DH group: none

interface: FastEthernet0/1

Crypto map tag: MAP1, local addr 10.7.7.7

protected vrf: (none)

local ident (addr/mask/prot/port): (192.168.70.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)

current_peer 8.9.2.2 port 500

PERMIT, flags={origin_is_acl,}



#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 10.7.7.7, remote crypto endpt.: 8.9.2.2

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1

current outbound spi: 0x0(0)




So they were but not for the VRF. Remember that ISAKMP Profile is used to specify which VRF the SAs belong to:

R7#sh cry isa prof tag ISA_PROF


Ref Count = 2


ip-address 8.9.2.2 255.255.255.255


keyring(s): KRING



R7(conf-isa-prof)#vrf VRF

R7#sh cry isa profile tag ISA_PROF


Ref Count = 2


ip-address 8.9.2.2 255.255.255.255


vrf: VRF

keyring(s): KRING


R7#sh cry ipse sa map MAP1

PFS (Y/N): N, DH group: none

interface: FastEthernet0/1

Crypto map tag: MAP1, local addr 10.7.7.7

protected vrf: VRF

local ident (addr/mask/prot/port): (192.168.70.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)

current_peer 8.9.2.2 port 500

PERMIT, flags={origin_is_acl,}



#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 10.7.7.7, remote crypto endpt.: 8.9.2.2

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1

current outbound spi: 0x0(0)

inbound esp sas:








*Nov 25 20:37:58.062: ISAKMP:(0): SA request profile is ISA_PROF


*Nov 25 20:37:58.062: ISAKMP: New peer created peer = 0x47C97534 peer_handle =

0x8000001A

*Nov 25 20:37:58.062: ISAKMP: Locking peer struct 0x47C97534, refcount 1 for

isakmp_initiator



*Nov 25 20:37:58.062: ISAKMP:(0):insert sa successfully sa = 47C96570


*Nov 25 20:37:58.062: ISAKMP:(0):Found ADDRESS key in keyring KRING









(I) MM_NO_STATE




*Nov 25 20:37:58.070: ISAKMP:(0):Notify has no hash. Rejected.

*Nov 25 20:37:58.070: ISAKMP (0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY:

state = IKE_I_MM1

*Nov 25 20:37:58.070: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY

*Nov 25 20:37:58.070: ISAKMP:(0):Old State = IKE_I_MM1 New .State = IKE_I_MM1

*Nov 25 20:37:58.070: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode

failed with peer at 8.9.2.2.


R7#



retransmit phase 1


R2#


Nov 25 20:33:22.410: ISAKMP:(0):insert sa successfully sa = 7108A6D8

Nov 25 20:33:22.410: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Nov 25 20:33:22.410: ISAKMP:(0):Old State = IKE_READY New State = IKE_R_MM1














Nov 25 20:33:22.410: ISAKMP:

R2#(0): processing vendor id payload



Nov 25 20:33:22.410: ISAKMP:(0):No pre-shared key with 8.9.2.7!









Nov 25 20:33:22.410: ISAKMP:(0):Preshared authentication offered but does not match

policy!


So, we cannot proceed with the negotiation because there was no PSK found on R2. Investigate and correct.

R2#sh cry isa key


default 8.9.50.5 ipexpert

8.9.50.6 ipexpert

8.9.50.4 ipexpert

KRING 8.9.2.7 IPEXPERT

R2#sh run | se keyring KRING

crypto keyring KRING vrf VRF


keyring KRING

R2#sh cry map int Gi0/1


Peer = 8.9.2.7






PFS (Y/N): Y

DH group: group5

Transform sets={


}


GigabitEthernet0/1




R2#sh cry isa prof tag ISA_PROF


Ref Count = 2


ip-address 10.7.7.7 255.255.255.255


vrf: VRF

keyring(s): KRING



R2(conf-isa-prof)#no keyring KRING

R2(config)#no cry keyring KRING

R2(config)#crypto keyring KRING

R2(conf-keyring)#pre-shared-key address 8.9.2.7 key IPEXPERT


R2(conf-isa-prof)#keyring KRING

Test again and observe the debugs.


R7#




*Nov 25 21:02:48.382: ISAKMP:(0): SA request profile is ISA_PROF


*Nov 25 21:02:48.386: ISAKMP: New peer created peer = 0x492A75A8 peer_handle =

0x80000114

*Nov 25 21:02:48.386: ISAKMP: Locking peer struct 0x492A75A8, refcount 1 for

isakmp_initiator


-- Output omitted –-

*Nov 25 21:02:48.454: ISAKMP:(1055): processing HASH payload. message ID = 0


authenticated

*Nov 25 21:02:48.454: ISAKMP:(1055):SA has been authenticated with 8.9.2.2

*Nov 25 21:02:48.454: ISAKMP:(1055):Setting UDP ENC peer struct 0x48CA1CA8 sa=

0x495E53D4

*Nov 25 21:02:48.454: ISAKMP: Trying to insert a peer 10.7.7.7/8.9.2.2/4500/, and

found existing one 47C97534 to reuse, free 492A75A8

*Nov 25 21:02:48.454: ISAKMP: Unlocking peer struct 0x492A75A8 Reuse existing peer,

count 0

*Nov 25 21:02:48.454: ISAKMP: Deleting peer node by peer_reap for 8.9.2.2: 492A75A8

*Nov 25 21:02:48.458: ISAKMP: Locking peer struct 0x47C97534, refcount 6 for Reuse

existing peer




4500 Global (I) QM_IDLE




*Nov 25 21:02:48.458: ISAKMP: set new node -1006205262 to QM_IDLE

*Nov 25 21:02:48.458: ISAKMP:(1054): processing HASH payload. message ID = -1006205262


*Nov 25 21:02:48.458: ISAKMP:(1054):Processing delete with reason payload

*Nov 25 21:02:48.458: ISAKMP:(1054):delete doi = 1

*Nov 25 21:02:48.458: ISAKMP:(1054):delete protocol id = 1

*Nov 25 21:02:48.458: ISAKMP:(1054):delete spi_size = 16

*Nov 25 21:02:48.458: ISAKMP:(1054):delete num spis = 1

*Nov 25 21:02:48.458: ISAKMP:(1054):delete_reason = 11

*Nov 25 21:02:48.458: ISAKMP:(1054): processing DELETE_WITH_REASON payload, message ID

= -1006205262, reason: Unknown delete reason!

R2#


Global (R) MM_NO_STATE


Nov 25 21:01:26.281: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert

sa = 7108A6D8

Nov 25 21:01:26.281: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Nov 25 21:01:26.281: ISAKMP:(0):Old State = IKE_READY New State = IKE_R_MM1

Nov 25 21:01:26.281: ISAKMP:(0): processing SA payload. m

R2#essage ID = 0


-- Output omitted –-

Nov 25 21:01:56.349: ISAKMP: authenticator is HMAC-SHA

Nov 25 21:01:56.349: ISAKMP: key length is 128

Nov 25 21:01:56.349: ISAKMP: group is 5

Nov 25 21:01:56.349: ISAKMP:(1011):atts are acceptable.

Nov 25 21:01:56.349: ISAKMP:(1011): IPSec policy invalidated proposal with error 32


remote 8.9.2.7)


Nov 25 21:01:56.349: ISAKMP:(1011):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

spi 1767168264, message ID = 719748755


4500 (R) QM_IDLE


Nov 25 21:01:56.349: ISAKMP:(1011):purging node 719748755

Nov 25 21:01:56.349: ISAKMP:(1011):deleting node 1226880993 error TRUE reason "QM

rejected"

Something is wrong with Phase II. Turn on IPSec debug on R2:

R2#deb cry ipse

Crypto IPSEC debugging is on

R2#

Nov 25 21:05:59.709: IPSEC(key_engine): got a queue event with 1 KMI message(s)

Nov 25 21:05:59.709: IPSEC(key_engine): got a queue event with 1 KMI message(s)

Nov 25 21:05:59.721: IPSEC(validate_proposal_request): proposal part #1

Nov 25 21:05:59.721: IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 8.9.2.2, remote= 8.9.2.7,

local_proxy= 192.168.20.0/255.255.255.0/0/0 (type=4),

remote_proxy= 192.168.70.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= NONE (Tunnel-UDP),

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0

R2#

Nov 25 21:05:59.721: IPSEC(ipsec_process_proposal): proxy identities not supported




Proxy identities refer to the proxy ACL.

R2#sh cry map int Gi0/1


Peer = 8.9.2.7






PFS (Y/N): Y

DH group: group5

Transform sets={


}


GigabitEthernet0/1

R2(config)#ip access-list ext 120

R2(config-ext-nacl)#permit ip 192.168.20.0 0.0.0.255 192.168.70.0 0.0.0.255






.!!!


R7#sh cry sess ivrf VRF de






Profile: ISA_PROF

Uptime: 00:00:37


Peer: 8.9.2.2 port 4500 fvrf: (none) ivrf: VRF

Phase1_id: 8.9.2.2

Desc: (none)



IKE SA: local 10.7.7.7/4500 remote 8.9.2.2/4500 Inactive

Capabilities:N connid:1064 lifetime:0









4.21 L2TP

Configure ASA2 for L2TP.

Create a user “l2tp” with password “ipexpert.”

Use MS-CHAP version 2 for authentication.

IP address assigned to the users should belong to 10.250.250.0/24 network.

Use 3DES encryption and SHA-1 HMAC for both phases. Set PSK to “CISCO.”

L2TP Hellos should be sent every 10 seconds.


If you try to connect you get the following message on Test PC and syslog messages on ASA2:

ASA2(config)# %ASA-4-713903: Group = DefaultRAGroup, IP = 8.9.2.200, Freeing

previously allocated memory for authorization-dn-attributes

%ASA-3-713122: IP = 8.9.2.200, Keep-alives configured on but peer does not support

keep-alives (type = None)

%ASA-3-713902: Group = DefaultRAGroup, IP = 8.9.2.200, QM FSM error (P2 struct

&0xd5469fb0, mess id 0xc0bb23e3)!

%ASA-3-713902: Group = DefaultRAGroup, IP = 8.9.2.200, Removing peer from correlator


%ASA-4-113019: Group = DefaultRAGroup, Username = , IP = 8.9.2.200, Session

disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0,

Reason: Phase 2 Mismatch

%ASA-4-713903: Group = DefaultRAGroup, IP = 8.9.2.200, Freeing previously allocated


%ASA-3-713122: IP = 8.9.2.200, Keep-alives configured on but peer does not support

keep-alives (type = None)


&0xd5469fb0, mess id 0xee4110d4)!






Enable ISAKMP/IPSec debugs in order to get more detailed information. L2TP debugs will not help us at this stage.

ASA2(config)# deb cry isa 7

ASA2(config)# deb cry ipse 7

ASA2(config)# Nov 16 13:10:05 [IKEv1]: IP = 8.9.2.200, IKE_DECODE RECEIVED

Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) +

VENDOR (13) + VENDOR (13) + NONE (0) total length : 312





Nov 16 13:10:05 [IKEv1]: IP = 8.9.2.200, Connection landed on tunnel_group

DefaultRAGroup

Nov 16 13:10:05 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 8.9.2.200, Generating keys

for Responder...

Nov 16 13:10:05 [IKEv1]: IP = 8.9.2.200, IKE_DECODE SENDING Message (msgid=0) with

payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) +

VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 304

%ASA-4-713903: Group = DefaultRAGroup, IP = 8.9.2.200, Freeing previously allocated


Nov 16 13:10:05 [IKEv1]%ASA-3-713122: IP = 8.9.2.200, Keep-alives configured on but

peer does not support keep-alives (type = None)

: IP = 8.9.2.200, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + ID (5) +

HASH (8) + NONE (0) total length : 64

Nov 16 13:10:05 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 8.9.2.200, processing ID

payload

Nov 16 13:10:05 [IKEv1 DEBUG]: Group = DefaultRAGroup, IP = 8.9.2.200, processing hash

payload


&0xd5469fb0, mess id 0x10d84358)!






Nov 16 13:10:05 [IKEv1]: Group = DefaultRAGroup, IP = 8.9.2.200, L2TP/IPSec session

detected.


The only thing we know is that something‟s wrong with Phase II. Normally you could also configure your windows machine for logging but it is beyond the scope of CCIE lab exam. Let‟s use the information we already have. Phase II parameters are grouped by a crypto map, remember that for L2TP we are using a dynamic map.

ASA2(config)# sh run crypto dynamic-map

crypto dynamic-map DYNMAP 2 set transform-set L2SET

crypto dynamic-map DYNMAP 2 set security-association lifetime seconds 28800

crypto dynamic-map DYNMAP 2 set security-association lifetime kilobytes

4608000

ASA2(config)# sh run crypto ipsec

crypto ipsec transform-set L2SET esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

Cisco‟s implementation of L2TP/IPSec uses transport mode only. Reconfigure the transform set appropriately and connect again.

ASA2(config)# crypto ipsec transform-set L2SET mode transport

Although we still cannot connect, the information displayed on the Test PC is much more helpful then before:




ASA2(config)# sh run username l2tp

username l2tp password 8S.4974OWzlm0I4Q encrypted

Password for the user should be MSCHAP-encrypted because the encrypted passwords are compared during authentication.

ASA2(config)# username l2tp password ipexpert mschap

ASA2(config)# sh run username l2tp

username l2tp password ueTyKRLzow/kxPQyM5of8g== nt-encrypted

ASA2(config)# sh vpn-sessiondb remote filter protocol l2tpOverIpSec

Session Type: IPsec

Username : l2tp Index : 43


Protocol : IKE IPsec L2TPOverIPsec

License : IPsec



Group Policy : DfltGrpPolicy Tunnel Group : DefaultRAGroup

Login Time : 13:39:08 UTC Mon Nov 16 2009















ipexpert security volume 1 dsg v5.0 labs 1 4 decrypted

Documents

ccie lab exam

ccie security lab exam

cisco ccie security

ipexpert products

lab exam volume

ipexpert training advisor

lab exam feedbackdo

cisco ccietm security