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

Notification

Icon
Error

Options
Go to last post Go to first unread
mjolly803  
#1 Posted : Wednesday, June 14, 2017 8:17:46 PM(UTC)
mjolly803


Rank: Guest

Joined: 11/7/2016(UTC)
Posts: 5
United States
Location: Charlotte, NC

Thanks: 2 times
We are current using Control version 6.2.12963.6312 self hosted. We changed the listen ports from the default 8040 & 8041 upon deployment. For our instance we have the Web Server setup to listen on port 443 (with an SSL cert for the portal website) and the Relay listening on port 80. Most of the people connecting to Meeting and Support sessions have no issues at all, so it seems configuration wise we are in a good configuration.

We have run into a couple folks that have tried to connect to a Meeting session and been met with difficulty. We have one we are working with specifically right now who has verified both ports are open in their firewall. They can reach the URL for the website, enter the code, click Join, then enter their name and submit that to start their connection to the session. Upon doing that they are met with the following message:

Unable to read beyond the end of the stream.

With most other users working without issue, it seems like the config is fine and the user has verified their firewall is not restricting those ports, so at this point we are looking for some guidance on the cause/next steps.

Thanks!
Scott  
#2 Posted : Monday, June 26, 2017 11:40:26 AM(UTC)
Scott


Rank: Administration

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

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

Thanks: 3 times
Was thanked: 304 time(s) in 261 post(s)
So, typically we recommend running the relay on port 443 if possible. The reason for this is likely what you're seeing, some firewalls do not like encrypted traffic coming across on the standard HTTP port. Often times they will attempt to scan/inspect it, which causes the connection issue you're seeing.

If possible, I recommend seeing if the customer can white-list traffic to/from your ScreenConnect server's IP address along port 80.

If that's too much of a hassle, you can always configure both ScreenConnect services to bind to port 443 as long as you can assign the machine a second IP address.

Finally, and I want to emphasize that this is not officially supported, but you can setup the ScreenConnect Router to allow both services to bind to the same port/address. We have a forum post outlining the process here. This is a pretty advanced customization so if you run into trouble please post questions here or within that other thread.
ScreenConnect Team
thanks 1 user thanked Scott for this useful post.
mjolly803 on 7/6/2017(UTC)
mjolly803  
#3 Posted : Thursday, July 6, 2017 1:41:43 PM(UTC)
mjolly803


Rank: Guest

Joined: 11/7/2016(UTC)
Posts: 5
United States
Location: Charlotte, NC

Thanks: 2 times
Thanks for the information. We will need to go the 2nd route of binding the ScreenConnect relay service to port 443 as we have seen this issue with a few different customers so the whitelist at each will be a hassle. We have assigned the ScreenConnect server a 2nd IP address and I'm familiar with the RelayListenURI value in the web.config to bind that service to a port. My question though is, how to I bind it to that port on the 2nd IP address specifically?
mjolly803  
#4 Posted : Friday, July 7, 2017 11:48:39 AM(UTC)
mjolly803


Rank: Guest

Joined: 11/7/2016(UTC)
Posts: 5
United States
Location: Charlotte, NC

Thanks: 2 times
Scott - We tried this early this morning with both a 2nd IP assigned to the existing NIC in Windows and by adding a separate NIC to the VM and assigning the 2nd IP to it. In both cases the Relay service starts and immediately stops showing the following error in the Application event log.

Failed to start service: System.InvalidOperationException: Unable to listen on end point: 192.168.201.75:443 ---> System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at ScreenConnect.SocketServer.Startup(IEnumerable`1 listenEndPoints)
--- End of inner exception stack trace ---
at ScreenConnect.SocketServer.Startup(IEnumerable`1 listenEndPoints)
at ScreenConnect.Relay.Startup()
at ScreenConnect.AppDomainServiceRoot.Startup()
at ScreenConnect.AppDomainServiceBase.StartServiceInternal()
at ScreenConnect.AppDomainConfigurationService.StartServiceInternal()
at ScreenConnect.ServiceBaseEx.StartService()

Below is the configuration we are attempting to use in the web.config file. Any further guidance would be much appreciated.

<add key="WebServerListenUri" value="https://xxx.xxx.xxx.65:443/" />
<add key="WebServerAddressableUri" value="https://assist.ourdomain.com/" />
<add key="RelayListenUri" value="relay://xxx.xxx.xxx.75:443/" />
<add key="RelayAddressableUri" value="relay://assistrelay.ourdomain.com:443/" />
Scott  
#5 Posted : Friday, July 7, 2017 12:24:45 PM(UTC)
Scott


Rank: Administration

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

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

Thanks: 3 times
Was thanked: 304 time(s) in 261 post(s)
Try adding the IP address for the webserverlistenuri to the ip inclusion list:

netsh http add iplisten x.x.x.x
ScreenConnect Team
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.