VPN Concepts in ISA Server 2006

VPN Concepts in ISA Server 2006

Microsoft Internet Security and Acceleration Server 2006

Microsoft® Internet Security and Acceleration (ISA) Server 2006 Standard Edition and ISA Server 2006 Enterprise Edition provide secure site-to-site virtual private network (VPN) functionality and secure VPN client access. In ISA Server 2006 Enterprise Edition, this functionality works with the ISA Server Network Load Balancing (NLB) functionality to provide redundancy and failover capacity for VPN.

Virtual Private Networks

A 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 or two networks 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 VPN.

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 a user's perspective, you are connected to the corporate network, and do not consider that you are communicating over a public infrastructure. 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 or branch offices 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. These connections are made over the Internet using a site-to-site VPN connection. Companies are changing from leased lines to standard Internet connections, because of the higher costs of leased lines, the complexities of maintaining these leased lines, and time required to have leased lines installed.

By using ISA 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 to a VPN server that connects the remote access client 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 "VPN Roaming Clients and Quarantine Control in ISA Server" at the Microsoft TechNet Web site.

By using the ISA Server computer as the VPN server, you can manage VPN client access to the corporate network. VPN clients can be quarantined by ISA Server in the Quarantined VPN Clients network, until their compliance with corporate security requirements is verified, and can then be moved to the VPN Clients network. Both of these VPN client networks are subject to your ISA Server firewall access policy, so that you can control VPN client access to network resources. For example, you can allow quarantined clients access to only the resources needed to restore their security compliance, such as access to antivirus updates or to a Windows Update server.

All VPN connections to the ISA Server computer are logged to the Firewall log, so that you can monitor VPN connections.

ISA Server enables VPN client access using either Layer Two Tunneling Protocol (L2TP) over Internet Protocol security (IPsec), or the Point-to-Point Tunneling Protocol (PPTP) commonly used by VPN servers. We recommend that L2TP over IPsec be used. From a security standpoint, L2TP over IPsec is superior to PPTP, because it uses certificate authentication to secure the connection.

Quarantine Control

Quarantine Control provides phased network access for remote (VPN) clients by restricting them to a quarantine mode before allowing them access to the network. After the client computer configuration is either brought into or determined to be in accordance with your organization's specific quarantine restrictions, standard VPN policy is applied to the connection, in accordance with the type of quarantine you specify. Quarantine restrictions might specify, for example, that specific antivirus software is installed and enabled while connected to your network. Although Quarantine Control does not protect against attackers, computer configurations for authorized users can be verified and, if necessary, corrected before they can access the network. A timer setting is also available, which you can use to specify an interval at which the connection is dropped if the client fails to meet configuration requirements.

With ISA Server, you can select how to enable quarantine mode:

Enable quarantine mode, using Routing and Remote Access. When you select the Quarantine according to RADIUS Server policies option, when a VPN client attempts to connect, Routing and Remote Access determines if the client will be subject to quarantine. After the client clears quarantine, the client unconditionally joins the VPN Clients network.
Enable quarantine mode, using ISA Server. When you select the Quarantine VPN clients according to ISA Server policies option, when a VPN client attempts to connect, Routing and Remote Access unconditionally passes the request to the ISA Server computer. ISA Server determines if the client will be subject to quarantine. After the client clears quarantine, the client joins the VPN Clients network.

You can also choose to disable quarantine mode. Quarantine Control is disabled by default and is enabled on the Quarantine VPN Clients network. For more information about configuring Quarantine Control, see "VPN Roaming Clients and Quarantine Control in ISA Server" at the Microsoft TechNet Web site.

VPN client credentials

The credentials received by ISA Server when a user connects through a VPN client connection can vary depending on the connection scenario.

When a user establishes a VPN connection from a client computer, ISA Server associates those credentials with the connection. Note that if other users use that connection, ISA Server will not receive their credentials, but will continue to associate the traffic with the credentials used to establish the connection, which could be a security concern. This would be the case if users use Terminal Services to connect to the client computer, and then make requests over the VPN connection. Another example is if the client computer is configured to act as a network address translation (NAT) device, allowing the VPN connection to be shared among many users on different computers.

When the computer that hosts a VPN client connection, or the computers behind it, have a properly installed and configured Firewall client, those computers will join the VPN Clients network, but ISA Server receives the credentials of each user, rather than the credentials of the host computer.

Virus infected VPN clients

VPN client computers that are infected with viruses are not automatically blocked from flooding the ISA Server computer (or the networks it protects) with requests. To prevent this occurrence, implement monitoring practices to detect anomalies such as alerts or unusual peaks in traffic loads, and configure alert notification by e-mail. If an infected VPN client computer is identified, perform one of the following:

Restrict VPN access by user name by using the remote access policy to exclude the user from the VPN clients who are not allowed to connect.
Restrict VPN access by IP address. Do this by creating a new network to contain external IP addresses that are blocked, and move the IP address of the client out of the External network to the new network. This only works when the user connects from the same IP address all the time. If the client computer is assigned a different address each time it connects to the public network, we recommend that you restrict access based on user name.

Site-to-Site VPN Connection

A site-to-site VPN connection connects two separate private networks. 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. For a detailed description about how to deploy a hub-spoke or mesh VPN configuration, see "Virtual Private Network Deployment Scenarios in ISA Server Enterprise Edition" at the Microsoft TechNet Web site.

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

PPTP
L2TP over IPsec
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, multiple 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 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 one VPN server to the other 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 or a preshared key.

Important:
When choosing between PPTP and L2TP over IPsec site-to-site VPN solutions, consider the following:

PPTP can be used for site-to-site VPN connections for servers 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 servers running Windows Server 2003 or Windows 2000 Server operating systems. When both types of servers are used, a PKI is required to issue computer certificates to all routers. Servers running Windows Server 2003 operating systems additionally support a single preshared key configured on the answering server and all calling servers. By using IPsec, L2TP over IPsec VPN connections provide data confidentiality, data integrity, and data origin authentication.

IPsec tunnel mode

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 at the Virtual Private Network Consortium Web site.

Tunneling is the entire process of encapsulation, routing, and then removing the encapsulation. 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.

For more information about IPsec tunnel mode, see "IPSec Technical Reference" at the Microsoft TechNet Web site.

Note:
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.

Note:

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.

Authentication

IPsec tunnel mode and L2TP over IPsec can use either preshared keys or certificates to authenticate incoming VPN connections. Because certificates are more secure than preshared keys, we recommend that authentication for L2TP over IPsec and IPsec tunnel mode VPN connections use certificate authentication.

Important:
For security reasons, we recommend the use of a dedicated private certification authority (CA) for certificates that will be used for IPsec authentication. This is due to the fact that IPsec does not match the name of the certificate to the name of the site. If the certificates come from the same CA, this is sufficient for authentication. For more information about security consideration for site-to-site VPN connections, see "Security Hardening and Administration Guide" at the Microsoft TechNet Web site.

Important:

For security reasons, we recommend the use of a dedicated private certification authority (CA) for certificates that will be used for IPsec authentication. This is due to the fact that IPsec does not match the name of the certificate to the name of the site. If the certificates come from the same CA, this is sufficient for authentication. For more information about security consideration for site-to-site VPN connections, see "Security Hardening and Administration Guide" at the Microsoft TechNet Web site.

VPN Considerations in Enterprise Edition

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

If you are using a multiple-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.
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 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.
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 multiple-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.

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 recommendations on where to install replicate Configuration Storage servers, see the "ISA Server Security Hardening and Administration Guide" at the Microsoft TechNet Web site. Note that there is also an option of connecting to a securely published configuration storage server, as described in "Securely Publish ISA Server Configuration Storage Server" at the Microsoft TechNet Web site.
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 unique 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 able to accept VPN connections until you add a static address pool.

Client Considerations in Enterprise Edition

In ISA Server 2006 Enterprise Edition, 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.

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 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 clients, in a scenario where there is a NAT relationship between those client networks and the remote VPN network.

Example of the Scenario

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 the request to the remote VPN site. However, because that member is not handling the connection to the remote site, it routes the request through the array member that handles 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.

The solution for this issue is to configure intra-array communication. 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.

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 clients and roaming VPN clients in the route relationship, site-to-site VPN scenario should not include user-specific rules.

DNS Configuration

In ISA Server 2006 Enterprise Edition, 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 Domain Name System (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.