Client Install Error - x-bes-minimum-supported-relay-level

I’m trying to install a new 10.0.2.52 client on Debian 10. I downloaded the deb file from source (https://software.bigfix.com/download/bes/100/BESAgent-10.0.2.52-debian6.amd64.deb), installed it and the client gives this error but then fails to register.

At 18:30:25 +0000 - 
   RegisterOnce: Relay does not support secure registration.
   RegisterOnce: Current deployment 'x-bes-minimum-supported-relay-level' masthead setting does not allow clear text registration.
At 18:32:25 +0000 - 
   Beginning Relay Select

Masthead: lines:

x-bes-minimum-supported-client-level: 9.0
x-bes-minimum-supported-relay-level: 9.5.6

Top of client log file:


Current Date: April 30, 2021
   Client version 10.0.2.52 built for Debian 6 amd64 running on sysname:Linux release:4.19.0-16-cloud-amd64 arch:x86_64
   Current Balance Settings: Use CPU: True Entitlement: 0 WorkIdle: 10 SleepIdle: 480
   Locale: LC_ALL="" LC_CTYPE="" LC_MESSAGES="" LANG="C.UTF-8"

I don’t have secure registration enabled and the relay version it is trying to reach via the masthead url is 10.0.2.52. I’ve used this same actionsite.afxm on all my other installs without issue, but this is the first for Debian.
Any suggestions?

Where I’ve seen that before, it’s always been a layer-4 firewall or proxy in the middle that allows HTTP traffic but not HTTPS traffic on tcp/52311.

And every time we get to the point of narrowing it down…whoever posted the message asking says “All good now, it’s fixed” and doesn’t tell me how :slight_smile:

From a browser on that machine, test connection to the Relay and to the Root Server via both HTTP and HTTPS

http://relay-fqdn:52311/masthead/masthead.afxm
https://relay-fqdn:52311/masthead/masthead.afxm

http://root-server-fqdn:52311/masthead/masthead.afxm
https://root-server-fqdn:52311/masthead/masthead.afxm

Each of those should present a copy of your deployment’s Masthead File. Please let me know whether they all do, or which ones don’t and we can troubleshoot from there.

our masthead url points to a fake root relay on v10, but these are the results trying to reach it. It does seem like a connectivity issue at layer 4 because telnet/wget connect but don’t get any data. I’ll have to investigate further.

wget http://relayurl:52311/masthead.afxm
--2021-04-30 19:07:45--  http://relayurl:52311/masthead.afxm
Resolving relayurl (relayurl)... x.x.x.x
Connecting to relayurl (relayurl)|x.x.x.x|:52311... connected.
HTTP request sent, awaiting response... No data received.
Retrying.
--2021-04-30 19:08:46--  (try: 2) http://relayurl:52311/masthead.afxm
Connecting to relayurl (relayurl)|x.x.x.x|:52311... connected.
HTTP request sent, awaiting response... No data received.
Retrying.
--2021-04-30 19:09:48--  (try: 3)  http://relayurl:52311/masthead.afxm
Connecting to relayurl (relayurl)|x.x.x.x|:52311... connected.




wget https://relayurl:52311/masthead.afxm
--2021-04-30 19:10:50-- https://relayurl:52311/masthead.afxm
Resolving relayurl (relayurl)... x.x.x.x
Connecting to relayurl (relayurl)|x.x.x.x|:52311... connected.

GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.

I agree it could be something in layer 4, but when you get back to testing, I think your URL needs a bit of tweaking as well - it’s /masthead/masthead.afxm, not /masthead.afxm that we need to retrieve.

The message about “TLS connection was non-properly terminated” is an example of exactly what a Layer-4 firewall would do, and makes it difficult to troubleshoot for the application owner.

The firewall will allow the TCP SYN/ACK/SYN-ACK on port 52311 , and then as soon as the Layer-4 firewall detects that the traffic is the (disallowed) HTTPS instead of the (allowed) HTTP, the firewall sends a TCP RESET to both the client and server on the connection, and blocks any further traffic. The client and server, if they log anything, would log “Connection reset by peer”.

In our case we had an asymmetric routing issue and after fixing that, the client could download successfully register with its relay.

1 Like

Thanks for updating!

I know this is an old topic but it was usefull, i had the same problem and the problem was HTTPS traffic on tcp/52311 blocked.

thanks

1 Like