Posts made by Alex Sage

Got it working on port 80 (Portal) and 443 (Relay)

How important is it to have a SSL cert to protect the portal page?

@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.....

@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.

@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!

@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?

@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:

@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?

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.....

@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/" />

From: http://help.screenconnect.com/Changing_default_ports

@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?

@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:
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:

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

I'll change them back to defaults, and restart.

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>

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

@scottalanmiller said:

See if ScreenConnect is running first of all.

How?

My bounty is as boundless as the sea,
My love as deep; the more I give to thee,
The more I have, for both are infinite.

I am trying to setup ScreenConnect on submain.mydomain.com.

I have it installed, and I setup using the following doc:

http://help.screenconnect.com/Changing_default_ports

I would like to use 443 for the Web, and 80 for the relay, as later on I want to install a SSL cert.

Using a CentOS7 box, with a LAMP stack on it. Firewall has http and https allowed.

Not working, what am I missing?

These violent delights have violent ends
And in their triump die, like fire and powder
Which, as they kiss, consume