VPN Roaming Clients and Quarantine Control in ISA Server 2004

Microsoft Internet Security and Acceleration (ISA) Server 2004 provides secure virtual private network (VPN) functionality for roaming clients.

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 users 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 computer as the VPN server, you can manage site-to-site VPN connections and 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. For more information about the implementation of VPN client quarantine for ISA Server, see Quarantine Control in this document. For information about how to configure Quarantine Control, see Quarantine Control Procedures in this document.

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 Layer Two Tunneling Protocol (L2TP) over Internet Protocol security (IPSec), which is superior from a security standpoint to the standard Point-to-Point Tunneling Protocol (PPTP) commonly used by VPN servers.

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.

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 computer is attached. Configuration of site-to-site VPN connections is described in the document Site-to-Site VPN in ISA Server 2004 (download solution documents from https://go.microsoft.com/fwlink?linkid=20746).

VPN Protocols

There are two VPN protocols for roaming client connections:

• Point-to-Point Tunneling Protocol (PPTP)
• Layer Two Tunneling Protocol (L2TP)

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

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 L2TP 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/IPSec connections require the same user-level authentication and, in addition, computer-level authentication using computer certificates.

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 organizations 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. This option is available only when ISA Server is installed on a computer running a member of the Microsoft® Windows Server 2003 family. When you select the Quarantine according to RADIUS Server policies option, then when a VPN client attempts to connect, ISA Server 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. This option provides use of the Quarantined VPN Clients network, for which you can set firewall policy. This option does not require Routing and Remote Access functionality, and therefore is available when ISA Server is installed on a computer running a member of the Windows® 2000 Server family.

You can also choose to disable quarantine mode.

To do so, open Computer Management, and expand the Routing and Remote Access node. Select Remote Access Policies. In the details pane, double-click each policy to open its properties, and select Edit Profile. On the Advanced tab, remove MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout from the attributes list, and then click OK.

For more information about Quarantine Control in ISA Server, see Quarantine Control Procedures in this document.

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, as follows:

• When a user establishes a VPN connection from a client computer, ISA Server associates those credentials with the connection. 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. 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 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 (RAP) to exclude the user from the VPN clients who are 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.

Scenarios

Using ISA Server 2004, you want to enable part of your workforce to connect to your Internal network from anywhere in the world, using a local Internet connection. For example, your offices are located in New York City, and your salesperson is working in Chicago. Rather than have the salesperson call in to New York City to connect directly to your Internal network (using Routing and Remote Access), you want the salesperson to connect to the Internet locally and use a VPN connection to access the Internal network. This is the remote access VPN scenario.

You may want to quarantine each VPN client when it connects, to ensure that it complies with your security policy. VPN clients that do not comply will be allowed to connect to resources on the Internal network from which they can retrieve the software or updates needed to achieve compliance, but will not be allowed general access to corporate resources.

Solutions

Using ISA Server 2004, two solutions are described in this document. One uses the Point-to-Point Tunneling Protocol (PPTP), and the other uses the Layer Two Tunneling Protocol (L2TP). Quarantine Control procedures are also described following the PPTP and L2TP solutions. This section contains the following topics:

• Network Topology
• Remote Access Using PPTP ” Walk-through
• Remote Access Using L2TP ” Walk-through
• Quarantine Control Procedures

Network Topology

The following figure describes a typical network topology for the roaming VPN client solutions.

Three networks are shown:

• The Internet, where the VPN client is located. The VPN client in this solution is a computer running Windows® XP, although other clients are supported.
• The VPN gateway, consisting of an ISA Server computer. This computer has Windows Server 2003 and ISA Server 2004 installed.
• The Internal network. The Internal network includes:
  • The domain controller, which has Windows Server 2003 or Windows 2000 Server installed. The domain controller stores user information needed for authentication of roaming VPN clients.
  • A Web server, used in this case to test roaming VPN client access to the Internal network.
  • A DHCP server, which dynamically assigns IP addresses to roaming VPN clients.
  • A certification authority (CA), needed only for the L2TP solution. Setup of the certification authority is described in the topic Remote Access Using L2TP ” Walk-through in this document.

Remote Access Using PPTP ” Walk-through

This walk-through contains the following procedures:

• Configure users and Windows services
• Configure VPN on ISA Server
• Configure the VPN client
• Test the connection

PPTP Walk-through Procedure 1: Configure Users and Windows Services

You can configure users and Windows services, using the following steps:

• Creating VPN clients and user group on the domain controller
• Configuring the DHCP server and scope

Creating VPN clients and user group on the domain controller

The first step is to create VPN clients on the domain controller computer. This computer contains the user group and user information that is necessary to authenticate your remote user. To keep track of the VPN users, this step also creates a new users group called VPN Clients.

To create VPN clients and user group on the domain controller:

1. Select Start, point to All Programs, point to Administrative Tools, and click Active Directory Users and Computers.

2. In Active Directory Users and Computers, in the domain node, right click Users, point to New and click Group.

3. In the New Object - Group dialog box, create a new group with the name VPN Clients. Leave the default selections for Group Scope (Global) and Group Type (Security) and click OK.

4. In Active Directory Users and Computers, in the domain node, right click Users, point to New and click User.

5. In New Object - User, provide the user information and then click Next. Provide the password information and then click Next. On the final page, click Finish.

6. Double click the VPN Clients group. On the Members tab, click Add to add the users you created. After you add the users, click OK.

Configuring the DHCP server and scope

A DHCP server will dynamically assign IP addresses to VPN clients when they connect. This is the recommended approach to assigning IP addresses to VPN clients. Alternatively, you can provide the IP addresses from a static pool of addresses, an approach that can be used, for example, when your Internal network IP addresses are statically assigned.

Any computer running Windows Server 2003 or Windows 2000 Server in the Internal network can serve as the DHCP server. The existing DHCP server of your Internal network will serve VPN client needs. If you do not have a DHCP server, configure a server using one of the procedures described in the following articles:

• HOW TO: Install and Configure a DHCP Server in an Active Directory Domain in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=18606).

• HOW TO: Install and Configure a DHCP Server in a Workgroup in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=18607).

• HOW TO: Install and Configure a DHCP Server in an Active Directory Domain in Windows 2000 (https://go.microsoft.com/fwlink/?LinkId=18608).

• HOW TO: Install and Configure a DHCP Server in a Workgroup in Windows 2000 (https://go.microsoft.com/fwlink/?LinkId=18609).

  Note

  If you use a DHCP server for address assignment, when a VPN client establishes a connection, its address is automatically moved from the Internal network to the VPN Clients network (or Quarantined VPN Clients network, if quarantine is enabled and the client is quarantined). The address is restored to the Internal network when the client disconnects. This address assignment is not visible in ISA Server Management. If you use a static address pool for address assignment, the addresses that you want to assign to the pool must first be removed from other defined networks, because the overlapping of IP addresses between networks is not allowed.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.)The ISA Server computer acts as an Address Resolution Protocol (ARP) proxy for VPN clients. For example, when addresses assigned to the VPN Clients network are part of the Internal network segment, whether addresses are assigned from a static pool or by a DHCP server, computers from the Internal network will send ARP queries to VPN clients. ISA Server will intercept the queries and reply on behalf of the connected VPN client.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.

PPTP Walk-through Procedure 2: Configure VPN on ISA Server

You can now configure the VPN settings on the ISA Server computer, using the following steps:

• Enabling and configuring VPN client access
• Creating a VPN access rule
• Checking the VPN networks routing rule

Enabling and configuring VPN client access

To enable and configure VPN client access:

1. Open Microsoft ISA Server Management.

2. In the console tree, select Virtual Private Networks (VPN).

3. In the details pane, make sure that the VPN Clients tab is selected.

4. In the task pane, on the Tasks tab, click Enable VPN Client Access. This action automatically enables the system policy access rules needed to allow VPN client access, and starts Routing and Remote Access, needed for VPN client connection.

5. In the task pane, on the Tasks tab, click Configure VPN Client Access.

6. On the General tab, select the Enable VPN client access check box, and then set the maximum number of VPN clients allowed.

7. On the Groups tab, click Add, and add the VPN Clients group that you created in Procedure 1. Click OK to close the VPN Clients Properties dialog box.

   Note

   You cannot add the Windows built-in user groups as VPN users. Built-in domain groups may be used (even in a situation where the ISA Server computer is also the domain controller).

8. In the task pane, on the Tasks tab, click Define Address Assignments to open the Virtual Private Networks (VPN) Properties dialog box on the Address Assignment tab. 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, and then click OK, to indicate that the DHCP server is on the Internal network. You may be prompted to restart the computer.

   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 computer, as shown in the following figure.

   

   Or, there must be a router specifically configured to pass DHCP requests to a DHCP server behind the router. If you do not want to set up a DHCP server or configure a router to pass DHCP requests, 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. 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 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.

9. You may want to modify the authentication method used to authenticate VPN clients. (MS-CHAPv2 is selected by default.) To do so, in the task pane, on the Tasks tab, click Select Authentication Methods to open the Virtual Private Networks (VPN) Properties dialog box on the Authentication tab. The authentication methods are described in Appendix D: Authentication Methods in this document.

10. In the ISA Server details pane, click Apply to apply the changes to ISA Server.

    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.

Creating a VPN access rule

Create a new access rule with the properties shown in the following table. This rule will allow access from the VPN Clients network to the Internal network on all protocols. To create a new access rule, follow the instructions in Appendix B: Using the New Access Rule Wizard in this document. After you create the new access rule, click Apply in the ISA Server details pane to apply the new access rule. Some properties cannot be set in the wizard. To set those properties, in the Firewall Policy details pane, double-click the rule to open the rule properties dialog box.

Notes:  You can limit VPN client access to certain protocols by selecting Selected Protocols, and choosing the protocols from the Add Protocols dialog box.

If you consider the VPN Clients network to be identical to the Internal network from a firewall policy perspective, you may also want to create an access rule allowing all traffic from the Internal network to the VPN Clients network.

If ISA Server is configured as a VPN server and acts as a firewall server for Firewall clients, VPN client computers with Firewall Client installed will use port 1745 of the ISA Server Internal network interface. Also, if ISA Server is configured as a VPN server and acts as a proxy server for Web Proxy clients, VPN client computers using the ISA Server as a proxy will use port 8080 of the ISA Server Internal network interface. By default, when you define a rule allowing access from the VPN Clients network to the Internal network, access is allowed to all ports. However, if you choose to limit the ports, you must allow access to ports 1745 and 8080, respectively, for these scenarios.

Checking the VPN networks routing rule

When you install ISA Server, a default network rule is created, establishing a routing relationship between the Internal network and the two VPN clients networks (VPN Clients and Quarantined VPN Clients). To view the rule, expand the Configuration node and click Networks. In the details pane, on the Network Rules tab, the VPN Clients to Internal Network rule is listed. To view the rules properties, double-click the rule. For more information about the relationship between the VPN Clients networks and the Internal network, see Appendix C: Network Relationships in this document.

PPTP Walk-through Procedure 3: Configure the VPN Client

This procedure is performed on the VPN client computer. The procedure is based on the features of Windows XP, although other clients are supported.

PPTP Walk-through Procedure 4: Test the Connection

You can test the connection, using the following steps:

Checking the connection from the client to the ISA Server computer

This procedure is performed on the VPN client computer.

Checking ISA Server for connection information

This procedure is performed on the ISA Server computer.

Remote Access Using L2TP ” Walk-through

This walk-through contains the following procedures:

L2TP Walk-through Procedure 1: Configure Users and the DHCP Server

You can configure users and the DHCP server, using the following steps:

Creating VPN clients group and users on the domain controller

The first step is to create VPN clients on the domain controller computer. This computer contains the user group and user information that is necessary to authenticate your remote user. To keep track of the VPN users, this step also creates a new users group called VPN Clients.

Configuring the DHCP server and scope

A DHCP server will dynamically assign IP addresses to VPN clients when they connect. This is the recommended approach to assigning IP addresses to VPN clients. Alternatively, you can provide the IP addresses from a static pool of addresses, an approach that can be used, for example, when your Internal network IP addresses are statically assigned.

Any computer running Windows Server 2003 or Windows 2000 Server in the Internal network can serve as the DHCP server. The existing DHCP server of your Internal network will serve VPN client needs. If you do not have a DHCP server, configure a server using one of the procedures described in the following articles:

L2TP Walk-through Procedure 2: Set up the Certification Authority

You need a certification authority (CA) to issue IP security (IPSec) certificates. Because the certificates are for internal use only (to be used on your servers and your VPN clients), it is advisable to create a local CA. This procedure is performed on a computer running Windows in the Internal network. For a stand-alone root CA, this can be any computer running Windows in the Internal network. An enterprise root CA must be installed on a domain controller.

Because L2TP with IPSec requires IPSec certificates to be installed from a CA, you will also install the services that will enable computers to obtain the certificates through a Web page. 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.

L2TP Walk-through Procedure 3: Configure VPN on ISA Server

You can now configure the VPN settings on the ISA Server computer, using the following steps:

Enabling and configuring VPN client access

Creating a VPN access rule

Create a new access rule with the properties shown in the following table. This rule will allow access from the VPN Clients network to the Internal network on all protocols. To create a new access rule, follow the instructions in Appendix B: Using the New Access Rule Wizard in this document. After you create the new access rule, click Apply in the ISA Server details pane to apply the new access rule. Some properties cannot be set in the wizard. To set those properties, in the Firewall Policy details pane, double-click the rule to open the rule properties dialog box.

Notes:  You can limit VPN client access to certain protocols by selecting Selected Protocols on the Protocols tab, and choosing the protocols from the Add Protocols dialog box.

If you consider the VPN Clients network to be identical to the Internal network from a firewall policy perspective, you may also want to create an access rule allowing all traffic from the Internal network to the VPN Clients network.

If ISA Server is configured as a VPN server and acts as a firewall server for Firewall clients, VPN client computers with Firewall Client installed will use port 1745 of the ISA Server Internal network interface. Also, if ISA Server is configured as a VPN server and acts as a proxy server for Web Proxy clients, VPN client computers using the ISA Server as a proxy will use port 8080 of the ISA Server Internal network interface. By default, when you define a rule allowing access from the VPN Clients network to the Internal network, access is allowed to all ports. However, if you choose to limit the ports, you must allow access to ports 1745 and 8080, respectively, for these scenarios.

Checking the VPN networks routing rule

When you install ISA Server, a default network rule is created, establishing a routing relationship between the Internal network and the two VPN clients networks (VPN Clients and Quarantined VPN Clients). To view the rule, expand the Configuration node and click Networks. In the details pane, on the Network Rules tab, look for the VPN Clients to Internal Network rule. For more information about the relationship between the VPN clients networks and the Internal network, see Appendix C: Network Relationships in this document.

L2TP Walk-through Procedure 4: Install a Certificate on the Server Computer

This procedure is performed on the ISA Server computer, using the following steps:

Creating an access rule from the ISA Server computer to the Internal network

For the ISA Server computer to access the certification authority (CA), you must create an access rule. ISA Server requires this access rule to obtain its certificate.

Installing the certificates on the ISA Server computer

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

L2TP Walk-through Procedure 5: Install a Certificate on the Client Computer

This procedure is performed on the VPN client computer. For purposes of this procedure, it is assumed that initially, the client computer is connected to the Internal network to obtain the certificate. If you installed a stand-alone root CA rather than an enterprise root CA, there are also actions that take place on the certification authority.

L2TP Walk-through Procedure 6: Configure the VPN Client

This procedure is performed on the VPN client computer. The procedure is based on the features of Windows XP, although other clients are supported.

L2TP Walk-through Procedure 7: Test the Connection

You can test the connection, using the following steps:

Checking the connection from the client to the ISA Server computer

This procedure is performed on the VPN client computer.

Checking ISA Server for connection information

This procedure is performed on the ISA Server computer.

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

Quarantine Control Procedures

Quarantine Control is an option available to you as a means of controlling the compliance of VPN clients with your corporate security requirements. Note that when quarantine mode is disabled, all remote VPN clients with appropriate authentication permissions are placed in the VPN Clients network, and will have the access you have allowed the VPN Clients network in your firewall policy.

NoteQuarantine Control is an administrative tool that enables you to ensure that your clients are in compliance with your policies. It is not a security feature. Quarantine Control does not provide encryption or authentication mechanisms.

Quarantine Control for ISA Server works with Routing and Remote Access to provide a means of restricting VPN client access to corporate networks. With ISA Server, you can require that a newly connected VPN client is assigned to the Quarantined VPN Clients network, with a restrictive firewall policy, until the client’s Connection Manager indicates that the client is in compliance with corporate connection policy.

Quarantine Control relies on the Connection Manager (CM) profile you create for your VPN clients. CM profiles are created with the Connection Manager Administration Kit (CMAK) provided in Windows Server 2003 and Windows 2000 Server. The CM profile contains a post-connect action that runs a network policy requirements script, configured when the CM profile is created with CMAK.

You will require a network policy requirements script that performs validation checks on the remote access client computer to verify that it conforms to network policies. This is the script that is called by the CM profile. This can be a custom executable file or a simple command file (also known as a batch file). When the script has run successfully and the connecting computer has satisfied all of the network policy requirements (as verified by the script), the script runs a notifier component (an executable) with the appropriate parameters. If the script does not run successfully, it should direct the remote access user to a quarantine resource such as an internal Web page, which describes how to install the components that are required for network policy compliance.

You will also require a notifier component that sends a message indicating a successful execution of the script to the quarantine-compatible ISA Server array. This is the component that is called by the network policy requirements script. You can use your own notifier component or you can use Rqc.exe, which is provided with the ISA Server 2004 Resource Kit in the RQSUtils executable.

With these components installed, the remote access client computer uses the CM profile to perform network policy requirements tests and indicate its success to the ISA Server array as part of the connection setup.

For more information about CMAK profiles, download the document "Network Access Quarantine Control in Windows Server 2003". For sample quarantine scripts, see VPN Quarantine Sample Scripts for Verifying Client Health Configurations.

Enabling Quarantine Using ISA Server

You can use ISA Server to process specific options for remote VPN clients in quarantine mode. When a client attempts a VPN connection, the client is placed in a Quarantined VPN Clients network. You can apply specific policies for clients in this network, which specify the resources that are accessible to clients in the Quarantined VPN Clients network.

When you enable quarantine for ISA Server, you can configure the following:

If you are running ISA Server on Windows Server 2003, you can enable quarantine by using RADIUS policy or by using ISA Server policy. When you run ISA Server on Windows 2000 Server, you can enable quarantine using ISA Server policy. RADIUS quarantine policy is not supported in Windows 2000 Server.

Selecting RADIUS quarantine policy or ISA Server policy

RADIUS quarantine policy provides two features:

We recommend that you use the RADIUS quarantine policy. Use the ISA Server policy only if you do not have a RADIUS server or if you are running ISA Server on a Windows 2000 server.

For more information about RADIUS quarantine policy, see the document Network Access Quarantine Control in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=20173).

Note:  In a situation where you have several branch offices, each running ISA Server 2004 Standard Edition, you may want to enable Quarantine Control using RADIUS policy to centralize the quarantine control in a single RADIUS server that serves all of the branches.

Quarantine Requirements

This section describes what you need to run ISA Server Quarantine Control.

ISA Server computer

A quarantine-compatible ISA Server computer has the following components:

If you create your own listener component, it must be designed to listen for a message from the notifier component and use the application programming interface (API) described in MprAdminConnectionRemoveQuarantine() (https://go.microsoft.com/fwlink/?LinkId=20172) to remove the quarantine restrictions from the remote access connection. Note that the API must call Vpnplgin.dll (in the ISA Server installation directory), rather than Mprapi.dll, as shown in the API documentation. ISA Server will then chain the call to Routing and Remote Access.

With these components installed, the ISA Server computer can use quarantine mode for connecting remote access clients and listen for notifier messages, indicating that the clients have satisfied network policy requirements and can be moved from the Quarantined VPN Clients network to the VPN Clients network.

If you are using Rqc.exe (the notifier component provided in the ISA Server 2004 Resource Kit) and Rqs.exe, the notification message sent by Rqc.exe contains a text string that indicates the version of the quarantine script being run. This string is configured for Rqc.exe as part of its command-line parameters, as run from the quarantine script. Rqs.exe compares this text string to a set of text strings stored (in the AllowedSet registry entry) in the registry of each computer running ISA Server services. If there is a match, the quarantine conditions are removed from the connection. The ConfigureRQSForISA.vbs script provided in the ISA Server 2004 Resource Kit RQSUtils executable (https://go.microsoft.com/fwlink/?LinkId=22611) helps install RQS (the listener component). For more information, see Configuring Quarantine Control in this document.

Note:  The notification sent by Rqc.exe is not encrypted or authenticated and can be spoofed by a malicious client.

Routing and Remote Access can be configured with either the Windows or RADIUS authentication provider.

Quarantine-compatible RADIUS server (optional)

If Routing and Remote Access on the ISA Server computer is configured with the RADIUS authentication provider, a quarantine-compatible RADIUS server requires a computer running Windows Server 2003 and Internet Authentication Service (IAS), which supports the configuration of the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout RADIUS vendor-specific attributes (VSAs). The MS-Quarantine-IPFilter attribute is for the quarantine filters. The MS-Quarantine-Session-Timeout attribute is for the quarantine session timer.

Quarantine resources

Quarantine resources consist of servers that a remote access client in quarantine mode can access to perform name resolution (such as DNS servers), obtain the latest version of the CM profile (file servers with anonymous access allowed), or access instructions and components needed to make the remote access client comply with network policies (Web servers with anonymous access allowed). Anonymous access to file and Web resources is needed, because although remote access users may have the correct credentials to create the remote access connection, they might not be using the correct domain credentials to access protected file and Web resources.

How ISA Server Quarantine Control Works

The following process describes how ISA Server Quarantine Control works when Rqc.exe, Rqs.exe, and ISA Server policy are used:

Configuring Quarantine Control

This section includes:

Initial steps

Before you enable quarantine mode, you must complete the following steps:

Quarantine notifier and listener components

You can create your own notifier and listener components, or you can use Rqs.exe (a listener component) and Rqc.exe (a notifier component) from the ISA Server 2004 Resource Kit (https://go.microsoft.com/fwlink/?LinkId=22611). The Remote Access Quarantine Agent service is included when Rqs.exe is installed on an ISA Server computer. When you create the CM profile, you can include the administrator-provided script and Rqc.exe, which are distributed to and installed on remote access client computers. This profile can be installed on the following client operating systems: Windows XP Professional, Windows XP Home Edition, Windows 2000 Professional, Windows Millennium Edition, and Windows 98 Second Edition.

For more information about CMAK, see the Connection Manager Administration Kit in Windows Help.

Quarantine settings

After you complete the preliminary steps for setting up quarantine, you can configure the quarantine settings on the ISA Server computer:

Configure firewall client settings to work with quarantine

To ensure that Rqs.exe on the ISA Server computer will remove firewall client computers from quarantine, a firewall client application exception must be created for Rqc.exe. Without this exception, Rqc.exe responses will be seen as coming from the internal network adapter of ISA Server, rather than from the client, and the client will not be removed from quarantine.

Follow these steps to configure a firewall client application exception:

Firewall policy for quarantined VPN clients

Your firewall policy controls the access you will allow from the Quarantined VPN Clients network to network resources. These resources could include the RADIUS server or domain controller against which the user is authenticated, a server that provides antivirus software and signature updates, and the DHCP server that provides IP addresses to VPN clients.

To allow access to a resource, you create an access rule, with the Quarantined VPN Clients network as the source, and the server to which access is required as the destination. This requires creating a computer rule element for each server, so that it can be used in access rules. Alternatively, you can create a computer set containing all of the computers to which the quarantined clients require access, and create an access rule with the Quarantined VPN Clients network as the source and the computer set as the destination. Another possibility is to design your network so that all of the servers to which access is required are on a subnet, and define a subnet rule element for use in the access rule.

For information about how to create a rule element, see Appendix A: Creating Rule Elements in this document. For information about how to create access rules, see Appendix B: Using the New Access Rule Wizard in this document.

The following are some examples of the types of access you may want to allow the Quarantined VPN Clients network. The first three items on this list represent the access needed by the network policy requirements script, without which the client will not be released to the VPN Clients network. Remember that the Connection Manager specific to your clients may require access to specific servers on specific protocols. Consult with the creator of your Connection Manager to ascertain what access rules are needed. Types of access include:

Appendix A: Creating Rule Elements

Follow this general procedure to create a rule element.

Appendix B: Using the New Access Rule Wizard

This procedure describes the New Access Rule Wizard in general terms. You would use the properties of the design phase in creating your rule.

Appendix C: Network Relationships

When you install ISA Server, a default network rule is created establishing a routing relationship between the Internal network and the two VPN clients networks (VPN Clients and Quarantined VPN Clients). Although the VPN clients networks are not associated with a physical network adapter, ISA Server handles those networks as having a virtual network adapter, to which traffic is routed.

There are situations where you may want to create a network address translation (NAT) relationship between the VPN clients networks and the Internal network. For example, if your network includes a cluster of ISA Server computers, a NAT relationship will ensure that when a packet is sent from one network to the other, it will return through the same ISA Server computer and be recognized, rather than to another server in the cluster, which will discard the unrecognized packet. A NAT relationship will also be useful where the VPN gateway is not the default gateway.

If you create a NAT relationship between the VPN clients networks and the Internal network, recognize that not all protocols are supported by NAT.

Appendix D: Authentication Methods

Authentication methods typically use an authentication protocol that is negotiated during the authentication process. ISA Server supports both highly secure and less secure authentication protocols.

Highly secure authentication protocols

ISA Server supports two highly secure authentication protocols:

MS-CHAPv2

Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) provides mutual authentication, strong initial data encryption keys, and different encryption keys for sending and receiving. To minimize the risk of password compromise during MS-CHAP exchanges, MS-CHAPv2 drops support for the MS-CHAP password change and does not transmit the encoded password. MS-CHAPv2 uses a two-way challenge/response exchange of credentials, utilizing encryption of the password on the responses. The connecting client sends proof of the client password without actually sending the password, and the access server sends proof that it has access to the client password without actually sending the password.

EAP

Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing arbitrary authentication methods that use credential and information exchanges of arbitrary lengths. By using EAP, you can support additional authentication schemes, known as EAP types. These schemes include token cards, one-time passwords, public key authentication using smart cards, and certificates.

Less secure authentication protocols

We recommend that you use the highly secure authentication protocols, but you have the option of using authentication protocols that are less secure. This can be useful for VPN clients running on Windows NT® Server 4.0 or Windows 98 that do not have the latest VPN client software installed. The following protocols can be used:

CHAP

Challenge Handshake Authentication Protocol (CHAP) uses a challenge/response exchange of credentials with Message Digest 5 (MD5) hashing on the response. The connecting client sends proof of the client password without actually sending the password. CHAP is widely supported by both access clients and network access servers. CHAP requires the storage of reversibly encrypted passwords for user accounts in the domain. Enable CHAP only when required by your access clients.

MS-CHAP

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) was created by Microsoft to authenticate remote Windows workstations, providing the functionality that LAN-based users are accustomed to, while integrating the hashing algorithms used on Windows networks. Like CHAP, MS-CHAP uses a challenge/response mechanism to keep the password from being sent during the authentication process. MS-CHAP is supported by certain Microsoft Windows access clients and access servers. Enable MS-CHAP only when required by your access clients.

PAP

Password Authentication Protocol (PAP) sends the password over the connection in an unencrypted form. Enable PAP only when required by your access clients.

SPAP

Shiva Password Authentication Protocol (SPAP) sends the password over the connection in an encrypted form. Enable SPAP only when required by your access clients.

Do you have comments about this document? Send feedback.