Vista x64 + Cisco VPN = big FAIL

[konakona]

So my boss got his brand new laptop. It came with a bunch of useless bloatware crap as usual from major vendors, so he asked me to help him do a clean install. With 4GB of ram to spare, I thought it only made sense to go with x64, and he was more than convinced about the benefits of doing so. Everything was fine until I discovered a little problem: Cisco is yet to come up with, or has no future plans of coming out with a IPSEC compatible VPN client.

AnyConnect, their new product, only supports SSL and DTLS. Frankly, a lot of these terms are just way over my head, but that just means a workaround has to be found as far as I or my boss is concerned. After long hours of arduous googing, I concluded there was no quick fix for that, and the most plausible solution seemed to be virtualization + guest OS (winXP).

VPN connected fine as expected from the guest OS, but he was very weary of the idea of having to go through the an intermediate "shared folder" between the guest and the host machines when moving files. Yet he wasn't ready to willingly ditch the 64bit OS, so I went back to google for an alternative answer. This guy was nearly on the mark:
http://xenomorph.net/use-cisco-vpn-under-vista-x64/

except that vmware is rather bulky so we have a strong preference for virtualbox. More importantly, his settings seemed to be geared toward a static and invariant fixed location. My boss travels a lot, literally all over the world. His need for VPN arises chiefly from his need to remotely access his office machine while he is away somewhere on the globe. He is not a complete computer illiterate, but doesn't want any "complications" for getting things done.

At the end, here is what I want to know: based on that article in the link, is there way I could replicate that on this computer using virtualbox, assuming there will be constant jumping from one location to another? I am quite uneducated when it comes to networking, and the whole idea of network bridging is a bit confusing at times.

I am currently disecing another, rather lengthy thread found here: http://geekswithblogs.net/evje...2007/01/01/102429.aspx

no signs of hope so far



NOTE: if you mention a word about switching to linux or anything along that line, I will be forced to ignore your replies from there on. This is not a thread meant for responses on OS superiority (or claims of such)

 

[konakona]

Here is where I am at right now:

Instead of the default NAT network adapter that ships with vbox, I set up a "host interface" adapter, then bridged it with the physical (wireless) adapter on the host. (I think I read somewhere wireless + bridging doesn't play nice, any truth to that?) The guest machine connects to internet and VPN fine, but the host is still unable to access private sites. I tried bridging the VPN adapter and the "host interface adapter" in the guest, and that took out internet access from the guest, so I reverted it back.


The last link there doesnt look too unfamiliar to me, perhaps thats a snipped version of whats posted on the MS's own site. General consensus was the only viable alternative out of all that was NCP and that didn't do it for me.. boohoo

 

[QuixoticOne]

IPSEC is, in theory, capable of being set up in a vendor neutral standardized fashion since it uses a series of open standardized protocols to work.

If Cisco's own "VPN client" doesn't work, consider using someone else's that does work and interoperate with Cisco's IPSEC implementation in use by your organization.

All that needs be done is to ensure the authentication / password / certificate / encryption protocol & network protocol options configured into the server side Cisco VPN server are compatible with the connecting VPN client's settings.

Actually Vista itself has some built in IPSEC capabilities but they're a pain in the rear to administer manually so it is usually nice to have some kind of easy to use client program to set up the parameters for you.

Also as their customer, I'd complain LOUDLY to Cisco that it is unacceptable for them to not support Vista.

Also if your organization does support / run the VPN server, would it be hard / expensive simply to allow additional access via the vista supported SSL / DTLS options to easy migration of organizational users that are running Vista x64? If you own the hardware/software server side to implement these it should be just a matter of "turning it on" alongside the existing IPSEC options / configurations.

 

[QuixoticOne]

http://www.thegreenbow.com/vpn.html
http://www.prnewswire.com/cgi-...2007/0004619887&EDATE=
http://news.thomasnet.com/fullstory/524062
http://www.zyxelguard.com/ZyWALL-remote-client.asp


http://www.windows-vista-updat...-Vista-VPN-Client.html

 

[konakona]

Well, the sad truth is schools are sometimes the slowest to adapt, even as are supposed to be cutting edge in their respective areas of research. In fact, they just recently allowed use of 32bit vista on the registered machines. Going by what I have read, people mostly blame Cisco for not supporting x64, and/or forcing their customers to upgrade their hardware, while Cisco seems to be upset with Microsoft's unwillingness/ineptitude to properly document their new API. Truth is probably somewhere in between

I actually tried the NCP's Secure Entry Client without any success. The program got far enough to ask me for the login info, but still no access to the folders. Looks like it is a hit or miss with Cisco networks.

 

[Tommouse]

I'm having the same time going about getting Vista x64 working with Cisco VPN as well at my work. We have had a bunch of people not be able to use VPN due to having this OS. Our interim solution is the web SSL VPN. But we are only licensed for 2 concurrent sessions, so it is very limited. Hence why we need to get it to work normally.

SSL VPN requires extra licensing to have more concurrent users, unlike IPSEC which is completely wide open (to the limit of what the hardware can support). So I tend to side on the "it's Cisco fault" side, as it seems like a blatant money grab. "oh it doesn't work, then you should upgrade. Money please" Cisco ASA 5500 Series SSL/IPsec VPN Edition

I have been playing with NCP. It has had some strange effects on the test machine I'm using (Vista x64 running on a VM [hostOS: ESX]). I have yet to nail it down, but the Vista box's NIC keeps forgetting its default gateway. This is less than desirable. Which is why I'm redoing my tests, as I haven't heard of others having this issue, so might just be a coincidence or some other strangeness.

Anyways, I'm getting sidetracked. The bottom line is that I'll be working on this in the next few days at work, whatever I figure out I'll post up

 

[QuixoticOne]

Be certain that you have all the information on the algorithms / modes / certificates / passwords needed for authentication & encryption.

It could fail simply because NAT transversal is required but not enabled, or because the server is expecting DES encryption whereas the remote is configured for AES only, et. al.

If they advertise Cisco compatibility I'd tend to assume that it is indeed possible to get it to work, given the right selection of a dozen or so protocol options to match your server side setup.

Usually I have good luck spying on the ethernet packet exchange with wireshark or a similar free protocol analyzer / packet tracing software to help debug the problems with the initial exchanges. Of course using any diagnostic / debug / informational & configuration screens on your client / server is essential.

Try getting Cisco client S/W working under XP / Win2k or whatever it supports well and verify that all the settings are as expected while you have a known working client machine to test with. Then replace the client software on that machine with NCP's or someone else's and get that working again under the older OS. Once that is done successfully, try the NCP or other suitable s/w under Vista x64 and use the same parameters as were observed to work on the older OS test machine. If it still doesn't work under Vista but it works on older machines, check the Vista firewall and networking settings et. al.

Originally posted by: konakona
I actually tried the NCP's Secure Entry Client without any success. The program got far enough to ask me for the login info, but still no access to the folders. Looks like it is a hit or miss with Cisco networks.

 

[Pheran]

While it is annoying that the Cisco IPsec VPN client does not support 64-bit Vista, folks reading this thread should understand that Cisco (and other vendors) consider IPsec remote access VPN to be legacy technology. Anyone who has run an IPsec remote access VPN infrastructure of any significant size with traveling employees can tell you that there are far too many places where firewalls are configured such that the protocols needed for IPsec VPN just don't work. Part of the reason everyone is switching to SSL VPN is that TCP port 443 pretty much has to be allowed out of everything or else large chunks of the web don't work. The Cisco VPN 3000 series IPsec concentrators are already end-of-life and I expect that the IPsec VPN client will follow suit in the next year or two.

 

[QuixoticOne]

It is a sad commentary on 'the internet' that it is being turned into 'the web' by moronic ISPs and incompetent firewall / network administrators that don't care/understand that there are (gasp) actually more protocols out there than (HTTP/S) like, say, FTP, SSH, X11, IPSEC, AH/ESP, TCP, UDP, SIP, IAX, RTSP, RDP, VNC, .........

When is the dumbing down of the internet going to stop?
When do we FINALLY get IPv6, multicast?

There's no good reason UDP encapsulated IPSEC with NAT transversal on shouldn't work in everything but the MOST BROKEN / BLOCKED networks.

 

[Goosemaster]

Originally posted by: Pheran
While it is annoying that the Cisco IPsec VPN client does not support 64-bit Vista, folks reading this thread should understand that Cisco (and other vendors) consider IPsec remote access VPN to be legacy technology. Anyone who has run an IPsec remote access VPN infrastructure of any significant size with traveling employees can tell you that there are far too many places where firewalls are configured such that the protocols needed for IPsec VPN just don't work. Part of the reason everyone is switching to SSL VPN is that TCP port 443 pretty much has to be allowed out of everything or else large chunks of the web don't work. The Cisco VPN 3000 series IPsec concentrators are already end-of-life and I expect that the IPsec VPN client will follow suit in the next year or two.

:wine:


OP. If it doesn't work I suggest you take it like a man, admit to yourself that this is NOT worth the time and either:

a) isntall an OS that will work*
b) find another VPN solution such as Hamachii

*You mentioned "schools" and said "slow to adapt" so assume that you are K-12 and not uni, which means that your boss will NEVER take advantage of 4GB of RAM. Install an OS that is compatible with the Cisco client and use the time you save to go get wasted.

 

[spidey07]

Originally posted by: QuixoticOne
It is a sad commentary on 'the internet' that it is being turned into 'the web' by moronic ISPs and incompetent firewall / network administrators that don't care/understand that there are (gasp) actually more protocols out there than (HTTP/S) like, say, FTP, SSH, X11, IPSEC, AH/ESP, TCP, UDP, SIP, IAX, RTSP, RDP, VNC, .........

When is the dumbing down of the internet going to stop?
When do we FINALLY get IPv6, multicast?

There's no good reason UDP encapsulated IPSEC with NAT transversal on shouldn't work in everything but the MOST BROKEN / BLOCKED networks.

Umm, if you've ever had to deal with VPNs outside of the US you'd see why the move is to SSL VPNs. IPSEC is almost considered a legacy protocol.

 

[maxSe]

Originally posted by: Goosemaster

Originally posted by: Pheran
While it is annoying that the Cisco IPsec VPN client does not support 64-bit Vista, folks reading this thread should understand that Cisco (and other vendors) consider IPsec remote access VPN to be legacy technology. Anyone who has run an IPsec remote access VPN infrastructure of any significant size with traveling employees can tell you that there are far too many places where firewalls are configured such that the protocols needed for IPsec VPN just don't work. Part of the reason everyone is switching to SSL VPN is that TCP port 443 pretty much has to be allowed out of everything or else large chunks of the web don't work. The Cisco VPN 3000 series IPsec concentrators are already end-of-life and I expect that the IPsec VPN client will follow suit in the next year or two.

:wine:


OP. If it doesn't work I suggest you take it like a man, admit to yourself that this is NOT worth the time and either:

a) isntall an OS that will work*
b) find another VPN solution such as Hamachii

*You mentioned "schools" and said "slow to adapt" so assume that you are K-12 and not uni, which means that your boss will NEVER take advantage of 4GB of RAM. Install an OS that is compatible with the Cisco client and use the time you save to go get wasted.

I agree. Cisco has pretty much stopped putting out support for IPsec VPN clients. As many pointed out, there is no Cisco IPsec VPN client that supports x64 Win-based OS. They were incredibly slow with relaesing a client that worked with MAC's as well. Their concentrators are reaching end of life and moving towards the ASA series firewalls that if you want to get the SSL VPN function for more than 2 concurrent connections they provide you by default, you'll have to shell out ~$4K for 25 user license.

Having said that, your best choice - I think - is to reinstall the laptop with 32-bit Vista (I think Vista has option to choose OS type during the initial install) and see if it takes the key that was shipped with the laptop. At least I know for a fact that the VPN client software version 5 & up supports Vista.

 

[konakona]

vista32 was in fact my last option that I have been saving as the last resort; we have several licenses available here, so moving to 32bit really isn't an issue here.

OP. If it doesn't work I suggest you take it like a man, admit to yourself that this is NOT worth the time and either:

a) isntall an OS that will work*
b) find another VPN solution such as Hamachii

*You mentioned "schools" and said "slow to adapt" so assume that you are K-12 and not uni, which means that your boss will NEVER take advantage of 4GB of RAM. Install an OS that is compatible with the Cisco client and use the time you save to go get wasted.

I meant school in the most generic sense - as in grad schools (which is where I work) and whatever else. Our school just isn't exactly technology savvy; like I said, they just recently approved 32bit vista, reluctantly while at that. Although I made it sound like a huge rant, I don't mind spending more time working on it

 

[konakona]

Originally posted by: Goosemaster
At least I know for a fact that the VPN client software version 5 & up supports Vista.

yeah, except in that thread that I linked to in the OP had replies filled with frustration and anger at cisco. Hope everything is well with newer patches now.

While it is annoying that the Cisco IPsec VPN client does not support 64-bit Vista, folks reading this thread should understand that Cisco (and other vendors) consider IPsec remote access VPN to be legacy technology. Anyone who has run an IPsec remote access VPN infrastructure of any significant size with traveling employees can tell you that there are far too many places where firewalls are configured such that the protocols needed for IPsec VPN just don't work. Part of the reason everyone is switching to SSL VPN is that TCP port 443 pretty much has to be allowed out of everything or else large chunks of the web don't work. The Cisco VPN 3000 series IPsec concentrators are already end-of-life and I expect that the IPsec VPN client will follow suit in the next year or two.

I see, IPsec is a thing of a past and should be phased out soon. People seemed to think it is too abrupt a change though.

Try getting Cisco client S/W working under XP / Win2k or whatever it supports well and verify that all the settings are as expected while you have a known working client machine to test with. Then replace the client software on that machine with NCP's or someone else's and get that working again under the older OS. Once that is done successfully, try the NCP or other suitable s/w under Vista x64 and use the same parameters as were observed to work on the older OS test machine. If it still doesn't work under Vista but it works on older machines, check the Vista firewall and networking settings et. al.

I guess I could give a shot at NCP in VBOX, as the cisco client worked fine there. The school supplies us with .pcf files for on-campus and off-campus configurations, which is what I have been using.

 

[Tommouse]

Yea I wasn't able to get anything working really. I was able to get NCP to connect via IPsec but it wasn't passing the routes correctly and effectively crippled itself. So I tried to make SSL VPN work, but that means upgrading the IOS on the ASAs (we're currently on 7.2.4(9)). So ... unfortunately I've got nothing for ya. Good luck :beer:

 

[konakona]

http://www.computing.net/answe...hrough-a-vm/34099.html

Response #5 in that thread caught my attention. Did anyone happen to know where he was getting at?

(Personally, I would have just used host+L on the vbox guest and call it a day but oh well )

 

[QuixoticOne]

Probably stuff like the following... I'd guess that you wouldn't need the registry hack under Vista 64 and there would be other tool / utility based options. Look up "forwarding" and "vista" and "routing" and so on.


http://www.runpcrun.com/howtoopenvpn

Setup VPN routing
Routing on the server should be enabled by enabling LAN routing in the Routing and Remote Access service, however we've found that this causes problems with the OpenVPN service so I would not recommend it. Instead use regedit to set the IPEnableRouter registry key to 1.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: IPEnableRouter
Type: REG_DWORD
Data: 0x00000001 (1)

http://securearea.blogspot.com...dows-as-pc-router.html

Here is the way to configure Windows as a PC router:


By default, Windows can't forward incoming IP address, as a result it can't route IP address between networks.
But we could make Windows as a PC router by adding little modification on the registry.


Note:
On Windows 2000/NT we don't need to modify the registry because there is an option to make Windows as PC router
enter control panel> network > TCP/IP Properties > router > IP Forwarding


In order to know the changes before and after modifying windows registry, run ipconfig /all on command prompt. Before act as router, "IP Routing Enabled""false".
(on Windows IP Configuration section) should be


Here is windows registry modification:


1. Open windows registry editor

Start -> Run -> type regedit

2. Find this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

3. Change dword value IPEnableRouter to 1

4. Restart windows


After windows reboot, run ipconfig /all on command prompt, if "IP Routing Enabled" value is set to "yes", then Windows has been a PC Router. The next step is creating routing table by route command on command prompt.


That's all folks, don't forget to leave your comment yeah!

Originally posted by: konakona
http://www.computing.net/answe...hrough-a-vm/34099.html

Response #5 in that thread caught my attention. Did anyone happen to know where he was getting at?

(Personally, I would have just used host+L on the vbox guest and call it a day but oh well )

 

[konakona]

I went the vpnc route instead, in hopes of getting rid of VBOX entirely. After a bit of switching things around, I was able to get it to connect to the server. Too bad I am still unable to do remote desktop, the reason being the gateway (or the whole routing part) not being setup properly. This is turning out to be a good learning experience

 

[Tbirdkid]

Can I ask why you are going thru a vpn? Just a dumb question, but what about just using dameware, or logmein to just remotely access his desktop at work. He can do everything he needs to do from his laptop at home, and that would be a viable solution unless he absolutely needs to have all of his emails on his notebook. Seems like a logical solution to me. I dont know... probably just too easy...

 

[konakona]

because his desktop is located in his school office, which requires him to establish VPN connection to get into the network, so to say.

still trying to see how to get the routing done manually, as per the vpnc manual instructs to do it yourself (the neat little program doesn't do everything for you unfortunately). I am seeing all the standard messages in the cygwin terminal that get spewed out when everything connects without a hiss. Should be getting pretty close.

 

[bsobel]

Cisco compatible V64 client www.ncp-e.com

Just use that (it will import your cisco profiles)

 

[bsobel]

Originally posted by: bsobel
Cisco compatible V64 client www.ncp-e.com

Just use that (it will import your cisco profiles)

Oops, sorry, missed that you tried it. What didn't work for you?

 

[konakona]

authentication went ok, but nothing worked from that point on - remote desktop and remote folders to be specific. besides, I doubt he would want to pay for an extra software when school supplies him with another commercial product.

does anyone have any experience with vpnc at all? I am trying to follow the manual and its a bit cryptic at best

 

[NeonGerbil]

I know I'm really late now, but I've updated my page with connection info for VMware, VirtualBox, and VirtualPC.

http://xenomorph.net/use-cisco-vpn-under-vista-x64/

By far, it's easier with VirtualBox and VirtualPC.