All Cisco-Network Study Notes: Basic LAN-to-LAN Troubleshooting

Basic LAN-to-LAN Troubleshooting

A basic LAN-to-LAN tunnel is the simplest form of IPsec tunnel in which private networks behind the tunnel end points communicate across the tunnel.

Because this is the simplest form of IPsec Tunnel, the troubleshooting steps that are described in the sections that follow form the foundation knowledge required for the subsequent sections of this book. Before going into the details of troubleshooting steps for a basic LAN-to-LAN tunnel, it's extremely important to understand a successful tunnel establishment process and understand the debug information. This section starts with this discussion. Then the section goes into the details of tunnel establishment failure issues, and issues with sending traffic across the tunnel. The following section is organized as follows:

Successful LAN-to-LAN Tunnel Establishment Process

Before looking into the details of configuration and troubleshooting steps for a LAN-to-LAN tunnel, it is important to understand the sequence of events that occurs when traffic needs to pass through an IPsec tunnel in both inbound and outbound directions. The list that follows explains both inbound and outbound IPsec traffic through the router configured with IPsec:

For outbound IPsec traffic (inside to outside)
1. If using IPsec, check for the input access-list and then if allowed, decrypt the IPsec packets; otherwise drop the packets.
2. Check the input access-list for decrypted traffic (Beginning with Version 12.3(8), this step is omitted).
3. Check policy routing and then routing.
4. Perform NAT and Crypto (check map and mark for encryption).
5. Perform Outbound access control list (ACL) checking after Network Address Translation (NAT).
6. If allowed and marked for encryption by the interesting traffic ACL, main/aggressive Mode starts to establish Phase I with a bidirectional IKE SA.
7. Then Quick mode, which is Phase II negotiation, triggers and establishes IPsec SA, which is unidirectional; so it needs two SAs for both traffic directions.
8. Then either with AH or ESP or both sides, send actual data over the tunnel.
For Inbound IPsec traffic (Outside to Inside)

The sequence of events is the same as for outbound except that NAT occurs before policy routing or routing

Now, before going into the details of debug command output, go through a packet flow. Take an example based on the LAN-to-LAN tunnel that has just been configured. Assume that host 10.1.1.10 on the LAN segment of the Dhaka router wants to communicate with a host 10.1.2.10 that is on the LAN segment of the Doha router. Also, assume that the connection is initiated from Dhaka to Doha. The following sequence of events takes place:

1.	Based on the route on Host with IP address 10.1.1.10, an IP packet is sent to the Dhaka router. Dhaka router will consult its routing table and based on its default route, it will forward the packet via the Ethernet 1/0 interface.

2.	Before the packet is transmitted out of this interface, as there is a crypto-map applied, the Dhaka router will consult the SPD to see if there is a policy match for this packet (Source:10.1.1.10, Destination: 10.1.2.1). The SPD is built based on the access-list defined for interesting traffic. As the access-list 101 includes the packet's source and destination address, the router will decide that the traffic needs to be IPsec protected.
3.	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.
4.	IKE phase 1 negotiation is performed between the peers to establish the ISAKMP SA. The IKE phase negotiation is based on the ISAKMP policy. The establishment of ISAKMP can be verified with the show crypto isakmp sa command.
5.	Upon successful establishment of ISAKMP SA (Phase I), IPsec SA negotiation takes place. This can be verified with the show crypto ipsec sa command.
6.	After the IKE and IPsec SA are established, the original IP packet is encapsulated in IPsec tunnel mode using an ESP header, as this is what is configured in the transform-set. As Tunnel mode is used, a new IP header is added with the source IP address of 20.1.1.1 and destination IP address of 30.1.1.1. This packet is handed back to the usual IP forwarding routines to process the packet.
7.	The encrypted IPsec packet arrives into the Doha router, and the presence of an IPsec header in the IP packet indicates that it must be decrypted on the Doha router.
8.	The outer header destination address (30.1.1.1), the security protocol ESP, and the SPI in the ESP header are used as indexes into the SADB to find the SA for this packet.
9.	Once there is a hit in the SADB, the packet is authenticated and then decrypted using the proper transforms.
10.	Once the packet is decrypted, the 5-tuple check of the policy corresponding to the packet is checked. The 5-tuple is the source address of the inner IP header, destination address of the inner IP header, source port of the inner header, destination port of the inner header, and the IP protocol ID. Querying the SPD validates the 5-tuple. The lifetime counter in bytes is decremented and the anti-replay window is updated. The packet would have been dropped in the following cases: a. The SA was not in the SADB. b. The sequence number was on the left of the sliding window; therefore, the packet failed the replay check. c. Authentication failed. d. The length was incorrect. e. The SA lifetime had expired.

11.	If all goes well in the previous step, the packet is passed to the usual IP packet processing on the hub router

Once you are comfortable with the packet paths, and can read and understand the debug output, go through the next few sections to find how to troubleshoot the IPsec VPN issues.