Yarp container can't proxy to service on host

[Suiram1701]

Is there an existing issue for this?

• [x] I have searched the existing issues

Describe the bug

(As said in the headline) the yarp container created by Aspire.Hosting.Yarp is unable to proxy to a ASP.NET application running on the host maschine.

The container it's self start without any problem but when I try to access the site using reverse proxy I get an 502. The stacktrace that apeared in the console sais that the hostname host.docker.internal cannot be resolved. A StackOverflow post sais that this problem is common on Linux (I'am running everything on Linux Mint 22.2) because this hostname (which represents the host gateway on the docker network) isn't set by docker on Linux.

I tried to to add the host name manuell by using .WithContainerRuntimeArgs("--add-host", "host.docker.internal:172.17.0.1") (this is the gateway in my case) and that resolved the issue of resolving the name but instead I get a 504 by the gateway and the stacktrace in the YARP console sais that the connection to the service timed out.

I also tried to use the host network for the container but it seems that aspire overrides this with its own network.

To fix this I changed the addresses the service is listening on to 0.0.0.0 and it does listen there but now regardless what port I set I random port number is used.

Expected Behavior

It would be nice when Aspire would support the interaction from yarp container to service on host "out of the box". Now I think it can access the host ports but I can't get the service to listen on a constant port / a port that aspire knows. Also in the dashboard isn't the real port the service is listening now shown.

Steps To Reproduce

1. Be on Linux (I think that has something to do wit it)
2. Create a solution containing a default .NET Aspire and a default .NET ASP.NET web application
3. Add the Aspire.Hosting.Yarp package to the Aspire host.
4. Add the folowing to the Aspire host project:

builder.AddYarp("gateway").WithConfiguration(yarp => {
     yarp.AddRoute("{**catch-all}", sampleService);
});

5. Start the Aspire application
6. Open the address displayed for the gateway

Exceptions (if any)

No response

.NET Version info

.NET SDK: Version: 9.0.306 Commit: cc9947ca66 Workload version: 9.0.300-manifests.87361a52 MSBuild version: 17.14.28+09c1be848

Runtime Environment: OS Name: linuxmint OS Version: 22.2 OS Platform: Linux RID: linux-x64 Base Path: /usr/share/dotnet/sdk/9.0.306/

.NET workloads installed: There are no installed workloads to display. Configured to use loose manifests when installing new manifests.

Host: Version: 9.0.10 Architecture: x64 Commit: e1f19886fe

.NET SDKs installed: 8.0.415 [/usr/share/dotnet/sdk] 9.0.306 [/usr/share/dotnet/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 8.0.21 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 9.0.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 8.0.21 [/usr/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 9.0.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found: None

Environment variables: Not set

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

Anything else?

Aspire version (Sdk, AppHost, Orchestation): 9.5.2 Aspire.Hosting.Yarp: 9.5.2-preview.1.25522.3 JetBrains Rider: 2025.2.3

[davidfowl]

This will be fixed in the next version. Lots of foundational problems needed to be fixed to make it "just work". We showed this in our halloween episode of aspirifridays https://youtu.be/inowoXFbP9s

• Container to Host tunnel working without docker desktop (across container runtimes)
• HTTPS from container to host (automatic certificate trusting inside of containers)
• TLS termination with YARP (showed in video, not in that version yet)

cc @danegsta

[karolz-ms]

Also check how the new container proxy is enabled in the Yarp playground application: https://github.com/dotnet/aspire/blob/main/playground/yarp/Yarp.AppHost/appsettings.json

[Suiram1701]

Alright. I tried to start it in the playground but for some reason the package restore for the ServiceDefaults fails. But its good to now that this is already known and its been worked on.

Is it already known (round about is enough) when this will be published?

[davidfowl]

next week Aspire 13 will be released.

[Victor-Ochoa]

Hi, this error continues on the Aspire 13

[karolz-ms]

@Victor-Ochoa did you use the container tunnel? (https://aspire.dev/whats-new/aspire-13/#universal-container-to-host-communication, ASPIRE_ENABLE_CONTAINER_TUNNEL environment variable)

[davidfowl]

@karolz-ms can we turn this on by default in main so we can work through the issues?

[Victor-Ochoa]

it worked! you guys are badass! @davidfowl and @karolz-ms

[karolz-ms]

@davidfowl that is the plan, and it is very high on my priority list, but I want to do some perf verification/infra work first so we have a good picture re perf impact.

[Suiram1701]

@karolz-ms I could get it also to work by setting the enviroment variable and start the app host in HTTP only. Now there is an issue with the HTTPS support. The YARP logs say that the certificate mismatches the host name. I think this happens because the app running on the host still serves the dev certificate which is issued for localhost while YARP sees the service as aspire.dev.internal (which obviously mismatches).

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
       ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch

I've tried to set the environment variable HTTPCLIENT__DANGEROUSACCEPTANYSERVERCERTIFICATE to true because according to the YARP configuration docs this should prevent YARP's client from verifiing the servers cert (at least the corresponding JSON appsetting should do this) but there is no change. Is there a way to solve this?

[Suiram1701]

Nvm. the environment variable worked! I just had to specify the exact cluster to use the HttpClient config for. The env. var. REVERSEPROXY__CLUSTERS__cluster_web-frontend__HTTPCLIENT__DANGEROUSACCEPTANYSERVERCERTIFICATE worked.

Anyways this is still quite uggly so is there a better way?

[davidfowl]

@Suiram1701 Are you using .NET 10?

cc @danegsta

[Suiram1701]

@davidfowl Not yet. I planned to do the Aspire and .NET migration separately in the affected project. I migrate to .NET 10 today so I let you know whether it works with 10.

[danegsta]

@Suiram1701 the ASP.NET development certificate was updated in .NET 10 to include hostnames required for containers to trust host services over HTTPS. Previously the certificate was only valid for localhost addresses, but in .NET 10 it also covers host.docker.internal/host.containers.internal (as well as *.dev.localhost and *.dev.internal) for addressing the host from a container.

[karolz-ms]

@danegsta is doing additional work to improve HTTPS support for many Aspire integrations, including Yarp. This should land in one of the upcoming Aspire releases, possibly as soon as 13.1.

Since the basic scenario works with the tunnel, I am going to close this.