Troubleshooting Connection Issues

Introduction

In this article, we’ll show you several ways to diagnose and resolve connection issues with Remote Desktop. We’ll also show you how to troubleshoot connection issues with MSSQL Server 2022.

Prerequisites

• creoline JTL-Wawi Server or a comparable Windows server

Checking the Connection

First, check whether the server is generally accessible from the device you are using to connect.

To do this, you’ll need a terminal or similar application on your device.

Below are some operating system-specific examples:

Windows:

• CMD
• PowerShell
• Windows Terminal

macOS:

• Terminal
• iTerm

Linux (Debian / Ubuntu):

• Terminal

Simple Connectivity Test

Use the following command in your terminal application to perform a basic connectivity test. In this example, the IP address of the Google DNS server is used for demonstration purposes:

ping 8.8.8.8

Interpreting the Output:

Server is reachable:

If the following is displayed after executing the command, the server can be reached from your device without any issues (the output may vary depending on the operating system and terminal application used):

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=21.739 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=21.340 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=19.072 ms

Server is unreachable:

If the following is displayed after executing the command, the server cannot be reached from your device (the output may vary depending on the operating system and terminal application used):

PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

In this case, proceed to the following section, Advanced Reachability Check.

Advanced Reachability Check

Use the following command in your terminal application (macOS and Linux) to check the entire route and the intermediate connection points. In this example, the IP address of the Google DNS server is used for demonstration purposes:

traceroute 8.8.8.8

On Windows, use the following command instead:

tracert 8.8.8.8

Interpreting the Output:

When interpreting the output in this case, keep in mind that not all nodes along the route will respond to your device’s request and provide information. The key factor here is that the final node—which represents your server—responds.

Server is reachable:

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40-byte packets
 1  Example Hostname Node (Example IP)  17.842 ms  16.522 ms  17.553 ms
 2  Example IP Address Connection Point (Example IP)  36.907 ms  19.010 ms  19.705 ms
 3  ae20.gate.fra1.de.creoline.net (5.1.73.2)  45.955 ms  28.927 ms  22.389 ms
 4  ae20.gate.fra1.de.creoline.net (80.77.17.168)  32,168 ms  19,266 ms  26,508 ms
 5  ae1.300.mx204.fra4.meerfarbig.net (80.77.16.119)  19,882 ms  18,680 ms  24,096 ms
 6  * * *
 7  * * *
 8  dns.google (8.8.8.8)  20.520 ms  26.773 ms  19.494 ms

Server is unreachable:

 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40-byte packets
 1  Example hostname connection point (Example IP)  17,059 ms  17,847 ms  17,752 ms
 2  Example IP Address Node (Example IP)  18.691 ms  17.633 ms  20.635 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *

In this case, the server cannot be reached. If the route tracing ends with an entry that looks like the following or something similar (the IP address may differ, depending on the IP address of your creoline server), the route to the server is essentially intact, and the problem is likely on the server side. To address this, proceed to the section Checking the Server:

 3  * ae20.gate.fra1.de.creoline.net (example IP)  2028.025 ms *

Checking the Server

Below, we explain the options available to you for narrowing down and, if necessary, resolving server-side connection issues.

Changing Your Public IP Address

Go to https://ip.creoline.com in your browser to find your public IP address.

Check whether you can connect via a different public network.

To do this, you can, for example, set up a mobile hotspot on your smartphone and connect your device to it. If your device does not have Wi-Fi capability, you can alternatively connect the smartphone via USB and use USB tethering to connect to the Internet via the smartphone and your mobile carrier.

When you visit https://ip.creoline.com again, different IP addresses should now be displayed.

Then try connecting to your device again via Remote Desktop.

If the connection is successful, proceed to the section Check for Blocking via IPBan.

If the connection fails, please proceed to the section Blocking the Windows User.

If the external connection to the MSSQL server does not work, please follow the steps described in the section Blocking the MSSQL user “sa”.

Lockout via IPBan

On our servers with JTL-Wawi pre-installed, the IPBan application runs by default to detect brute-force attacks and temporarily block the corresponding IP addresses.

Since the threshold for a block—set at 5 failed login attempts—is quite low for security reasons (which is also intended to prevent user accounts from being locked), your connection’s IP address may be blocked under certain circumstances.

If you were able to connect to the server via Remote Desktop using a mobile hotspot or similar, you can check whether your IP address has been blocked as follows:

• Open the following path in File Explorer:

C:\Program Files\IPBan

• Open the most recent log file. The name is structured as follows: logfile_XX\n, where XX is a number that increases daily. The file with the highest number at the end of the filename is usually the most recent log file on our servers.
• Search here for your regular public IP address—the one you had before connecting to the mobile hotspot or similar service. You can use the keyboard shortcut **CTRL + F ** to utilize the built-in search function in the Editor application and simplify your search.
• If you find your IP address and the log file also contains a message stating that the IP address has been blocked, you can create the file unban.txt in the IPBan directory and insert the IP addresses line by line (one IP address per line) to force an immediate unblock.
• Reconnect to the server via your regular Internet connection.

Blocking a Windows User

If your Windows user (e.g., jtl-wawi) has been blocked and no other user with administrative rights is available, please contact our support team. If your server is on the “Managed” support level, the support team can easily unlock the account.

If you have an additional Windows user who is authorized for a Remote Desktop connection and has administrative rights, you can unlock the locked-out user as follows.

Procedure:

• Verify that the account is actually locked by opening Computer Management\n

  \

• In the left sidebar, navigate to Users and Groups, then select Users.\n

  \

• Open the properties of the affected user\n

  \

• If the checkbox next to Account is locked is checked, the user is indeed locked and can be unlocked by unchecking the box and saving the changes using the Apply button. The user will then be able to log in again without any problems.

Locking the MSSQL User “sa”

If your Remote Desktop connection is working but you cannot establish an external connection to the MSSQL database server, we’ll explain below how you can check whether the database user sa has been locked.

To do this, first connect to the server via Remote Desktop.

Then open the SQL Server Management Studio (SSMS) application and connect to your MSSQL server instance using Windows authentication.

Next, open the properties of the sa user via the left sidebar under Security → Logins. Under Status, you can check whether the account has been locked. If the account is locked, you can unlock it by unchecking the checkbox and then confirming the change by clicking the OK button. After that, you should be able to connect again without any problems.