djmundyDon't forget to open up port 53 for DNS, both TCP and UDP. You probably only need to open this up for your server.
wodgerIs this bit something to do with kaseya at the client side?
Our firewall has detected UDP requests for Kaseya on ports 5722, 5733, 5737 and 5763 as well. We've given access to 5721 over UDP, and that has worked until the latest release of the LiveConnect xpi. Now Firefox won't LiveConnect, yet Chrome and IE will.
We also noticed that the videochat functionality uses some UDP ports on the client side.
It needs connection to UDP ports 10000 10001 and 1935.
These are used for the Real Time Media Flow Protocol which enables peer to peer communication between multiple adobe flash players.
(http://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol)Legacy Forum Name: General Discussion, Legacy Posted By Username: cyberling
This is an old post, but I think its worth bumping due to new revisions with Kaseya. Please see the below article for reference.
From what I can tell 5721 is used for agent check ins, but actual remote control goes out using TCP/UDP 3478. If you're like me, you are locking down the firewall for security, or using a UTM device like Cyberoam to authenticate user traffic, problem is DNS and Kaseya traffic is not authenticated, so you have to create rules to allow that traffic to pass through the firewall without authenticating.
Lan to Wan - Allow DNS to any destination address
Lan to Wan - Allow Kaseya 5721 and 3478 to any destination address
5722 is used by KBU (acronis) if you use the offsite replication function.
I'd take this a few steps further.
TCP/UDP 3478 only needs to be allowed out to stun.kaseya.com. This is the STUN server that KRC uses to allow it to negotiate P2P connections when behind NAT firewalls. helpdesk.kaseya.com/.../100428703-Troubleshooting-KRC-connection-failure
Outbound TCP 5721 should only be allowed to your VSA's primary and secondary check-in IP addresses (or hostnames if your firewall supports this).
Outbound DNS should only be allowed to your preferred reputable name servers (e.g. OpenDNS, Google public DNS, possibly your ISPs DNS servers) to prevent anything on your LAN from potentially accessing malicious or compromised DNS servers.
Hope this helps.
So thats why KRC works so badly, first connection needs to go over continents and over seas.
We're in Australia (i.e. significant latency to the USA) and our experience is that KRC connects fairly quickly, so I don't believe the initial STUN negotiation should be causing KRC to work badly. Have you reviewed the KRC log files (%localappdata%\Kaseya\Log\Kaseya Remote Control)?
In our particular case we have the firewall locked down so that P2P connections fail (they negotiate via STUN OK but choose some random port over 40,000 which isn't allowed out) and even then the failback to a relayed connection only takes a second or two.
Well for us its pretty much roulette if KRC connects at all, if it connects its usually freezes randomly and may drop connection and then start saying that client is offline. May work again after 5-10mins. Should the stun.kaseya.com be mentioned in KRC logs (at admin machine)?