Introduction
CloudSoda Agents run external to the CloudSoda Controller, but in order to function, they need to be able to connect to it. The most common issue of an Agent being disconnected is network-related. The sections below discuss common issues with connecting an Agent to the Controller and possible solutions.
Proxies
Proxies like Zscaler have default rules regarding redirecting and blocking outbound UDP traffic. We have tried a variety of workarounds to pass UDP traffic through Zscaler reliably to the CloudSoda Controller, but the only reliable method has been to permit UDP traffic to the CloudSoda Controller's address to bypass Zscaler.
Zscaler's model is to take traffic from the client and route it out through any one of hundreds of egress points on Zscaler's own network. To get around this, we can permit inbound UDP from any address, but the problem of Zscaler's unknown impact on UDP packets remains. This is why the cleanest method is for the client to permit this UDP traffic to bypass the Zscaler proxy. If this is not amenable to the organization, we can engage Zscaler's enterprise support for remediation.
Firewalls
Some organizations have default rules to permit web traffic bidirectionally, but default rules to block all other non-standard traffic. Commonly, our users have to make firewall exception requests to make sure the two standard UDP ports 7498 & 7499 are open bidirectionally, permitting egress as well as return traffic, on those ports.
In cases where organizations have multiple firewalls between the Agent runner and the CloudSoda Controller, ensure that the traffic is able to make it through every successive firewall, not just the one most proximal to the Agent.
Comments
0 comments
Please sign in to leave a comment.