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
