I’m seeking some guidance regarding an issue with our recent BigFix setup. Here’s the situation:
We’ve implemented an internet-facing relay, meaning it has a public DNS that can be reached by any computer worldwide. However, instead of placing the relay in a DMZ, it’s hosted in Azure. The child relay communicates with its parent relay over public IP addresses — both the child and parent relays have public IPs and are communicating in this manner.
To enhance security, I’ve set up authentication and configured a password that clients must use to connect. However, I noticed that anyone, whether inside or outside our organization, can execute a simple telnet relaydns.company.com 52311 and connect to the relay’s port. Is this behavior expected? Shouldn’t there be some sort of access restriction, or am I missing something in my configuration?
Additionally, when clients attempt to register with the relay, they encounter the following logs:
Has anyone experienced a similar issue with secure registration failure or open ports like this in a public-facing relay setup? Any suggestions on how to tighten security while maintaining proper communication between relays would be highly appreciated. Also, can I be sure that computers over the internet will only attempt to register using https?
However, simply connecting to the relay’s port using telnet does not imply full access or control over the relay or the BigFix environment. When you set up authentication and a password for client connections, it secures the actual data exchange, ensuring only authorized clients can register and communicate securely.
yes, relay configured to authenticate agents only performs SSL communication with child agents or relays that present an SSL certificate issued and are signed by the server during a key exchange.
You should coordinate with your network/firewall team to see whether any hidden URLs are being blocked, which could ultimately lead to a breakdown in communication.
Open case with HCL support for deep investigation.
Currently, I am observing that computers without the “_BESClient_SecureRegistration” setting, located on the internal network, are automatically selecting our internet-facing relay (relaydns.company.com). This behavior seems incorrect to me, as they should not be able to connect to this relay without the required password. Is my understanding correct?
My intention is for only laptops used by employees working remotely (hybrid workers) to connect to the internet-facing relay. For this reason, I have applied the “_BESClient_SecureRegistration” setting exclusively to laptops. However, I am noticing that servers and desktop machines are also able to connect to the relay, despite not having the password set.
This is incorrect. The password is only used if a client has never communicated with ANY BigFix relay ever before. Only for first time initial client registration. After the first registration, then clients get a unique certificate that is used to authenticate that client with any relay going forward without the need for that password. Effectively that password is never used again after the very first registration.
That is generally the intent behind having a DMZ relay, but you can affect the order of preference of relays by using relay affiliation groups and other settings to affect relay selection. The password is NOT such a setting.
