DCP should detect and advise on Windows reserved port ranges

[oising]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I ran into an apparent heisenbug issue recently whereby our Aspire solution failed to bind ports correctly on my workstation, but did so for everyone else. It turns out this was because Windows (specifically the WinNAT service) had reserved large blocks of TCP port ranges for itself, presumably for hyperv/docker/virtualization purposes. Other devs' systems had not reserved the same blocks - but had blocks reserved nonetheless. This doesn't appear to be an issue (presumably) when Aspire is allowed to dynamically allocate ports for its proxies. However, if Aspire is instructed to use static ports for its proxies, you run the risk of conflict with reserved port ranges.

c:\> netsh interface ipv4 sh excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
    49692       49791
    49792       49891
    49892       49991
    49992       50091  *
    50092       50191
    50214       50313
    50498       50597

* - Administered port exclusions.

Any attempts to declare a static port inside these ranges results in a wide variety of failures:

Describe the solution you'd like

DCP should enumerate and detect when declared static ports are in conflict with reservations, and advise on using a different port - or at least explain why the bind fails. I'm not sure if there's a "solution" per-se, but in the case of WinNAT, restarting the service did reset/remove the reservations. What other problems that may cause are beyond my knowledge and experience.

Additional context

Aspire 9.3, Windows 11/arm64, latest docker desktop.

[maddymontaquila]

@karolz-ms we hit this in the stream friday - i can repro on my machine if you need

[karolz-ms]

Funny thing we talked about this failure mode this morning at our issue triage, without even knowing this issue was reported (thanks @oising!) Must be a sign we need to address this soon! 😄

[dbreshears]

This is fixed in 0.15.15

[oising]

@dbreshears said:

This is fixed in 0.15.15

"Fixed" is a curious word to use for this situation. What was decided?

[danegsta]

We've added detection with specific error messages (and raising the error earlier) when a service with a fixed port has a conflict in the ephemeral port range on a machine (the dynamic Hyper-V reserved ports come from the ephemeral range).

On Windows, the default ephemeral port range is 49152 through 65535. Any randomly assigned or outgoing connection ports are allocated from that range, which makes it particularly prone to random conflicts when a service attempts to use a fixed port in the range.

[dbreshears]

@oising, fair point and "fixed" isn't the correct term here. We "addressed" this with better messaging and detection.