While setting Deny action in Content Filter rules, the Kerio Control is not sending TCP RST (reset) packet.
It is causing the browser to be stuck in "Establishing secure connection" or "Connecting" for 30 seconds, then just timing out with TCP.
This article provides detailed explanations on how Kerio Control handles Deny actions depending on the version installed.
In version 9.3.2 and later, Kerio Control sends TCP reset packet to end the connection to the remote site. In the meantime, the client still re-transmits and eventually times out. This is because Kerio Control only sends TCP RST to the receiving socket, but not to the sending socket. In other words, Kerio Control does not end the connection on the client-side.
IP addresses in this example:
- web client connected to Kerio Control: 10.10.10.250
- archive.org: 184.108.40.206
- Kerio Control WAN interface: 192.168.1.105
Kerio Control has already sent the RST packet to archive.org
Simultaneously the web client is still waiting for a response from Kerio Control to RST (reset) the connection. It waits for ~30 seconds before timing out.
In version 9.3.1 and prior, Kerio Control does not send TCP reset to the remote site (receiving socket), but re-transmits packets. However, the connection is already ended by the client itself (sending socket). This is not the correct behavior, since KC (Snort library in this case) should be responsible for dropping packets and ending connections.
Just after loading the page, the connection is instantly reset
The same is captured via packet analyzer
Enabling HTTPS filtering decryption allows the DENY rule to reset the connection to the client instantaneously.