runtime: NetworkInformationException: Permission denied (.NET 8 + Docker +GCloud)

Is there an existing issue for this?

I have searched the existing issues

Describe the bug

Identical code (below) that works fine in .NET 7, fails with the following error in .NET 8:

Unhandled exception. System.Net.NetworkInformation.NetworkInformationException (13): Permission denied
2023-11-16 02:04:53.524 JST
   at System.Net.NetworkInformation.NetworkChange.CreateSocket()
2023-11-16 02:04:53.524 JST
   at System.Net.NetworkInformation.NetworkChange.add_NetworkAddressChanged(NetworkAddressChangedEventHandler value)
2023-11-16 02:04:53.524 JST
   at System.Net.Http.HttpConnectionPoolManager.StartMonitoringNetworkChanges()
2023-11-16 02:04:53.524 JST
   at System.Net.Http.HttpConnectionPool.HandleAltSvc(IEnumerable`1 altSvcHeaderValues, Nullable`1 responseAge)
2023-11-16 02:04:53.524 JST
   at System.Net.Http.HttpConnectionPool.ProcessAltSvc(HttpResponseMessage response)
2023-11-16 02:04:53.524 JST
   at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
2023-11-16 02:04:53.524 JST
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
2023-11-16 02:04:53.524 JST
   at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)

Trimmed and adjusted code (same result for ANY https call):

var httpClient = new HttpClient();
_ = await httpClient.GetAsync("https://www.google.com");

The peculiarity of this issue lies in the fact that the code executes fine on a local environment. But the moment the container is spun up in a google cloud run instance, it fails.

Another weird thing is that raw TCP connections work fine, we have a database connection that goes directly over TCP, rather than traditional HTTP(s).

I have spent hours debugging this issue, and sadly we have no other choice but to revert back to .NET 7 for the time being.

Expected Behavior

A Proper HTTPs connection

Steps To Reproduce

No response

Exceptions (if any)

NetworkInformationException

.NET Version

.NET 8

Anything else?

No response

About this issue

Original URL
State: closed
Created 8 months ago
Reactions: 5
Comments: 20 (14 by maintainers)

Most upvoted comments

As a workaround, setting DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT env var to false should work.

+16

rzikm on Nov 16, 2023

Or programmatically with AppContext switch: “System.Net.SocketsHttpHandler.Http3Support”.

ManickaP on Nov 16, 2023

thanks for the super fast answer @rzikm 👍

I’ve used env DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT = “false” and it works

What does it mean for networking/security (with February release) :

a non-root container will be able to use HTTP/3
a non-root container will only be able to use HTTP/2 because it needs to be root for HTTP/3

glb-cblin on Nov 29, 2023

If I undesrstand correctly, this bug is going to be fixed in February release. Is that correct ?

Yes, that is the current plan. Meanwhile, you need to use one of the workarounds mentioned above.

rzikm on Nov 29, 2023

This is a general problem for Alt-Svc handling, the spec says you need to clear them on network change RFC 7838:

By default, cached alternative services will be cleared when the client detects a network change. Alternative services that are intended to be longer lived (such as those that are not specific to the client access network) can carry the “persist” parameter with a value “1” as a hint that the service is potentially useful beyond a network configuration change.

We just happen to use Alt-Svc only for H/3. So disabling it is a workaround.

I agree with Tomas, we should fix this, at least catch the exception and continue business as usual. If we’re not able to detect network changes due to access rights limitations we won’t.

ManickaP on Nov 16, 2023