ScreenConnect Setup
-
Doesn't look like you are listening on port 443.
-
He is correct, there is nothing using port 443, so if the port is open it will still not connect as there is nothing to connect to.
See if ScreenConnect is running first of all. Maybe it is not even on. If it is on, then it is on the wrong ports.
-
-
Is ScreenConnect an independant application or is it just a "web" app that sits on top of Apache? If it is just a web app make sure Apache is running. Something like:
systemctl status httpd.service -
@anonymous said:
@scottalanmiller said:
See if ScreenConnect is running first of all.
How?
ps aux | grep reen -
Output:
root 2814 0.0 0.2 115352 1168 ? S 06:03 0:02 /bin/sh /etc/rc.d/init.d/screenconnect start root 15933 26.0 1.9 211728 9760 ? Rl 10:19 0:00 mono /opt/screenconnect/Bin/Elsinore.ScreenConnect.Service.exe startservices 7 840 10 -
Here is my web.config:
<add key="WebServerListenUri" value="http://subdomain.mydomain.com:443/" /> </add> <add key="RelayListenUri" value="relay://0.0.0.0:80/" /> </add> -
Definitely looks like it is running. So must be on the wrong ports.
-
I'll change them back to defaults, and restart.
-
On screen connect the Relay port and all communications on that port are already encrypted the only bit you need to encrypt is the web portal. In order to properly encrypt the web portal you also need to apply an SSL certificate then you should be able to work HTTPS.
What I would do at this moment is reinstall Screen Connect from scratch leaving all the default ports and test it to be sure you can get it working.Once you are sure you have it working then go about changing the web portal port to 443 / HTTPS leaving the default relay port on 8041. I use this configuration on a few Screen Connect instances and it works well.
Also be sure this box does not have any other web services installed as that can interfere with your ports.
-
Thanks Greg. Greg is NTG's ScreenConnect admin.
-
@GregoryHall said:
What I would do at this moment is reinstall Screen Connect from scratch leaving all the default ports and test it to be sure you can get it working.
I'll give that a try. How do I make sure I property remove it? Keep in mind, it was working fine until I tried to change the ports...
Edit: Nevermind - http://help.screenconnect.com/Uninstalling_the_server_software
-
@GregoryHall said:
In order to properly encrypt the web portal you also need to apply an SSL certificate then you should be able to work HTTPS.Can I test without a SSL cert? Do they have a self signed one?
-
@GregoryHall said:
Once you are sure you have it working then go about changing the web portal port to 443 / HTTPS leaving the default relay port on 8041. I use this configuration on a few Screen Connect instances and it works well.
Sadly, I can't leave the relay port on 8041, as most of the time port 8041 is blocked. That is why I am using ports 80/443.
-
@GregoryHall said:
Also be sure this box does not have any other web services installed as that can interfere with your ports.
Would a LAMP stack running on the box cause any issues?
-
@anonymous said:
@GregoryHall said:
Also be sure this box does not have any other web services installed as that can interfere with your ports.
Would a LAMP stack running on the box cause any issues?
Absolutely. You can never have two systems trying to use the same ports. Ports can only be bound to a single process. This is a fundamental limitation of ports.
-
@scottalanmiller said:
Absolutely. You can never have two systems trying to use the same ports. Ports can only be bound to a single process. This is a fundamental limitation of ports.
This will not work?
*If you have other HTTP services running on the machine, you will need to narrow your scope of listening. For example IIS (Internet Information Services) may also need to listen for HTTP traffic on port 80.
To listen on port 80, but only for a certain host, use the following syntax, replacing support.mycompany.com with your hostname:*
<add key="WebServerListenUri" value="http://support.mycompany.com:80/" /> -
@anonymous said:
@scottalanmiller said:
Absolutely. You can never have two systems trying to use the same ports. Ports can only be bound to a single process. This is a fundamental limitation of ports.
This will not work?
*If you have other HTTP services running on the machine, you will need to narrow your scope of listening. For example IIS (Internet Information Services) may also need to listen for HTTP traffic on port 80.
To listen on port 80, but only for a certain host, use the following syntax, replacing support.mycompany.com with your hostname:*
<add key="WebServerListenUri" value="http://support.mycompany.com:80/" />I believe that's referring to Vhosts, not actually two different programs listening on the same port just, I guess you can think of it as two different configurations based on who asked for it.
-
@anonymous said:
@scottalanmiller said:
Absolutely. You can never have two systems trying to use the same ports. Ports can only be bound to a single process. This is a fundamental limitation of ports.
This will not work?
*If you have other HTTP services running on the machine, you will need to narrow your scope of listening. For example IIS (Internet Information Services) may also need to listen for HTTP traffic on port 80.
To listen on port 80, but only for a certain host, use the following syntax, replacing support.mycompany.com with your hostname:*
<add key="WebServerListenUri" value="http://support.mycompany.com:80/" />No, how could it? If IIS already owns that port, IIS is going to own that port. ScreenConnect has no means of accessing it. If ScreenConnect gets that port, IIS cannot bind to it. One or the other has to fail.
-
@thecreativeone91 said:
I believe that's referring to Vhosts, not actually two different programs listening on the same port just, I guess you can think of it as two different configurations based on who asked for it.
It requires a proxy in front (very common to use Nginx for this like we are with this community right now) which is the program that binds to and listens to the port (port 80 in the case of ML) and then hands off the connection via a secondary port to other programs, such as NodeBB.
