Fix connection problems

Foreword

In this article, we will show you several ways to isolate and resolve connection problems with Remote Desktop. We will also show you how to resolve connection problems with MSSQL Server 2022.

Prerequisites

• creoline JTL-Wawi server or comparable Windows server

Check connection

First check whether the server is generally accessible for the device from which you want to connect.

To do this, you need a terminal or something similar on your device.

Some operating system-specific examples are listed below:

Windows:

• CMD
• Powershell
• Windows Terminal

macOS:

• Terminal
• iTerm

Linux (Debian / Ubuntu):

• Terminal

Simple accessibility check

Use the following command via your terminal application to perform a rudimentary accessibility check. In the example, the IP address of the Google DNS server is used for demonstration purposes:

ping 8.8.8.8

Evaluation of the output:

Server is accessible:

If the following is output after executing the command, the server can be reached from your device without any problems (output may differ 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 not reachable:

If the following is output after executing the command, the server cannot be reached from your device (output may differ 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, continue with the following section Advanced accessibility check.

Extended accessibility check

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

traceroute 8.8.8.8

Under Windows, use the following command instead:

tracert 8.8.8.8

Evaluation of the output:

In this case, it should be noted that not all connection points on the route respond to the request from your device and disclose information. The decisive factor here is that the last connection point, 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 connection point (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 not reachable:

 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 connection point (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 is as follows or similar (IP address may be different, depending on the IP address of your creoline server), the route to the server is basically intact and the problem is probably on the server side. Continue with the section Checking the server:

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

Checking the server

In the following, we explain what options you have to limit and, if necessary, rectify server-side connection problems.

Change your own public IP address

Call up https://ip.creoline.com in your browser to determine your public IP address.

Check whether you can establish a connection via another public network.

For example, you can open a mobile hotspot with your smartphone and connect your device to it. If your device does not have a Wi-Fi function, you can alternatively connect the smartphone via USB and use USB tethering to connect to the Internet via the smartphone and your mobile phone provider.

Other IP addresses should now be displayed under https://ip.creoline.com when you call up the site again.

Then try to reconnect to your device via Remote Desktop.

If the connection is successful, continue with the section Check blocking by IPBan.

If the connection is unsuccessful, please continue with the section Blocking the Windows user.

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

Blocking by IPBan

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

As the threshold for blocking is set quite low at 5 failed login attempts for security reasons, which is also intended to prevent user accounts from being blocked, it is possible that your connection IP address may be blocked.

If you were able to establish a connection to the server via a mobile hotspot or similar via remote desktop, you can check whether your IP address has been blocked as follows:

• Open the following path via Explorer:

C:\Program Files\IPBan

• Open the latest log file. The name is composed as follows: logfile_XX\nWhere XX stands for a daily increasing number. The file with the highest number at the end of the file name is usually also the latest log file on our servers.
• Search here for your regular public IP address that you had before connecting to the mobile hotspot or similar. You can use the key combination **CTRL + F ** here to use the Editor application's integrated search and thus simplify the search.
• If you find your IP address and the log file also contains the message 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 a direct unblocking.
• Re-establish a connection to the server via your regular Internet connection.

Blocking the Windows user

If your Windows user (e.g. jtl-wawi) has been locked and no other user with administrative rights is available, please contact our support team. If your server is in the "Managed" support level, it can be unblocked without any problems.

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

Procedure:

• Check whether there is actually a lockout by opening the Computer Management\n

  \

• Navigate to Users and groups in the left sidebar and then select Users.\n

  \

• Open the properties of the affected user\n

  \

• If the checkbox next to Account is locked is filled in, the user is actually locked and can be unlocked by deselecting the checkbox and saving the changes using the Apply button. Logging in is then possible again without any problems.

Blocking of the MSSQL user "sa"

If the remote desktop connection works for you, but you cannot establish an external connection to the MSSQL database server, we 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.

Then open the properties of the user sa via the left sidebar under Security → Logins. Under Status you can check whether the account has been blocked. If the account has been blocked, you can unblock it by deselecting the checkbox and then confirming the change with the Ok button. You should then be able to connect again without any problems.