Product Details
Product Rating
AEP Systems SureWare A-Gate AG-600
AppGate A1
ArrayNetworks SP
Aventail EX-1500
netSurity Bridge
Nokia IP380
OvisGate SSL VPN
SafeNet SafeEnterprise SSL iGate
Symantec Clientless VPN Gateway 4460
Xceedium SSL-UAG+
With so many capable products to choose from, we felt that the Aventail EX-1500 should get our Best Buy award, because it offers the best solution for enterprises that require a wide range of secure access modes across a number of platforms. No less than three products have received our Recommended award. Both the Array Networks Array/SP and the SafeNet SafeEnterprise iGate devices offer useful security features for corporate Windows clients, while the software offering from netSurity should attract organizations that need simpler solutions.
SSL VPNs (2004)
Virtual private networks are trusted by online banks, so they should ensure safe remote access to your systems, too. Ian Parsons tries out the latest products
The choice between an Secure Sockets Layer Virtual Private Network (SSL VPN) and an Internet Protocol Security (IPsec) VPN is based as much on operational needs as on security considerations. The former are often platform-neutral, while IPsec clients tend to be written for particular platforms. Also, SSL VPN systems can go wherever a browser can go, while IPsec systems can only be used where their specialized client software has been installed.
However, some SSL VPN systems also use platform-specific client software. Most provide access to client/server applications using Java, which keeps the user within the browser environment. SSL VPN systems tend to be used where the clients are mobile and connections are short, perhaps to pick up email or access data from a web application, while IPsec solutions tend to be used where clients are fixed with long duration connections accessing networked resources.
But these distinctions tend to blur, and either solution can be used in most cases. The SSL solutions reviewed here provide more than just simple email collection, enabling remote access to a variety of web and network resources.
Using a combination of browser and Java applets also has administrative value, because changes and updates can be downloaded from a central source without any need to recall systems to install new versions of client software, or to send support personnel into the field to carry out upgrades.
Of course, an SSL VPN needs to be secure. Unlike an IPsec system, every would-be intruder already has the required client software to hand in whichever browser takes their fancy, so part of their job is already done for them. However, they should still have to get through the security systems or find a weakness in the VPN itself. We ran a number of port scanners against the VPN devices from inside and outside the network to see if there were any useful ports left open. A VPN system can often contain useful security information, and if it can be subverted in some way, can provide trusted access to the internal network and its resources. We found the devices were secure, and only responded on the expected ports.
Our test system consisted of two networks, one acting as a company LAN, the other as the internet. Our servers ran Windows 2000 and 2003 Server, with Active Directory and Certificate Services, providing simple shared directories, web services from IIS, and Windows Terminal Services. Users were configured to use roaming profiles.
Our client machines ran Windows 2000 and XP Professional and Linux Red Hat 9, and we used a variety of browsers – all with their recommended Java run time environments installed.
The only problem was performance measurement. Because the systems varied in capacity, and also in how they could be configured into the network, it was not possible to measure throughput or transactions per second in any useful way. A load that would reasonably test one would exceed the licensed capacity of another.
A further complication arose from using Active Directory Services for user authentication. Response times from the servers were not constant. However, since a major use for an SSL VPN is to provide access to network services for remote clients that would typically be laptops over dial-up lines, it was more useful to see what effect the systems had on responses at the client end. We compared performance by comparing the response times for a standard script of web browsing requests with the times for the same sequence through the VPN using the same browser. Ignoring the extra time taken to log onto the VPN and download any required client software, the response times were effectively the same in all cases.
A final performance factor was an assessment of how the client software felt in use. This is a largely subjective measurement, and opinions differ on how a user interface should look and behave.
