Lesson 1 Troubleshooting Tools in ISA Server

To determine the causes of connectivity, security, and service errors in ISA Server, you need to become familiar with the full range of tools available for network troubleshooting. These troubleshooting tools include features specific to ISA Server as well as common Transmission Control Protocol/Internet Protocol (TCP/IP) commands and Microsoft Windows 2000 utilities. This lesson introduces many of these tools and discusses how you use them to diagnose and repair errors in ISA Server installations.

After this lesson, you will be able to


Use several tools to troubleshoot ISA Server errors

Verify and modify routing tables

Verify port status using Netstat and Telnet


Estimated lesson time: 45 minutes

Troubleshooting Tools

When unexpected problems arise in your ISA Server installation, you can take advantage of a range of troubleshooting tools to determine the cause. Depending on the type of problem you need to troubleshoot, you can consult any combination of the following tools:

ISA Server Reports

Event Viewer

Performance Monitor

Netstat

Telnet

Network Monitor

The Routing Table


ISA Server Reports

ISA Server reports are useful as a first stop in troubleshooting. These reports can be viewed individually or together to pinpoint the cause of a performance problem. For example, if your users are complaining about sluggish Web performance, you can first review the Cache Performance report in the Traffic and Utilization reports file, as shown in Figure 10.1. However, even if the report indicates a low cache hit ratio, you should review other reports to determine whether the slow Web response is a result of the cache being underused. If active caching is disabled, and if no download jobs are scheduled, ISA Server will not be able to retrieve Hypertext Transfer Protocol (HTTP) requests frequently from the cache, and the end user will experience slow Web performance. However, if reports reveal that the cache is being used frequently, slow response can result from high network saturation, which can be caused by (among other things) too-frequent download jobs or too-short time-to-live (TTL) parameter settings.

Poor performance resulting from a low cache hit ratio can be remedied by configuring more frequent or extensive download jobs after hours, or by lengthening the TTL parameters in the Cache Configuration Properties dialog box.

Figure 10.1 A sample cache performance report

Event Viewer

When you are troubleshooting an error related to the function of an ISA Server service, you should consult the Microsoft Windows 2000 Event Viewer. Windows 2000 Event Viewer displays all event messages generated by the ISA Server services. These messages may be warnings or error notifications, or they may simply be informational. When you find a particular event message reported by the service you are troubleshooting, always double-click the event message and note its Event ID. Using the Event ID, you can search ISA Server Help or Appendix C of this book to learn recommended ways to remedy the problem associated with the event message.

Performance Monitor

The ISA Server Performance Monitor can help you resolve problems related to network usage, hardware, and configuration. For example, when attempting to determine the cause of slow cache performance, you might find % Disk Time to be high. If, in addition, the Disk Bytes/sec counter indicates a slow rate of data transfer to and from a disk, you might determine that slow cache performance will be improved by adding a new disk. If, on the other hand, the Disk Bytes/sec reading does not appear unusually low but the Pages/sec counter indicates a high rate of page faults, you might determine that slow cache performance will be improved by increasing the amount of physical RAM in your system, or by increasing the percentage of physical memory used for caching.

Troubleshooting successfully with ISA Server Performance Monitor requires you to establish baselines of counters before problems occur. This way, when you perceive that a given counter has diverged significantly from its baseline, you will be able to determine that a problem is occurring with a particular system element.

Netstat

Netstat is a command-line tool that is useful for troubleshooting security and connectivity problems. By typing netstat at the command line, you can check your ISA Server computer's port configuration and see every connection being made to and from your computer.

Ports are used in Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) to name the ends of logical connections. Port numbers may range from 0 to 65535, and are divided into the following three ranges: well-known ports, registered ports, and dynamic and/or private ports. Well-known ports are those whose numbers range from 0 through 1023. Registered ports' numbers range from 1024 through 49151. Dynamic and/or private ports have numbers spanning 49152 through 65535. For more information on ports, consult the port numbers Web site at http://www.isi.edu/in-notes/iana/assignments/port-numbers.

By using the –a switch with the Netstat command, you will receive an output of all listening ports in addition to all active connections. When you use the –n switch, addresses and port numbers are not converted to names. This enables you to differentiate between connections to the external and internal Internet Protocol (IP) addresses of your ISA Server computer and to determine which ports are open at any given moment on a particular interface. You can learn which services are active on which particular ports by comparing the output of netstat –an to that of netstat –a.

You can limit the output of the Netstat –an command by specifying a particular protocol with the –p TCP or –p UDP switch. For example, the Netstat –an –p TCP command will print an output of all active TCP connections and listening ports, and the Netstat –an –p UDP command will print an output of the port status for UDP only.

Knowing your port configuration allows you to check for connectivity problems, port conflicts, and security holes. For example, if you are unable to connect to a remote server, the netstat output may confirm that the problem is not local, and indicate that it is the remote computer that is rejecting your connection attempt. You can also verify that you are receiving TCP resets or ICMP Port Unreachable packets each time you attempt to connect.

Finally, Netstat can be used to diagnose attacks on your system. For example, a SYN attack is used to create a large number of half-open TCP connections and render a server inoperative. The foreign address in this case is typically a spoofed address with incrementally increasing port numbers. The distinctive nature of SYN attacks make them recognizable from the following netstat output:

C:\> netstat -a
C:\>netstat -n -p tcp
Active Connections
Proto  Local Address          Foreign Address        State
TCP    127.0.0.1:1030         127.0.0.1:1032         ESTABLISHED
TCP    127.0.0.1:1032         127.0.0.1:1030         ESTABLISHED
TCP    10.1.1.5:21            192.168.0.1:1025       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1026       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1027       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1028       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1029       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1030       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1031       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1032       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1033       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1034       SYN_RECEIVED
TCP    10.1.1.5:21            192.168.0.1:1035       SYN_RECEIVED

For more information on SYN attacks and on how to configure Microsoft Windows 2000 to defend against them, see Windows 2000 TCP/IP Protocols and Services Technical Reference, by Thomas Lee and Joseph Davies (Seattle: Microsoft Press, 2000).

Telnet

By specifying a port number after the Telnet command, you can test whether a server is accepting commands through that port. For example, after running the Netstat –an –p TCP command, you may find that port 3149 is listening for incoming requests. You can then determine whether ISA Server will allow users to telnet to that port by typing telnet external_ip_address 3149 at the command prompt, where external_ip_address is the public IP address assigned to your ISA Server computer. If you receive a blank screen, or any response output other than one indicating a connection failure, an external user may theoretically communicate with the service located at the port by typing service commands directly. Note that this status does not normally indicate a security hole, but if there are security weaknesses associated with a given service, a hacker will often use Telnet to exploit them.

You may also use Telnet to determine whether a given service is active on your computer. For example, if you are able to Telnet to port 25 of your ISA Server computer, this indicates that your Simple Mail Transfer Protocol (SMTP) service is running and accessible to external users. If you would like to prevent external users from accessing the SMTP service on your ISA Server computer, you can choose to remedy the situation by shutting down the service, by verifying that packet filtering is enabled on ISA Server, and/or by ensuring that no IP packet filters are enabled in ISA Server allowing inbound traffic to pass through port 25. If, on the other hand, you are publishing a server and want to test external access, you may want to Telnet to the service's port to see if it is accepting connections. For example, if you are publishing a Web server on port 9999 of your ISA Server computer, you can type telnet external_ip_address 9999 to ensure that you are able to connect to that port.

Network Monitor

Network Monitor, or Netmon, is a tool used to capture and display the contents of frames that a Windows 2000 computer receives from the local area network (LAN). To ease analysis of network traffic, Network Monitor breaks down and organizes 40 of the most common network protocols. This means that for most network traffic, Network Monitor displays virtually all information associated with network sessions, including source and destination ports and addresses, server responses, and traffic payloads.

The following is an example frame taken from a Network Monitor trace, or capture.

Network Monitor trace  Wed 03/07/2001 08:55:17 AM  Captur 1.txt
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol
+ IP: ID = 0xAD6; Proto = TCP; Len: 327
+ TCP: .AP..., len:  287, seq:3184161250-3184161537, ack:4040781620,
win:17520, src: 1225  dst:   80 
+ HTTP: GET Request (from client using port 1225)

For each frame displayed, the encapsulated protocols it contains are listed in order from the outside of the frame in, or from a networking perspective, from the lowest layer up. By clicking on the + sign at the start of any line, you can reveal more information contained in the given protocol. The first line, named Frame, is added by Network Monitor to introduce the frame captured. The next line presents the data-link layer protocol by which the frame is put on the network (in this case, Ethernet). Such a protocol represents the lowest layer protocol in the frame, corresponding to layer 2 in the Open Systems Interconnect (OSI) model. This is followed by the network layer protocol, or layer 3, which in this case is the IP protocol. Next is the transport layer protocol, or layer 4, which in the given frame is TCP. Finally, in this example, HTTP is the highest protocol layer in the frame.

Each protocol layer contains information relating to the present connection or transmission. For example, on the TCP line, the src and dst parameters refer to the source port and destination port of the TCP connection associated with the frame or packet. In this packet, the source was TCP port 1225 on the client side and TCP port 80 on the destination side. By looking at the TCP or UDP line within a captured frame in Network Monitor, you can always find the source and destination of traffic on the network. This is an essential tool for configuring firewalls.

In addition, by creating traces of network activity, you can analyze traffic and determine the source of a network problem. For example, suppose your users are complaining about logon delays through a virtual private network (VPN) connection. When you run a Network Monitor capture, the trace may reveal the presence of both Layer Two Tunneling Protocol (L2TP) and Point-to-Point Tunneling Protocol (PPTP) traffic during logons. This would indicate that you have configured the Local ISA VPN wizard to connect to the remote network by using L2TP by default, but to use PPTP when L2TP is unavailable. If L2TP is unavailable on the remote VPN server, your users will experience a delay while attempting to connect through both protocols. Network Monitor thus allows you to find out when the L2TP connection is not working. This allows you to remedy the logon delays by configuring ISA Server to connect to the remote VPN server through PPTP only.

Even if you don't require a VPN in your network environment, a Network Monitor capture may reveal that your network is slowed by protocols your network does not need for communication. For example, the tunneling protocol PPTP is not needed for private LAN connections.

The Routing Table

Every computer using TCP/IP as a network protocol has a routing table. The route that an IP packet takes from one computer to another is determined by the routing table of the computer that sent the network packet.

You can view and modify the routing table by using the Route command-line utility. By typing route print at the command prompt, the local routing table will be displayed, as shown in Figure 10.2.

Figure 10.2 A Sample Routing Table

The Route Determination Process

To determine a single route to use to forward an IP packet, the IP protocol uses the routing table in the following way:

For each route in the routing table, IP performs a bit-wise logical AND operation between the Destination IP address and the subnet (the netmask column in Figure 10.2) to determine if the network is local or remote. IP compares the result with the network destination for a match. If there is a match, IP marks the route as one that matches the Destination IP address.

From the list of matching routes, IP determines the route that has the most bits in the netmask. This is the route that matched the most bits to the Destination IP address and is therefore the most specific route for the IP packet. This is known as finding the longest or closest matching route.

If multiple closest matching routes are found, IP uses the route with the lowest metric.

If multiple closest matching routes with the lowest metric are found, IP randomly chooses the route to use.

The end result of the route determination process is the choice of a single route in the routing table. If the route determination process fails to find a route, IP declares a routing error.

Troubleshooting Routing Tables

By using IP utilities such as Ping and Tracert, you will be able to determine when certain network segments are inaccessible to the rest of the network. When you are installing ISA Server on a complex network, you can use the Route command to modify the routing tables and configure viable routes for all network segments. For example, if your ISA Server does not have an interface on a given (remote) subnet, you will need to add a static route to allow traffic to be forwarded to that subnet. (Static routes are those that do not appear automatically in routing tables.)

To add a static route, you can use the Route utility as follows:

route add 172.16.41.0 mask 255.255.255.0 172.16.40.1 metric 2

In this example, the Route add command states that to reach the 172.16.41.0 subnet with a mask of 255.255.255.0, gateway 172.16.40.1 should be used. Note also that in this case the metric is set to 2 because the subnet is two hops away. (The metric is usually set to the number of hops, or routers crossed, to the network destination.) In this case, you may also need to add static routes on downstream routers telling packets there how to get back to the 172.16.40.0/24 subnet.

Since your computer's routing table is automatically rebuilt each time you restart your computer, you will need to add persistent entries to the routing table if you want static routes to remain in the routing table. Persistent entries are automatically reinserted in your route table each time your computer's route table is rebuilt. Persistent entries are added using the Route add -p command.

Static routes can also be added by using the Routing and Remote Access console in Windows 2000. All static routes are treated as persistent routes when they are added by using the Routing and Remote Access console.

Follow these steps to add a static route in Routing and Remote Access:


Click Start, point to Programs, point to Administrative Tools, and click Routing And Remote Access.
Double-click IP Routing to expand that object.
Right-click Static Routes and click New Static Route.

The Static Route dialog box appears.

Complete the fields of the static route as necessary.

Practice: Testing Port Status

In this practice, you use the Netstat and Telnet commands to determine the status of ports on the ISA Server computer. This technique can be used to verify security, or it can be used to determine whether a service running on the ISA Server computer is available to external sites.

Exercise: Testing ISA Server ports

In this exercise, you run the Netstat utility at a command prompt and note the various ports that are open on the external interface of the ISA Server computer. You then try to telnet to these open ports.

To test the status of ports on the ISA Server computer


Log on to Server1 as Administrator.
Click the Start button, and then click Run.

The Run dialog box appears.

In the Open text box, type cmd and click OK.

A command prompt appears.

At the command prompt, type netstat –an –p tcp.

An output of all active TCP ports on the ISA Server computer appears. On the output screen, the left column of IP addresses with port numbers represents the local address of each active connection, and the right column of IP addresses with port numbers represents the foreign address of each active connection. Most of the local addresses in the output refer to the internal interface, 192.168.0.1. However, at the end of the list, there may be a few connections whose local address is the external IP address of the ISA Server computer.

How many connections are currently active on the external interface of the ISA Server computer? Look at the foreign address for each of those connections. Which ports being used in foreign addresses to send information to the external interface of your ISA Server computer?

On the ISA Server computer, open Microsoft Internet Explorer and connect to an external Web site such as http://www.microsoft.com.
While the Web page is still downloading in Internet Explorer, switch to the command prompt window and type netstat –an –p tcp again at the command prompt.

An output of all active TCP ports on the ISA Server computer appears.

Look at the end of the output list. Compared to your answer in Step 5, How many more connections are active on the external interface of the ISA Server computer? Do you see any active ports on foreign addresses that you did not list before? After you view this data, which foreign port can you determine is used to send Web data to the local external IP address?
To which local ports on the external interface of ISA Server computer is this Web data sent? These are dynamic ports that vary from connection to connection. Write the number corresponding to these ports in the space below.

Suppose that you find evidence of an intrusion in your network, and you want to troubleshoot security by testing the status of external ports through which a hacker may try to gain access. You can attempt to telnet to external ports to see whether a service located at that port responds to your connection request. (Ordinarily you would want to perform this from an external computer.)

Attempt to Telnet to one of the external ports that you wrote down in Step 9 as follows: At the command prompt, type telnet [external_ip_address] [port_number], where [external_ip_address] is the external IP address currently assigned to your ISA Server computer and [port_number] is one of the local ports you have noted in Step 9 ( for example, telnet 64.43.113.110 10123).

A message appears, indicating that the connection to the port has failed. The port is not a listening port. When a port is accepting external connections, you will either get a blank screen or a message output from the service communicating at that port.

In the command prompt window, attempt to telnet to each the ports listed in the left column of the table below. Write the status of each of these ports as either Open or Closed in the corresponding column to the right.

Answer will vary.

An open port status does not normally indicate a security weakness, but there are some ports that, for security reasons, you may not want to leave open statically, such as port 15 (Netstat), 21 (FTP), 23 (Telnet), 25 (SMTP), 79 (Finger), and HTTP (80).

Close the command prompt window.

Lesson Summary

Many tools are available to help you troubleshoot problems in ISA Server. As a starting point, ISA Server reports can help determine the cause of a performance problem. Event Viewer is useful in that it displays all event messages generated by the ISA Server services. The ISA Server Performance Monitor can help resolve problems related to network usage, hardware, and configuration. Netstat is command-line tool that shows all active TCP and/or UDP connections, which is useful for troubleshooting security and connectivity problems. You can also use the Telnet utility to test whether a server is accepting commands through given ports. Network Monitor is used to capture and display the contents of frames that a Windows 2000 server receives from the LAN. Finally, the Route command is useful for verifying and modifying the routing tables to make sure all network segments can be accessed through viable routes.