IIS Manager Remote Admin: Check WMSVC's Own Address First

Your site answers on 443 through the tunnel, and IIS Manager still cannot connect to the server. That pair of results is not a contradiction, because the website and the remote administration endpoint are two listeners with two configurations and two sets of access rules. The management one belongs to the Web Management Service, WMSVC, and it has its own address, port, certificate and IPv4 restrictions. Check that endpoint before you touch a single route.

Two listeners, two different problems

A request to the site reaches the HTTP.sys binding for that site, which is defined per site and per protocol in the applicationHost configuration. A request from IIS Manager reaches WMSVC, which by default answers HTTPS on TCP 8172 and is configured at the server level. Nothing about the site binding changes where WMSVC listens, and nothing about WMSVC changes which address the site answers on. They share a machine and a certificate store, and that is where the similarity stops.

So a successful Test-NetConnection against port 443 tells you the site listener is reachable, and nothing at all about management.

Find the address WMSVC is actually bound to

Ask the server what it is listening on rather than what it was configured to listen on years ago. Get-NetTCPConnection -LocalPort 8172 -State Listen prints the local address, and a value of 0.0.0.0 or :: means all addresses while a specific address means only that one. If a server has had its addressing changed, a listener still pinned to a retired address is exactly the failure this check catches.

The configured value lives in the Management Service page of IIS Manager on the server node, and behind it in administration.config under the inetsrv configuration directory. Compare the two: what the file says, and what the socket is actually bound to.

Then run Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed from the affected VPN client and read the resolved address and the selected source address. A different DNS answer on the VPN is common enough to be worth ruling out early. Keep that exact hostname and port in the ticket, because a later comparison against a different name proves nothing about the change you made.

Read the source address the server sees

WMSVC's IPv4 restrictions are evaluated against the address that arrives at the server, which is not always the address your laptop believes it has. If the VPN pool is translated somewhere along the path, the server sees the translated address and an allow list built from the client's inner address will refuse it. That refusal looks like a connection failure from the client side, which is why it gets misdiagnosed as routing.

Use the detailed output of the TCP test, plus the server's own connection table, to see which source address actually arrived before you edit the restriction list.

Change the binding as a service change

WMSVC has to be stopped before its configuration is edited, so plan it as a change with another management path available, such as console access or a remote session that does not depend on IIS Manager. Stop the service, apply the address, port or certificate change, then start it and confirm the listener moved. Anyone else using remote IIS administration loses their session during that window. Tell the other administrators before the window opens; discovering it mid-change is how two people end up editing the same listener.

Choosing all addresses is a legitimate option, but treat it as an access decision rather than a shortcut. Broadening the listener while the restriction list stays open is how a management endpoint ends up exposed on a network nobody intended. If the server has several NICs, restrict the listener to the management interface, leave the data path alone, and confirm the site still answers on its own address.

The certificate WMSVC presents is selected separately from the site certificates. If you change the address, confirm the certificate still matches the hostname clients use, or the connection will fail later at the TLS step with a complaint that has nothing to do with routing.

Separate reachability from trust and permissions

Once TCP succeeds, the remaining failures are ordered: TLS trust for the management certificate, then Windows authentication, then the IIS Manager permissions granted to that account. Each of those produces a different error, and none of them is fixed by a route or a firewall rule. Read the error text literally instead of restarting the service again.

Work the four checks in that order, endpoint, listener, source address, trust, and you will usually find the stale binding before you find a network problem.