I believe I have discovered a very strange, narrow issue relating to an interoperability problem with IIS and WINRM exercised by Powershell on Windows 10.
I have a device that has an IIS site bound exclusively to the localhost address, 127.0.0.1. When configured in this way, using "localhost" in a browser address bar doesn't work; the connection will either be refused or reset. The site can only be accessed 127.0.0.1 (explicitly). This issue is solved by adding 127.0.0.1 to the iplisten list via "netsh http add iplisten" command. With that done, the localhost-bound site then works. So far, so good.
But here's where it gets peculiar. The moment the localhost address is added to the iplisten list, remote commands via Powershell (invoke-command --> winrm) stop working. On the device, test-winrm against its public IP address now fails. "winrm quickconfig" indicates the device is already configured for remote and is working correctly. But no remote commands work, all reporting the "destination cannot be reached." Querying the listeners on the target device show all the appropriate endpoints defined and configuration for RM to be as expected - it all looks like it should work. There are no firewalls blocking access.
The solution? Removing 127.0.0.1 from the iplisten list on the target device instantly eliminates the problem, and powershell/remote commands begin to work. But then we're back to the original problem; "localhost" in the browser fails. As a workaround, I can create a phony DNS "alias" in hosts that point back to 127.0.0.1, but I'd really rather not have to mess with hosts if possible.
It seems to me that this is, in reality, a hiccup/bug in minimally network resolution on the target device; adding the 127.0.0.1 address to the explicit iplisten list shouldn't break remote WinRM connections over an entirely different address. It would seem that this is, inadvertently, routing all HTTP traffic to IIS, and when a remote command is sent to it, IIS obviously gets it "first," has no binding for it (over port 5985), has no idea what to do with it, and discards it, causing the remote command to fail. In reality, it seems to me IIS should never even see it; but adding the loopback address to the iplisten list routes such traffic precisely that way.
Is there something I'm missing or not understanding about how traffic gets routed, or some aspect of this setup I've simply overlooked? IF there is some additional step I have missed, I'd appreciate direction to resolve it.
