Iewb Sc Vol i v5.wewew.3.VPN.005

8/11/2019 Iewb Sc Vol i v5.wewew.3.VPN.005

1/333

Accessed by rohitparda [email protected] from 115.240.81.217 at 20: 26:22 Nov 23,2009

CCIE Security Lab Workbook Volume I Version 5.0 VPN

Copyright 2009 Internetwork Expert www.INE.comi

Copyright Information

Copyright 2009 Internetwork Expert, Inc. All rights reserved.

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

Cisco, Cisco Systems, CCIE, and Cisco Certified Internetwork Expert, are registered trademarks ofCisco Systems, Inc. and/or its affiliates in the U.S. and certain countries.

All other products and company names are the trademarks, registered trademarks, and service marks of therespective owners. Throughout this manual, Internetwork Expert, Inc. has used its best efforts to distinguishproprietary trademarks from descriptive names by following the capitalization styles used by themanufacturer.


2/333



Copyright 2009 Internetwork Expert www.INE.comii

Disclaimer

The following publication, CCIE Security Lab Workbook Volume I Version 5.0, is designed to assistcandidates in the preparation for Cisco Systems CCIE Security Lab Exam. While every effort has beenmade to ensure that all material is as complete and accurate as possible, the enclosed material is presentedon an as is basis. Neither the authors nor Internetwork Expert, Inc. assume any liability or responsibility to

any person or entity with respect to loss or damages incurred from the information contained in thisworkbook.

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


3/333



Copyright 2009 Internetwork Expert www.INE.comiii

Table of ContentsVPN .................................................................................................... 1

2.1 LAN-to-LAN VPN between IOS and ASA ........................................ 2

2.2

IPsec and NAT Interaction in ASA Firewall ..................................... 2

2.3 Authentication using Digital Signatures ........................................... 2 2.4 ASA Tunnel Group Names .............................................................. 2 2.5 ASA Certificate Mapping Rules ....................................................... 2 2.6 Filtering traffic inside LAN-to-LAN tunnels....................................... 2 2.7 LAN-to-LAN tunnel between IOS Routers ....................................... 4 2.8 IOS IPsec NAT Traversal ................................................................ 4 2.9 IOS IKE Aggressive Mode............................................................... 4 2.10 VPN between Overlapping Subnets ................................................ 4 2.11 IOS VPN with Digital Signatures Authentication.............................. 4 2.12 IOS Certificate Access Lists ............................................................ 4

2.13 Virtual Tunnel Interfaces.................................................................. 5 2.14 GRE over IPsec............................................................................... 5 2.15 DMVPN ........................................................................................... 6 2.16 IOS ezVPN Server........................................................................... 7 2.17 IOS ezVPN Server using VTI .......................................................... 7 2.18 IOS ezVPN Server: Group Lock ...................................................... 8 2.19 IOS ezVPN Server: RADIUS Authorization ..................................... 8 2.20 IOS ezVPN Server: Per User AAA download with PKI.................... 8 2.21 IOS ezVPN Remote: Client Mode ................................................... 8 2.22 IOS ezVPN Remote: NEM............................................................... 8 2.23 IOS ezVPN Remote: VTI ................................................................. 8

2.24 IOS ezVPN Remote: Digital Signatures........................................... 9 2.25 ASA ezVPN Server.......................................................................... 9 2.26 ASA ezVPN Server: DHCP Address Allocation............................... 9 2.27 ASA ezVPN Server: RADIUS Authorization .................................... 9 2.28 ASA ezVPN Server: Per User AAA download with PKI ................. 10 2.29 ASA Clientless SSL VPN............................................................... 10 2.30 ASA Clientless SSL VPN: Port Forwarding ................................... 10 2.31 ASA Clientless SSL VPN: Smart Tunnel ....................................... 10 2.32 ASA SSL VPN ............................................................................... 11 2.33 IOS SSL VPN ................................................................................ 12 2.34 IOS SSL VPN RADIUS Authorization............................................ 12

2.35 IOS WebVPN (Clientless SSL VPN).............................................. 12 2.36 IOS WebVPN Port Forwarding ...................................................... 12 2.37 GET VPN....................................................................................... 14 2.38 GET VPN COOP KS ..................................................................... 14

VPN Solutions .................................................................................. 15 2.1 LAN-to-LAN VPN between IOS and ASA ...................................... 15 2.2 IPsec and NAT Interaction in ASA Firewall ................................... 39


4/333



Copyright 2009 Internetwork Expert www.INE.comiv

2.3 Authentication using Digital Signatures ......................................... 42 2.4 ASA tunnel groups based on hostnames ...................................... 61 2.5 ASA Certificate Mapping Rules ..................................................... 65 2.6 Filtering traffic inside LAN-to-LAN tunnels..................................... 69 2.7 LAN-to-LAN tunnel between IOS Routers ..................................... 73

2.8 IOS IPsec NAT Traversal .............................................................. 76 2.9 IOS IKE Aggressive Mode ............................................................. 82 2.10 VPN between Overlapping Subnets .............................................. 89 2.11 IOS VPN with Digital Signatures Authentication............................ 92 2.12 IOS Certificate Access Lists .......................................................... 97 2.13 Virtual Tunnel Interfaces.............................................................. 101 2.14 GRE over IPsec........................................................................... 105 2.15 DMVPN ....................................................................................... 110 2.16 IOS ezVPN Server....................................................................... 121 2.17 IOS ezVPN Server using VTI ...................................................... 137 2.18 IOS ezVPN Server: Group Lock .................................................. 143

2.19 IOS ezVPN Server: RADIUS Authorization ................................. 144 2.20 IOS ezVPN Server: Per User AAA download with PKI................ 165 2.21 IOS ezVPN Remote: Client Mode ............................................... 181 2.22 IOS ezVPN Remote: NEM........................................................... 195 2.23 IOS ezVPN Remote: VTI ............................................................. 201 2.24 IOS ezVPN Remote: Digital Signatures....................................... 205 2.25 ASA ezVPN Server...................................................................... 212 2.26 ASA ezVPN Server: DHCP Address Allocation........................... 225 2.27 ASA ezVPN Server: RADIUS Authorization ................................ 229 2.28 ASA ezVPN Server: Per User AAA download with PKI ............... 248 2.29 ASA Clientless SSL VPN............................................................. 268

2.30 ASA Clientless SSL VPN: Port Forwarding ................................. 278 2.31 ASA Clientless SSL VPN: Smart Tunnel ..................................... 283 2.32 ASA SSL VPN ............................................................................. 285 2.33 IOS AnyConnect VPN ................................................................. 289 2.34 IOS SSL VPN RADIUS Authorization.......................................... 296 2.35 IOS WebVPN (Clientless SSL VPN)............................................ 303 2.36 IOS WebVPN Port Forwarding .................................................... 308 2.37 GET VPN..................................................................................... 311 2.38 GET VPN COOP KS ................................................................... 321


5/333



Copyright 2009 Internetwork Expert www.INE.com1

VPN

Note

Load the IOS and ASA VPN files to initialize your rack. Use the following diagramas your reference when working with the tasks below.


6/333




2.1 LAN-to-LAN VPN between IOS and ASA Configure a LAN-to-LAN IPsec tunnel between ASA1 and R3 using the

following information:o Phase 1 settings:

Use 3DES encryption. Use MD5 hash. Use the default DH group in the ASA. Use Pre-Shared keys authentication.

o Use 3DES/MD5 for traffic encryption and integrity validationrespectively.

Only protect traffic between VLAN23 and VLAN121 subnets.

2.2 IPsec and NAT Interaction in ASA Firewall Enable NAT in the ASA firewall and translate all inside addresses using

the IP address of the outside interface. Ensure the VPN traffic is not affected by this configuration.

2.3 Authentication using Digital Signatures Reconfigure the L2L tunnel between ASA1 and R3 to use digital

certificates for ISAKMP authentication. Use the following URL for CA enrollment:

http://10.0.0.100:80/certsrv/mscep/mscep.dll and use the domain nameINE.com for certificate DNs

2.4 ASA Tunnel Group Names Change the ASA firewall L2L VPN configuration to match the hostname

presented by R3.

2.5 ASA Certi ficate Mapping Rules Create a new L2L tunnel-group named INETUNNEL. Configure so that the VPN connection from R3 lands on this group, based

on the domain name INE.com.

2.6 Filtering traffic inside LAN-to-LAN tunnels Configure the ASA firewall so that telnet traffic is prohibited across the L2L

tunnel. All other connections should be permitted. Do not modify the interface access-list to accomplish this.


7/333




Note

At this point, erase running configurations on all devices in the racks. Load the ASA Access Control initial configurations. Refer to the following diagram whenworking with the scenarios below.

AAA/CAServer

DMZ

.100

136.X.122.0/24 VLAN122

136.X.121.0/24 VLAN121

Fa0/0

Fa0/0

10.0.0.0/24 VLAN120

RIPv2

R2

R1

OutsideInside

ASA1


8/333




2.7 LAN-to-LAN tunnel between IOS Routers Configure an IPsec tunnel between R1 and R2 to protect traffic between

the respective Loopback0 subnets. Use pre-shared key value of CISCO for authentication and 3DES/MD5 as

cipher/hash for both IPsec phases. Only permit the ICMP traffic across the tunnel. Apply this configuration to

R1.

2.8 IOS IPsec NAT Traversal Configure the ASA to translate all inside addresses using the outside and

DMZ interfaces for PAT. Ensure the IPsec tunnel between R1 and R2 is still operational. Refresh NAT state every 10 seconds of no traffic activity.

2.9 IOS IKE Aggressive Mode Modify the IPsec configuration in R1 and R2 so that the ISAKMP

authentication keys do not depend on the endpoint IP addresses.

2.10 VPN between Overlapping Subnets Create additional Loopback interfaces in R1 and R2 with the same subnet

12.12.12.0/24. Modify VPN configuration to provide connectivity between the overlapping

subnets. You are allowed to use static routes and NAT to accomplish this.

2.11 IOS VPN with Digital Signatures Authentication Reconfigure the L2L tunnel between R1 and R2 to use digital certificates

for ISAKMP authentication. Use the following URL for CA enrollment:

http://10.0.0.100:80/certsrv/mscep/mscep.dll and use the domain nameINE.com for certificate DNs.

2.12 IOS Certifi cate Access Lists Configure CA trustpoints in R1 and R2 to accept only the certificates

issued by authorities in the US and issued to hosts with the domain-nameINE.com.


9/333




2.13 Virtual Tunnel Interfaces Remove the previous NAT configuration in the ASA firewall. Reconfigure the LAN-to-LAN tunnel between R1 and R2 to be established

without using any crypto maps.

Ensure you can ping the translated addresseses for respective Loopback1interface across the VPN tunnel.

2.14 GRE over IPsec Replace VTI with the GRE tunnel and but do not use IPSec profiles for

traffic encryption. Replace the static routes with dynamic EIGRP routing.


10/333




2.15 DMVPN Load the DMVPN Initial configuration prior to starting with this task. Using the diagram below, configure DMVPN cloud protecting traffic

between Loopback 1 interface of R1, R2 and R3

RIPv2

2 0 1

1 0 2

1 0 3

3 0 1 136.X.0.0/24

Lo0: 150.X.2.2/24Lo1: 192.168.2.2/24

Lo0: 150.X.3.3/24Lo1: 192.168.3.3/24

Lo0: 150.X.1.1/24Lo1: 192.168.1.1/24

S0/0 S1/0

S0/0

R1

R2 R3

2 0 3 3 0 2

Use 3DES and MD5 as cipher/hash for traffic encryption and authenticate

endpoints using pre-shared keys. Use EIGRP as the VPN routing protocol.


11/333




Note

Clear all device configurations and load the Remote Access VPN InitialConfiguration files. You the following diagram as you reference when workingthrough the scenarios below.

S0/1

S1/3

Fa0/0 Fa0/1

Fa0/0.121

Inside

Outside

136.X.23.0/24136.X.121.0/24 VLAN121

136.X.123.0/24 VLAN123

1 3 6

. X . 1

0 0

. 0 / 2 4 V L A N 1 0 0

.200

AAA/CAServer

10.0.0.0/24 VLAN200

Fa0/0

RIPv2

Lo0: 150.X.1.1/24

Fa0/0.11

1 3 6 . X

. 1 1

. 0 / 2 4 V L A N

1 1

ASA1

Test PC

R1

R2

R3

2.16 IOS ezVPN Server Configure R3 as Easy VPN server per the following requirements:

o Use 3DES/MD5 as cipher/hash for Both IPSec Phase1/2.o Authenticate remote users identified by group name EZVPN using

the password value of CISCO.o Use the address pool 20.0.0.1-20.0.0.254 for remote userso Enable Xauth against the local user database and create new user

named CISCO with the password of CISCO1234 for this.o Only encrypt users traffic destined to the subnet 136.X.100.0/24

Configure the Test PC to verify your configuration.

2.17 IOS ezVPN Server us ing VTI Modify the previous task configuration to use Virtual Tunnel Interfaces for

ezVPN.


12/333




2.18 IOS ezVPN Server: Group Lock Configure R3 so that user CISCO is only allowed to log into group EZVPN.

2.19 IOS ezVPN Server: RADIUS Author ization Reconfigure ezVPN server in R3 for RADIUS authentication using the

AAA server at 10.0.0.100. Xauth should be performed against the RADIUS database and ezVPN

attributes should be authorized using the RADIUS server. Ensure the user CISCO cannot log into any other ezVPN group but dont

use the Group Lock feature to accomplish this.

2.20 IOS ezVPN Server: Per User AAA download with PKI Configure R3 to authenticate remote users using digital signatures. Enroll the Test PC with the CA installed on the AAA server.

Using the CN field in the Test PC certificate, create a separate RADIUSprofile for this user. The user should have a custom split-tunnel access-list allowing access to

40.0.0.0/24 and 20.0.0.0/24 subnets.

2.21 IOS ezVPN Remote: Client Mode Revert to local authentication and authorization for ezVPN in R3. Configure R1 as ezVPN Remote client to R3 using ezVPN Client Mode. Use R1s VLAN11 interface for the inside network. Make sure that only traffic to the IP address 10.0.0.100 brings the ezVPN

tunnel up. The users should be able to enter the Xuath credentials by starting anHTTP session across the client router.

2.22 IOS ezVPN Remote: NEM Modify the above task solution to implement Network Extension Mode with

R1 as ezVPN Remote client. Ensure R1 still requests an IP address from the server for troubleshooting.

2.23 IOS ezVPN Remote: VTI Reconfigure ezVPN in R1 and R3 to ensure that R3 may learn dynamic

VPN routes from R1 using EIGRP. Create new Loopback100 interface in R1 with the subnet 150.1.100.0/24

and make sure the traffic from this subnet to 10.0.0.0/24 is encrypted.


13/333




2.24 IOS ezVPN Remote: Digital Signatures Configure R1 and R3 to use digital signatures for authentication. Any host identifying it using the hostname in domain INE.com should be

mapped to ezVPN group EZVPN in R3.

2.25 ASA ezVPN Server Configure the ASA firewall to accept remote VPN connection from Cisco

Easy VPN Clients using group ID EZVPN Use 3DES/MD5 as the cipher/hash for IPSec Phase1/Phase2. Use address pool 20.0.0.0/24 to allocate IP addresses for remote clients

and push the DNS server IP address of 10.0.0.100 to the clients. Allow for split tunneling to network 136.X.121.0/24. Remote user should be authenticated using the name CISCO along with

the password CISCO1234. Ensure that this user is only allowed to login under the group EZVPN.

2.26 ASA ezVPN Server: DHCP Address Allocation Replace the local address pool allocation with DHCP-based addressing in

the ASA firewall. Configure R1 as a DHCP server to accomplish this task.

2.27 ASA ezVPN Server: RADIUS Authorization Create two group-policies in the RADIUS server named EZVPN_GROUP

and EZVPN_USER. The former policy should be associated with the EZVPN tunnel group and

specify the settings previously configured under the local group-policyEZVPN.

The latter policy must specify the split-tunnel list allowing access to subnet150.X.1.0/24 and lock user in the tunnel-group EZVPN.

Create a user named XAUTH_USER in the RADIUS server authenticatedusing the password CISCO1234. The RADIUS server should assign an IPaddress 20.0.0.100 to this user and associate it with the EZVPN_USERgroup policy.


14/333




2.28 ASA ezVPN Server: Per User AAA download with PKI Disable the use of Xauth in the previous scenario and switch to

authentication based on digital signatures. Ensure that per-user policy EZVPN_USER is downloaded from the AAA

server based on CN attribute of DN in the clients certificate. Use the OU value of Security for the client certificate and ensure it maps

to the connection profile EZVPN Use any CN of your choice, but ensure this user is assigned the IP

address 20.0.0.100. Additionally, ensure user is only allowed to login during weekdays from

9am to 6pm.

2.29 ASA Clientless SSL VPN Configure the ASA firewall to permit WebVPN connections on the outside

interface using the port number 443 Ensure the users may still access the ASDM application on the port 4043. Create an URL-List entry named Cisco pointing to the URL

http://www.cisco.com. Filter WebVPN connections and only allow the users to connect on the

port 80 to site in .com domain Configure R1 as a DNS server and make the firewall use it for WebVPN Create a DNS entry in R1 for www.cisco.com resolving to R1s IP address

for testing purposes. Remote users should authenticate using the name WEBVPN and

password CISCO1234 locally. Ensure this user is only allowed to use the WebVPN group.

2.30 ASA Clientless SSL VPN: Port Forwarding Configure WebVPN settings so that a user on the remote PC connecting

to the local port 20023 is redirected to R1s port 23. The applet should be automatically downloaded upon users login. Define a custom name for the downloaded applet.

2.31 ASA Clientless SSL VPN: Smart Tunnel

Modify the previous configuration so that the users no longer need port-forwarding to access any host on the private network via telnet. Ensure the feature permits the command telnet.exe to be transparently

proxied across the ASA firewall.


15/333




2.32 ASA SSL VPN Configure a new group named SSLVPN in the ASA firewall. A user named SSLVPN with the password of CISCO1234 should be

allowed to log into this group when connecting to the ASA via HTTPS. As soon as user logs in, Anyconnect VPN software should be pushed

back to the users PC. Allocate the connecting user an IP address from the pool 20.0.0.0/24. Make sure the user is only allowed to reach the subnet 136.X.11.0/24

under the tunnel protection. Enable the protocol that compensates the negative effect of the TCP

protocol. Make sure the amount of information sent over the VPN link is reduced to

the minimum.

Note

Load SSL VPN initial configuration prior to processing with the following tasks.


16/333




2.33 IOS SSL VPN Configure R6 as AnyConnect VPN server. The users are supposed to connect using the URL

http://150.X.6.6/SSLVPN .

Allocate the IP addresses using the local pool 20.0.0.0/24 and make surethe users are only tunneled to the subnet 6.6.6.0/24. Create a new Loopback interface to emulate this network. Authenticate the users against the local database and create a new user

named SSLUSER in the local database. Make sure this user is not allowed to log under any other VPN context.

2.34 IOS SSL VPN RADIUS Author ization Modify the previous task configuration so that all configuration settings for

use SSLUSER are pulled from the RADIUS server. This includes the address pool, split-tunnel networks and SVC settings.

2.35 IOS WebVPN (Clientless SSL VPN) Configure R6 to act as a WebVPN proxy for clientless SSL VPN clients. The users should be accessing the WebVPN services using the URL

http://150.X.6.6/WEBVPN . Authenticate the remote users against the local database populated with

the user WEBVPN and having the password of CISCO.

Filter WebVPN connections and only allow the users to connect on theport 80 to any web-site during weekdays (Mon-Fri 9:00am-6:00pm). Pre-configure the following two URLs in the list named Important Links

o http://www.cisco.com o http://www.google.com

Use the local router as DNS server and make sure these hostnamesresolve to the IP 10.0.0.100.

2.36 IOS WebVPN Port Forwarding

Configure R6 so that once the client logs in, it may start the thin client. The thin client should establish mapping of the local port 2080 to port 80

at 10.0.0.100.


17/333




Note

Load the GET VPN initial configuration prior to starting the following labs. Use

the following diagram as your reference.

R3 R4

R1 R2

136.X.0.0/24

Fa0/0 Fa0/0

S0/0 S0/0

S1/0 S0/0

302

203104

401402

204103

301

RIPv2


18/333




2.37 GET VPN Configure GET VPN cloud between R1, R3 and R4. Protect multicast

exchange sourced off the Loopback0 subnets towards the group

239.1.1.1. R1 should be the key server for R3 and R4. Use 3DES/MD5 encryption for

both IPSec phases and use pre-shared keys for authentication of GMswith the KS.

2.38 GET VPN COOP KS Add R2 as a redundant GDOI KS to R1. Configure R3 use R1, R2 as the Key Servers and R4 to use R2, R1 for the

purpose of load-balancing.


19/333




VPN Solutions

2.1 LAN-to-LAN VPN between IOS and ASA Configure a LAN-to-LAN IPsec tunnel between ASA1 and R3 using the

following information:o Phase 1 settings:

Use 3DES encryption. Use MD5 hash. Use DH Group2. Use Pre-Shared keys authentication.

o Use 3DES/MD5 for traffic encryption and integrity validationrespectively.

Only protect traffic between VLAN23 and VLAN121 subnets.

Configuration

Note

LAN-to-LAN IPsec VPN involves two devices in security negotiation. The result ofthis negotiation is an agreement to encrypt a certain set of traffic between the twoendpoints. The negotiations proceed in two phases:

1) IPsec Phase 1: Devices authenticate each other using any configuredmethod, .e.g a pre-shared password, digital signatures and so on. The bothparties have first to negotiate the authentication method.. During theauthentication phase, devices exchange their identities (e.g. IP addresses,hostnames, digital certificates) and prove that they are themselves. Further,devices establish a secure channel the called ISAKAMP SA (Security

Association) which is used to protect any further management communications.

The core procedure for establishing a secure channel is Diffie-Hellman (DH) keyexchange (KE). This procedure allows a pair of devices to derive a commonshared encryption key without letting any side party to eavesdrop it. DH KEinvolves discrete calculations on certain cyclic group. IPsec settings allows youselecting the group number, with the larger group being slower in computationsbut more secure.

You may often the term ISAKMP (Internet Security Association Key ManagementProtocol) and the term IKE (Internet Key Exchange) to be used interchangeably.However, this is not strictly correct, as ISAKMP is an abstract framework, while


20/333




IKE is its actual implementation.

The IPSec Phase 1 may run in two modes: Main Mode and Aggressive Mode.The first mode utilizes six messages exchange procedure. Priori to exchangingdevice identities and authenticating them, Main Mode ensures the DH KE

produces a shared encryption key to protect the authentication phase. Aggressive Mode uses just three messages to establish the ISAKMP SA. Thismode exchange device identities in parallel with the shared encryption keygeneration. This is less secure, but has some unique advantages, when usingpre-shared keys for authentication. As we see later, IKE Main Mode with pre-shared keys has some limitations, because identities are exchanged only afterthe channel has been secured.

2) IPsec Phase 2: Two endpoints agree on the traffic they are going to encryptand the cipher/hash functions to use. Both parties exchange the so-called ProxyIdentities, which are in essence access-lists defining the traffic that each side

wants to encrypt. Both sides check that their Proxy IDs are non-conflicting, i.e.they dont define mismatching traffic sets. The endpoints agree on the mode ofencryption, which is usually tunnel mode, when the endpoint prependsadditional header to route the tunneled packet to another device. The additionalheader is called ESP or encapsulated Security Payload. This header contains theIP addresses of the source/destination VPN endpoints and the original packet isencrypted and hidden behind. There is an option to use the AH (AuthenticatedHeader) encapsulation, which does not encrypt traffic but only checksums thecontent. Thus AH ensures integrity but not confidentiality, which is rather rarelyneeded.

IPSec Phase 2 has only one mode of operations, called Quick Mode. This modeuses three messages to establish the IPSec SA. All Quick Mode communicationsand negotiations are protected by the ISAKMP SA.

LAN-to-LAN VPN configuration in ASA firewall consists of the following steps:

1) Defining global ISAKMP (Phase 1) policy using the command cryptoisakmp policy . You need to set the authentication method, thecipher to protect the ISAKMP SA and the hash function for integrity checks.

Additionally, you may change the DH group number if you want, the defaultgroup is 2. After you have defined the ISAKMP policy, you should enable it onthe interface where the VPN tunnel is to be terminated using the commandcrypto isakmp enable . Notice that the default ISAKMP policyuses RSA-signatures for authentication, and that the policy-list is scanned fromlower numbers to higher when matching the incoming proposals from the remotepeer.

2) Create a tunnel-group the LAN-to-LAN tunnel using the commands tunnel-


21/333




group type ipsec-l2l and tunnel-group ipsec-attributes . The tunnel-group is essentially an object that defines theadministrative policy to be applied to the LAN-to-LAN tunnel. It does NOT definethe traffic to be protected; rather most attributes are related to IPSec Phase 1. Upto some point, it could be compared with ISAKMP profile concept in IOS routers.

The tunnel group name must be the IP address of the remote endpoint, if you areusing pre-shared keys for authentication. A symbolic name could be used insome cases, as we will see in separate tasks. When the firewall establishes aVPN tunnel it will look through the list of local tunnel-groups based on the remoteendpoint IP address. At the very least, the tunnel group must specify the peerauthentication information, such as pre-shared key, if the global ISAKMP policyuses pre-shared keys for authentication.

Notice that the concept of tunnel-group has been borrowed from VPN3000concentrator series. The rest of the IPSec configuration in ASA firewall is verysimilar to Cisco IOS.

3) Define a crypto transform-set for IPsec Phase 2 using the command cryptoipsec transform-set . This command defines the security parameters for theIPsec tunnel, specifically the cipher, hash function and optionally the mode of theIPsec protection tunnel or transport.

4) Define a subset of traffic for IPSec protection using an extended access-list.The syntax is permit and should mirror the entries configured in the remoteendpoint.

5) Create a crypto-map using the command crypto-map {set|match} that matches the above-created access-list, sets the remote peerand the transform-set. This completes the settings for IPSec Phase 2. Notice thatsetting the remote peer is important, since this is how the firewall binds the proxyIDs in the access-list to the tunnel group.

There are some optional parameters that are only supported by ASA firewall.You may use the command crypto-map set connection-type {answer-only|originate-only|bidirectional} to specify thetype of the VPN tunnel, similar to the types used in VPN3000. Answer-only entry

will not attempt to initiate the VPN tunnel for outgoing traffic. Originate-onlytunnel will not be established until there is outgoing traffic.

When youre done with the crypto-map configuration, apply the crypto-map to theinterface where you expect the VPN tunnel to be terminated using the interface-level command crypto-map .

6) The last thing you may want to do is make sure that the command sysopt


22/333




connection permit-vpn is enabled. When this option is enabled, thedecrypted VPN traffic is NOT subject to access-list checks on the interface wherethe tunnel has terminated. For example, if you have this command disabled, andthe tunnel terminates on the outside interface, then the decrypted traffic will bechecked against the interface inbound access-list.

Now for the IOS part of IPSec configuration.

1) The first step is very similar to ASA configuration you define an ISAKMPpolicy. Make sure you set the DH group to 2, when connecting to an ASA firewall(or configure the ASA firewall to use DH group 1) as the default DH group for IOSrouters is group 1. Other settings must much the settings configured in theremote endpoint.

2) If you are using the pre-shared keys for authentication, you should define oneusing the global mode command crypto isakmp key . This differs from the

tunnel-group settings used in the ASA firewall. In some advanced cases you maywant to set additional Phase 1 settings using ISAKMP profiles. We will coverthose in separate tasks.

3) Create a transform set, like you did in the ASA. Make sure the cipher and thehash match the values used in the ASA endpoint.

4) Create an extended access-list that defines the traffic to be encrypted. Asusual, this access-list should mirror the access-list entries used in the remoteendpoint.

5) Create a crypto map that matches the access-list created above, sets the peerIP address and configure the transform set to be applied to the traffic. Thiscompletes the configuration of IPSec Phase 2 settings.

As you can see, the configuration for ASA firewall and IOS router is very muchsimilar. There are, however, differences, mostly related to the tunnel-groupconcept inherited by the ASA firewalls from VPN3000 concentrator code.


23/333




ASA1: !! Configure & Enable ISAKMP policy !cr ypt o i sakmp pol i cy 10

aut hent i cat i on pr e- share

encr ypt i on 3deshash md5!cr ypt o i sakmp enabl e out si de

!! Configure tunnel group for L2L tunnel !t unnel - gr oup 136. 1. 123. 3 t ype i psec- l 2lt unnel - gr oup 136. 1. 123. 3 i psec- at t r i but es

pre- shared- key CI SCO

!! Configure transform-set !cr ypt o i psec t r ansf or m- set 3DES_MD5 esp- 3des esp- md5- hmac

!! Access-list to classify traffic for encryption !access- l i st VLAN121_TO_VLAN23 per mi t i p 136. 1. 121. 0 255. 255. 255. 0136. 1. 23. 0 255. 255. 255. 0

!! Create a crypto-map !cr ypt o map VPN 10 mat ch addr ess VLAN121_TO_VLAN23

cr ypt o map VPN 10 set peer 136. 1. 123. 3cr ypt o map VPN 10 set t r ansf or m- set 3DES_MD5

!! Apply crypto-map and enable VPN traffic to bypass ACLs !cr ypt o map VPN i nt er f ace out si desysopt connect i on per mi t - vpn

R3: !! Configure ISAKMP policy !cr ypt o i sakmp pol i cy 10

encr ypt i on 3desaut h pr e- sharehash md5gr oup 2

!cr ypt o i sakmp key CI SCO address 136. 1. 123. 12


24/333




!! Create transform-set !cr ypt o i psec t r ansf or m- set 3DES_MD5 esp- 3des esp- md5- hmac

!! Create access-list to classify traffic for encryption !i p access- l i st ext ended VLAN23_TO_VLAN121

per mi t i p 136. 1. 23. 0 0. 0. 0. 255 136. 1. 121. 0 0. 0. 0. 255

!! Create & apply crypto map !cr ypt o map VPN 10 i psec- i sakmp

mat ch addr ess VLAN23_TO_VLAN121set t r ansf or m 3DES_MD5set peer 136. 1. 123. 12

!

i nt er f ace Fast Et her net 0/ 0cr ypt o map VPN


25/333




Verification

Note

To verify your configuration, send some traffic from R1 to R1s VLAN121 IP

address.

Rack1R2#ping 136.1.121.1

Type escape sequence t o abor t .Sendi ng 5, 100- byt e I CMP Echos t o 136. 1. 121. 1, t i meout i s 2 seconds:. ! ! ! !Success r at e i s 80 percent ( 4/ 5) , r ound- t r i p mi n/ avg/ max = 100/ 166/ 189ms

Note

Now check the VPN tunnel stats in R3. Firs check the ISAKMP SA. Pay attentionto the cipher/hash and the authentication mode used.

Rack1R3#show crypto isakmp sa detailCodes: C - I KE conf i gur at i on mode, D - Dead Peer Det ect i on

K - Keepal i ves, N - NAT- t r aver salX - I KE Ext ended Aut hent i cat i onpsk - Preshared key, r si g - RSA si gnat ur er enc - RSA encr ypt i on

C- i d Local Remot e I - VRF Encr Hash Aut h DH

Li f et i me Cap.2 136. 1. 123. 3 136. 1. 123. 12 3des md5 psk 223: 54: 52

Note

Now check IPsec Phase 2 SAs in R3. They should cover traffic between VLAN23and VLAN121. Notice that the counters for encapsulated and de-capsulatedpackets are incrementing.


26/333




Rack1R3#show crypto ipsec sa

i nt er f ace: Et her net 0/ 0Cr ypt o map t ag: VPN, l ocal addr . 136. 1. 123. 3

pr ot ected vr f :

l ocal i dent ( addr / mask/ pr ot / por t ) : ( 136. 1. 23. 0/ 255. 255. 255. 0/ 0/ 0)r emot e i dent ( addr / mask/ pr ot / por t ) : ( 136. 1. 121. 0/ 255. 255. 255. 0/ 0/ 0)cur r ent _peer: 136. 1. 123. 12: 500

PERMI T, f l ags={or i gi n_i s_acl , }#pkt s encaps: 4, #pkt s encr ypt : 4, #pkt s di gest 4#pkt s decaps: 4, #pkt s decr ypt : 4, #pkt s ver i f y 4#pkt s compr essed: 0, #pkt s decompr essed: 0#pkt s not compr essed: 0, #pkt s compr . f ai l ed: 0#pkt s not decompressed: 0, #pkt s decompress f ai l ed: 0#send er r or s 21, #r ecv er r or s 0

Note

Notice the output below. It specifies the IPsec tunnel endpoints, which should bethe IP addresses of the router and the ASA firewall. Further note that Tunnelmode is in use and ESP header (Encapsulated Security Payload) is used forpacket tunneling. Make sure the transform set in the output matches the onerequired by the scenario.

If you are wondering about the meaning of SPI keyword, it stands for SecurityParameters Index. This value is carried in IPsec header, and used by thereceiving router to find the matching IPsec Phase 2 SA. Essentially, it is just anindex in the array of SAs.

l ocal cr ypt o endpt . : 136. 1. 123. 3, r emote cr ypt o endpt . : 136. 1. 123. 12pat h mt u 1500, medi a mt u 1500cur r ent out bound spi : 482D0576

i nbound esp sas:spi : 0xB0A78AA3( 2963770019)

t r ansf or m: esp- 3des esp- md5- hmac ,i n use set t i ngs ={Tunnel , }sl ot : 0, conn i d: 2000, f l ow_i d: 1, cr ypt o map: VPNsa t i mi ng: r emai ni ng key l i f et i me ( k/ sec) : ( 4455492/ 3285)I V si ze: 8 byt esr epl ay det ect i on suppor t : Y

i nbound ah sas:

i nbound pcp sas:

out bound esp sas:spi : 0x482D0576( 1210910070)

t r ansf or m: esp- 3des esp- md5- hmac ,i n use set t i ngs ={Tunnel , }


27/333




sl ot : 0, conn i d: 2001, f l ow_i d: 2, cr ypt o map: VPNsa t i mi ng: r emai ni ng key l i f et i me ( k/ sec) : ( 4455492/ 3285)I V si ze: 8 byt esr epl ay det ect i on suppor t : Y

out bound ah sas:

out bound pcp sas:

Note

Check ISAKMP SA status in the ASA firewall next. Notice the IKE Peer IPaddress and the State which should be MM_ACTIVE in the case of L2L tunnel(Main Mode, Active).

Rack1ASA1(config)# show crypto isakmp sa

Act i ve SA: 1Rekey SA: 0 ( A t unnel wi l l r epor t 1 Act i ve and 1 Rekey SA dur i ngr ekey)

Tot al I KE SA: 1

1 I KE Peer : 136. 1. 123. 3 Type : L2L Rol e : r esponderRekey : no St at e : MM_ACTI VE

Note

Now check the IPSec Phase 2 SA in the ASA firewall. They should mirror the

entries in the IOS router and have packet counters incrementing.

Rack1ASA1(config)# show cry ipsec sai nt er f ace: out si de

Cr ypt o map t ag: VPN, seq num: 10, l ocal addr: 136. 1. 123. 12

access- l i st VLAN121_TO_VLAN23 permi t i p 136. 1. 121. 0 255. 255. 255. 0136. 1. 23. 0 255. 255. 255. 0

l ocal i dent ( addr / mask/ pr ot / por t ) :( 136. 1. 121. 0/ 255. 255. 255. 0/ 0/ 0)

r emot e i dent ( addr / mask/ pr ot/ por t ) :( 136. 1. 23. 0/ 255. 255. 255. 0/ 0/ 0)

cur r ent _peer : 136. 1. 123. 3


28/333




#pkt s encaps: 4, #pkt s encr ypt : 4, #pkt s di gest : 4#pkt s decaps: 4, #pkt s decr ypt : 4, #pkt s ver i f y: 4#pkt s compressed: 0, #pkt s decompressed: 0#pkt s not compressed: 4, #pkt s comp f ai l ed: 0, #pkt s decomp

f ai l ed: 0#pr e- f r ag successes: 0, #pr e- f r ag f ai l ur es: 0, #f r agment s

cr eat ed: 0#PMTUs sent : 0, #PMTUs r cvd: 0, #decapsul at ed f r gs needi ng

r eassembl y: 0#send er r ors: 0, #r ecv er r ors : 0

l ocal cr ypt o endpt . : 136. 1. 123. 12, r emot e cr ypt o endpt . :136. 1. 123. 3

Note

The next thing were going to do is explore debugging output in the ASA firewalland the IOS router. We start with the firewall and clear all active IPSec sessionsfirst. Then we enable ISAKMP and IPSec debugging in the ASA unit.

Rack1ASA1( conf i g) # clear crypto isakmp Rack1ASA1( conf i g) # clear crypto ipsec sa

Rack1ASA1( conf i g) # debug crypto isakmp 9 Rack1ASA1( conf i g) # debug crypto ipsec 9

Rack1R2#ping 136.1.121.1

Type escape sequence t o abor t .Sendi ng 5, 100- byt e I CMP Echos t o 136. 1. 121. 1, t i meout i s 2 seconds:. ! ! ! !Success r at e i s 80 per cent ( 4/ 5) , r ound- t r i p mi n/ avg/ max = 4/ 4/ 4 ms

Note

The following output demonstrates IKE main mode 6 messages exchange. Thefirst portion of the debug output in the ASA shows the initial IKE messagereceived from R3. Most important thing in this output is that the incoming SA

proposal matches a local ISAKMP policy entry.


29/333




%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE RECEI VED Message ( msgi d=0)wi t h payl oads : HDR + SA ( 1) + VENDOR ( 13) + VENDOR ( 13) + VENDOR ( 13)+ VENDOR ( 13) + NONE ( 0) t ot al l engt h : 164%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng SA payl oad%ASA- 7- 713906: I P = 136. 1. 123. 3, Oakl ey proposal i s accept abl e%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715049: I P = 136. 1. 123. 3, Recei ved NAT- Tr aver sal RFC VI D%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715049: I P = 136. 1. 123. 3, Recei ved NAT- Tr aver sal ver 03 VI D%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715049: I P = 136. 1. 123. 3, Recei ved NAT- Tr aver sal ver 02 VI D%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng I KE SA payl oad%ASA- 7- 715028: I P = 136. 1. 123. 3, I KE SA Pr oposal # 1, Tr ansf or m # 1accept abl e Mat ches gl obal I KE ent r y # 3

Note

The firewall prepares a response IKE packet, where it specifies the acceptedpolicy and additional information.

%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng I SAKMP SA payl oad%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng NAT- Tr avers al VI D ver 02payl oad%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng Fr agment at i on VI D +extended capabi l i t i es payl oad%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE SENDI NG Message ( msgi d=0)wi t h payl oads : HDR + SA ( 1) + VENDOR ( 13) + VENDOR ( 13) + NONE ( 0)t ot al l engt h : 128

Note The third message in row is the one received from R3 again. The most importantfield here is the KE (key-exchange header) which is used for Diffie-Hellmanshared secret generation. The firewall processes the KE message and preparesa response. Notice that the firewall also processes NAT-D (NAT discovery)headers from the other node. Those headers contain the hashed values of theoriginal IP addresses used by the initiator. This allows for detection of a NATdevices on the path between the two IPSec endpoints.


30/333




%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE RECEI VED Message ( msgi d=0)wi t h payl oads : HDR + KE ( 4) + NONCE ( 10) + VENDOR ( 13) + VENDOR ( 13) +VENDOR ( 13) + VENDOR ( 13) + NAT- D ( 130) + NAT- D ( 130) + NONE ( 0) t ot all engt h : 296%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng ke payl oad%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng I SA_KE payl oad%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng nonce payl oad%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715049: I P = 136. 1. 123. 3, Recei ved Ci sco Uni t y cl i ent VI D%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715049: I P = 136. 1. 123. 3, Recei ved DPD VI D%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715038: I P = 136. 1. 123. 3, Processi ng I OS/ PI X Vendor I D payl oad( ver s i on: 1. 0. 0, capabi l i t i es : 00000f 7f )%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng VI D payl oad%ASA- 7- 715049: I P = 136. 1. 123. 3, Recei ved xaut h V6 VI D%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng NAT- Di scovery payl oad%ASA- 7- 713906: I P = 136. 1. 123. 3, comput i ng NAT Di scover y hash%ASA- 7- 715047: I P = 136. 1. 123. 3, processi ng NAT- Di scovery payl oad%ASA- 7- 713906: I P = 136. 1. 123. 3, comput i ng NAT Di scover y hash

%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng ke payl oad%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng nonce payl oad%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng Ci sco Uni t y VI D payl oad%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng xaut h V6 VI D payl oad%ASA- 7- 715048: I P = 136. 1. 123. 3, Send I OS VI D%ASA- 7- 715038: I P = 136. 1. 123. 3, Const r uct i ng ASA spoof i ng I OS VendorI D payl oad ( ver si on: 1. 0. 0, capabi l i t i es: 20000001)%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng VI D payl oad%ASA- 7- 715048: I P = 136. 1. 123. 3, Send Al t i ga/ Ci sco VPN3000/ Ci sco ASA GWVI D


31/333




Note

In addition to generating a KE response, the local endpoint prepares its ownNAT-D headers to be used in subsequent exchange.

%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng NAT- Di scover y payl oad%ASA- 7- 713906: I P = 136. 1. 123. 3, comput i ng NAT Di scovery hash%ASA- 7- 715046: I P = 136. 1. 123. 3, const r uct i ng NAT- Di scover y payl oad%ASA- 7- 713906: I P = 136. 1. 123. 3, comput i ng NAT Di scovery hash

Note

Now a very important moment. In order to be able to generate the sharedencryption key, the local endpoint must find the pre-shared key matching theremote peer. This is because the shared key is produced from the Diffie-Hellmangenerated key hashed with the pre-shared key configured for the remoteendpoint. At this point of IKE exchange the firewall does not yet learned the IKEID of the remote endpoint. Thus, the only way to find a matching pre-shared keyis to scan all local tunnel groups based on the remote peers IP address. This is afundamental limitation of using the pre-shared keys for IKE Main Modeauthentication PSKs are always looked up based on IP addresses.

%ASA- 7- 713906: I P = 136. 1. 123. 3, Connect i on l anded on t unnel _gr oup136. 1. 123. 3%ASA- 7- 713906: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Generat i ng keysf or Responder . . .

Note

We send our response to the peer. At this moment, the encrypted channel hasbeen established, and the following exchange is fully protected.

%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE SENDI NG Message ( msgi d=0)wi t h payl oads : HDR + KE ( 4) + NONCE ( 10) + VENDOR ( 13) + VENDOR ( 13) +VENDOR ( 13) + VENDOR ( 13) + NAT- D ( 130) + NAT- D ( 130) + NONE ( 0) t ot all engt h : 296


32/333




Note

Now we receive the fifth message from our peer, containing its IKE ID. Formally,this message is used for authentication, based on the peers ID. However, due tothe nature of the shared key generation, the remote party has been alreadyauthenticated. Thus, the remote IKE ID is simply ignored in case of IKE MainMode with PSK authentication.

%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE RECEI VED Message ( msgi d=0)wi t h payl oads : HDR + I D ( 5) + HASH ( 8) + NOTI FY ( 11) + NONE ( 0) t ot all engt h : 88%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng I Dpayl oad%ASA- 7- 714011: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, I D_I PV4_ADDR I Dr ecei ved136. 1. 123. 3%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng hashpayl oad%ASA- 7- 715076: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Comput i ng hashf or I SAKMP%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, pr ocessi ng not i f ypayl oad

Note

Also, now both devices know if there is any NAT box in the path or not, based onthe preceeding NAT-D exchange.

%ASA- 6- 713172: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Aut omat i c NATDet ect i on St at us: Remot e end i s NOT behi nd a NAT devi ce Thi send i s NOT behi nd a NAT devi ce%ASA- 7- 713906: I P = 136. 1. 123. 3, Connect i on l anded on t unnel _gr oup136. 1. 123. 3%ASA- 4- 713903: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Fr eei ngpr evi ousl y al l ocat ed memor y f or aut hor i zat i on- dn- at t r i but es%ASA- 7- 715046: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, const r uct i ng I Dpayl oad%ASA- 7- 715046: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, const r uct i ng hashpayl oad%ASA- 7- 715076: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Comput i ng hash

f or I SAKMP%ASA- 7- 715034: I P = 136. 1. 123. 3, Const r uct i ng I OS keep al i ve payl oad:proposal =32767/ 32767 sec.%ASA- 7- 715046: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, const r uct i ng dpdvi d payl oad


33/333




Note

The local endpoint sends its own IKE ID to the peer along with other information.This finishes the 6-message Main Mode exchange.

%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE SENDI NG Message ( msgi d=0)wi t h payl oads : HDR + I D ( 5) + HASH ( 8) + I OS KEEPALI VE ( 128) + VENDOR( 13) + NONE ( 0) t ot al l engt h : 92%ASA- 6- 113009: AAA r et r i eved def aul t gr oup pol i cy ( Df l t Gr pPol i cy) f oruser = 136. 1. 123. 3%ASA- 5- 713119: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, PHASE 1 COMPLETED%ASA- 7- 713121: I P = 136. 1. 123. 3, Keep- al i ve t ype f or t hi s connect i on:DPD%ASA- 7- 715080: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, St ar t i ng P1 r ekeyt i mer : 82080 seconds.

Note

Now its time to run IPSec Phase 2 negotiations (running in Quick Mode, QM)and establish the IPSec SA. We receive the initial proposal from our peer. Thisproposal contains the SA payload, that describes the security policy (cipher,hash) and the KE message, which is a part of the new DH exchange, to generatethe new encryption key.

%ASA- 7- 714003: I P = 136. 1. 123. 3, I KE Responder st ar t i ng QM: msg i d =c244ac78%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE RECEI VED Message( msgi d=c244ac78) wi t h payl oads : HDR + HASH ( 8) + SA ( 1) + NONCE ( 10) +I D ( 5) + I D ( 5) + NONE ( 0) t ot al l engt h : 164%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng hashpayl oad%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng SApayl oad%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng noncepayl oad%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng I Dpayl oad


34/333




Note

The first packet from the initiator also contains the ID payload. This payloaddescribes the Proxy IDs that the remote end is willing to protect.

%ASA- 7- 714011: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3,I D_I PV4_ADDR_SUBNET I D r ecei ved- - 136. 1. 23. 0- - 255. 255. 255. 0%ASA- 7- 713035: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Recei ved r emot eI P Pr oxy Subnet dat a i n I D Payl oad: Addr ess 136. 1. 23. 0, Mask255. 255. 255. 0, Pr ot ocol 0, Por t 0%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng I Dpayl oad%ASA- 7- 714011: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3,I D_I PV4_ADDR_SUBNET I D recei ved- - 136. 1. 121. 0- - 255. 255. 255. 0%ASA- 7- 713034: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Recei ved l ocal I PProxy Subnet dat a i n I D Payl oad: Address 136. 1. 121. 0, Mask255. 255. 255. 0, Pr ot ocol 0, Por t 0%ASA- 7- 713906: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, QM I sRekeyed ol dsa not f ound by addr

Note

The firewall starts scanning the crypto map attached to the interface where theIPSec session terminates. The crypto map is scanned to find the matching peerIP address and extract the access-list associated with this peer. Additionally, thelocally configured transform-set is extracted and compared to the remoteproposal. In our case, everything matches OK, and the local endpoint may

prepare and send an answer.

%ASA- 7- 713221: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, St at i c Cr ypt o Mapcheck, checki ng map = VPN, seq = 10. . .%ASA- 7- 713225: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, St at i c Cr ypt o Mapcheck, map VPN, seq = 10 i s a successf ul mat ch%ASA- 7- 713066: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, I KE Remot e Peerconf i gur ed f or cr ypt o map: VPN%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng I PSecSA payl oad%ASA- 7- 715027: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, I PSec SA Pr oposal# 1, Tr ansf or m # 1 accept abl e Mat ches gl obal I PSec SA ent r y # 10%ASA- 7- 713906: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, I KE: r equest i ng

SPI !%ASA- 7- 715006: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, I KE got SPI f r omkey engi ne: SPI = 0x0c27c77b%ASA- 7- 713906: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, oakl eyconst uct i ng qui ck mode


35/333




Note

The local endpoint prepares the quick-mode response, with the local proxy IDsand the accepted proposal.

%ASA- 7- 715001: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, const r uct i ngpr oxy I D%ASA- 7- 713906: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Tr ansmi t t i ngPr oxy I d:

Remot e subnet : 136. 1. 23. 0 Mask 255. 255. 255. 0 Prot ocol 0 Por t 0Local subnet : 136. 1. 121. 0 mask 255. 255. 255. 0 Prot ocol 0 Por t 0

%ASA- 7- 715046: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, const r uct i ng qmhash payl oad%ASA- 7- 714005: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, I KE Respondersendi ng 2nd QM pkt : msg i d = c244ac78%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE SENDI NG Mess age( msgi d=c244ac78) wi t h payl oads : HDR + HASH ( 8) + SA ( 1) + NONCE ( 10) +I D ( 5) + I D ( 5) + NONE ( 0) t ot al l engt h : 164

Note

The final 3 rd message of the QM exchange is received from the remote end. NowPhase 2 negotiations have been successfully terminated and we have IPSec SAsinstalled in both endpoints.

%ASA- 7- 713236: I P = 136. 1. 123. 3, I KE_DECODE RECEI VED Message( msgi d=c244ac78) wi t h payl oads : HDR + HASH ( 8) + NONE ( 0) t ot al l engt h

: 48%ASA- 7- 715047: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, processi ng hashpayl oad%ASA- 7- 713906: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, l oadi ng al l I PSECSAs%ASA- 7- 715001: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Generat i ng Qui ckMode Key!%ASA- 7- 715001: Gr oup = 136. 1. 123. 3, I P = 136. 1. 123. 3, Generat i ng Qui ckMode Key!


36/333




Note

Lets review the same IKE message exchange at the other side of the tunnel, inR3. Enable debugging and generate some traffic that matches the VPN filter.

Rack1R3# clear crypto isakmp Rack1R3# clear crypto sa

Rack1R3# debug crypto isakmpCr ypt o I SAKMP debuggi ng i s on

Rack1R3# debug crypto ipsecCr ypt o I PSEC debuggi ng i s on

Rack1R3# ping 136.1.121.1 source fastEthernet 0/1

Type escape sequence t o abor t .Sendi ng 5, 100- byt e I CMP Echos t o 136. 1. 121. 1, t i meout i s 2 seconds:Packet sent wi t h a sour ce addr ess of 136. 1. 23. 3. ! ! ! !Success r at e i s 80 per cent ( 4/ 5) , r ound- t r i p mi n/ avg/ max = 4/ 7/ 8 msRack1R3#

Note

The first thing that the local router attempts to do is to find a local SA matchingthe traffic. Since there is no local SA to use, the local endpoint starts ISAKMP

negotiations:

I PSEC( sa_r equest ) : ,( key eng. msg. ) OUTBOUND l ocal = 136. 1. 123. 3, r emot e= 136. 1. 123. 12,

l ocal _proxy= 136. 1. 23. 0/ 255. 255. 255. 0/ 0/ 0 ( t ype=4) ,r emot e_pr oxy= 136. 1. 121. 0/ 255. 255. 255. 0/ 0/ 0 ( t ype=4) ,prot ocol = ESP, t r ansf or m= esp- 3des esp- md5- hmac ( Tunnel ) ,l i f edur= 3600s and 4608000kb,spi = 0x0( 0) , conn_i d= 0, keysi ze= 0, f l ags= 0x0

I SAKMP: ( 0) : SA r equest pr of i l e i s ( NULL)I SAKMP: Cr eat ed a peer st r uct f or 136. 1. 123. 12, peer port 500I SAKMP: New peer cr eat ed peer = 0x83E80BDC peer _handl e = 0x80000005I SAKMP: Locki ng peer s t r uct 0x83E80BDC, r ef count 1 f or i sakmp_i ni t i at orI SAKMP: l ocal por t 500, r emot e por t 500I SAKMP: set new node 0 t o QM_I DLEI SAKMP: Fi nd a dup sa i n t he avl t r ee dur i ng cal l i ng i sadb_i nser t sa =83EA4438


37/333




Note

By default, IKE Main Mode is selected for negotiations. Based on the ISAKMPpolicy, the locally configured keys are looked up to find the one matching theremote peers IP address. The first packet will not be sent out until a local pre-shared key is found. The initial proposal contains the list of local ISAKMPpolicies, and suggests the responder to select the best one.

I SAKMP: ( 0) : Can not st ar t Aggressi ve mode, t r yi ng Mai n mode.I SAKMP: ( 0) : f ound peer pre- shar ed key mat chi ng 136. 1. 123. 12I SAKMP: ( 0) : const r uct ed NAT- T vendor- r f c3947 I DI SAKMP: ( 0) : const r uct ed NAT- T vendor - 07 I DI SAKMP: ( 0) : const r uct ed NAT- T vendor - 03 I DI SAKMP: ( 0) : const r uct ed NAT- T vendor - 02 I DI SAKMP: ( 0) : I nput = I KE_MESG_FROM_I PSEC, I KE_SA_REQ_MMI SAKMP: ( 0) : Ol d St at e = I KE_READY New St at e = I KE_I _MM1

I SAKMP: ( 0) : begi nni ng Mai n Mode exchangeI SAKMP: ( 0) : sendi ng packet t o 136. 1. 123. 12 my_por t 500 peer _port 500( I ) MM_NO_STATEI SAKMP: ( 0) : Sendi ng an I KE I Pv4 Packet .I SAKMP ( 0: 0) : r ecei ved packet f r om 136. 1. 123. 12 dport 500 sport 500Gl obal ( I ) MM_NO_STATEI SAKMP: ( 0) : I nput = I KE_MESG_FROM_PEER, I KE_MM_EXCHI SAKMP: ( 0) : Ol d St at e = I KE_I _MM1 New St at e = I KE_I _MM2

Note

We just received a response to our initial message with the ISAKMP policyselected by the peer. The response also contains other useful information suchas vendor IDs.

I SAKMP: ( 0) : process i ng SA payl oad. message I D = 0I SAKMP: ( 0) : pr ocessi ng vendor i d payl oadI SAKMP: ( 0) : vendor I D seems Uni t y/ DPD but maj or 123 mi smat chI SAKMP: ( 0) : vendor I D i s NAT- T v2I SAKMP: ( 0) : pr ocessi ng vendor i d payl oadI SAKMP: ( 0) : pr ocessi ng I KE f r ag vendor i d payl oadI SAKMP: ( 0) : Support f or I KE Fragment at i on not enabl edI SAKMP: ( 0) : f ound peer pre- shar ed key mat chi ng 136. 1. 123. 12

I SAKMP: ( 0) : l ocal pr eshar ed key f oundI SAKMP : Scanni ng pr of i l es f or xaut h . . .


38/333




Note

The local endpoint attempts to match the policy selected by the remote endpointagainst the list of the local rules. If a match is found, the system may processfurther to Key Exchange step.

I SAKMP: ( 0) : Checki ng I SAKMP t r ansf or m 1 agai nst pr i or i t y 10 pol i cyI SAKMP: encr ypt i on 3DES- CBCI SAKMP: hash MD5I SAKMP: def aul t gr oup 2I SAKMP: aut h pre- shar eI SAKMP: l i f e t ype i n secondsI SAKMP: l i f e dur at i on ( VPI ) of 0x0 0x1 0x51 0x80I SAKMP: ( 0) : at t s are accept abl e. Next payl oad i s 0I SAKMP: ( 0) : Accept abl e at t s: actual l i f e: 0I SAKMP: ( 0) : Accept abl e at t s: l i f e: 0

I SAKMP: ( 0) : Fi l l at t s i n sa vpi _l engt h: 4I SAKMP: ( 0) : Fi l l at t s i n sa l i f e_i n_seconds: 86400I SAKMP: ( 0) : Ret ur ni ng Act ual l i f et i me: 86400I SAKMP: ( 0) : : St ar t ed l i f et i me ti mer : 86400.

I SAKMP: ( 0) : pr ocessi ng vendor i d payl oadI SAKMP: ( 0) : vendor I D seems Uni t y/ DPD but maj or 123 mi smat chI SAKMP: ( 0) : vendor I D i s NAT- T v2I SAKMP: ( 0) : pr ocessi ng vendor i d payl oadI SAKMP: ( 0) : pr ocessi ng I KE f r ag vendor i d payl oadI SAKMP: ( 0) : Support f or I KE Fragment at i on not enabl edI SAKMP: ( 0) : I nput = I KE_MESG_I NTERNAL, I KE_PROCESS_MAI N_MODEI SAKMP: ( 0) : Ol d St at e = I KE_I _MM2 New St at e = I KE_I _MM2

Note

The third message is sent out, with the KE payload and other information.

I SAKMP: ( 0) : sendi ng packet t o 136. 1. 123. 12 my_por t 500 peer _port 500( I ) MM_SA_SETUPI SAKMP: ( 0) : Sendi ng an I KE I Pv4 Packet .I SAKMP: ( 0) : I nput = I KE_MESG_I NTERNAL, I KE_PROCESS_COMPLETEI SAKMP: ( 0) : Ol d St at e = I KE_I _MM2 New St at e = I KE_I _MM3


39/333




Note

Received the KE response from out peer. At this point, we should be able togenerate the session key based on the DH key-exchange and the pre-shared keyconfigured for the peer.

I SAKMP ( 0: 0) : r ecei ved packet f r om 136. 1. 123. 12 dport 500 sport 500Gl obal ( I ) MM_SA_SETUPI SAKMP: ( 0) : I nput = I KE_MESG_FROM_PEER, I KE_MM_EXCHI SAKMP: ( 0) : Ol d St at e = I KE_I _MM3 New St at e = I KE_I _MM4

I SAKMP: ( 0) : process i ng KE payl oad. message I D = 0I SAKMP: ( 0) : pr ocessi ng NONCE payl oad. message I D = 0I SAKMP: ( 0) : f ound peer pre- shar ed key mat chi ng 136. 1. 123. 12I SAKMP: ( 1004) : pr ocessi ng vendor i d payl oadI SAKMP: ( 1004) : vendor I D i s Uni t y

I SAKMP: ( 1004) : pr ocessi ng vendor i d payl oadI SAKMP: ( 1004) : vendor I D seems Uni t y/ DPD but maj or 144 mi smat chI SAKMP: ( 1004) : vendor I D i s XAUTHI SAKMP: ( 1004) : pr ocessi ng vendor i d payl oadI SAKMP: ( 1004) : speaki ng t o anot her I OS box!I SAKMP: ( 1004) : pr ocessi ng vendor i d payl oadI SAKMP: ( 1004) : vendor I D seems Uni t y/ DPD but hash mi smat chI SAKMP: r ecei ved payl oad t ype 20I SAKMP: r ecei ved payl oad t ype 20I SAKMP: ( 1004) : I nput = I KE_MESG_I NTERNAL, I KE_PROCESS_MAI N_MODEI SAKMP: ( 1004) : Ol d St at e = I KE_I _MM4 New St at e = I KE_I _MM4

Note

Fifth and Sixth messages constitute IKE ID exchange and peer authentication.However, like mentioned before, the IDs are not actually used for authenticationin Main Mode, since the session key generated already assumes mutualauthentication. The message below contains the local endpoint ID.

I SAKMP: ( 1004) : Send i ni t i al cont actI SAKMP: ( 1004) : SA i s doi ng pr e- shared key aut hent i cat i on usi ng i d t ypeI D_I PV4_ADDRI SAKMP ( 0: 1004) : I D payl oad

next - payl oad : 8

t ype : 1addr ess : 136. 1. 123. 3pr ot ocol : 17port : 500l engt h : 12

I SAKMP: ( 1004) : Tot al payl oad l engt h: 12I SAKMP: ( 1004) : sendi ng packet t o 136. 1. 123. 12 my_por t 500 peer _por t 500( I ) MM_KEY_EXCH


40/333




I SAKMP: ( 1004) : Sendi ng an I KE I Pv4 Packet .I SAKMP: ( 1004) : I nput = I KE_MESG_I NTERNAL, I KE_PROCESS_COMPLETEI SAKMP: ( 1004) : Ol d St at e = I KE_I _MM4 New St at e = I KE_I _MM5

Note

The message received in response contains the IKE ID of the remote box, in thiscase its the IP address of the firewall.

I SAKMP ( 0: 1004) : r ecei ved packet f r om 136. 1. 123. 12 dpor t 500 spor t 500Gl obal ( I ) MM_KEY_EXCHI SAKMP: ( 1004) : processi ng I D payl oad. message I D = 0I SAKMP ( 0: 1004) : I D payl oad

next - payl oad : 8t ype : 1addr ess : 136. 1. 123. 12pr ot ocol : 17por t : 0l engt h : 12

I SAKMP: ( 0) : : peer mat ches *none* of t he pr of i l esI SAKMP: ( 1004) : processi ng HASH payl oad. message I D = 0I SAKMP: r ecei ved payl oad t ype 17I SAKMP: ( 1004) : pr ocessi ng vendor i d payl oadI SAKMP: ( 1004) : vendor I D i s DPDI SAKMP: ( 1004) : SA aut hent i cat i on st at us:

aut hent i cat edI SAKMP: ( 1004) : SA has been aut hent i cat ed wi t h 136. 1. 123. 12I SAKMP: Tr yi ng t o i nsert a peer 136. 1. 123. 3/ 136. 1. 123. 12/ 500/ , andi nsert ed successf ul l y 83E80BDC.I SAKMP: ( 1004) : I nput = I KE_MESG_FROM_PEER, I KE_MM_EXCHI SAKMP: ( 1004) : Ol d St at e = I KE_I _MM5 New St at e = I KE_I _MM6

I SAKMP: ( 1004) : I nput = I KE_MESG_I NTERNAL, I KE_PROCESS_MAI N_MODEI SAKMP: ( 1004) : Ol d St at e = I KE_I _MM6 New St at e = I KE_I _MM6

I SAKMP: ( 1004) : I nput = I KE_MESG_I NTERNAL, I KE_PROCESS_COMPLETEI SAKMP: ( 1004) : Ol d St at e = I KE_I _MM6 New St at e = I KE_P1_COMPLETE


41/333




Note

The six message IKE MM exchange has completed. Now it is time for 3messages of Quick Mode. The initial message from the local node contains thelocal proxy IDs (not shown in the output) and our security policy (cipher, hash,etc).

I SAKMP: ( 1004) : begi nni ng Qui ck Mode exchange, M- I D of 946616940I SAKMP: ( 1004) : QM I ni t i at or get s spiI SAKMP: ( 1004) : sendi ng packet t o 136. 1. 123. 12 my_por t 500 peer _por t 500( I ) QM_I DLEI SAKMP: ( 1004) : Sendi ng an I KE I Pv4 Packet .I SAKMP: ( 1004) : Node 946616940, I nput = I KE_MESG_I NTERNAL, I KE_I NI T_QMI SAKMP: ( 1004) : Ol d St at e = I KE_QM_READY New St at e = I KE_QM_I _QM1I SAKMP: ( 1004) : I nput = I KE_MESG_I NTERNAL, I KE_PHASE1_COMPLETEI SAKMP: ( 1004) : Ol d St at e = I KE_P1_COMPLETE New St at e = I KE_P1_COMPLETE

Note

The next message is the response from the peer. Now the debug output showsthe transform set selected by the peer and other SA parameters. Additionally,you can see the Proxy IDs sent by the remote peer.

I SAKMP ( 0: 1004) : r ecei ved packet f r om 136. 1. 123. 12 dpor t 500 spor t 500Gl obal ( I ) QM_I DLEI SAKMP: ( 1004) : processi ng HASH payl oad. message I D = 946616940I SAKMP: ( 1004) : processi ng SA payl oad. message I D = 946616940I SAKMP: ( 1004) : Checki ng I PSec pr oposal 1I SAKMP: t r ansf orm 1, ESP_3DESI SAKMP: at t r i but es i n t r ansf or m:I SAKMP: SA l i f e t ype i n secondsI SAKMP: SA l i f e dur at i on ( basi c) of 3600I SAKMP: SA l i f e t ype i n ki l obyt esI SAKMP: SA l i f e durat i on ( VPI ) of 0x0 0x46 0x50 0x0I SAKMP: encaps i s 1 ( Tunnel )I SAKMP: aut hent i cat or i s HMAC- MD5I SAKMP: ( 1004) : at t s are accept abl e.I PSEC( val i dat e_pr oposal _r equest ) : pr oposal par t #1I PSEC( val i dat e_pr oposal _r equest ) : pr oposal par t #1,

( key eng. msg. ) I NBOUND l ocal = 136. 1. 123. 3, r emot e= 136. 1. 123. 12,

l ocal _proxy= 136. 1. 23. 0/ 255. 255. 255. 0/ 0/ 0 ( t ype=4) ,r emot e_pr oxy= 136. 1. 121. 0/ 255. 255. 255. 0/ 0/ 0 ( t ype=4) ,prot ocol = ESP, t r ansf or m= NONE ( Tunnel ) ,l i f edur = 0s and 0kb,spi = 0x0( 0) , conn_i d= 0, keysi ze= 0, f l ags= 0x0


42/333




Note

The local endpoint matches the QM response message against the crypto mapconfigured on the interface to find a match. Since the match was successful,IPSec SAs are created and user traffic is now encrypted.

Cr ypt o mapdb : pr oxy_mat chsr c addr : 136. 1. 23. 0dst addr : 136. 1. 121. 0pr ot ocol : 0src por t : 0dst por t : 0

I SAKMP: ( 1004) : pr ocessi ng NONCE payl oad. message I D = 946616940I SAKMP: ( 1004) : processi ng I D payl oad. message I D = 946616940I SAKMP: ( 1004) : processi ng I D payl oad. message I D = 946616940I SAKMP: ( 1004) : Cr eat i ng I PSec SAs

i nbound SA f r om 136. 1. 123. 12 t o 136. 1. 123. 3 ( f / i ) 0/ 0( pr oxy 136. 1. 121. 0 t o 136. 1. 23. 0)has spi 0xD00FF993 and conn_i d 0l i f et i me of 3600 secondsl i f et i me of 4608000 ki l obytesout bound SA f r om 136. 1. 123. 3 t o 136. 1. 123. 12 ( f / i ) 0/ 0( pr oxy 136. 1. 23. 0 t o 136. 1. 121. 0)has spi 0xD7A26A and conn_i d 0l i f et i me of 3600 secondsl i f et i me of 4608000 ki l obytes

Note

The last packet finished the QM negotiations. Now both parties may encrypt andexchange traffic.

I SAKMP: ( 1004) : sendi ng packet t o 136. 1. 123. 12 my_por t 500 peer _por t 500( I ) QM_I DLEI SAKMP: ( 1004) : Sendi ng an I KE I Pv4 Packet .I SAKMP: ( 1004) : del et i ng node 946616940 er r or FALSE r eason " No Er r or "I SAKMP: ( 1004) : Node 946616940, I nput = I KE_MESG_FROM_PEER, I KE_QM_EXCHI SAKMP: ( 1004) : Ol d St at e = I KE_QM_I _QM1 New St at e =I KE_QM_PHASE2_COMPLETE


43/333




2.2 IPsec and NAT Interaction in ASA Firewall Enable NAT in the ASA firewall and translate all inside addresses using

the IP address of the outside interface. Ensure the VPN traffic is not affected by this configuration.

Configuration

Note

ASA firewall code applies NAT translation before IPsec encryption. Thus, withNAT enabled you might find that traffic is not matching your proxy-ID access-listbecause of having source IP addresses translated. At it has been discussed inthe ASA Firewall section of the workbook, the solution is to use the NATexemption rules. Alternatively, you may disable NAT control, if it has been

enabled, and configure policy NAT rules so that only the relevant traffic istranslated.

The same NAT and IPSec order of operations takes place for Cisco IOS.However, in Cisco IOS you may simply configure the NAT access-lists so thatVPN traffic is not translated.

ASA1: nat - cont r ol!! NAT for inside users !nat ( i nsi de) 1 0 0gl obal ( out si de) 1 i nt er f ace

!! Exemption access-list !access- l i st EXEMPT per mi t i p 136. 1. 121. 0 255. 255. 255. 0 136. 1. 23. 0255. 255. 255. 0nat ( i nsi de) 0 access- l i st EXEMPT


44/333




Verification

Note

Telnet from R1 to R3 this traffic is not VPN protected. Make sure you see a

translation entry for the connection.

Rack1R1#telnet 136.1.123.3 Tr yi ng 136. 1. 123. 3 . . . Open

User Access Ver i f i cat i on

Passwor d:R3>Rack1AS>12[ Resumi ng connect i on 12 t o asa1 . . . ]

Rack1ASA1(config)# show x1 i n use, 10 most usedPAT Gl obal 136. 1. 123. 12( 1024) Local 136. 1. 121. 1( 11072)

Note

Now initiate some traffic between the protected subnets. Make sure the trafficmakes it through and no additional NAT translation entries are being created.

Rack1R1#ping 136.1.23.2

Type escape sequence t o abor t .Sendi ng 5, 100- byt e I CMP Echos t o 136. 1. 23. 2, t i meout i s 2 seconds:. ! ! ! !Success r at e i s 80 per cent ( 4/ 5) , r ound- t r i p mi n/ avg/ max = 96/ 165/ 189ms

Rack1R1#telnet 136.1.23.2 Tr yi ng 136. 1. 23. 2 . . . Open

User Access Ver i f i cat i on

Passwor d:R2>

Rack1ASA1(config)# show xlate0 i n use, 10 most used


45/333




Note

Even though there are not xlates created, we still see the connection across thefirewall.

Rack1ASA1(config)# show connection5 i n use, 43 most used

TCP out 136. 1. 23. 2: 23 i n 136. 1. 121. 1: 11073 i dl e 0: 00: 52 byt es 111 f l agsUI O


46/333




2.3 Authentication using Digital Signatures Reconfigure the L2L tunnel between ASA1 and R3 to use digital

certificates for ISAKMP authentication. Use the following URL for CA enrollment:

http://10.0.0.100:80/certsrv/mscep/mscep.dll and use the domain nameINE.com for certificate DNs

Configuration

Note

Authentication using pre-shared keys does not scale well for networks with manyIPsec tunnels, as it requires setting a separate key for every pair of devices. Onemay use wilcard-preshared keys to resolve this issue. Wildcard PSKs are

configured using the netmask based address scope, e.g. crypto isakmp keyCISCO address 150.1.0.0 255.255.0 will use PSK value of CISCO for thewhole subnet 150.1.0.0/16. However, this solution is less secure, as it reuses thesame key for multiple endpoints.

PKI or Public Key Infrastructure of fers a scalable way to authenticate allcommunicating endpoints in secure manner. Every router that needs toparticipate in IPsec VPN is issued a digital certificate by the Certification

Authority (CA). A typical digital certificate binds the identity information of a router(e.g. hostname or IP address) to the routers public key by means of CA digitalsignature. This involves the use of public key cryptography algorithms, such as

RSA. Based on this binding, any device that trusts the CA certificate, i.e. truststhe signature of the CA, would accept the identity inside the signed certificate.Next, in order to authenticate the side that presents the digital certificate, thechallenging party may ask the responder to encrypt a random piece ofinformation using the responders private key. Then, the challenge information isdecrypted using the public key from the certificate. If the original challenge andthe decrypted challenge are the same, then the identity of the remote party hasbeen established and validated.

The above procedure allows all routers that trust the same CA to authenticateeach other. More than that, since certificates contain information about endpoints

identity, no communicating party may ever deny that it has participated ininformation exchange, even if they try.

The certificate-based authentication is also called digital-signature or RSA-signature based, as RSA is the most common underlying public-key encryptionalgorithm.


47/333




To configure the authentication based on digital signatures, perform the followingsteps:

1) Generate RSA private and public keys in every router or firewall that shouldparticipate in VPN. This is needed to create a key that uniquely identifies the

router. Notice that IOS routers and ASA firewall require you to configure adomain-name before generating the RSA keys. (Notice that by generating thekeys you automatically activate SSH protocol support in IOS router). Thecommand to create the keys is crypto key generate rsa .

2) Configure the CA trustpoint in routers and firewalls. The devices use the CAtrustpoint to enroll with the CA for certificates and validate certificates presentedby peers. You define a trustpoint using the command crypto ca trustpoint in both IOS routers and ASA firewalls. Cisco devices use HTTP-based SCEPprotocol to interact with CA over the network and thus you must define the URLto access the CA. The command to define an URL is enrollment url under

the CA trustpoint configuration mode. By using SCEP, the devices may requestCA digital certificate (which is often self-signed) and store it locally. Many CAsdefine CRL (Certificate Revocation List) URL to allow the endpoints to poll theCA for the list of invalidated (revoked) certificates. If your CA does not supportthis functionality or you dont need it, specify the crl optional commandwhen configuring a trustpoint.

3) After you retrieved the CA certificate, you must authenticate it i.e. tell thesystem that this certificate is trusted and could be used for validating othercertificates. Use the command crypto ca authenticate for certificateretrieval and authentication. Before you authenticate the CA trustpoint, makesure the time is coordinated between the CA and the router. Most often, you maywant to use NTP protocol to accomplish this.

4) After you have authenticated the CA certificate you may enroll with the CAusing the command crypto ca enroll . When you issue this command, therouter or the firewall will send a request to the CA using SCEP protocol. Therequest contains the public key of the router and convenient identity information,such as routers hostname and domain name. Depending on the CAconfiguration, the certificate request will be kept pending until the administratorapproves it, or the certificate could be issued automatically. In our topology, theCA is configured for automatic certificate issuing. You may want to use thecommand debug crypto pki transactions if you are running into anyissues enrolling with the CA.

5) After you have obtained the certificate, you may configure ISAKMP policy forauthentication based on RSA signatures. For ASA firewall, you should alsoconfigure the respective tunnel-group to use the particular trustpoint for certificatevalidation:


48/333




t unnel - gr oup i psec- at t r i but est r us t - poi nt I E1

If you want the ASA firewall to be able to initiate the tunnel using the certificate-

based authentication, you need to add the command similar to the following inyour configuration:

cr ypt o map VPN 10 set t r ust poi nt I E1

replacing the trustpoint name with the ID needed in the configuration. This isneeded because by default there is no tunnel-group associated with outgoingconnections, and the authentication attributes could not be properly defined.

6) All other IPSec settings remain the same. Only the ISAKMP (Phase 1) isaffected by certificate configuration.

Finally, remember to permit SCEP (transported in HTTP) and NTP protocolacross the firewall, if the scenario needs this. In our case, we configure theaccess-list in the ASA to permit R3 communicating with the CA server.

ASA1:!! Trustpoint configuration !crypt o ca t r ust poi nt I E1

enr ol l ment ur l ht t p: / / 10. 0. 0. 100: 80/ cer t sr v/ mscep/ mscep. dl lcr l opt i onal

!nt p server 10. 0. 0. 100!cr ypt o ca aut hent i cat e I E1domai n- name I NE. comcr ypt o key generat e r sa gener al - keys modul us 512crypt o ca enr ol l I E1

!! L2L VPN. ISAKMP Configuration !cr ypt o i sakmp pol i cy 10

aut hent i cat i on rsa- si g

encr ypt i on 3deshash md5!cr ypt o i sakmp

Documents

Iewb Sc Vol i v5.wewew.3.VPN.005