Presently, the conditions under which SSL Visibility could reset an existing TCP session only apply when the SSL Visibility appliance is deployed in Active-Inline or Passive-Inline mode. Thus the device does not terminate connections prematurely in Passive-Tap mode.

 

The appliance generates TCP RST packet(s) in the following cases:

• When it receives a packet for a flow that triggers a Reject rule
• When an undecryptable policy under segment configuration is triggered (ie. presence of a client certificate)
• When there is an error in a flow that has been modified (where decrypt and re-encrypt action is being done) so that the remainder of the flow cannot be cut through. This might happen due to corrupt packet(s)
• When the attached active IPS device either drops some packet(s) or generates the RST itself on the SSLV generated TCP flow

When the SSL Visibility appliance determines that it must reject a TCP flow, it releases most of the state associated with that flow and considers the flow terminated. From that point on, the appliance will turn around any packets that it receives and determines to be a part of the original flow into RST packets and transmits them back to the sender.
If the SSL Visibility appliance rejects a flow then the appliance also tries to signal both endpoints of the connection about the termination by generating a spontaneous TCP RST for each endpoint of the connection. After the initial rejection, any subsequently received packets for the same flow will continue to trigger RSTs back to the sender.
There is one special case for a flow rejection triggered by a TCP SYN. In such a case, there is no server endpoint or state, so the SSL Visibility appliance only generates one spontaneous RST to send back to the SYN packet's source.

In the Active-Inline mode the attached inline appliance can also cause the SSL Visibility appliance to generate a reset in both directions on an SSL flow that is being inspected:

• If the inline appliance drops a packet from the SSLV generated TCP flow that is carrying the decrypted payload data then the SSL Visibility appliance will detect this ( Feedback Timeout expires ) and generate a RST in both directions on the original SSL flow in order to kill the flow
• If the active appliance generates a RST itself on the generated TCP flow then this will be detected by the SSL Visibility appliance, and will trigger a RST in each direction on the original SSL flow

The following are useful counters present in host_stats and ssl_stats statistics files whose progress over a period of an issue is worth checking:

T_tcp_reject: Total number of SSLV generated RST packets due to an error in a flow that has been modified (possibly a corrupt packet) or when SSLV was trying to fill the gaps in the TCP stream ( by sending its own early ACK packets to both ends of communication) to speed up packet delivery. When such a gap is not filled within a certain time window, such flow is rejected and SSLV sends TCP RST to both ends of the connection
T_ssl_policy_reject: Total number of SSLV generated RST packets triggered by a reject rule or an undecryptable policy match
T_ssl_ips_reject: Total number of RST packets generated by an active IPS device