ScreenConnect Setup
-
@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.....
-
@anonymous said:
@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.....
Well, if you can make it work, yes. But from my experience the confiruation you are dealing with is very unusual. The one place I have had issues, as mentioned previously, I have no issues with getting something opened if it is for a business purpose. ScreenConnect not being a tool for THEIR business means I simply never asked to have it opened. They likely would as we have a good relationship, but I chose not to ask.
For other services that I use there for supporting their software development I have had ports opened. Notably for the SVN repository we keep their code.
Side note: I really need to migrate that to a git solution sometime this year. -
Got it working on port 80 (Portal) and 443 (Relay)
How important is it to have a SSL cert to protect the portal page?
-
@anonymous said:
Got it working on port 80 and 443
How important is it to have a SSL cert to protect the portal page?
It's got to have a cert weather it's self-signed or a verified SSL cert.
-
@thecreativeone91 said:
It's got to have a cert weather it's self-signed or a verified SSL cert.
Do they provide a self-signed one out of the box?
-
If memory serves, no. Could easily be wrong, but I'm pretty sure that they do not.
-
@anonymous said:
@thecreativeone91 said:
It's got to have a cert weather it's self-signed or a verified SSL cert.
Do they provide a self-signed one out of the box?
Don't know. I've never used it, Should be easy enough to generate your own.
-
@anonymous said:
Got it working on port 80 (Portal) and 443 (Relay)
How important is it to have a SSL cert to protect the portal page?
You can't use SSL for the portal page because you have the relay on port 443.
You can't use the same port for both services.
-
@JaredBusch said:
You can't use the same port for both services.
Right, so I will just swap the ports.
