ScreenConnect Setup
-
@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.
-
@scottalanmiller said:
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.
He did not say he wanted access from a client site, I said that is why I had a Pertino work around.
The insinuation here is that @anonymous wants ScreenConnect to function for users to connect and create support sessions, but that the existing network configuration blocks ports other than 80/443.
The simple answer here is that if you are hired to be support, then demand that the required ports be open or do not take the business. How many clients are you going to have that you will not have access to their router /firewall in the first place?
-
@JaredBusch said:
The insinuation here is that @anonymous wants ScreenConnect to function for users to connect and create support sessions, but that the existing network configuration blocks ports other than 80/443.
Exactly!
-
I agree, there is accommodating clients and then there is over-accommodating them. At some point they have to let you do your job. You need a certain amount of tools, not a ton and it needs to be reasonable, but remote access is pretty basic. They can block things for everyone else and not for you if necessary.
-
@JaredBusch said:
How many clients are you going to have that you will not have access to their router /firewall in the first place?
One that I know of, but it's my biggest client, so I have to make it work
I have only tested with this one client, because I know there firewall is super tight.
-
@anonymous said:
One that I know of, but it's my biggest client, so I have to make it work
I have only tested with this one client, because I know there firewall is super tight.
Okay, then the next best answer would be to request that they add an exemption for you for the port the relay portion runs on. Offer them your droplet IP to say it even only needs to allow to "here" kind of thing.
-
@JaredBusch said:
Okay, then the next best answer would be to request that they add an exemption for you for the port the relay portion runs on.
Wouldn't changing the ports also work?
I kinda of like that idea of only needing ports that are almost always open.....
