Managing Access to VSA Web Interface


Kaseya recommends blocking public access to the VSA management console. However, there are some web interface components that need to be made publicly available in order to support common use cases: -

  • User Portal – a machine-specific web interface, authenticated via the Agent menu, allowing an end-user to interface with a ticketing system (VSA Service Desk or BMS).
  • Live Connect on Demand - provides access to temporary agent download packages for ad-hoc support requests.
  • Agent install packages - each package has a unique download link.
  • Endpoint APIs - installed agents need access to certain API routes using HTTP on port 5721.

We have previously recommended using URL Rewrite to control access to VSA through IIS and Firewall Rules (see step 4 of our On-Premises VSA Startup Readiness Guide - July 7th, 2021).

This document provides two options to allow access to the functionality listed above, whilst continuing to restrict access to the web interface.

Option 1 – Use URL Based Firewall Rules

Some advanced firewalls have URL-based filtering capability. If the firewall used to block access to VSA on port 443 has this capability, adding the following URL based exception rule will allow external users to access User Portal and Agent install packages (including LCoD): - 

  • Allow
  • Allow*
  • Allow*
  • Allow*
  • Allow*

Replace with the actual VSA server address. Refer to firewall documentation for correct formatting of the rule. 

Option 2 – Move Filtering Rules From External Firewall to VSA Edge Service 

Starting with VSA Release 9.5.7e, the VSA Edge service provides rule-based IP and HTTP filtering capable of blocking access by IP address and port with exceptions for specific client IP addresses and/or request URLs. Following the instructions below will provide access to User Portal and Agent install packages (including LCoD) from ANY location, whilst allowing management console access only from the local network and specified external IP addresses.

If this option is used, it is no longer necessary to use an external firewall or IIS Rewrite to control access to the management interface.
  1. Go to System > Server Management > Configure page and check that "Installed Patch Level" is or higher. If not, the remaining steps are not applicable and you must upgrade VSA to the latest version before proceeding.
  2. Download the attached file (link provided at end of this page) containing sample Edge Firewall configuration files (Firewall.config, Firewall-User.config) 
  3. Open firewall.config using a text editor. In the “FullInterfaceAccess” section starting at line 7, add the IP addresses for any networks which need to have access to the VSA management console. This would typically include the internal network and the addresses of any remote offices or home-workers. 
    • For internal networks, specify the IP range in CIDR format. 
    • For external networks, specify the public-facing IP address. mceclip0.png
  4. On the VSA server, make a copy of any existing Firewall.config and Firewall-User.config files in \kaseya\services folder and replace them with the files you have created in step 2. 
  5. In the same folder, make a backup copy of the existing KaseyaEdgeServices.config file, then open it using a text editor and add the following two lines (including commas) at the beginning of the “Application” section: -
      • "EnableHTTPFilter": true,
      • "EnableIPFilter": true, mceclip0.png
  6. After saving the change, open the Windows service manager (services.msc) and restart the “Kaseya Edge Services” service to apply the change. NOTE: connectivity to the server from agents and browser clients will be interrupted during the service restart. 
  7. Perform test 1 in the Testing section below - if you do NOT get the expected result, review the changes to firewall.config file and, if necessary, restore the backup copy of KaseyaEdgeServices.config and restart the “Kaseya Edge Services” service again to revert to the previous configuration. 
  8. Assuming test 1 was successful, remove the rule from the network firewall that blocks access to port 443. 
  9. Perform test 2 in the Testing section below - if you do NOT get the expected result, review the changes to firewall.config file and the network firewall. If necessary, revert VSA to the previous configuration as described in step 6 and reapply the network firewall rule that blocks port 443.


 These are the tests that should be performed, with expected results: - 

  1. From a “trusted” network (one that is listed in the “FullInterfaceAccess” section of firewall.config file), load a browser and attempt to access: 
    • - This should be SUCCEED and show the login page. This confirms that you can access the VSA Management Console. 
  2. From another network (one that is NOT listed in the “FullInterfaceAccess” section of firewall.config file), load a browser and attempt to access:
    • - This should FAIL to display the message “Access to was denied” - This confirms that public access to the VSA Management Console is blocked.
    • - This should be SUCCEED and show the message “This Session is invalid. Please relaunch the User Portal from your Agent icon in the notification area.” - This confirms that users will be able to access the User Portal.
    • - This should SUCCEED and display a page where LiveConnect on Demand code can be entered.
    • attempt to download an agent package using a link from Agent > Manage Packages page (e.g.  - this should SUCCEED and download KcsSetup.exe file.


The firewall configuration files have been set up to enable logging of all traffic through the Edge service. 

There are 3 keywords that you can use to search the log, which is in c:\ProgramData\Kaseya\Log\KaseyaEdgeServices\ 

BLOCKED and MATCHED have the same format: 
[ACTION]: [Rule Name] [Source IP address:port] [RequestType] [Resource] 

  1. “BLOCKED” - any traffic which Edge blocks, either due to IP or URL filtering rules. The rule that blocked the traffic will be displayed in the message, e.g., 
    BLOCKED: [Disable web access on 443] GET /login.asp 
  2.  “MATCHED” - any traffic that is allowed. The rule that allowed the traffic will be displayed in the message, e.g., 
    MATCHED: [Log Everything] GET /api/v1.0/infocenter/messages 
  3. “Firewall” - any changes made to the firewall configuration are recorded with this flag in the log, e.g., 
    [Firewall] Configuration change detected 


Have more questions?

Contact us

Was this article helpful?
2 out of 2 found this helpful

Provide feedback for the Documentation team!

Browse this section