VPN: Concepts
This section provides information about the virtual private network (VPN) feature of Internet Security and Acceleration (ISA) Server 2004.
VPN overview
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.
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 internetwork such as the Internet. From the user's perspective, the VPN is a point-to-point connection between the computer, the VPN client, and an organization server (the VPN server). The exact infrastructure of the shared or public network is irrelevant, because it appears as if the data is sent over a dedicated private link.
VPN connections also allow organizations to have routed connections with other organizations over a public internetwork such as the Internet while maintaining secure communications, for example, for offices that are geographically separate. A routed VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link.
With ISA Server 2004, you can configure a secure VPN, accessible by remote access clients and by remote sites, according to your specifications. By using the ISA Server computer as the VPN server, you benefit by protecting your corporate network from malicious VPN connections. Because the VPN server is integrated into the firewall functionality, VPN users are subject to the ISA Server firewall policy. Also, 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.
ISA Server supports two types of VPN connections:
With ISA Server, each type of VPN connection is configured slightly differently. When a single remote VPN client requires access, the configuration is for that single user. In a site-to-site network configuration, an entire network of remote users must be granted access, that is, a network of VPN users is configured.
However, much VPN configuration is common to both scenarios. For example, ISA Server perceives the initial connection request from a remote site network as it would any request from a single remote VPN client. Tunneling protocols, authentication methods, access network, and address assignment for the initial connection must be configured as they would be configured for a remote access client. For information about common VPN configuration, see Common VPN Configuration.
How a VPN works
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. Packets that are intercepted on the shared or public network are indecipherable without the encryption keys. The link in which the private data is encapsulated and encrypted is a virtual private network (VPN) connection.
The following steps describe what happens during a call from a remo 23323t196x te VPN client (or a remote site gateway) to ISA Server 2004:
A remote access client or a remote site gateway dials the ISA Server computer.
ISA Server sends a challenge to the client.
The client (or remote site gateway) sends an encrypted response to the server that consists of a user name, a domain name, and a password.
The server checks the response against the appropriate user accounts database.
If the account is valid and the authentication credentials are correct, the server uses the dial-in properties of the user account and remote access policies to authorize the connection.
Notes
Credentials used for remote access only provide a communication channel to the target network. The client does not log on to the network as a result of a remote access connection. Each time the client attempts to access a network resource, it will be challenged for credentials. If it does not respond to the challenge with acceptable credentials, the access attempt will fail.
Microsoft® Windows ServerT 2003 and Windows® XP add a feature to simplify remote access. After a successful connection, Windows Server 2003 and Windows XP remote access clients will cache these credentials as default credentials for the duration of the remote access connection. When a network resource challenges the remote access client, the client provides the cached credentials without requiring the user to enter them again.
ISA Server and Routing and Remote Access interoperability
ISA Server 2004 depends on and enhances the basic virtual private network (VPN) functionality enabled by Routing and Remote Access, available with Microsoft® Windows ServerT 2003 and Windows® 2000. While most VPN configuration is done by using ISA Server Management, you may also configure some advanced settings using Routing and Remote Access. When you do use Routing and Remote Access to configure VPN, be careful not to override specific settings that should be configured only in ISA Server. In particular, note the following:
Remote VPN Clients
This section provides information about the virtual private network (VPN) feature of Internet Security and Acceleration (ISA) Server for remote VPN clients.
Remote VPN client access
Using ISA Server 2004, you can enable part of
your workhouse to connect to the Internal network from anywhere in the world,
using a local Internet connection. For example, your offices are located in
With ISA Server, you can implement remote client access solutions using either the Point-to-Point Tunneling Protocol (PPTP) or the Layer Two Tunneling Protocol (L2TP). For more information about tunneling protocols, see VPN tunneling protocols.
Consider, for example, a typical network topology for roaming VPN clients, as illustrated in the figure. This picture shows three networks:
Remote VPN clients that connect to ISA Server can be computers running Microsoft® Windows ServerT 2003, Windows® XP, Windows 2000, Windows NT® 4.0, Windows 98, Windows 95, or Windows Millennium Edition. The client must be able to send TCP/IP packets to the remote access server over the Internet. Therefore, either a network adapter or modem with an analog telephone line or other WAN connection to the Internet is required. For more information, see VPN client computers
To enable remote VPN client access to a network protected by ISA Server, you must perform the following steps:
Identify and configure user accounts allowed to connect to ISA Server as remote VPN clients. Users can be identified as RADIUS users or as Windows users. For more information, see Users for remote VPN client access.
Enable VPN client access on the ISA Server computer. For instructions, see VPN clients and firewall policy.
Select which VPN tunneling protocol to use when connecting to ISA Server: PPTP or L2TP. For more information, see VPN tunneling protocols.
Optionally, enable Quarantine Control. 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. For more information, see VPN and Quarantine.
Note
VPN client computers
Virtual private network (VPN) client computers that connect to ISA Server 2004 can be computers running Microsoft® Windows ServerT 2003, Windows® 2000, Windows XP, Windows NT® 4.0, Windows 98, Windows 95, or Windows Millennium Edition. The client must be able to send TCP/IP packets to the remote access server over the Internet. Either a network adapter, modem with an analog telephone line, or other wide area network (WAN) connection to the Internet is required.
Note
Support for tunneling protocols for Microsoft VPN clients is outlined in the following table. For more information about tunneling protocols, see VPN tunneling protocols
|
VPN client |
Supported tunneling protocols |
Unsupported tunneling protocols |
|
Windows Server 2003 family, Windows 2000, and Windows XP |
Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP) |
None |
|
Windows NT version 4.0 |
PPTP |
L2TP |
|
Windows Millennium Edition and Windows 98 |
PPTP |
L2TP |
|
Windows 95 with the Windows Dial-Up Networking 1.3 Performance and Security Upgrade for Windows 95 |
PPTP |
L2TP |
|
Windows Millennium Edition, Windows 98, Windows NT 4.0 Workstation, and Windows 95 with Microsoft L2TP/IPSec VPN Client installed |
L2TP |
PPTP |
Support for authentication protocols by remote VPN clients is outlined in the following table. For more information about authentication methods, see VPN Authentication
|
Remote VPN Client |
Supported Authentication Methods |
Unsupported Authentication Methods |
|
Windows Server 2003 family, Windows XP, and Windows 2000 |
Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Challenge Handshake Authentication Protocol (CHAP), Shiva Password Authentication Protocol (SPAP), Password Authentication Protocol (PAP), MS-CHAP version 2 (MS-CHAP v2), and Extensible Authentication Protocol (EAP) |
None |
|
Windows NT version 4.0 |
MS-CHAP, CHAP, SPAP, PAP, and MS-CHAP v2 (with the Windows NT 4.0 Service Pack 4 and later) |
EAP |
|
Windows 98 |
MS-CHAP, CHAP, SPAP, PAP, and MS-CHAP v2 (with the Windows 98 Service Pack 1 and later) |
EAP |
|
Windows 95 |
MS-CHAP, CHAP, SPAP, PAP, and MS-CHAP v2 (with the Dial-Up Networking 1.4 Upgrade) |
EAP |
Note
Users for remote VPN client access
You can create users and groups that will be allowed to use the remote virtual private network (VPN) client access feature to connect to ISA Server 2004. You can create VPN users on the domain controller computer. This computer contains the user group and user information that is necessary to authenticate remote users.
Alternatively, you can create VPN users on a RADIUS server. For more information, see RADIUS authentication for remote VPN clients.
In Microsoft® Windows ServerT 2003, the user account contains a set of dial-in properties that are used when allowing or denying a connection attempt made by a user. You can set the dial-in properties on the Dial-in tab in the user account in Local Users and Groups or Active Directory Users and Computers. You must set the Remote Access Permission (Dial-in or VPN) to Allow access or Control access through remote access policy.
For instructions, see Create users and groups for remote VPN clients and Create a dial-in account for the remote site gateway.
RADIUS authentication for remote VPN clients
ISA Server 2004 supports Remote Authentication Dial-In User Service (RADIUS) authentication for virtual private network (VPN) clients. With RADIUS authentication enabled, VPN clients authenticate to a RADIUS server, which provides centralized remote access authentication, authorization, accounting, and auditing.
When you configure ISA Server, select RADIUS authentication as the authentication provider. When you add a RADIUS server, you must configure the following:
For instructions, see Configure RADIUS servers
When you install ISA Server, a default system policy rule allowing RADIUS authentication from the ISA Server computer (Local Host network) to the Internal network is enabled. When this rule is enabled, ISA Server can validate VPN clients using RADIUS authentication. For more information about system policy rules, see System policy overview
If clients are running an operating system other than Windows, and these clients are connecting as remote VPN access clients, you must specify the RADIUS server to use for authentication. Using the ISA Server user mapping feature, you can map users that do not use Windows to Windows accounts. In this way, if you have created any firewall policy rules that apply to user sets, they can also be applied to VPN remote access clients that do not use Windows.
With user mapping enabled, when a RADIUS user presents credentials, the user name and domain are mapped to the same user name and domain, and the user is authenticated as if Windows credentials had been presented.
For instructions, see Enable user mapping.
When you configure the properties of the server running Routing and Remote Access, select RADIUS accounting as the accounting provider.
When you add a RADIUS server, you must configure the following:
For instructions, see Use RADIUS for accounting
User mapping of VPN clients
User mapping is used to map virtual private network (VPN) clients connecting to ISA Server using an authentication method that is not based on Windows (RADIUS or EAP) to the Windows namespace. As a result, firewall policy access rules specifying user sets for Windows users and groups are also applied to authenticated users that do not use Windows. If you do not define user mapping for users from namespaces that are not based on Windows, default firewall policy access rules will not be applied to them.
To define user mapping
In the VPN Client properties, on the User Mapping tab, select the Enable user mapping check box.
If the user name does not include a domain name, select the When user name does not contain a domain name use this domain check box, and then type the domain name in the Domain Name text box.
Note
VPN clients and firewall policy
To allow remote virtual private network (VPN) clients access by using ISA Server 2004, you must enable VPN client access. For instructions, see Enable remote VPN client access. When you enable VPN client access, ISA Server enables the appropriate network and firewall policy rule to allow the initial access.
When remote VPN clients are allowed to connect, ISA Server 2004 makes these clients members of the VPN Clients network. A default system policy rule allows these clients access to the ISA Server computer (Local Host network).
When you enable VPN client access, a system policy rule named Allow VPN client traffic to ISA Server is enabled. Depending which protocols you configured for remote client access, the system policy rule allows the use of Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol (L2TP), or both, from the External network (where the VPN clients are assumed to be located) to the ISA Server computer (Local Host). This rule is modified when you configure these remote VPN client access properties:
A default network rule, created when you install ISA Server, defines a routing relationship between the Internal network and the VPN Clients network. Another default rule, allowing access from the VPN Clients network to the External network, is also created when you install ISA Server. You can create new network rules, to allow traffic from the VPN Clients network to other networks. For more information about network rules, see Network rules.
ISA Server 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.
You do not have to separate the subnet for the VPN Clients network from the Internal network.
To allow remote VPN clients access to resources on the Internal network, you must create an access rule, allowing the appropriate access. 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. For more information about firewall policy, see Firewall policy rules overview.
If you enable and configure quarantine, you must create an access rule for the Quarantined VPN Clients network, allowing appropriate permissions. For more information about quarantine, see VPN and Quarantine.
When ISA Server processes rules to determine if a request from a VPN client is allowed, the VPN credentials are used.
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. For more information about Firewall clients, see Firewall Client.
Similarly, 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. For more information about Web Proxy clients, see Web Proxy clients.
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 (for Firewall clients) and 8080 (for Web Proxy clients).
VPN client computers configured as Firewall clients will present Firewall client credentials (logged on user) for authentication, rather than the VPN session credentials. Access rules based on VPN credentials will take effect.
Firewall clients connected to ISA Server cannot connect to another VPN server. This is because the Firewall Client application sends all traffic-including VPN traffic-by way of ISA Server. Therefore, disable the Firewall client while you connect to the VPN server. Alternatively, include all the addresses in the remote network in the network configured for the Firewall client.
Certificates for L2TP connections
If you enable remote virtual private network (VPN) clients to connect to ISA Server 2004 using the Layer Two Tunneling Protocol (L2TP), you will require a certificate.
You need a certification authority (CA) to issue Internet Protocol security (IPSec) certificates. Because the certificates are for internal use only (to be used on your servers and by your remote VPN clients), it is advisable to create a local CA. This procedure takes place 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 over IPSec requires IPSec certificates to be installed from a CA, you will also need to 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 (ASP) installations.
After you create the certificate, you must install the certificate on the ISA Server computer. Then, the certificate must be installed on the remote VPN client computer.
The directions for creating and installing certificates are detailed in the Digital Certificates for ISA Server and Published Servers scenario documentation, available on the ISA Server Guides and Articles website.
VPN and Quarantine
This section provides information about the quarantine policy features of Internet Security and Acceleration (ISA) Server 2004.
Quarantine Control overview
Quarantine Control provides phased network access for remote clients, also known as virtual private network (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:
You can also choose to disable quarantine mode.
For instructions, see Enable Quarantine Control.
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.
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:
Note
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 click Edit Profile.
On the Advanced tab, remove MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout from the attributes list.
Quarantine Control requirements
This section describes what you need to run ISA Server Quarantine Control.
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 MprAdminConnectionRemoveQuarantine() (https://www.microsoft.com/) application programming interface (API) 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 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 registry of the ISA Server computer. If there is a match, the quarantine conditions are removed from the connection. The ConfigureRQSForISA.vbs script, available on the ISA Server website (https://www.microsoft.com/), helps install RQS (the listener component).
Notes
Routing and Remote Access can be configured with either the Windows or RADIUS authentication provider.
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 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 Quarantine Control works
The following process describes how ISA Server Quarantine Control works when Rqc.exe, Rqs.exe, and ISA Server policy are used:
The user on the quarantine-compatible remote access client uses the installed quarantine Connection Manager (CM) profile to connect with the quarantine-compatible ISA Server computer.
The remote access client passes its authentication credentials to the ISA Server computer.
The ISA Server computer validates the authentication credentials of the remote access client and, assuming that the credentials are valid, checks its remote access policies. The connection attempt matches the quarantine policy.
The connection is accepted with quarantine restrictions, and the client is assigned an IP address and placed in the Quarantined VPN Clients network. At this point, the remote access client can only successfully send traffic that matches the firewall policy for the Quarantined VPN Clients network and has up to the number of seconds specified in the ISA Server quarantine properties to notify the ISA Server computer that the script has run successfully.
The CM profile runs the quarantine script as the post-connect action.
The quarantine script runs and verifies that the remote access client computer's configuration complies with network policy requirements. If all the tests for network policy compliance pass, the script runs Rqc.exe with its command-line parameters, one of which is a text string for the version of the quarantine script included within the CM profile.
Rqc.exe sends a notification to the ISA Server computer, indicating that the script was successfully run. The notification includes the quarantine script version string.
The notification is received by the listener component (Rqs.exe). The notification traffic was allowed because it matched the permitted traffic specified by the firewall policy (in the ISA Server access rule that allows communication on the RQS port 7250 from the VPN Clients and Quarantined VPN Clients networks to the Local Host network).
The listener component verifies the script version string in the notification message with those configured in the registry and sends back either a message indicating that the script version was valid or a message indicating that the script version was invalid.
If the script version was valid, the listener component calls the MprAdminConnectionRemoveQuarantine() API, which causes ISA Server to move the client from the Quarantined VPN Clients network to the VPN Clients network.
The listener component creates an event detailing the quarantined connection in the system event log.
Quarantine Control configuration steps
This section provides information about configuring ISA Server Quarantine Control. Before you enable quarantine mode, you must complete the following steps:
Create a client-side script that validates client configuration information.
Create
a notification component that provides verification to the ISA Server computer
that the script has successfully run. If you do not want to create a
notification component, you can use Rqc.exe.
The notifier component is included in the Connection Manager (CM) profile and
installed on the client computer. The notifier component sends notification to
the ISA Server computer when the administrator-provided script has run
successfully on the client.
Create a listener component to install on ISA Server computers (that can receive information from the notification component), and then remove the client from quarantine mode, applying the full access policy. If you do not want to create a listener component, you can use the Rqs.exe sample. The listener component is installed on the ISA Server computer, and receives notification from the notifier component that the script on the client has successfully performed all configuration checks. After the listener component receives notification, it removes the client from quarantine mode, and the ISA Server computer applies standard firewall policy rules to the client.
If you are using the Rqs.exe sample, run the script ConfigureRQSForISA.vbs, available on the ISA Server website (https://www.microsoft.com/). The script performs the following actions:
a. Installs RQS as a service and sets it to run in the local system account.
b. Creates an ISA Server access rule that allows communication on the RQS port (7250) from the VPN Clients and Quarantined VPN Clients networks to the Local Host network. This is necessary so that the ISA Server computer can receive notice that the client has met the connection requirements.
c. Modifies registry keys on the ISA Server computer so that RQS will work with ISA Server.
d. Starts the RQS service.
The script
has one switch (install or remove) and requires two parameters: the set of
allowed RQS shared keys, and the path to RQS.exe.
A shared key is required by the RQS service from RQC.exe before the VPN client
can leave the Quarantined VPN Clients network. If the client provides a shared
key that is not in the allowed set, it will be disconnected. There can be more
than one shared key, separated by "\0" when providing arguments to
the ConfigureRQSForISA.vbs script, available on the ISA Server website (https://www.microsoft.com/).
Note
o The ConfigureRQSForISA.vbs script requires that the files Reg.exe and Sc.exe be in the system path. In Microsoft® Windows ServerT 2003, these files are present by default in %windir%\system32. In Windows® 2000 Server, you must install the files to the system path before running ConfigureRQSForISA.vbs. You can obtain Reg.exe from the Windows 2000 CD under support\tools. Sc.exe is part of the Microsoft Windows 2000 Resource Kit, which you can download from the Free Tool Downloads website. (https://www.microsoft.com/)
Create a CM profile with the Connection Manager Administration Kit (CMAK). For more information about CMAK, see Connection Manager Administration Kit in Windows Server 2003 Help (https://www.microsoft.com/).
Distribute the CM profile for installation on remote access client computers.
You can create your own notifier and listener components, or you can use Rqs.exe (a listener component) and Rqc.exe (a notifier component). For more information, see Windows Resource Kit Tools Help. 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.
After you complete the preliminary steps for setting up quarantine, you can configure the quarantine settings on the ISA Server computer. After you enable quarantine mode, you can configure the Quarantined VPN Clients network properties, selecting one of the following:
Even with quarantine enabled, you can exempt specific users from quarantine control.
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 more information about firewall policy, see Firewall policy rules overview.
The following are some examples of the types of access you may want to allow to 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.
Note
Site-to-Site VPN
This section provides information about the features of Internet Security and Acceleration (ISA) Server 2004 for a site-to-site virtual private network (VPN).
Site-to-site VPN overview
A large corporation often has multiple sites that
require communication, for example, a corporate office in
ISA Server 2004 provides three VPN protocols for site-to-site connections:
For more information about VPN tunneling protocols, see VPN tunneling protocols.
The process of configuring remote VPN networks differs, depending on the tunneling protocol you select. For all remote site networks, you must configure the network, set up a network and firewall policy for the remote network, and configure the remote site gateway (VPN server).
In addition, for IPSec networks, you can further configure the security settings on the ISA Server computer. You must also configure the IPSec policy settings on the remote site gateway.
For more information about configuring L2TP over IPSec and PPTP remote networks, see L2TP over IPSec and PPTP networks. For more information about configuring IPSec remote networks, see IPSec tunneling protocol network.
L2TP over IPSec and PPTP networks
ISA Server 2004 supports a site-to-site virtual private network (VPN) using Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP) over Internet Protocol security (IPSec). For example, you can use these tunneling protocols if you are using ISA Server 2004 as your VPN server, and the site you are connecting to is using Microsoft® Windows ServerT 2003, Windows® 2000 Server, ISA Server 2004, or ISA Server 2000 as a VPN server. ISA Server 2004 uses Routing and Remote Access to establish the L2TP over IPSec VPN connection.
The figure illustrates a possible network topology for the L2TP over IPSec solution.
Setting up remote networks using PPTP or L2TP over IPSec involves these general steps:
Create a remote site network, selecting PPTP or L2TP over IPSec as the tunneling protocol. For instructions, see Add a remote site network.
Select PPTP or L2TP over IPSec as the tunneling protocol. For instructions, see Configure tunneling protocol for a remote site network.
Configure ISA Server network rules and access policy. For more information, see Site-to-site VPN and firewall policy.
Configure the general VPN properties for connections initiated by remote VPN sites, because ISA Server views those sites as VPN clients. For more information, see Site-to-site VPN connections.
Configure automatic dialing, if your ISA Server computer is connected to the Internet through a dial-up connection. For instructions, see Configure automatic dialing.
Configure the remote VPN server.
IPSec tunneling protocol network
ISA Server 2004 supports a site-to-site virtual private network (VPN) using the Internet Protocol security (IPSec) tunneling protocol. For example, you can use IPSec tunneling protocol if you are using ISA Server 2004 as your VPN server, and the site you are connecting to is using a third-party product or ISA Server 2004 as its VPN server. The figure shows 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 Microsoft® Windows ServerT 2003 or Windows® 2000 Server.
The branch office may be running one of several third-party VPN servers. Alternatively, the branch may be using ISA Server 2004, Windows Server 2003 or Windows 2000 Server as its VPN server.
Setting up remote networks using IPSec involves these general steps:
Create a remote site network. Select IPSec as the tunneling protocol. For instructions, see Add a remote site network.
Configure ISA Server network rules and access policy. For more information, see Site-to-site VPN and firewall policy.
Configure automatic dialing, if your ISA Server computer is connected to the Internet through a dial-up connection. For instructions, see Configure automatic dialing.
Configure the remote VPN server. The remote VPN server must be configured to connect to the ISA Server computer in IPSec tunnel mode, according to manufacturer instructions. ISA Server provides a summary of the information needed to configure the remote server. For instructions on viewing the summary information, see View IPSec policy.
Configure advanced IPSec settings. For instructions, see Configure advanced IPSec settings for Phase I and Configure advanced IPSec settings for Phase II.
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 (https://www.microsoft.com/). The tool must be installed to the ISA Server installation folder.
When you create a remote site network that uses the IPSec tunneling protocol, the Microsoft Firewall service modifies the IPSec filters on the computer, when restarting the Firewall service. This process can take up to several minutes, depending on the number of subnets included in the address ranges for the network. To minimize the effect, we recommend that you define IP address ranges that are aligned in subnet boundaries.
If you stop or restart the IPSec PolicyAgent service, all dynamic IPSec configuration information is lost, including ISA Server VPN site-to-site IPSec configuration settings, and the clients are disconnected. Furthermore, when the PolicyAgent service is stopped, and the IPSec policy is erased, all traffic from the clients is forwarded to the Internet, unencrypted.
To restore settings, start the PolicyAgent service and restart the Firewall service. Alternatively, reboot the computer.
Typically, the ISA Server computer is not a member of a domain. In this case, a local IPSec policy can be used. However, if ISA Server is a member of a domain that has IPSec policy applied to all its members, the local IPSec policies are overwritten by the domain IPSec policies. Work with the domain administrator to ensure that the domain IPSec policy does not conflict with the IPSec policy configured for the remote site network. To view the remote site network's IPSec policy:
For IPSec remote site networks, when using a non-primary IP address as the local endpoint, the following is not supported:
When connecting multiple IPSEC remote site networks to the same ISA Server computer running Windows Server 2003, we recommend that you define unique IP addresses for each remote site network's local endpoint.
If multiple IPSec remote site networks require NAT/HTTP functionality (from the Internal network to the remote site network), we recommend that you use a dedicated network adapter for each remote site network (using the primary IP address on the network adapter as the local endpoint). To identify the primary IP address:
Select the relevant network adapter and then right-click Properties.
Click TCP-IP protocol and then click Properties.
Site-to-site VPN and firewall policy
When you configure a site-to-site virtual private network (VPN) in ISA Server, you are establishing a new network: the remote site, recognized by the ISA Server computer as a remote VPN. Remote site networks should include all the addresses on the remote site. For instructions on creating remote site networks, see Add a remote site network.
When you create a remote network, the VPN site-to-site connection is enabled. ISA Server enables system policy rules, allowing access from all External networks to the ISA Server computer (Local Host network), using the VPN tunneling protocols. This rule is modified if you modify the VPN access network, which is initially set to the External network. You can specify one or more networks from which VPN clients can connect to ISA Server. When you modify this, the system policy rule is changed automatically to apply to the additional or changed networks. For more information on system policy rules, see System policy overview.
The default system policy rules also allow access from a computer set named IPSec Remote Gateways. IPSec Remote Gateways is a predefined computer set, which cannot be modified. When an IPSec site-to-site network is added, the IP address configured as the remote tunnel endpoint is added to the IPSec Remote Gateways computer set.
To allow remote networks access to resources on the Internal network, you must create an access rule, allowing the appropriate access. If you consider the remote 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 remote network. For more information about firewall policy, see Firewall policy rules overview.
Site-to-site VPN connections
In a site-to-site network, virtual private network (VPN) connections can be initiated either by ISA Server 2004 or by the remote site gateway.
ISA Server considers a remote site gateway that uses Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) as any remote access client. For this reason, the remote site gateway must:
You can also configure whether connections initiated by the remote site should be terminated after a specific amount of time. For instructions, see Terminate inactive VPN connections automatically
For each remote site network that uses PPTP or L2TP, you can configure whether ISA Server can also initiate VPN connections. If ISA Server can initiate connections, you must configure appropriate credentials, which will be used to authenticate to the remote site gateway.
You can also configure the authentication methods used when ISA Server initiates connections to the remote site gateway. The authentication protocol that you configure should be the protocol required by the remote site gateway. For example, if the remote site gateway uses IPSec, you should configure authentication using either certificates or a preshared key. For instructions, see Configure VPN authentication methods for site-to-site connections initiated by ISA Server.
Dial-in accounts for remote site connections
When creating a site-to-site network for remote access, you must also create a user account for initiating the remote access dial-up connection. For the connection to succeed:
This information applies to site-to-site connections using Layer Two Tunneling Protocol (L2TP) or Point-to-Point Tunneling Protocol (PPTP). It does not apply to connections using Internet Protocol security (IPSec).
For instructions, see Create a dial-in account for the remote site gateway.
Common VPN Configuration
This section provides information about the features of Internet Security and Acceleration (ISA) Server 2004 for common virtual private network (VPN) configuration.
VPN access network
For virtual private network (VPN) client connections, networks from which clients can connect to the ISA Server 2004 computer with VPN enabled are called access networks.
For site-to-site (remote) connections, an access network is a network where the remote VPN server is located.
By default, for both site-to-site connections and for client connections, the VPN access network is set only to the External network. Therefore, when you enable VPN access, VPN connections can be established for computers on the External network.
For instructions, see Configure VPN access networks.
When you first enable VPN client access on ISA Server, a system policy rule called Allow VPN client traffic to ISA Server is enabled. This allows access from the External network to the Local Host, because the External network is configured by default as an access network. You can subsequently configure additional access networks, by specifying additional VPN access networks. The system policy rule is automatically updated to apply to the additional access networks.
For site-to-site access, when you create a new remote site network, ISA Server adds the remote network to the list of networks included in the Protected Networks network set. In addition, ISA Server enables these system policy rules:
VPN tunneling protocols
ISA Server 2004 supports two virtual private network (VPN) protocols for remote client access connections:
In addition, for site-to-site VPN connections, Internet Protocol security (IPSec) tunnel mode is supported.
For instructions on configuring protocols for remote client access, see Configure tunneling protocols for remote client access.
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.
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 over IPSec connections require the same user-level authentication and, in addition, computer-level authentication using computer certificates.
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 tunnel's beginning point and the tunnel's endpoint. When tunneling is combined with data confidentiality, it can be used to provide a VPN.
The encapsulated packets travel through the network inside the tunnel. In this example, the network is the Internet. The gateway might be an edge gateway that stands between the outside Internet and the private network. The edge gateway can be a router, firewall, proxy server, or other security gateway. Also, two gateways can be used inside the private network to protect traffic across untrusted parts of the network.
When IPSec is used in tunnel mode, it 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.
Note
The following table compares the VPN protocols.
|
Protocol |
When to use |
Security level |
Comments |
|
IPSec tunnel mode |
Connecting to third-party VPN server |
High |
This is the only option you can use if you are connecting to a non-Microsoft VPN server. |
|
L2TP over IPSec |
Connecting to an ISA Server 2004 computer, ISA Server 2000 computer, or Windows VPN server |
High |
Uses Routing and Remote Access. Less complicated than the IPSec tunnel solution, but requires that the remote VPN server be an ISA Server computer or a Windows VPN server. |
|
PPTP |
Connecting to an ISA Server 2004 computer, ISA Server 2000 computer, or Windows VPN server |
Moderate |
Uses Routing and Remote Access. Same restrictions as L2TP, but slightly easier to configure. L2TP is considered more secure because it uses IPSec encryption. |
VPN Authentication
The authentication of virtual private network (VPN) clients is an important security concern. Authentication methods typically use an authentication protocol that is negotiated during the connection establishment process. This section describes the authentication methods supported by ISA Server 2004:
When a remote site gateway initiates a connection with ISA Server, it is initially authenticated as any remote VPN client. The authentication methods that you apply for remote VPN clients also apply for the remote site gateway. For more information about how the remote site gateway connects to ISA Server, see VPN site-to-site connections
You can configure ISA Server to allow the ISA Server computer to initiate connections to the remote site gateway. In this case, you must also configure the authentication methods to be used. For instructions, see Configure VPN authentication methods for site-to-site connections initiated by ISA Server
EAP authentication method
With the Extensible Authentication Protocol (EAP), an arbitrary authentication mechanism authenticates a remote access connection. The exact authentication scheme to be used is negotiated by the remote VPN client and the authenticator (either ISA Server or the RADIUS server). ISA Server includes support for Message Digest 5 Challenge (MD5-Challenge) and EAP-Transport Level Security (EAP-TLS) by default.
EAP allows for an open-ended conversation between the remote VPN client and the authenticator. The conversation consists of authenticator requests for authentication information and the responses by the remote VPN client. For example, when EAP is used with security token cards, the authenticator can separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the remote access client passes through another level of authentication. When all questions have been answered satisfactorily, the remote access client is authenticated.
A specific EAP authentication scheme is known as an EAP type. Both the remote access client and the authenticator must support the same EAP type for successful authentication to occur.
For instructions on configuring authentication methods, see Configure VPN authentication methods.
EAP is a set of internal components that provide architectural support for any EAP type in the form of a plug-in module. For successful authentication, both the remote access client and authenticator must have the same EAP authentication module installed. ISA Server supports two EAP types: MD5-Challenge and EAP-TLS.
Message Digest 5 Challenge (MD5-Challenge) is a required EAP type that uses the same challenge/handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. A typical use for MD5-Challenge is to authenticate the credentials of remote VPN clients by using user name and password security systems. You can also use MD5-Challenge to test EAP interoperability.
EAP-Transport Level Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between the remote VPN client and the authenticator. EAP-TLS provides the strongest authentication and key determination method.
EAP-RADIUS is not an EAP type, but the passing of EAP messages of any EAP type by an authenticator to a RADIUS server for authentication. For example, when ISA Server is configured for RADIUS authentication, the EAP messages sent between the remote VPN client and ISA Server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server.
EAP-RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server. In the case of Internet Authentication Service (IAS), you only need to install EAP types on the IAS server.
For more information about RADIUS authentication, see RADIUS authentication for remote VPN clients.
EAP authentication configuration
If you create a virtual private network (VPN) remote site network that uses a Point-to-Point Tunneling Protocol (PPTP) connection, and select Extensible Authentication Protocol (EAP) as its authentication protocol, you must complete the EAP configuration. EAP configuration is done using Routing and Remote Access.
To complete the EAP configuration, do the following:
In Routing and Remote Access Management console, select the Network Interfaces node.
When you applied the changes to the ISA Server configuration, a demand dial interface with the same name you gave the network was created. Select this demand dial interface, and then click Properties.
On the Security tab, the advanced custom settings option should be selected. Click Settings to open Advanced Security Settings.
Select the EAP you will be using, and then click Properties to configure the EAP according to your EAP provider.
Note
MS-CHAP authentication method
ISA Server 2004 supports the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), also known as MS-CHAP version 1. MS-CHAP is a nonreversible, encrypted password authentication protocol. The challenge handshake process works as follows:
The authenticator, which is the remote access server or the Internet Authentication Service (IAS) server, sends a challenge to the remote access client that consists of a session identifier and an arbitrary challenge string.
The remote access client sends a response that contains the user name and a nonreversible encryption of the challenge string, the session identifier, and the password.
The authenticator checks the response and, if valid, the user's credentials are authenticated.
If you use MS-CHAP as the authentication protocol, you can use Microsoft Point-to-Point Encryption (MPPE) to encrypt the data sent on the PPP or PPTP connection.
ISA Server also supports MS-CHAP version 2. MS-CHAP version 2 provides stronger security for remote access connections than MS-CHAP. You should consider using MS-CHAP version 2 instead of MS-CHAP.
Notes
For instructions on setting authentication methods, see Configure VPN authentication methods
ISA Server supports version 2 of the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2), which provides stronger security for remote access connections.
MS-CHAP v2 is a one-way encrypted password, mutual authentication process that works as follows:
The authenticator, which is the remote access server or the Internet Authentication Service (IAS) server, sends a challenge to the remote access client that consists of a session identifier and an arbitrary challenge string.
The remote access client sends a response that contains:
o The user name.
o An arbitrary peer challenge string.
o A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user's password.
The authenticator checks the response from the client and sends back a response that contains:
o An indication of the success or failure of the connection attempt.
o An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user's password.
The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.
CHAP, SPAP, and PAP authentication methods
ISA Server 2004 supports the Challenge Handshake Authentication Protocol (CHAP), Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol (PAP).
The Challenge Handshake Authentication Protocol (CHAP) is a challenge/response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response. CHAP is used by various vendors of network access servers and clients. A server running Routing and Remote Access supports CHAP so that remote access clients that require CHAP are authenticated. Because CHAP requires the use of a reversibly encrypted password, you should consider using another authentication protocol such as Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2.
Notes
For instructions on setting authentication methods, see Configure VPN authentication methods
The Shiva Password Authentication Protocol (SPAP) is a reversible encryption mechanism employed by Shiva. When a computer running Windows XP Professional connects to a Shiva LAN Rover, it uses SPAP, as does a Shiva client that connects to a server running Routing and Remote Access. This form of authentication is more secure than plaintext but less secure than CHAP or MS-CHAP.
Important
Notes
Password Authentication Protocol (PAP) uses plaintext passwords and is the least secure authentication protocol. It is typically negotiated if the remote access client and remote access server cannot negotiate a more secure form of validation.
To enable PAP-based authentication, you must do the following:
Enable PAP as an authentication protocol on the remote access server. PAP is disabled by default.
Enable PAP on the appropriate remote access policy. PAP is disabled by default.
Enable PAP on the remote access client.
Notes
Preshared keys (custom IPSec policy for L2TP connections)
A preshared key is a string of Unicode characters used to authenticate Layer Two Tunneling Protocol (L2TP) over Internet Protocol security (IPSec) connections. The use of preshared keys is supported on many operating systems, including the Microsoft® Windows ServerT 2003 family and Windows® XP. You can also configure ISA Server to use a preshared key to authenticate connections from other routers.
For instructions, see Configure a preshared key for VPN connections.
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 L2TP over IPSec authentication. Preshared keys are simple to configure on a remote access server, and they are relatively simple to configure on a remote access client. They can be made transparent to the user if they are issued within Connection Manager profiles. If you are in the process of establishing a PKI or if you manage an Active Directory domain, you can configure Routing and Remote Access to accept an L2TP over IPSec connection using a computer certificate or a preshared key.
However, a single remote access server can utilize only one preshared key for all L2TP over IPSec connections that require a preshared key for authentication. You must issue the same preshared key to all L2TP over IPSec VPN clients that connect to the remote access server using a preshared key. Unless you distribute the preshared key within a Connection Manager profile, each user must manually type the preshared key. This limitation further reduces the security of the deployment and increases the probability of error. If the preshared key on a remote access server is changed, a client with a manually configured preshared key will be unable to connect to that server until the preshared key on the client is changed. If the preshared key was distributed to the client within a Connection Manager profile, that profile must be reissued with the new preshared key and reinstalled on the client computer. Unlike certificates, the origin and the history of a preshared key cannot be determined. For these reasons, the use of preshared keys to authenticate L2TP over IPSec connections is considered a relatively weak authentication method. If you want a long term, strong authentication method, you should consider using a PKI.
A preshared key is a sequence of characters that is configured on both the remote access server and the L2TP over IPSec client. The preshared key can be any non-null string of any combination of up to 256 Unicode characters. When you choose a preshared key, consider the fact that users who utilize the New Connection Wizard to create the VPN client connection must type the preshared key manually. A key that is long and complex enough to provide adequate security might be difficult for the majority of your users to type accurately. If the preshared key presented by the VPN client deviates in any way from the preshared key configured on the remote access server, client authentication will fail.
Note
When the preshared key is first stored, the remote access server and the VPN client attempt to convert the Unicode string into ASCII. If the attempt is successful, the ASCII version of the string will be used for authentication. This strategy ensures that the preshared key is not corrupted in transmission by any devices that do not comply with the Unicode standard, such as routers from other companies. If the preshared key cannot be stored as ASCII, the Unicode string will be used. If the Unicode preshared key must be processed by any device that does not comply with the Unicode standard, the connection attempt will probably fail.
VPN client address assignment and name resolution
When you configure ISA Server 2004 to allow a virtual private network (VPN), you must configure how remote clients will be assigned addresses: dynamically or statically. When a VPN client is assigned an address, the address becomes part of the VPN Clients network.
For instructions on setting authentication methods, see Configure VPN address assignment.
Note
If the remote clients are assigned addresses dynamically, you will require a DHCP server. The 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.
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 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 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.
When you use dynamic address assignment, the address that the VPN client is assigned is actually an address from the Internal network. When the VPN client establishes a connection, its address is dynamically moved from the Internal network to the VPN Clients network. When the client subsequently disconnects, the address is returned to the Internal network. These shifts in IP address membership are not visible in ISA Server Management.
Note
Alternatively, you can provide the IP addresses from a static pool of addresses. For example, this approach can be used when your Internal network IP addresses are statically assigned.
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 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.)
You can enable broadcast name resolution for VPN connections to ISA Server, specifying which DNS server or which WINS server the client will use to resolve computer names. In this case, a remote access client can resolve full computer names, NetBIOS names of computers, and other resources on a remote network that does not have either a DNS or a WINS server configured.
VPN connection monitoring
You can monitor virtual private network (VPN) sessions, filtering the Sessions view to show only the VPN connections. To monitor VPN clients, configure the filter so that Session Type is set to VPN client. To monitor connections from a remote site network, configure the filter on the Sessions view so that the Source Network is set to VPN Site-to-Site
ISA Server 2004 supports the following types of logging for VPN connections:
|
