VMware Cloud Community
AndyNico
Contributor
Contributor

Error: VMRC - Failed to initialize SSL session to remote host

Hi,

I have a new macbook pro running High Sierra and i'm unable to use VMRC due to the error: Failed to initialize SSL session to remote host. No problems with webui, just vmrc. ssh is enabled.

My old MBP (running High Sierra also) is still working fine with VMRC to the same hosts (hosts are running 5.5 with the latest 1.29 Web UI)

Both MBPs are on the same network, using the same dns (which has been suggested in other articles might be an issue with the dns resolution).

Does anyone have any ideas what's missing on the new MBP preventing VMRC from initializing?

Thanks.

Tags (1)
16 Replies
bluefirestorm
Champion
Champion

Considering that it is an SSL session error, perhaps something failed with the SSL handshaking process. Since it is a new MacBook Pro with a fresh High Sierra install instead of an upgrade an earlier macOS version, it is possible that TLS1.0 is disabled by default either at High Sierra or VMRC or both.

For VMRC you can look at the version 10.2 release notes on how to add TLS 1.0 protocol

https://docs.vmware.com/en/VMware-Remote-Console/10.0/rn/vmware-remote-console-1002-release-notes.ht...

I haven't figured out how to check and re-enable TLS 1.0 status with High Sierra. But looks like it is disabled in High Sierra.

https://support.apple.com/en-us/HT207828

Reply
0 Kudos
AndyNico
Contributor
Contributor

Thanks for the tips bluefirestorm​ It got me thinking..

1. As per the release notes, tried configuring it to use tls 1.0 but the info in the RN was incorrect. There is no /Library/Preferences/VMware Remote Console/config. created it anyway, no effect

2. Tried creating a ~/Library/Preferences/VMware Remote Console/config but no effect

3. Decided to look at the ip session with wireshark; the old mbp is using tls 1.2 AOK. New MBP is also using tls 1.2. It appears to be transmitting quite a lot of data before the error occurs.

4. Tried logging in using the ip address of the host instead of dns name but ended with the same error

5. disabled antivirus - no effect

6. vmrc services log shows it exits normally

7. the old MBP was using vmrc client 10.0.1 so I copied it over to the new MBP (running 10.0.2) but still .1 had the same problem.

That's about all the ideas I've got for the moment!

Reply
0 Kudos
wfangchi
VMware Employee
VMware Employee

Could you verify the system time on your new macbook and hosts are correct? We've seen ssl error before due to incorrect system time.

If the system time is correct. Could you upload VMRC's log file here for us? Thanks!

Reply
0 Kudos
Alfaj0r
Contributor
Contributor

Having the same issue here, Mac with High Sierra, VMRC gives the same error, but I am able to use the web console just fine (using Chrome).

Here are parts of the vmware-vmrc.log that are likely relevant:

2018-08-08T16:12:35.497-08:00| VMware Remote Console| I125: VMClient_ConnectMksClientEx

2018-08-08T16:12:35.497-08:00| VMware Remote Console| I125: VMClient_ConnectMksClientEx - trying remote socket connection to x.x.x.x:902 /vmfs/volumes/5fe78593-952d52e9/VMname.vmx

2018-08-08T16:12:35.497-08:00| VMware Remote Console| I125: VMClientConnectSocketEx

2018-08-08T16:12:35.790-08:00| VMware Remote Console| I125: SSLVerifyCertAgainstExternalStore: certificate verification requires confirmation: 5

2018-08-08T16:12:36.177-08:00| VMware Remote Console| I125: VMClient_ConnectMksClientEx - connecting the MKS client

2018-08-08T16:12:36.178-08:00| VMware Remote Console| I125: VMClientConnectMKSClientEx

2018-08-08T16:12:36.191-08:00| VMware Remote Console| I125: VmdbAddConnection: cnxPath=/db/connection/#4/, cnxIx=1

2018-08-08T16:12:36.247-08:00| VMware Remote Console| I125: VmdbCnxControlCb: registered SUBSCRIBE completion callback, cnx = /db/connection/#4/

2018-08-08T16:12:36.356-08:00| VMware Remote Console| I125: SOCKET creating new socket, connecting to /tmp/vmware-username/rmksctrl/mksctrl-0000045598-000-2cd57aff

2018-08-08T16:14:29.704-08:00| VMware Remote Console| I125: BasicHTTP: Request 7F9FF13046A0 in state 1 timed out after 123.966 seconds having sent 0/578 and received 0/-1 bytes. Cancelling request.

2018-08-08T16:14:29.706-08:00| VMware Remote Console| I125: BasicHttpOnSent: xmlReadMemory (NULL == xmlDoc) errorCode 51 responseCode 0 message

2018-08-08T16:16:33.135-08:00| VMware Remote Console| I125: BasicHTTP: Request 7F9FF0C31AC0 in state 1 timed out after 123.428 seconds having sent 0/578 and received 0/-1 bytes. Cancelling request.

2018-08-08T16:16:33.138-08:00| VMware Remote Console| I125: BasicHttpOnSent: xmlReadMemory (NULL == xmlDoc) errorCode 51 responseCode 0 message

2018-08-08T16:16:44.739-08:00| VMware Remote Console| I125: VmdbPipeStreamsOvlError Couldn't read: OVL_STATUS_EOF (remote disconnect)

2018-08-08T16:16:44.739-08:00| VMware Remote Console| I125: VmdbCnxDisconnect: Disconnect: closed pipe for sub cnx '/db/connection/#4/' (-14)

2018-08-08T16:16:44.739-08:00| VMware Remote Console| I125: Internal VMDB error: Pipe connection has been broken (-14)

2018-08-08T16:16:44.740-08:00| VMware Remote Console| I125: Internal VMDB error: Pipe connection has been broken (-14)

2018-08-08T16:16:44.740-08:00| VMware Remote Console| I125: VmdbDbRemoveCnx: Removing Cnx from Db for '/db/connection/#4/'

Reply
0 Kudos
shawnmix
Contributor
Contributor

I'm currently running into this exact same issue I believe - almost identical. When connecting on my primary machine, or even a secondary machine running the latest OSX 10.14.(1 or 2) - I'm met with this error message trying to connect to the consoles. I do however have another MBP, that I'm able to successfully connect with no issues. The only variation, is that it is running OSX 10.14.0 - no extra updated version level installs. I'm led to think/believe that there is something changed in support for certain SSL/TLS capabilities or libraries that is at fault. I unfortunately lack the knowledge of what those may be or where to identify specifically the problem. Happy to run diagnostics as needed though if anyone can provide instruction.

Details:

- Non-Working Box:

  - VMware Fusion 11.0.2

  - OSX 10.14.2

  - Failed to initialize SSL session to remote host

- Working Box:

  - VMware Fusion 11.0.0

  - OSX 10.14.0

  - Connecting no issue

All systems are connecting to vCSA 6.7, with multiple (6) ESXi hosts runnings 6.7 (8169922). This has really become a major hindrance as my daily driver machine, is not able to connect to the console of any of these systems, yet the web GUI is able to connect with no issues. Really hoping someone can help here.

Reply
0 Kudos
shep8541
Contributor
Contributor

Was a fix ever found?

fastbone
Contributor
Contributor

Don't think so...

Still the same even with Fusion 11.1.0

Reply
0 Kudos
CuriosTiger
Enthusiast
Enthusiast

I am getting the same error trying to connect to an ESXi 6.7 deployment using Fusion.

Reply
0 Kudos
PhSLU
Enthusiast
Enthusiast

Still no solution ? Same problem here

vCenter Server Appliance 6.7.0.21000

VMware ESXi, 6.7.0, 13473784

VMware Remote Console Version 10.0.4 (11818843)

macOS Mojave Version 10.14.15

I did open a call to VMware support ... let's see if they come with a solution .

Reply
0 Kudos
PhSLU
Enthusiast
Enthusiast

I got an answer !

Incredible, it was a timezone discrepancy between my Mac (CET +1) and the vCenter (UTC).

VMRC is now working

Hope this helps people that have the same issues.

Reply
0 Kudos
elproductoONE
Contributor
Contributor

PhSLU

Can you elaborate on what setting you changed?The vCenter we are levering is used by many admins in different time zones, so not sure if it would be possible to make any change on vCenter timezone.

PhSLU
Enthusiast
Enthusiast

I understand that in this case you will not be able to apply the solution that helped me.

here was the situation :

My Mac is set to CET +1 ...indicating 1:30 p.m

My vCenter to UTC  ... indicating 11:30 a.m

This is "legit" and both time are correct (it's actually the same time but in different time zone)

I just change my vCenter to be CET+1, of course the time then became  1:30 p.m. ... and immediately after that VMRC from my Mac stopped displaying "Failed to initialize SSL session to remote host" and I was able to connect to VM Console.

I don't know in your case how you can solve the issue, may be it worth trying trying to change client side (on your Mac) the time zone to match the one of the vCenter.

Then both "side" have the same time 11:30 am in my exemple. and just see if my interpretation is correct.

But of course I would report that as a bug in VMRC !!!

PhS

Reply
0 Kudos
paulyang81
Contributor
Contributor

i faced the same problem on macOS Mojave 10.14 with VMRC 10.0.6, I checked the ESXi 6.7 host is UTC, changed the macOS Time zone to "London - United Kingdom", mac time is the same as ESXi server but still can't connect to the VM on Nov-20-2019.

Reply
0 Kudos
Solidbrass
Enthusiast
Enthusiast

paulyang81, I had to reboot the Mac for the time zone change to restore virtual console on my Mac.  I also had vCenter set to run UTC and the workstation set to local time, and I'd see this SSL error after about a day.  Prior to the reboot but after setting the system timezone to match the vCenter 6.7 appliance timezone, I still got the SSL error when initializing the virtual console.  You my also want to make sure that vCenter and the ESXi 6.7 host are in the same timezone.  Mine already were but I didn't even think about it until the workaround seemed to fail for me like it did for you.  I'd ensure that your vCenter, ESXi host, and Mac area also all synced to a reliable time source like time.nist.gov or time.apple.com or time.microsoft.com if you still have problems.

For anyone who runs into this, I can offer another workaround if the timezone change does not fix the issue or if changing your local workstation timezone is not acceptable for your work environment.  If your Mac is old enough, you can downgrade to macOS 10.13.6 (which still gets patches and can be fully patched, though it does not have all the OS hardening that 10.15 does) and then you can run VMware Fusion Pro 10.1.6 as your virtual console.  This configuration is stable for me and has been for over a year.

I just found this thread this morning, and I already have a support request open for it that perhaps others can reference to get some weight behind fixing this, as running an obsolete OS and obsolete Fusion Pro version is not optimal.  My support request is #19073072910.  I will also note that I reported this bug last year when Fusion Pro 11 and Mojave were released.  It was verified by VMware engineering at the time, but apparently not fixed for Fusion Pro 11.5.

Reply
0 Kudos
Solidbrass
Enthusiast
Enthusiast

This seems to be a temporary workaround.  It has since stopped working with resumption of the same issue.  I have to recommend the 10.13.6/Fusion Pro 10 workaround instead.

Reply
0 Kudos
OIUTWQE
Contributor
Contributor

Just want to bump this post to say this is still an issue. Has anyone got a solution yet? I tried to downgrade my Mac Catalina system to 10.1.6 bit all VM's just end up with a blank screen.