VPN Client Support

Can you make a howto?  I'm not a programmer or a network administrator.  The VPN in Windows 8.1 work differently from what i'm use to.  I'm lost

In RT 8.1, you pull settings, change pc settings, network, add vpn connection.  You select the type of VPN manager you are using as Juniper Networks Junos Pulse and enter your company's server address and any credentials.  You also have options for SonicWALL, Microsoft, F5 and Checkpoint.

Otherwise, your options are to get with your network admin and show them the settings available when you go advanced and sort it that way if options are available.

Can you make a howto?  I'm not a programmer or a network administrator.  The VPN in Windows 8.1 work differently from what i'm use to.  I'm lost

In RT 8.1, you pull settings, change pc settings, network, add vpn connection.  You select the type of VPN manager you are using as Juniper Networks Junos Pulse and enter your company's server address and any credentials.  You also have options for SonicWALL, Microsoft, F5 and Checkpoint.

Otherwise, your options are to get with your network admin and show them the settings available when you go advanced and sort it that way if options are available.

Hmmm I try this, but the username and password fields seem to be inaccessible?

When I try and connect the VPN I get the message "Verifying credentials" and then it fails with "Invalid parameter"...

Just because Juniper's VPN now works doesn't mean Cisco's client can work the same way, or has the same requirements from the OS. This may answer the original poster's question about Juniper, but Cisco VPNs are still waiting...

Actually it does - even if the Juniper support doesn't allow for every security option, it at least allows for the most basic capabilities. Cisco could support this as well.

The important thing is, clearly, the Surface RT is capable of supporting encrypted communication.

That said, Cisco and Microsoft are competitors so there may be some jockeying going on here. Wouldn't be the first time.

It is possible Cisco is saying it is on MS because they don't want to enable a competitor's product. Microsoft could also be blocking Cisco for the same reason, but what is more logical?

Block one of the top two secure remote access providers from implementing VPN, thereby impacting the number of tablets sold

or

Not developing an app for your competitor's tablet to block the tablet from being sold into your client base?

I have no inside knowledge here aside from being in this industry for a LONG time, but with VPNs now clearly supported, the odds are it is Cisco, not Microsoft, that is the blockage here. Unless a Cisco PLM can post details about what they need that MS isn't capable of or giving them... but I haven't seen that since 8.1 SDKs came out.

Well, already knew Windows RT supported basic VPN functionality (IPSec etc) out of the box with 8.0. What it didn't, and in Cisco's case still doesn't, support is SSL VPN client functionality because the vendors all implement it differently from my understanding (correct me if I'm wrong). It sounds to me that additional capabilities have been added to the built-in Microsoft VPN client in 8.1 for Juniper etc, as opposed to a third party VPN client. Cisco may not be able to do the same with their client due to whatever may differ, or they may not be interested in exposing how their AnyConnect VPN works (the competitor drama you describe) to add that functionality to the built-in VPN client, but at the same time may still not be able to write a client using just the WinRT API. If this is the case it still may very well still be about the APIs on Windows RT. Once again I wish Microsoft would reconsider their insistence on blocking third party use of any API other than WinRT in Windows RT.

Can you make a howto?  I'm not a programmer or a network administrator.  The VPN in Windows 8.1 work differently from what i'm use to.  I'm lost

In RT 8.1, you pull settings, change pc settings, network, add vpn connection.  You select the type of VPN manager you are using as Juniper Networks Junos Pulse and enter your company's server address and any credentials.  You also have options for SonicWALL, Microsoft, F5 and Checkpoint.

Otherwise, your options are to get with your network admin and show them the settings available when you go advanced and sort it that way if options are available.

Hmmm I try this, but the username and password fields seem to be inaccessible?

When I try and connect the VPN I get the message "Verifying credentials" and then it fails with "Invalid parameter"...

I have the same problem.  Junos Pulse for iOS and Android both allow inputting the credentials that it then uses to authenticate but I do not see a field for this in 8.1.

Well, already knew Windows RT supported basic VPN functionality (IPSec etc) out of the box with 8.0. What it didn't, and in Cisco's case still doesn't, support is SSL VPN client functionality because the vendors all implement it differently from my understanding (correct me if I'm wrong). It sounds to me that additional capabilities have been added to the built-in Microsoft VPN client in 8.1 for Juniper etc, as opposed to a third party VPN client. Cisco may not be able to do the same with their client due to whatever may differ, or they may not be interested in exposing how their AnyConnect VPN works (the competitor drama you describe) to add that functionality to the built-in VPN client, but at the same time may still not be able to write a client using just the WinRT API. If this is the case it still may very well still be about the APIs on Windows RT. Once again I wish Microsoft would reconsider their insistence on blocking third party use of any API other than WinRT in Windows RT.

You highlight my contradiction - Cisco could write an SSL connection for Cisco to sit within RT but they didn't. Checkpoint, F5, Juniper, etc did take that initiative.

MS could open up their APIs for a Cisco client, but they haven't, and no other vendor is really complaining.

SSL is a standard: http://tools.ietf.org/html/rfc6101 and has been for a while.

That said, it is possible that Cisco wrote proprietary code they claim will make it better - they are notorious for that, and have done it with discovery protocols, routing protocols, and SIP just to name three. This doesn't really make it MS's obligation to support it.

I hope whatever the block is, the Cisco community out there get an acceptable answer for their connectivity. We will see...