github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #597] Barrier can't connect - Linux server, MacOS client #468

New issue

Open

opened 2026-05-05 06:29:14 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 06:29:14 -06:00

Owner

Originally created by @Eddles on GitHub (Mar 25, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/597

Operating Systems

Server: Linux Mint 19.1 Tessa

Client: MacOS Catalina 10.15.4

Barrier Version

Server: 2.3.2-snapshot-9080ce45

Client: 2.3.2-Release-210C2b70

Steps to reproduce bug

Start Barrier on Linux server - ip 192.168.1.135
Start Barrier on MacOS client, set it to connect to 192.168.1.135
Client shows "WARNING: failed to connect to sever: Timed out"
I verified Barrier was running and listening on the right port:

kit@wanderer:~$ sudo netstat -tupan | grep barrier
tcp6 0 0 :::24800 :::* LISTEN 31192/barriers
tcp6 0 0 :::35785 :::* LISTEN 31068/barrier
kit@wanderer:~$

I verified that the MacOS client can ping the server on 192.168.1.135 just fine.
I verified the Barrier client is set up to connect to port 24800.
Using "Autoconfig" doesn't work.
Both the Linux server and the MacOS client is on the same subnet.

Other info

When did the problem start to occur? I've never used this before.
Is there a way to work around it? No
Does this bug prevent you from using Barrier entirely? Yes

Any advice would be greatly appreciated, thank you.

Originally created by @Eddles on GitHub (Mar 25, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/597 ### Operating Systems ### Server: Linux Mint 19.1 Tessa Client: MacOS Catalina 10.15.4 ### Barrier Version ### Server: 2.3.2-snapshot-9080ce45 Client: 2.3.2-Release-210C2b70 ### Steps to reproduce bug ### 1. Start Barrier on Linux server - ip 192.168.1.135 2. Start Barrier on MacOS client, set it to connect to 192.168.1.135 3. Client shows "WARNING: failed to connect to sever: Timed out" 4. I verified Barrier was running and listening on the right port: `kit@wanderer:~$ sudo netstat -tupan | grep barrier` `tcp6 0 0 :::24800 :::* LISTEN 31192/barriers ` `tcp6 0 0 :::35785 :::* LISTEN 31068/barrier ` `kit@wanderer:~$` 5. I verified that the MacOS client can ping the server on 192.168.1.135 just fine. 6. I verified the Barrier client is set up to connect to port 24800. 6. Using "Autoconfig" doesn't work. 7. Both the Linux server and the MacOS client is on the same subnet. ### Other info ### * When did the problem start to occur? I've never used this before. * Is there a way to work around it? No * Does this bug prevent you from using Barrier entirely? Yes Any advice would be greatly appreciated, thank you.

gitea-mirror commented

2026-05-05 06:29:18 -06:00

Author

Owner

@Eddles commented on GitHub (Mar 25, 2020):

Update: I tried the following on the Linux server:

sudo iptables -I INPUT -p tcp --dport 24800 --syn -j ACCEPT

The MacOS client popped up an SSL warning and asked me to accept it. I clicked on "accept" but it's back to connection timing out the same as before.

One step forward, but still the same situation.

@Eddles commented on GitHub (Mar 25, 2020): Update: I tried the following on the Linux server: `sudo iptables -I INPUT -p tcp --dport 24800 --syn -j ACCEPT` The MacOS client popped up an SSL warning and asked me to accept it. I clicked on "accept" but it's back to connection timing out the same as before. One step forward, but still the same situation.

gitea-mirror commented

2026-05-05 06:29:20 -06:00

Author

Owner

@Eddles commented on GitHub (Mar 25, 2020):

Problem fixed - found an orphan Barrier thread still running and blocking the port.

So there's 2 issues here:

Linux firewall blocking the port - it'd be good if Barrier can identify this and let the user know.
Multiple instances of Barrier - again, it'd be good if Barrier can identify this and let the user know.

Many thanks!

@Eddles commented on GitHub (Mar 25, 2020): Problem fixed - found an orphan Barrier thread still running and blocking the port. So there's 2 issues here: 1) Linux firewall blocking the port - it'd be good if Barrier can identify this and let the user know. 2) Multiple instances of Barrier - again, it'd be good if Barrier can identify this and let the user know. Many thanks!

gitea-mirror commented

2026-05-05 06:29:24 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 27, 2020):

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions[bot] commented on GitHub (Sep 27, 2020): This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

gitea-mirror commented

2026-05-05 06:29:26 -06:00

Author

Owner

@sidouglas commented on GitHub (Jan 19, 2021):

For those coming from google:
Set both screen names of the mac and linux machines to something plain and simple ( no punctuation )

@sidouglas commented on GitHub (Jan 19, 2021): For those coming from google: Set both screen names of the mac and linux machines to something plain and simple ( no punctuation )

gitea-mirror commented

2026-05-05 06:29:28 -06:00

Author

Owner

@x64nik commented on GitHub (Mar 20, 2021):

sry for late answer,
so i was trying to share my keyboard and mouse from win10 (pc) to kali linux (laptop) on first startup i got a successful connection between 2machines but on 2nd startup i got this same error 'Failed to connect to server : Timed out'. my client ip and host ip was also correct but still i was not getting a connection then i found that the windows firewall is blocking the connection and that the main reason of connection Timed out

SOLUTION :- go to windows firewall and go to windows firewall properties and go in privet profile section and allow Inbound Connection. andddd we are DONE!

@x64nik commented on GitHub (Mar 20, 2021): sry for late answer, so i was trying to share my keyboard and mouse from win10 (pc) to kali linux (laptop) on first startup i got a successful connection between 2machines but on 2nd startup i got this same error 'Failed to connect to server : Timed out'. my client ip and host ip was also correct but still i was not getting a connection then i found that the windows firewall is blocking the connection and that the main reason of connection Timed out SOLUTION :- go to windows firewall and go to windows firewall properties and go in privet profile section and allow Inbound Connection. andddd we are DONE!

gitea-mirror commented

2026-05-05 06:29:31 -06:00

Author

Owner

@Nazareka commented on GitHub (Apr 28, 2021):

Update: I tried the following on the Linux server:

sudo iptables -I INPUT -p tcp --dport 24800 --syn -j ACCEPT

The MacOS client popped up an SSL warning and asked me to accept it. I clicked on "accept" but it's back to connection timing out the same as before.

One step forward, but still the same situation.

thank you!

@Nazareka commented on GitHub (Apr 28, 2021): > Update: I tried the following on the Linux server: > > `sudo iptables -I INPUT -p tcp --dport 24800 --syn -j ACCEPT` > > The MacOS client popped up an SSL warning and asked me to accept it. I clicked on "accept" but it's back to connection timing out the same as before. > > One step forward, but still the same situation. thank you!