RDM not resolving localhost

Update: it looks like anything requiring name resolution is not working properly.

Hello

My gut feeling is that this might relate to the Local Network Access permission for the application; although unless Apple changed something here in 27 (I didn't see it in the release notes) it shouldn't gate access to the loopback address. However it would affect DNS because if the app is denied permission here, it can't get responses from mDNSResponder.

1. Can it be a network ordering issue? Because, localhost resolves both 127.0.0.1 and ::1, and ::1 is usually first. If the AnyDesk tunnel is only binding IPv4 that could definitely have got broken "somewhere". The simplest test is, does it work if you use 127.0.0.1 instead of localhost?

2. In System Settings > Privacy and Security > Local Network; I guess that Remote Desktop Manager is listed and enabled? It would be worth toggling it off and on again, and relaunching the app.

3. When you talk about broken name resolution, is it .local / short hostnames specifically or also fully qualified public names?

Please, let me know if something isn't clear or you have further questions

Kind regards,

Hi Richard,

This is most definitely looking like a "my machine" problem now - it has gotten worse as it is not connecting to local IP as though it does not have access to the network. I had looked at the local network permissions and RDM is enabled there. I closed RDM and disabled it though, restarted my Mac (overkill), then re-enabled network for RDM, and still the same.

I tried 127.0.0.1, it didn't work, but as with how I started my reply, it is now not connecting to a (local) IP address. Toggling the local network access has now changed the message to Connection failed (0x00020006), and this is trying to RDP to a local IP address.

I'm at a loss as to what is going on.

Ok, the local IP one was false positive... the machine had been shutdown by someone. So we're back to the rest of what I posted.

Hello

Wait, this is weird: your original screenshot shows the error message in the tab, but there's no RDP hex code there.

Just to confirm, based on your last message; an RDP connection to a local IP address is working, right?

Kind regards,

Everything has started functioning again, the only thing I did was toggle Local Network Access off and on again. I did this on its own with RDM closed and it still didn't work, I did it with a restart after toggling off and after toggling things back on again after the restart it still didn't work so tried a restart with it too... still no joy. I must've cycled this three times and then randomly while try try trying again and again it just came right. I'm confused as all hell about it, as I'm sure you are too... but it is all working again. The timelines are too tight for me to separate in my mind between Mac OS update to 27, the update of RDM, and things working and not working again. So for now I'm considering it resolved.

Oh, and thank you for the quick reply @Richard Markiewicz, it is appreciated. I was busy losing my mind 😅

Hi

I'm glad it's working again. I have to guess an issue with TCC after the macOS update, the feature has been consistently half-baked since they introduced it all that time ago and Apple seems to regress something on networking with every major update. Do you have any third party network extensions installed? When I saw this in the past, it was also something to do with a misbehaving VPN extension.

Anyway, the last time this came up I prototyped a test inside RDM that would show if the problem was TCC but never took it past the prototype stage. I think it will be good to finish that work and at least have something we can run inside RDM to understand if we effectively have local network access, despite what the system settings is saying. The trouble is that it's not something you can just ask to the OS like accessibility, you actually have to probe the network in a specific way. Anyway, I'll get on and make a ticket for that and try to get it finished. These scenarios are super frustrating.

Please, let me know if you have some other questions or comments

Kind regards,

I experienced this again after updating to 27.2 this morning. When I went to look, RDM was not listed in local network, yet other applications that I have not used since the update are. I'm not sure whether the persistence of RDM through a Mac OS update is something in RDM's power of control, but RDM didn't prompt either to request these permissions if it doesn't have them?

After granting RDM local network access it still wouldn't connect and a restart seemed to remove RDM from being on the local network access list. Adding it back to the list did not seem to resolve connectivity, initially at least. I say initially as I eventually tried connecting to a VM in my local network after which the localhost connections then started working properly. But, the first connection to my local VM "flashes" with what looks to be the last screen of when I was previously connected to that host and doesn't connect, but the subsequent connection attempts then do work. I can't put a timeframe to the behaviour whether it corresponds to the update of Mac OS to 27+ or RDM to 2026.3+.

Hi again

This is confusing, and frustrating. I don't like to shift the blame to Apple but the mechanics of this feature are truly outside of our control. Apple has a detailed technical note about it, which I've been through again this morning to try and understand your issue.

In short, on macOS the OS does not allow apps to access the local network until the user explicitly grants permission. In our case, the two items that need permission are:

• Making an outgoing TCP connection

• Resolving a local DNS name

Apple lists a number of considerations for macOS, none of which apply to RDM. Apple goes on to say

The system implements these TCP [...] checks deep in the networking stack, and thus they apply to all networking APIs. This includes Network framework, BSD Sockets, URLSession, and any APIs implemented on top of those.

For the alert itself, they say

You don’t need to do anything special to bring up the local network alert. The system displays it automatically when your program performs a local network operation. In most cases that’s the correct behavior.

So; essentially local network access is blocked until the user approves it. It's not checked until the application actually tries to access a restricted path, and at that point the OS itself shows the prompt. The "flash" and then failure to connect are simply RDM not waiting for approval. The user’s choice is supposed to be remembered (either an approval or a denial) and the user is not prompted again.

How is the choice tracked? I can say it doesn't seem to use the TCC database that other permission-blocked parts of the OS do, although I can't say what mechanism it uses and Apple doesn't publish that information. I did find a plist that seems to reflect what's in system settings:

plutil -p /Library/Preferences/com.apple.networkextension.plist | grep -i -B6 -A6 devolutions

Which is weird, because it doesn't seem to be protected by SIP; it looks like sudo is the only barrier to edit it.

The "build time considerations" on the technical note says

Local network privacy tracks the identity of your program using its code signature [...] To ensure that local network privacy reliably tracks the identity of your macOS program, sign it with an Apple-issued code-signing identity [...] Local network privacy uses your main executable UUID as part of its implementation. If your main executable has no UUID, or shares a UUID with other programs, local network privacy may behave weirdly. To fix that, make sure your main executable has a UUID and that it’s unique.

RDM Mac is signed with an Apple-issued code-signing identity, and every slice of the main executable has a unique UUID.

I really can't explain the situation you see. I know that Apple has made changes here, because in 27.2 I now see the ability to manually add and remove entries from the local network access list (that wasn't available before). I can tell you that on my machine, I have Remote Desktop Manager listed 11 times (that's normal for a development machine, I have the actual installed application in /Applications and then 10 pointers to different development builds that don't have a consistent code signature); but even in that case the local network access is persisted across updates of the installed application.

Like I said in my last post, I've been toying with some ways to diagnose these issues inside RDM. I think actually the best thing to do might be to force the application to show the prompt at startup if it's not granted. Apple covers this technique in the technical note; it's for applications that may need network access in the future but might not have an attending user to grant it. It probably makes sense to have that approach in RDM because the app is not very useful without this permission, and it can still be denied by the user. Whether that helps in your case or not I cannot say; it's very irregular that the application was removed from the list but again it's something managed purely by the OS.

I hope the technical details are useful, but I don't like passing the buck onto Apple here. If I have some other ideas I will post them.

Sorry for the inconvenience

Kind regards,

Hello again

I've tried to improve what we can do on our side for the 2027.1 release, which will be close to the end of the year.

I've made two changes:

• First, I've explicitly added a description for the OS permission prompt explaining why RDM wants this access. The documentation says that apps "should" include this description, although the technical note doesn't make it a hard requirement. Other similar prompts require a description to even display. I don't think this is the cause of the weirdness you've seen, but maybe it will help. Either way it's better behaviour from RDM.

• Second, I've made the app explicitly test for local network access at startup.

  • If the application isn't registered in the list of "local network" applications, it will prompt at that point rather than waiting for you to open a connection (which will fail, because we don't wait for the prompt to be accepted or declined).

  • If the application is registered but permission has been denied or disabled, RDM will show it's own prompt explaining that local network access is blocked. That prompt is silence-able with a "don't show this again" checkbox.

This doesn't fix the issues that you've reported which as far as I can tell are independent of RDM itself. But it should at least give a better experience if this issue does occur again. We should now proactively tell you that we don't have local network access, instead of waiting for you to try a connection to a device on the local network that then fails with an inexplicable error.

Please let me know if something isn't clear or you have further questions

Thanks and kind regards,