How to: Get Secure Remote Access with SSL VPNs (Part 2)

By Lisa Phifer

December 15, 2008

In part two of this five-part series, wireless security expert Lisa Phifer explains how to deploy an SSL VPN appliance.

In Part 1 of this series, we explored the appeal of SSL VPNs and why many organizations are using them to augment or replace older IPsec VPN remote access concentrators. Next, we will illustrate how SSL VPN appliances work by taking you on a guided tour of the SonicWALL Aventail EX-1600 (from $9,995). Aventail EX-1600SonicWALL logo

Not your father's VPN

The remote access market has evolved considerably over the years, as pure-play SSL VPN vendors like Aventail made a splash and were then acquired by larger network companies. Today, enterprise SSL VPN appliances are available from over a dozen vendors, including SonicWALL (acquired Aventail), Juniper (acquired Neoteris), F5 (acquired uRoam), Citrix (acquired Net6), Cisco (acquired Twingo), and Microsoft (acquired Whale). For roll-your-own fans, SSL VPN software is also available as open source (e.g., OpenVPN).

We chose to illustrate SSL VPNs with the SonicWALL Aventail EX-1600 appliance because many of the managed security service providers we surveyed over the years used this product line. This well-known appliance also supported the diverse collection of SSL-based access methods that we wanted to illustrate in this series.

We installed the EX-1600—a SonicWALL "e-class" SSL VPN appliance for mid-sized companies and enterprise departments with up to 250 concurrent users. Organizations with 50 users or less can buy the smaller EX-750, while large enterprises can cluster up eight EX-2500s, supporting up to 2000 users apiece. Our EX-1600 ran Aventail 9.0 software and was priced at $9,995 for 25 users.

Appliance installation

The EX-1600 is a 1U appliance powered by an Intel Pentium 2.4 GHz CPU. We dropped this into our DMZ, operating in dual-homed mode. That means that we connected the unit's outside 10/100 Ethernet port (through the DMZ) to the public Internet, while connecting an inside Ethernet port to a private network containing resources we wanted authorized users to access.

Alternatively, we could have deployed the EX-1600 in single-homed mode, sending and receiving all traffic through one DMZ port. But single-homed deployment would not have given users access to LAN resources that we wanted to expose—most notably Windows fileshares—because those assets were not DMZ-reachable. The appliance also needed to reach our LDAP and RADIUS authentication servers, our private DNS, and (optionally) SNMP and Syslog servers. Dual-homing seemed easier and safer.

Most SSL VPN appliances—including the EX-1600—are not designed to terminate site-to-site VPN tunnels. SSL VPN appliances serve as access concentrators; they should be placed behind (and protected by) a perimeter firewall. However, that firewall must let Internet traffic arriving on TCP ports 80 and 443 reach the appliance for most SSL VPN access methods to operate correctly.

Next, we identified the public IP address and hostname used to reach the appliance. All users visit this URL, and the appliance must prove its own identity using a digital certificate bound to this hostname. As we later learned, when custom SSL VPN portal pages are presented to different user communities, you may actually prefer to reach those through their own unique virtual IPs, hostnames, and certificates.

For our test purposes, a single appliance was plenty. However, when SSL VPN is deployed in a production network, high availability may be needed. The EX-1600 can be deployed in identical load balanced active/active pairs, using a third GigE port to continuously synchronize configuration and state between them.

We completed installation by supplying the usual pre-requisites using a Set-Up Wizard (see Figure 2-1 below). The only tricky question concerned routing mode: dual gateway, single gateway restricted, single gateway unrestricted, or no gateway. We ended up trying this more than one way before settling on single gateway unrestricted, so that remote users could access the internet through the appliance.

Click to view larger image

Fig 2-1: Aventail Setup Wizard

Who goes there?

The EX-1600 Setup Wizard offers to configure a basic security policy for you, creating local user account(s) with a few simple resources and access control rules to sanity-check your installation. We created test users with closed access to a few private servers and the appliance implicitly denied access to everything else. This helped us get going, but our "real" security policy required far more planning. Immediately after installation, the Aventail Management Console (AMC) displays a setup checklist (see Figure 2-2).

This checklist guides you through policy implementation and questions that must be answered (that is, the policy elements that must eventually be defined). Which users and groups require remote access through this appliance? What kind of application resources do they need to reach? What access methods will they use, and will you place any restrictions on endpoint devices?

Click to view larger image

Fig 2-2: Aventail Management Console

In other words, to illustrate key SSL VPN concepts, we had to come up with an example scenario: a security policy that we intended to implement. After a good bit of trial and error, we came up with the following business goals for our demo SSL VPN.

  • Service providers must give their staff access to sensitive resources for troubleshooting and service restoration. Those users are generally privileged and need to reach many resources to get the job done. We decided to give these "power users" full network access, but only from known, trusted endpoints.
  • Service providers also need to provide employees with secure off-hours or travel access to ordinary business systems, like Webmail and fileshares. So we gave all staff members (including power users) access to a set of private resources like these from any endpoint device—including public PCs and Windows Mobile.
  • Many organizations—including ISPs—want to give authorized suppliers very tightly-controlled access to selected systems. To illustrate this, we created supplier accounts in our domain and used group membership to grant access to a single Windows Terminal Server, from endpoints that passed security checks.
  • Providers that host collocated or managed application servers may give their customers remote access to specific systems and applications inside the data center. To illustrate this, we configured policies that authenticated three customers by checking their own Active Directory servers. Authenticated users were then given access to their own private Web site, hosted on a shared server, to demonstrate granular access controls and custom portals.
  • Finally, managed security service providers often sell SSL VPN services. Most sell or rent an SSL VPN appliance to each customer, deployed at the edge of the customer's network or at the provider's data center. For this demo, we just gave each customer exclusive access to a unique IP address range. This example is very over-simplified—real customers would want granular policies of their own.

Coming up next

Once our SSL VPN appliance was installed and we had a rough idea of what we wanted to use it for, it was time to translate our security policy into rules that controlled and secured access through that appliance. In Part 3 of this series, we illustrate this process, using the EX-1600 to implement the policy outlined above. Stay tuned...

Article courtesy of ISP-Planet. For Part 1 in the series, click here.

Originally published on .

Comment and Contribute
(Maximum characters: 1200). You have
characters left.