We know that a firewall client first connects to ISA server on firewall client control channel which is created between any TCP ephumeral port on the firewall client machine and tcp port 1745 on the ISA server. In this post I will demonstrate using Network traces how data channel is negotiated and in case firewall client machine does not go by the negotiated agreement and try to create data channel using different ports what would happen.

In this post firewall client machine is trying to go to www.contoso.com. . After the initial TCP handshake on the control channel firewall client would send following

Client request

 Frame: Number = X, Captured Frame Length = X, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[XX-XX-XX-XX-XX-XX],SourceAddress:[XX-XX-XX-XX-XX-XX]

+ Ipv4: Src = 192.168.0.14, Dest = 192.168.0.1, Next Protocol = TCP, Packet ID = X, Total IP Length = X

+ Tcp: Flags=...AP..., SrcPort=2314, DstPort=1745, PayloadLen=X, Seq=X - Y, Ack=X, Win=X

- RWS: 0x2 Get host by name('www.contoso.com') from iexplore.exe

  - RwstPacket: Get host by name('www.contoso.com') from iexplore.exe

     NullChar: X

     ProtoSig: RWS

     PktLen: X

     Reserved1: X

     Flags: X

     Reserved2: X

     OpCode: Get host by name

     DataLength: X

   + ClientConnectionHandle: X

   + ServerConnectionHandle: X

   + ClientMappingHandle: X

   + ServerMappingHandle: X

   - RwsMessage: ('www.contoso.com') from iexplore.exe

    - Gxby: ('www.contoso.com') from iexplore.exe

       HostName: www.contoso.com

       Padding: Binary Large Object (X Bytes)

     - AppAndClientInfo: iexplore.exe

        Application: iexplore.exe

      - ClientInfo: - No detailed client information -

         Size: X

         Padding: Binary Large Object (X Bytes)

Comments: Here client Sent the request to the ISA server on firewall control channel for www.contoso.com using its own port 2314.

Server reply

+ Tcp:  [Bad CheckSum]Flags=...AP..., SrcPort=1745, DstPort=2314, PayloadLen=393, Seq=Y - X, Ack=X, Win=X

- RWS: X Host entry response to iexplore.exe for 'www.contoso.com'

  - RwstPacket: Host entry response to iexplore.exe for 'www.contoso.com'

     NullChar: X

     ProtoSig: RWS

     PktLen: X

     Reserved1: X

     Flags: X

     Reserved2: X

     OpCode: Host entry

     DataLength: X

   + ClientConnectionHandle: X

   + ServerConnectionHandle: X

   + ClientMappingHandle: X

   + ServerMappingHandle: X

   - RwsMessage: response to iexplore.exe for 'www.contoso.com'

   - HOSTENTRY:

       ReqHostName: www.contoso.com

       Padding: Binary Large Object (X Bytes)

     - AppAndClientInfo: iexplore.exe

        Application: iexplore.exe

      - ClientInfo: - No detailed client information -

         Size: 0 (0x0)

         Padding: Binary Large Object (X Bytes)

       offHostName: X

       offAliasList: X

       AddrType: IPv4

       Length: X

       offAddrlist: X

       RealHostName: xyz.abc.com

     + Aliases: 3 entries

       Padding: Binary Large Object (X Bytes)

     - Addresses: 3 entries

        offAddr: X

        offAddr: X

        offAddrEnd: X

      - Address:

         Address: 2.3.4.5

         Address: 6.7.8.9

          Address: 12.13.14.15

Comments: ISA server after doing the name resolution for this client sends the list of available addresses for www.contoso.com.

Client's next response 

- RWS: X New Connect request from iexplore.exe to 2.3.4.5/80; client will send from 192.168.0.14/3225

  - RwstPacket: New Connect request from iexplore.exe to 2.3.4.5/80; client will send from 192.168.0.14/3225

     NullChar: X

     ProtoSig: RWS

     PktLen: X

     Reserved1: X

     Flags: X

     Reserved2: X

     OpCode: New Connect

     DataLength: X

   + ClientConnectionHandle: X

   + ServerConnectionHandle: X

   + ClientMappingHandle: X

   + ServerMappingHandle: X

   - RwsMessage: request from iexplore.exe to 2.3.4.5/80; client will send from 192.168.0.14/3225

    - ConnectData: request from iexplore.exe to 2.3.4.5/80; client will send from 192.168.0.14/3225

     - ConnectEndpoint: 2.3.4.5/80

        Family: IPv4

        Port: 80 (0x50)

        Addr: 2.3.4.5

        Padding: Binary Large Object (X Bytes)

       ClientPort: 3225 (0xC99)

       Padding: Binary Large Object (X Bytes)

     - AppAndClientInfo: iexplore.exe

        Application: iexplore.exe

      - ClientInfo: - No detailed client information -

         Size: X

         Padding: Binary Large Object (X Bytes)

Comment:  Client then tells ISA server that it would like to set up the data channel from its port 3225.

Server's response

- RWS: X Connect reply to iexplore.exe; using 192.168.0.14/3225 with 192.168.0.1/52122 == 16.17.18.19/80 with 2.3.4.5/80

  - RwstPacket: Connect reply to iexplore.exe; using 192.168.0.14/3225 with 192.168.0.1/52122 == 16.17.18.19/80 with 2.3.4.5/80

     NullChar: X

     ProtoSig: RWS

     PktLen: X

     Reserved1: X

     Flags: X

     Reserved2: X

     OpCode: Connect reply

     DataLength: X

   + ClientConnectionHandle: X

   + ServerConnectionHandle: X

   + ClientMappingHandle: X

   + ServerMappingHandle: X

   - RwsMessage: to iexplore.exe; using 192.168.0.14/3225 with 192.168.0.1/52122 == 16.17.18.19/80 with 2.3.4.5/80

    - ConnReplyData: to iexplore.exe; using 192.168.0.14/3225 with 192.168.0.1/52122 == 16.17.18.19/80 with 2.3.4.5/80

     + InternalEndpoint: 192.168.0.1/52122

     + ExternalEndpoint: 16.17.18.19/80

       Padding: Binary Large Object (X Bytes)

     + AppAndClientInfo: iexplore.exe

Comments: Server then tells the client that he would provide its port 52122 for the data channel in the traces we can also see how it defines the internal and external end points.

In scenarios where if client after telling the ISA server that it would set up the data channel at a certain port then tries to create dat channel at some other port then ISA server drops that traffic with error

ERROR:Failed to find session's connection

 and in ISA logs we will see FWE_TCP_NOT_SYN

 As ISA server expects data channel connection to be on 192.168.0.14/3225 with 192.168.0.1/52122

 So if client tries to make it using any other port ISA would consider it non syn(out of session) packet and Hence drop it.

Issue: Consider a scenario where ISA administrator wants to cache a particular website but he is not able to cache it. He has created rule to cache the rule. Everything about the rule and the caching is configured properly. However responses from the web server are not being cached by the ISA server.

Data collection to resolve the issue 

Took HTTPWatch trace while accessing the problem website on a client machine. You can check about httpwatch here http://www.httpwatch.com/

 Data analysis and Conclusion

Following is the snapshot( httpwatch) of the header for the request for that problem website

As we can see in the header received section (received from webserver) cache-control has value of no-cache, which means that web server is configured not to let the client or proxy server cache its responses due to which ISA server was not able to cache the responses from the web server. Another variation to cache-control value is shown below which would also not let proxy server to cache the web server responses.

so if you see such behaviour, please check the cache-contol value of the web server response and look for the values mentioned.