Today, VPNs are commonplace in businesses of all sizes, no longer limited to large enterprises. They're popular because they let users—typically mobile and home workers—access internal network resources that aren't available to users outside the firewall. VPNs tunnel through that firewall, effectively extending your corporate network to remote users. However, VPNs have a downside. Unless you take strict precautions, malicious users can exploit a VPN to gain access to your corporate network. The VPN can also be a gateway through which a worm or other malware can enter and wreak havoc behind your firewall.
VPNs will always have a place in some companies, but many businesses can do away with them. In this article, I describe two scenarios that VPNs are traditionally used for—corporate email and internal Web sites—then talk about effective alternatives.
Corporate Email
Email was once the killer application for businesses. Although its status might have diminished, it's probably still the primary justification for implementing a VPN. Typically, remote users dial in to a special toll-free number provided by a VPN supplier or ISP, supply special credentials, then connect to a VPN gateway, supplying their usual username and password. Once connected, users can launch their email client (e.g., Microsoft Outlook) and access their email server. This scenario is a bit cumbersome, and fortunately, there are now alternatives to consider.
RPC over HTTP. With Windows Server 2003, Windows XP Service Pack 1 (SP1) or later, Exchange Server 2003, and Outlook 2003, Microsoft introduced the concept of Remote Procedure Call over HTTP (RPC over HTTP). RPC is the underlying protocol in effect between Exchange and Outlook clients. By tunneling RPC through firewalls in an HTTP connection, it's now possible to access Exchange servers from outside the firewall. Users still must connect to the Internet, but that's an increasingly simple task given the ubiquity of broadband connections for teleworkers and Wi-Fi hotspots in coffee shops, convention centers, and airport lounges, as well as broadband-quality connections in hotel rooms. Once connected to the Internet, users can open Outlook 2003 and have access to their Inbox and other folders as though they were on their corporate LAN or the VPN.
There are many RPC over HTTP deployment scenarios. The simplest method, which I describe here, assumes that you have a single Exchange domain-member server running Exchange 2003 SP1 or later. If you have multiple Exchange servers, or one or more of your Exchange servers is also a domain controller (DC), I recommend that you don't follow these instructions but rather consult the Microsoft TechNet article "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3rpc.mspx).
On the Exchange server, open the Microsoft Management Console (MMC) System Manager snap-in, select the Exchange server from the Servers node, right-click it, select Properties from the context menu, then go to the RPC-HTTP tab, which Figure 1 shows. Select RPC-HTTP back-end server. A warning message will pop up, stating that there are no front-end Exchange servers configured. You can safely ignore this warning for this single-server configuration, so click OK to dismiss it. Click Apply to effect the setting, then click OK to close the Properties dialog box.
If you have no front-end Exchange servers acting as RPC over HTTP proxy servers, you need to further configure your Exchange server. The first step is to install the RPC over HTTP Proxy (for Windows 2003) onto your Exchange server. To do so, open the Control Panel Add or Remove Programs applet, click Add/Remove Windows Components, scroll down the list of components until you reach Networking Services, click the Details button, select RPC over HTTP Proxy, click OK, click Next, then click Finish.
The second step is to configure authentication methods for the RPC over HTTP Proxy. Launch the MMC IIS snap-in by selecting Start, Administrative Tools, Internet Information Server (IIS) Manager. In the snap-in, navigate to Default Web Site, expand it, select the RPC virtual directory, and right-click it. From the context menu, select Properties. In the RPC Properties dialog box, go to the Directory Security tab and click the Edit button in the Authentication and access control section. In the resulting Authentication Methods dialog box, ensure that the Enable anonymous access check box is cleared. RPC over HTTP requires users to authenticate themselves. You can choose Integrated Windows authentication or Basic authentication, or both. I recommend that you select Basic authentication for RPC over HTTP. Although doing so means that usernames and passwords will flow through your network in clear text, you can use Secure Sockets Layer (SSL) to encrypt RPC over HTTP traffic. The use of Integrated Windows authentication will work in some scenarios but can be problematic, and problems are difficult to troubleshoot. If you select Basic authentication, the system will display a warning message. Click Yes to proceed with your selection, then click OK, Apply, and OK.
The third step is to configure ports that the RPC over HTTP Proxy will use. On your Exchange server, from the command line, run the command Ipconfig/all and record the host name and domain name. Next, launch a registry editor and navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy subkey. Double-click the ValidPorts value, and edit it so that it reads
<hostname>:6001-6002;<hostname>.
<domainname>:6001-6002;
<hostname>:6004;<hostname>
.<domainname>:6004;
where hostname and domainname are the values you recorded when you ran Ipconfig/all. The usual caveat applies: Editing the registry can cause your system to become unstable. Record the existing values for any entries and be prepared to reapply those should you encounter stability problems.
To allow Outlook 2003 clients to connect to Exchange 2003 servers through RPC over HTTP, you need to perform some configuration on the client, too. In Outlook 2003, select Tools from the menu bar, then Email Accounts. Select View or change existing e-mail accounts, click Next, select the email account of type Exchange, click the Change button, then click More Settings. In the Microsoft Exchange Server dialog box, go to the Connection tab, select Connect to my Exchange mailbox using HTTP, then click Exchange Proxy Settings. In the Exchange Proxy Settings dialog box, which Figure 2 shows, enter the URL for the Exchange proxy server and select the connection settings. Once the client and server are configured, Outlook 2003 will be able to communicate with Exchange 2003 without the need for a VPN.
OWA. If you don't want to install RPC over HTTP, or your users are running an older version of Outlook, or you're running Windows 2000 or Exchange 2000, users can still access email remotely through Outlook Web Access. OWA is extremely convenient and provides access to users' Inboxes and online folders from a simple Web browser. To access OWA from a browser, users simply type the name of their Exchange server and append /exchange (e.g., https://mail.contoso.com/exchange).
To enable access to email through OWA from outside the firewall, you'll need to publish your Exchange server—that is, make it available to Internet users. The simplest way to do so is to use ISA Server 2006 or a similar application-level firewall that can inspect OWA traffic for malicious traffic. ISA Server contains step-by-step wizards that make it easy to publish OWA sites. I recommend that if you use OWA, always use an SSL certificate to maintain confidentiality of email between your Exchange server and your users' browsers. I also recommend that you disable account lockout. If account lockout is enabled, a malicious user might be able to carry out a Denial of Service (DoS) attack against any user whose username they know.
Finally, to keep Help desk calls to a minimum, I recommend that you configure your firewall to direct any traffic addressed to the Fully Qualified Domain Name (FQDN) of the OWA server to the \exchange virtual directory on your Exchange server. That way, users won't have to remember to append /exchange to the URL they type into their browser. I also recommend that you redirect any user who forgets to type https:// or types just http:// to the SSL-protected site.