Remote Access

Securing Remote Access with SSL VPNs
Part 5: Using SSL VPN access methods

We conclude our SSL VPN primer by taking our demo VPN out for a spin, using everything from desktop browsers to mobile agents to access selected applications.

by Lisa Phifer VP Core Competence, Inc. [July 11, 2008]

Series Summary
Securing remote access with SSL VPNs

Part 1: Reinventing remote access
Part 2: Deploying an SSL VPN appliance
Part 3: Defining SSL VPN access policies
Part 4: Adding SSL VPN endpoint controls
Part 5: Using SSL VPN access methods

In Part 1, we discussed how SSL VPNs use browsers to enable "clientless access" from many devices. In Parts 2-3, we configured a SonicWALL Aventail EX-1600 to secure VPN access by diverse constituencies: suppliers, customers, power users, and other staff members. In Part 4, we used endpoint restrictions to enforce a few safety checks. Here, we conclude our series by illustrating several SSL VPN access methods and how they satisfy different user, endpoint, and application needs.

Dealing with diversity
Selecting the best access method for each user starts with identifying target applications. A vanilla browser can reach web applications, but SSL VPN agents are required to reach non-web, client/server, or bi-directional applications. Some agents are temporary, auto-downloaded for a single session, while others are persistent, installed on first access for repeated use from the same endpoint. Certain applications (e.g., push mail, incoming voice calls) may require persistent agents, but many others can be accessed securely through temporary agents.

This equation is further complicated by endpoint device and IT control (or lack thereof). Agents implemented as executables are OS-specific and may require admin rights to install. ActiveX agents require Internet Explorer and permission to install plug-ins. Java agents can provide cross-platform access, but still require browser permissions to run.

SSL VPN policies must therefore be designed with both application and endpoint in mind. Users that connect from different locations at different times may require more than one access method, depending on the endpoint(s) used and the application(s) being accessed at any given moment.

Our demo VPN illustrates this by giving PowerUsers the right to use any endpoint-supported access method (see figure). On managed endpoints, we let PowerUsers provision the Aventail Connect Tunnel client. On other ActiveX or Java-enabled devices, PowerUser can reach client/server TCP applications like e-mail using the Aventail OnDemand Proxy. Where neither dependency can be met, PowerUsers can still log into the Aventail Workplace Portal to reach web applications.

Network connection and clients
The Aventail Connect Tunnel client is a persistent SSL VPN "network connector" that delivers IP layer access to network resources (e.g., subnets, IP ranges, servers). With Connect Tunnel, users can use bi-directional applications (e.g., VoIP) and browse entire domains—tasks that cannot be performed with other SSL VPN access methods.

We let PowerUsers self-install Connect Tunnel packages for Win32, Mac, or Linux from a link on the VPN portal (see figure). Alternatively, we could have auto-launched the OnDemand Tunnel ActiveX control or Java applet whenever users connected to the VPN portal. Both require admin privileges, but the self-installed client is handier for users that don't otherwise need to launch a browser every time they access the VPN.

Like many IPsec VPN clients, the Connect Tunnel client runs as a virtual adapter, assigning each endpoint a private network IP address at VPN connect time (see figure). Also like IPsec, this persistent SSL VPN agent can be configured to tunnel everything the endpoint sends, including internet traffic (Redirect all) or only those packets sent to private VPN resources (Split tunnel).

Figure 5-3: Choosing a Connect Tunnel redirection mode

However, because SSL VPNs are not constrained by standard IPsec selectors, they can enforce more dynamic filters. Here, the Connect Tunnel client can be configured to bypass traffic sent to the endpoint's LAN—for example, to print a file at home while connected to a work VPN. This is a common gotcha in IPsec VPNs, where administrators cannot create static IPsec selectors that would bypass every local LAN.

Go to page two: TCP proxies and port forwarding >