Two computers registered to the same self-hosted RustDesk server can establish remote desktop sessions, but they do not automatically join a shared IP network. The RustDesk ID and relay services coordinate or relay RustDesk connections; they do not create routes for ping, SMB, RDP, or Windows Remote Management.
To administer one RustDesk client from another with WinRM, use one of three designs: a private routed VPN, an existing trusted LAN/domain network, or a temporary RustDesk TCP tunnel. The VPN design is the most predictable for ongoing administration.
Understand the Separate Data Paths
The RustDesk server has two core services. The official self-hosting documentation describes hbbs as the ID/rendezvous service and hbbr as the relay. Clients may connect peer to peer or pass RustDesk session traffic through the relay.
WinRM is a Windows service using WS-Management. Microsoft documents default WinRM 2.0 ports as TCP 5985 for HTTP and TCP 5986 for HTTPS. A WinRM client must reach the target computer’s listener over IP and pass authentication and firewall policy.
These paths can coexist, but neither implies the other:
RustDesk path: admin client → peer-to-peer or hbbr relay → remote RustDesk client
WinRM path: admin client → routed private network → remote WinRM listener
Installing hbbs and hbbr alone creates only the first path. It does not make the RustDesk server a router and does not give it administrative access to clients.
Pick the Right Design
| Design | Best use | Main limitation |
|---|---|---|
| Same trusted LAN or domain network | Office or datacentre management | No reachability across unrelated NAT networks |
| WireGuard or managed mesh VPN | Persistent client-to-client and server-to-client administration | Requires VPN deployment, routes, identity, and lifecycle management |
| RustDesk TCP tunnel | Occasional access to one service during a RustDesk session | Per-session setup and more complicated WinRM identity handling |
| Public port forwarding to 5985/5986 | None for normal administration | Exposes a high-value management endpoint to the internet |
Do not publish WinRM directly on the public internet. A firewall allow-list reduces exposure but does not provide the operational isolation and identity design of a private management network.
Recommended Architecture: WinRM over a Private VPN
Assign every managed Windows computer a stable VPN identity and address. Let only administration devices initiate connections to the managed subnet.
An example plan could be:
Management subnet: 10.77.0.0/24
Admin workstation: 10.77.0.10
Remote workstation: 10.77.0.21
RustDesk server: optional VPN member, no automatic WinRM privilege
The values are examples, not a network to copy blindly. Avoid overlap with LANs used at remote sites, because overlapping routes make client-to-client reachability unreliable.
RustDesk remains the recovery and interactive-support channel. The VPN carries WinRM, monitoring, file services, and other explicitly approved management traffic.
Enable PowerShell Remoting on the Target
Run an elevated PowerShell session on the managed computer:
Enable-PSRemoting -Force
This configures the WinRM service, a listener, PowerShell session endpoints, and Windows Firewall exceptions appropriate to the active network profile. On a public network profile, review Microsoft’s current behaviour and avoid broadening access just to make a test pass.
Inspect the resulting state:
Get-Service WinRM
Get-PSSessionConfiguration
Get-NetFirewallRule -Name 'WINRM*' |
Select-Object Name, Enabled, Profile, Direction, Action
winrm enumerate winrm/config/listener
Then restrict the inbound firewall scope to the management subnet. First identify the enabled inbound WinRM rules on that Windows version, then apply the remote-address limit:
Get-NetFirewallRule -Name 'WINRM*' -Enabled True -Direction Inbound |
Get-NetFirewallAddressFilter
Get-NetFirewallRule -Name 'WINRM*' -Enabled True -Direction Inbound |
Set-NetFirewallRule -RemoteAddress 10.77.0.0/24
If the computer needs a different scope, replace the example subnet. Verify that the pipeline selected only the intended rules before changing them. Group names displayed by Windows can be localised, while internal rule names are generally more dependable for scripts.
Test Reachability Before Authentication
From the administration computer:
Test-NetConnection 10.77.0.21 -Port 5985
Test-WSMan 10.77.0.21
Test-NetConnection checks the TCP path. Test-WSMan verifies that a WS-Management endpoint answers. Neither proves that the account is authorised for the desired PowerShell endpoint.
If the port test fails, inspect the VPN route, Windows network profile, listener, and firewall. Do not start changing credentials when packets cannot reach the service.
Domain and Workgroup Authentication
In an Active Directory environment with correct DNS, use the computer’s fully qualified name so Kerberos can provide mutual authentication:
Enter-PSSession -ComputerName pc21.example.test -Credential (Get-Credential)
In a workgroup, Kerberos is unavailable. Microsoft notes that TrustedHosts may be required when mutual authentication cannot be established and recommends keeping the list as restricted as possible. Never use * as a convenience default.
Inspect the current setting and add only the intended host if your design requires it:
Get-Item WSMan:\localhost\Client\TrustedHosts
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '10.77.0.21'
Treat TrustedHosts accurately: it does not make the remote computer trustworthy, authenticate it, or authorise a user. It changes which destinations the WinRM client is willing to use for authentication. Keep the VPN encrypted, restrict the firewall, and use dedicated administrative credentials.
When to Use WinRM over HTTPS
WinRM’s HTTP transport does not mean PowerShell messages are necessarily plain text; authentication methods can provide message-level protection. However, workgroup environments, nonstandard clients, and compliance requirements often make HTTPS easier to reason about.
Microsoft’s current WinRM HTTPS guidance requires a valid local-computer certificate with Server Authentication usage and a name matching the target hostname. The default HTTPS port is 5986.
With an appropriate certificate installed, the documented quick configuration is:
winrm quickconfig -transport:https
Verify the listener and certificate thumbprint afterward. Do not accept an expired, mismatched, or casually self-signed certificate in production merely to remove an error message.
Temporary RustDesk TCP Tunnelling
RustDesk clients can allow TCP tunnelling. The official advanced settings identify the enable-tunnel permission under Security → Permissions.
For an occasional session, map a local unused port to the remote computer’s loopback WinRM listener:
Local port: 15985
Remote host: 127.0.0.1
Remote port: 5985
This can establish a transport path without a routed VPN, but WinRM authentication may not behave as expected when the client connects to 127.0.0.1 while the service and certificate identify the remote computer by another name. Kerberos SPNs, certificate matching, and TrustedHosts rules are name-sensitive.
Use the tunnel for controlled troubleshooting, not as an invisible permanent management fabric. Keep the RustDesk tunnel permission disabled on devices that do not need it and require an authenticated RustDesk session before opening a tunnel.
Can the RustDesk Server Run WinRM Against Clients?
Only if you separately give the server network reachability and Windows credentials. Being the RustDesk rendezvous or relay server grants neither.
If central automation must originate there, join the automation host—not necessarily the internet-facing RustDesk service itself—to the management VPN. Restrict routes and firewalls so it can reach only required WinRM targets, store credentials in an appropriate secrets system, and log administrative actions. Separating the RustDesk relay from the privileged automation host reduces the impact of a compromise.
A Clean Troubleshooting Order
When WinRM fails between remote PCs, check in this order:
- Confirm each VPN peer has the intended address and route.
- Test the target VPN IP with
Test-NetConnectionon port 5985 or 5986. - Confirm the WinRM service and listener on the target.
- Confirm the inbound firewall rule and its
RemoteAddressscope. - Run
Test-WSMan. - Resolve authentication: DNS/Kerberos for a domain, or tightly scoped workgroup configuration.
- Check PowerShell endpoint permissions and event logs.
RustDesk is valuable in this process because it gives you an independent interactive route to inspect and repair the target. The robust design keeps that recovery channel separate from the private routed channel used by WinRM.
