Tunnel Not Established
If end users complain that they are unable to send any traffic across the tunnel, you should first check whether the LAN-to-LAN tunnel is established. You can verify this by going into Administration > Administer Sessions page and looking under LAN-to-LAN Sessions. If you do not see any sessions, perform a ping on the other Concentrator's private interface IP address and see if you can ping and if the tunnel shows that it is established. If you still have issues, you need to troubleshoot the issue further with the steps outlined in this section. But, before you look into the possibilities of why the tunnel is not being built up, you need to understand the Event Log messages for a good LAN-to-LAN tunnel establishment process. Table 8-3 shows the highlights of the sequence of events involved in LAN-to-LAN tunnel establishment on both initiator and responder sides for Main Mode negotiation.
Table 8-3. Event Log of Both Initiator and Responder for a Successful LAN-to-LAN Tunnel Phase I (Main Mode) Initiator
Pkt#
Responder
9 04/10/2005 22:48:24.280 SEV=8 IKEDBG/0
RPT=4 172.16.172.50
SENDING Message (msgid=0) with payloads :
! This is where the SA payload is sent
! by the Initiator
HDR + SA (1) + NONE (0) ... total length : 84
1
2
1 04/10/2005 10:50:03.820 SEV=8 IKEDBG/0
RPT=1 172.16.172.119
SENDING Message (msgid=0) with payloads :
! This is where the SA payload is sent
! by the responder
HDR + SA (1) + NONE (0) ... total length : 84
27 04/10/2005 22:48:24.490 SEV=8 IKEDBG/0
RPT=10 172.16.172.50
SENDING Message (msgid=0) with payloads :
! This is the 3rd packet and sent by
! the initiator with DH key and the
! Nounce
HDR + KE (4) + NONCE (10) + VENDOR (13) +
VENDOR (13) + VENDOR (13) + VENDOR (13)
+ NONE (0) ... total length : 256
3
4
10 04/10/2005 10:50:04.020 SEV=8 IKEDBG/0
RPT=7 172.16.172.119
SENDING Message (msgid=0) with payloads :
! This is the 4th packet sent by the
! Responder with DH key and the Nounce
HDR + KE (4) + NONCE (10) + VENDOR (13) +
VENDOR (13) + VENDOR (13) + VENDOR (13)
+ NONE (0) ... total length : 256
54 04/10/2005 22:48:24.700 SEV=8 IKEDBG/0
RPT=18 172.16.172.50
SENDING Message (msgid=0) with payloads :
! This is the ID payload and the 5th
! packet sent by the Initiator
HDR + ID (5) + HASH (8) + IOS KEEPALIVE (14)
+ VENDOR (13) + NONE (0) ... total length
: 92
5
6
41 04/10/2005 10:50:04.240 SEV=8 IKEDBG/0
RPT=14 172.16.172.119
SENDING Message (msgid=0) with payloads :
! This is the ID payload and the 6th
! packet sent by the Responder
HDR + ID (5) + HASH (8) + IOS KEEPALIVE (14)
+ VENDOR (13) + NONE (0) ... total length
: 92
Table 8-4 shows the sequence of events for a LAN-to-LAN tunnel on both initiator and responder sides for Quick Mode negotiation (only highlights are shown).
Table 8-4. Event Log of Both Initiator and Responder for a Successful LAN-to-LAN Tunnel Phase II (Quick Mode) Initiator
Pkt#
Responder
124 04/10/2005 22:48:24.800 SEV=8 IKEDBG/0
RPT=29 172.16.172.50
SENDING Message (msgid=70633ee2) with
payloads :
! This is the IPSEC Phase II proposal
! sent by the Initiator, and the first
! packet of Quick Mode negotiation.
HDR + HASH (8) + SA (1) + NONCE (10) +
ID (5) + ID (5) + NOTIFY (11) + NONE (0)
... total length : 180
1
2
95 04/10/2005 10:50:04.450 SEV=8 IKEDBG/0
RPT=34 172.16.172.119
SENDING Message (msgid=70633ee2) with
payloads :
! This is the 2nd packet by the
! Responder in response to the first
! packet by the Initiator
HDR + HASH (8) + SA (1) + NONCE (10) +
ID (5) + ID (5) + NONE (0) ...
total length : 152
142 04/10/2005 22:48:24.820 SEV=8 IKEDBG/0
RPT=36 172.16.172.50
SENDING Message (msgid=70633ee2) with
payloads :
! This is the 3rd and the final packet
! by the Initiator before the Quick
! Mode is established.
HDR + HASH (8) + NONE (0) ... total
length : 72
3
136 04/10/2005 10:50:04.470 SEV=8 IKEDBG/0
RPT=35 172.16.172.119
RECEIVED Message (msgid=70633ee2) with
payloads :
HDR + HASH (8) + NONE (0) ... total
length : 48
Now that you have become familiar with the debug messages of a normal LAN-to-LAN tunnel build-up process on VPN 3000 series Concentrator, work through the following steps to troubleshoot the issue with the tunnel establishment process:
Step 1. Check the connectivity between the Concentrators.
On the VPN Concentrator, go to Administration > Ping, and ping to the public interface IP address of the other Concentrator, and see if you receive a response. If you do not receive a response, work through the following steps to correct the problem:
(a). Check to see if you have a default gateway set up for the Concentrator by going to Configuration > System > IP Routing > Default Gateways.
(b). Ping to the Gateway IP address, and see if you get any response. If the Gateway responds, the problem may be with a device in transit dropping the packet reaching to the other Concentrator.
(c). Perform Traceroute to the IP address of the other Concentrator by going into the Administration > Traceroute page on your VPN Concentrator and find out where the packets are being dropped.
(d). Your ISP may be blocking ICMP packets, and if so, you will not be able to ping. Under this circumstance, you can send a UDP probe instead of ICMP for the traceroute. This process is discussed in the steps that follow.
(e). If the ping and traceroute both succeed or both fail due to ISP blocking of the ICMP protocol, perform Traceroute using UDP probes on port 500 instead of ICMP pings by going into Administration > Traceroute page. This will ensure that the ISKMP is allowed across the path between VPN 3000 Concentrators. If traceroute fails, talk to your ISP to correct the problem.
Step 2. Check the configuration on both sides of the tunnel.
Once you verify the IP connectivity between the Concentrators, verify the configuration of both Concentrators to see if they match each other. Everything should match except the network lists, which should be mirror images of each other.
Step 3. Verify that the Network Lists are configured correctly.
The Network List defines the interesting traffic of the LAN-to-LAN tunnel. Therefore, if the source and destination of a packet do not match the network list, an IPsec tunnel will not be initiated. Hence, you must ensure that Network Lists are defined correctly on both Concentrators. Pay close attention when you pass NATed traffic across the tunnel. When you configure NAT on the Concentrator to translate the private network, be sure to define the NATed IP rather than the actual private IP of the network in the Network Lists. For instance, if you have 10.1.0.0 NATed to 20.1.0.0, your Network List should include 20.1.0.0 instead of 10.1.0.0 as interesting traffic. It is an absolute requirement for Network Lists to be mirror images of each other on both Concentrators, so verify this configuration.
Step 4. Analyze the IKE packets on both Concentrators.
Once you verify the configuration, you need to analyze the IKE messages on both sides to find out the cause of failure for tunnel establishment. See the section in this chapter entitled "Diagnostic Commands and Tools" for details and follow the procedure explained under the subsection entitled "Debug Tool" to enable severity level 1-9 for IKE, IKEDBG, IPsec, IPsecDBG , AUTH, and AUTHDBG event classes. IKE and IKEDBG show the phase I information, IPsec and IPsecDBG show phase II, and AUTH/AUTHDBG shows the authentication-related messages. You should see the IKE- and IPsec-related messages on both of the Concentrators.
Download the "VPN3000 Concentrator Event Information" file from the following location and look for the message from the index. As of writing this book, the latest file name is "vpn3000events-4.7.Rel.zip".
http://www.cisco.com/cgi-bin/tablebuild.pl/vpn3000-3des
Step 5. Check the Filter on the public interface to allow ISKMP (UDP/500) and ESP (IP/50).
If you don't see the IKE packets, and if you have a custom filter or a misconfigured public filter applied on the public interface, you need to check the filter to ensure that the filter is allowing *IPSEC-ESP In (forward/in)* rule. If you do not have this rule under "Current Rules in Filter", you need to insert it there. Otherwise, the tunnel will not be established.
Step 6. Check Filter Configuration on the Public Interface.
If the firewall has the necessary ports open, check to see if the default public filter is applied on the public interface. If the filter is not applied, apply the filter, and if the filter is not the default public filter (but is a custom filter), be sure to allow UDP/500 for ISAKMP, and ESP packets.