Cisco VPN or wireless question.

keatron

Anyone had a problem connecting to their company VPN with Cisco VPN client over hotspots (airport, hotel, etc)? Unfortunately, I can't look at the problem laptop right now, just wondering if there's any one who's already run into this.

Keatron

sprkymrk

I found that in addition to the standard esp/isakmp (IP protocol 50 and udp 500 - I know you know this Keatron but for others) I found that the Cisco VPN seems to need udp 10,000 open. I'm not sure about the Cisco VPN client, but the Symantec client we use has an option you can configure to enable UDP encapsulation for help in traversing NAT'ed connections.

garv221

keatron wrote:

Anyone had a problem connecting to their company VPN with Cisco VPN client over hotspots (airport, hotel, etc)? Unfortunately, I can't look at the problem laptop right now, just wondering if there's any one who's already run into this.

Keatron

I know the vpn client has problems when the laptop is connecting from a local subnet exactly the same as where the home office is. THis is typical in a 192.168.1.x scnerio.

Ahriakin

99% of the time it's down to PAT (it breaks ESP/IPSEC, anyone behind a PAT device like a broadband router or firewall is SOL), and sometimes restricted ports. You need to encapsulate IPSEC inside a protocol that understands Port numbers and therfore can survive PAT using them for identification.
The simplest thing to do is enable NAT-T on the concentrator, it's enabled by default on the Cisco client (under transport) and is auto-negotiated between the Concentrator and Client during IKE Phase1. Sooooo if it's not needed it's not used and you don't waste time with extra protocol overhead. Of the 3 methods (NAT-T, Cisco Ipsec over UDP and Ipsec over TCP) I think it's the best option. It will encapsulate all Ipsec traffic with UDP on port 4500. If the provider has this blocked you can switch to one of the other 2 methods, they have one advantage in that the port is configurable (defaulting to 10000 for both) so if the provider is deliberately blocking that port (its a money-maker to restrict known VPN ports to business class accounts) you can get around it this way, however make sure the ports/method match on the client and concentrator. Like I said though NAT-T is the easiest, most efficient and most reliable as you just (usually) have to enable it on the Concentrator, try it first. CONFIGURATION / TUNNELLING AND SECURITY / IPSEC / NAT TRANSPARENCY .

darkuser

i was told that udp can't leave cisco
ie ... cisco vpn is over tcp and NO udp at all !!! can ever exit
it's all blocked .....

rossonieri#1

Ahriakin - nice answer

i think the access point did not set up as VPN gateway so UDP NAT traversal port 4500 wasnt opened.

cheers:)

Ahriakin

darkuser wrote:

i was told that udp can't leave cisco
ie ... cisco vpn is over tcp and NO udp at all !!! can ever exit
it's all blocked .....

I'm not sure of the context here, told by who (your own IT folks or as a rule in general?). Cisco border devices can be configured to deny or permit just about any network traffic so subjectively yup your own IT folks could restrict UDP. But as far as capabilities go those 3 methods I mentioned are supported by the VPN3000 series concentrator, hardware and software clients - whether you can use them just depends on how the concentrator/clients and intermediate interconnect devices are configured.

Edit: Also IPSEC uses either AH or ESP (or both) and while part of the TCP/IP suite they are individual protocols independent of TCP or UDP - this is where the port issue arises. While both have protocol numbers that can be used for traffic management they do not work the same way as UDP or TCP ports, the encapsulation is purely optional dependant on circumstance.

Rossonieri - Glad it made sense, I always wonder if my response is actually useful or if I'm just showing some eager inexperience/lack of understanding. I could be wrong and corrections are always a good thing.

forbesl

http://www.cisco.com/warp/public/471/nat_trans.html

keatron

Thanks for the replies guys. While checking this out here's what I found.

1. If the laptop is set to use the Windows Wireless Zero Config to manage the wireless, all is fine. However using the vendor client utility (Dell) is the only time the VPN client fails to connect properly. This is very weird indeed since I've always been one to go with vendor supplied wireless client utilities instead of WZC. Of course I got her connecting just fine, but I'd certainly like to figure out this behavior.

Ahriakin

I think Zero config can use Upnp which i 'think' can talk to any Upnp routers in the way to work out its config. Vague I know, but its similar to using Remote Desktop inside windows, using PAT on clients between 2 Upnp aware devices works. I've never delved into why but I imagine they work out something similar to NAT-T, some way to encapsulate traffic and resolve port issues.
Other options are that Zero config automatically detects NAT-T and it is already enabled on your concentrator, and the Dell client may not have it enabled/offer it as an option so being one-side the negotiation fails (I've never used their client so I don't know).

keatron

Ahriakin wrote:

I think Zero config can use Upnp which i 'think' can talk to any Upnp routers in the way to work out its config. Vague I know, but its similar to using Remote Desktop inside windows, using PAT on clients between 2 Upnp aware devices works. I've never delved into why but I imagine they work out something similar to NAT-T, some way to encapsulate traffic and resolve port issues.
Other options are that Zero config automatically detects NAT-T and it is already enabled on your concentrator, and the Dell client may not have it enabled/offer it as an option so being one-side the negotiation fails (I've never used their client so I don't know).

Certainly sounds plausible. When I'm able, I will certainly research it more. And again, thank you to those of you who responded.

Keatron.