Unable to open a specific server via FreeVNC

Hello

Ok, based on what you wrote, I can take a guess at the problem - I assume you're using system authentication (username/password credentials) and not just a password (VNC authentication)? If that's the case, it's likely that you have 256-bit AES encryption enabled. If I remember correctly, FreeVNC doesn't currently support it but I think IronVNC does.

You could help by verifying that:

• On the RealVNC server, allow 128-bit encryption
  • The relevant documentation is here. As I understand it, the setting should be "AlwaysOn" (not "AlwaysMaximum") to allow clients to use 128-bit encryption
  • Try the connection again using FreeVNC; if it works no need to perform the next step
• In RDM, go to File > Settings > Entry Types > Sessions > Apple Remote Desktop (ARD) / VNC
  • Under "Logging", check the box to enable the logs and provide a path to create a log file (e.g. C:\users\username\desktop\rdm-vnc.log)
  • Save the changes and restart RDM
  • Retry the connection, you should find a log file in the location specified that you can send to me by PM
  • Disable logging again afterwards, it has a performance impact

Broadly, the IronVNC integration in RDM is quite immature as the focus on that project has been to enable VNC in the web (through Devolutions Server). IronVNC can be compiled for web whereas freevnc - a C based library - cannot. It is a medium term goal of ours to uplift the IronVNC integration and replace FreeVNC but we're not there yet. If this turns out to be the problem, it might be that we have to add the 256-bit encryption level to FreeVNC if downgrading it on the server is not an option for you.

Anyway, I'd like confirmation that this is the problem before taking that further. It would be really helpful if you can carry out the above troubleshooting for me.

In the meantime, please don't hesitate if you have other questions or problems.

Kind regards,

Hi Richard,

Thank you for your detailed explanation. It is an awesome experience to have such a good level of support for our little issue and I certainly appreciate the effort.

Regarding option 1, that is unfortunately a no-go as we are not able to change any of the settings on the host machine we are trying to connect to.

I have sent over the logs privately. Let me know if there's anything else I can do !

Thank you so much, happy holidays.

Hello

Thanks for sending the log file however it's not what I was expecting.

In the log I see an initial connection to a server with an IP address ending in 22, using VNC authentication; and that connection seems to work. Then I see a failed connection to a server with an IP address ending in 2, using TLS authentication, and that connection seems to fail.

Does that match what you did when you created the log? Is the second server (with the IP ending in 2) the problematic one?

If so, it is strange because the server offers both VNC and TLS authentication, both of which FreeVNC supports. So it's likely you're hitting some other bug.

I'd really appreciate if you can confirm:

• The exact VNC server version (e.g. RealVNC x.x.x)
• The exact server operating system and version
• In RDM, what type of credentials are you using?
  • It will be either a plain password, or "system" or "NTLM" (I can't remember how it's labelled) with both a username and password

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

Thanks and kind regards,

Hi Richard,

The connection to .22 was just to check it worked generally speaking, but the .2 is the one we're struggling with.

Because the server is a proprietary machine from one of our partners running a modified distro (which I believe is based on GNOME), and which we have no access to whatsoever outside of the VNC window which just presents a single software it is not possible for me to look into the VNC server version numbering, or even the exact server OS. I appreciate that this does make the matter far more challenging than it ought to be...

Regarding your third point, I'm not sure I am totally getting what you're saying but we have tried using both the system and VNC password fields as well as entering nothing and filling the pop up that appears on screen.

Are there any troubleshooting steps I could undertake to help you that do not necessitate any access to the main server?

Thanks again for your support and so sorry for the hoops you're having to jump through to help me !

Happy holidays,

Best,

Mathis

Hello

Ok, so it's hard to reproduce the issue if I can't know the server version; but since this works (at least, you can connect) with IronVNC the issue should certainly be solvable. But we just need more information. I think I need to understand what's happening in the working case - please know that I am not jumping through hoops here, but I apologize for asking you to do the same!

Here's what I'd like you to try:

• Close RDM completely
• Open PowerShell (if you don't have PowerShell, let me know, and I can revise the instructions for cmd.exe - basically we just need to set some options that aren't available in the UI)
• Use the following commands (pressing "Enter" after each one)
  • Importantly ensure you customize the path for the log file to be created to a location on your machine; I've used the path to my desktop as an example
  • Importantly this assumes RDM is installed in the default location of C:\Program Files\Devolutions; if it's not you'll need to customize the path used to launch RDM

$Env:IRONVNC_LOG="trace"
$Env:IRONVNC_LOG_PATH="C:\users\rmarkiewicz\desktop\ironvnc.log"
& 'C:\Program Files\Devolutions\Remote Desktop Manager\RemoteDesktopManager.exe'

• What this will do is setup IronVNC to log at a "trace" level to the file "ironvnc.log" in the path specified, then launch RDM with those settings
• Now, change your connection settings on the problematic session to use "Embedded" and "IronVNC" as the VNC application
• Launch the session - it should connect as expected, although exhibit the screen artifacts
• Now you can send me the log file that got created, by private message or to service@devolutions.net (mentioning this forum thread)
• Finally close RDM and PowerShell to put everything back to defaults

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

Kind regards,

Hello again

I've had (what seems to be) an identical issue reported in this thread. With the additional context, I believe I understand the issue and I'm working on integrating a fix. I'll post back here once that's available. In the meantime no further troubleshooting is needed on your side.

Thanks for your patience

Kind regards,

Hello again

I'm confident this issue will be resolved in the upcoming 2025.3.30 release, which should be available within the next couple of weeks. I'm afraid in the meantime I don't have a workaround other than to continue using the "external" VNC client. Thanks for your patience.

Kind regards,

Hi Richard,

Apologies for the late reply, I was on holidays. Reading through the thread you linked I do see similarities, especially when it comes to the age of the servers. The one I'm trying to work with was deployed in the early 2010s and likely hasn't seen any real protocol updates since.

I'm very much looking forward to the update to RDM and thank you for your work. On the offchance it might still help, I did take the time to go through your original instructions and I have sent you the log file by PM. I will note annedoctically that for the first time I did not get any screen artifacts on this session...

Thank you again for your help.

Best,
Mathis

Hello

Thanks for that, it confirms the issue and I'm confident it will be resolved in 2025.3.30. Please let us know if you have any trouble or questions after that version is available and you update.

Best regards,

Hi Richard,

Just dropping by to confirm the update has fully resolved the issue. I'm very grateful for your help, thanks again ! RDM is proving to be a very useful tool to us so far.

Best,

Mathis

Hello

Excellent news and I'm glad RDM is proving useful. Please don't hesitate to post back with further comments or suggestions.

Kind regards,