Microsoft Forefront Threat Management Gateway: Using Network Monitor 3 for Troubleshooting TMG
- 2/10/2010
- Using Network Monitor to Capture Traffic
- Data Gathering with Network Monitor
- Reading a Network Monitor Capture
- Troubleshooting TMG Using Network Monitor
- Summary
Troubleshooting TMG Using Network Monitor
In this part of the chapter, you’ll see how to use various Network Monitor display filters to help evaluate a SOCKS-proxy application’s misbehavior. The capture used in this example is contained on the companion CD as socks4_ftp.cap.
In this scenario, a colleague has decided that he wants to test how Internet Explorer (IE) behaves as a SOCKS proxy client when accessing FTP servers. He believes the TMG and IE configurations are correct, but he has two problems that he needs your help to resolve:
His internal DNS structure does not allow clients to resolve public names to IP addresses, yet IE is able to make the connection to the FTP server.
Although IE is apparently able to connect to the FTP server, IE cannot display a directory listing from the FTP server.
At your request, he obtained a Network Monitor capture at the test client during an attempt to use the ftp.3com.com FTP server and sent it to you for analysis. When you open the capture file, Network Monitor initially displays an unfiltered protocol analysis as shown in Figure 33-10.
)
Figure 33-10 Initial Network Monitor display for socks4_ftp.cap
You’ll notice that because your colleague did not define a filter during the capture, it contains a lot of traffic that appears to be unrelated to the issue you’re evaluating—at least right now. You’ll see the value of an unfiltered capture as we move through the analysis.
Because you know that your colleague is testing the browser as a SOCKS client, you can apply a display filter to limit the traffic Network Monitor displays to that protocol. You do this by performing the following steps:
Enter the name of the protocol (SOCKS) in the Display Filter pane just above the Frame Summary pane, as shown in Figure 33-11.
Either click Apply in the Display Filter pane or press Ctrl+Enter to apply the filter to the Frame Summary display.
Figure 33-11 Frame Summary display filtered for SOCKS protocol
Initially, the capture seems to indicate behavior that is typical of an FTP application configured as a SOCKS proxy client:
IE sends a SOCKS CONNECT for IP address 192.136.34.93 and port 21 (FTP control channel). Because IE specified the IP address instead of the FTP server host name, it’s clear that IE is indeed resolving the host name to the IP address.
The SOCKS proxy replies with GRANTED. This response demonstrates two facts:
The SOCKS proxy rules allow this request.
The connection to the requested destination was successful.
Immediately following the SOCKS GRANTED reply, you see the FTP banner in Frame 612. This tells you that the FTP server is functioning at a basic level.
The FTP server accepts an anonymous login from IE. You can determine that whatever problem your colleague is having, it’s not related to FTP server authentication.
The FTP server accepts the IE instruction to change the working directory to the root directory (CWD /).
The FTP server accepts the IE command to send ASCII data (TYPE A).
The FTP server accepts the PASV command sent by IE and responds with the IP and port that the FTP server has prepared for IE to connect to for use as the FTP data channel. In this case, IE should connect to the FTP server on IP address 192.136.34.93, port 43799.
IE then issues a SOCKS CONNECT command for IP address 192.136.34.93 and port 21 (FTP control channel).
The process indicated in steps 5 and 6 is typical of an FTP client that is preparing to send a Print Working Directory (PWD) command to an FTP server (similar to the Windows DIR command). What is unusual about this capture is that immediately after the FTP server tells IE how it should establish the FTP data channel connection, IE issues the SOCKS CONNECT request for the same destination and port as the FTP control channel. Clearly, this is not what IE should be doing at this point. Because we don’t have visibility into the logic IE is using, we have to proceed using reasonable assumptions.
One thing that may have happened is that IE determined that it was unable to establish the FTP data channel connection as directed by the FTP server and decided instead to restart the whole process with the FTP server. Because the capture does not indicate that IE tried to make a SOCKS connection to the FTP server data channel listener, we can see whether IE tried to make a direct connection. To determine whether this is the case, change the display filter to limit the output to the FTP server IP address by following these steps:
Type ipv4.address==192.136.34.93 in the Display Filter pane just above the Frame Summary pane, as shown in Figure 33-12.
Figure 33-12 Frame Summary filtered for FTP server IP address
Either click Apply in the Display Filter pane or press Ctrl+Enter to apply the filter to the Frame Summary display.
It seems clear from the Frame Summary display in Figure 33-12 that IE did not try to make a direct connection to the FTP server for the data channel connection. Although this clarifies the scenario for you, it does raise some questions about IE behavior as a SOCKS proxy client.
Now that you can demonstrate why your colleague cannot obtain a directory listing from the FTP server and have the isolated the data required to prove it, you decide to move to the question of name resolution for public names that shouldn’t work.
A network capture can’t tell you why IE is choosing to establish another FTP control channel when it should be establishing an FTP data channel using the parameters provided by the FTP server, but the capture does provide the empirical data your colleague will need when he calls Microsoft Customer Support Services (CSS).
To answer the question of name resolution, your next step would be to filter the capture on the DNS protocol by following these steps:
Enter the name of the protocol (DNS in this case) in the Display Filter pane just above the Frame Summary pane, as shown in Figure 33-13.
Figure 33-13 Frame Summary display filtered for DNS
Either click Apply in the Display Filter pane or press Ctrl+Enter to apply the filter to the Frame Summary display.
)
It seems clear that the client did not issue any DNS queries at all—much less for ftp.3com.com, so the question now is how was IE able to resolve the name “ftp.3com.com” to an IP address?
One thing Network Monitor can do that no other network traffic capture tool does is to include the application process that is generating or accepting network traffic. This provides you with the ability to filter the traffic based on the process that Windows associates with the traffic. Although this is only possible if the capture was taken using Network Monitor 3 or later on a Windows computer, it is nonetheless a very valuable feature, as you’ll soon see.
Network Monitor builds the application-to-traffic association in the context of a conversation. To see all the traffic Network Monitor associated with IE while your colleague was taking the capture, follow these steps:
Type Conversation.ProcessName.contains(“iexplore”) in the Display Filter pane just above the Frame Summary pane, as shown in Figure 33-14.
Figure 33-14 Frame Summary display filtered for DNS
Either click Apply in the Display Filter pane or press Ctrl+Enter to apply the filter to the Frame Summary display.
)
){kind=link}
){kind=link}
The first thing you notice is that Network Monitor is displaying a protocol named RWS that includes a reference to TMG. The RWS protocol is one of two protocols used by the TMG Client (TMGC) to communicate with TMG. Therefore, you may surmise that your colleague has the TMGC installed on his test computer.
As you examine the conversation between the TMGC and TMG, you notice that among other things, the TMGC sends a “Get host by name('ftp.3com.com') from iexplore.exe” message to TMG, which responds with a “Host entry response to iexplore.exe for ‘ftp.3com. com’” message to the TMGC. Because you learned from the TechNet article that “Get host by name” is related to name resolution, you decide that this part of the conversation merits deeper investigation. You can examine the host entry message in greater detail by selecting the packet in the Frame Summary pane. When you do this, the packet details are displayed in the Frame Details pane. You can view more detail of each protocol by clicking the plus sign on the left side of the display to expand that item. You can continue this process until you find the data that you are seeking. In this case, although you are reasonably sure that IE is resolving the name ftp.3com.com to an IP address via TMG, you want to prove this theory conclusively. You do this by expanding each node in the RWS protocol as it is displayed until you locate the IP address IE used in the SOCKS CONNECT command. Figure 33-15 shows the part of the RWS message that includes this data.
){kind=link}
Figure 33-15 IP address in the Host Entry response message
Using Network Monitor, you’ve helped your colleague answer both of his questions—how IE is able to resolve the FTP server name to an IP address and why IE fails to display a directory listing of the FTP server. Although you are unable to explain why IE chooses not to connect to the FTP data channel listener described by the FTP server, you have demonstrated that IE fails to behave as expected based on the conversation with the FTP server. When your colleague contacts Microsoft Customer Support Services (CSS) to inquire about IE misbehavior, he can describe this problem clearly and in great detail. This information goes a long way in helping the CSS engineer determine the proper resources to engage on behalf of the caller.