Site-to-Site VPN in ISA Server 2004 Enterprise Edition

Article
10/09/2008

Microsoft® Internet Security and Acceleration (ISA) Server 2004 Enterprise Edition provides secure site-to-site virtual private network (VPN) functionality. This functionality works with the ISA Server Network Load Balancing (NLB) functionality to provide redundancy and failover capacity for VPN connections.

On This Page

VPN Considerations in Enterprise Edition
Scenarios
Solutions
Additional Information

Virtual Private Networks

A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. With a VPN, you can send data between two computers across a shared or public network in a manner that emulates a point-to-point private link. Virtual private networking is the act of creating and configuring a virtual private network.

To emulate a point-to-point link, data is encapsulated, or wrapped, with a header that provides routing information, which allows the data to traverse the shared or public network to reach its endpoint. To emulate a private link, the data is encrypted for confidentiality. Data that is intercepted on the shared or public network is indecipherable without the encryption keys. The link in which the private data is encapsulated and encrypted is a VPN connection.

VPN connections allow users who work at home or travel to obtain a remote access connection to an organization server using the infrastructure provided by a public network such as the Internet. From the user’s perspective, the VPN is a point-to-point connection between the computer, the VPN client, and an organization server (the VPN server). The exact infrastructure of the shared or public network is irrelevant, because it appears as if the data is sent over a dedicated private link.

VPN connections also allow organizations to have routed connections with other organizations over a public network, such as the Internet, while maintaining secure communications (for example, between offices that are geographically separate). A routed VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link.

By using the ISA Server array as the VPN server, you can manage site-to-site VPN connections and VPN client access to the corporate network. All VPN connections to the ISA Server array are logged to the Firewall log, so that you can monitor VPN connections.

VPN Connections

There are two types of VPN connections:

Remote access VPN connection
Site-to-site VPN connection

Remote access VPN connection

A remote access client makes a remote access VPN connection that connects to a private network. ISA Server provides access to the entire network to which the VPN server is attached. Configuration of remote access VPN connections is discussed in the document VPN Roaming Clients and Quarantine Control in ISA Server 2004 Enterprise Edition (https://www.microsoft.com).

Site-to-site VPN connection

A router makes a site-to-site VPN connection that connects two portions of a private network. ISA Server provides a connection to the network to which the ISA Server array is attached. Site-to-site VPN connections are discussed in this document. A detailed description of how to deploy a hub-spoke or mesh VPN configuration is provided in the document Virtual Private Network Deployment Scenarios in ISA Server 2004 Enterprise Edition (https://www.microsoft.com).

VPN Protocols

There are three VPN protocols for site-to-site connections:

Point-to-Point Tunneling Protocol (PPTP)
Layer Two Tunneling Protocol (L2TP) over Internet Protocol security (IPsec)
Internet Protocol security (IPsec) tunnel mode

PPTP

Point-to-Point Tunneling Protocol (PPTP) is a network protocol that enables the secure transfer of data from a remote client to a private enterprise server by creating a VPN across TCP/IP-based data networks. PPTP supports on-demand, multi-protocol, virtual private networking over public networks such as the Internet. PPTP allows IP traffic to be encrypted, and then encapsulated in an IP header to be sent across a corporate IP network or a public IP network such as the Internet.

L2TP over IPsec

Layer Two Tunneling Protocol (L2TP) is an industry-standard Internet tunneling protocol that provides encapsulation for sending Point-to-Point Protocol (PPP) frames across packet-oriented media. L2TP allows IP traffic to be encrypted, and then sent over any medium that supports point-to-point datagram delivery, such as IP. The Microsoft implementation of the L2TP protocol uses Internet Protocol security (IPsec) encryption to protect the data stream from the VPN client to the VPN server. IPsec tunnel mode allows IP packets to be encrypted, and then encapsulated in an IP header to be sent across a corporate IP network or a public IP network such as the Internet.

PPTP connections require only user-level authentication through a PPP-based authentication protocol. L2TP over IPsec connections require the same user-level authentication and, in addition, computer-level authentication using computer certificates.

Important

PPTP or L2TP over IPsec connections. When choosing between PPTP and L2TP over IPsec router-to-router VPN solutions, consider the following:

PPTP can be used for router-to-router VPN connections for routers running Microsoft Windows Server™ 2003 or Windows® 2000 Server with Routing and Remote Access, or Windows NT® Server 4.0 with the Routing and Remote Access Service (RRAS). PPTP does not require a public key infrastructure (PKI) to issue computer certificates. By using encryption, PPTP-based VPN connections provide data confidentiality. Captured data cannot be interpreted without the encryption key. PPTP-based VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data origin authentication (proof that the data was sent by the authorized user).
L2TP can be used with routers running Windows Server 2003 or Windows 2000 Server operating systems. When both types of routers are used, a PKI is required to issue computer certificates to all routers. Routers running Windows Server 2003 operating systems additionally support a single preshared key configured on the answering router and all calling routers. By using IPsec, L2TP over IPsec VPN connections provide data confidentiality, data integrity, and data origin authentication.

IPsec tunnel mode

Tunneling is the entire process of encapsulation, routing, and decapsulation. Tunneling wraps, or encapsulates, the original packet inside a new packet. This new packet might have new addressing and routing information, which enables it to travel through a network. When tunneling is combined with data confidentiality, the original packet data (as well as the original source and destination) is not revealed to those listening to traffic on the network. After the encapsulated packets reach their destination, the encapsulation is removed, and the original packet header is used to route the packet to its final destination.

The tunnel itself is the logical data path through which the encapsulated packets travel. To the original source and destination peer, the tunnel is usually transparent and appears as another point-to-point connection in the network path. The peers are unaware of any routers, switches, proxy servers, or other security gateways between the tunnel’s beginning point and the tunnel’s endpoint. When tunneling is combined with data confidentiality, it can be used to provide a VPN.

The encapsulated packets travel through the network inside the tunnel. In this example, the network is the Internet. The gateway might be an edge gateway that stands between the outside Internet and the private network. The edge gateway can be a router, firewall, proxy server, or other security gateway. Also, two gateways can be used inside the private network to protect traffic across untrusted parts of the network.

When Internet Protocol security (IPsec) is used in tunnel mode, IPsec itself provides encapsulation for IP traffic only. The primary reason for using IPsec tunnel mode is interoperability with other routers, gateways, or end systems that do not support L2TP over IPsec or PPTP VPN tunneling. Interoperability information is provided on the Virtual Private Network Consortium Web site (https://www.vpnc.org).

Note

To create a remote site network that uses the IPsec protocol tunneling mode on a computer running Windows 2000, you must install the IPsecPol tool, available on the Microsoft Web site (https://www.microsoft.com). The tool must be installed to the ISA Server installation folder.
When you create a remote site network that uses the IPsec tunneling protocol, the Microsoft Firewall service modifies the IPsec filters on the computer, when restarting the Firewall service. This process can take up to several minutes, depending on the number of subnets included in the address ranges for the network. To minimize the effect, we recommend that you define IP address ranges that are aligned in subnet boundaries.

VPN Considerations in Enterprise Edition

In Enterprise Edition, you must consider the following requirements when configuring a VPN:

If you are using a multi-server ISA Server array, and plan on using Network Load Balancing (NLB), you must use the integrated NLB of ISA Server. If you use Windows NLB, site-to site connectivity will not be supported. Configuration of ISA Server integrated NLB is described in Appendix K: Configuring ISA Server Integrated NLB in this document.
If you are not using ISA Server to provide NLB functionality, you must configure your corporate routers to make sure that traffic from clients assigned to a particular pool of a particular computer running ISA Server services is routed back through that server. If you do configure NLB on the ISA Server array that provides the static addresses, the routing of client traffic is handled automatically by ISA Server. In this case, configure your routers to use the ISA Server array’s virtual IP address for all static routes.
We recommend that you install a replicate Configuration Storage server in each branch that connects to other offices using a site-to-site VPN connection. This will allow continued full functioning of ISA Server in the event that connectivity is interrupted.
In ISA Server Enterprise Edition, the use of a Dynamic Host Configuration Protocol (DHCP) server to assign addresses for VPN connections is limited to a single-server ISA Server array. If you have more than one server in the array, assign addresses using static address pools.
If you are using static address pools, you must create a static address pool on each computer running ISA Server services that you are using for a site-to-site VPN connection. If you add a computer to an ISA Server array, it will not be operational for VPN connections until you add a static address pool.
When you use ISA Server integrated NLB, it selects a server for each site-to-site connection, and provides failover protection for that connection. When NLB is enabled, NLB must be configured on the External network for site-to-site connections to function properly. In addition, NLB should be enabled on each network with which the remote site network has a route relationship.
In a multi-server ISA Server array, where NLB is enabled, we recommend that you do not install the Configuration Storage server on one of the array members. When a Configuration Storage server is installed on an array member, and that array member does not handle the site-to-site connection, the remote site will lose connectivity with the Configuration Storage server. Install the Configuration Storage server on a separate computer behind the ISA Server array.

Note

If servers do not start, or shut down periodically for any reason, the result could be an unbalanced distribution of site-to-site connections between array members. This will be noted in an ISA Server alert. You can respond to such an alert by disconnecting some of the VPN site-to-site sessions on servers that are hosting many sessions. The sessions will automatically be moved to other servers that are hosting fewer sessions. Access to the sessions is through the Sessions tab of the ISA Server Monitoring node. For more information, see Checking ISA Server for connection information, later in this document.

Network Load Balancing and Site-to-Site VPN

You can use the Network Load Balancing (NLB) functionality of ISA Server to configure and manage the NLB functionality of Windows running on ISA Server arrays.

When you configure NLB through ISA Server, NLB is integrated with ISA Server functionality. This provides important functionality that is not available in Windows NLB alone:

NLB configuration is performed through ISA Server Management.
ISA Server provides NLB health monitoring, and discontinues NLB on a particular computer as necessitated by its status. This prevents the continued functioning of NLB when the state of the computer does not allow the passage of traffic. For example, if there is a failure of the network adapter card on the computer, or if you stop the firewall service, ISA Server stops NLB-directed traffic from passing though that computer. When the issue is resolved, ISA Server will again allow NLB traffic to pass through that computer.
NLB delivers scaled performance by distributing the incoming network traffic among one or more virtual IP addresses (the cluster IP addresses) assigned to the NLB cluster. The hosts in the cluster then concurrently respond to different client requests. Because you can only configure single affinity using ISA Server, multiple requests from the same client request are mapped to a single server. This speeds up processing and shortens the response time to clients.
ISA Server NLB provides automatic routing of client requests to the array member that is hosting the VPN connection.
If the server that owns a site-to-site VPN connection fails, ISA Server NLB automatically shifts the connection to another ISA Server array member.
ISA Server NLB handles SecureNAT clients transparently. Firewall clients, VPN clients, and SOCKS proxy clients require additional configuration, as described in Enterprise Edition Client Considerations in this document.

When you use ISA Server integrated NLB, each computer running ISA Server services requires an additional network adapter, for intra-array communication. We recommend that these network adapters be physically connected to each other (for example, through a single switch), and not to other network segments, to ensure that they receive only intra-array communication. You should then configure intra-array communication to use the IP address of the new adapter on each server. The configuration procedures are described in Solutions in this document.

Enterprise Edition Client Considerations

Use of a multiple-server ISA Server array with NLB configured through ISA Server requires consideration of several technical issues for Firewall clients, roaming VPN clients, and SOCKS proxy clients. Typically, these issues result from the fact that the array member that receives a request will not necessarily be the one that forwards the request to a remote site. Similarly, the response may be returned to the client by a member that did not receive the original request. This is shown in the following figure.

Cc713314.98924a46-51df-4dfa-bb59-62d0eb309d5a(en-us,TechNet.10).gif

These issues can result in:

Loss of user-specific information between array members, so that firewall policy cannot approve the request.
Loss of client IP address information between array members, in a network address translation (NAT) network relationship (between roaming VPN clients or Firewall clients and the remote site), so that firewall policy cannot verify requests that depend on client IP addresses.
Loss of Firewall client information between array members, which precludes the establishment of secondary connections through an array member that receives the request from another array member (and not directly from the client).

This document provides recommended solutions for these issues.

Note

The issues described previously would also apply to a server publishing scenario, in which the server that is being published is connected to the ISA Server computer through a VPN tunnel.

Firewall clients, roaming VPN clients, and SOCKS proxy clients in NAT relationship to the remote VPN site

You can configure your ISA Server array so that it can handle requests from Firewall clients, roaming VPN clients, and SOCKS proxy client, in a scenario where there is a NAT relationship between those client networks and the remote VPN network.

Example of the problem

If a Firewall client or VPN client makes a request, that request arrives at an array member. That member checks the request against the firewall policy, and if appropriate, prepares to send it to the remote VPN site. However, because that member is not handling the connection to the remote site, it routes it through the array member that does handle the connection, first performing network address translation on the request. In this process, the client information is lost, so that when the second member receives the request, the request might be denied by the firewall policy. Similarly, the second member will not allow secondary connections (defined in protocol definitions—those enabled by application filters would still be allowed), because the connection requires the client information.

Solution for the problem

The solution for this issue is to configure intra-array communication as described in the solution walk-throughs in this document.

After you configure intra-array communication, the first array member that receives the request has the user and client IP information, and can check the request against the firewall policy. If the policy allows the request, that array member performs network address translation and sends the request on the intra-array network to the member that is handling the remote site VPN connection. The user and client IP information is lost, but the second member checks the intra-array request against the intra-array allow rule, and forwards the request to the remote site.

Note

This solution will work for outgoing secondary connections regardless of the relationship between the intra-array network and the remote site network. However, this solution will work for incoming secondary connections only in the case that the intra-array network has a route relationship with the remote site network. In a NAT relationship, the IP address that the first array member will listen on for the incoming connection will not be accessible to the remote site network.

Firewall clients and roaming VPN clients with route relationship to the remote VPN site

In a scenario where you have a route relationship between the Firewall clients or VPN clients and the remote VPN site, note the following effects on the Firewall client and roaming VPN client:

Firewall client. The Firewall client is not treated as a Firewall client in a route relationship to the remote VPN site, so no user information, authentication information, or any other Firewall client feature is used in the communication.
Roaming VPN client. The user information is available to the array member that handles the connection to the roaming VPN client, but is not available to the other array member that may be handling the remote site connection.

The result is that the user information is not available. For this reason, firewall policy applied to Firewall client and roaming VPN clients in the route relationship, site-to-site VPN scenario should not include user-specific rules.

DNS Configuration

You may require name resolution in a site-to-site VPN scenario, so that clients on one network can make requests of computers on a remote site network using the remote computer’s name, rather than its IP address. In PPTP and L2TP over IPsec protocols, the remote site provides the local site with the address of a DNS server on the remote site, which then handles the name resolution requests. You must provide this address manually in IPsec tunnel mode.

Note

The DNS server address provided by the remote site in the PPTP or L2TP over IPsec modes will only be provided to the ISA Server array member that hosts the VPN connection. You should therefore manually configure your local corporate DNS server to forward requests to the remote site DNS server.

Scenarios

A large corporation often has multiple sites that require communication, for example, a corporate office in New York and a sales office in Washington. The two offices can be connected securely over the Internet using site-to-site virtual private networking. Internet Security and Acceleration (ISA) Server 2004 provides three methods of establishing a site-to-site VPN connection: Internet Protocol security (IPsec) tunnel mode, Layer Two Tunneling Protocol (L2TP) over IPsec, or Point-to-Point Tunneling Protocol (PPTP).

This document considers two scenarios:

The site you are connecting to is using a third-party product as its VPN server. In this scenario, you should use the IPsec tunnel mode solution.
The site you are connecting to is using ISA Server 2004, ISA Server 2000, Windows Server 2003, or Windows 2000 Server as its VPN server. In this scenario, you can use either the L2TP over IPsec solution or the PPTP solution. Of these two, L2TP over IPsec is considered more secure.

Solutions

Using Internet Security and Acceleration (ISA) Server 2004, configuring a site-to-site VPN connection consists of these general steps:

Configure the local VPN server, which in this case is an ISA Server array. This includes the choice of a protocol for the VPN connection.
If you are using ISA Server integrated NLB, configure intra-array communication on ISA Server.
Configure ISA Server network rules and access policy. For L2TP over IPsec and for PPTP, you must also configure the general VPN properties for connections initiated by remote VPN sites, because ISA Server initially treats those sites as VPN clients until authentication is complete, after which the connection is treated as a site-to-site VPN connection.
Configure automatic dialing, if your ISA Server array is connected to the Internet through a dial-up connection.
Configure the remote VPN server.

You can use one of three protocols to create the VPN connection:

Internet Protocol security (IPsec) tunnel mode
Layer Two Tunneling Protocol (L2TP) over IPsec
Point-to-Point Tunneling Protocol (PPTP)

The following table compares the three protocols.

Protocol	When to use	Security level	Comments
IPsec tunnel mode	Connecting to third-party VPN server	High	This is the only option you can use if you are connecting to a non-Microsoft VPN server.
L2TP over IPsec	Connecting to an ISA Server 2004 computer, ISA Server 2000 computer, or Windows VPN server	High	Uses Routing and Remote Access. Less complicated than the IPsec tunnel solution, but requires that the remote VPN server be a computer running ISA Server services or a Windows.
PPTP	Connecting to an ISA Server 2004 computer, ISA Server 2000 computer, or Windows VPN server	Moderate	Uses Routing and Remote Access. Same restrictions as L2TP, but slightly easier to configure. L2TP is considered more secure because it uses IPsec encryption.

A walk-through for each of these protocols is provided in the sections that follow.

IPsec Tunnel Solution—Walk-through

Use the IPsec tunnel solution in a scenario where you are using ISA Server 2004 as your VPN server, and the site you are connecting to is using a third-party product or ISA Server 2004 as its VPN server, as shown in the network topology section that follows.

Note

You cannot configure IPsec tunnel mode over a dial-up connection, because the IP address of the connection is not known before the connection is made.

IPsec Tunnel Solution Network Topology

The following figure describes a possible network topology for the IPsec tunnel solution.

Cc713314.5ba0f45b-ed60-45ba-a9c7-68e1c2bf7047(en-us,TechNet.10).gif

As shown in the figure, the main office is using ISA Server 2004 as its VPN server. ISA Server 2004 is on a computer running either Windows Server 2003 or Windows 2000 Server.

The branch office may be running one of several third-party VPN servers. Configuration information for third-party VPN servers may be obtained from the Virtual Private Network Consortium Web site (https://www.vpnc.org). Alternatively, the branch may be using ISA Server 2004, Windows Server 2003, or Windows 2000 Server as its VPN server.

IPsec Tunnel Walk-through Procedure 1: Configure Intra-Array Communication on the ISA Server Array

When you use ISA Server integrated NLB, you must configure the ISA Server array for intra-array communication. Follow these steps:

Add a network adapter to each computer running ISA Server services, for intra-array communication. We recommend that these network adapters be physically connected to each other (for example, through a single switch), and not to other network segments, to ensure that they receive only intra-array communication.
Configure intra-array communication to use the IP address of the new adapter on each server. Follow the procedures in Appendix J: Configuring Intra-Array Communication in this document.
Create an ISA Server network that includes only the addresses of the new network adapters, an intra-array network. Follow the procedures in Appendix H: Creating a New Network in this document.
Create an access rule allowing all traffic for all users from the intra-array network to the remote site networks, following the procedure in Appendix F: Using the New Access Rule Wizard in this document.
Create a network rule establishing the relationship between the intra-array network and the remote site network, following the procedure in Appendix I: Creating a New Network Rule in this document.

When you create additional rules to establish the firewall policy for the Firewall clients and roaming VPN clients, place them after the intra-array network access rule in the ordered rule base. While the order is not critical (because the intra-array network access rule is specific to traffic from the intra-array network), this will help ensure that a deny rule does not interfere with the intra-array communication.

IPsec Tunnel Walk-through Procedure 2: Add a Remote Site Network

When you configure a site-to-site VPN in ISA Server, you are establishing a new network: the remote site, recognized by the ISA Server array as a remote VPN. The following procedure sets up that network:

Open Microsoft ISA Server Management.
In the console tree, select Virtual Private Networks (VPN).
In the details pane, select the Remote Sites tab.
In the task pane, on the Tasks tab, click Add Remote Site Network to start the New Network Wizard.
On the Welcome page, provide a name for the new network, such as WashingtonSales, and then click Next. The network name is limited to 200 characters.
On the VPN Protocol page, select IP Security protocol (IPsec) tunnel mode, and then click Next.
If you have not enabled NLB, the next page in the wizard will be the Connection Owner page. If you have not enabled NLB, you must select an ISA Server array member from the drop-down menu to handle the connection with the remote site, and then click Next. If you have enabled NLB, the connection owner is assigned automatically by ISA Server.
On the Connection Settings page, you must supply the IP addresses for the remote and local VPN servers. In Remote VPN gateway IP address, provide the IP address that connects the remote VPN server to the Internet:
- If the remote gateway uses NLB, provide its virtual IP address.
- If the remote gateway does not use NLB, provide the IP address of the device that will handle the connection.
  For example, as shown in the figure in Ipsec Tunnel Solution Network Topology earlier in this document, the remote VPN gateway IP address is 208.147.66.1.
In Local VPN gateway IP address, provide the IP address of the network adapter that connects the computer running ISA Server services to the network you selected in the previous step. If the local gateway uses NLB, provide its virtual IP address. For example, as shown in the figure in Ipsec Tunnel Solution Network Topology earlier in this document, the virtual IP address for the ISA Server array is 157.54.0.1. Click Next.
On the IPsec Authentication page, select Use pre-shared key for authentication. This is the default IPsec authentication method for the IPsec tunnel solution. Enter the preshared key, and then click Next.

Note

Advantages and disadvantages of preshared keys
Preshared key authentication does not require the hardware and configuration investment of a public key infrastructure (PKI), which is necessary for using computer certificates for IPsec authentication. Preshared keys are simple to configure on a local VPN server.
Unlike certificates, the origin and the history of a preshared key cannot be determined. For these reasons, the use of preshared keys to authenticate IPsec connections is considered a relatively weak authentication method. If you want a long term, strong authentication method, you should consider using a PKI. This would require installation of digital certificates from the same certification authority on both the local and the remote VPN servers. For more information about digital certificates, see Appendix A: Installing Digital Certificates on the Local and Remote VPN Servers in this document.
On the Network Addresses page, click AddRange and add the address ranges of the remote network, or click Add Network to select the enterprise networks included in the remote network. You can obtain this information from the administrator of the remote network. After you add the address ranges, on the Network Addresses page, click Next.
On the summary page, review the configuration, and then click Finish.
If you are using ISA Server integrated NLB, and the remote site is using some form of load balancing other than ISA Server integrated NLB, follow these steps:
1. In ISA Server Management, select Virtual Private Networks (VPN). In the details pane, on the Remote Sites tab, right-click the VPN network that you just created and select Properties. Alternatively, you can click Configure Remote Site in the task pane on the Tasks tab.
2. On the Remote NLB tab, click the Add Range button and add all of the dedicated IP addresses of the remote site. ISA Server requires these to allow the remote site to initiate a connection to the ISA Server array.
  
  Note
  
  If the remote site is using ISA Server integrated NLB, the remote site will initiate a connection to the local site using its virtual IP address, which you specified in the VPN wizard. You can view and modify that virtual IP address on the Connection tab of the remote site properties. ISA Server at the local site also uses the address provided on the Connection tab when it initiates a connection to the remote site, regardless of whether the remote site is using load balancing.
  If you are not running ISA Server NLB on the local site, the dedicated IP addresses of the remote site are not needed.
In the ISA Server details pane, click Apply to apply the changes to ISA Server. If you are prompted to restart the services, do so.

Important

You may be required to restart the ISA Server array computers after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the ISA Server array node, and click Monitoring. In the details pane, on the Alerts tab, look for an alert that reads ISA Server computer restart needed. The alert information for that alert will read Changes made to the VPN configuration require the computer to be restarted. If you see that alert, you are required to restart the ISA Server array computers.

IPsec Tunnel Walk-through Procedure 3: Create Network Rules and Firewall Policy

After you have created the remote VPN, ISA Server views it as it does any other network connected to the ISA Server array. You should now create:

Network rules to establish whether the network has a network address translation (NAT) or route relationship with the other networks connected to the ISA Server array. Establish a route relationship, because two-way communication is required between the VPN networks, and a NAT relationship is one-way. If the computers that must communicate across the various networks have public IP addresses, a route relationship can be created without concern about address duplication, because public IP addresses are unique. When the computers have private IP addresses, such as those in the range 10.10.10.0–10.255.255.255, there is a risk that there will be duplicate addresses across the VPN networks. The administrators of the networks should ensure that there is no duplication of IP addresses between the computers that must connect across the two VPN networks, so that a route relationship can be established.

Note

A NAT relationship from each VPN network to the other will cause communication between the networks to fail. However, if a route relationship is defined by one of the networks, the other network can configure a NAT relationship, and communication will be enabled.
Access rules to control access to and from the remote network. When you create access rules, you can choose to have requests that match the rules written to the ISA Server log. You can then access the log to review access to and from the remote site network.

Examples of possible firewall policies for site-to-site VPN scenarios are provided in Appendix D: Site-to-Site VPN Firewall Policies in this document. The procedure for creating access rules is described in Appendix F: Using the New Access Rule Wizard in this document.

For information about network rules and access rules, see ISA Server 2004 Help.

IPsec Tunnel Walk-through Procedure 4: Configure the Remote VPN Server

The remote VPN server must be configured to connect to the ISA Server array in IPsec tunnel mode, according to manufacturer instructions. You may also find useful information on the Virtual Private Network Consortium Web site (https://www.vpnc.org).

ISA Server provides a summary of the information needed to configure the remote server. To obtain the summary, follow these steps:

Open Microsoft ISA Server Management.
In the console tree, select Virtual Private Networks (VPN).
In the details pane, select the Remote Sites tab.
Select the network you created in Procedure 2.
In the task pane, on the Tasks tab, click View IPsec Policy. The dialog box that appears contains the information that the administrator of the remote VPN server needs so that the connection from the remote VPN server to the ISA Server array can be configured.

IPsec Tunnel Walk-through Procedure 5: Test the Connection

Test the VPN connection as described in Appendix C: Testing and Monitoring the VPN Connection in this document. Although the appendix describes both testing and monitoring, only the testing steps are used for this procedure.

IPsec Tunnel Walk-through Procedure 6: Configure Advanced IPsec Settings

You can configure advanced IPsec settings, specifically, the Phase I and Phase II Internet Key Exchange (IKE) protocol settings. Follow these steps to access the settings:

Open Microsoft ISA Server Management.
In the console tree, select Virtual Private Networks (VPN).
In the details pane, select the Remote Sites tab, and double-click the remote site network for which you want to configure the IKE settings, to open its properties.
On the Connection tab, click IPsec Settings to open the IPsec Configuration dialog box. On this dialog box, you can select the Phase I and Phase II tabs, and then modify the settings.
Click OK to close the IPsec Configuration dialog box, and then click OK to close the network properties dialog box.
In the ISA Server details pane, click Apply to apply the changes to ISA Server. It may take a few moments for the changes to be applied.

Note

Troubleshooting the IPsec tunnel mode is easier if you enable Windows auditing on the computers running ISA Server services. For more information, see www.microsoft.com (https://www.microsoft.com)

L2TP over IPsec Solution—Walk-through

Use the L2TP over IPsec solution in a scenario where you are using ISA Server 2004 as your VPN server, and the site you are connecting to is using Windows Server 2003, Windows 2000 Server, ISA Server 2004, or ISA Server 2000 as a VPN server. ISA Server 2004 uses Windows Routing and Remote Access to establish the L2TP over IPsec VPN connection.

L2TP over IPsec Solution Network Topology

The following figure describes a possible network topology for the L2TP over IPsec solution.

Cc713314.8d408e82-42a6-484f-bb63-5b45508302c6(en-us,TechNet.10).gif

As shown in the figure, the main office is using an ISA Server 2004 computer as its VPN server. ISA Server 2004 is on a computer running either Windows Server 2003 or Windows 2000 Server.

The branch office is running Windows Server 2003, Windows 2000 Server, ISA Server 2004, or ISA Server 2000 as its VPN server.

Note

Automatic dialing is not supported for L2TP over IPsec.

L2TP over IPsec Walk-through Procedure 1: Configure Intra-Array Communication on the ISA Server Array

When you use ISA Server integrated NLB, you must configure the ISA Server array for intra-array communication. Follow these steps:

Add a network adapter to each computer running ISA Server services, for intra-array communication. We recommend that these network adapters be physically connected to each other (for example, through a single switch), and not to other network segments, to ensure that they receive only intra-array communication.
Configure intra-array communication to use the IP address of the new adapter on each server. Follow the procedures in Appendix J: Configuring Intra-Array Communication in this document.
Create an ISA Server network that includes only the addresses of the new network adapters, an intra-array network. Follow the procedures in Appendix H: Creating a New Network in this document.
Create an access rule allowing all traffic for all users from the intra-array network to the remote site networks, following the procedure in Appendix F: Using the New Access Rule Wizard in this document.
Create a network rule establishing the relationship between the intra-array network and the remote site network, following the procedure in Appendix I: Creating a New Network Rule in this document.

L2TP over IPsec Walk-through Procedure 2: Install Digital Certificates

You can use digital certificate-based IPsec authentication, or preshared key IPsec authentication for your L2TP over IPsec connection. We recommend that you use certificate-based IPsec authentication. Certificate authentication requires the installation of digital (IPsec) certificates from the same trusted certification authority (CA) on both the local and remote VPN servers. Because the certificates are for internal use, you can use certificates issued by a local CA. The procedures for installing a CA and installing certificates are provided in Appendix A: Installing Digital Certificates on the Local and Remote VPN Servers in this document.

L2TP over IPsec Walk-through Procedure 3: Create a User with Dial-in Permissions on the Remote Site

When creating a site-to-site network for remote access, you must also create a user account for initiating the remote access dial-up connection. For the connection to succeed:

The name of the user account and the name of the site-to-site network must be identical. For example, if on SiteA you create a site-to-site network representing SiteB, you must also create a user named SiteB. SiteB will connect to SiteA using the credentials of the user named SiteB.
The remote access user dial-in properties must be set to allow remote access.
In a multi-server ISA Server array installed in a domain, if you have enabled ISA Server integrated NLB, the dial-in account should be configured as a domain user. The dial-in account should not be configured as a local user on an array member, because the member that handles the VPN connection may not have that user defined. Alternatively, you can use a RADIUS user.
In a multi-server ISA Server array installed in a workgroup, if you have enabled ISA Server integrated NLB, the local user you create must be created on each array member, because you cannot predict which array member will handle the connection. This is known as a mirrored account. Alternatively, you can use a RADIUS user.

To create a domain dial-in account for the remote site gateway, follow these steps on the domain controller:

Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
Expand domainname.local, and then click Users.
In the details pane, right-click the applicable user, and then click Properties.
On the Dial-in tab, under Remote Access Permission (Dial-in or VPN), select Allow access.

To create a local dial-in account for the remote site gateway, follow these steps:

On the ISA Server computer, click Start, point to Administrative Tools, and then click Computer Management.
In Computer Management, click System Tools, click Local Users and Groups, and then click Users.
In the details pane, right-click the applicable user and then click Properties.
On the Dial-in tab, under Remote Access Permission (Dial-in or VPN), select Allow access.

L2TP over IPsec Walk-through Procedure 4: Set General VPN Properties

ISA Server makes use of the properties of the general VPN configuration when authenticating site-to-site VPN connections initiated by a remote site. To ensure that a secure connection can be established, you must configure the general VPN properties.

Note

When you set the general VPN configuration in the Virtual Private Networks (VPN) Properties dialog box, the settings will apply to any VPN connection initiated by a remote client, whether a roaming client or a remote site.

To configure general VPN properties, follow these steps:

Open Microsoft ISA Server Management.
In the console tree, select Virtual Private Networks (VPN).
In the task pane, on the Tasks tab, under General VPN Configuration, click Select Access Networks. This opens the Virtual Private Networks (VPN) Properties dialog box to the Access Networks tab. On this tab, select the network through which the remote VPN you created will connect to the ISA Server array, so that the remote network will be able to initiate a connection to the local VPN server. Typically, this will be the External network.
Select the Address Assignment tab. You can use a DHCP server to dynamically assign IP addresses to remote site VPN clients when they connect. However, in ISA Server Enterprise Edition, the use of a DHCP server to assign addresses for VPN connections is limited to a single-server ISA Server array. If you have more than one server in the array, assign addresses using static address pools.
1. To use DHCP, select Dynamic Host Configuration Protocol (DHCP). From the drop-down menu below Use the following network to obtain DHCP, DNS and WINS services, select Internal, to indicate that the DHCP server is on the Internal network. Click OK.
  
  Tip
  
  To use DHCP to assign IP addresses to VPN clients, you must have a DHCP server located on the Internal network side of the ISA Server array, as shown in the following figure.
  
  Alternatively, you can have a router specifically configured to pass DHCP requests to a DHCP server behind the router, or configure a DHCP relay agent on the ISA Server array.
2. If you do not want to configure DHCP, select Static address pool in this step, rather than Dynamic Host Configuration Protocol (DHCP). Then click Add to add IP address ranges to the static address pool.
If you are using static address pools, you must create a static address pool on each computer running ISA Server services that you are using for a site-to-site VPN connection, by selecting the appropriate server from the Select the server drop-down menu. If you add a server to an ISA Server array, it will not be operational for VPN connections until you add a static address pool. Note that IP addresses in the static address pool cannot be addresses that are included in another network. You must provide one more IP address in the static address pool than the expected number of remote VPN connections. (This includes remote site and roaming client connections.) If necessary, edit the Internal network to remove addresses, so that they can be included in the static address pool. Be sure to include enough addresses in the static address pool to handle the expected number of connections.

Note

To remove the IP addresses included in the Internal network, in the ISA Server console, expand the Configuration node, and then click Networks. In the details pane, on the Networks tab, double-click the Internal network. On the Addresses tab, select a range of IP addresses, and click Remove to remove that range.
If you use a DHCP server to assign IP addresses on the Internal network, but will assign a group of IP addresses from the Internal network to be a static pool for VPN clients, you must configure the DHCP server to not assign those addresses.
Select the Authentication tab, and then select the authentication methods that the incoming connection requests will use. If the connection will use a preshared key, also select Allow custom IPsec policy for L2TP connection and provide the preshared key.
If you are using RADIUS to authenticate the user whose credentials are being used for the remote VPN connection, select the RADIUS tab and configure RADIUS usage.
Click OK to close the Virtual Private Networks (VPN) Properties dialog box.
In the ISA Server details pane, click Apply to apply the changes to ISA Server. If you are prompted to restart the services, do so. It may take a few moments for the changes to be applied.

Important

You may be required to restart the ISA Server array computers after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the ISA Server array node, and click Monitoring. On the Alerts tab, look for an alert that reads ISA Server computer restart needed. The alert information for that alert will read Changes made to the VPN configuration require the computer to be restarted. If you see that alert, you are required to restart the ISA Server array computers.

L2TP over IPsec Walk-through Procedure 5: Add a Remote Site Network

Open Microsoft ISA Server Management.
In the console tree, select Virtual Private Networks (VPN).
In the details pane, select the Remote Sites tab.
In the task pane, on the Tasks tab, click Add Remote Site Network to start the New Network Wizard.
On the Welcome page, provide a name for the new network, such as WashingtonSales, and then click Next.
On the VPN Protocol page, select Layer Two Tunneling Protocol (L2TP) over IPsec, and then click Next. You will receive a warning about creating a user with dial-in permissions on the remote site. You created that user in Procedure 3, so click OK.

Note

If you have selected static address pools as the method of assigning addresses to remote sites, and have not properly configured the address pool, you will receive an error message and will be unable to configure the wizard. If you receive an error message regarding static address pools, exit the wizard, and return to Procedure 4, which describes how to configure the static address pools.
If you have not enabled NLB, the next page in the wizard will be the Connection Owner page. If you have not enabled NLB, you must select an ISA Server array member from the drop-down menu to handle the connection with the remote site, and then click Next. If you have enabled NLB, the connection owner is assigned automatically by ISA Server.
On the Remote Site Gateway page, supply the name or IP address for the remote VPN servers, and then click Next. For example, as shown in the figure in L2TP over Ipsec Solution Network Topology earlier in this document, the remote VPN gateway IP address is 208.147.66.1. If the remote gateway uses NLB, provide its virtual IP address.
On the Remote Authentication page, you can select to allow outgoing connections from the local site to the remote site. If you enable this option, you must provide a user name, domain, and password for the connection. If your ISA Server array is installed in a workgroup, do not provide a domain. If you do not enable this option, you will not be able to establish outgoing connections to the remote VPN site, although you will be able to accept connections from that site. Click Next.
On the L2TP/IPsec Authentication page, you have the option of using preshared key IPsec authentication instead of certificate authentication. We recommend that you use certificate authentication. If you select this option, provide the preshared key. Certificate authentication requires the installation of digital (IPsec) certificates from the same trusted certification authority on both the local and remote VPN servers. For more information about digital certificates, see Appendix A: Installing Digital Certificates on the Local and Remote VPN Servers in this document. Click Next.

Note

Preshared key authentication does not require the hardware and configuration investment of a public key infrastructure (PKI), which is necessary for using computer certificates for IPsec authentication. Preshared keys are simple to configure on a local VPN server.
A single local VPN server can utilize only one preshared key for all L2TP over IPsec connections that require a preshared key for authentication. Therefore, you must issue the same preshared key to all VPN remote sites that connect to the local VPN server using a preshared key, in the L2TP over IPsec scenario. This limitation reduces the security of the deployment and increases the probability of error. If the preshared key on a local VPN server is changed, a remote VPN server with a manually configured preshared key will be unable to connect to that server until the preshared key on the remote VPN server is changed.
Unlike certificates, the origin and the history of a preshared key cannot be determined. For these reasons, the use of preshared keys to authenticate IPsec connections is considered a relatively weak authentication method. If you want a long term, strong authentication method, you should consider using a PKI. This would require installation of digital certificates from the same certification authority on both the local and the remote VPN servers. For more information about digital certificates, see Appendix A: Installing Digital Certificates on the Local and Remote VPN Servers in this document.
On the Network Addresses page, click AddRange and add the address ranges of the remote network, or click Add Network to select the enterprise networks included in the remote network. You can obtain this information from the administrator of the remote network. After you add the address ranges, on the Network Addresses page, click Next.
On the summary page, review the configuration, and then click Finish.
If you are using ISA Server integrated NLB, and the remote site is using some form of load balancing other than ISA Server integrated NLB, follow these steps:
1. In ISA Server Management, select Virtual Private Networks (VPN). In the details pane, on the Remote Sites tab, right-click the VPN network that you just created and select Properties. Alternatively, you can click Configure Remote Site in the task pane on the Tasks tab.
2. On the Remote NLB tab, click the Add Range button and add all of the dedicated IP addresses of the remote site. ISA Server requires these to allow the remote site to initiate a connection to the ISA Server array.
  
  Note
  
  If the remote site is using ISA Server integrated NLB, the remote site will initiate a connection to the local site using its virtual IP address, which you specified in the VPN wizard. You can see and modify that virtual IP address on the Connection tab of the remote site properties. ISA Server at the local site also uses the address provided on the Connection tab when it initiates a connection to the remote site, regardless of whether the remote site is using load balancing.
  If you are not running ISA Server NLB on the local site, the dedicated IP addresses of the remote site are not needed.
In the ISA Server details pane, click Apply to apply the changes to ISA Server. If you are prompted to restart the services, do so.

Important

You may be required to restart the ISA Server array computers after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the ISA Server array node, and click Monitoring. In the details pane, on the Alerts tab, look for an alert that reads ISA Server computer restart needed. The alert information for that alert will read Changes made to the VPN configuration require the computer to be restarted. If you see that alert, you are required to restart the ISA Server array computers.

L2TP over IPsec Walk-through Procedure 6: Create Network Rules and Firewall Policy

After you have created the remote VPN, ISA Server views it as it does any other network connected to the ISA Server array. You should now create:

Network rules to establish whether the network has a network address translation (NAT) or route relationship with the other networks connected to the ISA Server array. Establish a route relationship, because two-way communication is required between the VPN networks, and a NAT relationship is one-way. If the computers that must communicate across the various networks have public IP addresses, a route relationship can be created without concern about address duplication, because public IP addresses are unique. When the computers have private IP addresses, such as those in the range 10.10.10.0–10.255.255.255, there is a risk that there will be duplicate addresses across the VPN networks. The administrators of the networks should ensure that there is no duplication of IP addresses between the computers that must connect across the two VPN networks, so that a route relationship can be established. To create a network rule, follow the procedure in Appendix I: Creating a New Network Rule in this document.

Note

A NAT relationship from each VPN network to the other will cause communication between the networks to fail. However, if a route relationship is defined by one of the networks, the other network can configure a NAT relationship, and communication will be enabled.
Access rules to control access to and from the remote network. When you create access rules, you can choose to have requests that match the rules written to the ISA Server log. You can then access the log to review access to and from the remote site network.

For information about network rules and access rules, see ISA Server 2004 Help.

L2TP over IPsec Walk-through Procedure 7: Configure the Remote VPN Server

Configure the remote VPN server to connect to the ISA Server array in L2TP over IPsec mode. Follow the manufacturer’s instructions for configuring the remote VPN server. For example, if the remote server is an ISA Server 2004 computer, you would follow these walk-through procedures on the remote ISA Server 2004 computer to configure it.

L2TP over IPsec Walk-through Procedure 8: Test and Monitor the Connection

Test and monitor the VPN connection as described in Appendix C: Testing and Monitoring the VPN Connection in this document.

PPTP Solution—Walk-through

Use the PPTP solution in a scenario where you are using ISA Server 2004 as your VPN server, and the site you are connecting to is using Windows Server 2003, Windows 2000 Server, ISA Server 2004, or ISA Server 2000 as a VPN server. ISA Server 2004 uses Windows Routing and Remote Access to establish the PPTP VPN connection.

PPTP Solution Network Topology

The following figure describes a possible network topology for the PPTP solution.

Cc713314.d97d65f4-02eb-462b-accd-b3c04f06b07a(en-us,TechNet.10).gif

As shown in the figure, the main office is using ISA Server 2004 as its VPN server. ISA Server 2004 is on a computer running either Windows Server 2003 or Windows 2000 Server.

The branch office is running Windows Server 2003, Windows 2000 Server, ISA Server 2004, or ISA Server 2000 as its VPN server.

PPTP Walk-through Procedure 1: Configure Intra-Array Communication on the ISA Server Array

When you use ISA Server integrated NLB, you must configure the ISA Server array for intra-array communication. Follow these steps:

Add a network adapter to each computer running ISA Server services, for intra-array communication. We recommend that these network adapters be physically connected to each other (for example, through a single switch), and not to other network segments, to ensure that they receive only intra-array communication.
Configure intra-array communication to use the IP address of the new adapter on each server. Follow the procedures in Appendix J: Configuring Intra-Array Communication in this document.
Create an ISA Server network that includes only the addresses of the new network adapters, an intra-array network. Follow the procedures in Appendix H: Creating a New Network in this document.
Create an access rule allowing all traffic for all users from the intra-array network to the remote site networks, following the procedure in Appendix F: Using the New Access Rule Wizard in this document.
Create a network rule establishing the relationship between the intra-array network and the remote site network, following the procedure in Appendix I: Creating a New Network Rule in this document.

PPTP Walk-through Procedure 2: Create a User with Dial-in Permissions on the Remote Site

When creating a site-to-site network for remote access, you must also create a user account for initiating the remote access dial-up connection. For the connection to succeed:

The name of the user account and the name of the site-to-site network must be identical. For example, if on SiteA you create a site-to-site network representing SiteB, you must also create a user named SiteB. SiteB will connect to SiteA using the credentials of the user named SiteB.
The remote access user dial-in properties must be set to allow remote access.
In a multi-server ISA Server array installed in a domain, if you have enabled ISA Server integrated NLB, the dial-in account should be configured as a domain user. The dial-in account should not be configured as a local user on an array member, because the member that handles the VPN connection may not have that user defined. Alternatively, you can use a RADIUS user.
In a multi-server ISA Server array installed in a workgroup, if you have enabled ISA Server integrated NLB, the local user you create must be created on each array member, because you cannot predict which array member will handle the connection. This is known as a mirrored account. Alternatively, you can use a RADIUS user.

To create a domain dial-in account for the remote site gateway, follow these steps on the domain controller:

Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
Expand domainname.local, and then click Users.
In the details pane, right-click the applicable user, and then click Properties.
On the Dial-in tab, under Remote Access Permission (Dial-in or VPN), select Allow access.

To create a local dial-in account for the remote site gateway, follow these steps:

On the ISA Server computer, click Start, point to Administrative Tools, and then click Computer Management.
In Computer Management, click System Tools, click Local Users and Groups, and then click Users.
In the details pane, right-click the applicable user and then click Properties.
On the Dial-in tab, under Remote Access Permission (Dial-in or VPN), select Allow access.

PPTP Walk-through Procedure 3: Set General VPN Properties

Note

To configure general VPN properties, follow these steps:

Open Microsoft ISA Server Management.
In the console tree, select Virtual Private Networks (VPN).
In the task pane, on the Tasks tab, under General VPN Configuration, select Select Access Networks. This opens the Virtual Private Networks (VPN) Properties dialog box to the Access Networks tab. On this tab, select the network through which the remote VPN you created will connect to the ISA Server array, so that the remote network will be able to initiate a connection to the local VPN server. Typically, this will be the External network.
Select the Address Assignment tab. You can use a DHCP server to dynamically assign IP addresses to remote site VPN clients when they connect. However, in ISA Server Enterprise Edition, the use of a DHCP server to assign addresses for VPN connections is limited to a single-server ISA Server array. If you have more than one server in the array, assign addresses using static address pools.
1. To use DHCP, select Dynamic Host Configuration Protocol (DHCP). From the drop-down menu below Use the following network to obtain DHCP, DNS and WINS services, select Internal, to indicate that the DHCP server is on the Internal network. Click OK.
  
  Tip
  
  To use DHCP to assign IP addresses to VPN clients, you must have a DHCP server located on the Internal network side of the ISA Server array, as shown in the following figure.
  
  Alternatively, you can have a router specifically configured to pass DHCP requests to a DHCP server behind the router, or configure a DHCP relay agent on the ISA Server array.
2. If you do not want to configure DHCP, select Static address pool in this step, rather than Dynamic Host Configuration Protocol (DHCP). Then click Add to add IP address ranges to the static address pool.
If you are using static address pools, you must create a static address pool on each computer running ISA Server services that you are using for a site-to-site VPN connection, by selecting the appropriate server from the Select the server drop-down menu. If you add a computer to an ISA Server array, it will not be operational for VPN connections until you add a static address pool. Note that IP addresses in the static address pool cannot be addresses that are included in another network. You must provide one more IP address in the static address pool than the expected number of remote VPN connections. (This includes remote site and roaming client connections.) Be sure to include enough addresses in the static address pool to handle the expected number of connections.

Note

To remove the IP addresses included in the Internal network, in the ISA Server console, expand the Configuration node, and then click Networks. In the details pane, on the Networks tab, double-click the Internal network. On the Addresses tab, select a range of IP addresses, and click Remove to remove that range.
If you use a DHCP server to assign IP addresses on the Internal network, but will assign a group of IP addresses from the Internal network to be a static pool for VPN clients, you must configure the DHCP server to not assign those addresses.
Select the Authentication tab, and then select the authentication methods that the incoming connection requests will use.
If you are using RADIUS to authenticate the user whose credentials are being used for the remote VPN connection, select the RADIUS tab and configure RADIUS usage.
Click OK to close the Virtual Private Networks (VPN) Properties dialog box.
In the ISA Server details pane, click Apply to apply the changes to ISA Server. It may take a few moments for the changes to be applied.

Important

You may be required to restart the ISA Server array computers after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the array node, and click Monitoring. On the Alerts tab, look for an alert that reads ISA Server computer restart needed. The alert information for that alert will read Changes made to the VPN configuration require the computer to be restarted. If you see that alert, you are required to restart the ISA Server array computers.

PPTP Walk-through Procedure 4: Add a Remote Site Network

Open Microsoft ISA Server Management.
In the console tree, select Virtual Private Networks (VPN).
In the details pane, select the Remote Sites tab.
In the task pane, on the Tasks tab, click Add Remote Site Network to start the New Network Wizard.
On the Welcome page, provide a name for the new network, such as WashingtonSales, and then click Next.
On the VPN Protocol page, select Point-to-Point Tunneling Protocol (PPTP), and then click Next. You will receive a warning about creating a user with dial-in permissions on the remote site. You created that user in Procedure 2, so click OK.

Note

If you have selected static address pools as the method of assigning addresses to remote sites, and have not properly configured the address pool, you will receive an error message and will be unable to configure the wizard. If you receive an error message regarding static address pools, exit the wizard, and return to Procedure 3, which describes how to configure the static address pools.
If you have not enabled NLB, the next page in the wizard will be the Connection Owner page. If you have not enabled NLB, you must select an ISA Server array member from the drop-down menu to handle the connection with the remote site. If you have enabled NLB, the connection owner is assigned automatically by ISA Server.
On the Remote Site Gateway page, supply the name or IP address for the remote VPN server, and then click Next. For example, as shown in the figure in PPTP Solution Network Topology earlier in this document, the remote VPN gateway IP address is 208.147.66.1. If the remote gateway uses NLB, provide its virtual IP address.
On the Remote Authentication page, you can select to allow outgoing connections from the local site to the remote site. If you enable this option, you must provide a user name, domain, and password for the connection. If your ISA Server array is installed in a workgroup, do not provide a domain. If you do not enable this option, you will not be able to establish outgoing connections to the remote VPN site, although you will be able to accept connections from that site. Click Next.
On the Network Addresses page, click AddRange and add the address ranges of the remote network, or click Add Network to select the enterprise networks included in the remote network. You can obtain this information from the administrator of the remote network. After you add the address ranges, on the Network Addresses page, click Next.
On the summary page, review the configuration, and then click Finish.
In the ISA Server details pane, click Apply to apply the changes to ISA Server.

PPTP Walk-through Procedure 5: Create Network Rules and Firewall Policy

After you have created the remote VPN, ISA Server views it as it does any other network connected to the ISA Server array. You should now create:

Network rules to establish whether the network has a network address translation (NAT) or route relationship with the other networks connected to the ISA Server array. Establish a route relationship, because two-way communication is required between the VPN networks, and a NAT relationship is one-way. If the computers that must communicate across the various networks have public IP addresses, a route relationship can be created without concern about address duplication, because public IP addresses are unique. When the computers have private IP addresses, such as those in the range 10.10.10.0–10.255.255.255, there is a risk that there will be duplicate addresses across the VPN networks. The administrators of the networks should ensure that there is no duplication of IP addresses between the computers that must connect across the two VPN networks, so that a route relationship can be established. To create a network rule, follow the procedure in Appendix I: Creating a New Network Rule in this document.

Note

A NAT relationship from each VPN network to the other will cause communication between the networks to fail. However, if a route relationship is defined by one of the networks, the other network can configure a NAT relationship, and communication will be enabled.
Access rules to control access to and from the remote network. When you create access rules, you can choose to have requests that match the rules written to the ISA Server log. You can then access the log to review access to and from the remote site network.

For information about network rules and access rules, see ISA Server 2004 Help.

PPTP Walk-through Procedure 6: Configure Automatic Dialing

If your ISA Server array is connected to the Internet through a dial-up connection, you can configure ISA Server to automatically dial the connection when a client computer sends a request to the remote VPN. The procedure for configuring automatic dialing is provided in Appendix B: Configuring Automatic Dialing in this document.

PPTP Walk-through Procedure 7: Configure the Remote VPN Server

Configure the remote VPN server to connect to the ISA Server array in PPTP mode.

PPTP Walk-through Procedure 8: Test and Monitor the Connection

Test and monitor the VPN connection as described in Appendix C: Testing and Monitoring the VPN Connection in this document.

Appendix A: Installing Digital Certificates on the Local and Remote VPN Servers

If you are using digital certificates to secure the site-to-site VPN connection, you must install the certificates on both the local and the remote VPN servers. This appendix guides you through the installation process. Note that these instructions apply to both the local and remote VPN server, assuming that the remote VPN server is running Windows Server 2003 or Windows 2000 Server.

Certification Authorities

Each VPN server must trust the certification authority (CA) that provided the server certificate for its counterpart. Certificate trust is based on the presence of a root certificate from the CA that issued the certificate.

Consider the scenario where the site-to-site VPN connection will be from an ISA Server 2004 computer called Server1 to an ISA Server 2000 computer called Server2. Server1 obtains its certificate from CA1 and Server2 obtains its certificate from CA2. The configuration of certificates will be as shown in the following table.

Server name	Server certificate	Root certificate
Server1	Issued by CA1	CA2
Server2	Issued by CA2	CA1

When you install a certificate from a commercial CA, there is no need for root certificate distribution because the root certificates are installed with Windows. When you install Certificate Services on one of your organization’s servers running Windows and issue your own certificates to the local and remote VPN servers, you must make arrangements to transfer the root certificate for your CA to any VPN server to which you will allow connections secured with digital certificates, as well as distributing the certificates. If there is no direct connectivity to the Certificate Services computer, information exchange can be done using a disk or CD, or by e-mail. (Be sure that your e-mail system is secure before doing so.) A CA can also be published using Internet Information Services (IIS) and Active Server Pages.

Because there is a cost associated with commercial digital certificates, in a scenario where both VPN servers are part of the same organization, we recommend that you set up a local CA and issue your own certificates. The procedure for doing so is provided in Installing Digital Certificates Procedure 1: Set Up the Certification Authority in this document.

Note

On an ISA Server 2004 computer, and on any VPN server running Windows Server 2003 or Windows 2000 Server, the server certificate obtained from a CA must be stored in the Personal Certificate store of the ISA Server array members. The root certificate for the VPN server to which the connection will be established must be stored in the Trusted Root Certificate Authorities store of the ISA Server array members.

Installing Digital Certificates Procedure 1: Set Up the Certification Authority

You need a certification authority (CA) to issue Internet Protocol security (IPsec) certificates. Because the certificates are for internal use, we recommend that you create a local CA, negating the need to purchase a commercial certificate. This procedure is performed on a computer running Windows. For a stand-alone root CA, this can be any computer running Windows. An enterprise root CA must be installed on a domain controller.

This procedure also installs the services that will enable computers to obtain the certificates through a Web page. You must create a Web publishing rule on the ISA Server array to make the Web page available outside of your corporate network. For more information, see the document Publishing Web Servers Using ISA Server 2004 (https://go.microsoft.com/fwlink?linkid=34644).

If you prefer a different approach for obtaining the certificates for computers, you do not have to perform the Internet Information Services (IIS) and Active Server Pages installations described in this procedure.

To set up the certification authority, perform the following steps:

Open the Control Panel.
Double-click Add or Remove Programs.
Click Add/Remove Windows Components.
Double-click Application Server.
Double-click Internet Information Services (IIS).
Double-click World Wide Web Service.
Select Active Server Pages.
Click OK to close the World Wide Web Service dialog box, click OK to close the Internet Information Services (IIS) dialog box, and then click OK to close the Application Server dialog box.
Select Certificate Services. Review the warning regarding the computer name and domain membership. Click Yes in the warning dialog box if you want to continue, and then click Next in the Windows components dialog box.
On the CA Type page, choose one of the following, and then click Next:
- Enterprise-rootCA. An enterprise root CA must be installed on a domain controller. The enterprise root CA will automatically issue certificates when requested by authorized users (recognized by the domain controller).
- Stand-alone root CA. A stand-alone root CA requires that the administrator issue each requested certificate, unless you follow the procedure in Optional: configure a stand-alone root CA to issue certificates automatically in this document.
On the CA Identifying Information page, provide a common name for the CA, check the distinguished name suffix, select a validity period, and then click Next.
On the Certificate Database Settings page, review the default settings. You may revise the database locations. Click Next.
On the Completing the Windows Components Wizard page, review the summary, and then click Finish.

Optional: configure a stand-alone root CA to issue certificates automatically

You can configure a stand-alone root CA to issue certificates automatically. Follow these steps:

In your MMC CA console, right-click the name of your CA, and select Properties.
On the Policy Module tab, click Properties.
On the Request Handling tab, select Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate.
Click OK to close the Policy Module properties dialog box, and then click OK to close the CA properties dialog box.
You will receive a message that you must restart Certificate Services. Right-click the name of your CA, point to All Tasks, and select Stop Service. After the service has stopped, right-click the name of your CA, point to All Tasks, and select Start Service.

Installing Digital Certificates Procedure 2: Install a Certificate and a Trusted Root Certificate

This procedure is performed on the ISA Server array members and on the remote site VPN server (if it is running Windows Server 2003 or Windows 2000 Server). If you installed a stand-alone root CA rather than an enterprise root CA, there are also actions that are performed on the certification authority.

Open Internet Explorer.
From the menu, select Tools, and then select Internet Options.
Select the Security tab, in Select a Web content zone to specify its security settings, click Trusted Sites.
Click the Sites button to open the Trusted sites dialog box.
In Add this Web site to the zone, provide the certificate server Web site name (https://IP address of certification authority server/certsrvname) and click Add.
Click Close to close the Trusted sites dialog box, and then click OK to close Internet Options.
Browse to: https://IP address of certification authority server/certsrv.
Request a certificate.
Select Advanced Certificate Request.
Select Create and submit a request to this CA (Windows Server 2003 CA), or Submit a certificate request to this CA using a form (Windows 2000 Server CA).
Complete the form and select IPsec certificate from the Type drop-down list.

Note

For an explanation of the options available on the Advanced Certificate Request page, see one of the following articles for Windows Server 2003 or Windows 2000 Server.
- Using Windows Server 2003 Certificate Services Web pages (www.microsoft.com)
- Using Windows 2000 Certificate Services Web pages (www.microsoft.com)
Select Store Certificate in the local computer certificate store (Windows Server 2003 CA) or Use local machine store (Windows 2000 Server CA) and submit the request by clicking Submit. Review the warning dialog box that appears, and then click Yes.
If you installed a stand-alone root CA, perform the following steps on the certification authority computer. These steps are automated in an enterprise root CA:
1. Go to the Microsoft Management Console (MMC) Certification Authority snap-in. (Click Start, point to All Programs, point to Administrative tools, and then click Certification Authority.)
2. Expand the CAName certificates node, where CAName is the name of your certification authority
3. Click the Pending requests node, right-click your request, select All Tasks, and then select Issue.
On the ISA Server array members, return to the Web page https://IP address of certification authority server/certsrv, and then click View status of a pending request.
Click your request and choose Install this certificate.
Return to the Web page https:// IP address of certification authority server /certsrv, and click Download a CA Certificate, Certificate Chain, or CRL (the text used by Windows Server 2003) or Retrieve the CA certificate or certificate revocation list (the text used by Windows 2000 Server). On the next page, click Download CA Certificate. This is the trusted root certificate that must be installed on the ISA Server array members. In the File Download dialog box, click Open.
On the Certificate dialog box, click Install Certificate, to start the Certificate Import Wizard.
On the Welcome page, click Next. On the Certificate Store page, select Place all certificates in the following store and click Browse. In the Select Certificate Store dialog box, select Show Physical Stores. Expand Trusted Root Certification Authorities, select Local Computer, and then click OK. On the Certificate Store page, click Next.
On the summary page, review the details and click Finish.
Verify that the IPsec certificate was properly installed. Open MMC, and go to the Certificates snap-in. Open Certificates (local computer), expand the Personal node, click Certificates, and double-click the new IPsec certificate. On the General tab, there should be a note that says You have a private key that corresponds to this certificate. On the Certification Path tab, you should see a hierarchical relationship between your certificate and the root certificate, and a note that says This certificate is OK.
Verify that the root certificate was properly installed. Open MMC, and go to the Certificates snap-in. Open Certificates (local computer), expand the Trusted Root Certification Authorities node, click Certificates, and verify that the root certificate is in place.

Appendix B: Configuring Automatic Dialing

Follow this general procedure to configure automatic dialing:

Open Microsoft ISA Server Management.
In the console tree, expand the array node, expand the Configuration node and select Networks.
In the task pane, on the Tasks tab, click Specify Dial-up Preferences to open the Dialing Configuration dialog box.
To allow automatic dialing, select Allow automatic dialing to this network, and from the drop-down menu, select the remote VPN you created. Note that you can only configure automatic dialing to one network.
If the dial-up connection is your default gateway, select Configure this dial-up connection as the default gateway.
In Dial-up connection, in Use the following dial-up connection, provide the name of the dial-up connection, or click Select to select a connection.

Note

Create dial-up connections by using the Windows New Connection Wizard.
If you choose a dial-up entry that is a VPN connection, you will experience connectivity problems, because the PPTP and L2TP over IPsec protocols that are used to establish VPN connections are blocked by default in ISA Server. To avoid this, create access rules that allow PPTP and L2TP over IPsec traffic.
If a specific account and password are needed to use the dial-up connection, in Dial-up account, click Set Account and provide the user and password information. Click OK to close the Set Account dialog box.
Click OK to close the Dialing Configuration dialog box.

Appendix C: Testing and Monitoring the VPN Connection

Follow these steps to test and monitor the VPN connection.

Note

Monitoring of IPsec tunnel site-to-site connections is not supported.

Testing the Connection

After you have created the connection, test it by trying to access a computer on the remote network from a computer on the local network (for which network rules and access policy allow access). If you can access the computer on the remote network, you have correctly configured the site-to-site VPN connection.

Checking ISA Server for Connection Information

This procedure is performed on the ISA Server array. To check ISA Server for connection information, follow these steps:

In the ISA Server console tree, expand the array node, and click Monitoring.
In the details pane, on the Sessions tab, verify whether your VPN session is listed. The site-to-site VPN session has the following properties:
- Session Type shows VPN Site-to-Site.
- Client Host Name shows the remote VPN server’s public IP address. (When the session has been initiated by the local VPN server, this field will be empty.) Client IP shows the IP address assigned for the VPN session.
- Application Name shows that this is a VPN connection and shows the protocol used for the connection. Application Name is not displayed by default. To add it, right-click one of the column headings in the Sessions tab, and select Application Name.

You can create a session filter so that only site-to-site VPN sessions are displayed. Follow these steps to create a filter:

In the ISA Server console tree, click Monitoring, and select the Sessions tab.
In the task pane, on the Tasks tab, click Edit Filter to open the Edit Filter dialog box.
In the Edit Filter dialog box, in Filter by, select Session Type. In Condition, select Equals, and in Value, select VPN Remote Site.
Click Add To List and then click Start Query. You must click Start Query to save the filter.

Appendix D: Site-to-Site VPN Firewall Policies

After you have created the remote VPN, you should establish a firewall policy that describes and regulates the relationship between the remote site and the other networks connected to your ISA Server array. This appendix describes some site-to-site VPN scenarios and examples of firewall policies you can establish for them.

Open Communication Between Branch Offices

In this scenario, the remote site is a branch office, and the ISA Server array is in the main office. The branch office is to have full access to the Internal network. If there are other branch offices, each branch office is to have full access to the resources of the other branch offices.

To enable full access, create an access rule allowing all traffic from the branch office VPN site to the Internal network, and to the VPN sites that define the other branch offices. The procedure for creating access rules is described in Appendix F: Using the New Access Rule Wizard in this document. For information about access rules, see the ISA Server product documentation.

Controlled Communication Between Branch Offices

In this scenario, the remote site is a branch office, and the ISA Server array is in the main office. The branch office is to have controlled access to the Internal network. Specifically, you want to create a firewall policy that allows the following types of communication:

Network administrator and senior manager computers will have full access to the Internal network of the main office.
Account managers will have access to the computer running Microsoft SQL Server™ in the Internal network of the main office.
All users will have access to the Exchange server in the Internal network of the main office.
The domain controller in the branch office will communicate with the domain controller in the main office, so that users from the branch office can be authenticated for access to the Exchange server in the main office.

To create this firewall policy, follow these general steps:

Create computer sets representing the groups of users that will have differing access rights. You will need a computer set for network administrator and senior manager computers, one for account managers, and one for domain controllers on the remote VPN network. Where there is only one computer, such as a single domain controller, you can create a computer object rather than a computer set. Computer sets and computer objects are rule elements. The procedure for creating rule elements is described in Appendix E: Creating Rule Elements in this document.
Create computer objects representing the computers that users will have access to on the Internal network of the main office. You will need computer objects for the computer running SQL Server, one for the Exchange server, and one for the internal domain controller. Where there is more than one server, such as two computers running SQL Server, create a computer set rather than a computer object.
Create an access rule allowing all traffic from the network administrator and senior manager computers in the branch office VPN site to the Internal network of the main office. The procedure for creating access rules is described in Appendix F: Using the New Access Rule Wizard in this document.
Create an access rule allowing Microsoft SQL (TCP) and Microsoft SQL (UDP) protocols from the account managers computer set to the computer running SQL Server on the Internal network of the main office.
Publish the Exchange server in the Internal network of the main office, using the Exchange RPC Server protocol. The procedure for creating mail server publishing rules is provided in Appendix G: Using the New Server Publishing Rule Wizard in this document.
Create an access rule allowing LDAP, LDAP (UDP), LDAPS, LDAP GC, LDAPS GC, DNS, Kerberos (TCP), and Kerberos (UDP) traffic from the remote site domain controller to the internal domain controller of the main office. The procedure for creating access rules is described in Appendix F: Using the New Access Rule Wizard in this document.

Appendix E: Creating Rule Elements

Follow this general procedure to create a rule element:

Open Microsoft ISA Server Management.
Expand the ISA Server array node.
Select Firewall Policy, and in the task pane, select the Toolbox tab.
Select the rule element type by clicking the appropriate header (Protocols, Users, Content Types, Schedules, or Network Objects) for that element.
At the top of the list of elements, click New.
Provide the information required. When you have completed the information and clicked OK in the dialog box, your new rule element will be created.

Note

You must click Apply in the details pane to apply changes, including the creation of new rule elements. If you prefer, you can click Apply after you create your access rules.

Appendix F: Using the New Access Rule Wizard

This procedure describes the New Access Rule Wizard in general terms:

In the Microsoft ISA Server Management console tree, select Firewall Policy.
In the task pane, on the Tasks tab, select Create Array Access Rule to start the New Access Rule Wizard.
On the Welcome page of the wizard, enter the name for the access rule, and then click Next.
On the Rule Action page, select Allow if you are allowing specific access rights, or Deny if you are denying specific access rights, and then click Next.
On the Protocols page, in This rule applies to, select All outbound protocols, and then click Next.
On the Access Rule Sources page, click Add to open the Add Network Entities dialog box, click the network entity category for which you are creating access, select the specific entity, click Add, and then click Close. On the Access Rule Sources page, click Next.
On the Access Rule Destinations page, click Add to open the Add Network Entities dialog box, click Networks, select the External network (representing the Internet), click Add, and then click Close. On the Access Rule Destinations page, click Next.
On the User Sets page, use the Remove and Add buttons to specify a set of users, and then click Next.
Review the information on the wizard summary page, and then click Finish.
In the ISA Server details pane, click Apply to apply the new access rule.
In the ISA Server details pane, order your access rules to match your access policy.

Appendix G: Using the New Mail Server Publishing Rule Wizard

This procedure describes the New Mail Server Publishing Rule Wizard in general terms:

Expand Microsoft ISA Server Management and click Firewall Policy.
On the task pane, in the Tasks tab, select Publish a Mail Server to start the New Mail Server Publishing Rule Wizard.
On the Welcome page of the wizard, provide a name for the rule, such as VPN Exchange RPC Access, and then click Next.
On the Select Access Type page, select Client access: RPC, IMAP, POP3, SMTP, and then click Next.
On the Select Services page, select Outlook (RPC), and then click Next.
On the Select Server page, provide the IP address of the Exchange server, and then click Next.
On the IP Addresses page, select the network on which ISA Server will listen for requests from external clients. Because you want to receive communication from the External network, select External, and then click Next.
On the Completing the New Mail Server Publishing Rule Wizard page, scroll through the rule configuration to make sure that you have configured the rule correctly, and then click Finish.
In the ISA Server details pane, click Apply to apply the changes you have made. It will take a few moments for the changes to be applied.

Appendix H: Creating a New Network

This procedure describes how to create a new network:

Open Microsoft ISA Server Management, expand the ISA Server array node, expand Configuration, and then click Networks.
In the details pane, select the Networks tab.
On the tasks pane, in the Tasks tab, click Create a New Network.
On the Welcome page, type a name for the network, and then click Next.
On the Network Type page, select Internal Network, and click Next.
On the Network Addresses page, click Add Adapter to open the Select Network Adapters dialog box. Select the network adapter that is used for intra-array communication. Click OK, and click Next.
On the Completing the New Network Wizard page, review the settings, and click Finish.
In the details pane, click Apply to apply your changes.

Appendix I: Creating a New Network Rule

This procedure describes how to create a new network rule:

In the Microsoft ISA Server Management console tree, expand the Configuration node and select Networks.
In the details pane, click the Network Rules tab. In the task pane, on the Tasks tab, select Create a Network Rule to start the New Network Rule Wizard.
On the Welcome page of the wizard, enter the name for the network rule, and then click Next.
On the Network Traffic Sources page, click Add to open the Add Network Entities dialog box, expand Networks, select the specific source network, click Add, and then click Close. On the Network Traffic Sources page, click Next.
On the Network Traffic Destinations page, click Add to open the Add Network Entities dialog box, expand Networks, select the destination network, click Add, and then click Close. On the Network Traffic Destinations page, click Next.
On the Network Relationship page, select either a Network Address Translation (NAT) relationship, or a Route relationship, and then click Next.
Review the information on the wizard summary page, and then click Finish.
In the ISA Server details pane, click Apply to apply the new network rule.

Appendix J: Configuring Intra-Array Communication

To configure intra-array communication, follow these steps:

In ISA Server Management, expand the array, expand Configuration, and select Servers.
For each server in the array, right-click the server and select Properties (or select Configure Selected Server in the tasks pane on the Tasks tab).
On the Communication tab, under Use this IP address for communication between array members, select the IP address of the network adapter over which intra-array communication will take place.
Click OK.
After you configure all of the servers, click Apply in the details pane to apply your changes.

Appendix K: Configuring ISA Server Integrated NLB

Follow this procedure to configure Network Load Balancing (NLB) for an array. NLB will be automatically configured in unicast mode and single affinity. Single affinity ensures that all network traffic from a particular client is directed to the same host. This procedure takes place on a computer in an ISA Server array, logged on as an array or enterprise administrator.

To configure ISA Server integrated NLB, follow these steps:

On one of the ISA Server computers, expand Arrays, expand the array on which you are going to configure NLB, expand Configuration, and click Networks.
In the details pane, verify that the Networks tab is selected.
In the task pane, on the Tasks tab, click Enable Network Load Balancing Integration to start the Network Load Balancing Integration Wizard. On the Welcome page, click Next.
On the Select Load Balanced Networks page, select the networks for which NLB will be enabled. We recommend enabling NLB on at least the External and Internal networks. Do not click Next.
Before you click Next, you must set the virtual IP address for each network. To set the virtual IP address, select a network, and then click Set Virtual IP. In the Set Virtual IP Address dialog box, provide the IP address and subnet mask for the virtual IP address you will use. Note that this IP address must be a valid static IP address (that cannot be assigned by your DHCP server), and must belong to the network you are configuring. Click Next.
On the summary page, click Finish.
In the details pane, click Apply. You will receive an ISA Server warning, prompting you to restart the Firewall service. Select Save the changes and restart the services, and then click OK.

Additional Information

Additional ISA Server 2004 documents are available on the ISA Server 2004 Guidance Page (https://www.microsoft.com).

Site-to-Site VPN in ISA Server 2004 Enterprise Edition

Virtual Private Networks

VPN Connections

Remote access VPN connection

Site-to-site VPN connection

VPN Protocols

PPTP

L2TP over IPsec

IPsec tunnel mode

VPN Considerations in Enterprise Edition

Network Load Balancing and Site-to-Site VPN

Enterprise Edition Client Considerations

Firewall clients, roaming VPN clients, and SOCKS proxy clients in NAT relationship to the remote VPN site

Example of the problem

Solution for the problem

Firewall clients and roaming VPN clients with route relationship to the remote VPN site

DNS Configuration

Scenarios

Solutions

IPsec Tunnel Solution—Walk-through

IPsec Tunnel Solution Network Topology

IPsec Tunnel Walk-through Procedure 1: Configure Intra-Array Communication on the ISA Server Array

IPsec Tunnel Walk-through Procedure 2: Add a Remote Site Network

IPsec Tunnel Walk-through Procedure 3: Create Network Rules and Firewall Policy

IPsec Tunnel Walk-through Procedure 4: Configure the Remote VPN Server

IPsec Tunnel Walk-through Procedure 5: Test the Connection

IPsec Tunnel Walk-through Procedure 6: Configure Advanced IPsec Settings

L2TP over IPsec Solution—Walk-through

L2TP over IPsec Solution Network Topology

L2TP over IPsec Walk-through Procedure 1: Configure Intra-Array Communication on the ISA Server Array

L2TP over IPsec Walk-through Procedure 2: Install Digital Certificates

L2TP over IPsec Walk-through Procedure 3: Create a User with Dial-in Permissions on the Remote Site

L2TP over IPsec Walk-through Procedure 4: Set General VPN Properties

L2TP over IPsec Walk-through Procedure 5: Add a Remote Site Network

L2TP over IPsec Walk-through Procedure 6: Create Network Rules and Firewall Policy

L2TP over IPsec Walk-through Procedure 7: Configure the Remote VPN Server

L2TP over IPsec Walk-through Procedure 8: Test and Monitor the Connection

PPTP Solution—Walk-through

PPTP Solution Network Topology

PPTP Walk-through Procedure 1: Configure Intra-Array Communication on the ISA Server Array

PPTP Walk-through Procedure 2: Create a User with Dial-in Permissions on the Remote Site

PPTP Walk-through Procedure 3: Set General VPN Properties

PPTP Walk-through Procedure 4: Add a Remote Site Network

PPTP Walk-through Procedure 5: Create Network Rules and Firewall Policy

PPTP Walk-through Procedure 6: Configure Automatic Dialing

PPTP Walk-through Procedure 7: Configure the Remote VPN Server

PPTP Walk-through Procedure 8: Test and Monitor the Connection

Appendix A: Installing Digital Certificates on the Local and Remote VPN Servers

Certification Authorities

Installing Digital Certificates Procedure 1: Set Up the Certification Authority

Optional: configure a stand-alone root CA to issue certificates automatically

Installing Digital Certificates Procedure 2: Install a Certificate and a Trusted Root Certificate

Appendix B: Configuring Automatic Dialing

Appendix C: Testing and Monitoring the VPN Connection

Testing the Connection

Checking ISA Server for Connection Information

Appendix D: Site-to-Site VPN Firewall Policies

Open Communication Between Branch Offices

Controlled Communication Between Branch Offices

Appendix E: Creating Rule Elements

Appendix F: Using the New Access Rule Wizard

Appendix G: Using the New Mail Server Publishing Rule Wizard

Appendix H: Creating a New Network

Appendix I: Creating a New Network Rule

Appendix J: Configuring Intra-Array Communication

Appendix K: Configuring ISA Server Integrated NLB

Additional Information

Additional resources