Network Monitor 3.3 RWS Parser Basics, Part 2: Observing single-connection HTTP traffic

  • Article

Published: March 2010

Author:
Jim Harrison - Program Manager

Reviewers:
Yuri Diogenes - Sr Security Support Escalation Engineer
Michael Hawker - Program Manager

Editor:
Simon Rabinowitz - Technical Writer
Meir Feinberg – Technical Writer

Introduction

In part 1 of this article series, I described the RWS message set and the relationship between those messages. In this part, I’ll discuss a single-connection TCP scenario using HTTP as the application protocol.

As a rule, it’s best to test using a tool whose proxy usage you can control without affecting the rest of the computer. The logic behind this is that if you can demonstrate that a properly-behaving application can elicit a proper response through Forefront TMG, then the original problem is most likely to be found in the original application or the computer configuration. Although this is not guaranteed, it is highly probable. https://isatools.org/tools/http_test.zip contains a script I wrote specifically to meet that requirement. It’s this tool that I’ve used to produce the HTTP-based captures in this article.

In the following examples, I’ll use the http_test.wsf script to take you through four scenarios:

  • A Successful scenario (we need to know what looks right).

  • A failed scenario based on destination rejection by a rule. See Deny Rule Action.

  • A failed scenario based on name resolution failure. See Name Resolution Failure.

  • A failed scenario based on connection failure (not rule-based). See Connection Failure.

Successful scenario

In order to recognize when something is wrong, you have to know what the process looks like when it works properly. Ideally, you should set aside some time to walk through a normal RWS/WSP process with an application you’re comfortable with so you can become familiar with the expected RWS and WSP abstractions for this application’s traffic profile. The results of this effort and the captures you produce will be very enlightening and useful when you have to troubleshoot this application later.

In this example, I’ll use the http_test.wsf script to establish a connection to https://isatools.org using the TMGC. In order to do this, I’ll run this tool in a command window using the following command:
cscript http_test.wsf /url:https://isatools.org
If I wanted the script to operate as a CERN proxy client, I would use the following command:
cscript http_test.wsf /url:https://isatools.org /proxy:NameOrIpAddress:port
Before I run the script, I need to start a network capture on the Forefront TMG computer. Because I want to capture data on the internal and external networks simultaneously, the command I’ll use is nmcap /capture /network *.This command will capture traffic on all active interfaces simultaneously, allowing me to review all of the resulting traffic in a single display window and tab. If you want to learn more about nmcap usage, use nmcap /examples.

The order of operations for this sort of effort should be:

  1. Configure the relevant computers for the specific repro effort

  2. Start all monitoring tools (Network Monitor 3.3, Perfmon, etc.)

  3. Run the test

  4. Stop the monitoring tools

Now let’s examine the results of this effort. I open the network capture and apply a basic TMGC filter as shown below:

Basic RWS and WSP filter

Figure 1 - Basic RWS and WSP filter

These resulting frames tell us that the TMGC was able to:

  1. Establish and negotiate the control channel with Forefront TMG.

  2. Resolve the name “isatools.org” to an IP address through Forefront TMG.

  3. Establish a connection to IP address 216.249.33.234 on TCP port 80 through Forefront TMG

  4. Exchange HTTP traffic with the server at 216.249.33.234 through Forefront TMG

RWS Conversation Breakdown

What isn’t completely clear from the frame summary alone is how TMGC and Forefront TMG communicate throughout this process. The following discussion breaks down this conversation.

Note

This is not intended to be a complete discussion of the RWS protocol – only those parts that relate to this example.

Channel Setup Request

In frame 4, the TMGC indicates its desire to establish a RWS control channel with Forefront TMG. This message includes data that tells Forefront TMG a lot about the application and its environment (the most interesting parts are in bold).

- RWS: Channel setup request (TMG compatible) for cscript.exe as Administrator on winxp-pro running Windows XP x32
  - RwstPacket: Channel setup request (TMG compatible) for cscript.exe as Administrator on winxp-pro running Windows XP x32
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 365 (0x16D)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Channel setup
   - RwsMessage: request (TMG compatible) for cscript.exe as Administrator on winxp-pro running Windows XP x32
    - SetupData: request (TMG compatible) for cscript.exe as Administrator on winxp-pro running Windows XP x32
       Padding: Binary Large Object (18 Bytes)
       MinVersion: ISA Server compatible 
       MaxVersion: Forefront TMG compatible 
       Authentication: not required
       Reserved: 0 (0x0)
     - SetupFlags: KeepSession: False; RouteMode: True; ServerEncrypt: False; ClientEncrypt: True
        ServerKeepOldSession:  (...............................0) Keep previous session for this application
        ClientRouteMode:       (..............................1.) Route mode desired
        ServerEncryption:      (.............................0..) Encryption not required
        ClientEncryption:      (............................1...) Encryption enabled
        FlagsUnused:           (....000000000000000000000000....)
       dwReserved: 0 (0x0)
     + DiagBuf: 
       Padding: Binary Large Object (178 Bytes)
     - ClientInfo: cscript.exe as Administrator on winxp-pro running Windows XP x32
        Size: 84 (0x54)
      + OsVerInfo: Windows XP x32
        CPU: 586 (0x24A)
      + DosVer: 
        Reserved: 0 (0x0)
        offUserName: 48 (0x30)
        offMachineName: 62 (0x3E)
        offAppName: 72 (0x48)
        UserName: Administrator
        HostName: winxp-pro
        AppName: cscript.exe

  1. The ProtoSig field identifies the version the RWS protocol that the TMGC wants to use. There are three valid values for this field:

    1. RWS- this identifies unencrypted RWS on TCP

    2. RWSP - this identifies unencrypted RWS on UDP

    3. RWSE- this identifies encrypted RWS. This is only seen on TCP and only after successful authentication between TMGC and Forefront TMG

  2. The OpCode field identifies the action relevant to this RWS message. In this case, it identifies the beginning of the RWS control channel setup process. This field is where the RWS protocol summary derives the action part of the frame summary.

  3. The MinVersion field identifies the lowest firewall version supported by this client. In this case, it supports ISA Server.

  4. The MaxVersion field identifies the highest firewall version supported by this client. In this case, it supports Forefront TMG. This field is where the RWS protocol summary derives the compatibility statement.

  5. The ServerKeepOldSession field indicates that if a control channel exists between this TMGC and Forefront TMG, the server should allow that session to remain active.

  6. The ClientRouteMode field tells Forefront TMG that the TMGC wants the application traffic to be handled in Route Mode. This request cannot override defined network rule action and is only valid when defining an application path through Forefront TMG.

  7. The ClientEncryption field tells Forefront TMG whether or not the TMGC supports an encrypted control channel. If this field is set to 0 and Forefront TMG requires encryption, TMG will reset the control channel TCP connection and TMGC-based applications will not be able to communicate through Forefront TMG.

  8. The UserName field identifies the user account associated with the Winsock application. This field is used to populate the RwsApp properties.

  9. The HostName field identifies the computer name where TMGC is operating. This field is used to populate the RwsHost properties.

  10. The AppName field identifies the Winsock process being served by the TMGC. This field is used to populate the RwsApp properties.

Note

Because a single application may host multiple processes, the process name may not reflect the application you expect to see. The most notable example is the svchost process, which can host many different services. Another example is the tool used to create the HTTP traffic for this article. The Winsock process name is “cscript.exe”, but the tool we run is “http_test.wsf”.

Channel Setup Response

In frame 5, Forefront TMG responds to the Channel Setup request with a Channel Setup response. This message uses the same format as the Channel Setup Request, but some fields will be changed. Only the fields that differ in this message or are specifically relevant to the Channel Setup response message are discussed.

- RWS: Channel setup response to cscript.exe (TMG compatible), authentication not required; encryption not required
  - RwstPacket: Channel setup response to cscript.exe (TMG compatible), authentication not required; encryption not required
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Channel setup
   - RwsMessage: response to cscript.exe (TMG compatible), authentication not required; encryption not required
    - SetupData: response to cscript.exe (TMG compatible), authentication not required; encryption not required
       Padding: Binary Large Object (18 Bytes)
       MinVersion: ISA Server compatible
       MaxVersion: Forefront TMG compatible
       Authentication: not required
       Reserved: 0 (0x0)
     - SetupFlags: KeepSession: False; RouteMode: True; ServerEncrypt: False; ClientEncrypt: True
        ServerKeepOldSession:  (...............................0) Keep previous session for this application
        ClientRouteMode:       (..............................1.) Route mode desired
        ServerEncryption:      (.............................0..) Encryption not required
        ClientEncryption:      (............................1...) Encryption enabled
        FlagsUnused:           (....000000000000000000000000....)
       dwReserved: 0 (0x0)
     + DiagBuf: 
     Unparsed: Binary Large Object (178 Bytes)

  1. The MinVersion field indicates the minimum supported client that will be accepted by Forefront TMG. If this field indicates “TMG compatible”, an ISA Firewall Client will not work. If this field indicates “Proxy 2 compatible, the TMGC will not work.

  2. The MaxVersion field indicates the maximum supported client that will be accepted by Forefront TMG. if this indicates “ISA Server compatible” the TMGC will work, but new commands added in Forefront TMG will not be used.

  3. The Authentication field indicates that Forefront TMG does not require authentication for this control channel.

    Note

    If any access rule requires authentication, this field will indicate “required”.

  4. The ServerEncryption field indicates whether Forefront TMG requires encryption on the RWS control channel. In this case, it does not require encryption because authentication is not required.

Extended Data

In frame 6, the TMGC communicates additional information about itself and the Winsock application to Forefront TMG. This specific message is part of the new command set created for Forefront TMG.

Note

If the Channel Setup response message indicates ISA Server as the MaxVersion, TMGC will not send this message, nor will it use the v12 command set introduced in Forefront TMG.

- RWS: Extended Data for cscript.exe as Administrator on winxp-pro running 5.7.0.18
  - RwstPacket: Extended Data for cscript.exe as Administrator on winxp-pro running 5.7.0.18
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 901 (0x385)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Extended Data
     DataLength: 620 (0x26C)
     ClientConnectionHandle: 0 (0x0)
     ServerConnectionHandle: 0 (0x0)
     ClientMappingHandle: 0 (0x0)
     ServerMappingHandle: 0 (0x0)
   - RwsMessage: for cscript.exe as Administrator on winxp-pro running 5.7.0.18
    - ExtendedData: for cscript.exe as Administrator on winxp-pro running 5.7.0.18
       Buffer: Binary Large Object (246 Bytes)
       SHA1: 8E34DBDC5FA9904CCD0D8F9ACC462ADBCF5ED474
       FileName: cscript.exe
       AppPath: C:\WINDOWS\system32\cscript.exe
       UserName: Administrator
       MachineFQDN: winxp-pro
       IsTrusted: True
       ProductName: Microsoft (R) Windows Script Host
       ProductVersion: 5.7.0.18 (5.7.0.18066)
       FileVersion: 5.7.0.18066
       OrgName: cscript.exe
       FwcVersion: 7.0.7733.100  x86

  1. The SHA1 field provides the SHA-1 hash calculated for the Winsock application executable. This field corresponds to the firewall log Client Application SHA1 Hash field.

  2. The FileName field provides the file name on disk for the Winsock application. This field corresponds to the file name part of the firewall log Client Agent field. When the Channel Setup messages are missing from the capture, the RWS parser uses this field to populate the RwsApp properties.

  3. The AppPath field provides the full path to the Winsock application. This field corresponds to the firewall log Client Application path field.

  4. The UserName field provides the name of the user running the Winsock application. This field corresponds to the firewall log Client Username field. When the Channel Setup messages are missing from the capture, the RWS parser uses this field to populate the RwsUser properties.

  5. The MachineFQDN field provides the fully-qualified domain name of the computer where the Winsock application is running. This field corresponds to the firewall log Client FQDN field. If the Channel Setup messages are missing from the capture, the RWS parser uses this field to populate the RwsHost properties.

  6. The IsTrusted field indicates whether the application is considered trusted. This field is intended for use in collaboration with Forefront Endpoint protection, but currently defaults to “True”. This field corresponds to the firewall log Client Application Trust State field.

  7. The ProductName field provides the product friendly name as might be seen in the properties of the application itself. This field corresponds to the firewall log Client Application product Name field.

  8. The ProductVersion field indicates the version associated with the Winsock application. This field corresponds to the firewall log Client Application Product Version field.

  9. The FileVersion field indicates the file version as applied in the Winsock application file properties. This field corresponds to the firewall log Client Application File Version field.

  10. The OrgName field indicates the application “original name” of the Winsock application as might be seen in the file properties dialog. This field corresponds to the firewall log Client Application Original File Name field.

  11. The FwcVersion field indicates the version of the TMGC operating on the client computer. This field corresponds to the firewall log Forefront TMG Client Version field.

Get host by name

In frame 8, the TMGC issues a Get host by name message for “isatools.org” to Forefront TMG. You may notice that this is the first RWS message that includes an RWS ID value (0x1, in this case).

- RWS: 0x1 Get host by name('isatools.org') from cscript.exe
  - RwstPacket: Get host by name('isatools.org') from cscript.exe
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Get host by name
     DataLength: 13 (0xD)
   + ClientConnectionHandle: 0x1
   + ServerConnectionHandle: 0x0
   + ClientMappingHandle: 0x0
   + ServerMappingHandle: 0x0
   - RwsMessage: ('isatools.org') from cscript.exe
    - Gxby: ('isatools.org') from cscript.exe
       HostName: isatools.org
       Padding: Binary Large Object (87 Bytes)
     - AppAndClientInfo: cscript.exe
        Application: cscript.exe
      + ClientInfo: - No detailed client information -

  1. The ClientConnectionHandle field provides a value to Forefront TMG to be used for managing RWS requests. This field also provides the primary source for the RwsId properties.

  2. The HostName field provides the host name that Forefront TMG should resolve to an IP address

  3. The Application field is found in almost every RWS message sent by the TMGC. If the RwsApp properties have not been populated from prior RWS messages, the RWS parser will populate them from this field.

  4. The ClientInfo structure is a holdover from the ISA Server version of the RWS protocol; this structure is not populated when the Extended Data message has been sent.

Note

When Forefront TMG receives this message, it will issue a Winsock getaddrinfo(hostname) call. The format of “hostname” and the name resolution configuration applied to the Forefront TMG computer will determine the results of this call.

Host Entry

In frame 11, Forefront TMG responds to the TMGC with the results of the attempt to resolve “isatools.org” to an IP address. In this case, the resulting DNS query produced two IP addresses.

- RWS: 0x1 Host entry response to cscript.exe for 'isatools.org'
  - RwstPacket: Host entry response to cscript.exe for 'isatools.org'
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Host entry
     DataLength: 56 (0x38)
   + ClientConnectionHandle: 0x1
   + ServerConnectionHandle: 0x0
   + ClientMappingHandle: 0x0
   + ServerMappingHandle: 0x0
   - RwsMessage: response to cscript.exe for 'isatools.org'
    - HOSTENTRY: 
       offHostName: 16 (0x10)
       offAliasList: 32 (0x20)
       AddrType: IPv4
       Length: 4 (0x4)
       offAddrlist: 36 (0x24)
       RealHostName: isatools.org
     + Aliases: 0 entries
     - Addresses: 2 entries
        offAddr: 48 (0x30)
        offAddr: 52 (0x34)
        offAddrEnd: 0 (0x0)
      - Address: 
         Address: 216.249.33.234
         Address: 71.164.21.26
       Padding: Binary Large Object (44 Bytes)
     - AppAndClientInfo: cscript.exe
        Application: cscript.exe
      + ClientInfo: - No detailed client information -

  1. The ClientConnectionHandle field value corresponds to the value provided by the TMGC in the Get host by name request. This allows the TMGC and Forefront TMG to manage message mapping.

  2. The HOSTENTRY response from Forefront TMG is a serialized form of a Winsock HostEnt struct. You can read more about this struct at the link provided in the References section

  3. The AddrType field indicates what IP version is represented by the addresses in the HostEnt structure.

  4. The RealHostName field will contain a value different from the name used in the Get host by name request if the original name represents an alias or CNAME record. In that case, this field will contain the primary A record representing associated with the alias.

  5. The Aliases structure will include any aliases (CNAME records) that are associated with the name specified in the Get host by name request.

  6. The Addresses structure includes any IP addresses that are associated with the requested name record.

Note

In general, a network client application will use the first address if the response includes more than one, but because this depends on how the application was designed and built, there is no guarantee of this behavior.

Connect v12 Request

In frame 13, the TMGC issues a Connect v12 request to Forefront TMG indicating that the Winsock application want to establish a connection to the Web server at 216.249.33.234.

- RwstPacket: Connect v12 request from cscript.exe to 216.249.33.234/80; client will send from 10.10.255.129/1163
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Connect v12
     DataLength: 0 (0x0)
   + ClientConnectionHandle: 0x10002
   + ServerConnectionHandle: 0x0
   + ClientMappingHandle: 0x0
   + ServerMappingHandle: 0x0
   - RwsMessage: request from cscript.exe to 216.249.33.234/80; client will send from 10.10.255.129/1163
    - Connect12Data: request from cscript.exe to 216.249.33.234/80; client will send from 10.10.255.129/1163
     - ConnectEndpoint: 216.249.33.234/80
      - Socket: 216.249.33.234/80
         Family: IPv4
         Port: 80 (0x50)
         Addr: 216.249.33.234
         Padding: Binary Large Object (8 Bytes)
        Padding: Binary Large Object (12 Bytes)
     - ClientEndpoint: Dynamic/1163
      - Socket: Dynamic/1163
         Family: IPv4
         Port: 1163 (0x48B)
         Addr: 0.0.0.0
         Padding: Binary Large Object (8 Bytes)
        Padding: Binary Large Object (12 Bytes)
       Padding: Binary Large Object (44 Bytes)
     - AppAndClientInfo: cscript.exe
        Application: cscript.exe
      + ClientInfo: - No detailed client information -

  1. The ClientConnectionHandle field provides the data that the RWS parser will pass to the WSP parser so that if this request is successful, the resulting WSP traffic can be associated with the RWS messages that created it.

  2. The ConnectEndpoint structure contains the IP version, IP address and port that Forefront TMG should use to establish the connection.

  3. The ClientEndpoint structure contains the IP version, IP address and port that the TMGC will use to send and receive data for the application if the connection is successful. When the IP address is 0.0.0.0, it means "assume the same IP address as used in this control channel”.

Connect Reply v12

In frame 14, Forefront TMG responds with a Connect Reply v12, indicating that Forefront TMG successfully connected to the specified destination and that the Winsock application may exchange data between itself and the remote host using the connection described by the ConnectEndpoint field specified in the Connect v12 request and the InternalEndpoint field specified in the Connect Reply v12 response.

- RWS: 0x10002 Connect Reply v12 to cscript.exe; using 10.10.255.129/1163 with 10.10.255.2/14103 == 131.107.8.2/80 with 216.249.33.234/80
  - RwstPacket: Connect Reply v12 to cscript.exe; using 10.10.255.129/1163 with 10.10.255.2/14103 == 131.107.8.2/80 with 216.249.33.234/80
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Connect Reply v12
     DataLength: 0 (0x0)
   + ClientConnectionHandle: 0x10002
   + ServerConnectionHandle: 0x10199
   + ClientMappingHandle: 0x0
   + ServerMappingHandle: 0x0
   - RwsMessage: to cscript.exe; using 10.10.255.129/1163 with 10.10.255.2/14103 == 131.107.8.2/80 with 216.249.33.234/80
    - Connect12Reply: to cscript.exe; using 10.10.255.129/1163 with 10.10.255.2/14103 == 131.107.8.2/80 with 216.249.33.234/80
     - InternalEndpoint: 10.10.255.2/14103
      - Socket: 10.10.255.2/14103
         Family: IPv4
         Port: 14103 (0x3717)
         Addr: 10.10.255.2
         Padding: Binary Large Object (8 Bytes)
        Padding: Binary Large Object (12 Bytes)
     - ExternalEndpoint: 131.107.8.2/80
      - Socket: 131.107.8.2/80
         Family: IPv4
         Port: 80 (0x50)
         Addr: 131.107.8.2
         Padding: Binary Large Object (8 Bytes)
        Padding: Binary Large Object (12 Bytes)
       Padding: Binary Large Object (44 Bytes)
     - AppAndClientInfo: cscript.exe
        Application: cscript.exe
      + ClientInfo: - No detailed client information -

  1. The ClientConnectionHandle field value matches the value used in the original Connect v12 request so that the TMGC knows which application action this response is for.

  2. The ServerConnectionHandle field provides the Forefront TMG mapping for this connection. The TMGC is expected to include this value when it sends other RWS messages related to this connection.

  3. The InternalEndpoint field provides the IP version, IP address and port at Forefront TMG for the TMGC to use when establishing the application data channel.

  4. The ExternalEndpoint field provides the IP version, IP address and port data that the TMGC should provide if the application issues a Winsock getsockname() call.

Set Socket Option

In frame 18, TMGC sends a Set socket option message to Forefront TMG. Like the Host Entry message, the data provided in this message represents a serialized Winsock structure.

- RWS: 0x10002 Set socket option enable 'Receive OOB data in normal stream'
  - RwstPacket: Set socket option enable 'Receive OOB data in normal stream'
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Set socket option
     DataLength: 0 (0x0)
   + ClientConnectionHandle: 0x10002
   + ServerConnectionHandle: 0x10199
   + ClientMappingHandle: 0x0
   + ServerMappingHandle: 0x0
   - RwsMessage: enable 'Receive OOB data in normal stream'
    - SockOptData: enable 'Receive OOB data in normal stream'
       Level: Act on TCP protocol
       OptName: Receive OOB data in normal stream
       OptLen: 1024 (0x400)
       SetValue: TRUE
       Buffer: Binary Large Object (31 Bytes)
     Unparsed: Binary Large Object (202 Bytes)

  1. The ClientConnectionHandle and ServerConnectionHandle fields provide a logical association with the application data connection that will be established between the TMGC computer and the Forefront TMG computer.

  2. The SockOptData structure represents a serialized form of a Winsock SockOpt structure. The specific option being set in this example tells Winsock that any data received in an Out-Of-Band context is to be passed in the normal data stream. You can read more about this socket option in the link provided in the References section.

More Questions, More Answers

We have other questions about this communication that need to be answered, such as:

  1. How was the name “isatools.org” resolved?

  2. How do we know that the HTTP content wasn’t delivered from the Forefront TMG cache?

  3. If the display filter stipulates “rws or wsp”, why don’t we see the WSP protocol in the display?

To answer these questions, we need to refine our display filter and look beyond the frame summary data.

How was the name “isatools.org” resolved?

Essentially, what we want to discover is the mechanism that was used to translate the name “isatools.org” to the IP address Forefront TMG provided to TMGC. Because we know DNS is normally used to resolve Internet names, the simplest way to determine this is to add “dns” to the display filter as shown below:

DNS added to the display filter

Figure 2 - DNS added to the display filter

The resulting frames tell you that the Forefront TMG computer (not Forefront TMG itself) issued a DNS query in frame 9 for the name “isatools.org” to the DNS server at 4.2.2.2, which responded in frame 10 with two IP addresses; 216.249.33.234 and 71.164.21.26. You can also see that a reverse query was performed in frames 20 and 23 for IP address 216.249.33.234. This is likely the result of Forefront TMG asking Windows for this information. Forefront TMG does this to ensure that the IP address does not match a rule that might reject the request based on a name other than “isatools.org”.

Note

If Forefront TMG had resolved this name prior taking this network capture, the DNS traffic would only be seen if the Forefront TMG DNS cache and Windows DNS cache records Time-To-Live (TTL) had expired.

How do we know that the HTTP content wasn’t just delivered from the Forefront TMG cache?

In order to determine this, we need to see if we captured any traffic from the Web server operating at IP address 216.249.33.234. To accomplish this, we’ll expand the display filter to include that IP address as shown below:

Web server IP address added

Figure 3 - Web server IP Address added

Now the frame summary includes HTTP traffic passing between the Forefront TMG external IP address (131.107.8.2) and the Web server (216.249.33.234). Thus, we can determine that Forefront TMG at least asked the Web server about this request. In order to determine whether the response Forefront TMG sent to the TMGC came from cache, we need only examine the HTTP response from the Web server in frame 28. The status code is “200: Ok”, which means “here is what you asked for”.

If the display filter stipulates “rws or wsp”, why don’t we see the WSP protocol in the display?

For simplicity, the frame summary window only displays the highest-order protocol. In order to find the WSP protocol, we need to look beyond the frame summary into the frame details for the HTTP response traffic between Forefront TMG and the TMGC computer. When we select frame 37 (HTTP “200: Ok” response from Forefront TMG), the frame details window displays the protocols related to this packet in the order they’re used.

WSP protocol details

Figure 4 - WSP protocol details

From the lowest-layer protocol to the highest, Network Monitor 3.3 tells us that this frame represents Ethernet, IPv4, TCP, WSP and HTTP. You may also have noticed the connection details provided by the WSP parser.

WSP: 0x10002; 216.249.33.234/80 --> 131.107.8.2/80 and 10.10.255.2/14103 --> 10.10.255.129/1163 for cscript.exe as Administrator on winxp-pro

This statement describes the relationship between the two connections:

  • The RWS identifier is 0x10002 (can be used in a display filter as Conversation.RwsId==0x10002 or Property.RwsId==0x10002)

  • The Winsock application is “cscript.exe” (can be used in a display filter as Conversation.RwsApp==“cscript.exe” or Property.RwsApp==“cscript.exe”)

  • The Winsock user is “Administrator” (can be used in a display filter as “Conversation.RwsUser==“administrator” or Property.RwsUser==“administrator”)

  • The TMGC computer is “winxp-pro” (can be used in a display filter as Conversation.RwsHost==“winxp-pro” or Property.RwsHost==“winxp-pro”)

  • The packet is coming from the Web server to the TMGC computer through the Forefront TMG computer

  • Traffic between the Web server and Forefront TMG passes through 216.249.33.234:80 and 131.107.8.2:80

    Note

    Forefront TMG didn’t really use port 80 for its local port in the connection to the Web server. This is a side effect of Web proxy handling of the TMGC traffic.

  • Traffic between Forefront TMG and the TMGC passes through 10.10.255.2:14103 and 10.10.255.129:1163.

    The WSP parser knows all of this because the RWS parser gathered this information as it processed the RWS packets in frames 4, 5, 6, 8, 11, 13, 14 & 18.

Neato Toys to Play With

Just for the fun of it, let’s play with one of the RWS conversation properties in a display filter. The first one I’ll use is Conversation.RwsApp==“cscript.exe” because it’s the kewlest one, if I may say so m’self. When we enter that filter criteria in the display filter window and hit CTRL-Enter (or click Apply), the frame summary window changes to include all of the packets related to the RWS or WSP traffic between TMGC and Forefront TMG for “cscript.exe”.

RWS application filter display

Figure 5 - RWS application display filter

We can see the TCP setup packets for the RWS control channel in frames 1 through 3 as well as the TCP application channel connection setup between Forefront TMG and TMGC in frames 15 through 17, as well as all of the ACK frames interspersed throughout the conversation and finally, both TCP connection resets from the TMGC to Forefront TMG in frames 44 and 45. The reason I like this conversation property so much (thanx for the suggestion, Congyong!) is that it combines all of the RWS and WSP traffic for a specific application. This is very useful when you’re trying to wade through a large capture from a computer with multiple connections and applications.

Another property that can help you is Conversation.RwsId. When you have an application that creates many connections, it’s frequently useful to be able to isolate one connection from another in the display. Because all four of the RWS conversation and frame properties are derived from RWS message data, you can associate the WSP packets with the specific RWS messages that spawned them. For instance, we can see in the WSP frame we examined that the ID is 0x10002. We can use this to associate the WSP traffic we’re examining with the relevant RWS messages. The following figure demonstrates the results of that combination.

RWS ID display filter

Figure 6 - RWS ID display filter

Notice that the frame summary window displays all of the packets related to the WSP traffic, but only the RWS messages that are specific to the particulars of the WSP conversation. Although the RWS channel setup and name lookup messages are certainly a prerequisite for establishing the WSP connection, they do nothing to help define the WSP conversation itself as do the Connectv12 request and reply messages. Also, you won’t see TCP management frames for the RWS conversation using this filter because a single RWS conversation can include multiple RWS ID numbers (recall that the GetHostByName request/response used RWSID 0x01000). This means that although the RWSID property is unique for an entire WSP conversation, it’s unique in RWS only for a single packet. Thus, in order to associate the RWS messages with the WSP conversation, the display filter has to include Property.RwsId==0x10002 as well as Conversation.RwsId==0x10002.

Remember; there are four properties created by the RWS parser that are designed specifically to help you isolate problem areas in TMGC –related traffic:

Property Name Description

Conversation.RwsApp

The name of the Winsock application, such as ftp.exe.

Ff536096.note(en-us,TechNet.10).gifNote:
This field is limited to16 characters.

Conversation.RwsHost

The name of the computer where TMGC is operating, such as “jimsbox”.

Conversation.RwsId

A binary value derived from the RWS Client Connection Handle value

Conversation.RwsUser

The name of the account used to run the Winsock application

You should spend some time gathering captures at your Forefront TMG server and use these properties to help you understand the results of using each one or combinations of them.

Deny Rule Action

In this example, the client attempts to make a connection to isatools.org using destination port 81. Forefront TMG has no rule that allows this traffic (implicit deny action) or it does have a rule that denies it (explicit deny action). These two states are functionally identical from the TMGC perspective, because it never knows why the connection can’t be made; only that it failed in some form.

The capture used for this example is linked in the Tools and Techniques section. Figure 7 illustrates the process that would be observed when TMG rules do not allow the traffic described by the RWS message.

Rule rejection

Figure 7 - Rule rejection

The capture frame summary indicated in Figure 7 illustrates the results of running http_test.wsf and specifying, TMGC issued two Connect v12 requests to 216.249.33.234 on port 81 in frame 12 and to 71.164.21.26 on port 81 in frame 15.

Note

You may have noticed that the client attempts to use both of the IP addresses provided in the Host entry response from Forefront TMG in frame 10. This client behavior is what DNS Round-robin load-balancing depends on in order to function.

Because TMG has no access rules that would allow a connection using TCP port 81, it denies this request and responds to TMGC with a Winsock 10061 error code, which means “connection refused” (a link to Winsock error codes is provided in References). Normally, Winsock responds to the calling application with 10061 when the destination actively refused the connection by responding to the TCP SYN with a TCP RST. Because we do not see any traffic between TMG and the requested destinations, we may surmise that this connection refusal is rule-based. Of course, you should verify this by reviewing the Forefront TMG logs.

The contents of the error response for RwsId 0x10003 in frame 16 are outlined below:

- RWS: 0x10003 Error to cscript.exe for Connect v12(71.164.21.26); (10061); Connection refused
  - RwstPacket: Error to cscript.exe for Connect v12(71.164.21.26); (10061); Connection refused
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Error
     DataLength: 0 (0x0)
   + ClientConnectionHandle: 0x10003
   + ServerConnectionHandle: 0x0
   + ClientMappingHandle: 0x0
   + ServerMappingHandle: 0x0
   - RwsMessage: to cscript.exe for Connect v12(71.164.21.26); (10061); Connection refused
    - ErrorData: to cscript.exe for Connect v12(71.164.21.26); (10061); Connection refused
       PrivateCode: TRUE
       OpCode: Connect v12
       ErrorCode: (10061); Connection refused
       SvrAddr: 71.164.21.26
       Padding: Binary Large Object (20 Bytes)
     - ClientEndpoint: 10.10.255.129/1173
      - Socket: 10.10.255.129/1173
         Family: IPv4
         Port: 1173 (0x495)
         Addr: 10.10.255.129
         Padding: Binary Large Object (8 Bytes)
        Padding: Binary Large Object (12 Bytes)
       Padding: Binary Large Object (44 Bytes)
     - AppAndClientInfo: cscript.exe
        Application: cscript.exe
      + ClientInfo: - No detailed client information -

  1. The first OpCode value informs TMGC that Forefront TMG encountered an error while trying to serve a request. The remaining data in this message provides the information TMGC needs to associate this response to the proper application and request.

  2. The ClientConnectionHandle value allows TMGC to map the error response back to the specific application Winsock call that should receive this response.

  3. The OpCode field in the ErrorData struct tells TMGC which command failed; in this case, it was the Connect v12 message associated with ClientConnectionHandle value 0x10003.

  4. The ErrorCode field provides the Winsock error that TMGC should deliver to the Winsock application.

  5. The SvrAddr field provides the remote IP address that is associated with the Connect v12 request that produced this error.

  6. The ClientEndpoint struct describes the client end of the application data connection that the TMGC would have used if the Connect v12 request had succeeded. This reminds the TMGC that it should release the socket associated with this connection.

TMGC forwards this error state back to the Winsock application and closes all sockets related to this connection request. It’s up to the application to manage any retry attempts.

Name Resolution Failure

In this example, the gethostbyname request will fail. As with any name lookup, the failure response is dependent on the actual failure state; such as “valid name but not found”, “name found but no record of the requested type”, “server error”, etc. In this example, I’ll make http_test ask for a connection to https://nogood.isatools.org because I know this destination is based on a valid domain, but the hostname requested doesn’t exist. Figure 8 illustrates the conversation summary.

Name lookup failure

Figure 8 - Name lookup failure

In frame 8, TMGC issues a gethostbyname request for nogood.isatools.org on behalf of cscript.exe. In frame 9, TMG issues a host name lookup to the DNS server at 4.2.2.2 and in frame 10, the DNS server responds with “name error” and finally, TMG responds to TMGS in frame 11 with an RWS error message.

If I select frame 10 in the frame summary window, the frame details window provides the following information:

- Dns: QueryId = 0x96F9, QUERY (Standard query), Response - Name Error 
    QueryIdentifier: 38649 (0x96F9)
  - Flags:  Response, Opcode - QUERY (Standard query), RD, RA, Rcode - Name Error
     QR:                (1...............) Response
     Opcode:            (.0000...........) QUERY (Standard query) 0
     AA:                (.....0..........) Not authoritative
     TC:                (......0.........) Not truncated
     RD:                (.......1........) Recursion desired
     RA:                (........1.......) Recursive query support available
     Zero:              (.........0......) 0
     AuthenticatedData: (..........0.....) Not AuthenticatedData
     CheckingDisabled:  (...........0....) Not CheckingDisabled
     Rcode:             (............0011) Name Error 3
    QuestionCount: 1 (0x1)
    AnswerCount: 0 (0x0)
    NameServerCount: 1 (0x1)
    AdditionalCount: 0 (0x0)
  + QRecord: nogood.isatools.org of type Host Addr on class Internet
  + AuthorityRecord: isatools.org of type SOA on class Internet: PrimaryNameServer: ns1.jalojash.org, AuthorativeMailbox: jim.jalojash.org

The DNS RCODE value is defined in RFC 5395 (linked in References). Because Forefront TMG was unable to resolve this name to an IP address, it responds to TMGC with the Winsock error code (11001) it received, which indicates “host not found”. TMGC passes this response back to the Winsock application.

Because the name lookup failed for “nogood.isatools.org”, no further communication between the TMGC and Forefront TMG is expected or seen.

Connection Failure

In this example, name resolution will succeed, and the Forefront TMG rules allow the request, but the connection attempt fails due to a network problem upstream between the TMG computer and the destination host. Actually, the remote runs Forefront TMG and blocks connections on TCP port 81, but the net effect is the same as an unresponsive listener at the remote host.

Connection failure

Figure 9 - Connection failure

The display filter I used in Figure 9 is conversation.rwsapp==“cscript.exe”. What we can determine from the resulting capture display are three things:

  1. The control channel was successfully established and negotiated (frames 1-7).

  2. Forefront TMG successfully resolved “isatools.org” to at least one IP address (frames 8, 11).

  3. TMGC issued two separate Connect v12 requests; one for each of the IP addresses returned in the Host Ent response (frame 11); both of which produced a Connect v12 reply from Forefront TMG (frames 13-14 and 22-23).

Even though the control channel traffic flow seems normal, no WSP traffic is seen in the frame summary. In order to understand why this is so, we need to examine the results of the Connect v12 replies so that we can adjust our view of the conversation properly. If we select frame 14 and examine the frame details window, we can see that Forefront TMG created a server handle for this connection and provided the remainder of the connection details to TMGC.

- RWS: 0x10002 Connect Reply v12 to cscript.exe; using 10.10.255.129/1543 with 10.10.255.2/11477 == 131.107.8.2/11476 with 71.164.21.26/81
  - RwstPacket: Connect Reply v12 to cscript.exe; using 10.10.255.129/1543 with 10.10.255.2/11477 == 131.107.8.2/11476 with 71.164.21.26/81
     NullChar: 0 (0x0)
     ProtoSig: RWS
     PktLen: 281 (0x119)
     Reserved1: 0 (0x0)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
     OpCode: Connect Reply v12
     DataLength: 0 (0x0)
   + ClientConnectionHandle: 0x10002
   + ServerConnectionHandle: 0x200048
   + ClientMappingHandle: 0x0
   + ServerMappingHandle: 0x0
   - RwsMessage: to cscript.exe; using 10.10.255.129/1543 with 10.10.255.2/11477 == 131.107.8.2/11476 with 71.164.21.26/81
    - Connect12Reply: to cscript.exe; using 10.10.255.129/1543 with 10.10.255.2/11477 == 131.107.8.2/11476 with 71.164.21.26/81
     + InternalEndpoint: 10.10.255.2/11477
     + ExternalEndpoint: 131.107.8.2/11476
       Padding: Binary Large Object (44 Bytes)
     - AppAndClientInfo: cscript.exe
        Application: cscript.exe
      + ClientInfo: - No detailed client information -

The InternalEndpoint field contains the interesting data point for us in this effort because it defines the side of the application data connection that is owned by Forefront TMG. Because we know that the TMGC should connect to Forefront TMG on this IP address and port and because we know that Forefront TMG should try to connect to the remote server on TCP port 81, we can adjust our display filter as conversation.rwsapp=="cscript.exe" or tcp.port==11477 or tcp.port==81. When we do this in Figure 10, we see that TMGC did indeed try to establish this connection, but as we see no SYN-ACK response packets, it’s clear that the remote server is not responding (or something in between is blocking) and thus Forefront TMG is not able to respond to the TMGC attempts to establish the application data channel.

Unanswered connections

Figure 10 - Unanswered connections

Frames 15, 18 and 21 clearly indicate that Forefront TMG is attempting to establish a connection to 71.164.21.26 on port 81, but no SYN-ACK frames are displayed. Consequently, the SYN packets sent from TMGC to port 11477 on Forefront TMG fail to elicit any SYN_ACK frames from Forefront TMG and the attempt to establish the application data connection fails.

Although you can’t see it in the screenshot, the TMGC application receives a Winsock 10060 (connection timeout) error from TMGC. When this occurs, the application executes a retry using 216.249.33.234 (the alternate IP address) in frames 22 and 23, which also fails in an identical manner. If the remote server had responded with a TCP RST packet, Forefront TMG would have responded in kind to TMGC and the application would have received a Winsock 10061 (connection refused) error from TMGC.

Summary

I discussed and illustrated the RWS and WSP protocol behavior for success and two failure states for single-connection TCP traffic using HTTP as the application protocol. Part 3 of this series (the final installment) addresses single-connection UDP traffic using DNS as the application protocol.

Tools and Techniques

References