No matter what solution a company employs, remote access is almost always a huge pain for users and administrators. Users have trouble accessing their corporate resources when they're away from the office, and administrators end up with a large phone bill, extra equipment to maintain, and holes in their firewall.
Because I work from a remote home office and travel every month to my corporate office, I have to deal with these situations. I also have the added bonus of needing remote access to two different offices when my travels take me to some other location.
Let's take a look at the common solutions I've tried. The first solution uses dedicated dial-up hardware. On the plus side, this method is inherently secure because users dial in to a location within their corporate network. This method doesn't add holes to the firewall, and you can add security measures, such as dial-back connections to authorized numbers. On the minus side, this method requires sufficient dedicated phone lines to support peak demand. I worked in an organization in which remote access—with more than 100 dedicated lines—became effectively unavailable during major trade shows because too many employees were trying to check their email messages at the same time. Although the market for this solution is mature and many solutions are easy to implement, you need to consider the cost. The hardware necessary to handle dial-up connections and the large monthly phone bills (even high-volume toll-free service is expensive) limit this solution's value to businesses.
VPN technology has made significant strides in recent years as the preferred remote access solution. The ability to use an inexpensive local Internet connection to access a corporate network makes remote access simpler. Whether a user connects when traveling, working in a remote office, or telecommuting, the connection type is always the same when using a VPN.
With Windows NT 4.0's PPTP, Microsoft jump-started the common use of VPNs. I briefly reviewed this technology when it became available in the mid-1990s. For my tests, I set up one server and one client and used DUN and PPTP to make a VPN connection. I learned of people's vast interest in this technology when I received more than 100 reader responses asking how I made my test VPN work—the directions that Microsoft provided were incomplete and inaccurate. Despite problems with PPTP and its security, I continued to receive requests for additional information on a regular basis for more than a year after the story ran. Users and administrators wanted a secure software-based connection that could run over the public Internet.
A quick look at Windows 2000 (Win2K) will show you just how much attention Microsoft paid to VPNs. Microsoft provides a VPN option as a basic connection type in the Dial-up Networking Connection Wizard. Microsoft also added IP Security (IPSec) and the Layer 2 Tunneling Protocol (L2TP), which the company developed with Cisco Systems.
With ISPs offering Internet access nationwide for $20 per month, a VPN connection offers mobile users an exceedingly inexpensive method for accessing their main office. VPN connections can cause problems because you need to configure the user client and the host network to support public Internet connections without compromising the security of the host network. Network administrators balk at anything that creates holes in their firewalls, and rightly so. Although vendors offer products, such as Network Associates' PGP VPN and SynData Technologies' SynCrypt VPN, to simplify the client side of the connection equation, keeping VPNs properly configured, connected, and secured is not a trivial activity. Some products, such as Cisco's router software, allow connections using IPSec, which might solve the VPN security problem. Eventually, any properly configured router with a security authentication mechanism, such as a Remote Authentication Dial-In User Service (RADIUS) server, will provide secure point-to-point communications between two Internet-connected systems.
If you look at why users most often need remote access, you'll discover that the number one reason is email access. And to obtain email messages, direct access to a host network isn't a necessity (unless the email solution requires direct access). But the most popular email solutions for NT—Microsoft Exchange Server and Lotus Domino—offer POP3 connectivity as well as proprietary options. POP3 support is the key to easy email connectivity that provides minimal exposure and risk to your corporate network.
With the two offices I connect to regularly, my primary need is email access. I almost never remotely access files from servers at either location, so access to those network resources isn't crucial when I travel. Therefore, my remote access solution is pretty simple. Although my business email account is on an Exchange server, my corporate office connects the Exchange server to a POP3 connector that is accessible from outside the firewall. The connector's resolvable IP address is an alias and makes security simple and straightforward. I use Exchange only for email (not for other uses), so POP3 access is all I need. For my home office, in which I run a standard SMTP and POP3 sendmail implementation, I already have the appropriate holes punched into my firewall.
So my routine when traveling is easy. I use MSN as my dial-up Internet provider, so before I travel, I obtain a list of numbers for my destination city from MSN's Access Phone Numbers Web page and save those numbers to a file on my notebook computer. When I arrive at my hotel, I dial up the most convenient number, and I'm on the Internet. Because I don't need any special VPN software, I can launch my email client and download the few hundred messages that show up in my inboxes each day. The access phone number is almost always local, so the price for the call stays the same whether I connect for 10 minutes or 10 hours.
Does my method solve every problem I have with remote access? Of course not. For my home office frame relay network, I'm investigating whether to switch to a Cisco router to directly access my network resources, then use IPSec to secure the connection. But for now, I have an easy way to obtain the items that are necessary to perform my daily job: my email messages. And when I need a large file from the corporate network, I can make a quick phone call or email request to have the file sent to me. (I find it a little less painful to have someone send a large file to me in an email message than to download a 2MB file over a 28.8Kbps connection.) Because I'm remotely accessing only my email messages, when I walk away from a system during a download, I'm not leaving an unsecured pipe in my corporate network, as I would be if I were downloading from a direct dial-up or VPN connection. This method keeps the security level a little higher, and I'm sure my corporate IT staff sleep a bit easier, too.
