CEM client machines are unable to connect to the Gateway: An existing connection was forcibly closed by the remote host. (0x80072746)
Article ID: 172424
Updated On:
Products
Issue/Introduction
The customer noticed that his Cloud-Enabled Management (aka CEM) client machines stopped communicating after some changes in his network settings. While running a Wireshark capture, Wireshark doesn't show that the request is actually making it to the gateway and no responses back from it.
On those client machines, the following messages (all or a combination of them) can be found on the Agent logs:
Error 1: "The Local Security Authority Cannot Be Contacted" (Error 0x80090304)"
Error 2: “An existing connection was forcibly closed by the remote host. (0x80072746)”
Error 3: "The certificate chain was issued by an authority that is not trusted. (0x80090325)"
Error 4: "Request 'HTTPS://YourSMP.yourdomain.net:443/altiris/NS/Agent/ConnectionTest.asp' failed, COM error: No error description available (0x800701F7).
Configure Server Mode: Failed to receive server version from 'YourSMP.yourdomain.net'
Error 1:
Operation 'CEM: Connect' failed.
Protocol: HTTPS
Error type: TLS Handshake error
Error code: The Local Security Authority Cannot Be Contacted" (Error 0x80090304)
Error note: SocketIOStrategySyncSelect::Send error
Error 2:
Operation 'CEM: Connect' failed.
Protocol: HTTPS
Error type: TLS Handshake error
Error code: An existing connection was forcibly closed by the remote host. (0x80072746)
Error note: The connection was closed by the server during TLS handshake, check the System Event Log on the server for SCHANNEL errors
Error 3:
Operation 'CEM: Connect' failed.
Protocol: HTTPS
Error type: TLS Handshake error
Error code: The certificate chain was issued by an authority that is not trusted (0x80090325)
Error note: '<FQDN>' server's certificate is not valid, thumbprint mismatch
Error 4:
COM error: No error description available (0x800701F7)
Environment
ITMS 8.1 RU7 and later
Cause
The customer was using SSL offloading which caused to replace our gateway certificate with their own certificate (no supported) and that the Gateway external name was published in the internet, but disabled in the Firewall.
Other causes are available.
SSL offloading is the process of removing the SSL-based encryption from incoming traffic to relieve a web server of the processing burden of decrypting and/or encrypting traffic sent via SSL. The processing is offloaded to a separate device designed specifically for SSL acceleration or SSL termination.
SSL termination is particularly useful when used with clusters of SSL VPNs, because it greatly increases the number of connections a cluster can handle.
Note:
In some other instance, we found that there were two NAT rules with the same IP address that pointed to two different servers.
Resolution
We don't support SSL offloading. Please refer to 150683 "Is SSL offloading supported by ITMS?"
Check that there are no issues accessing the gateway externally. See 164782 in case you have issues with SSL offloading that could be causing changes or replacements on the expected certificates.
As well make sure that your firewall is allowing (publishing) the gateway its external name and also enabled to allow access.
Another issue was seen where the Gateway certificate was 3072 bits or other non-standard option. When recreating certificates, it is recommended to use the same features in the new certificate.
Note:
In some cases, look for entries like:
The client and server cannot communicate, because they do not possess a common algorithm
If those happen around the time the client machine is trying to register to a Task Server, verify that the same TLS version is used. KB 162386 "The client and server cannot communicate. TLS version mismatch"
Feedback
