Remote Access

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

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

Web-based applications
Whenever a user logs into an SSL VPN portal, the appliance tries to use the agent that provides the broadest access, based on the authenticated user's privileges, operating system, browser, and other endpoint constraints. Where other access methods are unavailable or denied, users may still reach web-based applications, including web applications, web portals, web servers, and webified GUIs (e.g., ActiveX-based network explorers and terminal servers).

The Aventail EX-1600 supports two web-based application access methods:

Aventail Web Proxy: A temporary ActiveX agent (HTTP proxy), used by default on Windows PCs with Internet Explorer to reach any web-based resource.

Aventail Translated Web Access: Basic web access from any browser that supports SSL and JavaScript (e.g., Win32/Firefox, WinCE/PocketIE, Mac OS/Safari). Treated as the fallback in cases where no other access method applies.

Web-based access methods are typically presented through a VPN web portal. For our demo VPN, we defined several custom Aventail WorkPlace portals (see figure).

Each WorkPlace displays a Realm-specific login screen, reached by browsing a unique hostname. For example, we gave each individual Customer its own WorkPlace site, assuming that everyone who landed on custA.cs.corecom.com wanted to authenticate to Customer A's server. This approach allows for privately-branded log-in pages, logos, instructions, terms of service, etc. The only catch is that WorkPlaces with an entirely different hostnames require their own virtual IPs and certificates.

After authentication, the WorkPlace site auto-loads any agents required for endpoint interrogation, data protection, and/or VPN access, and then displays authorized shortcuts for web-based resources, including URLs, fileshares, and terminal servers.

For example, users that successfully authenticate to Customer A's Realm are presented with the WorkPlace shown in Figure 5-6 (on previous page), including public OWA and private website shortcuts. However, users that successfully authenticate to the Supplier's Realm are presented with the Workplace shown in Figure 5-8 below, with a single TermServer shortcut. These and several other shortcuts were configured in Figure 5-7, but only those shortcuts actually accessible to each user appear on that user's WorkPlace display.

Custom portals can help you hide VPN details from users who shouldn't see them. In our demo VPN, we did not want Customers (and Suppliers and Staff) to be aware of each others' resources. Although Customers' private websites were actually hosted on the same IIS server, shortcuts and aliases made that fact less visible. We also configured single sign-on to relay VPN logins to our IIS server so that users did not have to explicitly authenticate to both the VPN and their private websites.

Although custom portals can deliver a personalized experience for each authenticated user/endpoint, we did encounter a few limitations. For example, every portal displays the Network Explorer icon—even when users don't have permission to reach fileshares. We also had a little trouble with "extra" shortcuts appearing when resources of different types were hosted on the same physical server.

SSL VPN portals are also widely used to simplify agent provisioning, either by auto-loading required agents or by letting users download self-installed packages. For example, the Aventail Access Manager is required to use anything more than translated web access (see figure).

This Access Manager auto-installs the Aventail Web Proxy wherever it can, and will then try to auto-load the OnDemand Proxy or OnDemand Connect agents as required by Community policy. Win32/IE users often find themselves with several new programs and ActiveX plug-ins after logging into the EX-1600. Others may receive access to fewer resources when auto-loads are cancelled or fail due to OS/browser limitations.

In our demo VPN, Suppliers with Win32/IE could reach the SafeWindows zone when the Aventail Access Manager, Web Proxy, and an ActiveX endpoint interrogator were allowed to auto-load. However, the same Supplier using Firefox with Java disabled ended up in the Default Zone, without TermServer access. This is precisely how we wanted our policy to work, but we found that debugging SSL VPN policies on each and every supported endpoint can take some effort.

Webified applications
Using a browser to access web applications, including portals like Outlook Web Access and servers like IIS, is fairly intuitive. SSL VPN policies may pull a few tricks under the covers, like mapping external aliases to internal URLs and using single-sign on to supply credentials, but users interact with web apps remotely in very much the same way that they do back at the office.

However, some very common business applications are not web applications. Many users wish to access those applications from ordinary browsers on unmanaged devices. To accomplish this simply, without a TCP proxy or network connector, many SSL VPN products supply a few "webified" application GUIs written in ActiveX or Java.

For example, the EX-1600 provides a webified version of Network Explorer, accessed from the Aventail WorkPlace. Clicking on Network Explorer launches an ActiveX control or Java applet in a browser window (see figure). This GUI enables web-based access to native Windows Network Neighborhood (SMB) resources, including shared files, folders, servers, and entire workgroups.

Through this webified Network Explorer GUI, users can access fileshares by clicking on WorkPlace-defined shortcuts, navigating displayed shared servers and folders, or typing in the full UNC path name (//server/share). However, each user can only perform the operations permitted by SSL VPN Access Rules.

For example, Figure 5-10 shows a user with read-only access to the share named PXP2. This user can view and download shared files, but lacks the rights to create, copy, rename, or delete those files. In our demo VPN, PowerUsers were given read-write access and could perform those operations—either directly over a network tunnel, or using a browser and this Network Explorer. This webifier can be used from non-Windows desktops and laptops, but not phone micro-browsers.

The EX-1600 also provides webified access to Windows Terminal Services (WTS) and Citrix terminal servers and server farms. WTS agents are supplied along with the appliance in ActiveX and Java format; Citrix agents can be purchased separately. Earlier, Figure 5-8 illustrated a Supplier using a TermServer shortcut to launch the WTS ActiveX control. In Figure 5-11 (below), we offer a few more details about that TermServer.

A TermServer shortcut links the ActiveX or Java webifier to the port and native protocol used by the appliance to reach the back-end terminal server. Attributes like domain / username / password can also be passed to the back-end server at session connect. We used the "forward static credentials" option to let Suppliers reach a single WTS, without disclosing the actual Windows login required to do so.

Graphical TermServers can also be used to reach back-end applications not otherwise accessible through a VPN. For example, a legacy application that doesn't speak web or support TCP clients might still be reached by launching a TermServer to a device inside your VPN that runs the legacy application's native GUI. However, only users with Web Proxy or better SSL VPN access can use TermServers; this webifier is not supported on endpoints that default to Translated Web Access.

Finally, note that Figure 5-11 depicts a few options that can be configured for other web shortcuts. Our demo VPN made very limited use of handheld devices, but we could have leveraged custom browser profiles to deliver access from other handheld devices, like WAP and i-mode telephones that use micro-browsers. Browser profiles can help you adjust user/endpoint access to fit small footprint device screens and capabilities—for example, by cutting down the shortcut list.

Series conclusion
In this series, we examined the benefits and limitations associated with using SSL as a platform to deliver secure remote access. We demonstrated the breadth and depth of this technology by using the SonicWALL Aventail EX-1600 to implement example policies used to secure remote access by a diverse collection of users.

We hope that creating an actual demo VPN to satisfy a few ISP remote access requirements helped you understand how and why SSL VPNs differ from IPsec predecessors. In fact, the right remote access solution for your business may well be multiple solutions. Over time, many companies end up with a mixture of remote access platforms to satisfy varied user needs and device limitations. SSL VPNs are promising precisely because they are designed from the get-go to deliver multiple access methods and granular access policies through a unified appliance and policy engine.

We would like to thank SonicWALL Aventail for letting us test drive the EX-1600 as we developed this series. They neither held nor tied our hands as we experimented with this appliance at length, so any errors in policy or description are our own.

However, bear in mind that SSL VPN appliances are a diverse lot. Policy details, access methods, endpoint checks, and agents vary quite a bit from product to product. Don't assume that the illustrations appearing in this primer represent all SSL VPN products. To learn more about the SSL VPN market, visit Secure Access Central or check out the VPNC SSL VPN features chart.

—End

< Back to page one

< Back to page two