VMware ESXi and vCenter Remote Access for MSPs: Reach the Host Client and vSphere Client Without Opening Ports

Virtualization is where an MSP has the most to lose in one place. A VMware ESXi host or a vCenter cluster runs every production VM a client depends on: the domain controller, the file server, the line-of-business database. When a host needs a patch, a datastore fills up, a VM will not power on, or vCenter stops responding, someone on your team has to reach the management interface. The way you reach it decides whether that interface is also sitting in front of every attacker scanning the internet.

This guide shows how to give your engineers browser access to the ESXi Host Client, the vSphere Client, and the appliance shell across every client cluster, over one outbound tunnel, with no static IP, no open ports, and nothing installed on the hypervisor.

Why ESXi and vCenter must never face the internet

The ESXi management plane is a prize target, and the industry has the scars to prove it. In February 2023 the ESXiArgs ransomware campaign swept up thousands of internet-facing ESXi hosts, exploiting CVE-2021-21974, a heap overflow in the OpenSLP service, to encrypt virtual machine files directly on the hypervisor. CISA and the FBI issued a joint advisory after more than 3,800 servers were compromised worldwide, and the flaw it abused was already two years old at the time. The standing guidance from that incident is blunt: do not expose ESXi to the internet.

That guidance leaves the management interfaces exactly where they should be, on an isolated management network with no route in from outside. The ESXi Host Client answers on HTTPS over port 443, vCenter serves the vSphere Client on 443, and the vCenter Server Appliance management interface (VAMI) listens on 5480. SSH to an ESXi host is a separate matter: the TSM-SSH service is disabled by default and is meant to be turned on only for troubleshooting. None of these should ever answer an unsolicited connection from the public internet, which leaves the MSP with the familiar bad options. Forwarding 443 publishes the exact console attackers hunt for. A per-engineer client VPN is heavy to roll out across every site and still has to route the management VLAN correctly at the far end.

Reach the management network through one tunnel

ProxyLink works from the inside out. You install one WireGuard tunnel on the site's router or gateway: a MikroTik, a pfSense or OPNsense box, an OpenWrt or EdgeRouter, or any Linux host down to a Raspberry Pi. The tunnel dials outbound to ProxyLink and holds itself open with a keepalive, so the site never accepts an inbound connection, needs no static IP, and works fine behind carrier-grade NAT. Declare the management VLAN that your ESXi hosts and vCenter sit on as a subnet on the tunnel, alongside the main LAN, and every one of them becomes reachable with nothing installed on the hypervisor at all.

The links you create

Once the tunnel is up, you create a proxy link per interface:

• ESXi Host Client (HTTPS): an HTTPS link to a host on port 443 opens the embedded VMware Host Client in a browser tab, for VM power operations, datastore browsing, and service control on that host directly.
• vSphere Client (HTTPS): an HTTPS link to vCenter on 443 gives you the full vSphere Client, so cluster-wide work (vMotion, DRS, snapshots, host maintenance mode) runs through the same login as everything else.
• vCenter appliance management (HTTPS): a link to the VCSA on port 5480 reaches the VAMI for appliance updates, backups, and health, exactly when vCenter itself is unhappy.
• Browser SSH: when you have to drop to the ESXi shell, enable TSM-SSH on the host, then a ProxyLink browser SSH terminal puts you on it with no client on your laptop. SSH sessions can be recorded per link on paid plans when you need an audit trail of what ran on a client's hypervisor.

ProxyLink's default appliance mode rewrites the Origin and Referer headers so a web console's same-origin check accepts the proxied request, the same handling that makes Synology, UniFi, and pfSense UIs work through it. If a console rejects it, one toggle flips the link to app mode.

What this looks like for an MSP

One tunnel per client site covers the management VLAN and every other network you declare through the same peer. An engineer opens ProxyLink, clicks the client's vCenter, and is on the vSphere Client in a browser with no VPN client to launch. Every session is tied to an engineer identity, with the target IP, port, start time, and duration recorded, and access requires a ProxyLink login. The hosts keep zero open inbound ports and stay invisible to the internet scans that ESXiArgs relied on. Traffic runs over open WireGuard, and the relay is hosted in the EU on German infrastructure with no third-party routing of the session.

Access is scoped through the team model: each client is a group, engineers are granted only the sites they manage, and peer isolation keeps every customer's traffic separate at the network layer. The same tunnel that reaches the hypervisor also reaches the NAS holding the backups and the switch in the same rack, so the whole site is one browser tab away instead of one tool per device class.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. Setup guides for MikroTik, pfSense, OPNsense, and Linux gateways are in the docs.