If VMRC opens but reports “Invalid or expired session ticket” or “No response” while the web console works, inspect the VMRC workstation's path to the ESXi host. For the default MKS console transport in VMRC 11.x and 12.x, Broadcom documents a direct WebSocket connection to ESXi over TCP 443. Reaching vCenter in a browser does not prove that path works. A30-R1, A30-R2
This article is an inspection-only explanation of existing evidence. No console, connection probe, firewall change or client preference modification was executed.
Three endpoints are easy to confuse
The administrator workstation, vCenter and the ESXi host are separate endpoints. A successful browser connection to vCenter establishes access to that web service. It does not establish the workstation's direct route to every host that might run a VM.
The guest's own IP address is another endpoint again. A VM can serve an application while the remote console path is blocked, or its console can work while the guest application fails. Keep application reachability and MKS console reachability as separate facts.
Broadcom's VMRC case specifically describes web-console success alongside native-console failure. That comparison is useful because it narrows the observed failure, but it does not prove that the guest, its virtual switch or vCenter authentication is universally healthy.
Choose the right version and feature
Before interpreting a port record, obtain the installed VMRC version, the target VM's host at the failure time and the feature that failed. Console display and remote-device redirection do not have identical transport requirements.
The official matrix distinguishes:
| Feature and client version | Documented port distinction |
|---|---|
| MKS console, VMRC earlier than 11 | TCP 902 |
| MKS console, VMRC 11 or later | TCP 443 |
| Remote devices, VMRC 11.0 | TCP 902 |
| Remote devices, later than 11 with vSphere 7 or later | TCP 443 |
Older host combinations retain additional remote-device differences. Use the complete official matrix for those combinations; do not extend the MKS row to every USB or device-redirection feature. A30-R2
This prevents a common false conclusion: “TCP 902 is allowed, therefore VMRC 12 console traffic must work.” That observation does not establish the default 443 WebSocket path.
Map existing evidence to the actual host
Prerequisites are the VMRC error and time, current or historical VM placement, existing client logs and authorised network/proxy records. Use existing records rather than moving the VM or generating fresh traffic for this article.
Identify the host running the VM at the incident time. If vMotion occurred later, today's inventory can point to a different destination. Record the client network context as well: an office workstation, VPN client and jump host can have different access paths.
Compare the destination host name or address in the existing failure record with that placement. Establish whether the evidence reaches TCP connection, TLS handling, WebSocket establishment or a later console stage. If the logs cannot distinguish those stages, state the limit rather than declaring a firewall fault.
KB 436152 specifically identifies firewall or Web Application Firewall inspection/blocking of WebSocket traffic. An open TCP 443 path is therefore not sufficient evidence of a successful WebSocket upgrade. For Windows VMRC, the KB’s client log is %LOCALAPPDATA%\Temp\vmware-<user>\vmware-<vmrcPid>-mks-<loginUser>-<remoteMKSPid>.log; retain the time and BasicHttpOnSent with errorCode 28 responseCode 0, plus PlayerApp::OnLoginAbort, where present. These are existing-log checks, not a connection test.
Worked interpretation
Imagine a synthetic administrator workstation that can browse vCenter on 443. The web console opens, but VMRC 12 reports no response. Existing network records show the workstation's connection to the VM's ESXi host on 443 is denied.
That is direct evidence for a path-policy problem affecting the required endpoint. The successful vCenter browser session is consistent with it because it used a different destination. The appropriate handoff identifies client, host, port and time; it does not request a blanket rule opening every management network.
In another case, existing records show the transport connection succeeds but the console still rejects the ticket. The port evidence alone does not establish the remaining cause. Preserve the exact VMRC and host errors for further diagnosis instead of repeatedly opening firewall rules.
The matrix in KB 316564 lists vSphere 6.5–7.0 environments; it is not independent proof of every 8.x host combination. KB 436152 separately scopes the default WebSocket discussion to VMRC 11.x/12.x. Keep exact client/host applicability in the incident record. KB 316564 also documents disabling the WebMKS/WebRemoteDevice preferences as a legacy-mode alternative, restoring the TCP 902 requirement. That is a client-configuration change outside this diagnosis, not a proposed way to bypass the observed failure.
Acceptance and safe limits
A completed diagnostic identifies the client version, feature, host at the failure time, documented transport and the point the existing evidence reaches. It separates a supported path hypothesis from an unproven ticket or application problem.
After a separately authorised correction, proposed acceptance is a fresh VMRC console connection to the intended VM from the affected client context, with the required feature working. If device redirection matters, validate it separately against its own matrix. No acceptance test was run here.
Do not bypass certificate verification, alter legacy MKS preferences or restart host agents merely to test the hypothesis. Those changes can conceal the original boundary or affect unrelated operations. The diagnosis requires no configuration rollback; a later network or client change needs recorded previous settings and its own reversal plan.
Learning notes
- Browser access to vCenter does not prove workstation access to ESXi.
- VMRC version and feature determine the relevant transport.
- Working guest applications and working remote consoles are different outcomes.
References
- A30-R1: VMware Remote Console (VMRC) fails with "Invalid or expired session ticket" or "No response was received from the server"
- A30-R2: VMware Remote Console 11.x - connection error