ping class doesn't work in published net core web app

Question

I have a very simple ping endpoint in net core web API controller. It works locally.

[HttpGet("ping")]
    public IActionResult Ping()
    {

        string host = "www.google.com";
        Ping servicePing = new Ping();
        var reply = servicePing.Send(host);

        return Ok($"{reply.Status}");
    }

But on published Azure application, when I go to that endpoint it returns 500 status code for internal server error.

I've tried adding some nugget packages, using async, but it's always the same - works locally, but not when published.

I also tried checking in Azure portal, maybe their servers are blocking pinging?

edit:

from Azure portal app service diagnostics report:

at System.Net.NetworkInformation.Ping.InitialiseIcmpHandle
at System.Net.NetworkInformation.Ping.DoSendPingCore
at System.Net.NetworkInformation.Ping.GetAddressAndSend
at System.Net.NetworkInformation.Ping.GetAddressAndSend
at System.Net.NetworkInformation.Ping.Send
at TestApi.Controllers.WeatherForecastController.Ping
at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync

edit 2:

I checked Debug console in Kudos for eventlog.xml file to find exception. (Please tell me if there's a better way to check for server exceptions.)

Here's the actual exception:

System.Net.NetworkInformation.PingException: An exception occurred during a Ping request.
 ---> System.ComponentModel.Win32Exception (5): Access is denied.
   at System.Net.NetworkInformation.Ping.InitialiseIcmpHandle()
   at System.Net.NetworkInformation.Ping.DoSendPingCore(IPAddress address, Byte[] buffer, Int32 timeout, PingOptions options, Boolean isAsync)
   at System.Net.NetworkInformation.Ping.GetAddressAndSend(String hostNameOrAddress, Int32 timeout, Byte[] buffer, PingOptions options)
   --- End of inner exception stack trace ---
   at System.Net.NetworkInformation.Ping.GetAddressAndSend(String hostNameOrAddress, Int32 timeout, Byte[] buffer, PingOptions options)
   at System.Net.NetworkInformation.Ping.Send(String hostNameOrAddress, Int32 timeout, Byte[] buffer, PingOptions options)
   at System.Net.NetworkInformation.Ping.Send(String hostNameOrAddress)
   at TestApi.Controllers.WeatherForecastController.Ping() in C:\Users\Dellas\source\repos\TestApi\TestApi\Controllers\WeatherForecastController.cs:line 48

What's a workaround here? Does Azure really blocks pinging?

Answer 1

Yes, on Azure App Service the tools ping, nslookup and tracert won’t work through the console due to security constraints. However, there are two separate tools: In order to test DNS functionality,you could leverage nameresolver.exe and Tcpping -which allows you to test for TCP connectivity to a host and port combination.

To highlight more details on this, the standard Azure Web Apps run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available. In this environment, the only way an application can be accessed via the internet is through the already-exposed HTTP (80) and HTTPS (443) TCP ports; applications may not listen on other ports for packets arriving from the internet.

Connection attempts to local addresses (e.g. localhost, 127.0.0.1) and the machine's own IP will fail, except if another process in the same sandbox has created a listening socket on the destination port.

Take a look at this article for more details on this topic. From Kudu console, you can perform tcpping www.google.com:80