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
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 connectionT_ssl_policy_reject
: Total number of SSLV generated RST packets triggered by a reject rule
or an undecryptable
Total number of RST packets generated by an active IPS device