We are encountering an issue with one client not reporting to the console.
Client log shows the following message. We tried to run besremove and reinstall the client, but it still does not report to the console and log file still shows the same message.
RegisterOnce: Relay does not support secure registration.
RegisterOnce: Registration backing off from SSL, attempting in clear text
Registration Server version 11.0.1.104 , Relay version 11.0.1.104
Relay does not require authentication.
Failed automatic client authentication key exchange with server message: SSL protocol not supported.
The client logs also shows that it is able to sync with sites.
Successful Synchronization with site âUpdates for Windows Applicationsâ (version 2105) - âhttp://sync.bigfix.com/cgi-bin/bfgather/updateswindowsappsâ
Successful Synchronization with site âUpdates for Windows Applications Extendedâ (version 128) - âhttp://sync.bigfix.com/cgi-bin/bfgather/updateforwinappextendâ
Successful Synchronization with site âVirtual Endpoint Managerâ (version 70) - âhttp://sync.bigfix.com/cgi-bin/bfgather/virtualendpointmanagerâ
Successful Synchronization with site âVulnerabilities to Windows Systemsâ (version 690) - âhttp://sync.bigfix.com/cgi-bin/bfgather/vulnwindowsâ
The relay where the client is reporting to already has the following setting
_BESRelay_Comm_Authenticating = 0
It appears that your client has a secure password in order to connect, and since client attempt to register with an authenticated relay but failed, you disabled relay authentication as a result.
However, registration is still not possible with authentication disabled.
Have you observed that the ComputerID remains the same even after removing and reinstalling?
Could you also confirm the results of this sql query? Just mention the computerID that you see in the logs of the problematic client before executing the query:
Select * from COMPUTER_REGISTRATIONS where ComputerID in (Mention_ComputerID_Here)
Select * from COMPUTER_CERTIFICATES where ComputerID in (Mention_ComputerID_Here)
Select * from COMPUTERS where ComputerID in (Mention_ComputerID_Here)
The relay authentication was never enabled and the value is always set to 0 even before the client reporting issue. The computer ID changed after the bes remove and reinstall of the client as per the old and new client logs.
What do you see, then, after executing those queries? Iâm attempting to determine whether your actions resemble those that we had previously due to a client certificate issue.
If not, thereâs a good chance that your networkâs ACL changes are to blame.
That article I believe is incorrect or at least incomplet or outdated, Iâll look in tog etting it fixed.
I may need to check my recollection, but I believe current versions will not perform registration over clear text.
I usually see this error when a layer-4 firewall is allowing traffic on tcp/52311, but is not specifically allowing https on 52311.
Hi @JasonWalker
Where do you recommend to check if the firewall is not allowing https on 52311? Is there like a cmd or powershell script that can be run?
No, Iâd recommend checking with your network team. Iâm not talking about Windows Firewall, Iâm talking about something more like a Palo Alto firewall (just as an example of a Layer-4 firewall) somewhere in the network path between the client and the server.
From a browser or Curl, you should be able to connect to the Relay on a url like
https://relay.local:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=Version
A âGoodâ result is getting back an text page showing the relay version.
An âOKâ result is getting back an HTTP 403:Forbidden message, which indicates the Relay has Relay Authentication turned on and wonât give you the page because you canât authenticate.
A âBadâ result is getting a timeout or Connection Reset message. A Connection Reset usually means a firewall or switch device is blocking the connection.
2 Likes
@JasonWalker
The relay url is accessible from a browser and returns the version
ClientRegister
Version 11.0.1.104
What version of BESClient is installed on the client side?
You should probably open a support ticket to get some live help and review the other logs & settings.
The client side has version 11.0.1.104 as well
@JasonWalker
Using TLSv1.3 returned the below error message.
While TLSv1.2 worked
Ok, that may be getting somewhere.
In the BESAdmin Tool, what do you have set up in the Security tab? Specifically Iâm interested in whether âRequire TLS 1.3â is specified.
My theory would be that your server is set to âRequire TLS 1.3â, which is supported on your level of client; but there may be a Layer-4 firewall in the path that is not properly handling the TLS 1.3.
The client was able to report after enabling TCP communication on port 52311. 
Would love to hear some more details on this.
When you say âEnable TCP on 52311â, do you mean thatâs a definition in a Layer-4 Firewall? Would you be willing to share the brand/maker of the firewall?
I assume that âHTTPâ and âHTTPSâ communication on 52311 were already allowed, since your Browser connection appeared to work; should we suppose then that your firewall does not recognize TLS 1.3 and, failing to categorize the traffic, failed back to a âgeneric TCPâ application and thus adding your âtcpâ rule unblocked it?
âŚand also, when you checked the BESAdmin tool, was TLS 1.3 set to Required on yours?
We just added a new rule on the OS level firewall that allowed TCP on port 52311.
TLS 1.3 was never enabled on our environment.
I think better messaging on the client logs would be really helpful in determining the issue for this kind of cases.
Something doesnât seem to be making sense there, if the OS firewall was blocking the traffic then your connection from the browser should not have worked, nor would you have gotten the error message about TLS ciphers when using curl. I suspect something else has changed while you were diagnosing this, perhaps more than one person or group were investigating.
Also the client logs shouldnât have shown successful sync messages.
What OS is the Relay running, and what commands did you use to open the firewall rules?
The relay is on Windows Server 2019. I forgot to mention previously that it is a DMZ relay, and command polling is enabled on the clients reporting to the relay.
netsh advfirewall firewall add rule name="Allow Outbound TCP Port 52311" dir=out action=allow protocol=TCP localport=52311
netsh advfirewall firewall add rule name="Allow Inbound TCP Port 52311" dir=in action=allow protocol=TCP localport=52311
Hm. I still have to think there was something going on in addition to this.
I would have expected that installing the Relay should have set up the Windows Firewall; and in any case, if Windows Firewall was doing the blocking you shouldnât have gotten a response earlier from the Browser or from Curl, and the log messages would have been different (would have timed-out rather than complained about SSL protocol).
Iâm happy itâs working for you now, but I donât think that the Windows Firewall alone fixed it, and Iâd be cautious that this could happen again next time you set up a new Relay if you arenât sure what change fixed it.
