VPN Client can Connect but Tunnel Is Not Passing Traffic
If the VPN Client is able to connect but unable to pass any traffic, work through the steps that follow to isolate and resolve the problem:
Step 1. Check Routing for Issues on the VPN Client PC.
If the tunnel is up and you still cannot send any traffic across the tunnel (this can be verified by checking the number of encrypts/decrypt packets in both client and VPN concentrator session logs), then most likely the problem is with client routing. Traffic originating from the laptop will be sent to the NIC, not through the VPN tunnel, if these circumstances apply: first, you connected your laptop earlier to the corporate network that allocated an IP address from a 10.1.0.0 network; and second, when you connect from home, the VPN 3K assigns you an IP address from the 10.1.0.0 network. This problem is very prominent in Microsoft Windows 95/98/NT.
To solve the problem, release the Dynamic Host Configuration Protocol (DHCP) that learned the IP address that you learned while you were connected to the LAN. Also, be sure that the default gateway is set up correctly. For more details on this specific issue, refer to the following link:
http://www.cisco.com/en/US/partner/products/sw/secursw/ps2308/products_tech_note09186a00801b7615.shtml
Step 2. Check for Routing on the VPN 3000 Concentrator.
If the Tunnel default gateway is defined, traffic will be sent out of the private interface of the Concentrator to the Tunnel Default Gateway (Router, PIX or any other device). The default gateway device should have a route for tunneled traffic pointing back to the VPN Concentrator private interface for the return traffic. The tunneled route can be defined based on the address pools, network extension mode, DHCP scope, and so on, based on your setup. You can use Reverse Route Injection (RRI) to redistribute tunneled routes into the non-tunneled network. If RRI is configured, you can use the Event Class IPDBG with Severity 1-8 to see routes dynamically added and removed from the Concentrator's Routing Table.
Step 3. Check to see if you have a Port Address Translation (PAT) device in the middle.
Once you verify the routing issue, if you are still unable to pass traffic, check to see if you have a PAT device in the middle, which may cause problems with the Encapsulating Security Payload (ESP). This can be verified by checking to see if the number packet encryption is increasing and that the number of the packet decryption is unchanged on the VPN Client. On the VPN Concentrator, if you look at the VPN Concentrator session statistics, you will see that there is no change in the number of packet encryptions or to the number of packet decryptions (see under Administration > Administer Sessions). If you have a NAT/PAT device, configure for NAT Transparency (NAT-T) or IPsec over Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) on both VPN 3000 Concentrator and on the VPN client as per the following link:
http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2284/products_tech_note09186a00800946af.shtml
On the VPN Concentrator, go to the Client Config tab of the Group to configure NAT-T or IPsec over TCP.
On the VPN Client Properties window, click on the Transport tab, and turn on NAT-T or IPSEC over TCP as shown in Figure 8-8.
Figure 8-8. NAT-T Configurations on VPN Client PC
[View full size image]
Step 4. Check maximum Transmission Unit (MTU) Issues.
If you have solved both the routing and PAT issues, and you can ping the resources in your corporate network, you still might be unable to use certain applications. If so, there is a very good chance that you are running into MTU issues across the path. You can verify this by pinging the application server with "l" and "f" options. l is used to define the number of bytes and f forces the packet not to be fragmented. Start with a 1500 bytes packet and reduce this number until you stop receiving the message "Packet needs to be fragmented but DF set," and get a ping reply.
Example 8-13 shows a sample ping test performed from a Windows machine to uncover any MTU issues.
Example 8-13. Sample Test To Identify MTU Issues
D:\>ping -f -l 1300 www.xyz.com
Pinging www.xyz.com [10.1.1.1] with 1300 bytes of data:
! The following lines indicate that 1300 bytes are too big along the path, so
! need to reset the MTU to some sCAller number on the VPN client.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 10.1.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
ApproxiCAte round trip times in milli-seconds:
Minimum = 0ms, CAximum = 0ms, Average = 0ms
D:\>ping -f -l 1250 www.xyz.com
Pinging www.xyz.com [10.1.1.1] with 1250 bytes of data:
! As the following lines indicate a reply, that means MTU can be set to this
! number minus 42 byeted for layer VII to layer IV header. So, ideally you
! should set the MTU on the client to be 1208 bytes.
Reply from 10.1.1.1: bytes=1250 time=51ms TTL=47
Reply from 10.1.1.1: bytes=1250 time=29ms TTL=47
Reply from 10.1.1.1: bytes=1250 time=32ms TTL=47
Reply from 10.1.1.1: bytes=1250 time=34ms TTL=47
Ping statistics for 10.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
ApproxiCAte round trip times in milli-seconds:
Minimum = 29ms, CAximum = 51ms, Average = 36ms
D:\>
To set up MTU on Cisco VPN client, follow Start > Programs > Cisco Systems VPN Client > Set MTU
A more detailed discussion on MTU can be found at the following location:
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
On the VPN 3000 Concentrator's public interface (where the VPN tunnel terminates), set the highest MTU value possible.
Step 5. Check for filters.
Three types of filters can affect the traffic going through the tunnel. These three filters are:
- Static filters applied to an interface
- Static filters applied to the user group
- Dynamic filters applied through the RADIUS Server
Work through the following steps to verify if the filter is causing the problem:
(a). Try to determine if traffic is indeed being dropped due to a filter by checking the counters on Monitoring > Statistics > Filtering. If the "Filtered" counter increases over a period of time, there is a very good chance that traffic is being dropped by the filter.
(b). Next, verify if the rule you have defined for the filter is working the way you intended. You can verify this by changing the Action of the rule to Drop and Log or Forward and Log by going into Configuration > Policy Management > Traffic Management > Rules > Add or Modify. Then enable the FilterDBG Event Class to Severity to Log 1-9. This will allow traffic affected by the rule to be logged to Syslog or to the Event Log.
(c). Check the Dynamic filter assigned by the RADIUS Server to see the rules being applied to a dynamic filter. To do so, go to the Monitoring > Dynamic Filters page. You can find details on Dynamic Filters in the detail screen of a specific user session on the Monitor > Session > Detail screen. Analyze the dynamic filter applied for the specific user and make sure the filter is accurate. If the filter is applied incorrectly, correct the configuration on the RADIUS Server.
Step 6. Check for Microsoft networking issues.
If you have a problem specific to Microsoft networking through the VPN tunnel, refer to the following link:
http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_tech_note09186a0080194b4a.shtml
VPN Client can connect but User Cannot Access the Internet
If you can access all resources on the private network of the other side of the tunnel (VPN 3000 Concentrator) but cannot access anything on the Internet, it could be because one of the following setups is not configured for tunneled traffic:
You are tunneling all traffic but do not have a Gateway on the VPN Concentrator for Internet-bound traffic On the VPN Concentrator, you can configure it to force all traffic to go through the tunnel from the VPN client. This ensures that the VPN client cannot make any connections to the Internet in clear text bypassing the IPsec tunnel. This provides extra security to the client while it is connected to the corporate network via tunnel. If you want the users from the VPN client under this setup to be able to connect to the Internet as well, you need to define a route for the Internet-bound traffic on the VPN Concentrator. The easiest solution is to define a tunnel default gateway to an Internal Router and have the internal router make the routing decision for the inside traffic versus Internet-bound traffic. The VPN Concentrator itself cannot be used to redirect the traffic on the public interface where the tunnel is terminated.
You do not have the Split tunneling configured If you do not want to send the Internet-bound traffic across the tunnel from the VPN Client, then be sure to configure split tunneling so that VPN client can make the connections to the Internet in clear text from the client PC itself. Note that with split tunneling, you are leaving the client PC vulnerable. Therefore, be sure to install a Personal Firewall or other host base Intrusion Detection Agent (for example CSAgent). To configure Split Tunneling, you first need to define a Network List that includes the networks that need to be tunneled. To define a network list, go to Configuration > Policy Management > Traffic Management > Network Lists. Then click on Add or Modify.
Once you have defined the Network List, you need to apply the Network List under the Client Config Tab of the Group Setup page. Under the Client Config tab, select only tunnel networks in the list. From the Split Tunneling Network List drop-down list, select the Network List defined earlier to allow going through the tunnel. No special configuration is required on the VPN Client.
VPN Client Can Connect But Users Cannot Access the Local LAN
If you cannot access any resources on the local LAN (for example, you are unable to print to the local printer) after building up the VPN tunnel, use the VPN client local LAN feature to allow local LAN traffic that is not encrypted. Go to the Client Config Tab of the Group Setup page. Under the Client Config tab, select the Tunnel everything button and check the Allow the networks in list to bypass the tunnel box. From the Split Tunneling Network List, select VPN Client Local LAN (Default).
To turn on Local LAN access, on the VPN Client GUI, for the user profile, go under the Transport tab, and check Allow Local LAN Access.