.NET 8.0.17 Upgrades, Forwarded Headers, and Unknown Proxy Issues

Khalid Abuhakmeh, Wesley Cabus |

We've recently seen a trend of issues in our priority support related to a .NET 8.0.17 release that we thought we'd address publicly to give developers information about the cause and how to resolve it quickly.

With any luck, we'll help many folks avoid this issue entirely before it becomes a problem in their production environments. Let's get started.

The Symptoms

As many Duende customers may already know, developers build IdentityServer using C# APIs with the identity provider hosted on top of ASP.NET Core, utilizing many of the elements you'd use when building any ASP.NET Core application. This is generally a great advantage to developers since knowledge learned when implementing IdentityServer is transferable to other applications.

That said, the same dependency on core .NET libraries can inadvertently break production code, with symptoms revealing themselves through IdentityServer. This post documents a new issue with the release of .NET 8.0.17.

Users report that the discovery document served by their Duende IdentityServer instance no longer generates the appropriate base URL (with https) but instead returns the host domain or a non-secure HTTP URL version. In almost all cases, no meaningful changes were made to the codebase or production environment, except for one change. This issue has been reported by many users who recently deployed the June 2025 .NET Update (KB5061935).

What's going on?

The Cause

With the release of .NET 8.0.17, a fix was made to ensure the Forwarded Headers Middleware would only accept headers from explicitly set KnownNetworks and KnownProxies values. You can see the pull request here.

If the ForwardedHeadersMiddleware middleware is used without using XForwardedFor then the KnownNetworks and KnownProxies checks are skipped.

This is a case where the previous behavior was patched and now breaks misconfigured deployments of ASP.NET Core applications. If you are in a cloud environment, where environments are managed for you, your environment may be subject to rolling upgrades. You may not see this issue yet, but it's best to mitigate it before it becomes one for your organization.

The Fix

The first step we recommend is, if possible, to temporarily pause production environment upgrades of .NET 8 to the latest patch release, 8.0.17, until you've had time to review your Duende IdentityServer deployments. For Windows Azure users, you may be able to set the .NET version while you investigate the configuration fixes by using Azure commands.

Once you've protected your production environment from an unplanned upgrade, thoroughly review the KnownNetworks and KnownProxies properties in your Duende IdentityServer host applications to ensure all settings are correctly configured. Consult our documentation for more information on proxy servers and load balancers.

Your configuration should include similar lines of code:

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    // you may need to change these ForwardedHeaders
    // values based on your network architecture
    options.ForwardedHeaders = ForwardedHeaders.XForwardedHost |
                                ForwardedHeaders.XForwardedProto;

    // exact Addresses of known proxies to accept forwarded headers from.
    options.KnownProxies.Add(IPAddress.Parse("203.0.113.42"); // <-- change this value to the IP Address of the proxy

    // if the proxies could use any address from a block, that can be configured too:
    // var network = new IPNetwork(IPAddress.Parse("198.51.100.0"), 24);
    // options.KnownNetworks.Add(network);

    // default is 1
    options.ForwardLimit = 1;
});

If you're missing either KnownProxies or KnownNetworks, you'll likely have issues after upgrading to .NET 8.0.17.

Conclusion

While patch version upgrades should be uneventful, this one may be. Many developers hosting ASP.NET Core applications in production may run into it! Even though our documentation explicitly spells out the need to set KnownProxies and KnownNetworks, we understand that it can be easy to miss this setting.

Hopefully, this post can help you avoid this issue before it becomes an urgent production-breaking issue.

As always, thank you for being a valued Duende customer. We look forward to hearing from you in the comments section below.