There are two types of VPN connections:

• Remote access VPN connection
  
• Site-to-site VPN connection
  

Remote access VPN connection

Site-to-site VPN connection

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

L2TP over IPSec

PPTP or L2TP over IPSec connections

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 just 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 tunnels beginning point and the tunnels 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 website (http://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 website (http://go.microsoft.com/fwlink/?LinkId=16466). 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.

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

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 website (http://www.vpnc.org). Alternatively, the branch may be using ISA Server 2004, Windows Server 2003, or Windows 2000 Server as its VPN server.

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 computer as a remote VPN. The following procedure sets up that network.

1. Open Microsoft ISA Server Management.
   
2. In the console tree, select Virtual Private Networks (VPN).
   
3. In the details pane, select the Remote Sites tab.
   
4. In the task pane, on the Tasks tab, click Add Remote Site Network to start the New Network Wizard.
   
5. On the Welcome page, provide a name for the new network, such as Washington Sales Office IPSec Tunnel, and then click Next. The network name is limited to 200 characters.
   
6. On the VPN Protocol page, select IP Security protocol (IPSec) tunnel mode, and then click Next.
   
7. 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. For example, as shown in the figure, the remote VPN gateway IP address is 208.147.66.1.
   
8. Click Networks to open the Access Networks dialog box. Select the network that represents the VPN gateway for the ISA Server computer. Typically, and by default, this will be the External network, because the VPN connection will be across the Internet. Click OK to close the Access Networks dialog box.
   
9. In Local VPN gateway IP address,select the IP address of the network adapter that connects the ISA Server computer to the network you selected in the previous step. For example, as shown in the figure, the IP address for the network adapter that connects the ISA Server computer to the External network is 157.54.0.1.
   
10. 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.
    
11. On the Network Addresses page, click Add and add the address ranges of the remote network. You can obtain this information from the administrator of the remote network.
    
12. On the summary page, review the configuration, and then click Finish.
    
13. In the ISA Server details pane, click Apply to apply the changes to ISA Server.
    

    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.

    Important:

    You may be required to restart the ISA Server computer after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the ISA Server computer 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 computer.

After you have created the remote VPN, ISA Server views it as it does any other network connected to the ISA Server computer. 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 computer. 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 have to 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.

If your ISA Server computer 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.

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

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

1. Open Microsoft ISA Server Management.
   
2. In the console tree, select Virtual Private Networks (VPN).
   
3. In the details pane, select the Remote Sites tab.
   
4. Select the network you created in Procedure 1.
   
5. 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 computer can be configured.
   

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.

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.

1. Open Microsoft ISA Server Management.
   
2. In the console tree, select Virtual Private Networks (VPN).
   
3. 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.
   
4. 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.
   
5. Click OK to close the IPSec Configuration dialog box, and OK to close the network properties dialog box.
   
6. 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.
   

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

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.

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 computer as a remote VPN. The following procedure sets up that network.

1. Open Microsoft ISA Server Management.
   
2. In the console tree, select Virtual Private Networks (VPN).
   
3. In the details pane, select the Remote Sites tab.
   
4. In the task pane, on the Tasks tab, click Add Remote Site Network to start the New Network Wizard.
   
5. On the Welcome page, provide a name for the new network, such as Washington Sales Office L2TP over IPSec, and then click Next.
   
6. On the VPN Protocol page, select Layer Two Tunneling Protocol (L2TP) over IPSec, and then click Next.
   
7. 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, the remote VPN gateway IP address is 208.147.66.1.
   
8. 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 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.
   
9. The Local Authentication page provides a reminder that a user with dial-in properties must be configured on the local network for the remote network to be able to initiate a connection to the local network. 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.
   

   Note:

   To configure a user with dial-in properties, open Computer Management. (Click Start, right-click My Computer, and then click Manage.) In Local Users and Groups, right-click Users and select New User. Complete the New User dialog box, being sure to provide a name that is identical to the name of the remote network. Double-click the new user to open its properties, and select the Dial-in tab. Under Remote Access Permission (Dial-in or VPN), select Allow access. Click OK to close the properties dialog box.

10. On the Local Authentication page, click Next.
    
11. On the L2TP/IPSec Authentication page, you have the option of adding preshared key IPSec authentication as a backup authentication method. If you select this option, provide the preshared key. Digital certificates are used as the primary authentication method, if you have installed digital (IPSec) certificates from the same trusted certificate 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:

    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. 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 certificate 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.

12. On the Network Addresses page, click Add and add the address ranges of 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.
    
13. On the summary page, review the configuration, and then click Finish.
    

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.

1. Open Microsoft ISA Server Management.
   
2. In the console tree, select Virtual Private Networks (VPN).
   
3. 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 remote VPN you created, so that the remote network will be able to initiate a connection to the local VPN server.
   
4. Select the Address Assignment tab. We recommend that you use a Dynamic Host Configuration Protocol (DHCP) server to dynamically assign IP addresses to VPN clients when they connect. 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.
   

   Note:
   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 computer, 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 computer. 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. Note that IP addresses in the static address pool cannot be addresses that are included in the Internal 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.
   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.
   
5. 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.
   
6. 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.
   
7. Click OK to close the Virtual Private Networks (VPN) Properties dialog box.
   
8. 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 computer after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the ISA Server computer 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 computer.

After you have created the remote VPN, ISA Server views it as it does any other network connected to the ISA Server computer. 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 computer. 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 have to connect across the two VPN networks, so that a route relationship can be established. To create a network rule, follow the procedure in Appendix H: 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.
  

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.

Configure the remote VPN server to connect to the ISA Server computer in L2TP over IPSec mode. Follow the manufacturers 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.

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

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

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.

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 computer as a remote VPN. The following procedure sets up that network.

1. Open Microsoft ISA Server Management.
   
2. In the console tree, select Virtual Private Networks (VPN).
   
3. In the details pane, select the Remote Sites tab.
   
4. In the task pane, on the Tasks tab, click Add Remote Site Network to start the New Network Wizard.
   
5. On the Welcome page, provide a name for the new network, such as Washington Sales Office PPTP, and then click Next.
   
6. On the VPN Protocol page, select Point-to-Point Tunneling Protocol (PPTP), and then click Next.
   
7. 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, the remote VPN gateway IP address is 208.147.66.1.
   
8. 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 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.
   
9. The Local Authentication page provides a reminder that a user with dial-in properties must be configured on the remote network. 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. Click Next.
   

   Note:
   To configure a user with dial-in properties, open Computer Management. (Click Start, right-click My Computer, and then click Manage.) In Local Users and Groups, select Users. Double-click a user to open its properties, and select the Dial-in tab. Under Remote Access Permission (Dial-in or VPN), select Allow access. Click OK to close the properties dialog box.

10. On the Network Addresses page, click Add and add the address ranges of the remote network. You can obtain this information from the administrator of the remote network.
    
11. On the summary page, review the configuration, and then click Finish.
    
12. In the ISA Server details pane, click Apply to apply the changes to ISA Server.
    

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.

1. Open Microsoft ISA Server Management.
   
2. In the console tree, select Virtual Private Networks (VPN).
   
3. 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 remote VPN you created, so that the remote network will be able to initiate a connection to the local VPN server.
   
4. Select the Address Assignment tab. We recommend that you use a Dynamic Host Configuration Protocol (DHCP) server to dynamically assign IP addresses to VPN clients when they connect. Select Dynamic Host Configuration Protocol (DHCP). From the drop-down menu below Use the following network to obtain DHCP, DNS and WINS, select Internal, to indicate that the DHCP server is on the Internal network. Click OK.
   

   Note:
   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 computer, 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 computer. 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. Note that IP addresses in the static address pool cannot be addresses that are included in the Internal 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.
   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.
   
5. Select the Authentication tab, and then select the authentication methods that the incoming connection requests will use.
   
6. 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 computer after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the ISA Server computer 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 computer.

After you have created the remote VPN, ISA Server views it as it does any other network connected to the ISA Server computer. 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 computer. 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 have to connect across the two VPN networks, so that a route relationship can be established. To create a network rule, follow the procedure in Appendix H: 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.
  

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.

If your ISA Server computer 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.

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

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

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 Server2004 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.

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 organizations 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 themselves. 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 computer. 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 computer.

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 computer to make the Web page available outside of your corporate network. For more information, see the document Publishing Web Servers Using ISA Server 2004 (www.microsoft.com).

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.

1. Open the Control Panel.
   
2. Double-click Add or Remove Programs.
   
3. Click Add/Remove Windows Components.
   
4. Double-click Application Server.
   
5. Double-click Internet Information Services (IIS).
   
6. Double-click World Wide Web Service.
   
7. Select Active Server Pages.
   
8. 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.
   
9. 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.
   
10. 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.
      
11. 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.
    
12. On the Certificate Database Settings page, review the default settings. You may revise the database locations. Click Next.
    
13. On the Completing the Windows Components Wizard page, review the summary, and then click Finish.
    

This procedure is performed on the ISA Server computer 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.

1. Open Internet Explorer.
   
2. From the menu, select Tools, and then select Internet Options.
   
3. Select the Security tab, and in Select a Web content zone to specify its security settings, click Trusted Sites.
   
4. Click the Sites button to open the Trusted sites dialog box.
   
5. In Add this Web site to the zone, provide the certificate server website name (http://IP address of certification authority server/certsrvname) and click Add.
   
6. Click Close to close the Trusted sites dialog box, and then click OK to close Internet Options.
   
7. Browse to: http://IP address of certification authority server/certsrv.
   
8. Request a certificate.
   
9. Select Advanced Certificate Request.
   
10. 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).
    
11. 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)
      
12. 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.
    
13. 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.
       
14. On the ISA Server computer, return to the Web page http://IP address of certification authority server/certsrv, and then click View status of a pending request.
    
15. Click your request and choose Install this certificate.
    
16. Return to the Web page http://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 computer. In the File Download dialog box, click Open.
    
17. On the Certificate dialog box, click Install Certificate, to start the Certificate Import Wizard.
    
18. 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.
    
19. On the summary page, review the details and click Finish.
    
20. 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.
    
21. 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.
    

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.

This procedure is performed on the ISA Server computer.

1. In the ISA Server console tree, 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 servers 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.
   
2. 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.
     

In this scenario, the remote site is a branch office, and the ISA Server computer 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.

In this scenario, the remote site is a branch office, and the ISA Server computer 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 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.
  

Follow these general steps to create this firewall policy.

1. 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.
   
2. 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 SQL server, one for the Exchange server, and one for the internal domain controller. Where there is more than one server, such as two SQL servers, create a computer set rather than a computer object.
   
3. 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.
   
4. Create an access rule allowing Microsoft SQL (TCP) and Microsoft SQL (UDP) protocols from the account managers computer set to the SQL server on the Internal network of the main office.
   
5. 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.
   
6. 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.