Connect Exchange Servers Over a VPN

A VPN, as a secured LAN-to-LAN connection, is an ideal method for connecting Exchange servers, whether they're next door to one another or thousands of miles apart. Although a VPN connects servers via the Internet, the connection is secure, private, and encrypted because the VPN operates as a WAN link between sites.

The VPN connection is also easier to implement and less expensive to maintain, compared with maintaining a connection that uses the Dynamic RAS (DRAS) connector. Typically, administrators use a DRAS connector to connect Exchange servers that aren't linked by a permanent LAN connection. However, DRAS has two major drawbacks.

First, to establish a RAS connection, server A needs an appropriate rights context to connect to server B. Appropriate rights require either that the servers have a trusted domain relationship or that you've set up and validated in server B the accounts server A uses for the connection. With a VPN, you can use the X.400 connector. The X.400 connector is more reliable and doesn't require that you set up the rights context.

Second, the connection must occur according to a fixed schedule (e.g., every hour). The DRAS connector opens the connection at the specified time, regardless of the mail queue length. This rigid schedule can be inefficient and costly because the connection incurs unnecessary long-distance costs if no messages are on the server. In an international company with Exchange sites around the world, a scheduled connection can rack up substantial costs. Although you can prevent these wasteful connections by changing a Message Transfer Agent (MTA) Registry key that Microsoft included with Exchange Server 5.5 Service Pack 1 (SP1), this Registry key reduces only the number of connection times and not the costs for each connection. With a VPN, you can lower the costs for each connection. If your company has access to the Internet, your ISP is usually nearby; therefore, telephone costs for connecting to the provider are low.

You can use a VPN between a company's headquarters and a subsidiary with a permanent Internet IP address. You can also set up a low-budget dial-in alternative for small subsidiaries. To implement either setup, you need to know the VPN requirements, how to install and configure the services and protocols, and how to set up the Exchange servers.

VPN Requirements
You can obtain the software for a VPN from Microsoft free of charge. First, you need the RRAS, which is an update to the standard RAS that ships with Windows NT Server. You can obtain RRAS from http://www.microsoft.com/ ntserver/nts/downloads/winfeatures/rras/rras down.asp. You need RRAS because it natively supports demand-dial routing and lets you define IP filters. You use PPTP, an extension to the Point-to-Point Protocol (PPP), for the communication protocol.

Next, you need a connection to the Internet. The connection can be a dial-up or a leased line connection, but at least one party must have a dedicated link with a static IP address. In addition, you need an Exchange server running on NT and an X.400 connector on both sides.

Finally, I recommend installing NT 4.0 SP4 because it contains the RRAS and PPTP performance and security upgrades for NT 4.0, which significantly improve the performance and security of PPTP-based VPN connections via the Internet. The Microsoft article "PPTP Performance & Security Upgrade for WinNT 4.0 Release Notes" (http://support.microsoft.com/ support/kb/articles/q189/5/95.asp) has information about this upgrade.

Installing Protocols and Services for the Tunnel
If you install the protocols and services on a machine from scratch (i.e., the machine is running NT Server but not RAS), install PPTP first. In the Network applet in Control Panel, go to the Protocols tab and choose Add, then Point To Point Tunneling Protocol. During setup, the program prompts you for several VPNs to install. This number is the maximum number of VPNs your server can handle in a parallel way. Remember that each connected VPN device increases the load on the server to handle a RAS device and increases CPU time for data encryption.

At the end of PPTP setup, RAS setup starts automatically. You can't install RRAS over an existing RAS, so you can either uninstall RAS before you install PPTP or abort the PPTP setup after you've copied the RAS files. To abort the setup, click Cancel in the Add RAS Device dialog box, which Screen 1 shows.

After you reboot, the server displays the TCP/IP and PPTP protocols but no RAS service. Install the RRAS update by starting mpri386.exe for Intel systems or mpralpha.exe for Alpha systems. That action finishes the installation with a clean Multi-Protocol Routing (MPR) environment that enhances the ordinary RAS features.

As Screen 2 shows, the setup process prompts you to choose some other RRAS components. The Remote access service option initializes the RRAS server to act as a dial-in server for remote (e.g., traveling) clients. The LAN routing option supports LAN-to-LAN routing. You can select this option if you need routing protocols such as Routing Information Protocol (RIP). You must select Demand-dial routing because it's the basic connection mechanism in this context.

Later in the process, the Add RAS Device dialog box in Screen 1 reappears, and you can add all the previously defined VPN devices by clicking OK. Close the dialog box by choosing Continue to finish the PPTP and RRAS setup.

Finally, reinstall NT SP4 to ensure that you have the most recent versions of the installed RRAS and PPTP services. The service pack includes the RRAS and PPTP performance and security upgrades. The Microsoft article "New Features Available in Windows NT 4.0 Service Pack 4" (http://support.microsoft.com/ support/kb/ articles/q194/3/03.asp) has information about this service pack.

Configuring Interfaces and Routes
Now, you're ready to configure the VPN. Figure 1 illustrates the interface and route configuration. Let's assume that Cyberdyne Systems' headquarters runs a server named Jupiter and wants to connect to server Venus at the company's subsidiary. Because both companies run leased-line Internet connections via their ISPs, they both have permanent IP addresses that are known and routed throughout the Internet. On the WAN side (exposed to the Internet), Jupiter's IP address is 62.213.12.157 and Venus' IP address is 193.156.134.14. The headquarters uses the private IP range 172.16.1.0 through 172.16.1.16 in its LAN, and the subsidiary uses the range 192.168.1.0 through 192.168.1.4. Jupiter's LAN IP address is 172.16.1.10, and Venus' address is 192.168.1.10.

Before you create the interfaces in the RRAS administration tool, you must set up user accounts for mutual authentication of the VPN devices in both companies. From Programs, Administrative Tools, User Manager for Domains, create the accounts in the Jupiter and Venus servers. The accounts must be members in only the domain guests groups and must have dial-in permissions with callback to the remote WAN IP address, as Screen 3 shows. For authentication, the callback number for the account VPNMaster in Jupiter is 193.156.134.14 and the account VPNSlave in Venus is 62.213.12.157. (If the remote server didn't have a fixed IP address exposed to the Internet, you'd choose No Call Back for this account.) To improve security, use strong passwords that are difficult to guess. Effective passwords are long and include special characters (e.g., exclamation points or question marks) and uppercase and lowercase characters.

To create the interfaces and routes, navigate to Programs, Administrative Tools, Routing and RAS Admin, and start the RRAS administration tool. First, you have to create the VPNMaster interface for the Jupiter server. In the RRAS admin tool, select LAN and Demand-Dial Interfaces, as Screen 4 shows. From the Toolbar, choose Actions, Add Interface. The interface name (i.e., VPNMaster) must have the same name as the user account in the same server. In the dialog box you see in Screen 5, enter the demand-dial interface name. Finally, select the I know all about demand-dial interfaces and would rather edit the properties directly check box.

Right-click the newly created interface, and select Configure Interface. On the General tab of the New Phonebook Entry dialog box, enter the address of the remote router (193.156.134.14), as Screen 6 shows. You don't need to change the Connect using setting because RRAS automatically selects an unused VPN device.

On the Protocols tab, click TCP/IP settings. You must set up a specific IP address that will function as one end of the virtual tunnel. You need this address because PPTP needs a definite tunnel endpoint at each end. For example, you might set the headquarters side of the tunnel to 192.168.199.1 and the subsidiary side to 192.168.199.2. As Screen 7 shows, you can use the Use this address option to set each IP address. Click OK.

On the Security tab, select Accept only Microsoft encrypted authentication and Require (strong) data encryption. Finally, close the New Phonebook Entry dialog box, and right-click the interface VPNMaster again. Go to Set Credentials, and enter for the VPNMaster device name the domain and password of account VPNSlave, as Screen 8 shows.

Using the RRAS admin tool, choose Actions, Add Static Route to add a static route. A static route tells RRAS which interface to bring up for connecting to which IP address. For example, you might set the route for the Jupiter server to the destination 192.168.1.0 with subnet mask 255.255.255.0, gateway 192.168.199.2, and interface VPNMaster, as Screen 9 shows.

Configuring Filters
To restrict access to certain machines, protocols, or applications, you can set up IP filters. For example, if you want to let only the two Exchange servers use the tunnel, follow these steps:

Options for Nonpermanent IP Addresses
Some companies access the Internet on demand, as thousands of private users do, by using ISPs such as America Online (AOL) or The Microsoft Network (MSN). Users worldwide can dial in to these ISPs on an inexpensive or flat rate that keeps supplemental telephone costs at a minimum. These big providers assign changing IP addresses from a pool they own with every connection to clients who dial in to them.

A subsidiary that doesn't have a permanent WAN IP address must always initiate Exchange-server-to-Exchange-server connection via the Internet with headquarters that has a permanent WAN IP address. Although the connection is two-way, headquarters can't initiate the connection.

In the Cyberdyne scenario, suppose Jupiter has a fixed WAN IP address that is always available across the Internet and Venus has a dynamic WAN IP address. In other words, Venus gets a new WAN IP address every time it dials in to its ISP. To accommodate Venus' dynamic IP address, you need to make the following changes:

You can test communication by pinging the LAN IP address of the remote Exchange server, which will cause the PPTP and the demand-dial interface to come up.

Configuring the X.400 Connector
For the communicating Exchange servers, the address of the remote server is its LAN IP address. The favored connector is X.400 on a TCP/IP stack because of its stability and reliable performance. The ordinary X.400 connector makes the VPN solution available for Exchange Server 5.5, 5.0, and 4.0.

When you have a permanent IP address, the tab stack in the Jupiter server's X.400 connector contains the IP address of the remote server (192.168.1.10 in this scenario). The corresponding setting for the Venus server is 172.16.1.10. When you have a nonpermanent IP address, you must set the X.400 connector in Jupiter to schedule: remote initiated (!) and the remote host name in the tab stack Venus. Otherwise, you might receive errors during name resolution and X.400 error messages in the event log. Set up the connector for Venus the same way you did in the scenario with permanent WAN IP addresses. You can configure all the other X.400 connector or directory replication connector settings in the usual way.

A Few Words About Security
The vulnerability of RRAS and the underlying PPTP is a controversial topic. On one hand, no security mechanism is totally secure. I believe that the security level I suggest is sufficient for robust protection against the Internet; you can add additional firewalls or proxy servers to secure the communicating Exchange servers if you think you need to. On the other hand, Microsoft states that, to date, no one has invaded PPTP during production.

Three areas affect VPN security. First, when a server dials in to its ISP, the ISP uses the Password Authentication Protocol (PAP), the Challenge Handshake Authentication Protocol (CHAP), or the Microsoft Challenge Handshake Authentication Protocol (MSCHAP) to authenticate the user account. The strength of security depends on what mechanism your ISP supports; MSCHAP is the most secure of the three protocols.

After completing the four initial phases (i.e., link establishment, user authentication, PPP callback control, and network layer protocols invocation), PPP starts to transfer data through the tunnel. Microsoft uses Microsoft Point-to-Point Encryption (MPPE), based on the RSA/RC4 algorithm, for transmitting the data with 128-bit data encryption (inside the United States).

To prevent any protocol other than PPTP from accessing the external interface (i.e., the interface that is exposed to the Internet), you can set up additional packet filters on it. The Microsoft article "Enable PPTP Filtering Option No Longer Works" (http://support.microsoft.com/support/kb/ articles/q169/8/90.asp) provides details about configuring PPTP filters. Disabling the Internet Control Message Protocol (ICMP) by setting corresponding filters complicates troubleshooting because the filtering prevents you from pinging the remote server.

The PPTP release notes offer supplementary information about the advanced security features that NT SP4 provides. The most important improvement is MSCHAP 2.0, which provides mutual authentication, stronger initial data encryption keys, and different encryption keys for the transmit and receive paths. To minimize the risk of password compromise during MSCHAP exchanges, MSCHAP 2.0 drops support for the MSCHAP password change and won't transmit the LMHash encoding of the password.

Secure and Inexpensive
A VPN is an ideal way to expand the local network for connecting resources in affiliated companies, no matter how far away they are from one another, with low costs and a secured connection. A VPN lets you use the more reliable X.400 connector instead of the DRAS connector to link your Exchange server to the remote server. A VPN gives you a higher level of security in your LAN because you eliminate the need to set up and validate in one server the accounts the other server uses for the connection.