Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IPSec Vs. SSL: Picking The Right VPN: Page 4 of 6

Nearly every SSL VPN product enables and encourages tight access-control policies--in fact, it's often difficult to allow open access. When a resource is added, specific access rights for it must be defined. For non-HTTP applications, that typically involves a quick address/port definition. However, depending on the product, HTTP application access can be controlled down to the URI (Uniform Resource Identifier) and the method used to access the resource. For example, if a user can access a Web server, but not the /admin directory, the SSL VPN gateway won't grant the access, thus adding another layer of protection to Web server permissions. Similar access controls can be applied to ftp and Windows file sharing.

Typically, access to resources can be granted or denied based on the client's location, whether it is up-to-date on OS patches or whether it can load the SSL VPN gateways mobile code for cache cleaning. Advanced protection features, such as URI access control and dynamic ACL (access control list), vary by vendor.

For those users who need secure access to non-HTTP applications, SSL VPN products offer two methods. With the so-called "clientless" method, the user downloads a Java or ActiveX component within his or her browser, setting up a proxy on a local-host address (for example, 127.0.0.1), and temporarily modifies the local hosts file to resolve host names to the local-hosts address. The user access level required on the client to start the local proxy on a port below 1023 and change the local hosts file varies with each product--most require local administrator access. Additionally, UDP protocols are rarely supported by SSL VPN products, so be sure you have a firm grasp on your application requirements and ensure the SSL VPN gateway will support them. Don't overlook in-house developed applications. The best practice would involve a detailed log of all applications, testing SSL VPNs with as many as possible.

If you want to go the tried-and-true route, use installed clients on the client and forward sensitive packets over the SSL VPN. Aventail and Juniper support this method. However, there's nothing to download or install and you don't need to jump through any hoops with the user's privileges.

Having It Both Ways