For several years, my company used Microsoft's Point-to-Point Tunneling Protocol (PPTP) to provide remote users with VPN access to corporate resources. This worked well, and almost all employees who had PPTP permissions were comfortable with this method. But after several security problems with PPTP were reported, we decided about a year ago to deploy virtual private network concentrators from Cisco Systems at all of our core points of presence.
We ran things in parallel for about six months to let users get used to this new way of connecting. Users were instructed to download the Cisco VPN client and associated profile and start using the Cisco client. During that period, if the users had problems, they could always fall back on the PPTP connection until the issue was resolved.
That option disappeared about a month ago, though, when we pulled the plug on our PPTP servers. Now, all users have to use the Cisco VPN client. Many global e-mail messages were sent to users about this impending action, but by the time we were ready to retire our PPTP servers, several hundred users were still using it. We tried to advise each of them of the change, but about 50 were traveling, on vacation or otherwise out of reach. This wasn't so bad, considering that we have more than 7,000 employees using the VPN. Our company has a global presence, so some users we have to communicate with don't speak English and work out of their homes on the other side of the world.
Now we have a new set of issues. A particularly loud group in the company is reporting problems with theCisco VPN client. These users are mostly in sales and need access to demos on the network and sales databases. What makes them loud is that they generate revenue, so they usually get what they want.
The problem is that customers block the ports necessary for the VPN clients to communicate with our VPN gateways. Similar difficulties are experienced by users in hotel rooms for the same reason. This isn't a Cisco issue, mind you; almost any IPsec VPN client would have similar problems.
Meanwhile, we have had numerous requests for access to corporate mail from kiosks. Users have said that when they can't use their company-issued computer -- be it at a conference or a coffee shop -- they would like to be able to get into their Microsoft Exchange e-mail and calendar.
We have contemplated extending Microsoft Outlook Web Access externally, but we don't want to do so without robust authentication, access control and encryption.
SSL Solution
With both of these problems in mind, we've decided to explore using Secure Sockets Layer VPNs. This technology has been around for quite some time, and almost every Web browser on the market today supports SSL, otherwise known as HTTPS, secure HTTP or HTTP over SSL.
A VPN over SSL is almost guaranteed to solve the problems employees have been having at customer sites, since almost every company lets its employees make outbound Port 80 (standard HTTP) and Port 443 (secure HTTP) connections.
SSL VPN will also let us extend Outlook Web Access to remote users, but there are two more problems. First, this type of VPN is primarily beneficial for Web-based applications. Second, employees who run complex applications such as PeopleSoft or Oracle, or who need to administer Unix systems via a terminal session, will most likely need to run the Cisco VPN client. That's because it provides a secure connection between their client and our network, whereas an SSL VPN provides a secure connection between the client and the application. So we'll be keeping our Cisco VPN infrastructure and adding an SSL VPN alternative.
The second problem we anticipate concerns users who need to access internal Web-based resources from a kiosk. Many of the SSL VPN technologies require a thin client to be downloaded to the desktop. Many SSL VPN vendors claim that their products are clientless. While this may be true for pure Web-based applications, a Java applet or ActiveX control object must be downloaded to the desktop/laptop/kiosk before any specialized application can be executed.
The problem is that most kiosks are locked down with a policy that prevents users from downloading or installing software. That means we have to look at alternative means of addressing the kiosk scenario. We'll also want to find a vendor that provides a secure browser and client log-off that wipes all traces of activity from the computer, including cached credentials, cached Web pages, temp files and cookies. And we'll want to deploy an SSL infrastructure that allows for two-factor authentication, namely our SecurID tokens.
Of course, this will incur an additional cost per user, since the SecurID tokens, whether soft or hard, are pricey. In addition, the enterprise deployment of SecurID tokens is no trivial task. It is, however, on the security road map, which I'll discuss in a future article.
As for an SSL VPN, we're looking at offerings from Cisco and Juniper Networks. Juniper recently acquired Neoteris, which has been a longtime leader in SSL.
As with any new technology we introduce, we'll come up with a set of requirements and conduct rigorous testing to ensure that we have addressed deployment, management, support and, of course, security.