localhost connection refused

[OxyzOne]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Dotnet 6 AspNetCore started localhost port not working correctly on my machine:

OS Name: Microsoft Windows Server 2019 Standard
Version: 10.0.17763 Build 17763
System Type: x64-based PC

As you can see in 'Steps to Reproduce', dotnet run without any error but the localhost displayed port (20470, 20462) is not working instead it worked at other port (20366) which I don't know how and why, and also dotnet did not show any information about the new port.

Oddly this happend only to dotnet core but not .NET 4 (Using IIS Express) and NodeJs App in the same machine.

Expected Behavior

AspNetCore should work in the port specified by dotnet run process not in other random port.

Steps To Reproduce

1. Create new dotnet WebApi app

dotnet new webapi -n TestLocalhost

2. Go to the directory and run. Please note I didn't modify any code prior to run.

dotnet run
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:20470
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:20462
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: X:\Temp\code\TestLocalhost\

Notice that the port usually default to 4000 or 5000, but got 204xx

3. Goto the specified address in Chrome both http and https got:
   
4. Open command prompt check listening port found no listening port as specified:

netstat -a | findstr /c:"20470"
netstat -a | findstr /c:"20462"

5. Oddly I tried other listening localhost port and got the correct result of weather data:

https://localhost:20366/WeatherForecast

6. To make sure I didn't connect to other running webapi with port 20366, I terminated the dotnet run process from step#2 and tried again and it legitly returned failed response 'This site can't be reached'

Exceptions (if any)

No response

.NET Version

6.0.100

Anything else?

.NET SDK (reflecting any global.json):
Version: 6.0.100
Commit: 9e8b04bbff

Runtime Environment:
OS Name: Windows
OS Version: 10.0.17763
OS Platform: Windows
RID: win10-x64
Base Path: X:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
Version: 6.0.0
Commit: 4822e3c3aa

.NET SDKs installed:
5.0.101 [X:\Program Files\dotnet\sdk]
6.0.100 [X:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 5.0.1 [X:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.0 [X:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.1 [X:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.0 [X:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 5.0.1 [X:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.0 [X:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

[wtgodbe]

This is a weird one! Did you make any modifications to your app after running dotnet new? Is there anything else unusual about your setup? Are you by chance using containers? Are you able to push the project to a github repo & reproduce the failure on a different machine?

[ghost]

Hi @OxyzOne. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[OxyzOne]

@wtgodbe, so sorry for late reply, been so busy lately.

So, answering your question,

Did you make any modifications to your app after running dotnet new?
No, just plain: dotnet new webapi -n TestLocalhost, dotnet run

Is there anything else unusual about your setup?
Since my Windows enviroment is provided by our Infrastructure team I don't know much about the setup. I know they create a virtual machine for us and deploy some group policy. I tried several things in windows OS:

1. Disable windows defender firewall
2. Disable Antivirus.
3. Grant Administrator account.
4. Copy dotnet runtime/SDK to OS disk (C:) instead using from network location.
5. Dotnet new to OS disk (C:) and run from C:
6. Disable any applied group policy.

If this is OS/environment issue, I expect that it's also failed for .NET4 or NodeJS that run at localhost, but that's not the case.
As I understand that dotnet core run locally using Kestrel, .NET4 using IISExpress, NodeJs using express maybe.
So I think this issue maybe because some compatibility between OS and Kestrel

Q: can you give some clue of what possibly cause port reassign to other port ?

Are you by chance using containers?
You mean like Docker ? No, Don't even install it the OS

Are you able to push the project to a github repo & reproduce the failure on a different machine?
I think the project is exactly the same anywhere, I'm using : dotnet new webapi -n TestLocalhost

So I've tested 3 other different machine with same OS: 2/3 have same behaviour, 1/3 has no issue.

A little background story, we are planning to migrate our dev environment into Windows Server 2019 from Windows Server 2008 which is quite old but it has no issue at all.

This is really frustating, actually I found this issue since dotnet 3 but up until now even with dotnet 6 the issue persists.

Q: Do Kestrel has any mechanism to dynamically assign to other port if it failed to serve dotnet run in default or specified port ?

[wtgodbe]

So I've tested 3 other different machine with same OS: 2/3 have same behaviour, 1/3 has no issue.

A little background story, we are planning to migrate our dev environment into Windows Server 2019 from Windows Server 2008 which is quite old but it has no issue at all.

So you're running on Windows Server 2008? I suspect that this is the issue - Server 2008 is not in our support matrix, we haven't tested on it for a very long time. I would be surprised if the same failure occurred on Server 2019.

[ghost]

Hi @OxyzOne. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[OxyzOne]

@wtgodbe , The issue happened in Windows Server 2019, but no issue at all in Windows Server 2008.

[wtgodbe]

Oh, that's interesting - were all the machines you tested on part of your dev environment? It definitely seems like there's some issue there, though I'm struggling to think of what it could be that would reassign ports. We do still build and test regularly on Windows Server 2019, so any widespread issue with such a simple scenario would come as a surprise. @halter73 are you aware of any other reason Kestrel might be reassigning ports?

[halter73]

Q: Do Kestrel has any mechanism to dynamically assign to other port if it failed to serve dotnet run in default or specified port ?

No. And I highly doubt there are any regressions in reassigning ports.

I think this might have to do with how ASP.NET Core binds to "localhost" by default which prevents Kestrel from accepting external connections. There's some more discussion about this in #43149 @richlander @davidfowl

[adityamandaleeka]

Triage: unfortunately we can't reproduce this and there's not much we can do without more information/clues.

[ghost]

Hi @OxyzOne. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.