Kaseya Community

Which ports to open on closed firewall

  • Hello there,

    Due to security issues we want to tighten down the firewall at one of our clients.
    Mainly we only want to allow http/https/mail traffic (mail only from servers)

    Which ports should be opened in addition to allow Kaseya to function properly?

    Regards,

    Gerwin

    Legacy Forum Name: Which ports to open on closed firewall,
    Legacy Posted By Username: gdekeijzer
  • port 5721 is all it needs

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: nviner
  • Ok, as in the port that Kaseya-server uses.

    And how does this affect remote control sessions? (RDP, VNC)

    Regards

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: gdekeijzer
  • You only need 5721 for the remote control stuff in Kaseya.

    Don't forget to open up port 53 for DNS, both TCP and UDP. You probably only need to open this up for your server.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: djmundy
  • Works like a charm Smile

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: gdekeijzer
  • djmundy
    Don't forget to open up port 53 for DNS, both TCP and UDP. You probably only need to open this up for your server.


    Is this bit something to do with kaseya at the client side?

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: wodger
  • wodger
    Is this bit something to do with kaseya at the client side?


    No, this is for name resolution. Eg. so you can go to http://www.google.com instead of http://150.101.98.211.

    Having said that, if your agent check in to eg. remote.yourcompany.com instead of your public IP address, then they will require DNS to resolve that.

    The rule of thumb is that if you are opening TCP ports 80 and 443 for internet browsing, you will also want to open TCP and UDP port 53 for DNS resolution.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: djmundy
  • This may be clear, but just to make sure.... you do not need to open any inbound ports on the firewall. If the firewall denied all inbound traffic, Kaseaya woudl still work fine, as all traffic through the kserver is initiated by the agent on the lan. The kserver does not reach out and communicate with any agents. All ktraffic is in response to traffic initiated by the agent.

    You only need to open outbound ports to allow machines inside the network to access the internet.

    Lloyd

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: lwolf
  • 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



    [edited by: Anonymous at 6:20 AM (GMT -7) on 4-28-2011] additional information
  • 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

    help.kaseya.com/.../index.asp

  • 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.



    clarified
    [edited by: Combo at 7:15 PM (GMT -7) on Aug 20, 2015]
  • 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)?



    fix typos
    [edited by: Tomi at 6:43 AM (GMT -7) on Sep 10, 2015]