Hyper-V Remote Access for MSPs: Reach the Host, Windows Admin Center, and VM Consoles Without Opening Ports

Broadcom's VMware licensing changes have pushed a wave of small and mid-sized businesses off ESXi, and for most of them the landing spot is Hyper-V: it ships as a role in Windows Server they already own, and the tooling is familiar. For the MSP that now manages those hosts, the question is the same one ESXi raised. When a host needs a patch, a VM will not power on, a cluster node drops, or a checkpoint fills a volume, someone on your team has to reach the management plane. How you reach it decides whether that plane is also sitting in front of every attacker scanning the internet. This guide shows how to give your engineers browser access to Hyper-V hosts, Windows Admin Center, and VM consoles across every client site over one outbound tunnel, with no static IP, no open ports, and nothing installed on the host.

Why a Hyper-V host must never face the internet

A Hyper-V host runs every production VM a client depends on: the domain controller, the file server, the line-of-business database. Exposed RDP to a Windows server has been one of the most common ransomware entry points for years, and the host is the worst possible machine to lose, because losing it loses every guest at once. The management tooling makes exposure a non-starter on its own terms too. Hyper-V Manager connects to a remote host over WMI and DCOM, which answers on TCP port 135 and then negotiates a dynamically assigned RPC port for the actual session, so there is no single port you could forward even if you wanted to, and WinRM (5985/5986) and the VMConnect console (2179) sit alongside it. None of these should ever answer an unsolicited connection from the public internet. That leaves the MSP with the familiar bad options. A per-engineer client VPN is heavy to roll out across every site and still has to route the management network correctly at the far end, and forwarding RDP publishes the exact service attackers hunt for.

One tunnel reaches the whole host

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 your Hyper-V hosts sit on as a subnet on the tunnel, alongside the main LAN, and every host becomes reachable with nothing installed on it. The host stays exactly as it is: no agent, no extra service, no change to its own firewall.

The links you create

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

• Windows Admin Center (HTTPS): Microsoft's browser-based management tool serves over HTTPS on port 443 by default, and its Virtual Machines extension manages Hyper-V host settings, VM inventory, VM creation, live migration between cluster nodes, and VMConnect, on Windows Server 2012 and later. An HTTPS link to the Admin Center gateway puts all of that in a browser tab.
• Browser RDP to the host: because Hyper-V Manager and Failover Cluster Manager rely on WMI/DCOM and dynamic RPC ports, the clean way to run them remotely is to RDP to the host and run them there. A ProxyLink browser RDP session lands you on the host with no RDP client to launch and port 3389 never exposed to the internet.
• Cluster and storage: the same tunnel reaches every node in a failover cluster and the NAS or SAN management UI in the same rack, so you are not reaching the virtualization tier through one door and the storage behind it through another.

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 host, and is on Windows Admin Center or an RDP session in a browser with no VPN client to launch. 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. Every session is tied to an engineer identity, with the target IP, port, start time, and duration recorded, and RDP sessions can be recorded per link on paid plans when you need an audit trail of what ran on a client's host. The hosts keep zero open inbound ports and stay invisible to the internet scans ransomware relies on. Traffic runs over open WireGuard, with the relay hosted in the EU on German infrastructure and no third-party routing of the session.

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.