Troubleshooting Client VPN connections

[henrysacco]

I have a number of users of our VPN3000 that seem to have problems connecting from many hotels. They are using client 4.02 and are able to connect using TCP and UDP, but still are unable to access any resources on our network.

I was wondering if someone could point me in the right direction for troubleshooting.

Thanks,

[ehirsel]

When you state that they are able to connect using tcp and udp, what does that mean? Check to see if the users are able to complete vpn authentication successfully. If the vpn authen fails, then they will not be able to access the corp. network resources.

How is the vpn conn profile setup? Is NAT-T being used? Or NAT tunneling over udp or tcp?

Let's start with the basics and proceed from there.

[henrysacco]

Under the transport tab, you have the choice of TCP or UDP for connecting...and yes, the majority of hotels are using NAT.

Again, here is the client config.

In a hotel on a high speed connection.

Hotel network is NAT.

Clients are configured for NAT-T

The client attempts a connection to our network, authenticates fine...connects fine...but then are not able to access ANY resources on our network.

This only happens from various hotels.

[ehirsel]

My first thought was it may be a dns related issue, but now I am thinking that it could be a path mtu issue and that certain hotels are blocking the icmp type=3 code=4 (fragment needed) that the client expects to use. The hotels that are having the issue, may have a dsl connection that involves pppoe and that effectively makes the mtu set to 1492.

One thing to do when to test this is to see if there is a user that is already at one of the hotels, and if so, walk them thru adjusting the mtu on the vpn client to 1300. The pix mss size by default uses 1380, but that is just for payload. I am not sure what the vpn concentrator's mtu is - it may be 1500.

At any rate, the cicso 4.0.3 client when it's mtu is set to 1300, the tcp/udp and ip header is already included, the data payload is 1300-40=1260 bytes.

Is it feasable to run this test?

[henrysacco]

Yes, i will give it a shot...thanks

[ehirsel]

One other question:

Is there a firewall or other NAT device in between the user and the vpn concentrator, or between the vpn concentrator and the internal network?

The reason I ask is that if there was one, but the dns server only contains the non-translated internal addresses, you will need to bypass nat for the remote access vpn clients.

On the pix firewall for example you would code something like this:

access-list nonat_acl permit ip internal-net netmask vpn-client netmask - where vpn-client is the address assigned by the vpn 3000 (or other dhcp server) to remote clients. If nonat_acl is an already existing acl, then just add the entry, or if not then create it and then refer to it like so:

nat (inside) 0 access-list nonat_acl

[ehirsel]

I assume that the issue is that user X can connect from site A, but not from site B. That is the same user has issues only in certain locations, but in other they were able to successfully connect. Is that valid?

Because if this is not known to be certain, then one addtional check would be to insure that if these users run MS Win OS, that the client for ms networks, and the file and print share for ms networks is enabled on the virtual adapter. I am not sure what the default setting is, but it could be that these users would have an issue no matter where they connect from if the proper protocols are not enabled.

[#8]

We have experienced similar issues where hotel network address space overlaps or conflicts with our internal RFC 1918 addresses. The result is the same problem you are describing. Could be the reason you only see it with certain hotels. Easy to check next time someone reports the problem.