If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.
Introduction
We’ve always been big remote access fans here in the “Shinder compound” in Texas. I remember the first time we put together a Windows NT 4 based routing and remote access server and configured it as a PPTP VPN server. Way back then, we had never used a VPN before and didn’t know what to expect of it. We didn’t have two Internet connections available at that time (we had only one POTS phone line) at our home, so we decided it was a good excuse to take a short vacation to a hotel that had “modem ports,” to which we could connect the IBM laptop and test the VPN connection.
We got to the hotel and plugged the laptop into the modem port. The first think we had to figure out was the phone number for our ISP so that we could get an Internet connection. In the “dinosaur days” of the 1990s, it wasn’t like it is today, with Internet connectivity virtually ubiquitous (at least in U.S. metropolitan areas). Fortunately, I was able to call my son at home and he was able to read the phone number to me from the demand dial interface settings on the server. I entered the dial-in information for the dial up client on my Windows 95 computer and made the connection.
We waited with great anticipation as the modem connected to the ISP, making that rubber band jaw harp sound when it negotiated the hyper-fast (for the time) 28.8Kbps connection. Now was the moment of truth – would the VPN connection work? And if it does, how will I know? Will I actually be able to get files that are on my PC at home, even when I’m at a hotel 20 miles away? I fired up the VPN client software and clicked “Connect”. It looked as if something good was happening, so I entered the UNC path for a folder on my workstation at home and almost like magic, I had access to files on my home computer!
That was then; this is now
We all take this stuff pretty much for granted now. Virtual private networking is pretty tame stuff in a cloudified world. Remote access to files and folders and web sites and just about any kind of information you need is a trivial affair. There are many different ways you can gain remote access to your information. You can configure a VPN server using Windows, you can configure a cheap NAT router to act as a VPN server, you can publish your computer via remote desktop publishing, you can set up a remote desktop server and gateway. Or, you can just put all of your information in a cloud storage system such as Microsoft SkyDrive and not even worry about enabling remote access to a private network; simply connect to the cloud resource and away you go.
Of course, things are a bit more complicated for businesses. Business networks contain a lot of proprietary information that needs to be kept segregated from any public networks. Not only is this good business, but in many cases it’s the law or at least an industry standard. Organizations today are duty bound to secure their networks from intruders. But at the same time, they still need to give employees the ability to gain access to the information they need, when they need it, wherever they need it. It can become quite a balancing act for the network and security admin to serve all the masters.
That old time VPN
Many organizations still cling to their VPNs just like I cling to my old time rock and roll. But, while today’s music might not have any soul, today’s technologies have a lot to offer. Historically, though, at least in terms of recent history, most organizations have continued to depend on VPN solutions to enable remote access to corporate resources. There are good reasons for that. VPN technology is well understood, the threat landscape is well defined, and network administrators have a lot of experience with VPN solutions.
The problem with VPN solutions is that they are a bit of a pain for the typical non-techie end user. The user has to start the VPN client, figure out how to use the VPN client, and then hope that the VPN protocol the client uses isn’t blocked by the firewall or web proxy they’re behind. Also, there are big issues with overlapping network IDs. I’m sure you have had the painful experience of being in a hotel room where your computer was assigned the same network ID as the one that was in use on your corporate network. This was a show stopper for most users (There is a workaround, but you have to be fairly technically sophisticated to use it, and it involves the end user having to use the command line interface).
So while VPN solutions are able to provide users with the remote access to file and folders and services on the corporate network that they need, the overall experience is less than optimal. There’s too much user overhead, too many potential issues that can block the connection, and too many moving parts that can break. There had to be a better way.
VPN 2.0
The search for a better way came to fruition in the first half if the first decade of the twenty first century. The solution was called an “SSL VPN”. As with the situation with “cloud” today, SSL VPN was a somewhat nebulous term, used to describe anything that allowed users remote access to corporate resources over a SSL connection. It didn’t matter whether it was actually a VPN connection; it only had to be done over SSL to earn the label. And there was a ton of hype disseminated by the vendors when it came to their “latest and greatest” SSL VPNs, which explains why these solutions tended to be so costly.
What is an SSL VPN? SSL VPNs typically provide a remote access connection over SSL using one or more of the following methods:
- Reverse Proxy. Yes, that’s right. Many vendors thought it would be cool to call an SSL reverse proxy solution an SSL VPN! Using that definition, you could have called ISA Server 2004 an SSL VPN solution, since it supported reverse web proxy for SSL connections. Most technical folks weren’t fooled by this and considered reverse web proxy based SSL VPNs to be nothing more than marketing hype.
- Port and Socket Forwarding. This type of SSL VPN can use a client side piece of software to intercept defined ports and sockets and then wrap those in an SSL header. The SSL header is then stripped from the connection at the point of the SSL VPN server and forwarded to the destination. The problem with this is that the SSL VPN vendors claimed that SSL VPNs were “client-less”. In addition, this isn’t a true VPN solution, since there is no virtual network PPP connection established to the destination network. Again, this smelled and felt like hype.
- Protocol Encapsulation. This method takes advantage of the fact that you can encapsulate virtually any protocol in an HTTP header and then encrypt it with TLS and have it use TCP port 443 for network access. This is how the original and subsequent versions of the RPC/HTTP protocol work for Outlook and Exchange. It’s pretty nifty. Unfortunately, you need to have a protocol gateway for each protocol that you want to use and the protocol wrapper has to be built into the client application. The end result is that you can access some of the information on the corporate network, but it is far from a native “on network” experience.
- True SSL VPN. Some vendors actually provide a true SSL VPN solution. By “true,” I mean that a real PPP negotiation takes place after an SSL connection is established with the SSL VPN server. After the negotiation, the client has a virtual network connection to the destination network and is assigned a valid IP address on that network. All protocols are accessible, just like with a traditional VPN. After the buzz died down on the entire SSL VPN craze, Microsoft subsequently came out with the Secure Socket Tunnel Protocol (SSTP), which provides a true SSL VPN connection, and included the client on Windows 7 and above clients.
SSL VPNs were popular for a short period of time because they promised to be more flexible than traditional VPNs. The problem with them is that they never were truly “client-less” and they are prohibitively expensive. Again, there had to be a better way.
Enter RDP
Terminal services was something that a lot of people first enjoyed using when working on the corporate network. They could gain access to a full desktop environment by connecting to a terminal server. But what if you could do the same thing over the Internet? Even though the client system was on the Internet and didn’t have direct connection to the corporate network, the client could connect to a system already on the corporate network and work on that system, which had full access to the network. That provides a viable remote access solution.
That led to the increasing popularity of using Virtual Desktop Infrastructure (VDI) as a remote access solution. The term VDI is often misused. The technically correct definition of VDI is when you provide dedicated virtual machines that are remote desktop server enabled to each of the users who want to connect to the network. However, the term has also been used to include traditional terminal servers where multiple users connect to a single terminal server and that server is able to provide multiple sessions. Both the shared sessions terminal server and VDI can provide solutions for remote access to the corporate network.
The remote desktop solution can be further improved by taking advantage of a terminal services gateway. In this way, the end users can use an SSL connection (which encapsulates the RDP protocol) to connect to the terminal services gateway, and then the gateway or a companion device can broker the connections to make sure the connection is forwarded to the appropriate terminal server. This ends up being a decent solution. But it still requires that the user “do something” in order to make it happen. It is not a totally transparent solution.
Remote Access done right
It seemed that we were getting closer and closer to what we want and what our users need, but we never really seemed to get there. Then those days came to a close when Microsoft introduced a solution that meets all of our requirements as network and security administrators, and meets all the requirements of our users. That solution is DirectAccess.
And that’s where we’ll begin in the second part of this article series. We’ll talk about DirectAccess as a secure remote access solution and then get to the heart of the matter: which form of DirectAccess should you use: UAG DirectAccess or Windows Server 2012 DirectAccess? They have similar capabilities and features, but what sets them about? Stay tuned for Part 2, where we’ll begin the battle of the Titans: UAG versus Windows Server 2012 DirectAccess. See you then! –Deb.
If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.
