Network users experience problems with Internet. Sometimes the webpage can't be opened or audio can't be played, at other times customer experience a long wait time while the content loads.
For example, the following is a packet capture on the PC on which the audio file request is sent. We can see the audio file request and the TCP retransmission for this request. There is no response for the requests.
The TCP handshake packets received on the ProxySG are as follows. The TCP connection is successfully established.
The request for the audio file on the ProxySG is seen below. We don't see the audio request, but some Reset packets sent from Client IP address.
Why did the ProxySG receive Reset packets instead of the original request?
Below we compare a packet capture on the PC and another on the ProxySG, to understand what causes the problem.
To understand this issue begin with checking the MAC address of the packets between the PC and ProxySG. When the TCP handshake occurs, you can see the Source MAC address is Cisco_56:07:c2 (00:26:52:56:07:c2), which is a Cisco Switch with a Cisco MAC address.
But in the TCP Reset packet, see the Source MAC address is NexcomIn_1c:cc:61 (00:10:f3:1c:cc:61). This does not match the original MAC address (the Cisco Switch) that established the session.
Check if there is a security device between the ProxySG and the switch on the same subnet as the ProxySG that uses the MAC address specified above ( from Nexcom International Co.) It is security false positive.
In the customer's network environment, there could be many other security devices from other vendors. From the ProxySG's side, if we can't see the as same request as which is sent from PC, then we should check other upstream network/security devices in the network path.
After the issue is uncovered, you can reconfigure the security settings or bypass the security monitoring on ProxySG for third party devices to resolve these types of problems.