My client currently has a VPN setup on an ASA 5510, it has worked successfully from various parts of the world using a variety of different OS's:
For example current tested OS's: Windows XP, Windows 7, Windows 8.1, MAC OS X
Locations: 3 Different locations in Canada, 1 US location, 1 Germany Location
Aside from the MAC system all clients are running 5.0.07.0440
Recently a location that has 2 clients located in Oregon, US has had an issue with the connection. This issue occurs from both the office and hotel for the onsite consultant as well as an additional client in the office. The Cisco VPN client connects but is unable to establish an RDP connection. In my browsing online I found a variety of similar issues but none where it was only just a couple of clients that encountered the issue.
Further to this; the person onsite is able to RDP into a different location they have setup at their home office (RDP Direct no VPN).
The following is a listing of some of the troubleshooting steps we employed to attempt to reslove the issue:
- Ran a route print from the client end, all routing information for the VPN populated with no issue
- Tested out the ports via Gibson Research port was showing "port 500" stealthed but I think that was a non issue as I have the same results on my end and have no issues connecting
- Ensured that the correct ports were port forwarded on the client end router/modem
- Tested with Windows Firewall off
- Attempted to ping various VPN IP's (none worked)
Whatever is happenening is preventing LAN access after a VPN connection is establshed. If this was the case at multiple locations I would suspect a config issue on the ASA but as it is not an issue elswhere I am left scratching my head.
Any thoughts would be appreciated.
I can submit a config at somepoint if that becomes needed
I would first monitor through ASDM if the central ASA sees the TCP SYN from the RDP Connection of the client.
If it doesnt then you could perhaps configure a traffic capture on the ASA itself on the port connected towards the destination server to which the client wants to connect. This would tell if the server replies anything.
You could for example check the IP address given to the VPN Client user and use that IP address in the capture configurations.
A simple example configuration could be
access-list VPN-RDP-CAP permit ip host
access-list VPN-RDP-CAP permit ip host
capture VPN-RDP-CAP type raw-data access-list VPN-RDP-CAP interface inside buffer 1000000 circular-buffer
The above presumes the server is located behind "inside" interface.
After this you could tes the connection and then use the following command to determine if any traffic has been catched by the capture
You could then use this command to view the capture on the CLI of the ASA
show capture VPN-RDP-CAP
You could also copy the capture file to some internal host and view the capture with Wireshark which would make it easier to go through the data
copy /pcap capture:VPN-RDP-CAP tftp://
You can remove the capture and its data with the command
no capture VPN-RDP-CAP
The created "access-list" needs to be removed separately.
The above would be the first steps for me probably as I usually dont have access to either the client or the server machine but control the devices in between.
Hope this helps
Thanks for the responses and so quickly!
I will setup the capture and do some testing today. 99.9% sure they have transparent tunneling enabled on both clients.
What IP subnet are you using at the location VPN users are connecting to? It almost sounds like they are connecting from locations that also use the same subnet as the VPN network they are trying to reach, and that you have split tunneling configured.
Could you verify that the remote networks which they are connecting from do not overlap with the network being accessed over the VPN.
If they do overlap, then remove split tunneling and instead tunnel all VPN traffic.
Please rate all helpful posts
Just waiting for the consultant to arrive onsite so we can get some captures rolling. We have found a common denominator in the puzzle. If I neglected to mention this, he was able to successfully connect from both the office and Hotel about 2 weeks ago with no issues. Both the hotel and office are using Comcast as their ISP. As Far as I understand they do not block any of the related ports but it is in fact only from their connection that this problem exists.
Should have some captured data in about 1 hour
So I ran the capture with the consultant connected attempting to RDP a few times, no data was captured. I was not 100% about the IP to capture (External IP coming in or to use the Cisco IP pool assigned one) so I went through and completed the process twice in order to make sure about the IP's.
Marius: I would have thought that NAT and all that good stuff would have resolved things but just to be certain:
I have a seperate policy with no split tunnel, applied this to the user and went through and changed the local IP range on the client side to be certain there was no overlap. Neither of these changes had any effect.
Obviously with no data capture I am not likely to get any useful information that can help push this along any ideas on what might not be working with the capture?
The above ACL for the capture is basicly meant to contain the internal IP of the server and the VPN Pool IP address of the VPN Client. There are mirrored ACL lines for these hosts as we want to catch both directions (though there is another way to configure the same but I have gotten used to configuring it like this)
What you also have to make sure is that the capture is attached to the correct interface. I mean the first interface that would see this traffic from the VPN Client would be the interface closest to the internal server. You can confirm that the capture is ok if you ask someone else to use it for whom its working and capture that traffic.
Its starting to seem that the problems is either on the Client side or networking equipment in between.
Have you checked the Transparent Tunneling setting on the user profile?
Could you share the Statistics page screenshot from the user?
Naturally if the user has a chance to use some other public Internet connection and attempt the VPN connection then that might also help to narrow down the cause of the problem.
I just wanted to get back here and thank everyone for the assistance provided. It ended up being environment related and the issue has been resolved.