We're seeing a bunch of incorrect "Connection to server timed out" on macOS when connecting to a server that's on the same network as the macOS client. The logs show that the error code we get is EHOSTUNREACH: > 2025-02-18T09:27:47: ssh[E]: ssh: connect to host lab-132 port 22: No route to host > 2025-02-18T09:27:47: ssh[E]: CONNECT ERROR: 65 This is fake as the machine is up, and we can connect to it just fine using ssh on the terminal.
This seems to be a new feature in macOS 15 that is just incredibly buggy. They've added a new "Local Network" permission that blocks access to resources on the same network. It is supposed to pop up a dialog when an application tries a blocked access, so the user can approve it. But that is very unreliable. And even once you have approved the application, it is very unreliable that the application is actually unblocked. They also haven't yet fixed so you can reset the system for testing. Apple recommends running a VM, or creating a new test user. I can find a bunch of reports about this affecting Firefox and Chrome, so it is a general issue. Here is a Firefox report that is closed as they consider it an Apple issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1919889 And here is Apple's documentation for how it's supposed to work: https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy
I can see that there are multiple "ThinLinc Client" entries under "Privacy & Security" => "Local Network". I've seen some claims that this is part of when things break down. I'm also seeing multiple entries for Chrome in the same place. So it's not a ThinLinc specific problem.
It is unclear what triggers the issue, or resolves it. A reboot seems to get things working for a while at least.
A reboot isn't really reliable. After a short while, it stops working again. I suspect it might take a short while for the blocking system to boot up, and it works until then.
I've filled bug report FB16734000 using macOS Feedback Assistant.
It might be a signature issue. I tried the official 4.18.0 bundle, which gave me a prompt (even though ThinLinc Client was already listed in the privacy settings). After clicking yes to that prompt, and trying again, the client was now able to connect. Switching back and forth between an unsigned jenkins build, and the 4.18.0 client, reliably gives me an issue with the unsigned build, and works with the 4.18.0 build. We saw something similar when testing to use accessibility functions for keyboard grab. You could not mix signed and unsigned applications in that case. See bug 4660, comment 12.
One interesting note is that when I removed all copies of the ThinLinc client, then one of the entries under "Privacy & Security" => "Local Network" for tlclient can be seen as turned off, and it's not possible to change it (most entries won't change though). This hidden setting could be what is blocking things. I'm unsure if this entry was previously hidden, or if it was one of the existing entries that changed state. I didn't keep a list before and after removing the clients to compare. (There is also the odd behaviour that it doesn't forget about the client after all copies have been removed. But I think Apple documented that this is a known bug with the new "Local Network" check)
After wiping all copies of ThinLinc, rebooting, and installing the signed 4.18.0 version again, we're unfortunately back to a wedged state. This time with the signed client not working again. :/ Installing a development build, that now has a different bundle id, works fine, though.
I've managed to find where macOS stores the configuration for this: /Library/Preferences/com.apple.networkextension.plist If I toggle the permissions in the Settings UI, then I can see the values in this plist change. Note that this is a global file, not a per user one. I can not see any field that links this to a specific user. So it might be a complete lie from Apple that this setting is per user. Given the fields in the file, I was also able to find this code that seems to show how things are implemented: https://git.saurik.com/apple/mdnsresponder.git/blame/19fa75a9b9d0f880da91504945516a17ce09a2fb:/mDNSMacOSX/mdns_objects/mdns_trust_checks.m#l340 In short, MulticastPreferenceSet controls if the user has been queried, and DenyMulticast if the application should be blocked or not. We could try removing this file to reset everything. I can find some references that this can be done from recovery mode.
Removing the file seems to work well. The list is now empty in Settings, and com.apple.networkextension.plist is rebuilt with all applications found on the system but with all settings in their default values. Starting a signed 4.18.0 client initially fails, and gives a popup asking to allow it. After allowing it, it can then proceed. The same thing happens with an unsigned development build. After that, I now have two independent entries in Settings.
I just got a duplication for the TigerVNC 1.14.1 and TigerVNC 1.15.0 bundles. No idea why. Both bundles have the same id. Both bundles are signed by the same certificate. Both bundles are unmodified (confirmed by codesign). What I can see in the database is the original entry is still in place. It has just the id (com.tigervnc.tigervnc). At the end of the list, a new entry has shown up with not just the id, but also the path to the second bundle.
Upstream report: https://github.com/TigerVNC/tigervnc/issues/1912
