I assume this happens because the Cluster cannot resolve the FQDN to the internal IP of the Cluster ActiveGate - so will the creation of a DNS record for the FQDN which then resolves to the internal IP address fix this issue? How does the test work, is it executed from the Cluster, or Mission Control? If the latter, the internal DNS entry won't help.
I need to get this working, else the SAP plugin won't work, as it tries to use the Cluster ActiveGate as the endpoint to send the beacon to. At this point, the data will try get to the public IP (that's what the FQDN resolves to) but can't due to firewall/proxy restrictions - also doesn't make sense sending the data out onto the web, then back in via Cluster AG.
Solved! Go to Solution.
Hello @Andre van der V.
You will have to open the port from Cluster ActiveGate to your local DNS Server/Entry.
The test actually is an HTTP request executed from the cluster node to check connectivity over specified endpoint.
Internal RUM actually does same - sends the data to that address. So it has to be resolvable from all places in your network.
We have achieved this exactly as the previous comments. It is a network/security issue internally on your infrastructure. There needs to be a path (and resolution) from the internal end to the external public endpoint.
Thanks everyone, that confirms my assumption that the FQDN needs to resolve internally (to the internal IP of the Cluster AG). Awaiting the client to get the necessary DNS records added...