First of all it depends very much on the type of proxy. Routers are proxies for IP, there are email proxies, socks proxies and web proxies etc etc. Given the situation I'm guessing it's a web proxy. A Kaseya agent does not communicate using HTTP, it uses encrypted TCP/IP packets, and as such a web proxy will not be able to 'transport' this kind of traffic. So in short there is no way to get Kaseya agent traffic to run through a web proxy. The discussions on the web mentioning proxy support in Kaseya refer to a hidden setting that we have that will allow the agents to use a proxy to download files (for things like patch management), it is not used for agents to check-in.
Often if machines are using a web proxy they don't in fact have an internet connection, it is only the browser on the machine that connects to the web proxy, and the web proxy is the device with an internet connection. This is the most important factor, as for the agent on each machine to connect to the IP address (via DNS of course) each machine needs to establish an outbound TCP/IP connection all the way back to the address of the Kaseya server. If the machines aren't able to make a routable path to the internet, thats never going to happen.
So if the machines are configured to have no default gateway and using something like Microsoft ISA server, there may be a way to create some IP rule based exception on the firewall. If the machines do have a default gateway and can reach a router, but just have all the outbound ports blocked, then it's just as simple as setting up a firewall rule to allow port 5721 out from machines back to the address of your Kaseya server. All inbound traffic can remained blocked as the Kaseya server never makes a connection back to the Agents, so from that point of view the impact on security in negligible.