ScreenConnect Setup
-
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.
-
So I guess I am going to need a second box to run this on, since I can't be sure that any other ports are open. 80/443 are almost always open.
Unless someone has a better idea? Don't really want to have to run another box if I can avoid it.....
-
@anonymous said:
So I guess I am going to need a second box to run this on, since I can't be sure that any other ports are open. 80/443 are almost always open.
Unless someone has a better idea? Don't really want to have to run another box if I can avoid it.....
It's easy to check ports. I would just take a moment to check that before spinning up another box.
Also, how will you have two boxes using the same ports? Are you behind NAT? NAT will only forward one port to one place. So a port conflict will cause the same problems at the firewall level. Unless you have multiple IPs, which is unlikely with any service that doesn't give you open Internet access.
-
@scottalanmiller said:
@anonymous said:
So I guess I am going to need a second box to run this on, since I can't be sure that any other ports are open. 80/443 are almost always open.
Unless someone has a better idea? Don't really want to have to run another box if I can avoid it.....
It's easy to check ports. I would just take a moment to check that before spinning up another box.
Also, how will you have two boxes using the same ports? Are you behind NAT? NAT will only forward one port to one place. So a port conflict will cause the same problems at the firewall level. Unless you have multiple IPs, which is unlikely with any service that doesn't give you open Internet access.
I am using Digital Ocean. My plan would be to take mydomain.com and point it to my web server droplet and have subdomain.mydomain.com point to my screenconnect droplet. Since there different boxes, no ports issues, unless I am missing something?
-
You are concerned that places where your desktop will reside will have outgoing ports blocked?
-
@anonymous said:
@scottalanmiller said:
@anonymous said:
So I guess I am going to need a second box to run this on, since I can't be sure that any other ports are open. 80/443 are almost always open.
Unless someone has a better idea? Don't really want to have to run another box if I can avoid it.....
It's easy to check ports. I would just take a moment to check that before spinning up another box.
Also, how will you have two boxes using the same ports? Are you behind NAT? NAT will only forward one port to one place. So a port conflict will cause the same problems at the firewall level. Unless you have multiple IPs, which is unlikely with any service that doesn't give you open Internet access.
I am using Digital Ocean. My plan would be to take mydomain.com and point it to my web server droplet and have subdomain.mydomain.com point to my screenconnect droplet. Since there different boxes, no ports issues, unless I am missing something?
Right, if they are different machines there are no port issues.
-
@scottalanmiller said:
You are concerned that places where your desktop will reside will have outgoing ports blocked?
I am not concerned about the server at all, I have complete control of that.
My concern the client might have ports blocked. In some cases, I can control that, and it some cases I have no control over the firewall on-site.
I have to assume the worst, and go from there....
-
@scottalanmiller said:
You are concerned that places where your desktop will reside will have outgoing ports blocked?
@anonymous said:
I am not concerned about the server at all, I have complete control of that.
My concern the client might have ports blocked. In some cases, I can control that, and it some cases I have no control over the firewall on-site. I have to assume the worst, and go from there....
I have this issue at one client where our company is only hired as software development.
Their network administrators block all outbound traffic that is not on port 80 or 443. It is a large pain in the ass. -
@JaredBusch said:
Their network administrators block all outbound traffic that is not on port 80 or 443. It is a large pain in the ass.
Do we have the same clients?
What did you do to solve the issue so you could use ScreenConnect? Use port 80/443?
-
@anonymous said:
@JaredBusch said:
Their network administrators block all outbound traffic that is not on port 80 or 443. It is a large pain in the ass.
Do we have the same clients?
What did you do to solve the issue so you could use ScreenConnect? Use port 80/443?
As I am not the network support for this client, I was only wanting access to MY tools when I am on site.
I put Pertino on the ScreenConnect server and access it via that
-
@anonymous said:
@scottalanmiller said:
You are concerned that places where your desktop will reside will have outgoing ports blocked?
I am not concerned about the server at all, I have complete control of that.
My concern the client might have ports blocked. In some cases, I can control that, and it some cases I have no control over the firewall on-site.
I have to assume the worst, and go from there....
I see, so you want to have access from a client site. They might have 443 blocked too, some companies do that to try to get around SSL hiding stuff. Port 80 with SSL might be the best bet. Haven't tried that, just spitballing.
