لطفا منتظر باشید ...
Lesson 2 Troubleshooting Strategies in ISA Server
Successful troubleshooting requires a systematic approach. When you experience unexpected behavior in ISA Server, you can begin troubleshooting by determining whether the error is user-based or packet-based. The following lesson offers strategies for troubleshooting both types of connection problems.
After this lesson, you will be able to
Troubleshoot user-based access problems
Troubleshoot packet-based access problems
Troubleshoot VPN connections in ISA Server
Estimated lesson time: 30 minutes
Troubleshooting User Access
When user account access is intermittent or unavailable, the problem could be caused by overly restrictive user security, improperly configured rules, or inadequate authentication methods. Tools such as Ping and Tracert may function properly even in these conditions.
To troubleshoot user-based access problems, first check access policy rules. Make sure that users unable to establish a network connection have been granted proper permissions to connect to the site(s), content group(s), and protocol(s) in question through configured access policy rules.
If you have configured rules that are not being successfully applied to user sessions, verify that your array properties are configured to ask unauthenticated users for identification. Note also that if you create an allow-type access policy rule that is applied to specific users and groups, user sessions will be forced to authenticate with the ISA Server. On the other hand, if access is being denied to Web sessions when you want all Web sessions to remain anonymous, make sure that the array properties do not force anonymous users to authenticate themselves. In addition, delete any allow-type site and content rules or protocol rules that are applied to specific Windows 2000 users or groups.
Authentication
Your choice of authentication method for an ISA Server array can affect the users' ability to connect. Each authentication method is designed to accommodate specific network environments. If an incompatible authentication method is chosen for a network configuration, or if an authentication method is improperly configured, users will be denied access to the ISA Server computer and the network.
For example, the default authentication mode on an array is Integrated Windows authentication, but this authentication method cannot authenticate clients not running Windows operating systems. If you need to provide authenticated access for such clients in ISA Server, you must configure the array properties to use another authentication method. Similarly, Integrated Windows authentication is incompatible with Netscape browsers because Netscape cannot pass user credentials in NTLM format. Another limitation of Integrated Windows authentication in Windows 2000 is that can rely on the Kerberos V5 authentication protocol or its own challenge/response authentication protocol. However, in a pass-through authentication scenario, as shown in Figure 10.3, ISA Server does not support Kerberos V5 authentication because Kerberos V5 requires that the client be able to identify the authenticating server.
Figure 10.3 Pass-through authentication is not compatible with Kerberos V5
The alternative authentication methods available in ISA Server include Basic, Digest, and Client Certificate. Basic authentication is compatible with all client types. However, because when this method is used user names and passwords are sent over the network in clear, unencrypted format, it is not a sufficient method of security by itself. Digest authentication can be used only in Windows 2000 domains. With this method passwords are sent in clear but encrypted text. Client Certificate authentication uses an Secure Sockets Layer (SSL) channel for authentication and requires that the a client certificate be installed in the Microsoft Web Proxy Service certificate store on the ISA Server computer and that the certificate be mapped to the appropriate user account. ISA Server can present client certificates only in SSL bridging configurations.
Troubleshooting Packet-Based Access Problems
Access problems can be determined to be packet-based when network access fails for all users, or when IP-based utilities such as Ping or Tracert fail.
To troubleshoot packet-based access problems in ISA Server, begin by simplifying the network configuration as much as possible to create a testing environment.
To set up a network troubleshooting configuration
With packet filtering enabled, create a custom packet filter to allow any IP protocol to transmit in both directions.
Create a protocol rule to allow all IP traffic for any request, and ensure that you have a site and content rule allowing access to all sites and content groups.
Return all application filters and routing rules to default settings.
Verify that you have defined the local address table (LAT) as the range of internal ISA Server clients.
Enable IP Routing in the IP Packet Filters Properties dialog box. The IP Routing option provides routing capabilities to protocols with secondary connections. This setting is especially important for perimeter network configurations. You can enable the IP Routing option either in the IP Packet Filters Properties dialog box in ISA Management or in the Routing and Remote Access console.
On the ISA Server computer, make sure that no default gateway is defined for the internal interface. However, make sure that a proper default gateway is specified on the external interface.
On the client computers for which you are trying to establish access, disable the Firewall Client software and assign the ISA Server computer as the default gateway.
Once you have configured ISA Server in this simplified way, restart the ISA Server services. If you still cannot gain access, reboot the ISA Server computer. If this does not fix the problem, the network problem may not be related to your ISA Server configuration. In this case, you should perform network troubleshooting as you would with any network, performing Network Monitor traces and reviewing Domain Name System (DNS), routing tables, alerts, reports, and logs as appropriate.
If you can establish Internet access with the simplified testing configuration, you can then reintroduce network elements one by one to determine the cause of the problem. For example, if you can establish Internet access from a given client computer, you can attempt to use specific Internet applications from that computer. If you encounter problems, you can assume that either the application has been improperly configured to use ISA Server as a proxy or that the application is not designed to use a proxy server. For applications that are not able to use a proxy server, you must configure the client for SecureNAT or run the Firewall Client software. After reconfiguring the client, note any changes in behavior. If you use the Firewall Client software and access fails when you enable automatic discovery, you can assume that automatic discovery is improperly configured. Proceed incrementally, fixing problems as they arise, until you have added all the network components required for your particular configuration.
VPN Network Considerations
In VPN Networks, begin troubleshooting by creating the simplified network configuration as outlined above. If you have already run the VPN wizards, you should verify first that the Routing and Remote Access service has been started. Next, make sure that you have configured the client as a secure network address translation (SecureNAT) client and not a Firewall client.
You should also verify that the Local ISA Server VPN Configuration wizard has created the appropriate demand-dial interfaces in Routing and Remote Access. This can be checked in the Routing Interfaces node, as shown in Figure 10.4.
Figure 10.4 Demand-dial interfaces in Routing and Remote Access
After this, verify that two IP packet filters have been created for each authentication protocol you have chosen for your VPN connection. For example, if you have configured your VPN to use either L2TP or PPTP, the Local ISA Server VPN Configuration wizard should have created and enabled four IP packet filters. (For L2TP, the wizard creates custom filters for ports 500 and 1701, and for PPTP, the wizard creates predefined filters for PPTP Call and PPTP Receive.)
If the appropriate interfaces and IP packet filters have been created, and if rebooting the computer does not help, it is recommended that you delete the IP packet filters created by the VPN wizards, disable Routing and Remote Access, and run the wizards again.
Additional Troubleshooting Notes
When you are troubleshooting errors in ISA Server, you can begin by consulting the following tables. The following tables summarize common problems and solutions relating to various aspects and functions of ISA Server.
Table 10.1 Troubleshooting Access Policy
| Problem | Possible Cause(s) | Possible Solution(s) |
|---|---|---|
| Clients cannot browse external Web sites. | Initially, ISA Server does not allow any communication to or from the Internet. You can create rules that will allow communication in a manner consistent with your corporate security policy. | Create protocol rules to allow specific users to use the protocols. Then create site and content rules that allow users access to particular sites, using the protocols specified by the protocol rules.Check the browser settings of the client to ensure that the proxy port is specified correctly. The default port for ISA Server is 8080. |
| Clients receive a 502 error every time they try to browse the Web. | Initially, ISA Server does not allow any communication to or from the Internet. You can create IP packet filters or rules that will allow communication in a manner consistent with corporate security policy.Some access policy rules require authentication, but no authentication methods were configured for the listener. | Create protocol rules to allow specific users to use the protocols. Then create site and content rules that allow users access to particular sites, using the protocols specified by the protocol rules.Select an authentication method for the listener. Clients will be allowed access, in accordance with configured rules, if they can authenticate using the method. |
| Clients cannot use specific protocol, such as HTTP, RealAudio, or others. | Initially, ISA Server does not allow any communication to and from the Internet. You can configure IP packet filters or rules that will allow use of particular protocols. | Create protocol rules to allow users to communicate using the specified protocols. Also check to see whether a particular protocol is not blocked by a disabled application filter. |
| After disabling a protocol rule, clients can still use the specified protocol that is allowed by the rule. | Existing client sessions are not terminated when you disable a protocol rule, although new sessions will not be opened. For example, if a client is using a RealAudio protocol, in accordance with configured rules, the session will continue even after you disable the protocol rule allowing the access. | Disconnect the client sessions. |
| Clients cannot use a specific protocol definition, although a protocol rule has been configured to allow access. | If you disable an application filter, all traffic that uses the protocol definition is blocked, even if protocol rules seem to allow the traffic. | Enable the application filter. Create a protocol rule that allows access to the specific clients. |
Table 10.2 Troubleshooting Authentication
| Problem | Possible Cause(s) | Possible Solution(s) |
|---|---|---|
| ISA Server failed to authenticate a Netscape user. | ISA Server may have been configured only to accept Windows integrated authentication. Netscape browsers cannot pass user credentials in NT LAN Manager (NTLM) format. | You can configure ISA Server to require other authentication methods, including Basic or Digest. |
Table 10.3 Troubleshooting Caching
| Problem | Possible Cause(s) | Possible Solution(s) |
|---|---|---|
| Not all traffic is saved to the ISA Server cache. | ISA Server caches only items that meet the caching criteria. | When clients access objects that can be cached, network performance seems to improve, as the objects are retrieved from the ISA Server cache rather than from the network. However, if your clients are commonly accessing objects that are not cached, you may not perceive improved performance. |
| The Web Proxy service will not start. | The cache contents file is corrupted. | If the cache contents file becomes corrupted for whatever reason, the Web Proxy service will not be able to start. To overcome this problem, reconfigure the drives allocated for caching. |
Table 10.4 Troubleshooting Logging
| Problem | Possible Cause(s) | Possible Solution(s) |
|---|---|---|
| The client authentication (user names) information cannot be found in the log file. | ISA Server does not always require that clients authenticate themselves. If clients are not authenticated, they are granted anonymous access and their authentication information is not logged. | You can configure ISA Server to always require that Web Proxy clients authenticate themselves, by configuring the incoming and outgoing Web request properties. |
Table 10.5 Troubleshooting Publishing
| Problem | Possible Cause(s) | Possible Solution(s) |
|---|---|---|
| Clients receive a 403 error every time they try to access the published Web server. | Some access policy rule requires authentication, but no authentication methods were configured for the listener | Select an authentication method for the listener. Clients will be allowed access, in accordance with configured rules, if they can authenticate using the particular method chosen. |
| External clients cannot send mail via the computer running Microsoft Exchange Server that is set up as a Firewall client behind the ISA Server computer. | There is a port conflict between a server publishing rule and a Firewall client configuration file. | If you published a mail server in a Microsoft Proxy Server 2.0 environment, you had to configure the mail server as a Winsock Proxy client. In this case, you created a Wspclnt.ini file on the mail server. With ISA Server, publishing servers do not require special configuration, since they are published as SecureNAT clients. Remove the Wspclnt.ini file from the publishing server. Then, in ISA Management, run the Mail Server Security wizard. |
| The Microsoft Exchange Server may be unable to bind to the SMTP port on the ISA Server computer. | Be sure that there is no other local service or application running on the ISA Server computer that is binding to port 25 before the Exchange Server. | |
| The Exchange Server loses its connection to the ISA Server computer. | If the connection between the ISA Server computer and the Exchange Server was temporarily disrupted, you must restart the Exchange services so that it will bind to the necessary ports on the ISA Server computer. | |
| External clients cannot send mail via the Exchange Server, which is set up as a SecureNAT client, behind the ISA Server computer. | The server publishing rules may not be configured correctly. | Check that the server publishing rules are configured so that the external interface passes all traffic on port 25 for SMTP traffic and port 110 for Post Office Protocol 3 traffic to the correct IP address and port on the internal Exchange Server. |
Table 10.6 Troubleshooting Services
| Problem | Possible Cause(s) | Possible Solution(s) |
|---|---|---|
| Services did not start after installation completed successfully. | If the LAT was configured incorrectly and does not include the internal network adapter that communicates with Active Directory, the ISA Server services cannot start. | Perform the following steps to add the appropriate entries to the LAT: 1. Stop ISA Server services and packet filtering. To do this, at a command prompt, type net stop mspfltext. 2. Reconfigure the LAT. Since you cannot run ISA Management, you will have to configure the LAT using the ISA Server Administration COM objects. For more information on how to do this, see "Constructing the Local Address Table" in the ISA Server Software DevelopmentKit. 3. Reboot the computer. |
Lesson Summary
A good way to begin troubleshooting an access problem in ISA Server is to determine whether the problem is user-based or packet-based. Access problems can be distinguished as user-based when connection ability varies among users, or when network resources are accessible from IP utilities such as Ping or Tracert but not through all user accounts. Access problems can be distinguished as packet-based when network access does not vary among users, or when you are unable to connect to a network resource using an IP utility.
To troubleshoot user-based access problems, you should check access policy rules to make sure that the proper users have been granted access to the proper sites, content groups, and protocols. In addition, if you want access policy rules configured for specific users and groups to apply to Web sessions, you should verify that your array properties have been configured to require authentication for outgoing Web requests. Finally, you should make sure that an authentication method has been properly configured for your array.
To troubleshoot packet-based access problems in ISA Server, begin by simplifying the network configuration as much as possible and then performing the access test. If you are still experiencing a network problem in a simplified test environment, the network problem might not be related to your ISA Server configuration. If it is unrelated to ISA Server, proceed to troubleshoot the configuration as you would with any network access problem. If you can establish Internet access with the simplified testing configuration, you can then reintroduce the elements of your network one by one until you can determine the cause of the problem. Additional troubleshooting considerations for VPN connections include verifying that VPN clients are configured as Secure NAT clients, that Routing And Remote Access is started, that the proper demand-dial interfaces are created for the VPN, and that two IP packet filters are enabled for each authentication protocol selected for the VPN.
