logo

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

Icon
Error

Options
Go to last post Go to first unread
fthomasr  
#1 Posted : Friday, March 15, 2013 9:52:10 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
I currently have our Screenconnect server with the Web Server using port 80 and the Relay using port 443. We have many customers with firewalls that ONLY allow those ports.

I don't like the idea of my login name/password passing in the clear coupled with the fact that I want our more security conscious customers to feel comfortable with a certificate/ssl/encrypted protected guest page. I would like to purchase a certificate and bind it to the Web Server while changing the port it listens on to 443. However, I also need customers/technicians to be able to type in HTTP://oursupportsite and have screenconnect redirect or rewrite the URL to HTTPS://oursupportsite . While I have seen at least one post that describes how to do this by Jake, it was under the assumption that the Relay port was NOT using port 80 but instead 8041. I need to use 80 for the relay (or even 443 ALSO, if it will work that way.) It doesn't matter so long as its 443 or 80 for relay and 443 for the web server.

I have also seen a post where someone suggests assigning an additional IP to the screenconnect server's network interface. I'd rather not do that either as I'm 99% sure I'd have to use ANOTHER precious external static IP to port forward to that additional internal IP, of which I don't have many left.

I'm not fond of major changes to the default code included with screenconnect because I fear it will be something easily broken with future updates, and will make me gun shy in performing them. I really want to update to take advantage of features in the future.

Please advise.

bigdessert  
#2 Posted : Friday, March 15, 2013 10:33:39 PM(UTC)
bigdessert


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 3: Shirt off your back! Received 25 Thanks!

Joined: 9/13/2010(UTC)
Posts: 708
Location: Minnesota

Thanks: 1 times
Was thanked: 44 time(s) in 32 post(s)
You can run the relay on port 80 and web on 443. The problem lies when a client hits your web server on port 80 it will not respond. So unless you make sure all clients use https and not http you can just stop here.

I have tried this extensively and the only possible method I have found is to have 2 IP's on the SC server so that 80 is bound to IP1 for web server and 80 for relay and 443 for web are bound to IP2.
Sean  
#3 Posted : Tuesday, April 9, 2013 10:22:13 AM(UTC)
Sean


Rank: Administration

Medals: Level 3: Shirt off your back! Received 25 Thanks!

Joined: 4/16/2010(UTC)
Posts: 441
Location: Raleigh

Thanks: 5 times
Was thanked: 38 time(s) in 33 post(s)
bigdessert is absolutely correct in his analysis. You will have to ensure your clients join sessions via (https://yoursite.screenconnect.).
ScreenConnect Team
fthomasr  
#4 Posted : Tuesday, April 9, 2013 9:51:02 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
First, thanks bigdessert for your response.

Sean wrote:
bigdessert is absolutely correct in his analysis. You will have to ensure your clients join sessions via (https://yoursite.screenconnect.).


Ok. After asking phone support for the solution to do this I was referred to the 'forum' as this was 'Advanced Customization', which annoyed me. Why? First of all, this should be the STANDARD way the product should be configured out of the box. More than ever the Internet is a scary place to do business and other users on this forum have also posted that inputing logins and passwords in plaintext across the internet on port 80 is DANGEROUS. Not only that if you use ports 80 + 443 99.9% of firewalls are going to allow that traffic through. For the life of me I can't figure out why it's not like this by default. Heck $40 Linksys, Netgear, Dlink routers come this way out of the box. Anything this day and age that has a WebGUI ALWAYS has a default option of 443 out of the box!! Not only that they usually have a built in certificate which negates the need to buy a certificate (which I don't mind doing, but still). So fine we try to figure it out as consumers of your product on our own. Well because you don't use IIS, but your own custom code in .Net or whatever it is, you can't search out there and find answers away from Screenconnect easily! So we are stuck with the FAQ and the forum. Second it's not 'Advanced Customization'. I'm not asking to have my logo bounce up and down spin around, have 6 factor authentication, be rewritten in Java, AJAX, or whatever, etc.

So after patiently waiting almost a month for an official answer, and having Mike Bannerman email me to tell me that the development team is looking into my post, and paying for my two licenses last week this is the official support response I get. Now I'm aggravated and annoyed.

1. Did you read bigdessert's post at all Sean? He does suggest a way to do it via dual IPs.
2. I suggested the dual IPs method in my original post. If this is true please explain exactly HOW to do it, and if I will have to use an additional external IP. I mean its not like you can just throw an secondary IP and point your router to screenconnect, there will be code changes, and because it's not using IIS......well see above.
3. A 5 to 10 minute phone call would have been easier to both explain what I want and get a response with followups with support. After which if a solution is offered, support can ADD it to the FAQ rather than say, if you post it on our forum it will be seen by all, which is not the same as forum is only as good as it's search engine and is a disorganized hodgepod. I love forums, but nothing beats a knowledgebase or FAQ.
4. Email support directly would be a great option for this.
5. A call back when 'we(support) are not busy' would also be acceptable. This is how Digium does it, when they deem a support issue not vital. You can call and if their lines are free they will answer you or they will call you back when they are slow, which can take a while. Fine by me.


Edited by user Tuesday, April 9, 2013 9:51:39 PM(UTC)  | Reason: Not specified

DrM  
#5 Posted : Saturday, April 13, 2013 4:47:25 PM(UTC)
DrM


Rank: Newbie

Joined: 4/13/2013(UTC)
Posts: 1
Location: CA

I think another solution to this issue may be having a subdomain set up with a forwarding html page that takes the user to the ssl secured web portal so the user can type in a quick url and not need to add the https. For example, support.mysite.com takes the user to a page with a meta tag like:

Code:
<meta HTTP-EQUIV="Refresh" CONTENT="0; URL=https://anyothersubdomain.mysite.com">


It's not the smoothest solution ever but I think it would do the trick. The web port is 443. The relay port is 80. Anyothersubdomain.mysite.com points to the IP of your SC server. Your password isn't passed in plain text. It works on nearly every firewall out there. It's easy to set up and easy for users to access...

Any thoughts?
brandonsstanley  
#6 Posted : Saturday, April 13, 2013 11:24:16 PM(UTC)
brandonsstanley


Rank: Newbie

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 4/13/2013(UTC)
Posts: 7

Was thanked: 1 time(s) in 1 post(s)
I considered the several options I discovered when searching for a solution to this problem. I ended up using the nginx solution as described below... however I get the following results from the External Accessibility Check on the Status Tab of the Administration Page:

Web Server Test URL:https://support.mydomain.com/
Web Server Error: Unrecognized server. Not ScreenConnect Web Server.

Relay Test URL: relay://support.mydomain.com:8041/
Relay Error:

Can this problem be safely ignored... It doesn't seem to affect any functionality but its entirely unsatisfying to have the red error indicator and any advice would be appreciated

Quote:
ScreenConnect works very well with a fast free proxy called nginx.

Here's the config file if interested, I'll be putting it up on my wiki but it is useful information for anyone who wants a quick easy way to make the portal have SSL.

I chose to leave the relay port at 8041.. nginx redirects customer to port 443 if they go to the site on 80.



Code:
server {
        listen 80;
        server_name <FQDN>;
        rewrite ^ https://<FQDN> permanent;
}

server {
        listen 443;
        server_name <FQDN>;
        ssl on;
        ssl_certificate <CERTIFICATE FILE>;
        ssl_certificate_key <CERTIFICATE KEY FILE>;
        keepalive_timeout 70;
        root <EMPTY DIRECTORY>
        location / {
                proxy_pass http://localhost:8040/;
                proxy_redirect default;
        }
}



fthomasr  
#7 Posted : Sunday, April 14, 2013 6:11:39 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
DrM wrote:
I think another solution to this issue may be having a subdomain set up with a forwarding html page that takes the user to the ssl secured web portal so the user can type in a quick url and not need to add the https. For example, support.mysite.com takes the user to a page with a meta tag like:

Code:
<meta HTTP-EQUIV="Refresh" CONTENT="0; URL=https://anyothersubdomain.mysite.com">


It's not the smoothest solution ever but I think it would do the trick. The web port is 443. The relay port is 80. Anyothersubdomain.mysite.com points to the IP of your SC server. Your password isn't passed in plain text. It works on nearly every firewall out there. It's easy to set up and easy for users to access...

Any thoughts?


Bad thing about that is I registered a nice neat domain name for my customers. Adding an additional subdomain is not good because it complicates what you tell them over the phone to type in and unfortunately they seem to mess up the simple one I have now more often than not!

Second, I've already bought a certificate for the domain. Subdomain is no good unless I bought it that way to begin with, and no I'm not buying a wildcard cert.


fthomasr  
#8 Posted : Sunday, April 14, 2013 6:21:01 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
brandonsstanley wrote:
I considered the several options I discovered when searching for a solution to this problem. I ended up using the nginx solution as described below... however I get the following results from the External Accessibility Check on the Status Tab of the Administration Page:

Web Server Test URL:https://support.mydomain.com/
Web Server Error: Unrecognized server. Not ScreenConnect Web Server.

Relay Test URL: relay://support.mydomain.com:8041/
Relay Error:

Can this problem be safely ignored... It doesn't seem to affect any functionality but its entirely unsatisfying to have the red error indicator and any advice would be appreciated

Quote:
ScreenConnect works very well with a fast free proxy called nginx.

Here's the config file if interested, I'll be putting it up on my wiki but it is useful information for anyone who wants a quick easy way to make the portal have SSL.

I chose to leave the relay port at 8041.. nginx redirects customer to port 443 if they go to the site on 80.



Code:
server {
        listen 80;
        server_name <FQDN>;
        rewrite ^ https://<FQDN> permanent;
}

server {
        listen 443;
        server_name <FQDN>;
        ssl on;
        ssl_certificate <CERTIFICATE FILE>;
        ssl_certificate_key <CERTIFICATE KEY FILE>;
        keepalive_timeout 70;
        root <EMPTY DIRECTORY>
        location / {
                proxy_pass http://localhost:8040/;
                proxy_redirect default;
        }
}





For one, this runs the relay on a non standard port(not 80 or 443). Second this overly complicates the setup. Avoid proxies when you can.

I found a very neat solution this weekend which I will implement and post a how to when I do it. Unfortunately it requires a secondary external IP address and the installation of IIS, but it is really neat and easy with no code modification of screenconnect which will upgrade proof it as well. One cool extra feature of this setup in addition to an automatic redirect of HTTP to HTTPS is also if your user types www.domainname.com it will redirect them to domainname.com or in other words ANYTHING they type OTHER than what you want redirects them to what you want. They could type http://screenconnectiscool.domainname.com and it will redirect to desired your domainname.com, not too mention httpS://domainname.com.
gb5102  
#9 Posted : Friday, April 19, 2013 5:23:44 PM(UTC)
gb5102


Rank: Advanced Member

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

Joined: 3/14/2013(UTC)
Posts: 42
Location: USA

Thanks: 13 times
Was thanked: 2 time(s) in 2 post(s)
Quote:
I found a very neat solution this weekend which I will implement and post a how to when I do it. Unfortunately it requires a secondary external IP address and the installation of IIS, but it is really neat and easy with no code modification of screenconnect which will upgrade proof it as well. One cool extra feature of this setup in addition to an automatic redirect of HTTP to HTTPS is also if your user types www.domainname.com it will redirect them to domainname.com or in other words ANYTHING they type OTHER than what you want redirects them to what you want. They could type http://screenconnectiscool.domainname.com and it will redirect to desired your domainname.com, not too mention httpS://domainname.com.



Sounds interesting, can't wait to hear what you've come up with.
charisis  
#10 Posted : Monday, April 22, 2013 2:46:47 AM(UTC)
charisis


Rank: Member

Joined: 2/12/2013(UTC)
Posts: 18

If you can afford a second public IP address, you could try the following middle ground solution (haven't tried it, but should theoretically work):

- Have ScreenConnect bind it's relay service on some port (maybe 80?) on that secondary ip (let's say relay.yourdomain.com).
- Have ScreenConnect bind it's web interface on your primary ip (www.yourdomain.com?) on 443/https.
- ScreenConnect seems to be able to have a secondary binding for its web. Try the "WebServerAlternateListenUri" configuration key and have that bind on the primary ip, 80/http

With this setup you'll have an https endpoint for security conscious customers and host access. Port 80 will still be reachable and work as expected BUT it won't forward to https.

About the rest of the featureset discussed, I don't think you'll be able to set up http redirects without setting up a proper http server in front of ScreenConnect. That's kind of expected to be honest.

What you can do though is use DNS cnames to have screenconnectis.domainname.com or whatever other domain point to your www.domainname.com.


Let us know if it works in case you decide to try it out.
fthomasr  
#11 Posted : Saturday, June 22, 2013 7:23:41 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
I haven't forgotten to implement this, I just haven't had time. I bought the certificate weeks ago. I've been on a couple of vacations and we've gotten busy. I should be able to try it out within the next couple of weeks...
bblankenship78  
#12 Posted : Friday, June 28, 2013 9:43:31 AM(UTC)
bblankenship78


Rank: Member

Joined: 1/10/2012(UTC)
Posts: 11

As suggested above, we implemented 2 domains a while ago. Here's exactly what we did as you don't need to communicate your relay domain.

In this situation, I'm assuming your web and relay servers are the same box. Configure the web server to listen on 443 and the relay to listen on any other port, i.e. 8443.

Assume you have 2 IP Addresses on your firewall, 1.1.1.1 and 1.1.1.2. Route Ports 80 and 443 on 1.1.1.1 to your web port 80 and 443. Route 443 on 1.1.1.2 to your relay port 8443.

Then setup DNS for realycooldomain.com to 1.1.1.1 and the set relay.realycooldomain.com to 1.1.1.2.

Your webconfig will have several lines:

<add key="WebServerListenUri" value="https://+:443/" />
<add key="WebServerAlternateListenUri" value="http://+:80/" />
<add key="RelayListenUri" value="relay://0.0.0.0:8443/" />
<add key="WebServerAddressableUri" value="https://reallycooldomain.com/" />
<add key="RelayAddressableUri" value="relay://relay.reallycooldomain.com:443/" />

This allows the web server to listen on port 80 so you don't have to type in HTTPS and 443 for HTTPS. Create a redirect so if a client doesn't type in HTTPS, it automatically redirects them.

Hope this helps.
fthomasr  
#13 Posted : Saturday, June 29, 2013 12:11:01 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
bblankenship78 wrote:
As suggested above, we implemented 2 domains a while ago. Here's exactly what we did as you don't need to communicate your relay domain.

In this situation, I'm assuming your web and relay servers are the same box. Configure the web server to listen on 443 and the relay to listen on any other port, i.e. 8443.

Assume you have 2 IP Addresses on your firewall, 1.1.1.1 and 1.1.1.2. Route Ports 80 and 443 on 1.1.1.1 to your web port 80 and 443. Route 443 on 1.1.1.2 to your relay port 8443.

Then setup DNS for realycooldomain.com to 1.1.1.1 and the set relay.realycooldomain.com to 1.1.1.2.

Your webconfig will have several lines:

<add key="WebServerListenUri" value="https://+:443/" />
<add key="WebServerAlternateListenUri" value="http://+:80/" />
<add key="RelayListenUri" value="relay://0.0.0.0:8443/" />
<add key="WebServerAddressableUri" value="https://reallycooldomain.com/" />
<add key="RelayAddressableUri" value="relay://relay.reallycooldomain.com:443/" />

This allows the web server to listen on port 80 so you don't have to type in HTTPS and 443 for HTTPS. Create a redirect so if a client doesn't type in HTTPS, it automatically redirects them.

Hope this helps.


No it doesn't help. Again, ports 80 or 443 ONLY. No other ports. Any other port than these are far far more likely to be filtered. Not only that but you don't provide the mechanism for the redirect. That's the whole point of the thread! LOL
cingular  
#14 Posted : Sunday, June 30, 2013 2:03:07 PM(UTC)
cingular


Rank: Newbie

Joined: 10/13/2011(UTC)
Posts: 7
Location: Melbourne, FL

bblankenship78 wrote:
As suggested above, we implemented 2 domains a while ago. Here's exactly what we did as you don't need to communicate your relay domain.

In this situation, I'm assuming your web and relay servers are the same box. Configure the web server to listen on 443 and the relay to listen on any other port, i.e. 8443.

Assume you have 2 IP Addresses on your firewall, 1.1.1.1 and 1.1.1.2. Route Ports 80 and 443 on 1.1.1.1 to your web port 80 and 443. Route 443 on 1.1.1.2 to your relay port 8443.


Interesting concept about using two names/IP Addresses...but I don't see the need for having the relay being on port 8443? Since your using two domains and two IP Addresses, they can be on the same port.

fthomasr wrote:

No it doesn't help. Again, ports 80 or 443 ONLY. No other ports. Any other port than these are far far more likely to be filtered. Not only that but you don't provide the mechanism for the redirect. That's the whole point of the thread! LOL


The two domains/IP Addresses is a good solution to secure all traffic (Web and relay), but the example above uses a non-standard port which shouldn't be the case. I might give this a try this week when time permits.

Regarding the redirect, I'll see what can be done, but a quick/dirty way is to change the unsecure port to something else (I.E. 8080) so its not used, then put IIS or Apache on port 80 with the redirect/.htaccess file to point everything to the HTTPS Port. I'll see if I can test this week as well when time permits.
bblankenship78  
#15 Posted : Tuesday, July 2, 2013 12:05:16 AM(UTC)
bblankenship78


Rank: Member

Joined: 1/10/2012(UTC)
Posts: 11

I should have been more explicit. Only 1 service can listen on any given port. If your using port 443 and SSL, then the ScreenConnect relay cannot listen on 443 as well, hence, 8443. We have a firewall on our parameter of our network that has the capability of listening on multiple IP Addresses. In this example 1.1.1.1 and 1.1.1.2.

1.1.1.1:80 --------->10.101.101.20:80
1.1.1.1:443 --------->10.101.101.20:443

1.1.1.2:443 --------->10.101.101.20:8443

Both ports 80 and 443 are standard ports. What you listen to inside your network is immaterial.
fthomasr  
#16 Posted : Monday, July 8, 2013 7:56:02 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
I got my original plan implemented today. Works great! I had to call Screenconnect support about one part that they had to manually resolve but I can get them to post that here if you guys run into the same thing. I will post the how to very soon.
mvirnoche  
#17 Posted : Saturday, August 10, 2013 11:05:09 PM(UTC)
mvirnoche


Rank: Advanced Member

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

Joined: 7/31/2013(UTC)
Posts: 37
Location: USA

Was thanked: 1 time(s) in 1 post(s)
Can you post what ended up working for you in the end?
ComputerRepairTech  
#18 Posted : Sunday, August 11, 2013 6:23:08 AM(UTC)
ComputerRepairTech


Rank: Advanced Member

Joined: 7/25/2013(UTC)
Posts: 135
Location: Columbia, SC

Just want to remind people that you if you use screenconnect for tech support you are going to run into more people that can't access SSL sites than people that care about connecting to a secure site. Theres plenty of minor things that break SSL the most common being incorrect date.
teksigns  
#19 Posted : Sunday, August 11, 2013 8:45:14 AM(UTC)
teksigns


Rank: Advanced Member

Medals: Bug Buster Level Two: Bugs are more afraid of you than you are of them...ScreenConnect Advisor: Focus Group MemberLevel 2: Lent a Helping Hand! 10 Thanks!

Joined: 6/20/2011(UTC)
Posts: 457
United States
Location: Salisbury, NC (Aka: Gurusonwheels)

Thanks: 17 times
Was thanked: 15 time(s) in 14 post(s)
ComputerRepairTech wrote:
Just want to remind people that you if you use screenconnect for tech support you are going to run into more people that can't access SSL sites than people that care about connecting to a secure site. Theres plenty of minor things that break SSL the most common being incorrect date.



i agree it would be nice if screen connect could just use ssl on the login page .
DaveHTS  
#20 Posted : Sunday, August 11, 2013 6:21:28 PM(UTC)
DaveHTS


Rank: Newbie

Joined: 8/9/2013(UTC)
Posts: 7
Location: Illinois

teksigns wrote:



i agree it would be nice if screen connect could just use ssl on the login page .


This is essentially what I am trying to implement - SSL for techs to log on, clear HTTP for clients. I just cant get the web server to listen on both ports.
fthomasr  
#21 Posted : Friday, September 20, 2013 9:02:06 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
Ok here's how to do it. Works with version 3.3.XXXX through the latest 3.4.4855.4932.

You'll need 2 external IP's and 2 internal IP's, Microsoft IIS, and a free Microsoft module for IIS. Both screenconnect web service and relay service will use port 443.

Assuming you have a DNS record for your screenconnect domain(Web service) create another DNS record, a subdomain(relay service), under the same domain. For example if your url is domainname.com then relay.domainname.com.

I will use the following examples throughout this post so it's easy to follow:
External IP 1 = 1.1.1.1 domainname.com
External IP 2 = 1.1.1.2 relay.domainname.com

Now assign two internal IP's to your screenconnect server's network adapter.
Internal IP 1 = 192.168.1.1
Internal IP 2 = 192.168.1.2

Now in your create these router port forwards:
1.1.1.1 > 192.168.1.1 Port 80 (Microsoft IIS)
1.1.1.1 > 192.168.1.1 Port 443 (Screenconnect Web Service)
1.1.1.2 > 192.168.1.2 Port 443 (Screenconnect Relay Service)

Now install Microsoft IIS.

Download and install this: Microsoft URL Rewrite Module 2.0

1. Then copy the code below in notepad.
2. Save it as [web.config] in the \inetpub\wwwroot folder:

Code:
<?xml version="1.0" encoding="UTF-8"?>
 
<configuration>
 
    <system.webServer>
 
        <rewrite>
 
            <rules>
 
               <rule name="Redirect to https" enabled="true">
                <match url="(.*)" />
                 <conditions>
                     <add input="{SERVER_PORT}" pattern="443" negate="true" />
                 </conditions>
                  <action type="Redirect" url="https://domainname.com/{R:1}" />
               </rule>
             </rules>
 
        </rewrite>
 
    </system.webServer>
 
</configuration>


Now under IIS Management, Sites, Default Web Site, Open Feature URL Rewrite. You should see the rule Redirect to https listed in the top rule box for Inbound Rules.

Purchase and install an ssl certificate for domainname.com using the guides found in the knowledgebase and forum.

Update your web.config in your screenconnect program folder with these lines:

Code:
<add key="WebServerListenUri" value="https://domainname.com:443/" />
 <add key="RelayListenUri" value="relay://1.1.1.2:443/" />
 <add key="RelayAddressableUri" value="relay://relay.domainname.com:443/" />


Done!

My thanks especially to bblankenship78, the Screenconnect staff, and others who contributed to this thread.

Edited by user Friday, September 20, 2013 9:11:05 PM(UTC)  | Reason: Not specified

tvr  
#22 Posted : Thursday, October 3, 2013 7:53:46 AM(UTC)
tvr


Rank: Newbie

Joined: 10/3/2013(UTC)
Posts: 5
Location: Netherlands

I have tried this nice solution below, but I can't get it to work. The relay service cannot be started with the config below, I think because the ScreenConnect webconfig is trying to start 2 services on the same port (443).... and that fails. How dit you get this to work?


fthomasr wrote:
Ok here's how to do it. Works with version 3.3.XXXX through the latest 3.4.4855.4932.

You'll need 2 external IP's and 2 internal IP's, Microsoft IIS, and a free Microsoft module for IIS. Both screenconnect web service and relay service will use port 443.

Assuming you have a DNS record for your screenconnect domain(Web service) create another DNS record, a subdomain(relay service), under the same domain. For example if your url is domainname.com then relay.domainname.com.

I will use the following examples throughout this post so it's easy to follow:
External IP 1 = 1.1.1.1 domainname.com
External IP 2 = 1.1.1.2 relay.domainname.com

Now assign two internal IP's to your screenconnect server's network adapter.
Internal IP 1 = 192.168.1.1
Internal IP 2 = 192.168.1.2

Now in your create these router port forwards:
1.1.1.1 > 192.168.1.1 Port 80 (Microsoft IIS)
1.1.1.1 > 192.168.1.1 Port 443 (Screenconnect Web Service)
1.1.1.2 > 192.168.1.2 Port 443 (Screenconnect Relay Service)

Now install Microsoft IIS.

Download and install this: Microsoft URL Rewrite Module 2.0

1. Then copy the code below in notepad.
2. Save it as [web.config] in the \inetpub\wwwroot folder:

Code:
<?xml version="1.0" encoding="UTF-8"?>
 
<configuration>
 
    <system.webServer>
 
        <rewrite>
 
            <rules>
 
               <rule name="Redirect to https" enabled="true">
                <match url="(.*)" />
                 <conditions>
                     <add input="{SERVER_PORT}" pattern="443" negate="true" />
                 </conditions>
                  <action type="Redirect" url="https://domainname.com/{R:1}" />
               </rule>
             </rules>
 
        </rewrite>
 
    </system.webServer>
 
</configuration>


Now under IIS Management, Sites, Default Web Site, Open Feature URL Rewrite. You should see the rule Redirect to https listed in the top rule box for Inbound Rules.

Purchase and install an ssl certificate for domainname.com using the guides found in the knowledgebase and forum.

Update your web.config in your screenconnect program folder with these lines:

Code:
<add key="WebServerListenUri" value="https://domainname.com:443/" />
 <add key="RelayListenUri" value="relay://1.1.1.2:443/" />
 <add key="RelayAddressableUri" value="relay://relay.domainname.com:443/" />


Done!

My thanks especially to bblankenship78, the Screenconnect staff, and others who contributed to this thread.

Edited by user Thursday, October 3, 2013 7:58:31 AM(UTC)  | Reason: Not specified

fthomasr  
#23 Posted : Thursday, October 3, 2013 11:00:08 AM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
tvr wrote:
I have tried this nice solution below, but I can't get it to work. The relay service cannot be started with the config below, I think because the ScreenConnect webconfig is trying to start 2 services on the same port (443).... and that fails. How dit you get this to work?


Call technical support and speak to Reid. He had to remote it and resolve something on mine to get to work as well. He told me that other people MAY have the issue and need them to fix it as well when he fixed mine at the time.
tvr  
#24 Posted : Thursday, October 3, 2013 2:19:53 PM(UTC)
tvr


Rank: Newbie

Joined: 10/3/2013(UTC)
Posts: 5
Location: Netherlands

Ok, but before I call support: You are sure that in your config you run the web AND relay service both on port 443? Do you know what support fixed or do you know which config they also changed beside IIS and the web.config screenconnect file?


fthomasr wrote:
tvr wrote:
I have tried this nice solution below, but I can't get it to work. The relay service cannot be started with the config below, I think because the ScreenConnect webconfig is trying to start 2 services on the same port (443).... and that fails. How dit you get this to work?


Call technical support and speak to Reid. He had to remote it and resolve something on mine to get to work as well. He told me that other people MAY have the issue and need them to fix it as well when he fixed mine at the time.

fthomasr  
#25 Posted : Thursday, October 3, 2013 2:26:15 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
Yes that code is taken above is taken directly from my config file. Both services on running on the same port. They can as long as they are on different IP's. You do have each service on it's own internal IP correct? I had an issue after I tried to install the SSL Cert. They had to fix that. I don't remember exactly what they did to though.

I showed them the IIS and IIS URL Rewrite trick! They emailed me last month helping someone else and asked me again what program I used because they forgot.

tvr wrote:
Ok, but before I call support: You are sure that in your config you run the web AND relay service both on port 443? Do you know what support fixed or do you know which config they also changed beside IIS and the web.config screenconnect file?


fthomasr wrote:
tvr wrote:
I have tried this nice solution below, but I can't get it to work. The relay service cannot be started with the config below, I think because the ScreenConnect webconfig is trying to start 2 services on the same port (443).... and that fails. How dit you get this to work?


Call technical support and speak to Reid. He had to remote it and resolve something on mine to get to work as well. He told me that other people MAY have the issue and need them to fix it as well when he fixed mine at the time.


tvr  
#26 Posted : Thursday, October 3, 2013 2:37:47 PM(UTC)
tvr


Rank: Newbie

Joined: 10/3/2013(UTC)
Posts: 5
Location: Netherlands

The URL rewrite trick is indeed a must have!

My web.config screenconnect files is configured the same way you have mentioned in your article... but when i start the web service and then te relay serve (or vise versa) then I get an eventviewer log error because 2 services want to run on the same port...

I have configured my SSL cert to listen only on the internal IP of the web url....
Can you please paste the exact content of your web.config?


fthomasr wrote:
Yes that code is taken above is taken directly from my config file. Both services on running on the same port. They can as long as they are on different IP's. You do have each service on it's own internal IP correct? I had an issue after I tried to install the SSL Cert. They had to fix that. I don't remember exactly what they did to though.

I showed them the IIS and IIS URL Rewrite trick! They emailed me last month helping someone else and asked me again what program I used because they forgot.

Edited by user Thursday, October 3, 2013 2:39:19 PM(UTC)  | Reason: Not specified

tvr  
#27 Posted : Friday, October 4, 2013 2:33:34 PM(UTC)
tvr


Rank: Newbie

Joined: 10/3/2013(UTC)
Posts: 5
Location: Netherlands

I found out that by default there is no specific IP which the HTTP API listens on... I used the folowing command and after that I can run the 2 services both on 443.... I am not able to test if everything works now because I miss some port forwardings which my networkadmins have to setup.

netsh http add iplisten <internal IP 1>
netsh http add iplisten <internal IP 2>

Does this sounds like what the screenconnect support did for your config?

tvr wrote:
The URL rewrite trick is indeed a must have!

My web.config screenconnect files is configured the same way you have mentioned in your article... but when i start the web service and then te relay serve (or vise versa) then I get an eventviewer log error because 2 services want to run on the same port...

I have configured my SSL cert to listen only on the internal IP of the web url....
Can you please paste the exact content of your web.config?


fthomasr wrote:
Yes that code is taken above is taken directly from my config file. Both services on running on the same port. They can as long as they are on different IP's. You do have each service on it's own internal IP correct? I had an issue after I tried to install the SSL Cert. They had to fix that. I don't remember exactly what they did to though.

I showed them the IIS and IIS URL Rewrite trick! They emailed me last month helping someone else and asked me again what program I used because they forgot.


fthomasr  
#28 Posted : Friday, October 4, 2013 5:17:44 PM(UTC)
fthomasr


Rank: Member

Joined: 3/13/2013(UTC)
Posts: 17
Location: Albany, GA

Thanks: 1 times
I don't remember but I think so. Call support and ask for Reid. I would think he has notes for my call, or remembers, or would know if you had to do that for sure. If so, PLEASE update the thread and I will go back and add it to my how-to notes above.

tvr wrote:
I found out that by default there is no specific IP which the HTTP API listens on... I used the folowing command and after that I can run the 2 services both on 443.... I am not able to test if everything works now because I miss some port forwardings which my networkadmins have to setup.

netsh http add iplisten <internal IP 1>
netsh http add iplisten <internal IP 2>

Does this sounds like what the screenconnect support did for your config?


Reid  
#29 Posted : Monday, October 7, 2013 2:18:05 PM(UTC)
Reid


Rank: Administration

Medals: Level 2: Lent a Helping Hand! 10 Thanks!

Joined: 4/22/2010(UTC)
Posts: 475
Location: NC

Was thanked: 17 time(s) in 15 post(s)
@tvr,

We also had to configure an IP Inclusion list on Thomas' server as well. I would have expected that to resolve things for you. Can you shoot an email to support@screenconnect.com, so that we can arrange a time for a session together?
ScreenConnect Team
BeanAnimal  
#30 Posted : Sunday, February 16, 2014 9:28:56 PM(UTC)
BeanAnimal


Rank: Member

Joined: 9/24/2012(UTC)
Posts: 14
Location: Pittsburgh

While I think SC is a great product, and have recently purchased... I am finding this to be a wholly unacceptable situation. In a nutshell, as good as the application is, the basic architecture needs a serious rethink, or at the very least the ability to deal with host headers.

The simple fact is that in this modern age, any firewall that is worthy of business class traffic will lock down just about everything but 80 and 443. This application should be more than capable of using those two ports for secure login and relay, PERIOD. Anything less and it useless for about 80% of my remote support scenarios.

While some of us may have the ability to use two public IPs, some of us do not. I am currently hosting SC on Azure. I do not have the ability to bind two public IPs.
Why can this application simply not use host headers to differentiate between web traffic and relay traffic.

http and https support.mydomain.com for guest and admin login, etc.
relay.mydomain.com for the relay traffic (already encrypted)

AND NO... I do not want to mess around with IIS and piggybacking, etc. The SC webserver should simply have the ability to deal with host headers. Come on SC, how about a little love on this?

This should not really be that hard to implement and is far more important than half of the bells and whistles that are being developed.



farewelldave  
#31 Posted : Friday, February 21, 2014 6:48:12 PM(UTC)
farewelldave


Rank: Newbie

Joined: 2/7/2014(UTC)
Posts: 4
United States
Location: Missouri

Originally Posted by: fthomasr Go to Quoted Post
Ok here's how to do it. Works with version 3.3.XXXX through the latest 3.4.4855.4932.

You'll need 2 external IP's and 2 internal IP's, Microsoft IIS, and a free Microsoft module for IIS. Both screenconnect web service and relay service will use port 443.

Assuming you have a DNS record for your screenconnect domain(Web service) create another DNS record, a subdomain(relay service), under the same domain. For example if your url is domainname.com then relay.domainname.com.

I will use the following examples throughout this post so it's easy to follow:
External IP 1 = 1.1.1.1 domainname.com
External IP 2 = 1.1.1.2 relay.domainname.com

Now assign two internal IP's to your screenconnect server's network adapter.
Internal IP 1 = 192.168.1.1
Internal IP 2 = 192.168.1.2

Now in your create these router port forwards:
1.1.1.1 > 192.168.1.1 Port 80 (Microsoft IIS)
1.1.1.1 > 192.168.1.1 Port 443 (Screenconnect Web Service)
1.1.1.2 > 192.168.1.2 Port 443 (Screenconnect Relay Service)

Now install Microsoft IIS.

Download and install this: Microsoft URL Rewrite Module 2.0

1. Then copy the code below in notepad.
2. Save it as [web.config] in the \inetpub\wwwroot folder:

Code:
<?xml version="1.0" encoding="UTF-8"?>
 
<configuration>
 
    <system.webServer>
 
        <rewrite>
 
            <rules>
 
               <rule name="Redirect to https" enabled="true">
                <match url="(.*)" />
                 <conditions>
                     <add input="{SERVER_PORT}" pattern="443" negate="true" />
                 </conditions>
                  <action type="Redirect" url="https://domainname.com/{R:1}" />
               </rule>
             </rules>
 
        </rewrite>
 
    </system.webServer>
 
</configuration>


Now under IIS Management, Sites, Default Web Site, Open Feature URL Rewrite. You should see the rule Redirect to https listed in the top rule box for Inbound Rules.

Purchase and install an ssl certificate for domainname.com using the guides found in the knowledgebase and forum.

Update your web.config in your screenconnect program folder with these lines:

Code:
<add key="WebServerListenUri" value="https://domainname.com:443/" />
 <add key="RelayListenUri" value="relay://1.1.1.2:443/" />
 <add key="RelayAddressableUri" value="relay://relay.domainname.com:443/" />


Done!

My thanks especially to bblankenship78, the Screenconnect staff, and others who contributed to this thread.


Along with this configuration - we had to make a few changes for our environment (ScreenConnect 4.1.6060.5144, Windows Server 2012, IIS 7.0)

2 issues were found with the above configuration

1. ScreenConnect Relay service would not start using the External IP (e.g. 1.1.1.2) for Relay service in the "RelayListenUri" variable.
2. ScreenConnect Web Server service would bind to the first, local IP interface when specifying the domain name in the "WebServerListenUri" variable.

Our configuration in our web.config file (using the example IP addresses):

Code:
<add key="WebServerListenUri" value="https://192.168.1.1:443/" />
 <add key="WebServerAddressableUri" value="https://domainname.com:443/" />
 <add key="RelayListenUri" value="relay://192.168.1.2:443/" />
 <add key="RelayAddressableUri" value="relay://relay.domainname.com:443/" />


We also had to add both local interface IPs to the http iplisten array. For the example IPs, you would need to run these commands on Server 2008/2012:

Code:
netsh http add iplisten 192.168.1.1
netsh http add iplisten 192.168.1.2


If you run the following command, it will list your iplisten IP addresses. Just verify the correct IPs are listed:

Code:
netsh http show iplisten


After doing all of this, I just restarted the Windows server to make sure services starting normally would give us a functional setup.

Once rebooted, I was able to go to http://domainname.com and it redirected to https://domainname.com, and upon creating a session, I was able to connect as both host and guest (whether internal or external to our LAN network where the ScreenConnect server is hosted)

-David
number_one  
#32 Posted : Saturday, March 1, 2014 12:27:30 AM(UTC)
number_one


Rank: Advanced Member

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

Joined: 3/1/2014(UTC)
Posts: 46
United States

Thanks: 4 times
Was thanked: 11 time(s) in 5 post(s)
+1 for getting a solution built-in to ScreenConnect.

Setting up everything with 2 external IPs is cumbersome, but more importantly it can be quite expensive or unfeasible to even get more than one external IP in certain scenarios.

There really needs to be some built-in way of having encrypted web traffic without losing the ability to respond on port 80 (Can't the relay service listen for a web request in addition to handling the session data and forward those requests to port 443?)

Short of that, it seems to me that by far the easiest workaround presently would be a variant of what DrM posted by using an alternative domain or subdomain as the "front" for web traffic and have that forward to the the "real" domain. If you have a DNS service that supports forward records it can be handled entirely with DNS (no separate websites needed for the forwarding).
vexation  
#33 Posted : Wednesday, March 19, 2014 8:08:43 PM(UTC)
vexation


Rank: Member

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

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

Thanks: 7 times
Was thanked: 3 time(s) in 2 post(s)
I'd completely forgotten about this and ran into my first instance of the relay ports being blocked at a site today. Luckily extra internal and external IP addresses aren't a problem for me.. but can someone explain why the IIS module / re-direct is necessary (I'm probably missing something really straight-forward, definitely lack of coffee today) or is it only necessary if you literally want another subdomain/domain redirect?

If you have two internal IP addresses and two external IP addresses and configure the bindings properly (to lets say support.domainname.com and relay.domainname.com and separate IP addresses internally), I thought SC could re-direct port 80 to 443 itself via http://forum.screenconne...t-to-HTTPS.aspx#post2508 for the web server side?

+1 for having all of this handled internally by SC / host headers tho.. would make a lot of sense although i'm guessing there'd be backwards-compatibility issues. Would likely need extra bindings / ports to handle the older clients that don't support it?

Edited by user Wednesday, March 19, 2014 8:23:11 PM(UTC)  | Reason: clarification

shawnkhall  
#34 Posted : Wednesday, March 26, 2014 10:53:16 AM(UTC)
shawnkhall


Rank:: Advanced Member

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

Joined: 2/6/2014(UTC)
Posts: 316
Man
United States

Thanks: 6 times
Was thanked: 33 time(s) in 29 post(s)
Sorry for the book, guys. I wanted to clear up some misunderstandings here and answer some questions.

I'm afraid some of you are misunderstanding the nature of SSL. SSL is not simply enforced just because something uses a port that normally uses SSL (such as 443). Quite the opposite, the service must be capable of using SSL from the ground up, and unless it's imposed at that level it will not be enforced regardless of the port in use.

The specific position for using 80 and 443 is to ensure maximum firewall and environment compatibility, as some hardened networks will not allow certain traffic on other ports. That's only a consideration at all because ScreenConnection requires two ports to function.

ScreenConnect requires these two ports for differing purposes/services: one for the web interface and one for the relay service. Both can use the same port, but if they'll be on the same port they must be on different IP addresses.

OR you can use the same IP and use different ports.

In any case, you are NOT required to use 443 for SSL! If you're concerned about firewall impositions, consider using a different common SSL port for bypassing that. You have 465, 993 and 995 to choose from just from common email services. As long as you don't require those ports for email on your IP you can use them and bypass most firewalls that way. You can also opt to use ports that are not normally SSL but impose SSL by adding the "s" to https in the SC configuration value for WebServerListenUri. As long as you're defining the https protocol there, regardless of port, it'll use SSL. There are a dozen ports that are allowed by most firewalls, but the 5 above are the most common. Surely if you're stuck in an environment where it's that big of a deal, you can configure them to work for you. Https will remove the port number from the URL if the port is 443, but only because that's considered the "standard" port for encrypted http traffic. Just as using standard http will hide the ":80" from the browser -- it's redundant. You *can* use port 80 for SSL as long as you're willing to include the port number in the URL, a la, httpS://example.com:80/

There's a GREAT utility I use all the time from Digicert to test SSL certificates on various ports:
http://www.digicert.com/help/index.htm
Enter the host name and port number, such as:
gmail-smtp-in.l.google.com:25
You'll quickly see whether it's really using SSL (or even capable) and if it's configured correctly.

It is NOT possible to "just use host headers" to differentiate between which service is functioning on a port, as only a single service can have access to a given port on a single IP. Host headers are great at doing what they do -- differentiating between different destinations within a single top-down service (such as Apache or IIS), but since two different services cannot simultaneously access the same port on the same IP, the relay and web interface must be split up either by ports or IP's.

Furthermore, I'm not seeing anything to indicate that ScreenConnect is capable of using SSL for the relay. Sure, you can put the relay service on 443, but that does NOT make it use SSL! I don't know that I'd personally want it to due to the overhead, but it's important to understand that putting it on 443 for the sake of imposing SSL will not work. Please, someone from SC, correct me if I'm wrong and there's some form of internal parsing for 443 that isn't otherwise exposed in the settings - 'cause I do not see anything there to suggest relay would actually be secured on 443. For that matter, I don't see anything to suggest that, outside of potential hardened firewall issues, putting the relay on any port other than 8041 is going to help in any way whatsoever. And updating the clients to use the new relay service port would be a PITA.

Finally -- thank you to everyone who contributed to this topic. It's going to help me configure SC how I want it when I have the time to juggle the options & settings in my environment. When I'm done I'll share my configuration so others can benefit.
number_one  
#35 Posted : Wednesday, March 26, 2014 10:53:21 PM(UTC)
number_one


Rank: Advanced Member

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

Joined: 3/1/2014(UTC)
Posts: 46
United States

Thanks: 4 times
Was thanked: 11 time(s) in 5 post(s)
Originally Posted by: shawnkhall Go to Quoted Post
Sorry for the book, guys. I wanted to clear up some misunderstandings here and answer some questions.


I'm not sure exactly what you are responding to. Nobody is talking about needing SSL for the relay, as ScreenConnect already encrypts the relay traffic anyway. The issue is simply about ports that are typically open on *CLIENT* side networks (in other words, configurations that you can't change). Many people have noted that there are some networks that are ultra-locked down and ONLY allow traffic through the standard HTTP/HTTPS ports (80/443).

There is no problem with running the relay service on port 80 without SSL (because the data is already encrypted) and using port 443 with SSL for the web interface in terms of ScreenConnect operation.

The problem is simply that in this configuration the client has to manually enter "https" in their browser as the relay service on port 80 won't respond to web requests. The workaround with two public facing IP addresses is OK for those that already have an "extra" public IP, but many do not.

I can't see the actual ScreenConnect code, but it would seem to me that it would be at least possible for the relay service to listen for very specific HTTP requests and respond with a 301 redirect. Note that I'm not talking about running a full HTTP server on the port, but that the relay service would be able to identify specific HTTP requests (at an IP packet level) that are currently just dropped and instead send a simple 301 redirect in response.
shawnkhall  
#36 Posted : Thursday, March 27, 2014 3:03:01 AM(UTC)
shawnkhall


Rank:: Advanced Member

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

Joined: 2/6/2014(UTC)
Posts: 316
Man
United States

Thanks: 6 times
Was thanked: 33 time(s) in 29 post(s)
Originally Posted by: number_one Go to Quoted Post
Nobody is talking about needing SSL for the relay...


#14 did. Others (#30, for example) seems to think that some magical use of host headers can somehow fix a problem that's imposed by service-level differences.

The "fix the default configuration" complaints are the one's that really needed to understand that this isn't something that can be safely changed in the setup. Routers that have their own SSL certificates, for example, are a poor example of native SSL, since they don't need to be responding to our own domain names. When they only need to respond to routerlogin.net, a shared central cert is fine. But when it needs to have a unique URL for each SC install, it won't work. SC imposing itself on ports 80 and 443 would break our existing web servers and changing ports after we have clients installed will result in losing their connections.
number_one  
#37 Posted : Thursday, March 27, 2014 3:23:29 AM(UTC)
number_one


Rank: Advanced Member

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

Joined: 3/1/2014(UTC)
Posts: 46
United States

Thanks: 4 times
Was thanked: 11 time(s) in 5 post(s)
Originally Posted by: shawnkhall Go to Quoted Post
Originally Posted by: number_one Go to Quoted Post
Nobody is talking about needing SSL for the relay...


#14 did. Others (#30, for example) seems to think that some magical use of host headers can somehow fix a problem that's imposed by service-level differences.

The "fix the default configuration" complaints are the one's that really needed to understand that this isn't something that can be safely changed in the setup. Routers that have their own SSL certificates, for example, are a poor example of native SSL, since they don't need to be responding to our own domain names. When they only need to respond to routerlogin.net, a shared central cert is fine. But when it needs to have a unique URL for each SC install, it won't work. SC imposing itself on ports 80 and 443 would break our existing web servers and changing ports after we have clients installed will result in losing their connections.


Even though you're correct that host headers aren't going to solve the issue of running the SC relay service and a web service on the same port that still has nothing to do with people wanting SSL for the relay service. Bottom line what people want is the ability to have SSL encrypted web connections and still be able to have the relay service work using only ports 80 and 443, while still allowing a client to initially visit the site using HTTP or HTTPS.

All your talk of certificates, routers, and "SC imposing itself on ports" doesn't even make sense. Certificates and SSL configuration are not even remotely what this thread is about (except that we need SSL to encrypt web sessions). The reason SC needs to have the option of working over only ports 80 and 443 is because, as stated many times before, there are A LOT of networks out there that block anything external except those specific ports.

My previous post details a possible solution by having the relay service (on port 80) operate its own crude HTTP listener at a packet level only for the purpose of redirecting clients to the HTTPS site (port 443), but this would have to be implemented by the SC developers directly.

Maybe I'm not understanding your posts at a fundamental level, but what exactly are you trying to add to the discussion? I'm really not trying to be mean; I just don't understand what you're trying to say...
shawnkhall  
#38 Posted : Thursday, March 27, 2014 4:46:57 AM(UTC)
shawnkhall


Rank:: Advanced Member

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

Joined: 2/6/2014(UTC)
Posts: 316
Man
United States

Thanks: 6 times
Was thanked: 33 time(s) in 29 post(s)
Originally Posted by: number_one Go to Quoted Post
Maybe I'm not understanding your posts at a fundamental level, but what exactly are you trying to add to the discussion? I'm really not trying to be mean; I just don't understand what you're trying to say...


Then read the entire thread. Maybe if you had actually read what other people actually wrote you wouldn't be wasting my time by debating the finer points of what THEY were requesting and complaining about.
number_one  
#39 Posted : Thursday, March 27, 2014 5:55:04 AM(UTC)
number_one


Rank: Advanced Member

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

Joined: 3/1/2014(UTC)
Posts: 46
United States

Thanks: 4 times
Was thanked: 11 time(s) in 5 post(s)
Originally Posted by: shawnkhall Go to Quoted Post
Originally Posted by: number_one Go to Quoted Post
Maybe I'm not understanding your posts at a fundamental level, but what exactly are you trying to add to the discussion? I'm really not trying to be mean; I just don't understand what you're trying to say...


Then read the entire thread. Maybe if you had actually read what other people actually wrote you wouldn't be wasting my time by debating the finer points of what THEY were requesting and complaining about.


Let's keep this civil please. I read the entire thread long before your first post (and in fact posted in this very thread 26 days ago), and I'm simply asking you to explain what you mean in better detail.

First, there is no specific technical reason why the "default" configuration can't be to have secure communication for both web and data sessions. It is simply a matter of programming effort on the part of the SC developers using some type of solution like what I proposed (or something else). Other remoting software systems can do it (whether they are of similar design or not).

Second, there is absolutely nothing wrong with a user of ScreenConnect expecting that web traffic would be encrypted in a default configuration. Unencrypted traffic is VERY dangerous today, and I can't imagine much worse than someone gaining access to an admin's SC login with a bunch of unattended sessions. Trying to defend the lack of "default" support by talking about a bunch of technical limitations is not very helpful. Sure, there may be limitations currently and some people won't understand how things are setup, but the status quo is not really acceptable IMO if it means unencrypted logins out of the box, so that is not an excuse forever. Workarounds are fine as well, but are pretty obtuse or require complicated setups. Bottom line, if LogMeIn can have no-nonsense encrypted web and data there is no reason SC developers can't figure out a way (even if it means changing how certain things are structured). I'm not saying that they have to do it exactly like LogMeIn or that it will be easy, but simply that it CAN be done somehow. And THAT is what this thread is primarily about--that is, asking the SC developers to make it work.

Also, the only point that was mentioned about routers was that they are typically set up to require SSL sessions even for LAN use. It was just a reference to the fact that even local router traffic is usually encrypted these days because of the danger of sniffing data in unencrypted communication. SC on the other hand is being used over the internet for most people so the danger is all that more real for snooping unencrypted data. The type of certificate a router uses versus what would be required for a service like SC truly is immaterial to the discussion. The point was simply that even routers use SSL to encrypt traffic these days, so why isn't SC doing that out of the box? Sure it might be "hard" to get it working that way, but that doesn't mean it's any less important.

Finally, I still don't think you understand why many people want things to work using ONLY ports 80 and 443. It is simply for getting through firewalls, period. Using any other ports increase the chance that a client won't be able to access SC (and also makes for potential headaches trying to get non-technical users to add a ":<port>" on the end of a URL. It has been stated and recognized in the thread already that the relay service already encrypts its own data using methods other than SSL (which is why it is perfectly fine to use port 80 for the relay service). The only "problem" with that scenario is the lack of support for HTTP web requests on port 80, and that is specifically what the workarounds are addressing. What we want is for ScreenConnect to create a solution that will solve that problem "out of the box". And that is, again, what this thread is really about.
davidc  
#40 Posted : Monday, March 31, 2014 6:33:31 PM(UTC)
davidc


Rank: Newbie

Joined: 3/31/2014(UTC)
Posts: 2
United States

Many thanks to the contributors on this post. I finally had success using 2 public and 2 private IPs. The only twist is that I did my setup on Windows Server 2003 and I couldn't get ScreenConnect's web service to answer on port 443. Finally figured out that IIS was binding to 0.0.0.0:443

This article fixed it for me:
http://support.microsoft.com/kb/892847

In closing let me add that I too feel that it shouldn't be this difficult to implement encryption on the web interface. Security should be top priority in all facets of this product, not just the relay service.

Now to figure out how to expire the web session after so many minutes. Another security hole in my opinion.

-David


vexation  
#41 Posted : Sunday, October 19, 2014 4:13:51 PM(UTC)
vexation


Rank: Member

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

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

Thanks: 7 times
Was thanked: 3 time(s) in 2 post(s)
Originally Posted by: farewelldave Go to Quoted Post
We also had to add both local interface IPs to the http iplisten array. For the example IPs, you would need to run these commands on Server 2008/2012:

Code:
netsh http add iplisten 192.168.1.1
netsh http add iplisten 192.168.1.2


If you run the following command, it will list your iplisten IP addresses. Just verify the correct IPs are listed:

Code:
netsh http show iplisten


After doing all of this, I just restarted the Windows server to make sure services starting normally would give us a functional setup.

Once rebooted, I was able to go to http://domainname.com and it redirected to https://domainname.com, and upon creating a session, I was able to connect as both host and guest (whether internal or external to our LAN network where the ScreenConnect server is hosted)

-David


Just in case anyone ends up doing this on a Server 2012 R2 box (which works fine by the way) but also needs to use the Server Manager (which I needed for control over Storage Spaces etc) when browsing to 'File and Storage Services' in the Server Manager you'll likely encounter error messages like "Error occurred during enumeration of SMB shares" and you'll be told to make sure the WinRM service is running (and it already is) or to run "winrm quickconfig" which will result in an "Error number: -2144108526 0x80338012"

Make sure you add..
Code:
netsh http add iplisten 127.0.0.1

..too, otherwise the Server Manager cannot communicate with WinRM.

Posting here because I've got nowhere to blog and I figure anyone else that comes across this problem might stumble across this in a Google search and save themselves an hour or two if they're lucky.
thanks 2 users thanked vexation for this useful post.
gb5102 on 10/20/2014(UTC), rgreen83 on 2/16/2015(UTC)
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.