github-starred/barrier

Fork 0

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

[GH-ISSUE #261] client uses wrong server ip address with auto config #210

New issue

Open

opened 2026-05-05 05:41:25 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 05:41:25 -06:00

Owner

Originally created by @ArntWork on GitHub (Mar 1, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/261

Operating Systems

Server: Windows 7 SP1

Client: Mac OS 10.13.6

Barrier Version

Server (windows): 2.1.0-RELEASE-0b2dfd80
Client (Mac): 2.1.0-RELEASE-8b69f9fe

Steps to reproduce bug

Server has multiple network cards and IP addresses due to VM's (using VirtualBox) plus wired and wireless external networks. The 'real' ip addresses (on the external connection) are assigned via dhcp, so they are variable.

The client is set to auto config, and in the log I see tries to connect to an IP address that is internal to the server. This address is the one in bold on the server side, however there is no efficient way to make this the right one. I applied advice from https://symless.com/forums/topic/69-default-bold-ip-address-on-server-is-incorrect-one/ to set the right interface first in the network settings, that did not change the bolded address. I also tried to enter the correct ip address into the 'Interface' field (under networking) but also did not change the bolded address and did not fix the issue.

What is strange is that the only way for the client to get this incorrect IP address, is to have a successful connection with the server, because the address isn't known outside the server...

Other info

When did it occur: after I started the barrier interface on the server (Windows)

Workaround: if I turn off auto-config, but now I have to manually add the ip address on the client, and as said, dhcp, so it changes.

Ideas/suggestions:

allow me to put a dns name in the current 'server IP' filed on the client This will fix the 'ip address is variable' trouble in my workaround and will generally be an improvement as it means less relying on ip addresses and more on dns names, which is what most of us identify our machine by, I think.
document the 'Interface' field somehow, so we know what to put there. Or better: make it a dropdown to list interfaces, so we don't have to know what it expects. In case it expects an IP address (that doesn't work for me however), allow a dns name as well
the ip address that the client wrongly tries to use, comes form the server, so the client already knows how to reach the server? (I don't know how, but whatever it is, it will include the correct ip address as the source I would think?)

Note that https://github.com/debauchee/barrier/issues/81 claims to hold code for a solution, but is closed and I see no way to reopen it. I'm not currently set up to build barrier, unfortunately.

Originally created by @ArntWork on GitHub (Mar 1, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/261 ### Operating Systems ### Server: Windows 7 SP1 Client: Mac OS 10.13.6 ### Barrier Version ### Server (windows): 2.1.0-RELEASE-0b2dfd80 Client (Mac): 2.1.0-RELEASE-8b69f9fe ### Steps to reproduce bug ### Server has multiple network cards and IP addresses due to VM's (using VirtualBox) plus wired and wireless external networks. The 'real' ip addresses (on the external connection) are assigned via dhcp, so they are variable. The client is set to auto config, and in the log I see tries to connect to an IP address that is internal to the server. This address is the one in bold on the server side, however there is no efficient way to make this the right one. I applied advice from https://symless.com/forums/topic/69-default-bold-ip-address-on-server-is-incorrect-one/ to set the right interface first in the network settings, that did not change the bolded address. I also tried to enter the correct ip address into the 'Interface' field (under networking) but also did not change the bolded address and did not fix the issue. What is strange is that the only way for the client to get this incorrect IP address, is to have a successful connection with the server, because the address isn't known outside the server... ### Other info ### When did it occur: after I started the barrier interface on the server (Windows) Workaround: if I turn off auto-config, but now I have to manually add the ip address on the client, and as said, dhcp, so it changes. Ideas/suggestions: - allow me to put a dns name in the current 'server IP' filed on the client This will fix the 'ip address is variable' trouble in my workaround and will generally be an improvement as it means less relying on ip addresses and more on dns names, which is what most of us identify our machine by, I think. - document the 'Interface' field somehow, so we know what to put there. Or better: make it a dropdown to list interfaces, so we don't have to know what it expects. In case it expects an IP address (that doesn't work for me however), allow a dns name as well - the ip address that the client wrongly tries to use, comes form the server, so the client already knows how to reach the server? (I don't know how, but whatever it is, it will include the correct ip address as the source I would think?) Note that https://github.com/debauchee/barrier/issues/81 claims to hold code for a solution, but is closed and I see no way to reopen it. I'm not currently set up to build barrier, unfortunately.

gitea-mirror commented

2026-05-05 05:41:28 -06:00

Author

Owner

@Cobalt6700 commented on GitHub (May 20, 2020):

I have this exact same issue, using Win 10.

I have a Hyper-V Virtual Ethernet Adapter and when enabled barrier defaults to this IP range.

Changing the client side to manual IP allows me to connect - auto connect doesn't work.

@Cobalt6700 commented on GitHub (May 20, 2020): I have this exact same issue, using Win 10. I have a Hyper-V Virtual Ethernet Adapter and when enabled barrier defaults to this IP range. Changing the client side to manual IP allows me to connect - auto connect doesn't work.

gitea-mirror commented

2026-05-05 05:41:30 -06:00

Author

Owner

@enordstrand commented on GitHub (Nov 20, 2020):

Seems to be the same issue I am experiencing. The server has bolded another IP address than the one I want to use, so the Client tries to auto-connect incorrect IP.

@enordstrand commented on GitHub (Nov 20, 2020): Seems to be the same issue I am experiencing. The server has bolded another IP address than the one I want to use, so the Client tries to auto-connect incorrect IP.

gitea-mirror commented

2026-05-05 05:41:33 -06:00

Author

Owner

@davidthewatson commented on GitHub (Nov 24, 2020):

I've got the same configuration: win10 pro barrier server and macos catalina barrier client. The client ignores the setting in the server IP field and instead goes to another IP address. In the barrier client log on macos, it outputs the following:

[2020-11-24T17:45:25 WARNING:  failed to connect to server: Timed out
[2020-11-24T17:45:26] NOTE: connecting to '192.168.50.75 ': 92.242.140.21:24800

The correct IP address for the server is 192.168.50.75. The incorrect IP address is 92.242.140.21. This happens after stopping and restarting barrier. I've yet to find a way around it.

Barrier client on linux continues working with the same Win 10 Pro barrier server without issue.

@davidthewatson commented on GitHub (Nov 24, 2020): I've got the same configuration: win10 pro barrier server and macos catalina barrier client. The client ignores the setting in the server IP field and instead goes to another IP address. In the barrier client log on macos, it outputs the following: ``` [2020-11-24T17:45:25 WARNING: failed to connect to server: Timed out [2020-11-24T17:45:26] NOTE: connecting to '192.168.50.75 ': 92.242.140.21:24800 ``` The correct IP address for the server is 192.168.50.75. The incorrect IP address is 92.242.140.21. This happens after stopping and restarting barrier. I've yet to find a way around it. Barrier client on linux continues working with the same Win 10 Pro barrier server without issue.

gitea-mirror commented

2026-05-05 05:41:36 -06:00

Author

Owner

@davidthewatson commented on GitHub (Nov 28, 2020):

Turns out that the wrong IP address that I noted above is barefruit in the UK:

https://whatismyipaddress.com/ip/92.242.140.21

Why this breaks the mac barrier client is a mystery. I'm going to take a look at the source and see if I can figure out what's going on because at this point, nothing has changed on my end, but whatever is going on completely broke my mac client in a windows server, linux client, mac client barrier setup that has been working flawlessly for months.

Not only that, but this error survives clearing barrier's library application state in the local Library directory, and in fact, survives dragging the barrier install to the trash and completely re-installing from the DMG. Whatever is going on, it's persistent.

I may try blocking barefruit at my router because I think the DNS is causing this to go awry and I believe that may be originating with Verizon but no evidence, just a hunch.

@davidthewatson commented on GitHub (Nov 28, 2020): Turns out that the wrong IP address that I noted above is barefruit in the UK: https://whatismyipaddress.com/ip/92.242.140.21 Why this breaks the mac barrier client is a mystery. I'm going to take a look at the source and see if I can figure out what's going on because at this point, nothing has changed on my end, but whatever is going on completely broke my mac client in a windows server, linux client, mac client barrier setup that has been working flawlessly for months. Not only that, but this error survives clearing barrier's library application state in the local Library directory, and in fact, survives dragging the barrier install to the trash and completely re-installing from the DMG. Whatever is going on, it's persistent. I may try blocking barefruit at my router because I think the DNS is causing this to go awry and I believe that may be originating with Verizon but no evidence, just a hunch.

gitea-mirror commented

2026-05-05 05:41:38 -06:00

Author

Owner

@davidthewatson commented on GitHub (Nov 28, 2020):

Indeed, I set DNS explicitly at the router and turned off Windows private network firewall on the Windows barrier server, and now my mac barrier client is working again. No barefruit DNS. I'm still not sure why that hijacks the barrier client, but the log I displayed previously:

[2020-11-24T17:45:25 WARNING:  failed to connect to server: Timed out
[2020-11-24T17:45:26] NOTE: connecting to '192.168.50.75 ': 92.242.140.21:24800

is now:

[2020-11-24T17:45:26] NOTE: connecting to '192.168.50.75'

without the trailing colon and the IP address to barefruit.

@davidthewatson commented on GitHub (Nov 28, 2020): Indeed, I set DNS explicitly at the router and turned off Windows private network firewall on the Windows barrier server, and now my mac barrier client is working again. No barefruit DNS. I'm still not sure why that hijacks the barrier client, but the log I displayed previously: ``` [2020-11-24T17:45:25 WARNING: failed to connect to server: Timed out [2020-11-24T17:45:26] NOTE: connecting to '192.168.50.75 ': 92.242.140.21:24800 ``` is now: ``` [2020-11-24T17:45:26] NOTE: connecting to '192.168.50.75' ``` without the trailing colon and the IP address to barefruit.