LAS VEGAS- With more applications becoming webified through the direct use of thin clients and the growing prevalence of portals, Aventail Corp. is here at the Networld+Interop trade show evangelizing a slightly different approach to virtual private networks. Instead of using proprietary client software based on the IPSEC protocol, as many of us do today, Aventail is suggesting that we take advantage of a standard part of our Internet browsers: SSL.

Even though IPSEC is a standard, IPSEC-based VPN solutions from vendors like Cisco and Nortel require that the system needing VPN access have special client software that works with their VPN servers. According to Aventail managing director Richard Ting, this requirement creates unnecessary complexity on the client side. The additional software needs to be managed and tracked for updates and license management.

Instead, Aventail is advocating the use of software that's already present on most systems. Web browsers and the Java Virtual Machine (JVM) that sits along side most of those browsers both support SSL and, according to Ting, both can handle most (but not all) applications that corporate users might deploy across VPNs.

[an error occurred while processing this directive]

The gating factor, according to Ting, is whether your applications can tunnel through the browser's or the JVM's SSL-based connections. To leverage the browser's SSL connectivity, the application needs to be browser-based. "For applications like these, or companies that are providing application access through HTML-based portals," says Ting, "SSL makes a lot more sense than IPSEC." But applications don't have to be browser-based in order to take advantage of SSL. A JVM can set up a tunnel based on SSL in the same way that a proprietary client can set up a tunnel with IPSEC.

The main requirement right now, explained Ting, is the use of single or multiple static TCP ports. (Examples of static ports include the TCP ports used by e-mail protocols and other application layer protocols like HTTP and Citrix's terminal server protocol.) "For applications that use static ports," says Ting, "we've established loopback proxies that allow those applications to use the JVM as a tunneling client without having to worry about problems with the Java sandbox. We run into a problem when applications like SAP's SAPGUI dynamically select ports to work across. Applications like that aren't supported yet, but will be soon."

Also supported is a Java-based client that runs within the JVM.

The way this works, from the end user's perspective, is that a user would access a public-facing portal to start the VPN for employees, business partners or whoever is authorized to get behind the firewall. The Java-based VPN client is downloaded on the fly to the client and the user, after entering the necessary credentials, is authenticated, and a tunnel is established. There are some limitations to the tunnel's use that are associated primarily with Java's sandbox. For example, a user wouldn't have access to shared Windows resources that might normally appear under the Network Neighborhood. But for basic application access, those resources may not be necessary.

Client-side requirements are fairly basic: a minimum of Internet Explorer 5.5 or Pocket IE (for PocketPC and PocketPC 2002), the Microsoft JVM or any of Sun's JVMs beginning with version 1.2. As for JVMs on the PocketPC (which doesn't ship with a JVM), Aventail supports Crème JVM. Aventail is talking to Palm about adding support for that platform. Says Ting, "Our feeling is that Palm is behind PocketPC in terms of available and stable JVMs."

		Wireless That Works Note: As a part of ZDNet's ongoing Wireless That Works series of webcasts, this story was filed from Networld+Interop in Las Vegas using a Compaq TC1000 Tablet PC that was connected to CNET's e-mail servers via a Handspring Treo 300's access to Sprint's 2.5G high speed wireless wide area network. To give the Tablet PC access to the PCS network, a third-party application from JuneFabrics.com called PDANet was loaded onto both devices. Stay tuned for the forthcoming webcast that chronicles David's real world experiment with this configuration.

On the server side, Aventail provides an appliance called the EX-1500, and cost is based on the number of users supported. A 50-user configuration costs $24,000; the maximum 1,000-user configuration costs about $75,000. Factored into these costs is the licensing fee for the Java VPN client that downloads on-demand. Aventail calls this the "Aventail On-Demand" client and an entry level configuration for 50 users costs $7,000. "But," says Ting, "not everyone needs the Java client. The baseline appliance supports browser-based applications without the need for additional licensing fees." This seems like an incentive to move more applications to a thin-client architecture.

Considering the way they could simplify behind-the-firewall access of corporate networks and applications with very low client overhead and how they can work for desktops and handheld's alike, SSL-based VPNs seem to make a lot of sense. The solution could be especially useful for companies that have non-employee constituents -- like stockholders or partners - who need application access and whose systems the central IT department has very little control over.

Is SSL a potential option for you when compared to IPSEC-based firewalls? Share your VPN war stories with your fellow ZDNet readers using TalkBack or write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.

[an error occurred while processing this directive]

[an error occurred while processing this directive]