The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 1: SSL VPN 101

If you would like to read the other parts in this article series please go to:

• The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 2: IAG Connectivity Options
• The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 3: IAG File Access and Security Options

As many of you who have been reading the ISAserver.org newsletter might know, Microsoft has recently released its SSL VPN offering, known as the Intelligent Application Gateway 2007 (IAG 2007). The IAG 2007 provides SSL VPN services that have been sorely lacking in the Microsoft stable of security products. With the introduction of the IAG 2007, Microsoft now has a complete line of security products for the network edge, for server services protection and for client protection.

However, before you can get a good understanding of what the IAG 2007 has to offer you, you need a grounding in SSL VPNs. Since Microsoft network admins might not have experience with the concept of an SSL VPN, I thought it might be a good idea to provide an “SSL VPN 101” course for you all. Actually, I have to give Wayne Small of SBS fame the credit for this idea, as he mentioned that this would be a good idea at a recent IAG 2007 class I delivered recently.

In this article we will discuss the following:

• History of SSL VPNs
• What Every SSL VPN Has

History of SSL VPNs

SSL VPNs were introduced to solve a problem. The problem was the complexity and difficulty in providing employees remote access to corporate hosted applications. The oldest solution to this problem was the dial-up RAS server. The problem with dial-up RAS was that it was painfully slow, and supporting an enterprise wide dial-up solution could be a very expensive proposition. If you’ve been in this business since pre-Internet days, you’ll remember your RAS modem banks with fondness (not so much!).

The remote access scene changed significantly with the introduction of the Internet and high-speed Internet connections. Using the Internet, the company no longer needed to maintain those unwieldy modem banks. Instead, they replaced those modem banks with VPN servers. The VPN servers could accept connections from any host connected to the Internet and provide network-level access to corporate resources to just about any application and support all application protocols, in the same way as hosts that are directly connected to the corporate network.

At first, it seemed that VPN technology was the ideal solution. Using a Microsoft VPN server with the Windows NT RRAS service, we could connect using PPTP (and later L2TP/IPSec) and get total access to the company network, just like what we had when sitting in front of our corporate desktop computers. When connecting over fast Internet connections (like an ISDN 128kbps line), the experience was vastly superior than dial-up modem connections. Things got even better when real high speed connections, from 1.5Mbps and upward, became available from home, hotels, and conference centers.

However, as good as the VPN solution felt initially, it began to lose some of its luster. Why? Because there were soon to be discovered drawbacks to our beloved network level remote access VPN solution:

• Users had to remember to click the VPN icon on the desktop before firing up their applications, such as Outlook or a database client app. Users expect things to “just work”
• VPN client configuration can be complex. Users generated Help desk calls because they couldn’t figure out how to correctly configure their VPN client software
• Even when the VPN client is correctly configured, it might not work in some environments. This variable functionality of the VPN client software generated even more help desk calls and increased expenses
• The VPN client needs to be on a different network ID as the destination network that the VPN client is calling. When the VPN client is on a network ID that is the same as the destination network, packets cannot be routed correctly over the VPN. This became increasingly problematic as hotels began to provide Internet services to customers, but often used the same private address network IDs that companies use.
• Because PPTP has security issues when complex passwords are not in use, there was an increased adoption of L2TP/IPSec. The problem is that in order for IPSec to work correctly, all devices participating in the connection must support NAT Traversal for IPSec, as NAT will break IPSec under normal circumstances. Not all devices supported NAT traversal, and even the Windows XP SP2 and Windows Vista teams have contributed to this problem by breaking NAT Traversal right out of the box for these clients (it can be fixed using a Registry entry).
• Traditional VPN connectivity enabled complete network access once the VPN connection is established. The VPN connection thus was effectively a universal firewall bypass port where external users could share their viruses, worms and other exploits with the corporate network. This continues to be a major problem, unless you use an advanced VPN server and firewall like the ISA 2004 or ISA 2006 firewall
• Users located behind firewalls had to hope and pray that there was either a PPTP NAT editor on that firewall (which was often not the case) or that the L2TP/IPSec NAT-T ports were open. In many cases, only TCP 80 and 443 were open. Although there was never a serious security reason for limiting outbound access to only these ports, it was and continues to be a popular peccadillo for network operators at hotels and convention centers.

With all of these problems in mind, the concept of an SSL VPN was born. The initial goals of the SSL VPN were to provide:

• Seamless access through firewalls
• A remote access solution that would work from anywhere, regardless of the existence of NAT devices
• A “clientless” solution, so that users would not need to install or provision complex VPN client software

Early SSL VPNs provided these features. However, they were simple devices that provided little more than reverse proxy capabilities for already Webified applications. This is one of the reasons why networkers have always had a large distaste for the term “SSL VPN” because the early SSL VPNs were not VPNs at all – they didn’t provide any measure of network level connectivity and only provided remote access to Webified applications.

However, as SSL VPN began to mature a bit, you could find that there were essentially four types of access, or types of devices (some devices would provide more than one type of SSL VPN). These four types of SSL VPN were:

• Simple reverse proxy devices supporting only Webified applications. An example of this would be the ISA Firewall’s Web Publishing feature set. There was nothing at all to these implementation to suggest anything related to VPN. However, these devices did support pre-authentication and URL rewriting, which made some somewhat more secure than a reverse NAT solution.
• Protocol tunneling. Clients and gateways that supported tunneling application protocols in an SSL session. An example of this type of SSL VPN would be the Outlook RPC/HTTP client and RPC/HTTP proxy. The Outlook RPC/HTTP client tunnels RPC/MAPI calls in an SSL encrypted sessions and forwards these to the RPC/HTTP proxy. The RPC/HTTP proxy then detunnnels RPC/MAPI communications and forwards them to the mailbox server.
• Socket or Port forwarding devices that would install client software that would listen for calls on specific port or socket, intercept those calls, and forward them to the SSL VPN gateway over an SSL link for detunneling. An example of this type of SSL VPN would be when a local SOCKS proxy is installed on the client and is configure to incepted calls to TCP port 25 and 110 and forward those connections to the SSL VPN gateway, there they are detunneled and forwarded to the mail server.
• True SSL VPNs. These types of SSL VPNs enabled true network layer access to the corporate network. The clients are assigned a valid IP address on the corporate network and all protocols are supported, bidirectionally, between the SSL VPN client and hosts on the corporate network. This type of SSL VPN provides the same type of user experience as traditional network level VPN servers and protocols.

Something every SSL VPN solution had in common at that time (and even to a significant extent now), is that the vendors were very good at not providing any useful information about what exactly their technology did. All you could get from the SSL VPN vendor Web sites was marketing drivel about “access from anywhere” without any useful information on what the product actually did.

This left it up to the consumer to make up their own definitions of an SSL VPN. This became even more so the case when the SSL VPN “buzz” started to get louder, and customers came from all over the place saying that they needed an SSL VPN, even though they really had no idea what an SSL VPN solution was, or what it would provide them. All they knew was that it was the next big thing and they had to have one before they were all gone.

Many potential SSL VPN customers decided that what they needed was remote access to file shares without using a network level VPN connection. They knew that SMB/CIFS was not a good protocol to allow over the Internet, so they thought this was what an SSL VPN must be used for. Other people thought that an SSL VPN was the same as a network level VPN, but that it allowed you to get past “restrictive” firewalls (isn’t that what firewalls are supposed to do, restrict access?). Why would it be called a VPN unless it actually was a VPN?

One thing that was missing from the discussion of SSL VPNs was security. This is likely due to the fact that traditional “hardware” VPN gateways at the time didn’t provide any security either. Instead, traditional “hardware” VPN and SSL VPN gateways were solely focused on privacy by sending information over an encrypted tunnel. There was no security, because there was no application layer inspection done on any of the communications moving through the tunnel, and so remote access users could freely share their viruses, worms, trojans and other exploits with the corporate network.

Even more significant than the ability of malware to travel over these unsecured tunnels was the increased probability that skilled hackers could gain access to the traditional VPN gateway or SSL VPN gateway and then leverage that access to execute subtle, but powerful, application layer attacks against servers on the corporate network with the aim being to steal, change, or destroy critical data without leaving a trace of his activity. The remote access solution suddenly became just another powerful vector of attack for the bad guys.

The SSL VPN guys quickly discovered that while they solved a number of problems related to remote access, they enlarged the already wide security hole that was created by the traditional “hardware” VPN vendors. With the advent of SSL VPN, more and more users could gain access to the corporate network, which opened more and more unsecured connections to the corpnet. This quickly became an intolerable situation and was another problem that the SSL VPN guys had to solve.

What Every SSL VPN Has

Many of SSL VPN vendors realized that leaving such a large security hole in an otherwise very useful remote access solution was something that had to be fixed, and fixed quickly. This led to the current generation of SSL VPN features that every SSL gateway has. These features are implemented at the client and at the gateway, as seen in the figure below.

Figure 1

Every enterprise-ready SSL VPN solution today needs to include the following features:

• Tunneling All SSL VPN gateways should be able to tunnel both Web and non-Web applications and application layer protocols within an SSL session.
• Client side security All SSL VPN gateways should be able to provide some type of endpoint detection that provides a means of evaluating the current health status of the SSL VPN client system. The goal is to prevent systems that do not meet network security policy guidelines from connecting to the network. Endpoint security is especially important in an SSL VPN scenario because users could literally connect from anywhere, from a friends computer that the kids also use to the dollar an hour kiosk at the local watering hole. It could not be taken for granted that SSL VPN clients were not infected or not run by malicious attackers.
• Pre-authentication External users should never be able to create a direct session with a corporate server. Not even for authentication attempts. A viable SSL VPN gateway should be able to pre-authenticate users at the gateway and then after authenticating and authorizing that user, delegate those credentials to the published Web server. There should also be support for authenticating non-Web protocols as well.
• Authorization The SSL VPN gateway should be able to provide allow and deny access to either or both the portal or the applications hosted in the SSL VPN portal.
• User Portal The user portal is a web page that users visit to access the applications that are made available to SSL VPN users after they log onto the portal. Users only need to remember the URL to the portal page. Once they reach the portal page, all their application will appear in the list provided on that page. Users do not need to remember specific URLs for each application they need remote access to.
• Application Layer Inspection In order to qualify as an enterprise grade SSL VPN gateway, the solution must provide some form of application layer inspection. Application layer inspection might be limited to only HTTP/HTTPS connection, or more robust solutions would include application layer inspection for other protocols, such as SMTP, POP3, RPC, IMAP4 and other commonly used protocols that are tunneled to the SSL VPN gateway.

As you can see, the concept of an SSL VPN has changed and evolved quite a bit since its initial presentation as a simple reverse Web proxy server. Today’s modern SSL VPN provides all the features that define SSL VPN: reverse proxy, tunneling of Web and non-Web protocols, and true network level connectivity over an SSL session. Not only that, but today’s SSL VPN provides not only privacy for the connection, but some level of security, because of application layer inspection.

Summary

In this article I provided you with a short review of SSL VPNs, starting with the short history of SSL VPNs and their early definitions, to the SSL VPNs we see today. In the next article in this series of articles on SSL VPNs, I’ll talk about the IAG 2007, which is built on a hardened Windows Server 2003 box with the ISA Firewall to keep it safe. In that article, I’ll point out what I think the most significant features and technologies are, and point out where the IAG 2007 stands above the competition in the SSL VPN space.