From my understanding Kaseya uses random ports from 1024 - 65535 for both inbound and outbound traffic from the client end. I have a client that has a Sonicwall TZ100. At the moment I have had to open all those ports for Kaseya to work and the client is wondering why they bothered spending the NZ$1000 approx on a firewall if it is open to the world. Is there some way to mitigate this issue or is Kaseya truely this lacking in security awareness?
Kaseya only uses a single outbound port for its monitoring, management and alerting - by default this is 5721
I agree with Peter's response. The crowd I work for uses SonicWALL's too and all we allow is 5721 and only to our Kaseya server's IP address. To make things even more complex we even have a SonicWALL at our office and its configured so that our Kaseya is not open to the world so you can't access the portal from the outside without a VPN connection.
+1, the initial connection for Kaseya is Outbound from your customer on port 5721. You'll see a random port used for the inbound response, but you don't need to open up those ports, that's what the intelligence of the firewall is suppose to handle.
Reading all your responses, I want to fully understand so that we are all on the same page.
Port 5721(TCP) needs to be opened on the FW for INBOUND connections where the K2 portal resides behind the FW.
So any agents out there on the internet, will need to connect to this 5721 port....
Am I missing anything else?
If you want to use Live Connect with the peer-to-peer feature you also need UDP/5721 open to the Kaseya VSA server. Same TCP and UDP ports outbound from any agents checking in if you clients have outbound restrictions on their firewalls (CheckPoint and others default to restricted outbound for all ports.
I agree. I have opened port 5721 Outbound, as well as Inbound with a One-to-One NAT to allow clients to check in with the KServer while away.
Since you mentioned you had to open 5721 outbound, does that mean you have all other ports closed? And you are manually specifying outbound ports for all services?
Yes, by default all ports are closed and we allow only what we need.
I'd like to add something about Live Connect and the NAT/Sonicwall issue. Even if you have all outbound ports allowed on the client side, Live Connect will still not work. I ran a packet capture and worked with support extensively on this. In the end they directed me to NAT and specifically symmetric NAT.
"Enable Consistent NAT" in the SIP settings on the sonicwall will help. It allows the random inbound port to work. Otherwise the firewall thinks it's not the same request and blocks it. Apparently SIP uses a similar method or something.
I enabled this on most of our sonicwalls and LC works through the peer to peer connection about 75% of the time now. We have all ports allowed out, but I think you would need 5721 TCP and UDP allowed out in addition to the consistent nat.
Thanks for your post. It sounds very confusing though, whether it's Sonicwall or K2, it seems to go against what I know about how TCP/UDP connections work. I'd like to try to understand this better if possible.
In your last sentence you mentioned that you have all ports allowed out. But need 5721/TCP/UDP in addition. But if your policy already is to allow all inside to out, I just don't understand why 5721 needs to be specified?
Also, what I don't understand is that source ports usually are random, with the destination port being 5721 at the destination. So even if you were to open all ports inside to outside, the K2 shouldn't be using 5721 as its source port, only as its destination. Unless this is the actual behavior of K2 agents??
So again, my apologies, just trying to better understand the behavior of K2 since we are also a Sonicwall shop so this thread comes in very handy.....
Your confusion in that was exactly what I was dealing with for so long. Sorry, let me try to explain.
First. We have all ports allowed out. No special rules at client sites. 5721 TCP and UDP at the kserver allowed in. Everything allowed out at the kserver, too. If you had a firewall rule blocking all outbound services, you would obviously need to open 5721 TCP, UDP, and possibly some other ports, too. I'm not sure what exactly.
Normally traffic would leave the kserver on a random port and leave the agent on a random port. The agent random port would connect to 5721 on the kserver.
If you run a packet capture on the sonicwall you'll see a packet blocked FROM 5721 on some unknown IP (kaseya corporate/STUN server). This is addressed TO a random port on the agent. the consistent NAT forces the agent to use the same random port on the outbound side so this STUN server can create the peer to peer connection from the live connect session to the agent. The live connect is a third-party in the mix and thus creates the need some authority to pass off the session from the kserver/agent to the agent/live connect.
Let me recap. Without consistent NAT, a packet is blocked FROM 5721 on an unknown IP to a random port on the agent. There is now way to create a rule for that. SIP also uses STUN, so the sonicwalls list consistent NAT under the SIP settings. If you enable consistent NAT is creates a predicable port on the outbound side so the STUN server can transition the connection to a peer to peer instead of relay.
Hope that was clear. By the way, after all this it does work better some of the time, but not all.
Ahhh....now I understand.....wow, that is very interesting, if that is the case, then Kaseya needs to have this documented as this behavior needs to be known!
I had no idea that liveconnect was some 3rd party in the mix so this makes sense. Thank god that you were using Sonicwall to discover this because I'd just simply say the LiveConnect was broken!!
We have been testing K2 internally only so the LC has worked flawlessly since we never had to traverse the firewall. But now this is something to test.
Also, you mentioned this doesn't always fix the issue. I'm assuming you are looking elsewhere for other possible solutions? Do the other locations that this doesn't work for use Sonicwall as well? Or are you implying that consistent NAT on Sonicwall doesn't always work, even on Sonicwalls?
We did say it was broken! After daily calls with Lenny from support for about 2 weeks, we were finally able to get to some sort of resolution. There is a hidden link to the P2P log. Alt-click to the left of Help in the upper right of the live connect window. That will tell you if you are connected P2P or relaying through kserver. You can definitely tell a difference.
I've still had some cases where certain sites don't connect P2P for some reason. I don't know if it's the firmware or other router involved or what exactly. It's definitely touchy.
Also, Kaseya has been TERRIBLE about getting the word out on this issue. Liveconnect was the complaint with everyone that I've heard, probably because it wasn't working correctly!
No other solution really. I'm not ready to jump ship from Sonicwall just because Kaseya remote control is slow.
Yea port 5721 is only port Kaseya uses. We're a Sonicwall Reseller so we have them at pretty much all of our customers ranging from TZ100 to Enterprise class E-5500. No problems connecting to Kaseya at all. We dont even have a NAT policy or Firewall rule added specifically for port 5721 nor for the port we use for the Offsite Replication. But we also have LAN > WAN firewall rule set to Any Any Any Allow which will allow all traffic outbound so no reason to add a specific rule unless you had it set to Any Any Any Deny. We only have NAT policy and firewall rule added on our Firewall thats in front of our Kaseya server to allow (LAN > WAN).
Some of our customers have 2 WAN connections setup on their Sonicwall, mostly for Redundacy. Some places we use that 2nd WAN for either all Kaseya traffic or just the offsite backup traffic. So we just set a route for LAN subnets to Any source for 5721 on interface X2 or whatever interface you want.
So what do you recomend for this - should we put a different firewall in front of our kserver - maybe a Cisco ASA or something?
I can't change the firewall at every single client - i'd sooner dump kaseya for a competing product before doing that.