Cisco Security Troubleshooting: Part II - Virtual Private Networks
Abstract
This is the second in a three-part series of white papers that examine the challenge of implementing network security on equipment from Cisco Systems while maintaining the connectivity requirements of the business or enterprise. The focus on this paper is primarily on the use of CLI debug and show commands. It will also examine three primary VPN implementation areas: 1) Site-to-Site (LAN-to-LAN) with IPSec; 2) Remote Access with IPSec; and 3) Remote Access with SSL. To a lesser extent the ASDM Monitoring area is also discussed. As with any troubleshooting, the most effective use of any trace or debug tool is realized by a thorough knowledge of the operation of the protocols used for VPN session establishment.
Sample
IPSec VPNs
Before we illustrate the effective use of IPSec debugging tools, we need to discuss some basic principles of operation. These are enumerated below.
1. IPSec VPN sessions undergo two phases of negotiation which result in two
types of Security Associations
(SAs):
a) ISAKMP1 SA (IKE2 Phase I result)
b) 2 @ IPSec SAs - 1 for inbound traffic, (IKE Phase II result)
1 for outbound traffic
2. The negotiations above "begin" when "interesting" traffic arrives at a router or firewall configured for encryption. By "interesting," we mean a packet matching what is usually specified in permit statements in ACLs associated with a configured crypto map.
3. The device into which the "interesting" packet arrives starts the negotiation process; hence it is commonly known as the "Initiator." The router or firewall which is the IPSec partner or "peer" is known as the "Responder."
4. The initiator will send ALL configured Phase I proposals and Phase II proposals configured specifically for the peer device. As a result, when possible, debugs should be run on the device which is the responder. This is the approach that will be taken in this paper.
Phase I Debugging - Policy Mismatch
In the previous scenario, we initiated a VPN from the IOS Router to the ASA Firewall by starting an HTTP connection from the Site1-PC (10.20.10.10) to the Admin-PC (10.10.10.10). The output below shows what happens when there is no match between all of the policies presented by the router (the Initiator, in this example) to the ASA (the Responder). The syntax of the appropriate debug command for this is "debug crypto isakmp <level>" where 1 = level = 255, and the default level = 1. Three debugs are shown below for comparison.
Phase I Debugging - Preshared Key Mismatch
Although the previous section would seem to suggest that debug crypto isakmp is not useful at its default level of 1, that level of debugging, as shown below, is able to pick up a mismatch between the preshared keys between the IOS Router and the ASA Firewall.
Phase II Debugging - Transform Set Mismatch
Unlike ISAKMP Phase I where ALL configured proposals are presented by the Initiator to the Responder, regardless of peer, the Phase II transform sets are specifically referenced in a set of crypto map entries for a particular peer. As with the Phase I debug traces, level 254 must be chosen in order to see the presented alternative transform sets. The output from the ASA CLI debug crypto isakmp 254 command is shown on the next page. For the sake of clarity, the output for IKE Phase I has been omitted.
Phase II Debugging - Crypto ACL Mismatch
This final example of IPSec Site-to-Site debugging illustrates the mismatch of the configured crypto access lists (also referred to as proxies). As can be seen from this trace, a level value as low as 2 sufficient for troubleshooting this problem.
Phase II Failure with Phase I Success as Seen in ASDM
While the ASDM GUI does not have the ability of being used to actively debug IPSec VPN tunnel establishment failures, the screenshot on the next page shows the result of an ASA initiating a tunnel where Phase I succeeds, but Phase II fails. Note the IKE: 1 item under the VPN Tunnels section while next to it is IPSec: 0 indicating the Phase II failure.
Remote Access VPNs - Misconfigured Group Name
Unlike the Site-to-Site VPNs examined previously, Remote Access IPSec VPNs use a logical name (vs. an IP Address) to identify the tunnel-group. With this in mind, a trace is shown below for a situation where the configured Group Name on the client software does not match any configured Group Name on the ASA. Level 2 is chosen here because, surprisingly, the misconfigured Group Name on the client is not shown at any higher level.
Remote Access VPNs - Misconfigured Preshared Key
With this same level of debugging, a trace of a misconfigured preshared key is clearly shown. Note also that in this case the Group Name displayed is NOT the DefaultRAGroup but rather the configured one.
Related Courses
IINS - Implementing Cisco IOS Network Security
SNRS - Securing Networks with Cisco Routers & Switches v3.0
SNAF - Securing Networks with ASA Fundamentals
SNAA - Securing Networks with ASA Advanced
MARS - Cisco Security Monitoring, Analysis, and Response System v3.0
CANAC - Implementing NAC Appliance (formerly Cisco Clean Access)
Related White Papers
Understanding the Basic Configuration of the Adaptive Security Appliance (ASA)
Cisco Security Troubleshooting: Part I - Connectivity Through ASA or PIX Firewalls
RSS