logo

The ConnectWise Control forum has moved to ConnectWise University! This forum has been locked and is in read-only mode. Click here for instructions on how to access the new forum.

Welcome Guest! You can not login or register.

Notification

Icon
Error

Options
Go to last post Go to first unread
Jordan  
#1 Posted : Sunday, December 28, 2014 6:53:57 PM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Has anyone had success in changing the default ports of ScreenConnect to 80 and 443 on their Linux server with Apache?

I'd like to change the ports to 80 for web and 443 for relay, but the docs say that SC needs 443 completely free for this to work. How would I do that and still have SSL for my web traffic, etc.?

My desired setup would have a dedicated subdomain for ScreenConnect that connects on port 80, with the relay using port 443 and the multi-domain SSL certificate that I purchased that includes that dedicated subdomain. (The domain that I would like ScreenConnect on has one dedicated IP address for the domain and its sub-domains.)

So far no luck in getting this working; any experiences out there with this scenario?

Update: I was unable to get this to work with Apache, but I was able to set up NGINX to work as a reverse proxy for ScreenConnect. See below.

Edited by user Thursday, January 8, 2015 9:51:34 PM(UTC)  | Reason: Found a solution

Paul Moore  
#2 Posted : Sunday, December 28, 2014 9:27:01 PM(UTC)
Paul Moore


Rank: Advanced Member

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 9/16/2011(UTC)
Posts: 334

Thanks: 5 times
Was thanked: 70 time(s) in 44 post(s)
Hi Jordan

It needs to be the other way around. 443 for the web/UI and 80 for the relay. The relay is already encrypted, without the need for TLS.

You can use Apache, but only as proxy to ScreenConnect. Screenconnect will serve content itself over which ever port you specify, so Apache/NGINX isn't required. You can add SSL certificates through Mono; there are plenty of guides for this around the forum.

If you need any help, drop me a PM.

Thanks.
ScreenConnect Reporting - Collects live & historical information including session times.
http://goo.gl/nrF3e9
Jordan  
#3 Posted : Monday, December 29, 2014 12:03:48 AM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Paul, actually the docs recommend using 443 for the relay port and 80 for the web server port, but support either configuration. I don't really care which uses which, as I would like to use 80 and 443 for the app to maximize my compatibility with strict corporate environments.

My concern is with the line from ScreenConnect's docs that say that says "Unlike the Web Server, the Relay must have exclusive access to the specified port" -- Apache (httpd) is listening on both, as those are defacto standards for web connectivity (unencrypted and SSL).

Is there some way to configure things that I have overlooked that will allow me to retain all of the normal functionality of my web server and still use either port 80 or 443 for the ScreenConnect relay?
Paul Moore  
#4 Posted : Monday, December 29, 2014 12:31:38 AM(UTC)
Paul Moore


Rank: Advanced Member

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 9/16/2011(UTC)
Posts: 334

Thanks: 5 times
Was thanked: 70 time(s) in 44 post(s)
They recommended 80 for the UI so the client doesn't need to specify a port. If you intend to run TLS (and everyone should), the UI must run on 443 and the relay on 80.

You can't run both apache & screenconnect on those ports for the same FQDN. You could listen on a subdomain for screenconnect, disabling Apache on just that FQDN.
ScreenConnect Reporting - Collects live & historical information including session times.
http://goo.gl/nrF3e9
Jordan  
#5 Posted : Monday, December 29, 2014 7:51:04 PM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Thanks Paul. I'm now trying to figure out how I can most effectively tell Apache to IGNORE my new IP address now dedicated to ScreenConnect.

Such a process should eventually be documented, as my setup is pretty standard: LAMP server on CPanel. The desire to use ports for SC that provide for the greatest level of compatibility with most environments is something many customers would be interested in.

Right now I'm messing with the Apache Main.Default template that helps generate the full httpd.conf file for Apache. I'm using a modified copy as Main.Local (since it supercedes Main.Default), with the following admittedly hacky-looking tweaks. If anyone has a better method for doing this, PLEASE let me know.

I commented out the two relevant sections related to setting up the httpd listeners on port 80 and 443, and added my server's IP addresses manually:

Code:
### Commented out server-wide listening for ScreenConnect support: ###
#[% IF configured.ip_listen -%]
#[%- FOREACH ip IN configured.ip_listen -%]
#Listen [% ip %]:[% configured.main_port %]
#[% END -%]
#[% ELSE -%]
## Defined in /var/cpanel/cpanel.config: apache_port
#Listen [% main.listen.item.listen %]
#[% END -%]

### Added each server IP to Listen, except the one dedicated to ScreenConnect ###
Listen 25.52.152.52:80
Listen 25.52.152.53:80
Listen 25.52.152.54:80
Listen 25.52.152.55:80
Listen 25.52.152.56:80
Listen 25.52.152.57:80
# Don't Listen on ScreenConnect IP
#Listen 25.52.152.58:80
Listen 25.52.152.59:80


A little further down in the template, a similar structure exists that adds 443/HTTPS listening. I tried modifying it as follows:

Code:
### Commented out server-wide 443/HTTPS listening for ScreenConnect SSL support: ###
#[% IF configured.ip_listen_ssl -%]
#[%- FOREACH ip IN configured.ip_listen_ssl -%]
#    Listen [% ip %]:[% configured.main_port_ssl %]
#[% END -%]
#[% ELSE -%]
#    # Defined in /var/cpanel/cpanel.config: apache_ssl_port
#    Listen [% main.ifdefinessl.listen.item.listen %]
#[% END -%]

### Added each server IP to Listen, except the one dedicated to ScreenConnect ###
Listen 25.52.152.52:443
Listen 25.52.152.53:443
Listen 25.52.152.54:443
Listen 25.52.152.55:443
Listen 25.52.152.56:443
Listen 25.52.152.57:443
# Don't Listen on ScreenConnect SSL IP
#Listen 25.52.152.58:443
Listen 25.52.152.59:443


I tried this once so far and Apache started saying it couldn't connect to 127.0.0.1:80, had to have my webhost bail me out. Has anyone gone down this road before?
Jordan  
#6 Posted : Tuesday, December 30, 2014 2:10:48 AM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Getting closer... I found that editing the Apache template is not necessary if you are using CPanel.

Logged in as root in WHM, navigate to Service Configuration >> Apache Configuration >> Reserved IPs Editor and check the IP address you want excluded from Apache's listeners. It'll draw up the config pretty much how I did it manually above.

Now to figure out how to get SSL and HTTP->HTTPS redirect working on the WebServer side of things... I'm not sure yet if I need a VirtualHost for my subdomain or if an A NAME DNS entry pointed to the IP address is enough. Right now ScreenConnect is giving me an error that says "ScreenConnect is already started, please stop it first." even though the process is not running. More investigation needed...
Jordan  
#7 Posted : Tuesday, December 30, 2014 8:26:50 AM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
I'm trying my best to get the SSL certificate working directly through Mono, but I'm not having any luck so far.

I've decided that I'd like to use 443/SSL on the ScreenConnect WebServer and port 80 for the relay.

For the SSL setup, I used the ScreenConnectConfigurator to create a Tarball of the certificates that I successfully extracted in the opt/screenconnect directory, but I continue to get "Connection Refused" errors when attempting to connect to the subdomain via HTTPS/port 443.

It should be noted that I have no problem getting ScreenConnect working on the dedicated-IP subdomain with the default ports, 8040 and 8041.

Here's the config that I would like to have working (I have also enabled the BaseUrlRedirectionModule in the hopes of redirecting HTTP calls to HTTPS):

Code:
	<add key="WebServerListenUri" value="http://55.525.252.55:443/" />
	<add key="WebServerAddressableUri" value="https://remote.mydomain.com/" />
	<add key="WebServerAlternateListenUri" value="http://55.525.252.55:80/" />
	<add key="RelayListenUri" value="relay://55.525.252.55:80/" />
	<add key="RelayAddressableUri" value="relay://remote.mydomain.com:80/" />
	
	<add key="RedirectFromBaseUrl" value="http://remote.mydomain.com*" />
	<add key="RedirectToBaseUrl" value="https://remote.mydomain.com/" />


My server config is CentOS 6.6, Apache 2.2.29, and the latest 5.0 version of ScreenConnect. SSL cert is a multi-domain from Comodo.

Help!

Edited by user Tuesday, December 30, 2014 8:28:08 AM(UTC)  | Reason: Not specified

Jordan  
#8 Posted : Thursday, January 1, 2015 8:39:49 AM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
The saga continues!

After seemingly exhausting all of my visible options, I have, for the time being, given up trying to implement the ScreenConnect-recommended route of using Mono directly to serve all of the ScreenConnect functionality (SSL on the WebServer and port-80 on the relay). Despite my best efforts, I could not get SC and Apache to work together (or, more accurately, completely separately). I would continually get this entry in the SC log file, followed by a bunch of exceptions until the WebServer restarted:

Code:
Event (2014/12/30 12:23:00.620 -05:00, ScreenConnect Session Manager, Information): Starting service...
Event (2014/12/30 12:23:01.144 -05:00, ScreenConnect Session Manager, Information): Successfully started service.
Event (2014/12/30 12:23:01.144 -05:00, ScreenConnect Relay, Information): Starting service...
Event (2014/12/30 12:23:01.361 -05:00, ScreenConnect Relay, Information): Successfully started service.
Event (2014/12/30 12:23:01.361 -05:00, ScreenConnect Web Server, Information): Starting service...
Event (2014/12/30 12:23:07.961 -05:00, ScreenConnect Web Server, Error): Failed to start service: System.Net.Sockets.SocketException: Address already in use


I decided instead to abandon the circumvention of Apache and have now embraced it via its reverse proxy feature. I was able to get SSL working on the HTTP side (https://remote.mydomain.com) and I setup a second subdomain for the relay (http://secure-relay.mydomain.com)

The Apache VirtualHosts for standard and SSL on the https://remote.mydomain.com subdomain appear to be setup correctly, as does the http://secure-relay.mydomain.com/ relay URL, as navigating to it using the web browser gives an expected error (the ScreenConnect app doesn’t know what to do with a GET command).

For completeness, and for the next soul that ends up here traveling this same journey, here's the config modifiers I had to use on Apache 2.2 with CPanel to get things (mostly) working:

Under /usr/local/apache/conf/userdata/std/2_2/wwwusername/remote.mydomain.com, I created the Port80Redirect.conf (these can be any name, but must end in .conf) file with the following contents so that all visitors to my subdomain would be redirected to the SSL version:
Code:
	RewriteCond %{HTTP_HOST} ^remote.mydomain.com
	RewriteRule ^/(.*)$ https://remote.mydomain.com/$1 [L,R=301]


Under /usr/local/apache/conf/userdata/std/2_2/wwwusername/secure-relay.mydomain.com, I created the RemoteVHostRelayProxy.conf file with the following contents so that any connections to the relay subdomain would be directed to the port that ScreenConnect is listening to for relay activity:
Code:
	ProxyPreserveHost On
	ProxyPass / http://localhost:8041/ disablereuse=on ConnectionTimeout=120 Timeout=120
	ProxyPassReverse / http://localhost:8041/
	KeepAliveTimeout 0


Under /usr/local/apache/conf/userdata/ssl/2_2/wwwusername/remote.mydomain.com, I created the RemoteVHostSSL.conf file with the following contents so that any connections to the WebServer SSL would be directed to the port that ScreenConnect is listening to for WebServer activity:
Code:
	ProxyPreserveHost On
	ProxyPass / http://localhost:8040/ disablereuse=on ConnectionTimeout=120 Timeout=120
	ProxyPassReverse / http://localhost:8040/
	KeepAliveTimeout 0


Unfortunately, at this time I am still getting a connection error when I attempt to connect to a session:

"The given key was not present in the dictionary."

I got a similar error from the Java client: "key "60" was not found in hash map"

My ScreenConnect config is as follows:

Code:
                <add key="WebServerListenUri" value="http://127.0.0.1:8040/" />         
                <add key="WebServerAddressableUri" value="https://remote.mydomain.com:443/" /> 
                <add key="RelayListenUri" value="http://127.0.0.1:8041/" />
                <add key="RelayAddressableUri" value="http://secure-relay.mydomain.com/" />


Using the RelayAddressableUri is needed in this scenario, otherwise the relay sessions attempt to connect to the "remote" subdomain, which will not work. I also tried using relay://secure-relay.mydomain.com with relay://127.0.0.1:8041 and received the same error.

I fear that this may be a ScreenConnect issue, and have offered to work out the issue with their team. If anyone has setup their Linux/Apache server in the above-described manner, please chime in any time. :)

Edit: this is for ScreenConnect version 5.0.8132.5459; any other version may or may not have the above issue.

Edited by user Sunday, January 4, 2015 11:01:22 PM(UTC)  | Reason: Not specified

Alexander  
#9 Posted : Friday, January 2, 2015 5:08:48 PM(UTC)
Alexander


Rank: Administration

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 7/23/2013(UTC)
Posts: 715
Man
Location: Raleigh, NC

Was thanked: 66 time(s) in 63 post(s)
You could use Network Monitor or Wireshark to see what's being passed to the client; 60 is ASCII <, so it seems like it might be an html error page of some sort.
Also, what happens if you use the default "relay://+:8041/" for RelayListenUri?
ScreenConnect Team
Paul Moore  
#10 Posted : Friday, January 2, 2015 11:15:49 PM(UTC)
Paul Moore


Rank: Advanced Member

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 9/16/2011(UTC)
Posts: 334

Thanks: 5 times
Was thanked: 70 time(s) in 44 post(s)
Hi Jordan

Your setup is all over the place.

1. Your SSL/TLS config is festooned with errors, so Java <7 will fail to connect... along with several browsers. You're also vulnerable to POODLE/SSLv3 at present, so you'll need to make some protocol changes to sort that.
2. Regarding protocols, you're attempting to ProxyReverse the relay using HTTP. The relay doesn't listen on that protocol, hence why Apache is returning content which the app can't understand. If Apache isn't compiled to allow raw TCP connections over a proxy, you'll need to recompile Apache/mod_proxy.
3. Your Apache vhost is listening for HTTP connections on 8041. If Apache returns content on 8041, Screenconnect won't have a clue how to handle it.

You either need to start over, pay someone to configure it for you or throw NGINX on it. An SC install (like you're proposing) should take no more than an hour to configure.
ScreenConnect Reporting - Collects live & historical information including session times.
http://goo.gl/nrF3e9
thanks 1 user thanked Paul Moore for this useful post.
Jordan on 1/4/2015(UTC)
Jordan  
#11 Posted : Sunday, January 4, 2015 5:12:09 AM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Paul, thanks for raising my awareness to potential SSL issues. I have configured NGINX to serve as a proxy to ScreenConnect, using your configuration post as a guide. (Are there any issues with opening up TLS 1.1 and 1.2? Those were disabled in your walkthrough...)

Unfortunately, I am still receiving an error on the relay: "The given key was not present in the dictionary."

This is on public port 80, being forwarded by NGINX to port 8041. Same error if I try a different port for the relay (8080).

I'm going to try deleting the entire SC installation and reinstalling...

Edit: No luck on a clean install, still the same error when attempting to connect to a session.

Edit 2: Same error on the latest 5.1 pre-release version. :-\

Edited by user Sunday, January 4, 2015 6:22:37 AM(UTC)  | Reason: Not specified

Jordan  
#12 Posted : Sunday, January 4, 2015 8:02:06 PM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Anything different is good, right?

I updated my NGINX install to the latest version (installing via the EPEL repository installed version 1.0.15, the latest stable is 1.6.2), and now I'm getting a new error message when either the Host or the Guest attempt to connect to the relay:

Code:
Message must be type Elsinore.ScreenConnect.HandshakeMessage but was Elsinore.ScreenConnect.EndPointStatusMessage


This is using the pre-release ScreenConnect 5.1.8174.5466. Assistance and insight is appreciated. :)
Alexander  
#13 Posted : Monday, January 5, 2015 3:48:29 PM(UTC)
Alexander


Rank: Administration

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 7/23/2013(UTC)
Posts: 715
Man
Location: Raleigh, NC

Was thanked: 66 time(s) in 63 post(s)
I suspect that error is basically the same as the previous one, but with 72 instead of 60; there just happens to be a message type corresponding to that this time.
ScreenConnect Team
Jordan  
#14 Posted : Monday, January 5, 2015 8:04:57 PM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Originally Posted by: Alexander Go to Quoted Post
I suspect that error is basically the same as the previous one, but with 72 instead of 60; there just happens to be a message type corresponding to that this time.


Alexander, I took your advice and logged the error in detail from the server. I sent support AT screenconnect.com my detailed error log to hopefully diagnose and resolve the issue.

The error in the NGINX log reads: "client sent invalid method while reading client request line ..." with the resulting HTTP error "HTTP/1.1 400 Bad Request"
Alexander  
#15 Posted : Tuesday, January 6, 2015 3:44:38 PM(UTC)
Alexander


Rank: Administration

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 7/23/2013(UTC)
Posts: 715
Man
Location: Raleigh, NC

Was thanked: 66 time(s) in 63 post(s)
The request looks like the initial message from the client, which should be passed on to the relay, but nginx is apparently giving it an HTTP error instead. Are you still using http:// instead of relay:// for the RelayListenUri and RelayAddressableUri, perhaps?
ScreenConnect Team
Jordan  
#16 Posted : Tuesday, January 6, 2015 8:07:22 PM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Thanks for working with me on this, Alexander.

Yes, I've tried both relay:// and http:// to begin the relay URLs; even tried relay on one and http on the other to no avail. I tried enabling the ignore_invalid_headers option on NGINX thinking it just might not like what ScreenConnect is sending it without success as well.
Jordan  
#17 Posted : Thursday, January 8, 2015 8:44:07 AM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
Bit of a breakthrough here...

I discovered that the issue with NGINX (and probably the Apache reverse proxy) was that neither one of them supported forwarding raw TCP packets. The ScreenConnect applet communicates with the server using TCP, not HTTP packets, and NGINX and Apache didn't know what to do with them, hence the 400 Bad Request errors.

There is, however, a solution!

NGINX has a third-party module that enables TCP proxy support: https://github.com/yaoweibin/nginx_tcp_proxy_module

You'll have to build NGINX from source in order to use it. I was able to incorporate it into the latest mainline version as of this posting, NGINX 1.7.9.

This was the most helpful resource I found to configure and build NGINX, you just have to also incorporate the TCP proxy module into the mix.

Testing this now, and it does connect, but it seems to frequently drop the mutual connection about every 45 seconds to a few minutes. It drops and reconnects after a few seconds. Maybe need to play with the timeout settings, maybe this approach is just unreliable...

EDIT: It appears to be disconnecting on a random interval with the error "unable to read beyond the end of the stream"... does that tell us anything?

Edited by user Thursday, January 8, 2015 10:13:26 AM(UTC)  | Reason: Not specified

Alexander  
#18 Posted : Thursday, January 8, 2015 3:06:01 PM(UTC)
Alexander


Rank: Administration

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 7/23/2013(UTC)
Posts: 715
Man
Location: Raleigh, NC

Was thanked: 66 time(s) in 63 post(s)
That means that the server closed the connection, which seems to be what you were saying anyway.
ScreenConnect Team
Jordan  
#19 Posted : Thursday, January 8, 2015 7:33:48 PM(UTC)
Jordan


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 12/26/2014(UTC)
Posts: 37

Thanks: 5 times
Was thanked: 3 time(s) in 2 post(s)
After restarting the server (I was using nginx -s reload to reload the config), and tweaking some settings, it appears that the connection has stabilized. For reference, this is how my TCP block looks right now:

Code:
tcp
{
	server 
	{
		listen my.ip.add.ress:80;
		server_name secure-relay.mydomain.com;
		timeout 180000;
		proxy_pass 127.0.0.1:8041;
		proxy_connect_timeout 120000;
		proxy_send_timeout 120000;
		proxy_read_timeout 120000;
		proxy_buffer 64k;
	}
}


Coming on two hours now of connection time without interruption. Looking good!
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.