Does this site look plain?

This site uses advanced css techniques

Almost everybody running a small office wants some kind of remote access: check email, fetch a document, look up a phone number, or run a line-of-business application. It could be just a quick visit to the system while in a hotel on the road, or it could be getting work done while home with the kids on a day off from school.

Table of Contents

Unfortunately, there are as many variants on remote-access as there are reasons to want it, and these choices, and choices-within-choices, are often entirely bewildering even to experienced IT staff.

Faced with these requests from multiple customers, we decided to research the field and enumerate the choices available, and (especially) the pros and cons of each. Not all environments are the same, and though we believe some choices are head and shoulders above the others, one must nevertheless weigh the tradeoffs for oneself given the particular circumstances of the given installation.

We're explicitly targeting the small-business space (as noted in the Assumptions), because not only is the corporate space so much larger, but also because we simply have no experience with it. We suspect that many of the points apply universally, but enterprises with thousands of users are different from companies with just a few.

It's our goal for this Tech Tip to be a comprehensive survey of the available remote-access mechanisms, as well as a fair presentation of the pros and cons involved.

Important Notes

Assumptions About the Environment

It's simply not plausible to think that we can write the definitive paper on remote access for every circumstance, so we have to make some assumptions to narrow the scope of our inquiry. Though many of these notes apply anywhere, we believe that by limiting ourselves to the small office running Windows Small Business Server 2003, we'll hit users most in need of this information.

We only consider SBS2003 with IIS6
SBS2003 Logo SBS2003 is Microsoft's latest Small Business Server system, and it contains features specifically targeting remote access. At least one (Remote Web Workplace) is available only in SBS2003, and this is our favorite remote-access solution for many users.
Nick Burns, Your Company's Computer Guy Customer installations often have limited IT staff
SBS customers commonly rely much more on consultants to do most IT tasks, sometimes farming out even help-desk operations. Solutions for remote access which can be self-served are much more highly preferred than those which require ongoing expert care and feeding.
Customer have a general unwillingness to buy more hardware or software
In this space, almost nobody is going to buy a separate machine to put in a DMZ for (say) Outlook Web Access, and are likely to be unwilling to do so for a Terminal Server system as well.
This unwillingness may not extend to the proper hardware firewall or VPN server, because these are seen as more "ordinary", but solutions which work with existing installations are going to be very highly preferred.
Laptops move inside and outside the network
A Laptop A laptop moving both inside and outside the network is more difficult to configure than a desktop remaining inside the network entirely: the former is a moving target which generally needs at least two configurations to operate properly.
Solutions proposed must take into account these multiple environments and not present an onerous burden to change from one to another.

Common Concerns

Most access mechanisms present their own particular set of tradeoffs, but there are some common themes which occur again and again. Here we'd like to elaborate on some of those concerns in some detail.

Where's the data?
We're very concerned about where sensitive data resides, and it's almost always superior to choose an access mechanism which keeps that data inside the corporate network where it can be monitored and protected properly.
Many a security-conscious administrator pales at the thought of sensitive corporate data residing on home computers, or worse, on a laptop that can be stolen or left in a cab. The whole notion of sensitive data can include emails, data files, documents, and even temporary files used by the browser or reporting printing: all can be compromised even temporary data used in printing/reporting) on a computer
For this reason, remote-desktop type solutions (Remote Web Workplace, pcAnywhere, etc.) are a big win because everything is kept inside the enterprise. The downside, of course, is that you'll not get much done while offline.
Companies which maintain personal information about consumers are increasingly falling under mandated-reporting laws in the event of information loss or disclosure must be ultra-sensitive to this issue.
IIS (Internet Information Server) has always made us nervous
We're always nervous about exposing a webserver on the inside network to the outside world. In the SBS space, almost nobody's going to buy a separate machine for a DMZ to provide this kind of protection, so any solutions involving remote web access will bridge the gap completely from outside to inside.
But: since the webserver is typically exposed via https only (via SSL), and it asks for authentication immediately, this may not be such a concern in practice.
Furthermore, IIS6 — included with SBS2003 — has developed such an outstanding track record for security that we're now inclined to consider it on par with all the other remote access mechanisms instead of a specially-dangerous exception.
We would be really nervous about exposing an internal-homed IIS5.x system to the outside world.
Users pick terrible passwords
Really lousy passwords Anything which uses normal user credentials exposed to the outside world is a risk: when the only way to use your Windows logon is when you're already inside the network, in practice you can get away with lousy passwords, but as soon as the outside world gets a crack at them (so to speak), the game changes a lot.
This means we have to enforce password complexity. Yes, we're supposed to do that anyway, but this is often a very hard sell in the small-biz space.
Two-factor authentication (passwords plus smartcard) would go a very long way to alleviating this concern, as well as VPN solutions which use IT-provided access credentials.
We favor solutions which allow us to limit the users which have whatever type of remote access. Most enterprises have users with internal-only needs, so excluding them from external access reduces the exposure of whatever their password quality is.
Remote client installs are inconvenient
Any solution which requires administrative installation of a client component on the user's laptop starts off with a mark in the negative column: it's one more knob to turn, one more thing to misconfigure, one more piece of software to be incompatible with something else.
This is particularly the case with VPN-type solutions, though we're not sure we consider an ActiveX control (with no configuration parameters) in this same category - probably not.
We don't consider the one-time installation of a server component to be onerous or problematic.

Email-only solutions

Since access to email is by far the most common request, and because there are email-only mechanisms, we're putting these in a separate section. By using a limited access mechanism, which doesn't provide more intrusive entry into the network, we can reduce the attack surface of the provided service.

POP/IMAP

The standard protocols POP (port 110/tcp) and IMAP (port 143/tcp) are mature, quite stable and supported everywhere by all email clients.

Pro and Con: POP/IMAP
Pro Works with essentially any email client, including on non-Windows platforms
Pro IMAP can include shared public folders to provide access to shared documents without the use of a VPN.
Pro If DNS is set up properly inside and outside, the same profile works everywhere for roaming users without changing anything.
Con We don't get full-strength Outlook/Exchange integration, including calendaring and shared contacts. However, many mail clients do provide LDAP Directory support for access to the address book.
Con It's really easy to set up insecure connections.
Pro Protocols are well known, and easy to administer in firewalls.
Con Easy target for brute-force password guessing from the outside.
Con Requires a computer configured for this email account; it can't generally be used conveniently from unplanned locations while on the road.
Pro Exchange can control which users can get email this way.

Outlook via RPC-over-HTTPS

With this mechanism, SBS exposes the internal Exchange protocol over HTTPS via the webserver, and Outlook thinks it's actually inside the network with full access to everything. It uses the same MAPI connection as the internal client uses, and one is hard-pressed to find any difference in behavior.

This mechanism has been incredibly popular for secure, functional, remote email. It's new with Outlook/Exchange 2003.

Pro and Con: Outlook via RPC-over-HTTPS
Pro Full-strength Exchange support using the same Outlook client as used inside the office.
Pro Uses https; fully encrypted
Pro This has been wildly popular.
Con Only supported on Outlook 2003; not Outlook Express, not other email clients, not older Outlook
Pro SBS2003 includes Outlook 2003 software and one client access licence for each SBS CAL; no need to purchase an Office license just toget Outlook 2003.
Con Requires a computer configured for this email account; it can't generally be used from unplanned locations whle on the road.
Con Exchange doesn't seem to offer control over which users can get email this way
Con Because this uses real Outlook, this may not be suitable for laptop devices which might be stolen while containing sensitive data (such as locally-stored attachments).

Outlook Web Access

Outlook Web Access

OWA is the browser-based Outlook-alike provided by Microsoft Exchange, and it's been available for some years with ever-increasing quality. When visiting the OWA URL on the SBS server (via HTTPS) and presenting login credentials, it brings up a web page which looks and behaves remarkably like the traditional Outlook client.

It supports email, contacts, calendaring - everything which Outlook does, all from any IE browser which allows ActiveX. There are some inherent incompatibilities due to limitations of what can be supported in a browser application, but Microsoft has done a pretty amazing job recreating the look and feel.

Pro and Con: Outlook Web Access
Con OWA is probably a highly visible target for attackers.
Con It's not quite the same as Outlook.
Pro It works anywhere with essentially no setup, even on machines which you've not been on before while on the road.
Con Because it works so well from anywhere, it can be used from insecure locations, such as an Internet café, where malware (a keylogger) can steal the login information. As the corporate administrator has no way to enforce a "no insecure locations" policy, OWA may not be suitable for users who cannot be trusted to follow security policies.
Pro It's easy to configure with secure transport (https only).
Con Internet Explorer is the only supported browser: the others may work to some degree or other, but it's not considered a bug if it fails to work properly in (say) Firebox or Safari.
Con Provides access to server-based resources only; no desktop-local access. Many users have personal .PST files with email archives and contacts, but these are not visible through OWA.
Pro Exchange can control which users can get email this way.
Con Requires Microsoft Exchange Server; other mailservers such as MDaemon (and many others) won't use it. But most alternate mailservers provide their own web-based email.

Remote Application-Level Access

For many users, email-only access is sufficient, but others require more access to the inside network. Whether it's to grab something from one's own desktop, to manage the servers, or to run an internal line-of-business application, there are numerous mechanisms for remote access beyond email.

This does not include, however, the more low-level IP access provided by Virtual Private Networks; that's saved for a later section.

Remote Desktop through the firewall

Remote Desktop icon The Remote Desktop Protocol (RDP) is a pcAnywhere-like mechanism for taking over the screen of a remote system, and it's done very well. It can optimize its behavior depending on the quality of the network link, omitting some aspects of the experience (say, the background image) when the network connection is not fast enough.

Generally speaking, the RDP port (3389/tcp) is blocked at the corporate firewall to forestall outsiders, but some have been known to open it up with a pinhole in the rules to allow remote access.

This makes nearly all security-conscious administrators nervous unless the rules can limit access to known-trusted IP address ranges, but even so this is an unnerving prospect.

Pro and Con: Remote Desktop through the firewall
Pro Probably the best network performance of all the remote access
Con Unless the remote user has a fixed IP, firewall can't restrict who gets in; this presents an enormous security risk. Most responsible security administrators hate this idea.
Pro By default, the connection negotiates the highest level of encryption supported by both ends, and for XP and SBS2003, this is High security mode, though it's possible to select less security by turning some knobs. With Group Policy, one can enable enforcement of high security, refusing to allow connections with less.
Con XP desktops only allow one user at a time, so a remote user may kick off one sitting at the console.
Pro RDP supports remote printing; while working on the office desktop from home, one can print through the session to the printer at home. Likewise with audio.
Pro Active Directory has extensive support for per-user permit/deny access to terminal services
Con Installations with many desktops needing remote access have to either allocate a lot of external IPs, or do lots of port mapping in the firewall behind just a few IPs. This is very cumbersome to administer and support.

SharePoint

SharePoint logo SharePoint is Microsoft's web-based collaboration system, and it's a very popular way to organize company documents, discussion lists, tasks, calendering, etc. It's based on IIS and SQL Server, and it integrates directly into the suite of Office tools.

We'll note that SharePoint is worth considering even without the remote-access component: the collaboration facilities are very powerful when adopted by an enterprise, and it's quite straightforward to administer even without heavy-duty IT staff. Just the ability to apply version control to Word/Excel documents is enough to justify the use of this portal tool. SharePoint Services are included in the SBS client access licenses, but are available at extra cost for Server 2003 platforms.

Pro and Con: SharePoint
Pro Works from anywhere that IE is available with no setup required; great for using while on the road.
Pro For enterprises which actively revolve around SharePoint, this may provide enough access to the collaborative workspace without setting up even higher level IP access
Con Highly visible target for attackers

pcAnywhere and related programs

pcAnywhere icon Symantec's pcAnywhere is the granddaddy in this area, virtually a synonym for the entire "remote access" product space. There are others, such as Famatech's RAdmin.

The products all require installation of an explicit component on both the host being managed, and on each client which will exercise remote-control abilities.

Pro and Con: pcAnywhere and related programs
Pro pcAnywhere has a long history of stability and compatibility.
Con Requires licensing both the host and remote parts (in the ballpark of $100 each)
Con Requires installation, activation, and maintenance of a substantial component on the remote client.
Pro Provides the ability to shadow an existing session; this is wildly popular for providing tech support so the technician can jump on a user's desktop directly and see the error or fix the problem.

GoToMyPc and related programs

This section is incomplete, because we have very limited experience with these other than as a client receiving remote technical support.

GoToMyPC logo Programs of this class (GoToMyPC, WebEx, iLinc, etc.) allow for setting up of ad hoc remote-control sessions, and are widely popular for performing remote technical support.

In the support scenario, the support-ee visits a central website and performs a one-time installation of a local component (usually an ActiveX control), then joins the session already set up by the support technician.

With appropriate permissions, the desktop can be shared back to the support tech's computer where s/he can take over the keyboard and mouse, transfer files, or whatever else is required to service the support-ee.

It's a great way to get one-time support without the need for the client receiving support having to set up a lot of stuff in advance, though the support organization usually needs to open an account in advance. These usually have per-minute or per-usage charges.

These programs are also gaining popularity for remote access to a person's unattended home or office computer while on the road. At a remote site, the user can hit the central website, present credentials, then take over the controlled PC as if he were sitting at the office directly.

Unlike the ad hoc technical support scenario, where the user in front of the PC being controlled explicitly grants permission (usually twice: once to connect to the desktop, a second time to allow the support technician to "drive" the keyboard and mouse), these uses are unattended.

A somewhat different component is installed on the unattended PC, and it "phones home" periodically to the central server where it awaits a rendesvous with a roaming user wishing to join the session.

Pro and Con: GoToMyPC and related programs
Pro Very easy client setup for one-time use
Con Typically requires per-use or per-minute charges, and can get costly when used a lot.
Pro Better support than Remote Desktop for multiple monitors on the controlled PC (at least with GoToMyPC); it seems they've figured something out which RDP hasn't yet.
Con The unattended monitored PC has to "phone home" a lot to the central server, and this is reportedly fairly chatty, as well as with unknown security implications that make some people nervous.

Remote Web Workplace

This is an underused feature which is gaining popularity: It's essentially an authenticated RDP proxied through the SBS webserver. The remote user hits an https:// URL on the web server, which immediately demands access credentials. After login, the user is given the choice of machines to connect to, and an Remote Desktop session starts. The target machine again prompts for its own local credentials.

It uses an ActiveX control, which makes a "real" connection to port 4125/tcp (which must be open through the firewall). This is an encrypted RDP connection, which is received by the webserver and proxies to the target system.

As an added security protection, this port is not generally open to accept connections, only listening when it has a specific request for a connection generated via the web interface. It rejects 4125/tcp connection attempts from other than the IP address which requested it, and it's not listening during any other time. This is a very clever, very secure mechanism.

Remote Web Workplace
Pro Provides secure, remote access to internal desktop via Remote Desktop
Pro Leaves nearly nothing behind on the client after disconnect (e.g., credentials, or other sensitive data)
Pro Heavily secured TCP connection management
Pro Active Directory controls who has access to this facility via the Remote Web Workplace Users group.
Con Not very useful for laptop users on the road who have no "base station" inside the enterprise, though this might be addressed by having one or more standalone XP machines dedicated for these users.
Pro Provides an application-specific tunnel only, not general IP connectivity to the internal network (like a VPN would) which would allow badware to get inside.
Con Requires Internet Explorer to launch and maintain a desktop session (no Firefox, Opera, etc.).
Con No ability to shadow a session: RWW can't be used to provide remote assistance (though it's not clear whether this can be somehow leveraged into the Remote Assistance facility).
Con All RWW users can select from all visible desktops (though they still need credentials to actually login, as well as requiring the right to connect in the first place). This means that one cannot escape thinking about permissions in a domain-wide manner.
Con Seems to require installation of an ActiveX component on the client machine, which has problem problematic in some circumstances (such as a non-admin user). This seems like a minor, one-time inconvenience.
Con RWW doesn't seem to support multiple-monitor desktops (it provides access to just one unified screen), and users have reported their desktop icons moved around after using RWW.

Mobile Devices

We don't know anything about this, but will fill it in here once we learn more.

Virtual Private Networks

This section was saved for last, because it presents the biggest challenges in terms of tradeoffs, and even in understanding just what's involved.

Typical VPN Configuration
Typical VPN Organization

A Virtual Private Network is what amounts to a software Ethernet cable: a special software "tunnel" is created which carries traffic from one system or network to another, and it's done in a secure manner. By allowing a home user to access corporate resources through the tunnel, access can be granted outside the view of attackers. More information on the background of VPNs can be found on Wikipedia.

VPNs present a special dilemma of remote access: the same power which allows remote users to access nearly everything also provides the power for bad things to happen. Site-to-site VPNs which effectively extend the enterprise IP space to the home greatly increase the attack surface on the enterprise: why try to break into the fortress directly when you can sneak in quietly via the out-building connected by an underground passageway?

There are three common security issues involving VPNs which provide unrestricted routing of IP traffic between the two endpoints (in order of increasing concern):

Most modern VPN solutions address this in a number of ways, including NAT and/or firewalling the VPN connection, and running the machine's default gateway through the tunnel. Both of these involve substantial tradeoffs of security, functionality, and manageability.

We believe that the most intrusive tradeoff is pointing the default gateway through the tunnel: in this scheme, the VPN effectively becomes the internet line for the home PC, and all external access — whether to the corporate office or to the internet at large — goes through the VPN.

In this manner, the corporate firewall has an opportunity to inspect all the traffic coming or going, and may be able to apply content filtering and to enforce other policies. Workers may not be permitted to visit any random site on the internet while on company time, or at least connected to the company network.

Long Round Trip
The Long Round Trip

Not surprisingly, offsetting the security benefits of this approach are some substantial limitations: unless the corporate network has excellent, high-bandwidth internet connectivity, the home user is going to see very poor performance when accessing non-corporate resources.

Traffic destined to the corporate network can't help but go through the tunnel, but when all the other traffic goes there too, it has to go through the corporate internet circuit twice.

A user requesting a web page from (say) www.unixwiz.net does so with the standard web request, but the small request packet is routed through the VPN tunnel to the firewall/gateway device. It sees that the traffic is destined for the outside world so turns right around and sends it back down the T1 to the website, where a reply is generated by that site.

The reply goes not to the home user, but to the firewall, which again turns the traffic around back through the internet circuit to the user at the other end of the VPN tunnel.

The main factor influencing the performance is the slower of the corporate internet's upload/download speed. For most business-grade circuits such as a T1, the speeds are the same in both directions, but DSL or cable circuits almost always have asymmetric bandwidth, with much slower upstream speeds than download.

There are other complications with the default-gateway approach, so our feeling is that it's not worth the trouble except for limited applications.

Now we'll touch on the various flavors of VPNs available, though in this space there is tremendous variety where vendors go to substantial lengths to differentiate themselves from one another.

Important - when considering the pros and cons of a VPN solution, it's always based on the presumption that this level of access is actually required. When one can use more restricted access (such as email only, or RDP/RWW), this should be considered first.


Router-to-Router Hardware VPN

In this configuration, the end machines themselves are not building the VPN, but intermediate hardware devices do. Our experience has been using SonicWall units at the corporate office, with small Netopia units in the home.

This is clearly the most powerful, but also the most dangerous.

Router-to-Router Hardware VPN
Pro By default, provides the least restrictions on IP traffic between the two networks.
Con By default, provides the least restrictions on IP traffic between the two networks.
Con Probably the most costly solution; the home router is amortized over only one user.
Pro More suitable and cost effective for branch offices where multiple users are at the remote location.
Con Provides essentially no audit trail to activities done from the home network.
Con Compromise of even one machine at the home location (say, the computer in the teenager's bedroom) can compromise the entire corporate network.
Pro VPN link security maintained by IT staff, not the user.
Pro Nothing to install, configure, or maintain on the home PC or on the servers.
Con Entirely unsuitable for on-the-road use.

Software VPN to gateway device

Here we remove the hardware router from the previous case and replace it with a software component on the user's machine.

Con Costs less than hardware, but still nonzero $ per user.
Pro Link security maintained by IT staff through policies.
Con Requires installation of client software on the remote user's machine, and the disturbance of the network stack can introduce compatibility problems with some applications.
Con Accessing multiple unrelated systems at the same time might be impossible because the VPNs.
Pro Ideally suited for laptops on the road.

Software Client with PPTP

A special case of the previous item, this uses the built-in VPN client found in all Windows systems. Using the PPTP (Point-to-Point Tunneling Protocol) service on the SBS system, a user on a home PC can create a VPN with justa few clicks.

Pro Remarkably easy setup via the Client Connection Manager link on the SBS server: this may be within the ability of IT staff to walk a sales person through this over the phone.
Pro Outstanding integration with the entire Windows system, including DNS.
Con It's still a VPN with an IP path inside the network.
Pro Great choice for on the road.

Summary

We hope this paper will help the SBS user revisit remote-access needs with a new light on previously-unknown options.

Our two favorite technologies here are Remote Web Workplace and Exchange's RPC over HTTP: they both provide a great mix of utility and security, and each does an outstanding job addressing its particular problem.

Surveying the this space has been much more work than we expected, because we kept finding more categories, and more programs in each category (and each variant had its own twists). We're sure we've missed plenty, and we welcome feedback on them.

Special thanks to the Microsoft Security MVP Community for providing very useful feedback on this paper.

Published: 2006/08/01 (Blogged)