When to use Remote Desktop over VPNWindows has two major mechanisms for allowing remote users controlled, protected access on a server: the virtual private network (VPN) and remote desktop. These methods are designed to solve different problems, so which should you use and when? To help you answer that question, I will provide a technical overview of each and offer comparisons in the following tip.
What is a VPN?
A VPN is an extension of a private network that redirects a client's network traffic to the remote server through an encrypted connection. It is best suited for giving someone direct, protected connectivity to a specific resource available through the server.
For instance, at one of my old jobs, a file repository was available as a shared network drive in the office. If someone connected to the office VPN from outside, they could connect to the same shared drives and gain access to the company intranet, among other things.
What is a remote desktop?
Unlike VPNs, Remote Desktop in Windows 2000 or XP Professional allows the user to run a functional clone of another computer's desktop, giving him access to all the programs, resources and accessories on that computer.
For instance, many server applications are managed through an administrative application that can only run on the machine where the server is present or another machine that can reach the server across the network. One common example is the Microsoft Management Console (MMC), an application that provides a graphical-user interface and programming framework for managing server components such as Exchange or SQL Server.
When to use one method over the other
VPNs have one big disadvantage that remote desktops do not. When a user sets up a VPN connection, all network traffic on his computer is redirected through the VPN. It's often difficult to force a specific application to use a different network interface.
A remote desktop connection, on the other hand, does not commandeer the system's networking; it runs as a standalone network application. Remote desktop connections can also (and probably should) be encrypted at the option of the administrator, so they rarely pose a security problem.
In some cases it's possible to choose either VPN or Remote Desktop as your solution, although they will be deployed and used in radically different ways and to different ends. Let's use SQL Server as an example.
Users can administer SQL Server through an MMC client that connects to the database through an administrator-defined network protocol, usually named pipes or TCP/IP. If a remote user administers SQL Server through a VPN, he would need to install not only the VPN networking connection on his computer, but the SQL Server front-end program as well -- and he'd have to make sure the SQL Server front end could "see" SQL Server itself through the VPN. This type of arrangement is useful if the client user is writing an application that needs data from SQL Server.
By contrast, a Remote Desktop user wouldn't need to install anything. He could simply connect to the remote computer using the Remote Desktop client already available in Windows 2000 or XP. (This would probably require the administrator to create an interactive login for him.) However, he would not be able to allow programs running on his computer access to SQL Server, although such a program being written or debugged on the server would work fine.
When determining whether to use Remote Desktop or VPN, you need to ask yourself if you need connectivity or just management access. For resource connectivity, choose VPN. For management, choose Remote Desktop.
HEADS UP: Bear in mind that a conventional system login (i.e., Windows Authentication) will probably not work with SQL Server across a VPN. You can set up network credentials to do this, but it is often more complicated than it needs to be. Instead, it may just be easier to change the database security to Mixed Authentication -- which allows both Windows user accounts and SQL Server accounts to connect to SQL Server -- as opposed to Windows-only user authentication. In a way, this can become yet another argument for using SQL Server on Remote Desktop.
About the author: Serdar Yegulalp is the editor of the Windows 2000 Power Users Newsletter and a regular contributor to SearchWindowsSecurity.com.
More Information from SearchWindowsSecurity.com
- Book Excerpt: VPN protocol choices
- Expert Response: Specifying users with Remote Desktop permissions through Group Policy
- Topics: Research technologies and technical advice for Windows network infrastructures
Jeremy H. writes:
I think you are just about dead wrong in this article. Administration via VPN is a piece of cake. Getting traffic to flow over the VPN or split the tunnel is a cake walk for most network deployments. And have you ever tried to open an 80MB PowerPoint file over a VPN? For remote access to resources, have the user log in to a terminal server and work from there. If they aren't going to have a live Internet connection when they work remotely then set up offline folders in Windows (and watch your access permissions on those files so you don't have conflicts when the user returns from the field). IPSec VPNs can be troublesome to implement and MS VPNs can be too lacking in security features. Try SSL-Explorer as yet another VPN alternative (GNU licensed SSL VPN server). SSL-Explorer supports both WebDAV and Internet Explorer access to workgroup (or domain) file sharing, SSL proxying for Web applications and SSL tunneling for direct connect applications.
This was first published in April 2005