ScreenConnect Setup
-
@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.
-
Maybe I am missing something here, but how important is it to use a SSL cert on your Portal Page?
All the remote support sessions are encrypted, so is this really a concern?
-
From the SC website:
*All data passing between host and guest systems is fully encrypted and protected from unauthorized access. This includes all screen data, file transfers, key strokes, and chat messages. ScreenConnect employs a 256 bit AES encryption algorithm, similar to that used by many banking and government institutions.
Although ScreenConnect encrypts all Relay session traffic by default, the Web Server HTTP traffic is not encrypted unless configured with SSL. There's really not a way to SSL/secure just the Login process without securing the entire website. Though this is something that we are looking into.*
-
So if I understand this right, the only thing the SSL cert does it protect the login?
