A discussion took place regarding the inbound and outbound connections in the new version 9.x. Some users reported issues with disconnected connections and concern was raised about the impact on the agents. Ultimately, it was suggested to allow client traffic to/from ControlUp’s AWS hosted services without firewall packet inspection for optimal communication. The agents have an escalating hold off pattern for reconnection attempts. It was also mentioned that the ControlUp URLs are hosted in Azure and there is an offline flow available as an alternative.
Read the entire ‘ControlUp v9.x Inbound/Outbound Connections: Issues and Solutions Shared’ thread below:
Version 9.x Inbound/Outbound connections question.
I’m trying to better understand the new version 9.x Inbound/Outbound connections. From the Monitor setting page, I can see the new Outbound connections.
In this case, there are quite a few that are Disconnected. Should this concern me? Do they disconnect and reconnect often?
Update: I opened a Support ticket and was told to ensure agent traffic (from clients) can connect to cu-agents-cpa.controlup.com &
cu-agents-cpa-us.controlup.com (US) My Palo Alto firewall shows no Denies, but yet I have only 7% connected clients. Maybe the connections are dropped by the firewall after a period of time, and the agent does not try to reconnect? I’m not sure.
I guess I’ll revert back to inbound only communication.
The audit log should show you connection issues. The agents will log it locally in the event log as well.
The agent does try to reconnect but it has an escalating hold off pattern. Depending on what the reason is that it couldn’t connect, that could be up to 1 hour.
In most cases the retry will be up to 5 minutes though.
This is great information. I appreciate the details.
Cc @member
Hi @member
@member already provided the details, it would be interesting to get feedback from your side, if agents are now able to connect via outbound
I’m still awaiting firewall approvals to allow client traffic to/from the AWS hosted services without packet inspection. Things take time in a HealthCare environment… I’ll update this thread next week. I’m fairly sure this will resolve it, as we have had many other AWS solutions fail because of this packet inspection. AWS sees it as a Man-in-the-middle attack, which it basically is, and drops the session. It’s been an issue for a couple years, and we fight the fight for all AWS hosted solutions.
You mean to allow the ControlUp urls? I think they’re hosted in azure if that matters.
Also, you don’t have to use those. There’s also an offline flow where you essentially put one or multiple monitors in the registry and it’ll just use those instead of the online services.
The URLs are already allowed, it’s the Palo Alto "decryption" that needs to be bypassed. We reverted back to the inbound for now, and are back up and running.
When we upgraded the ControlUP agents, they defaulted to Outbound. While reading the documentation prior to upgrading to 9.x, we assumed we had to manually switch the agent to outbound…but they all started failing immediately. As soon as we went into the Agent Settings in ControlUP Realtime Monitor and rebooted the Monitor servers, we were back up and running.
We will try the outbound communication next week. We are hoping it takes the load off the monitors, or reduces the Lag/Delay (60-70 minutes) in reporting.
Continue reading and comment on the thread ‘ControlUp v9.x Inbound/Outbound Connections: Issues and Solutions Shared’. Not a member? Join Here!
Categories: All Archives, ControlUp Real-Time DX