Unlike LAN-to-LAN tunnel, with the Remote Access VPN, you can immediately determine if the tunnel is establishing or not. When the tunnel is successfully established, this message displays: "You are connected."
The Remote Access VPN tunnel establishment may fail for various reasons. Using a systematic approach is the best way to check various possibilities and correct them as you analyze the best approach to troubleshooting Remote Access VPN issues. Work through the following steps to correct the Remote Access VPN tunnel establishment failure:
Step 1. Check the connectivity between the VPN Client and the Concentrator.
From the VPN client PC, ping to the public interface IP addresses of the VPN Concentrator. If you cannot ping, work through the following steps to correct the problem:
(a). Be sure that the default gateway is defined on the VPN client host, and that the host can ping to the default gateway IP address.
(b). Go to the VPN Concentrator GUI, and verify that you have a default gateway defined for the Concentrator. If none is defined, define one. Otherwise, go to Administration > Ping, and ping to the default gateway of the Concentrator.
(c). If both the VPN Concentrator and VPN client can ping each other, then ensure that ISKMP packets are allowed by a firewall that is between them. This can be done by performing Traceroute using a UDP probe instead of the ICMP ping to the IP address of the other Concentrator. To perform this action, go to Administration > Traceroute page on your VPN Concentrator.
Step 2. Be sure that IKE packets are being exchanged between the VPN Client and the Concentrator.
Once connectivity is verified with the previous step, check the event logs on both VPN client and Concentrator. See the "Diagnostic Commands and Tools" section for details on how to use the Event Log features on both VPN Client and the Concentrator. If the IKE packets are being exchanged, you should see messages similar to the one shown in examples 8-6 on the VPN Client.
Example 8-6. IKE Messages Shown on VPN Client
121 20:04:56.778 06/20/05 Sev=Info/4IKE/0x63000013
SENDING >>> ISAKMP OAK INFO (NOTIFY:INVALID_HASH_INFO) to 172.16.172.119
135 20:12:54.580 06/20/05 Sev=Info/4IKE/0x63000014
RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID, VID, VID, VID) from
172.16.172.119
Example 8-7 shows the IKE packets seen on the VPN concentrator.
Example 8-7. IKE Messages on VPN Concentrator
1 04/07/2005 20:04:16.640 SEV=8 IKEDBG/0 RPT=2955 192.168.1.100
RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + KE (4) + NONCE (10) + ID (5) +
VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) ... total length : 561
If you do not see the IKE packets on the VPN client, then the problem is on the VPN client. You may need to stop and restart the cvpnd service with net stop cvpnd and net start cvpnd, or you may need to reboot the VPN client PC. As a last resort you may end up re-installing the VPN client software. If you see the IKE packets on VPN client but do not see the IKE packets on the VPN 3000 Concentrator, go to the next step.
Step 3. Be sure the firewall between the VPN Client and Concentrator allows ISKMP (UDP/500) packets.
If you do not see the IKE packets on VPN 3000 Concentrator, check to see if you have a firewall between the VPN client and Concentrator. If you do, be sure that ISKMP (UDP/500) packets are allowed through the firewall. Otherwise, IKE packets will be dropped by the firewall. If you have a NAT device between the VPN client and Concentrator, and you have NAT-T configured, then you need to allow UDP/4500 for the NAT-T. If a firewall between blocks the UDP/500 packets, you will see the event log on VPN Client as shown in Example 8-8.
Example 8-8. VPN Client Log When the NAT-T Fails Due to UDP/4500 Packets Block
! Received Aggressive Mode Message 2
595 20:47:46.335 06/21/05 Sev=Info/4IKE/0x63000014
RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID(Unity), VID(Xauth), VID(dpd),
VID(Nat-T), NAT-D, NAT-D, VID(Frag), VID(?), VID(?)) from 172.16.172.119
! Sending Aggressive Mode Message 3 to the VPN Concentrator. Here it shows NAT-T
! Negotiated UDP Port 4500
603 20:47:46.355 06/21/05 Sev=Info/4IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NAT-D, NAT-D,
VID(?), VID(Unity)) to 172.16.172.119
! The Client Receives the Retransmissions
608 20:47:54.327 06/21/05 Sev=Info/5IKE/0x6300002F
Received ISAKMP packet: peer = 172.16.172.119
609 20:47:54.327 06/21/05 Sev=Info/4IKE/0x63000014
RECEIVING <<< ISAKMP OAK AG (Retransmission) from 172.16.172.119
! The Client Retransmits AM MSG 2
610 20:47:54.327 06/21/05 Sev=Info/4IKE/0x63000021
Retransmitting last packet
611 20:47:54.327 06/21/05 Sev=Info/4IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(Retransmission) to 172.16.172.119
! The Client Receives the Unencrypted Delete Message
625 20:48:18.321 06/21/05 Sev=Warning/3IKE/0xA3000058
Received CAlformed message or negotiation no longer active (message id: 0xB7381790)
! The Client Sends It's Own Delete Message
636 20:49:18.007 06/21/05 Sev=Info/4IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, DWR) to 199.246.40.12
On the VPN Concentrator, you will not see any re-transmission. Instead, you will see the messages shown in Example 8-9.
Example 8-9. VPN Concentrator Log When the NAT-T Fails Due to UDP/4500 Packets Block
333 05/06/2005 09:55:03.860 SEV=7 IKEDBG/65 RPT=1 172.16.172.1190
Group [mygrou]
! FSM ErrorTime Out Waiting for AM MSG 3 is shown below
IKE AM Responder FSM error history (struct &0x7ea8590)
AM_DONE, EV_ERROR_CONT
AM_DONE, EV_ERROR
AM_WAIT_MSG3, EV_TIMEOUT
AM_WAIT_MSG3, NullEvent
! Sending a Delete MSG After the Time Out. You will not see Retransmissions. The
! Concentrator Resends AM MSG 2 Three Times at 8 Second Intervals
338 05/06/2005 09:55:03.860 SEV=8 IKEDBG/81 RPT=7 172.16.172.1190
SENDING Message (msgid=d0257b9c) with payloads :
HDR + HASH (8) + DELETE (12)
total length : 76
If IPsec over TCP is configured, the default port you need to allow is TCP/10000. If another port is used, you need to allow that specific port. Additionally, you need to allow ESP (IP/50) to enable the tunneled traffic.
Step 4. Be sure that the filter applied on the public interface allows ISKMP (UDP/500) and ESP (IP/50) traffic.
If the firewall has the necessary ports open, check to see that the filter is applied on the public interface of the concentrator. By default, the public filter allows all the necessary ports for the IKE message. However, if the filter is not public or if you have customized the filter, be sure to have the IPSEC-ESP In (forward/in) rule under "Current Rules in Filter" on your filter.
If NAT-T is configured, you must assign the NAT-T In and NAT-T Out rules to that filter, applied and active on the public interface.
Step 5. IKE Proposal Parameters mismatch between the VPN Client and VPN Concentrator.
In Aggressive Mode Message 1, the VPN client sends a list of supported proposals to the VPN Concentrator. On the concentrator, you need to have at least one of the proposals sent by the VPN client active. The concentrator will match based on order in the active proposal list. To verify the proposals on the VPN Concentrator, go to Configuration > Tunneling and Security > IPsec > IKE Proposals.
Step 6. Check for Group Authentication Failure.
Upon receiving the IKE proposal, the VPN concentrator first finds the group name and authenticates the group. Example 8-10 shows a successful group authentication in VPN 3000 Concentrator.
Example 8-10. Successful Group Authentication on VPN 3000 Concentrator
15 04/07/2005 20:04:16.640 SEV=9 IKEDBG/23 RPT=42 192.168.1.100
Starting group lookup for peer 192.168.1.100
39 04/12/2005 01:54:03.230 SEV=6 AUTH/41 RPT=26 192.168.1.100
! The following line shows the group authentication is successful.
Authentication successful: handle = 17, server = Internal, group = mygroup
40 04/07/2005 20:12:14.500 SEV=7 IKEDBG/0 RPT=2984 192.168.1.100
Group [mygroup]
Found Phase 1 Group (mygroup)
Table 8-6 shows some of the most common group-authentication problems and how to resolve them.
Table 8-6. Common Group Authentication Issues and Resolution On VPN Concentrators Parameters MisMatch
Client Error Message
VPN Concentrator Error message
How to resolve
Group Name MisMatch
GI VPN start callback failed
"CM_PEER_NOT_RESPONDING"
(16h).
No Group found
Matching mygroupo
for Pre-shared key
peer 192.168.1.100
Check group name. If missing configure it in VPN Concentrator, or if it exists, correct the group name in client configuration.
Group Password MisMatch
Hash verification failed...
May be configured with
invalid group password.
Group [mygroup]
Received non-routine
Notify message:
Invalid hash info (23)
Correct the group password on the concentrator or specify it correctly on the VPN client.
Group Lock Configuration
GI VPN start callback failed
"CM_PEER_NOT_RESPONDING"
(16h).
User (U1) not member
of group (test_grp),
authentication
failed.
If the Group Lock feature isenabled on the Group test_grp, then the User must be part of test_grp to connect.
Step 7. Verify that User Authentication (X-Auth) is successful.
Once group authentication is successful, user authentication occurs if it is configured on the VPN Concentrator. If the user authentication fails at this stage, the VPN tunnel will not be built up. Note that user authentication can be performed either locally on the VPN Concentrator or using an external AAA server. If the authentication is configured with an AAA Server, refer to Chapter 12, "Troubleshooting AAA on VPN 3000 Series Concentrator." If authentication is performed locally on the VPN Concentrator, turn on XAuth Verbose level to high on the VPN Client and set the level of logging for AUTH, AUTH, and AUTHDBG to 1-9 following the procedure explained in the "Diagnostic Commands and Tools" section. The same section also explains how to interpret the event log message. Example 8-11 shows an example of a successful user authentication on the VPN 3000 Concentrators Event Log.
Example 8-11. A Successful User Authentication Event Log on VPN Concentrator
116 04/12/2005 02:08:52.970 SEV=6 AUTH/4 RPT=9 192.168.1.100
Authentication successful: handle = 19, server = Internal, user = vpn3k
165 04/12/2005 02:08:53.170 SEV=7 IKEDBG/14 RPT=20 192.168.1.100
Group [mygroup] User [vpn3k] Authentication configured for Internal
171 04/12/2005 02:08:53.170 SEV=4 IKE/52 RPT=9 192.168.1.100
Group [mygroup] User [vpn3k] User (vpn3k) authenticated.
Step 8. If authentication fails, be sure the appropriate authentication server is set by going into Configuration > System > Servers > Authentication servers. To ensure that the specific group configuration for the authentication server does not override the server configuration setup under System, go into Configuration > User Management > Groups > Authentication Servers, and check to see if the VPN Concentrator is configured correctly to assign the address.
If the VPN client can connect to the VPN Concentrator but is unable to get the IP address, check the log on both client and Concentrator to find the cause of the problem. Example 8-12 presents the Event Log on the VPN Concentrator that shows it is unable to assign the IP address to the VPN client.
Example 8-12. Event Log on the VPN Concentrator Shows That it Is Unable to Assign an IP Address to the VPN Client
! The following line indicates that VPN Concentrator is unable to allocate an IP
! address
Group [mygroup] User [U1] IKE received response of type [FAILED] to a request from
the IP address utility
. . .
204 04/11/2005 00:29:42.500 SEV=5 IKE/132 RPT=2 192.168.1.100
! The following line reaffirms that the obtaining of IP address is indeed
! unsuccessful.
Group [mygroup] User [U1] Cannot obtain an IP address for remote peer
Typically, the address assignment problem occurs due to misconfiguration. But there also can be other reasons for the VPN Concentrator being unable to assign an IP address to the VPN Client. The list that follows outlines procedures to deal with the most common problems:
- Be sure that the IP address Pool is configured To allocate an IP address from a local pool, be sure that the pool is configured under Configuration > System > Address Management > Pools. Be sure that you have a correct pool defined, and if you do not, define one. On the other hand, if you want to assign the address from an AAA server, define the pool on the AAA server.
- Be sure Method of Assignment is selected Merely defining a pool is sufficient unless you check the correct box under Configuration > System > Address Management > Assignment page. This is one of the most common mistakes an engineer makes.
- Be sure you are not reaching to max of address from address pool If you are having address assignment issues with a specific client intermittently, or after a certain number of host connection, chances are that your Concentrator is hitting the max on the address pool. Consider redefining the address pool to add additional addresses to the pool.
Figure 8-7 shows how to create the IP address pool and apply it on a VPN 3000 Concentrator.