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

Notification

Icon
Error

Options
Go to last post Go to first unread
aaronberger  
#1 Posted : Monday, July 30, 2018 3:23:32 AM(UTC)
aaronberger


Rank: Guest

Joined: 7/25/2018(UTC)
Posts: 6
Australia
Location: Melbourne

Hi Guys,

I've been reading up on this topic for the last week to figure out the best and simplest way to implement it. The main reason I need to change is I find some networks block the standard 8040 and 8041 ports, or if you use non-encrypted ports in general, making it harder to connect to clients on some networks. I figure the best way to solve this is to move both the Screenconnect listen and relay ports 443 or 80 with SSL enabled.

I currently have Labtech 12 on a Windows 2008R2 server and have Screenconnect deployed on the same server. I also have an SSL cert deployed.
I've recently setup Screenconnect SSL piggybacking and have changed the WebServerListenUri from port 8040 to 443 on SSL. This is working perfectly.

However, changing the RelayListenUri port from 8081 to 443 or 80, I am finding harder to understand how to do.
Through my reading in the forums I understand that using the "Router" function (built into Screenconnect 5x and newer) with a shared relay, might be the easiest way to do it:
Post1 example: http://controlforum.conn...red-Relay.aspx#post18410
Post2 example: https://controlforum.con...y-and-web-interface.aspx

So, I have a couple of questions:
1. Am I ok to use port 443 for both the WebServerListenUri and RelayListenUri, with the Router fuctionality, or do I need to use a different port? What are the best ports to use for the listen and the relay?
2. Has anyone configured the Router with the Screenconnect and Labtech setup and got it working? What steps do I need to perform to get it working? Also, do I need to modify my firewall rules too?

Any help to point me in the right direct would be greatly appreciated. :-)

Kind regards
Aaron
aaronberger  
#2 Posted : Tuesday, July 31, 2018 3:02:16 AM(UTC)
aaronberger


Rank: Guest

Joined: 7/25/2018(UTC)
Posts: 6
Australia
Location: Melbourne

Ahh I think I might have my head around it better. I've decided to go with 443 for the listen and replay ports and not use the Router function.

I decided 443 for both because I hopefully shouldn't get blocked as much on corporate networks. I could use 80 for the relay, but 443 feels like a good choice.
I don't believe the relay has the ability to use SSL, but the traffic is encrypted anyway (unless that has changed in version 6x ?).
To achieve using 443 on the listen and relay ports I believe you need 2x public IP and 2x private IP.
--Listen (HTTPS using SSL piggybacking): Public IP1 > 443 rule set in the firewall > Private IP1
-- Relay: Public IP2 > 443 rule set in the firewall > Private IP2
(I understand there is a Router function, but I'm not sure it's possible to use it when you're already using Labtech on the same server (but if I'm wrong, let me know).)

The best thread I could find on this setup is this one (it's a little old but seems the best option if you can afford 2x public IP): Thread: https://controlforum.con...-redirect-from-HTTP.aspx

I hope this helps anyone who's in the same scenario. I'll do a bit more reading over the next few days and see if I can find any other useful threads or other ways to deploy, then try to implement over the weekend.
Michael L  
#3 Posted : Tuesday, July 31, 2018 12:42:45 PM(UTC)
Michael L


Rank: Administration

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

Joined: 8/18/2015(UTC)
Posts: 88
Man
United States

Thanks: 9 times
Was thanked: 13 time(s) in 11 post(s)
Originally Posted by: aaronberger Go to Quoted Post
Ahh I think I might have my head around it better. I've decided to go with 443 for the listen and replay ports and not use the Router function.

I decided 443 for both because I hopefully shouldn't get blocked as much on corporate networks. I could use 80 for the relay, but 443 feels like a good choice.
I don't believe the relay has the ability to use SSL, but the traffic is encrypted anyway (unless that has changed in version 6x ?).
To achieve using 443 on the listen and relay ports I believe you need 2x public IP and 2x private IP.
--Listen (HTTPS using SSL piggybacking): Public IP1 > 443 rule set in the firewall > Private IP1
-- Relay: Public IP2 > 443 rule set in the firewall > Private IP2
(I understand there is a Router function, but I'm not sure it's possible to use it when you're already using Labtech on the same server (but if I'm wrong, let me know).)

The best thread I could find on this setup is this one (it's a little old but seems the best option if you can afford 2x public IP): Thread: https://controlforum.con...-redirect-from-HTTP.aspx

I hope this helps anyone who's in the same scenario. I'll do a bit more reading over the next few days and see if I can find any other useful threads or other ways to deploy, then try to implement over the weekend.


The relay is encrypted with AES-256 block encryption out of the box, regardless of the port you use, and you can't encapsulate it in SSL at this time. You likely won't be able to use the router service if you're hosting Control on the same server as Automate and also won't be able to use dual IPs for the web/relay service because Automate binds to ports 80/443 on all IPs. The router service or relay would need to bind directly to 443, which is the reason you have to use piggybacking for SSL if you host them together and want the web traffic on port 443. It might be possible to modify the Automate bindings somehow so that it only binds to a single IP, but I don't have any guides readily available for how to do this (nor do I know it's even possible to do), or also might be possible to use dual IPs if you bind IP2 to a different port internally like 8041, and you just forward the traffic for that IP only from 443 > 8041. You'll need to set up the RelayAddressableUri key as well.

443 is a good choice for the relay traffic on most occasions as it will give you the least amount of trouble getting through firewalls, although you will still occasionally notice issues with aggressive firewalls and/or content/web filters - especially if these devices are trying to do TLS/SSL decryption (effectively a man in the middle attack on the network's own traffic). In those one-off scenarios, you'll need to get whitelist entries added for your URLs into those devices.

Based on what you're trying to do, it may be easier and you may benefit from moving Control over to its own server, which we actually recommend to do if you have around 1,000+ deployed agents for performance reasons. If you were to do this and you have 2 public IPs already, then you could configure the router service on the new server as a quick and easy way to use both ports 80 and 443 with a built-in redirect along with 443 for the relay.

I hope this helps :)
ConnectWise Control (ScreenConnect) Support Team
aaronberger  
#4 Posted : Wednesday, August 1, 2018 11:30:44 PM(UTC)
aaronberger


Rank: Guest

Joined: 7/25/2018(UTC)
Posts: 6
Australia
Location: Melbourne

Hi Michael,

Many thanks for taking the time to reply to my post. This information is very helpful. Based on what you have said I think you are right and it's best if I spin up another server to run Screenconnect. I'll built a test server this weekend. :)
Thanks for your help.

Kind regards
Aaron
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.