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
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'
OpCode: Host entry
- RwsMessage: response to iexplore.exe for 'www.contoso.com'
- HOSTENTRY:
ReqHostName: www.contoso.com
Size: 0 (0x0)
offHostName: X
offAliasList: X
AddrType: IPv4
Length: X
offAddrlist: X
RealHostName: xyz.abc.com
+ Aliases: 3 entries
- Addresses: 3 entries
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
OpCode: New Connect
- 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
ClientPort: 3225 (0xC99)
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
OpCode: Connect reply
- 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
+ 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.