Kelvin Tran

Preliminary Troubleshooting

18 posts in this topic

to stop the restart on linux close it like any other application.

if you have the service open in a terminal(using the terminal to manually start it) press ctrl-c, this will close the service.

if you have a modified(working) service then restart it using the terminal:

systemctl restart synergy

 

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, jaap aarts said:

to stop the restart on linux close it like any other application.

if you have the service open in a terminal(using the terminal to manually start it) press ctrl-c, this will close the service.

if you have a modified(working) service then restart it using the terminal:

systemctl restart synergy

 

Yeah, what he said! xD

Share this post


Link to post
Share on other sites

WINDOWS FIREWALL 

These Windows 10 firewall settings have worked for several users first by Ilya reported on the forum:

manually add the following rules to the windows firewall:

%ProgramFiles%\Synergy\synergys.exe

%ProgramFiles%\Synergy\synergyd.exe

%ProgramFiles%\Synergy\synergyc.exe

%ProgramFiles%\Synergy\synergy2.exe

 

permit synergys.exe to "Outbound Rules" (Domain + Private) in Windows 10

added port 24810 inbound and outbound rules to windows firewall on both systems

  • Like 1

Share this post


Link to post
Share on other sites

I posted about this back in September when beta4 was first released. But that will have dropped down the thread list now.

IMO, adding program exceptions (using the four paths listed above) is a better solution than port exceptions. With program exceptions you are permitting that specific program only and by default you are permitting it to use any port(s) it wants. So if the port changes for any reason, your rule will still work as expected.

With port exceptions, by default, you are allowing any program to use that specific port. So some other unexpected/unwanted application could make use of the port.

You don't need to do both.

Also, with a standard Windows Firewall setup, you only need to add inbound rules, it is not necessary to add outbound rules. By default any program on your computer can connect outbound. You will only need to add outbound rules if you are using some third-party firewall manager which denies outbound by default.

Share this post


Link to post
Share on other sites
On 10/16/2017 at 4:05 AM, IT Troll said:

I posted about this back in September when beta4 was first released. But that will have dropped down the thread list now.

IMO, adding program exceptions (using the four paths listed above) is a better solution than port exceptions. With program exceptions you are permitting that specific program only and by default you are permitting it to use any port(s) it wants. So if the port changes for any reason, your rule will still work as expected.

With port exceptions, by default, you are allowing any program to use that specific port. So some other unexpected/unwanted application could make use of the port.

You don't need to do both.

Also, with a standard Windows Firewall setup, you only need to add inbound rules, it is not necessary to add outbound rules. By default any program on your computer can connect outbound. You will only need to add outbound rules if you are using some third-party firewall manager which denies outbound by default.

What you're saying is true about the program exceptions, but I prefer port exceptions because whilst it's true that a program can then come and use that port if they'd like, from my understanding, no two ports can be used simultaneously by two different programs and port exceptions work better with router-based firewalls, since I know that there will be situations where that will matter. For a host-based firewall/IDS/IPS, what you're saying is ABSOLUTELY true. 

I'd like to agree to disagree with your assertion that there is not a desire to do both. Doing both is overkill, but it is a way to ABSOLUTELY guarantee it works. I've seen some of these cases with other applications where it will not work with a program exception but then go ahead and work again with a port exception or if I turn the entire domain into a DMZ. It is overkill, but it's a way to ensure that it works.

With a standard Windows Firewall setup, it's true. However, see note 1 about guaranteeing that it will work.

Share this post


Link to post
Share on other sites

My post was specifically aimed at Synergy 2, which does not work out of the box with the Windows host firewall.

Port-based rules are indeed better suited to dedicated firewall appliances, but that is not what we are talking about here. I can't see anyone trying to control devices with Synergy which are sitting either side of a network perimeter firewall.

Setting both port and program exceptions is overkill and unnecessary for Synergy. Setting the program exception alone will also absolutely guarantee it works. However, the same is not true of just setting the port exception as the port might change in a future release, if unavailable, or through a custom configuration.

From a general security strategy point of view, you should avoid overlapping rules which weaken your defence any more than is absolutely necessary. Having said that, setting both is still vastly better than just disabling the firewall completely which the official troubleshooting guide still advocates.

Share this post


Link to post
Share on other sites

Just to tighten up on this a little more. It would seem that on both Windows and Mac the device-to-device communication occurs on ports 24800 and 24810 which is used by the synergyd, synergys and synergyc processes. Port 24888 is also used but it appears just for local loop back purposes.

Synergy2 (the GUI) just appears to use https to connect to Symless and also the local loop back.

synergyd also makes an external connection to Symless on port 8081.

Share this post


Link to post
Share on other sites

Sure, you could do that, and I will edit the post. But I still stand by the fact that I prefer port based exceptions personally. I've seen program-based exceptions fail spectacularly in cases that don't necessarily pertain to Synergy. I will edit the post and give you credit for your contribution.

Share this post


Link to post
Share on other sites

I just want to make it known that it wasn't I who initially found that adding firewall exceptions for the exe's fixed many peoples' issues, but it was actually @gee4vee. Then, @Fridgey pasted the actual paths to the executables that he allowed through his firewall. Lastly, @caveguy shared that he also added the port to the firewall. The combination of all three of these users and their suggestions is what got my setup working...so THEY deserve the credit, not I.

Share this post


Link to post
Share on other sites

I posted this for people that are having issue with Windows 7 64 Bit and Synergy2

 

Share this post


Link to post
Share on other sites

Suffice it to say, the next beta build installer will need to address the firewall assignments to Windows based computers to either:

a) place the programs needed to firewall allows

b) specify range that should be open port wise.

While this may not cover the third party firewall solutions, another suggestion would be to include in the synergy2 gui a help button for people who don't visit the forums to have an alternative means to see where or what they might want to try.

Share this post


Link to post
Share on other sites
On 18/10/2017 at 10:33 AM, IT Troll said:

Just to tighten up on this a little more. It would seem that on both Windows and Mac the device-to-device communication occurs on ports 24800 and 24810 which is used by the synergyd, synergys and synergyc processes. Port 24888 is also used but it appears just for local loop back purposes.

Synergy2 (the GUI) just appears to use https to connect to Symless and also the local loop back.

synergyd also makes an external connection to Symless on port 8081.

Cheers @IT Troll, this fixed the issue I was having for me.

 

I run ESET Endpoint Security, and I had to create a rule for synergyd.exe, synergyc.exe, and synergys.exe, allowing bidirectional access on TCP ports 24800, 24810, and 24888, to get beta4 to work. 

 

Beta is beta, of course, but it's a real pain in the rear to have to make these manual changes. Let's hope the release version does something to make this easier for those without the skills or forethought to check these forums ;)

Share this post


Link to post
Share on other sites
20 hours ago, SilverbackSays said:

Beta is beta, of course, but it's a real pain in the rear to have to make these manual changes. Let's hope the release version does something to make this easier for those without the skills or forethought to check these forums ;)

It is entirely possible to add standard Windows firewall rules during the installation process. I think this just got missed due to the changes introduced with beta4.

However, there are a multitude of third-party "default deny" security products out there which may require additional configuration. These will require very clear guidance if non-technical users are to stand any chance.

Share this post


Link to post
Share on other sites

I can confirm Synergy 2 beta 4 working, after adding 4 program rules from OP step 4 to Windows Firewall for inbound connections and one outbound rule for synergys.exe. Running Windows 10 1709 on both ends. I think it actually worked after adding the inbound rules on my server system (the one with kb and mouse) and having only the outbound synergys.exe rule and the predefined "Synergy" and "Synergy 2.0" inbound rules on the other system. The mouse movement on the client side is very choppy though.

Looking forward to try beta 5!

Share this post


Link to post
Share on other sites

Nick has unpinned and unfeatured this post because much of is it now incorrect following the release of beta5.

Prior to installation of beta5, I removed all my manual firewall rules and let the installer do it's thing. I'm happy to report that it added the required rule and connections were made without needing any intervention.

The binaries have been renamed to; synergy-config (the GUI), synergy-core, and synergy-service.

synergy-config connects to the Symless cloud server using standard https and so should no longer be a problem for most perimeter/boundary firewalls.

The installer automatically adds a rule to the Windows firewall for synergy-service, all the host-to-host communications are now handled by this process; it uses a number of different ports.

If you use a third party host firewall and need to add a rule manually, then just adding the following as a program exception should be enough.

%ProgramFiles%\Synergy\synergy-service.exe

Edited by IT Troll

Share this post


Link to post
Share on other sites
13 minutes ago, IT Troll said:

Nick has unpinned and unfeatured this post because much of is it now incorrect following the release of beta5.

 

Feel free to update and re-pin :)

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now