Access Control with IP Restriction

The access control page allows an Owner to manage the web console access and Splashtop On-Prem client access with IP restriction.

Step 1

Log into Gateway's management console as Owner, go to System > Access Control.

Splashtop currently supports IP restriction on the access to Gateway web console or On-Prem client app.

Filled up the allowed IP addresses into IP range list. The IP syntax should be in CIDR. 

Step 2

In addition, owner can choose different display methods for web console access denied.

Step 3

Enable IP access restrictions for Splashtop On-Prem Client or Web Console so that access generated from IP sources excluded from the list will be blocked. 

Click Save button to save the settings and turn on the feature.

Note:

Currently, failed access attempts due to web console access control are not logged in the web console but instead recorded in the debug logs. This approach is based on both security and design considerations, particularly for system-level activity that occurs before any authentication or authorization takes place.

Reasons:

1. Security Against DDoS and Brute-Force Attacks:

   • One of the reasons for limiting such logs to the debug logs is to mitigate potential DDoS or brute-force attack risks:
     • These failed attempts could represent malicious activity (e.g., repeated access attempts from different IPs).
     • Logging them in the web console could expose a large volume of irrelevant or sensitive data, making the system vulnerable to log flooding during a Distributed Denial-of-Service (DDoS) attack.
     • By handling these logs in debug mode, we reduce the visibility of such activity to attackers while enabling administrators to monitor and investigate in a secure, controlled environment.

2. No Authorization or Account Context:

   • Since these failed attempts occur before login, they are tied only to the originating IP address rather than any specific account or authorization process. Including them in the web console, which is designed for organization-level activity, could lead to misinterpretation or irrelevant data for users, as there’s no account context or actionable insight.

3. Security and Operational Performance:

   • Logging high-volume, low-value events like failed access attempts in the web console could introduce performance risks during high-traffic scenarios, such as a DDoS attack. By offloading these logs to the debug logs, we maintain the web console’s performance and ensure sensitive security data is safeguarded.

​