Troubleshooting the network error: "(tcp_error) - A communication error occurred. "Operation timed out"

Products

• ProxySG Software - SGOS
• ISG Proxy

Issue/Introduction

Troubleshooting the network error: "(tcp_error) - A communication error occurred. "Operation timed out" 

Resolution

To troubleshoot the "Network (tcp_error) - A communication error occurred. "Operation timed out"" error messages, a proxy policy trace and PCAP (packet capture) for the failed web request would need to be collected and investigated. An example output can be reviewed in continuation:

From the above capture, we can determine that the client machine request failed, via frames 1421 & 1422, to return valid or correct authentication credentials to the Edge SWG (formerly ProxySG), hence the FIN, ACK seen in frame 1422. This behavior changes in the subsequent frames that follow. See the snippet below.

From the capture above, we see that the TCP sessions eventually completed successfully and the CONNECT request to the Edge SWG (formerly ProxySG) can be seen in frame 1494 and the TLS communication begins with the "Client Hello" in frame 1497. However, the Edge SWG (formerly ProxySG) appliance does not receive a "Server Hello" from the X.43.205.2 destination host. Investigating the possible cause of the lack of response from the OCS (X.43.205.2), for the TLS communication to happen resulted in the following finding:

The above unending TCP Retransmissions provide valid proof of the lack of "Network (tcp_error)" communication errors previously received when access to the same URL was tested from our lab environment, with SSL Interception and authentication enabled in policy (see snippet below).

TCP Retransmission

The TCP retransmission mechanism ensures that data is reliably sent from end to end. If retransmissions are detected in a TCP connection, it is logical to assume that packet loss has occurred on the network somewhere between client and server. In this case, the Edge SWG (formerly ProxySG) appliance is the client, while the OCS is the server.

To resolve this web access challenge, we recommend to have your network/firewall team investigate and allow access to the X.43.205.2 destination host and that should be tested from the firewall and from within the Edge SWG (formerly ProxySG) appliance, using the "traceroute" CLI command. For this, you may need to allow ICMP on the firewall, for the appliance, temporarily. Once the retransmission is resolved and the OCS can send the Server Hello, we expect that this access would be restored.

Additional Information

TCP retransmissions usually indicate that a network conflict (packet loss for example) is being experienced. 

The way it works: 

1. Requests from the sender are sent to the receiver 
2. The receiver acknowledges the received data. 
3. If a packet is lost for any reason it is retransmitted by the sender. 

Possible causes of retransmissions include but are not limited to: 

• Full Duplex / Half Duplex mismatch (configuration of the network card and switch interfaces) 
  
  • The server transmits data with a high speed (e.g. 1 GBit) and the receiver is connected with a lower speed (e.g. 100 MBit). Drops occur if the receiver is signaling a large TCP window size, found in the TCP header. 
• One of your routers is configured with a quality of service rule that enforces a certain the bandwidth 
• A broken cable offers very poor signal quality 
• A wireless network is busy or suffers from interference 
• OCS related conflicts