Microsoft Forefront Threat Management Gateway: Using Network Monitor 3 for Troubleshooting TMG

Reading a Network Monitor Capture

Analyzing network captures is an exercise made up of 50 percent knowledge and 50 percent experience. A dazzling number of digital and print references are available that are intended to help you improve your network analysis skills. Network capture analysis requires at least a basic knowledge of the behavior expected from the application under test as well as some familiarity with the related protocols. The time spent using multiple capture and analysis tools will help you gain these skills.

If you’ve never used a network analysis tool, you need to understand a few things about how Network Monitor processes network captures:

• All network traffic is divided into data chunks called packets.

• The packets contain data relative to one or more protocols.

• The protocols in these packets are identified and analyzed using protocol parsers.

• One parser can call another parser if it has been written to recognize the protocol handled by the next protocol layer parser.

When you open a network capture file, Network Monitor passes the file data through its parser engine, which in turn calls the related protocol parsers as each protocol is identified. The result of this action is displayed to you in the Frame Summary pane of the Network Monitor application window, as shown in Figure 33-5.

Figure 33-5 Network Monitor display example

In the left pane, Network Monitor displays a summary of the IP conversations identified by the parsers that were called by the Network Monitor parsing engine. By default, Network Monitor limits this display to the lowest-layer protocol; in this case, the application process name and process ID are shown because the capture was taken with these options enabled.

Each conversation is assigned a unique number to help you filter the capture so that only the protocols you are interested in are displayed.

You can click the plus sign (+) indicator to expand an IP conversation to display the higher-layer protocols, each of which can be expanded if it contains a higher-layer protocol. If you select one of the conversations in the left pane, the Frame Summary pane is updated to show only those packets that are related to that protocol and conversation. Figure 33-6 illustrates this relationship for one of the conversations.

Figure 33-6 Conversation summary display

If the data is saved as part of the capture file, Network Monitor organizes the conversation summary so that the relationship between applications and the protocols is clear. If the process information is not part of the capture, Network Monitor only shows the protocol relationships. In the example shown in Figure 33-6, HTTP conversation 10 is part of TCP conversation 9, which in turn is related to IP conversation 8 and was created by iexplore.exe (Internet Explorer) process ID 2484. One thing to remember about Network Monitor conversation identifiers is that they are assigned as each parser tells the parser engine to create a conversation. Because higher-layer protocols are called by lower-layer protocols, the conversation value represents the total number of conversations Network Monitor has identified up to that point in the capture, not the conversation count for a particular protocol. In other words, HTTP conversation 10 represents the tenth conversation Network Monitor was instructed to build, not the tenth HTTP conversation Network Monitor identified.

These values are useful in the display filter pane as values provided in the Conversation. Protocol.ID, where Protocol is replaced by the name of the protocol of interest, such as TCP, HTTP, and so on. If you wanted to limit the display to HTTP conversation 10, you would type conversation.http.id==10 in the Display Filter text box and click Apply or press Ctrl+Enter to apply the filter.

Network Monitor also provides the means to filter the capture on any parsed aspect of the capture data. Network Monitor depends on the protocol parsers to help with this functionality because it is the parser’s responsibility to interpret the data and identify key aspects of the protocol that can be used by you in your analysis efforts. For instance, if you want to limit the display to TCP traffic to and from the TMG Web Proxy listener for a protected network, but you don’t yet know the conversation, you can use the display filter statement tcp.port==8080. Network Monitor allows you to apply the port number to the source and destination ports simultaneously by using the generic .port property. By using this generalization for source and destination ports, the display will show traffic to and from TMG, not just to TMG (as with tcp.dstport==8080) or traffic from the TMG Web Proxy listener (as with tcp.srcport==8080). This applies to UDP as well as TCP because they both utilize source and destination ports as part of the protocol.

This is where having a basic understanding of most common protocols is useful. If you try to apply a display filter to a protocol that doesn’t define a property you specify in the display filter, or if you specify an invalid value, Network Monitor will indicate an error and the current Frame Summary display will be unchanged. Figure 33-7 illustrates this behavior.

Figure 33-7 Network Monitor invalid filter response

The example in Figure 33-7 illustrates a common misunderstanding of protocol relationships. It’s generally accepted in the networking community that TCP port 80 is used for HTTP, but a common misunderstanding is that port 80 is part of the HTTP protocol itself.

Recall from Chapter 15, "Web Proxy Auto Discovery for TMG," that the WPAD process is actually made up of three separate protocols:

• DHCP to discover the WPAD URL

• DNS to discover the WPAD host record or resolve the name obtained in the DHCP INFORM response

• HTTP to request the CFILE (configuration file)

If you want to isolate the traffic related to WPAD, you have to use a more complex display filter statement than just ports. There is no way to write a single filter called WPAD, but because you know which protocols are involved, you can write a display filter that includes only the protocols that are part of the WPAD process. The simplest filter would appear as dhcp or dns or http, instructing Network Monitor to display only the packets that include those three protocols. Unfortunately, it would also display the DNS, DHCP, and HTTP traffic that was not related to WPAD.

You can create a filter that limits the traffic to only the data you want, but it takes a bit of sleuthing to gather the data you need to provide to Network Monitor. Because the Network Monitor team is owned and operated by some very experienced networking folks, they understand the need to make this task as simple as possible. The following steps illustrate how to use Network Monitor to build the query needed to isolate only WPAD-related traffic. The capture file is included on the companion CD as chapter-33-wpad.cap. The example capture doesn’t include DHCP traffic, so you get to limit your efforts to DNS and HTTP only.

Open Network Monitor

1. Click Start and then click All Programs.

2. Expand Microsoft Network Monitor 3.3 and then click Microsoft Network Monitor 3.3.

Open the Example Capture File

1. In Network Monitor, click Open Capture and navigate to your CD drive.

2. Select chapter-33-wpad.cap and click Open.

Apply the Basic WPAD Display Filter

1. In the Display filter text box, type dns or http.

2. Click Apply or press Ctrl+Enter to apply the filter to the Frame Summary display pane.

Your Network Monitor display should appear, as shown in Figure 33-8.

Figure 33-8 Initial Frame Summary display

Narrow the DNS Filter Scope

1. In the Frame Summary pane, select Frame 6 (DNS Query for wpad.contoso.com). This is the DNS query for the WPAD record. The Frame Details pane will display the protocol details for this packet.

2. Starting with the DNS protocol in the Frame Details pane, expand each following item until you see QuestionName: wpad.contoso.com.

3. Right-click QuestionName: wpad.contoso.com and select Add Selected Value To Display Filter. The Display Filter text box will change to “dns or http OR DNS.QRecord.QuestionName == “wpad.contoso.com"”.

Narrow the HTTP Filter Scope

1. In the Frame Summary pane, select Frame 11. This packet is the WPAD request from the client to TMG. The Frame Details pane will display the protocol details for this packet.

2. In the Frame Details pane, expand the data points within HTTP until you see the host: wpad.contoso.com.

3. Right-click host: wpad.contoso.com and select Add Selected Value To Display Filter. The Display Filter text box will change to “dns or http OR DNS.QRecord.QuestionName == “wpad.contoso.com” OR HTTP.Request.HeaderFields.Host == “wpad.contoso.com"”.

4. In the Frame Summary pane, select Frame 12. This packet is the WPAD response from TMG to the client. The Frame Details pane will display the protocol details for this packet.

5. In the Frame Details pane, expand the data points within HTTP until you see MediaType: application/x-ns-proxy-autoconfig.

6. Right-click MediaType: application/x-ns-proxy-autoconfig and select Add Selected Value To Display Filter. The Display Filter text box will change to “dns or http OR DNS.QRecord.QuestionName == “wpad.contoso.com” OR HTTP.Request.HeaderFields.Host == “wpad.contoso.com” OR HTTP.Response.HeaderFields.ContentType.MediaType == “application/x-ns-proxy-autoconfig”.”

Narrow the Whole Display Filter

1. In the Display Filter pane, delete “dns or http OR” from the display filter text. The remaining text should read “DNS.QRecord.QuestionName == “wpad.contoso.com” OR HTTP.Request.HeaderFields.Host == “wpad.contoso.com” OR HTTP.Response.HeaderFields.ContentType.MediaType == “application/x-ns-proxy-autoconfig”.”

2. In the Display Filter pane, click Apply or press Ctrl+Enter to apply the display filter. The Frame Summary pane contents should resemble Figure 33-9.

   

   Figure 33-9 WPAD display filter results

Congratulations! You’ve just defined a filter that will specifically identify the DNS and HTTP portions of the WPAD process used by any host in the Contoso organization. Because Network Monitor also allows you to save filter definitions, you need never be forced to re-create this little gem.