This is how I ended the thread on the problem I had with Remote Connections: Resolved: Unable to establish connection - Remote Monitoring
"PS: I realized that if anyone else has a similar problem, they might want more info on the solution.
For each remote machine, go to
Control Panel > System and Security > Firewall > Advanced Settings
I started by setting all the tabs to “off” to make the remote connection, but then went back and started turning them on. Both the Domain and Public tabs can remain with full Firewall protection. In the Private tab, I selected “Customize” and unchecked the boxes for Wifi (leaves the Wifi connection not protected by Firewall rules). That is where I am now that allows full remote connection ability.
But that does not enable remote connection on my 3rd machine."
Like my other remote PC, this is a Windows 10 system, but it is the PC that I use to run the current beta of Win10. The functioning PC is at release 10230 (GA version) while this PC is at 10586.
I’ve set this machine up with Firewall the same way as the other two (the Win10 and a Win7 PC). I’ve re-installed Glasswire and re-booted my client and the server after Remote Monitor setup. I’ve turned off remote monitoring on one of the other machines to see if this one would activate.
I have noticed that if I have Firewall enabled on this remote machine, there is a considerable wait period on the client while the timeout is in effect for each connection try. When I disable the Firewall, the return from each attempt is only 2 seconds.
Reply received from RichieRoe in the original thread:
Glad to know that this solution worked out!
I guess there are some custom rules on the Firewall, which blocked the connection. So if there are no any important settings, you can restore the default settings in a following way:
- Run GlassWire and unblock all the applications under the Firewall tab if you’ve got anything blocked;
- Open Windows Firewall settings Control Panel\System and Security\Windows Firewall;
- Click at the “Advanced settings” at the left hand panel;
- Select “Action\Restore default policy” at the main menu of the Advanced settings window.
But please keep in mind that this will also remove the exceptions added by Dropbox, uTorrent etc. It’s not a big problem actually, since you’ll be notified when the application will try to establish connection, so you’ll be to add the exceptions later.
As I said, good thought, but no that didn’t help. Frankly, there is almost nothing on that Win10 test machine, so not surprising there were few Firewall exceptions (only one from Netgear Genie, I think.) And btw, I have Netgear Genie running on all my machines, so that is not the issue.
I also tried to reverse this connection on these two machines (making the remote the client and vice versa). That also did not succeed.
So still, two remote servers work just fine, and the third will not connect. This is what my Glasswire window looks like:
There are 4 laptops in this network: my main Win10 client, a rather old Sony Win10 test machine (the one that I can’t get to accept a remote connection), a Yoga2 with Win10, and an older HP with Win7. I decided to try the same reverse client/server connection described on the Yoga2 – (I think I tried that earlier, but that was before I finally got a remote connection with the Yoga2.) Immediate connection! Literally shocked me! So now I CAN establish the remote connection both ways between my primary client and that Yoga2.
Well, nothing else to do but go back to the Win10 test machine and try the reverse remote connection yet again (this is the one from the quote above). Bingo! Immediate connection!
My best guess is that with all the option changing and re-tries among these 4 machines, I probably skipped a step at some point while trying to do the reverse connect (probably in the Firewall setup). With yet another retry I got it right and now two “remote” machines can reverse remote connect with my main client.
So all remote connections between my various PCs work except for the one that this thread was opened to report. Back to that machine to once again prowl through the Firewall – again!
Since I was able to do the reverse remote connection on two machines, I decided to try to connect to the Win10 test (the problem machine) using the Yoga2 as client. It worked! So neither Windows 10 nor the machine setup (including Firewall) is not at issue. That means do some more checks.
At the old HP Win7 machine, it tried to remote connect the Win10 test. It connected. So all the four machines will remote connect to each other except the main Glasswire client to the Win10 test machine.
Going back to the main client, I tried it with the Win10 test – no connection. So it was definitely something between these two. To start a new set of re-tests, I deleted the remote connection identity for the Win10 test machine from my client. I then clicked Add New Server and re-entered exactly the same information that I used on the many previous attempts. It connected.
- at some point in the multiple setups of the four machines I must have made a mistake in the Firewall of the Win10 test machine that is now corrected.
- Something in the Glasswire remote connection process parameters entered for that Win10 test machine did not “take” making the connect attempt fail. This is an issue for the Glasswire team.
- I still have a minor (in my situation) issue in that all the “remote server” machines must have “Wifi” deselected in the Windows Firewall Properties Private Network Profile. (Control Panel > System and Security > Windows Firewall > Advanced Settings (at left) > Windows Firewall Properties > Private Profile > Customize > deselect any Wifi boxes)
In other situations, this would leave the Firewall for any Wifi network unprotected (off). For my situation, I’m remote and my network is protected behind two hardware firewalls (my router and my gateway). My Wifi network is secure and not at all exposed to potential outside attack. But I still want to find out why I must have this vulnerability for Glasswire Remote Connection to work.
So I will open a new problem report on that issue.