Cisco VPN Concentrator 3000

I am having some problems with the Cisco VPN Concentrator 3000 at my office. Basically, users are able to connect to the VPN using the Cisco VPN client 5.0.01.0600. Once the VPN connection has been established the user will then double-click on RDP to remote into there desktop. This is where the problem resides, users can't RDP into there desktop.

What makes this issue even more difficult to troubleshoot, is that it happens sporadically. But lately it has been happening more and more to various users.

I have checked the firewall settings and everything looks good. I haven't made any changes in the last few months that would affect the VPN.

The temporary solution I have right now is to simply add the external users IP address in the firewall and have them tunnel through. But this completely defeats the purpose of a secure VPN connection.

Does anybody have any suggestions? I am a bit stumped on where to even approach this and troubleshoot further. I am now doing some in-depth research on VPNs and possibly looking at this issue at the various layers.

As I'm typing this message I tried connecting and I was successful. So, I am not able to provide an error message yet, but as soon as I get one I will post it. If my memory serves me correctly, the error message was very vague stating simply that it couldn't connect successfully.


Cheers,

ZiPPy

I had a similar issue and it took me about four months to solve it.

CheckPoint is the firewall/VPN end-point at work.
CheckPoint SecureClient VPN-1 (i think that's the name) is the client that is locally installed on users' laptops.
We also have SSL VPN setup, but its not published to all the users.

One specific user on a specific laptop would connect to the VPN but then wouldn't be able to access anything internal (ie: file server, Exchange, application servers, etc). I uninstalled the client and reinstalled it, played with the configurations (although we never had to), reimaged the machine, recreated the VPN account and the issue persisted. Strange thing was, the user was able to easily access servers and other internal resources when the user would connect with SSL VPN, so I had to do research on specifically how the two connectivity methods differed.

After reading many forums, I came across this MS knowledgebase article: support.microsoft.com/kb/244474

The section of interest is:
"By default, Kerberos uses connectionless UDP datagram packets. Depending on a variety of factors including security identifier (SID) history and group membership, some accounts will have larger Kerberos authentication packet sizes. Depending on the virtual private network (VPN) hardware configuration, these larger packets have to be fragmented when going through a VPN. The problem is caused by fragmentation of these large UDP Kerberos packets. Because UDP is a connectionless protocol, fragmented UDP packets will be dropped if they arrive at the destination out of order. "

...which is basically saying that as the computers attempt to authenticate to the DC using Kerberos, larger, fragmented UDP packets involved get dropped, preventing the computers from authenticating (since there's missing fragments to make up the packets).

This made sense in my situation because the client configuration was authenticating and connecting to the VPN end-point, but everything after that point wasn't working because the computer wasn't authenticating.

I wish I had thought of asking the sysadmin who looked at the laptop to also look at the DC's event viewer to see if he saw any issues

Hope this helps or gives you an idea of where to go

Error message from the Cisco VPN client logs:

Cisco Systems VPN Client Version 4.0 (Rel)
Copyright (C) 1998-2003 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 5.2.3790

1 11:18:54.309 08/06/08 Sev=Warning/2 CVPND/0xE3400014
AddRoute failed to add a route: code 87
Destination 192.168.1.0
Netmask 255.255.255.0
Gateway 255.255.255.255
Interface 192.168.1.185

2 11:18:54.309 08/06/08 Sev=Warning/3 CM/0xA310002B
Failed to add Split Tunnel route.

3 11:18:54.309 08/06/08 Sev=Warning/2 CVPND/0xE3400014
AddRoute failed to add a route: code 87
Destination 192.168.2.0
Netmask 255.255.255.0
Gateway 255.255.255.255
Interface 192.168.1.185

4 11:18:54.309 08/06/08 Sev=Warning/3 CM/0xA310002B
Failed to add Split Tunnel route.

5 11:18:54.309 08/06/08 Sev=Warning/2 CVPND/0xE3400014
AddRoute failed to add a route: code 87
Destination 192.168.3.0
Netmask 255.255.255.0
Gateway 255.255.255.255
Interface 192.168.1.185

I'm thinking ...no responses means I need to get rid of my Cisco Concentrator 3000???

ZiPPy

I've come across another theory or hunch in regards to this issue that might spark some ideas from others, hopefully!

I was told to have my carrier check the MTU (maximum transmission unit) across my link. Apparently, I might have to small of an MTU set therefore restricting RDP to work properly.

When I login to my Cisco 1700 router and run a 'show running-config' command I get my current configuration. I am looking to see what my MTU is set to on the router. From what I understand when the MTU is not listed with a value it is set to default. The default value of the MTU is 1500.

With this information and the statement to check my MTU would dropping it to another well known setting of 1492 help the situation? Is there a "sweet spot" if you will when it comes to the MTU setting on a Cisco router?

Once again just throwing out my thoughts to solve this odd VPN issue.

Thanks,

ZiPPy

You could also test for the MTU size yourself accross the link by using PING and setting the DF (Do not fragment bit) and set the size of the packet and see when it fails.

I was too lazy to find the instructions, but I think you can google it.