ISA Server troubleshooting Policy (1)

ISA Server troubleshooting Policy
10.2 ISA Server troubleshooting Policy
System methods are essential for successful troubleshooting. In the event of an unexpected ISA Server error, You Can troubleshoot the error based on the user or the data packet. This section provides troubleshooting policies for two types of connection problems.

Objective
Eliminate user-based access issues.

Eliminate packet-based access issues.

Resolves VPN connection faults in ISA Server.

Estimated learning time: 30 minutes
10.2.1 troubleshooting of user access
When user account access is interrupted or unavailable, it may be caused by overly strict security requirements, incorrect rule configuration, and incomplete authentication methods. In this case, tools such as Ping and Tracert are useful.

To eliminate user-based access problems, first check the access policy rules. With the configured access policy, you can confirm that users who cannot establish a network connection are authorized to access the site, content group, and protocol.

If the configured rule cannot be successfully applied to user sessions, confirm that the array attribute is configured to require authentication to unauthenticated users. At the same time, if you create an access policy that allows access types and apply the policy to the specified users and groups, the user session is required to pass ISA Server Authentication. On the other hand, if you want to keep all Web sessions anonymous and access to Web sessions is denied, determining the array attribute does not require anonymous users to perform authentication. In addition, delete all site and content rules or Protocol rules that are allowed to be applied to the specified Win2000 users and groups.

Authentication

In array attributes, the selection of authentication methods affects the user's connection capabilities. Each authentication method is designed for a certain network environment. If an incompatible authentication method is selected in the network configuration or the method configuration is incorrect, the user cannot access the ISA Server computer or the network.

For example, the Default Authentication Mode of the array is integrated Windows authentication. However, this method cannot verify clients running non-Windows operating systems. If you want to provide authenticated access services for such customers in ISA Server, you must configure the array attribute to use other authentication methods. Similarly, integrated Windows authentication is not compatible with Netscape because Netscape cannot pass User Certificates in NTLM format. Another limitation is that it relies on the Kerberos V5 authentication protocol or its own inquiry/Response Authentication Protocol. However, in the pass-through authentication scheme, as shown in 10.3, ISA Server does not support the Kerberos V5 authentication protocol, because Kerberos V5 requires the client to recognize the authenticated Server.

In ISA Server, Basic, Digest, and Client Certificate are optional authentication methods. Basic authentication is compatible with all customer types. However, the security of Basic authentication is insufficient because the user name and password are transmitted in plaintext without encryption. Digest authentication can only be used in the Windows2000 domain. The password is transmitted in plain-coded but encrypted text.

Line. Client Certificate authentication uses the SSL channel for authentication. It needs to install the customer certificate in the Web Proxy service certificate library on the ISA Server computer, and the certificate should be mapped to the appropriate user account. ISA Server only provides customer certificates when configuring SSL bridging.

10.2.2 data packet-based access troubleshooting
When all users cannot access the network, or IP-based utilities such as Ping and Tracert fail, it can be determined that the access problem is based on data packets.

In ISA Server, to eliminate packet-based access faults, simplify network configuration as much as possible to form a test environment.

Establish network troubleshooting Configuration

1. enable packet filtering and create a custom packet filter to allow any IP protocol to pass in and out.

2. Create a protocol rule to allow any requested IP addresses to communicate with each other and determine that a site and content rule already exist to allow access to all sites and content groups.

3. Restore all program filters and routing rules to the default settings.

4. Verify that the local address table has been defined within the customer scope of ISA Server.

5. In the IP Packet Filters Properties dialog box, start IP Routing.

Note that the IP Routing option provides Routing capabilities for protocols with secondary connections. This setting is especially important for the configuration of the Border network. You can enable the IP Routing option in the IP Packet Filters Properties dialog box of ISA Management or the Routing and Remote Access console.

6. On the ISA Server computer, make sure that no default gateway is defined for the Internal interface. However, make sure that the appropriate default gateway is specified on the external interface.

7. Disable the firewall client software on the client that tries to establish an access connection, and specify the ISA Server as the default gateway.

Once the ISA Server is configured in this simplified way, restart the ISA Server service. If you still cannot access the network, restart the ISA Server computer. If the problem persists, it may not be caused by the configuration of the ISA Server. In this case, network troubleshooting should be performed. Use a network monitor to track and check DNS, route tables, reports, and logs.

If you can access the Internet in this simplified mode, you can import network units one by one to determine the cause of the problem. For example, if you can access the Internet on a given client, you can try to use the specified Internet program on the computer. If a problem occurs, either the application is not correctly configured to use the ISA Server as the proxy Server, or the program cannot use the proxy Server. For programs that cannot use the proxy server, you must configure the client to convert the security network address to the client or run the firewall client software. After you reconfigure the client, pay attention to its behavior changes. The automatically discovered feature configuration is incorrect. The problem persists until all required network components are added to the specified configuration.

VPN Network considerations
In the VPN Network, troubleshooting also begins with the establishment of a simplified network environment. If you have run the new VPN wizard, verify that you have run the Routing and Remote Access Service. Then, make sure that the client has been configured as a secure network address translation client, instead of a firewall client.

In addition, it must be confirmed that the LocaISA Server VPN Configuration Wizard has created an appropriate request dialing interface in Routing and Remote Access. You can check this on the Routing Interfaces node, as shown in Figure 10.4.

Then, confirm that two IP data packet filters are created for each authentication protocol selected for the VPN connection. For example, if the VPN network is configured to use L2TP or PPTP, The LocaISA Server VPN Configuration Wizard should create and start four IP data packet filters. (For L2TP, the Configuration Wizard creates custom General filters for ports 500 and 1701. For PPTP, the Configuration Wizard creates a predefined filter for PPTP call and PPTP receive ).