Windows 10 21H1 won't connect to R80.40 SMS

[cosmos]

I've just built a fresh R80.40 management server with HFA take 94, to replicate a customer issue.

To run the fat client I'm running Windows 10 21H1. I have the latest SmartConsole build installed, and get the following error on connection to the manager:

An error occurred while making the HTTP request to https://<server>:19009/cpmws/LoginSvcRemote?wsdl . This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.

Following sk169253 scenario 1 I can confirm the client machine indeed supports the ciphers:

PS C:\Users\admin> get-TlsCipherSuite | findstr "ECDHE_RSA_WITH_AES_128_GCM_SHA256"
Name         : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Following scenario 2, I found multiple certs on the manager and followed the instructions to revoke/recreate. Issue still occurs.

Scenario 3 doesn't apply - the client sends a TLS 1.2 hello and gets a TCP RST from the SMS.

I've rebuilt the SMS several times now, thinking of rolling HFA take 118 but I don't see this specific issue as fixed.

Has anyone else seen this?

[PhoneBoy]

If you haven’t opened a TAC case it might be a good idea to do so.
Wonder if debugging cpm might explain what’s going on: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[genisis__]

Its probably worth going to JHFA118, TAC will very likely ask if your running the latest GA release, additionally are you running the latest SmartConsole build.

Run SCConfigManager.exe > enable option 3 > replicate issue > disable option 3, take the logs and send to TAC as well.  This may also help them.

by any chance have you locked down the ciphers/TLS versions to use on the SMS? 

[cosmos]

I couldn't replicate the issue in a clean lab with 21H1 and R80.40 directly connected. After some digging we found another vendor's firewall in the service chain blocking the connection even though the rule was any/any, apparently due to an application enforcement (https not allowed on tcp/19009).

How embarrassing!

Thanks for your help guys.

[genisis__]

Main thing is that the issue is resolved!

[yogeshtaneja]

how did this resolved i am also facing the same

[Chris_Atkinson]

As above traffic was allowed on an intermediary firewall.