logo
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
sean.herman  
#1 Posted : Monday, May 21, 2018 2:21:50 PM(UTC)
sean.herman


Rank: Guest

Joined: 5/21/2018(UTC)
Posts: 4
United States
Location: Central

Thanks: 1 times
I have a single Windows server running 6.6 hosting relay on 443 and web interface on 80. I want to switch relay to 80 and web interface to 443 because only 80 and 443 are reliably allowed through firewalls at client sites.
I can utilize multiple public IPs (NAT’d to multiple internal NICs or a single internal NIC, whichever is required), different hostnames/A records, or have a temporary web interface port for a few weeks if needed but I don't understand how to make this switch.

  1. If I switch relay to 80 and web interface to 443 how do clients that are not connected at the time of the switch receive the updated configuration (since the relay, which presumably provides the agent the information is no longer listening on the agreed-upon port)? Do I have to use an intermediate port for the web interface and switch it to 443 after all my agents have received the updated configuration or can I use different public IPs (NAT’d to different or the same internal NICs to different or the same hostnames)?
  2. If I switch relay to port 80 and web interface to 443 can I still somehow implement http->https redirection using the BaseUrlDirectionModule (and is it still supported on 6.6?)? If so, do I have o accomplish using different listening public IPs/DNS (WebServerListenURI, RelayListenURi, RelayAddressableUri) or can the relay handle that redirection somehow?
  3. Is there a specific transition sequence I have to go through with any of the above methods?
Scott  
#2 Posted : Monday, May 21, 2018 2:54:18 PM(UTC)
Scott


Rank: Administration

Medals: Level 4: Wise Old Owl! Received 100 Thanks!

Joined: 3/28/2014(UTC)
Posts: 2,806
United States

Thanks: 3 times
Was thanked: 345 time(s) in 299 post(s)
So in theory you can use the Router service to handle requests on the same port(s) via their protocol. More information on the Router can be found here. This setup would not be Supported although I do not see any obvious problems from the information you have provided.

To specifically answer your questions:
1. You can use the RelayAddressableUri web.config setting to hard-code to where clients callback to hit the relay. You would add this setting, configure it, and then push out a Reinstall to every client in order to propagate the change. Clients that are not connected when you push the Reinstall would not receive the update unless you were to wait for them to reconnect before changing the RelayListenUri setting.
2. No, but the Router mentioned above can do this instead of the HttpModule method.
3. Yes, take a look at this KB article for the full list of steps for moving your clients to a new relay address/port.
ScreenConnect Team
sean.herman  
#3 Posted : Monday, May 21, 2018 3:21:19 PM(UTC)
sean.herman


Rank: Guest

Joined: 5/21/2018(UTC)
Posts: 4
United States
Location: Central

Thanks: 1 times
So if I was trying to sequence this type of change in a safe way without worrying about http->https redirection for web interface, would the below be a reasonable sequence that others could adopt for their own environments in the future?

1. Create test agent in isolation network:
a. Spin up a temporary Windows AWS instance on different network as Screenconnect VM without elastic IP.
b. Install ConnectWise agent on temporary the temporary Windows AWS instance.

2. Test in isolation:
a. Purchase certificate for HTTPS (for web interface).
b. Confirm inbound 3389 to ScreenConnect VM (DONE).
c. Disable AWS inbound 443 and 80 (to stop external connectivity to SC) except to the tempory Windows IP.
d. Confirm all clients disconnect except test client.
e. Add <add key="RelayAddressableUri" value="relay://remote.myscreenconnectsite.com:80/" /> to web.config and save.
f. Reinstall agent on temporary Windows agent and confirm reconnection.
g. Modify web.config change of <add key="WebServerListenUri" value="https://+:443/" />, <add key="RelayListenUri" value="relay://+:80/" /> and save.
h. Confirm agent reconnects, relay shows up as relay://remote.myscreenconnectsite.com:80, web interface is available at https://remote.myscreenconnectsite.com, and a support session works.
i. Revert web.config changes in step 2g, reopen the AWS firewall to all public addresseses inbound on 80/443.
j. After clients check in, re-install all agents.

3. After all agents complete the re-install (how will I know when this is done?), re-complete step 2g-2h.

Edited by user Monday, May 21, 2018 3:22:02 PM(UTC)  | Reason: Not specified

Scott  
#4 Posted : Monday, May 21, 2018 3:33:33 PM(UTC)
Scott


Rank: Administration

Medals: Level 4: Wise Old Owl! Received 100 Thanks!

Joined: 3/28/2014(UTC)
Posts: 2,806
United States

Thanks: 3 times
Was thanked: 345 time(s) in 299 post(s)
The Router gives you the ability to have both the Relay and Web Server services "running" on the same port. The best way to set it up in terms of dealing with firewalls is to use 443 for both services. Now, while traffic will call back to/interact with the Control server on 443, the processes will actually be listening on completely different ports on the machine, but the router will act as a reverse-proxy-like traffic handler.

For a real world example, our semi-product development instance uses the router. Both clients and web traffic interact with it on 443 but the web server is listening on 8043 and the relay is technically listening on 8041. The Router is configured as such:
Code:

<configSections>
    <section name="screenconnect.routing" type="ScreenConnect.RoutingConfigurationHandler, ScreenConnect.Server" />
  </configSections>
  <screenconnect.routing>
    <listenUris>
      <listenUri>tcp://+:80/</listenUri>
      <listenUri>tcp://+:443/</listenUri>
    </listenUris>
    <rules>
      <rule schemeExpression="http" actionType="issueRedirect" actionData="https://$HOST/" />
      <rule schemeExpression="ssl" actionType="forwardPayload" actionData="https://localhost:8043/" />
      <rule schemeExpression="relay" actionType="forwardPayload" actionData="https://localhost:8041/" />
    </rules>
  </screenconnect.routing>


And the processes are configured with:
Code:

    <add key="WebServerListenUri" value="https://+:8043/" />
    <add key="RelayListenUri" value="relay://+:8041/" />
    <add key="WebServerAddressableUri" value="https://live.screenconnect.com:443" />
    <add key="RelayAddressableUri" value="relay://live.screenconnect.com:443" />


So there are three scenarios:
1. A HTTP request comes in, the Router recognizes the request type and issues a redirect, sending it instead to HTTPS.
2. A HTTPS request comes in, the Router recognizes it as ssl and then forwards the payload along to 8043 which is the port on which the WebServerListenUri is set.
3. A relay request arrives, the Router recognizes it as relay and forwards it to 8041, the value for the RelayListenUri

We use the WebServerAddressableUri and RelayAddressableUri values to manually specify values for each setting so that they are not inherited from the two *ListenUri settings.
ScreenConnect Team
sean.herman  
#5 Posted : Wednesday, June 13, 2018 3:22:34 PM(UTC)
sean.herman


Rank: Guest

Joined: 5/21/2018(UTC)
Posts: 4
United States
Location: Central

Thanks: 1 times
Hey Thanks a lot Scott.

Below was the full process I went through on Windows and it worked perfectly for me. Much thanks to marktoo in his post at for helping me find the full process on Windows (see http://controlforum.conn...red-Relay.aspx#post30513).

Windows:
Install IIS
Generate CSR
Buy certificate
Generate cert
Complete cert in IIS
Bind IIS 8443
Run netsh http show sslcert
477383fde398083d16f134eb063b306b
Run:
netsh http add sslcert ipport=0.0.0.0:8043 certhash=477383fde398083d16f134eb063b306b appid={00000000-0000-0000-0000-000000000000}
Change instance security group to "RDP Only" (to break public connectivity in case the config breaks the relay communications)
Create ScreenConnect Relay service by export (HKLM\SYSTEM\CurrentControlSet\Services\ScreenConnect Relay), search and replace "Relay" with "Router" and import and reboot .
Change Config file.
Next, we added the following to web.config (after backing it up) between <configuration> and <location path="Host.aspx">

<configSections>
<section name="screenconnect.routing" type="ScreenConnect.RoutingConfigurationHandler, ScreenConnect.Server" />
</configSections>
<screenconnect.routing>
<listenUris>
<listenUri>tcp://+:80/</listenUri>
<listenUri>tcp://+:443/</listenUri>
</listenUris>
<rules>
<rule schemeExpression="http" actionType="issueRedirect" actionData="https://$HOST/" />
<rule schemeExpression="ssl" actionType="forwardPayload" actionData="https://localhost:8043/" />
<rule schemeExpression="relay" actionType="forwardPayload" actionData="https://localhost:8041/" />
</rules>
</screenconnect.routing>

we also changed these web.config appsettings:
<add key="WebServerListenUri" value="https://+:443/" />
<add key="RelayListenUri" value="relay://+:80/" />

to this:
<add key="WebServerListenUri" value="https://+:8043/" />
<add key="WebServerAddressableUri" value="https://support.ourcompany.com/" />
<add key="RelayListenUri" value="relay://+:8041/" />
<add key="RelayAddressableUri" value="relay://support.ourcompany.com:443/" />
Restart services.
Test SC internally.
Change instance security group to "Win-Public-Web-Server"
Test Screenconnect publicly.
Update Windows Firewall Inbound rule for ScreenConnect Web Server to allow 80,443 (80 was removed automatically during the config change).

Edited by user Wednesday, June 13, 2018 3:23:18 PM(UTC)  | Reason: Not specified

vexation  
#6 Posted : Sunday, July 1, 2018 9:26:50 AM(UTC)
vexation


Rank: Member

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

Joined: 8/28/2012(UTC)
Posts: 33

Thanks: 6 times
Was thanked: 3 time(s) in 2 post(s)
Didn't realise this was possible now - sounds great to have both running on 443.

We've been running the web interface on 443 and relay on 80 for years now but are starting to come across a lot of firewalls that block the relay on 80 due to IPS/IDS/it's simply not HTTP traffic. So far have been successful in asking for exception but I might just move it to 443 in the hopes that's less restrictive.
sean.herman  
#7 Posted : Thursday, August 16, 2018 5:08:51 PM(UTC)
sean.herman


Rank: Guest

Joined: 5/21/2018(UTC)
Posts: 4
United States
Location: Central

Thanks: 1 times
Support: When the relay and web services are restarted the they update their Windows firewall rule with then proper ports automatically but SC Relay does not create its own firewall rule so if you don't create a manual firewall rule in Windows Firewall then after the services are restarted you will loose inbound access through the SC relay port (80 and 443 for us). This seems undesirable (why build the firewall rule into the Web and Relay services but not into the Router service?) and engineering may wish to change this behavior in future releases.
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.