Cannot connect to RealVNC Server

Cannot connect to RealVNC Server

avatar

I'm having trouble connecting to a RealVNC Server from RDM. It seems like it's first able to connect, then immediately disconnects while it's still just a black screen, and does that in an infinite loop. Looking at the Windows Event Log on the RealVNC Server, I see a series of the same sequence:

  • Connections: connected: 192.168.100.198::61004
  • Connections: authenticated: 192.168.100.198::61004, as (anonymous) (d permissions)
  • Connections: disconnected: 192.168.100.198::61004 ([System] write: Connection reset by peer (10054))

And it does that over and over, until I stopped the connection attempt.

Can't see nothing wrong in the logs on the RDM side.

I tried both the Windows and VNC authentication approaches, result is the same.

Using the RealVNC Client works fine, but I standardized all my remote access to dozens of machines with RDM, so I'd like to get that one working too. Most of my remote access is done over RDP, but in the case of this particular machine I need it to be VNC - it's an unattended machine and I cannot log the current user off and have to log back in.

Thank you everyone!

All Comments (8)

avatar

Hello,

For RealVNC, the recommended way to launch them is in external mode


Is your session configured like on the screenshot above?

Best regards,

Jeff Dagenais

ffa22a81-d7d4-44c2-bcc6-c6bd2ab6d34f.png

avatar

Well in this case, RDM merely becomes a shortcut to open another application (in which I need to type the password every single time).
That sort of defeats the purpose of using RDM as the one-stop for everything remote access.. ;)

That's a little frustrating, since RDM does offer VNC connectivity, but doesn't seem to truly support it... I was really hoping somebody from Devolutions or the community would help nail this down and make this work.

Thanks for your note anyways!

Any inputs, anyone?

avatar

Hi spilon

We're working hard to support as many scenarios as possible with the integrated FreeVNC application, and this case should work.

What's the version of RealVNC you're running on the server?

If possible, can you generate a diagnostic log from RDM?

  • Switch the connection back to embedded, being sure to select the "FreeVNC" application
  • Under Options > Types > Others > Other, check "Enable logging for ARD and VNC" and give a path to place the log file (e.g. c:\users\rmarkiewicz\desktop\vnc.log)
  • Close RDM and open it again
  • Try your connection. After it fails, a log file should be in the path given in the earlier step


You can send the log file to me either by PM, or to support@devolutions.net (being sure to mention this forum thread).

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

Kind regards,

Richard Markievicz

avatar

Hello again

For what it's worth, I just tested a connection to a Windows 11 server running RealVNC 6.10.1 and it worked well. So I'd like to try and reproduce the problem you're having, which seems to be either environmental or possibly a setting or configuration we don't support yet.

Please can you confirm the version of RealVNC on the server?

Also, I note that you tried both VNC and Windows (System) Authentication, but what do you have configured for authentication on the server? In the RealVNC options, what is configured under the "Security" tab for both "Encryption" and "Authentication"?

Please don't hesitate to post back if something isn't clear

Thanks and kind regards,

Richard Markievicz

avatar

Hi Richard, thanks for your responses and apologies for the delay in getting back to you.

I enabled logging as you suggested and was going to send the log file via private message, but I tried something else and resolved it in the meantime.

You pointed me in the direction of Encryption and Authentication... I am using VNC Authentication and this was configured properly within RDM. However I realized there were 4 encryption options, so I decided to try them all - here are the results:

  • Always maximum: "cannot connect" error message
  • Always on: infinite connection loop I described earlier
  • "Prefer on" or "Prefer off": works fine!!


Thanks again!

avatar

Hello again

First, I'm glad you found a workaround.

Since the settings relate to security, I'd like to explain and understand a little more what's going on. RealVNC encryption is a closed-source extension to the RFB (VNC protocol) that's normally only supported by their own viewer application. We have a partial implementation in FreeVNC; we support the 128-bit encryption level ("Prefer On" / "Always On") but not 256-bit ("Always maximum"). So I'm not surprised that "Always maximum" doesn't work.

However, I think that "Always On" should work and I did just try it successfully on my side. If you can help me investigate this a little further, can you tell me:

  • The server OS and RealVNC version on the server
  • Can you verify that in the RDM connection authentication settings; you have system (Windows) credentials configured and _not_ a VNC password? Importantly, the encryption will only work with system credentials and you should not have a VNC password configured at the same time.


Depending on your needs and environment, it could be preferable to have "Always On" encryption working.

Please let me know if something isn't clear

Thanks and kind regards,

Richard Markievicz

avatar

Thank you for your additional explanations.

The machine running the server is Windows Vista Professional SP2 32-bit and the RealVNC server is v5.2.0 32-bit. Admittedly a little aged of a setup, but this is on a production machine we don't have complete access to...

I wouldn't be surprised if these older versions explain the behavior we are experiencing... RDM is probably working as expected (with more recent OS/VNC versions), so I'm thinking it's probably best you don't waste any more of your time on this, especially now that I've found a workaround :)

Many thanks again!

avatar

Thank you for the update, it's not what I was expecting but you're probably right that the older Real version might have some quirks that we don't account for (our implementation of their encryption protocol is based on observing their client behaviour, we don't have access to the specification).

Please don't hesitate to post back with further questions or comments.

Kind regards,

Richard Markievicz