When signing up to Kaseya, I went cloud based, but am wondering if the reason others here don't experience the problems i am having, because they are on premise? Do many here have the cloud based version?
Ive had the following in as tickets with no resolution and Kaseya have got back to me saying it's with engineers and they are fixing it.
Im thinking most people here are on premise and thus dont experience what I am experiencing and perhaps we need to look at migrating out of the cloud version and onto on premise, as the cloud based version has various bugs yet to be sorted out.
We are on Premise and running VSA 9.3. We have not experienced any delay for our agents and our Latency is 3ms-60ms normally through our wan.
We are also on premise and do not experience much latency. Not overly sure how the cloud application works but maybe your firewall is missing some exclusions?
We are on prem as cloud came out after our purchase (Kaseya was originally on prem only). We get 3ms latency internally and anything from 30 to 2000ms externally. Our k server is in a data centre externally and not actually on prem. the latency is largely a factor of the clients internet link - most clients are on adsl and have <1mb/s upload capacity.
The average latency is usually around 100-300ms and this is just tolerable.
Ok, seems I am the odd one out here. Although Craig has said he experiences up to 2000ms . That sort of latency is the norm for us and we are on the cloud based version.
On LAN connections we get between 4-10ms, as you would expect over LAN. But WAN is mostly between 600ms-1200ms. Every now and then we will get a bad one, with up to 6000ms, lol.
We have the obligatory port 5721 open for live connect to actually work and 3478 open on our core router for P2P to work . But going by the logs, it never uses P2P and instead uses a relay/proxy, which i think is the cause of the whole problem.
If a local proxy could be nominated, or more common ports used for the P2P negotiation, then the latency would probably be quicker.
Danny Vincent It depends on your proximity to the SaaS server. Seems like you have your port settings configured but your remote control sessions are still being relayed here. If you deploy SonicWall firewall, there is a specific setting for VoIP that will require enabling for P2P to work. If not, what other configuration would you have in place that would potentially stop a P2P connection from happening? Do both machines (viewer and agent) reach our STUN server? If we can figure this one out, your experience will be enhanced.
No, we use mainly Linux SHorewall and Mikrotiks routers/firewalls.
From one of my earlier tickets, it mentioned in the solution that only one end needed port 3478 to be open for a P2P negotiation to happen.
For sites across the WAN where we have our own router in place and possibly a VPN, the latency is good. But for sites where we have no control over the FW at the other end and ports they have allowed open, this is where the high latency is being experienced. We could never ensure that port 3478 is opened at every users site, as sometimes they might be at home for example.
The Kaseya help file says it only needs one side to have 3478 for P2P to work:
"at least one end of the connection (viewer or agent) can connect to stun.kaseya.com on port 3478 (TCP and UDP)"
But it appears, both sides need this port open for P2P to work, Otherwise it is relayed back to the USA and back to here in Australia adding considerable latency.
we have it running on a Hyper-V server in our datacenter we have 100MB fiber full Dup. We have close to 2,000 endpoints. the performance is good. we have the SQL server separate from the APP server although they are both on the Same Hyper-V host. We plan to get SSD Drives to increase performance although it almost does not need it. however this year we plan to increase our endpoints by at least another 1,000 so the SSD drives should be a good investment.
We are on prem, but still have latency/download issues when some of our technicians are connecting from other sites within our company. The problem in our case is due to the remote site reaching the Kaseya server through a very small VPN tunnel instead of just accessing it outside the network over the web. Haven't managed to get my internal IT teams to fix it, and the sad thing is if the guys just walked outside the building and hooked up to wifi at a coffee shop, they wouldn't have a problem. Essentially, it has something to do with how the DNS gets internally resolved. The benefit to our local site is if we enter our kaseya server https address, it resolves to the internal server than going over the internet, but it doesn't help our remote sites with small VPN tunnels.
Just wanted to point it out in case anyone else ran into this, it might be part of their problem.