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]

TCP proxies and port forwarding
In our demo VPN, giving Customers and Suppliers full-blown network access would have been inappropriate, since we wanted to restrict those "outsiders" to very specific resources. In fact, we did not even want to give our trusted "insiders" network access from risky endpoints like home PCs or smart phones. For those Communities, we used Port Forwarding by TCP proxies.

The Aventail EX-1600 offers three such access methods:

Aventail Connect Proxy: An installed Win32 SSL VPN agent that supports TCP client/server applications, web applications, and fileshare operations.

Aventail Connect Mobile: An installed Windows Mobile SSL VPN agent that also supports TCP client/server and web applications, but not fileshares.

Aventail OnDemand Proxy: A temporary ActiveX or Java SSL VPN agent, similar to Connect Proxy, but available on Windows and non-Windows endpoints.

These access methods bind a VPN proxy agent to selected TCP ports on the endpoint. Native client applications open TCP sessions to those ports in the usual fashion; the proxy tunnels those ports securely through the SSL VPN appliance. The trick is to map the right ports needed to reach desired applications and resources—and nothing more.

On non-Windows endpoints, this must be done the old fashioned way by configuring a static list of TCP ports (see Mapped Mode in Figure 5-4). Here, we map ports 143, 110, and 25 to our mail server. Not only is this tedious in a complex VPN, but Access Rules that permit Resources without corresponding Port Maps will not work. Fortunately, Aventail's proxy can also insert itself into the TCP stack to dynamically redirect sessions to any permitted Resource (see Redirection List in Figure 5-4). However, Dynamic Redirection only works on Win32 endpoints with admin privileges.

Access methods for each Community determine whether the TCP proxy tries to use Dynamic Redirection or Mapped Mode. In either case, when the proxy runs, users can view the list of mapped ports. We found this helped us understand which applications were actually being proxied and which were not. In fact, this motivated us to whittle down our port maps, since they are global. (We could not see a way to define per-Community port maps.)

To use a TCP proxy on endpoints that are managed, install Connect Proxy (Win32) or Connect Mobile (Windows Mobile). Both packages are distributed and installed out-of-band—for example, Connect Mobile must be pushed to smart phones using ActiveSync. However, no user configuration is required, beyond entering the public-facing hostname or IP address of the VPN appliance. All policies (including port maps and access rules) are maintained on the appliance and provided to the agent at connect time.

Below, we show the Connect Mobile agent running on a Motorola Q smart phone (see figure). We opted to launch this agent manually, but it can also be run at start-up. Whenever the agent was running and logged into the VPN, users could exchange POP, SMTP, and IMAP securely with our private mail server. Under the covers, those mapped sessions were proxied through our VPN appliance. Other applications used on the smart phone at the same time (like public web access) were not affected.

To use port maps on public or third-party endpoints where it is impractical or impossible to install persistent agents, use the Aventail OnDemand Proxy. Like OnDemand Connect, OnDemand Proxy can be auto-loaded each time a user connects to the VPN portal. Alternatively, you can let a particular Community launch the OnDemand Proxy manually by clicking a shortcut on the VPN portal's home page.

For example, we gave our Customers access to both webmail (Outlook Web Access) and POP/SMTP/IMAP mail. Here, Customers can use OWA from any kind of endpoint, but can only use native POP clients (e.g., Outlook, Eudora, Thunderbird) when logged into the VPN from a Java or ActiveX-enabled browser, after clicking the OnDemand Agent link shown below.

We recommend auto-loading the OnDemand Proxy for Communities with compatible endpoints, so that users don't have to remember (or forget) to launch it. However, auto-loading can be inconvenient, inappropriate, and/or fail on public or third-party devices where you don't really want to install any software or ActiveX controls. In all cases, it is important for users to understand that proxies protect selected application sessions to authorized destinations. SSL VPNs are granular by design; users cannot assume that everything they might send over unsafe links (e.g., hotpots) will be encrypted.

Go to page three: Web-based applications >