Shared Relay- Page 2

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

Error

2 Pages<12

Shared Relay

Options

Previous Topic Next Topic

syn-jmicallef		#51 Posted : Monday, November 7, 2016 10:46:16 PM(UTC)
Rank: Guest Joined: 10/30/2016(UTC) Posts: 3 Location: Australia		Hi Alexander, no I get the same problem as if I was going to the standard address. The web browser simply keeps trying to hit a page until it eventually times out. Running Netstat -a I can see ports 80, 443, 8041 and 8043 are listening.


User Profile View All Posts by User View Thanks

Alexander		#52 Posted : Tuesday, November 8, 2016 5:05:32 PM(UTC)
Rank: Administration Medals: Joined: 7/23/2013(UTC) Posts: 715 Location: Raleigh, NC Was thanked: 66 time(s) in 63 post(s)		In that case, the root problem doesn't seem to be related to the router. You could try checking with Network Monitor or something and see if that tells you anything.
		ScreenConnect Team


User Profile View All Posts by User View Thanks

dkitchens		#53 Posted : Monday, January 9, 2017 6:10:42 PM(UTC)
Rank: Guest Joined: 1/9/2017(UTC) Posts: 7 Thanks: 2 times		I've been fighting with this over the weekend, I looks easy enough but for the life of me I cannot get it to work if I set the WebServerListenUri to 8043, it works fine on 443. If I set it to anything besides 443 the redirect works but it cannot display the page. Netstat -an does not see anything listening on 443 if WebServerListenUri is not set to that. I made these changes to web.config: <configSections> <section name="screenconnect.routing" type="Elsinore.ScreenConnect.RoutingConfigurationHandler, Elsinore.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:443/" /> <rule schemeExpression="relay" actionType="forwardPayload" actionData="https://localhost:8041/" /> </rules> </screenconnect.routing> <add name="HttpsRedirectModule" type="HttpsRedirectModule" /> <add key="WebServerListenUri" value="https://screen01.net.local:443/" /> <add key="WebServerAlternateListenUri" value="http://+:80/" /> <add key="RelayListenUri" value="relay://0.0.0.0:8041/" /> <add key="WebServerAddressableURI" value="https://screen01.net.local:443/" /> <add key="RelayAddressableUri" value="https://screen01.net.local/" />


User Profile View All Posts by User View Thanks

Steven		#54 Posted : Monday, January 9, 2017 6:18:46 PM(UTC)
Rank: Guest Medals: Joined: 5/1/2015(UTC) Posts: 55 Location: Tampa, FL Was thanked: 12 time(s) in 8 post(s)		A few quick things to check: 1 - That when on 8043, the WebServerListenUri does NOT have the URL spelled out: <add key="WebServerListenUri" value="https://+:8043/" /> 2 - That you've bound your SSL certificate to port 8043 as well as 443: https://help.screenconne...L_certificate_on_Windows (replace 443 with 8043 in the instructions) 3 - Ensure your site firewall has the external ports forwarded to the server (80 and 443). 4 - Ensure your windows firewall, if enabled, has rules added for 80 and 443 to allow them in as well, and create a new rule for ports 8041 and 8043 to allow, enabling Edge Transversal (http://forum.screenconnect.com/yaf_postsm30513_Shared-Relay.aspx#post30513).
		ScreenConnect Team


User Profile View All Posts by User View Thanks

dkitchens		#55 Posted : Monday, January 9, 2017 10:41:28 PM(UTC)
Rank: Guest Joined: 1/9/2017(UTC) Posts: 7 Thanks: 2 times		Fixed WebServerListenUri Bound cert to 8043 Enabled Edge Transport on 8041 and 8043 Created Router entry in Registry Still no joy, rebooted the server, all services come up fine except for the new Router service, it starts and stops immediately. Changing ListenUri back to 443 and the web server comes back to life. ??? Scratching my head... Originally Posted by: Steven A few quick things to check: 1 - That when on 8043, the WebServerListenUri does NOT have the URL spelled out: <add key="WebServerListenUri" value="https://+:8043/" /> 2 - That you've bound your SSL certificate to port 8043 as well as 443: https://help.screenconne...L_certificate_on_Windows (replace 443 with 8043 in the instructions) 3 - Ensure your site firewall has the external ports forwarded to the server (80 and 443). 4 - Ensure your windows firewall, if enabled, has rules added for 80 and 443 to allow them in as well, and create a new rule for ports 8041 and 8043 to allow, enabling Edge Transversal (http://forum.screenconnect.com/yaf_postsm30513_Shared-Relay.aspx#post30513).


User Profile View All Posts by User View Thanks

Alexander		#56 Posted : Tuesday, January 10, 2017 8:45:21 PM(UTC)
Rank: Administration Medals: Joined: 7/23/2013(UTC) Posts: 715 Location: Raleigh, NC Was thanked: 66 time(s) in 63 post(s)		One thing that stands out to me is the "Elsinore."s in your web.config changes; try taking those out, so it's just type="ScreenConnect.RoutingConfigurationHandler, ScreenConnect.Server"
		ScreenConnect Team


User Profile View All Posts by User View Thanks

dkitchens		#57 Posted : Tuesday, January 10, 2017 9:07:03 PM(UTC)
Rank: Guest Joined: 1/9/2017(UTC) Posts: 7 Thanks: 2 times		I noticed that this morning and have changed it with no effect. When I run netstat -an when the webserverlistenuri is set to 8043 I see nothing at all running on 443 where the web gui should be running. When webserverlistenuri is set to 443, 443 shows up in netstat as listening. Here are the liines that I have added so far, maybe I am missing something else? <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> <add name="HttpsRedirectModule" type="HttpsRedirectModule" /> <add key="WebServerListenUri" value="https://+:8043/" /> <add key="WebServerAlternateListenUri" value="http://connect.domain.com:80/" /> <add key="RelayListenUri" value="relay://+:8041/" /> <add key="WebServerAddressableURI" value="https://connect.domain.com:443/" /> <add key="RelayAddressableUri" value="https://connect.domain.com/" /> Originally Posted by: Alexander One thing that stands out to me is the "Elsinore."s in your web.config changes; try taking those out, so it's just type="ScreenConnect.RoutingConfigurationHandler, ScreenConnect.Server"


User Profile View All Posts by User View Thanks

dkitchens		#58 Posted : Tuesday, January 10, 2017 9:23:39 PM(UTC)
Rank: Guest Joined: 1/9/2017(UTC) Posts: 7 Thanks: 2 times		Here is netstat -an results, first one is with webserverlistenuri set to 8043 and second is set to 443 Y:\>netstat -an Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:80 0.0.0.0:0 LISTENING TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING TCP 0.0.0.0:5120 0.0.0.0:0 LISTENING TCP 0.0.0.0:8041 0.0.0.0:0 LISTENING TCP 0.0.0.0:8043 0.0.0.0:0 LISTENING TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING TCP 0.0.0.0:49175 0.0.0.0:0 LISTENING TCP 0.0.0.0:49181 0.0.0.0:0 LISTENING TCP 0.0.0.0:49183 0.0.0.0:0 LISTENING TCP 10.8.53.20:139 0.0.0.0:0 LISTENING TCP 10.8.53.20:3389 10.28.158.102:61614 ESTABLISHED TCP 10.8.53.20:49210 10.8.96.126:445 ESTABLISHED TCP 10.8.53.20:49292 10.8.0.18:135 TIME_WAIT TCP 10.8.53.20:49293 10.8.0.18:49159 TIME_WAIT TCP 10.8.53.20:49299 52.202.11.141:443 ESTABLISHED TCP 10.8.53.20:49300 10.8.0.18:445 ESTABLISHED TCP [::]:80 [::]:0 LISTENING TCP [::]:135 [::]:0 LISTENING TCP [::]:445 [::]:0 LISTENING TCP [::]:3389 [::]:0 LISTENING TCP [::]:8041 [::]:0 LISTENING TCP [::]:8043 [::]:0 LISTENING TCP [::]:47001 [::]:0 LISTENING TCP [::]:49152 [::]:0 LISTENING TCP [::]:49153 [::]:0 LISTENING TCP [::]:49154 [::]:0 LISTENING TCP [::]:49175 [::]:0 LISTENING TCP [::]:49181 [::]:0 LISTENING TCP [::]:49183 [::]:0 LISTENING UDP 0.0.0.0:123 : UDP 0.0.0.0:500 : UDP 0.0.0.0:4500 : UDP 10.8.53.20:137 : UDP 10.8.53.20:138 : UDP 10.8.53.20:57072 : UDP 10.8.53.20:57073 : UDP 127.0.0.1:55051 : UDP 127.0.0.1:55336 : UDP 127.0.0.1:55337 : UDP 127.0.0.1:55340 : UDP 127.0.0.1:58402 : UDP [::]:123 : UDP [::]:500 : UDP [::]:4500 : Y:\>netstat -an Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:80 0.0.0.0:0 LISTENING TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:443 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING TCP 0.0.0.0:5120 0.0.0.0:0 LISTENING TCP 0.0.0.0:8041 0.0.0.0:0 LISTENING TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING TCP 0.0.0.0:49175 0.0.0.0:0 LISTENING TCP 0.0.0.0:49181 0.0.0.0:0 LISTENING TCP 0.0.0.0:49183 0.0.0.0:0 LISTENING TCP 10.8.53.20:139 0.0.0.0:0 LISTENING TCP 10.8.53.20:443 10.28.158.102:63429 CLOSE_WAIT TCP 10.8.53.20:443 10.28.158.102:63435 ESTABLISHED TCP 10.8.53.20:443 10.28.158.102:63437 ESTABLISHED TCP 10.8.53.20:3389 10.28.158.102:61614 ESTABLISHED TCP 10.8.53.20:49210 10.8.96.126:445 ESTABLISHED TCP 10.8.53.20:49299 52.202.11.141:443 TIME_WAIT TCP 10.8.53.20:49302 52.202.11.141:443 ESTABLISHED TCP [::]:80 [::]:0 LISTENING TCP [::]:135 [::]:0 LISTENING TCP [::]:443 [::]:0 LISTENING TCP [::]:445 [::]:0 LISTENING TCP [::]:3389 [::]:0 LISTENING TCP [::]:8041 [::]:0 LISTENING TCP [::]:47001 [::]:0 LISTENING TCP [::]:49152 [::]:0 LISTENING TCP [::]:49153 [::]:0 LISTENING TCP [::]:49154 [::]:0 LISTENING TCP [::]:49175 [::]:0 LISTENING TCP [::]:49181 [::]:0 LISTENING TCP [::]:49183 [::]:0 LISTENING UDP 0.0.0.0:123 : UDP 0.0.0.0:500 : UDP 0.0.0.0:4500 : UDP 10.8.53.20:137 : UDP 10.8.53.20:138 : UDP 10.8.53.20:61948 : UDP 10.8.53.20:61949 : UDP 127.0.0.1:55051 : UDP 127.0.0.1:55336 : UDP 127.0.0.1:55337 : UDP 127.0.0.1:55340 : UDP 127.0.0.1:58402 : UDP 127.0.0.1:59475 : UDP [::]:123 : UDP [::]:500 : UDP [::]:4500 :


User Profile View All Posts by User View Thanks

Alexander		#59 Posted : Tuesday, January 10, 2017 10:49:21 PM(UTC)
Rank: Administration Medals: Joined: 7/23/2013(UTC) Posts: 715 Location: Raleigh, NC Was thanked: 66 time(s) in 63 post(s)		Quote: <add key="WebServerAlternateListenUri" value="http://connect.domain.com:80/" /> Try removing that line; it seems like it'd interfere with the router, since that's also trying to listen on port 80.
		ScreenConnect Team


User Profile View All Posts by User View Thanks

dkitchens		#60 Posted : Wednesday, January 11, 2017 4:31:52 PM(UTC)
Rank: Guest Joined: 1/9/2017(UTC) Posts: 7 Thanks: 2 times		I removed the line and the same thing happens, I do not believe the router service is doing anything, no port 80 or 443 are listening. Y:\>netstat -an Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING TCP 0.0.0.0:5120 0.0.0.0:0 LISTENING TCP 0.0.0.0:8041 0.0.0.0:0 LISTENING TCP 0.0.0.0:8043 0.0.0.0:0 LISTENING TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING TCP 0.0.0.0:49175 0.0.0.0:0 LISTENING TCP 0.0.0.0:49181 0.0.0.0:0 LISTENING TCP 0.0.0.0:49183 0.0.0.0:0 LISTENING TCP 10.8.53.20:139 0.0.0.0:0 LISTENING TCP 10.8.53.20:3389 10.28.158.102:61614 ESTABLISHED TCP 10.8.53.20:49210 10.8.96.126:445 ESTABLISHED TCP 10.8.53.20:50017 52.202.11.141:443 ESTABLISHED TCP 10.8.53.20:50018 10.8.96.33:445 ESTABLISHED TCP 10.8.53.20:50022 10.8.0.18:445 ESTABLISHED TCP [::]:135 [::]:0 LISTENING TCP [::]:445 [::]:0 LISTENING TCP [::]:3389 [::]:0 LISTENING TCP [::]:8041 [::]:0 LISTENING TCP [::]:8043 [::]:0 LISTENING TCP [::]:47001 [::]:0 LISTENING TCP [::]:49152 [::]:0 LISTENING Originally Posted by: Alexander Quote: <add key="WebServerAlternateListenUri" value="http://connect.domain.com:80/" /> Try removing that line; it seems like it'd interfere with the router, since that's also trying to listen on port 80.


User Profile View All Posts by User View Thanks

Alexander		#61 Posted : Wednesday, January 11, 2017 4:49:57 PM(UTC)
Rank: Administration Medals: Joined: 7/23/2013(UTC) Posts: 715 Location: Raleigh, NC Was thanked: 66 time(s) in 63 post(s)		It sounds like the router service just isn't running… hmm, you mentioned your web.config changes, but did you also make the registry change from the second post in this thread? Or if you look at Windows Logs > Application in Event Viewer, do you see any exceptions from the Router service?
		ScreenConnect Team


User Profile View All Posts by User View Thanks

dkitchens		#62 Posted : Wednesday, January 11, 2017 5:02:57 PM(UTC)
Rank: Guest Joined: 1/9/2017(UTC) Posts: 7 Thanks: 2 times		Yes, I made the regedit and I see a Screenconnect Router service but it starts and stops immediately as I mentioned earlier. Hrm, I may have just got it working. When I was making changes and restarting the Screenconnect Session Manager it was not trying to restart the Router too. I set web.config to 8043 and removed the altwebserveruri line, restarted services and then manually started the Router Service and it stayed running this time. netstat is happy right now as well. This is on my test server and I will now have to try the production server later tonight. Originally Posted by: Alexander It sounds like the router service just isn't running… hmm, you mentioned your web.config changes, but did you also make the registry change from the second post in this thread? Or if you look at Windows Logs > Application in Event Viewer, do you see any exceptions from the Router service?


User Profile View All Posts by User View Thanks

dkitchens		#63 Posted : Monday, January 16, 2017 3:08:12 PM(UTC)
Rank: Guest Joined: 1/9/2017(UTC) Posts: 7 Thanks: 2 times		I got it all working on the production system and it was not difficult on that machine once I had the right configuration. With the fact that a lot of EMEA companies restrict outbound ports, I think you guys should make this a default setup. We have had several times when our techs have had to use another tool because the customer had ports blocked and could not connect to ScreenConnect.


User Profile View All Posts by User View Thanks

marktoo		#64 Posted : Monday, January 16, 2017 3:27:29 PM(UTC)
Rank: Advanced Member Medals: Joined: 3/29/2015(UTC) Posts: 100 Location: Metro DC Thanks: 27 times Was thanked: 10 time(s) in 8 post(s)		Originally Posted by: dkitchens With the fact that a lot of EMEA companies restrict outbound ports, I think you guys should make this a default setup. Agreed!
		WWW
1 user thanked marktoo for this useful post.		dkitchens on 1/16/2017(UTC)
User Profile View All Posts by User View Thanks

Alexander		#65 Posted : Monday, January 16, 2017 4:52:09 PM(UTC)
Rank: Administration Medals: Joined: 7/23/2013(UTC) Posts: 715 Location: Raleigh, NC Was thanked: 66 time(s) in 63 post(s)		Glad to hear you got it working! We've had requests to make this default before, so I'll add your +1s to that ticket.
		ScreenConnect Team

1 user thanked Alexander for this useful post.		dkitchens on 1/16/2017(UTC)
User Profile View All Posts by User View Thanks

RdWing		#66 Posted : Thursday, February 2, 2017 9:42:50 AM(UTC)
Rank: Guest Joined: 11/11/2016(UTC) Posts: 5 Location: SF Bay Area		Has this been updated/tested working for linux servers? I host my SC on AWS...


User Profile View All Posts by User View Thanks

Alexander		#67 Posted : Thursday, February 2, 2017 3:47:59 PM(UTC)
Rank: Administration Medals: Joined: 7/23/2013(UTC) Posts: 715 Location: Raleigh, NC Was thanked: 66 time(s) in 63 post(s)		I'm afraid not, sorry.
		ScreenConnect Team


User Profile View All Posts by User View Thanks

ctaylor95		#68 Posted : Sunday, September 16, 2018 11:49:46 PM(UTC)
Rank: Guest Joined: 3/7/2018(UTC) Posts: 2		Any update on the Linux support?


User Profile View All Posts by User View Thanks

ctaylor95		#69 Posted : Sunday, September 16, 2018 11:50:44 PM(UTC)
Rank: Guest Joined: 3/7/2018(UTC) Posts: 2		Any update on the Linux support?


User Profile View All Posts by User View Thanks

Users browsing this topic

2 Pages<12

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.