We are using a Cisco VPN Portal as our Security Gateway in this situation.
Details on IPsec tunnels from Cisco here:
IPsec provides secure tunnels between two peers, such as two routers. You define which packets are considered sensitive and should be sent through these secure tunnels, and you define the parameters which should be used to protect these sensitive packets, by specifying characteristics of these tunnels. Then, when the IPsec peer sees such a sensitive packet, it sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer.
Multiple IPsec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of security associations. For example, some data streams might be just authenticated while other data streams must both be encrypted and authenticated.
IP-based data is vulnerable to hackers' tampering and eavesdropping. IP's strength is that it has small, manageable packets of electronic information that can be routed quickly and easily. These chunks of information create breaks in the data stream that allow them to be transmitted efficiently through the network.
Sounds like chunk is another word for IP Packet with Cisco flair added to it. Thus I imagine what the Connection Server is trying to tell us is that the tunnel from the Security Gateway has been shutdown for one reason or another. This suggests either something from the Cisco appliance or the users network connection is dropping prematurely.
I tried to reproduce these error messages with some connection testing. It appeared that the same errors were generated when I removed the internet connection from a test laptop instead of properly disconnecting from the View Client or the VPN portal. It wasn't always consistent, sometimes I received errors about the stream dropping too.
I wonder if there is anything else we can do on this on from our side of the equation. Our users are spread out all over the nation yet it seems that only certain pools of users experience these chunk/stream/tunnel related issues.
Chunks in this log context are just discrete blocks of data being sent through the View HTTPS tunneling protocol to the connection server and aren't related to Cisco's terminology. As you've seen, you can reproduce these when a client tunnel connection is lost - along with other possible error messages depending on what was being decoded when the tunnel ran out of data.
It won't be related to the desktop pool, since the tunnel goes only between the client device and the security/connection server [CS] but will definitely be linked to the users being externally connected as that will have a large impact on the network quality between client and CS.
Ultimately, you would really only see these messages if the TCP connection between client and server is being broken (this could be caused by physical loss of connection, some issues with the wrapping Ciso IPSec tunnel you mention you're using, general flakiness in user internet connectivity, etc), so you're going to want to look at an affected TCP connection itself from your router logs and see if there's TCP retransmits, packet loss etc.
Thanks for the info. Your post suggests that we cannot configure around this problem from the VMware View environment itself. These are disconnection error messages and need to be addressed on the infrastructure level between the Client and the CS.
> so you're going to want to look at an affected TCP connection itself from your router logs and see if there's TCP retransmits, packet loss etc.
I was afraid it was going to come to this. Since our impacted end users are external vendors access to their personal network equipment and physical machines is going to be difficult. Ideally when packet sniffing you want to have both client and server logs to compare and isolate where the problems are occurring. Logging from the Security Server [SS?] in our situation isn't very easy to do since its a Cisco appliance and doesn't have persistent logging enabled at the moment. We might have to explore more traditional packet tracing such as Wireshark to collect more info. Still, since I can reproduce these errors with my own connection testing we might be able to rig up something and review before coordinating logging efforts on their side of the equation.