FAQ – Remote Access

Automatos Remote Support (ARS) products initiate an outgoing connection therefore they work with your existing firewall and do not require special configuration. ARS products first try to connect using port 7615 and then if this fails they also try ports 80 and 443. In extremely rare cases, when a strict firewall is implemented on the remote computer and all of the mentioned ports are closed, ARS products won’t work until at least one of the mentioned ports is opened.

Port 7615 is the preferred choice and you can think of it as the standard port for Automatos Remote Support (ARS), just like 22 is SSH, 23 Telnet, 25 SMTP, 3389 RDP, etc.

Having a specific port is also very convenient. If your company has a specific security policy and uses a firewall or proxy, but you would like to allow ARS traffic, simply open port 7615 and all ARS products will work properly. If only ports 80 and 443 were used, it would be much more difficult for administrators to allow ARS traffic while restricting other traffic that also uses those ports.

In general, when working in a proxy environment, the first thing to consider is checking with your system or network administrator to determine whether it is possible to create an exception. This does not mean disabling the proxy entirely; instead, it means allowing ARS traffic to pass directly while continuing to filter all other traffic. If the proxy supports DNS name exceptions, allow a direct outgoing TCP connection on port 7615 to *.islonline.net. If the proxy supports only IP address exceptions, refer to the current list of server IP addresses.

In an ideal environment with direct connections and flexible security policies, the process would end here. However, many customers operate behind corporate firewalls or proxies where only HTTP and HTTPS traffic (ports 80 and/or 443) is permitted, and system or network administrators either cannot or do not want to create exceptions. To support these environments, ARS applications automatically attempt to establish a working connection by detecting proxy settings, using WinINet, creating tunnels, leveraging wildcard DNS, and applying other supported connection methods.

Environments with this type of filtering may experience additional delays, primarily due to transport timeouts during the connection establishment process. ARS products always attempt a direct connection through port 7615 first. If that attempt fails, they automatically try ports 80 and 443 using several proxy transport methods. Each transport method has a timeout of 7 seconds, and on Windows the application tests up to eight transport methods. As a result, if the successful method is the last one tested, the connection delay can approach one minute.

If a customer reports long connection delays, the recommended approach is to connect to the affected computer and use the Find Best Transport option in the connection testing utility. This tool displays all successful transport methods, along with their average transfer rates, latency, and other performance metrics. Based on these results, you can configure the application to use the optimal transport method, significantly reducing future connection times.

Our web pages fully support TLS 1.3, ensuring a secure browsing experience. However, our applications currently do not support TLS 1.3.

There are several ways to do this. A simple mouse move suspends the control for a few seconds. If this is not enough, you can click the Stop Sharing button on the ARS Client side or simply close the ARS application by pressing the Close button on the ARS application window.

A session is active while ARS is active. When ARS is closed, or when the session is closed by pressing the Disconnect from the session button, the session is no longer active.

The system keeps the basic session information (Host and Client computers’ IP addresses, chat transcript, amount of transferred data, etc.).

A session can also be automatically terminated after a specified period of user inactivity. Idle time is calculated from the last user action performed on the computer.

Yes, ARS reconnects to the server. It is almost the same as if you unplugged the network cable and then plugged it back in.

The ARS session continues running normally as soon as the internet connection is re-established.

ARS uses industry standard SSL/TLS encryption. You can be sure that your session is private — it is encrypted point to point — from the ARS Client to ARS.

Also, the Client must approve each action, meaning the remote user cannot take control of your computer without explicit permission. You do not need to change anything in your operating system settings.

The connection uses end-to-end SSL/TLS encryption. After the session is established, the traffic still goes over the server, but the server cannot read the data (everything is encrypted end-to-end). For added security, you also have the option of Server license, so you can install the server yourself.

If you do not filter outgoing connections, then you do not need to make any changes. However, if you do filter outgoing connections, please whitelist all connections to *.islonline.net, if your firewall allows DNS whitelisting. If you can only whitelist IP addresses, check the next question.

Please refer to this link for an up-to-date list of ARS server IP addresses. However, please keep in mind that the list of servers changes over time (new servers are added, old servers are decommissioned), so you should check the provided link regularly and update your firewall configuration accordingly.

Alternatively, an intermediary ARS forward proxy can be configured to minimize the number of firewall rules and reduce maintenance overhead.

You can add the ARS Client executable to a ZIP file (optionally password-protected) and place it on your website. You can also publish it on the customer’s intranet or even distribute it directly to such restricted computers.