[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Trying to connect [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
One of the most interesting results of our testing was the difficulty each vendor had in supporting the most basic VPN activity: the ability to mount a Windows file server and connect to one of its shared drives, and open and copy files to this network share. Only Juniper was able to complete this task in the time allotted, and even it had to struggle to figure out the problem.

That problem was Stanford's wide-open network--its servers are directly connected to the Internet, with no intervening firewalls. To protect themselves and these resources, Stanford's server support group has locked down its user authentication to use NTLM v2. This requires stronger authentication than the original version that supported the LAN Manager-style username and password combinations that are sent over the wire in the clear.

SSL gateways can't talk this protocol to the Windows file servers, so users must employ the network extension client to authenticate. When we tried to set up a share for the thin clients using each vendor's portal pages, the logins failed. Juniper has a setting that specifically turns on v2 authentication, while Aventail required a manual editing of its start.sh file to enable it. F5 and Cisco don't support this protocol. Check Point says the problem was longer passwords that didn't parse in its Samba client.

--DAVID STROM
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
...

Applications Support
Corporate VPN administrators will need to carefully examine every application and test to make sure that it works for each client, and under both thin and network extension clients. This is where SSL VPNs are weakest: IPSec products can handle a wider range of applications without any configuration, since they own the entire protocol stack.

We tested a variety of simple and complex applications to see how well they would work on each product. We tried to connect to a Windows file share on the local LAN, to an FTP and SSH server, and view a variety of Web servers that were behind a firewall. We also tried to run Outlook Web Access and connect to a Java-based Avocent KVM over IP server.

With each application, we used a browser-based client to connect to a custom Web portal page linking to each application, and with the network extension client (if it was available for that particular platform).

Juniper had the widest support for applications, and has a nice way to debug URLs entered into its portal configuration screen.

Surprisingly, the biggest issue with our tests was connecting to a Windows file server shared drive. This is a relatively simple task, but it confounded all the products except Juniper and Aventail (See "Trying to Connect," at right).

Certain complex Web applications, such as the Avocent KVM over IP, gave us trouble as well. Aventail was the only product that could support the Avocent KVM session inside a browser, but it only worked with IE. The others required their network extension clients to enable viewing remote desktops over their VPN connections.

While Cisco wasn't alone in its failure to support Mac Intel clients, even its thin client couldn't browse Windows file shares on these Macs, which is a bug. Check Point and F5 also had some issues and couldn't support all the applications as well as Juniper did.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   NEXT PAGE  >