Unable to connect to the New Relic service: troubleshooting network issues with the .NET agent

If you’ve noticed your agent has stopped reporting to New Relic or has never reported in, and you’ve taken a look at the agent logs and found a message similar to…

ERROR: Unable to connect to the New Relic service at collector.newrelic.com:443 : 
System.Net.WebException: Unable to connect to the remote server ---> 
System.Net.Sockets.SocketException: No connection could be made because the target machine 
actively refused it

or

ERROR: Unable to connect to the New Relic service at collector.newrelic.com:443 : 
System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: 
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

…then you’re likely running into a network connectivity issue, which could be related to your server’s (or user’s) firewall settings.

If the issue just started you may want to check our New Relic status page to make sure there’s not an ongoing incident.

Then the first thing to check is that the required IP ranges and ports are open, and those can be found here:

It’s worth noting that, depending on how your firewall is set up, the actual user identity your process runs as may need to be unblocked from those IPs and ports. For example, if your app runs in an IIS application pool, the user under which that app pool runs (ApplicationPoolIdentity by default) must be able to reach the specified IPs, as the agent resides within that process and has the same permissions.

One way to test whether your app can reach New Relic servers is to log in to Windows as your app’s user and run this command in Powershell:

Invoke-WebRequest https://collector.newrelic.com/status/mongrel

A response of mongrel ==> up indicates a successful connection.

PROTIP:
As an admin, try using the runas command in Windows to “impersonate” another user.

Proxy settings

If your company uses a proxy for outgoing connections, that proxy will also need the above mentioned IPs and ports open, and an additional setting must be added to your newrelic.config so the agent knows to communicate via that proxy.

Note that the proxy element is an optional child of the service element so it should look like this in your newrelic.config:

<service licenseKey="YOUR_LICENSE_KEY">
 <proxy
   host="hostname" <!-- Required -->  
   port="PROXY_PORT" <!-- Required -->  
   uriPath="path/to/something.aspx" <!-- Optional -->  
   domain="mydomain.com" <!-- Optional -->  
   user="PROXY_USERNAME" <!-- Optional -->  
   password="PROXY_PASSWORD" <!-- Optional -->  
   passwordObfuscated="OBFUSCATED_PROXY_PASSWORD"/> <!-- Optional -->  
</service>

You can test this with Powershell as well:

Invoke-WebRequest -Proxy http://__proxy_host:__proxy_port__ https://collector.newrelic.com/status/mongrel

TLS Troubles

If, however, you’re seeing error messages like the following…

The request was aborted: Could not create SSL/TLS secure channel.
The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: 
Received an unexpected EOF or 0 bytes from the transport stream.
The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: 
The client and server cannot communicate, because they do not possess a common algorithm.

…then you’re running into issues with TLS settings and will need to make the changes outlined here:

If some of your applications on a server are getting the error and some are not, this document from Microsoft goes over all the ways that might explain that:

A few things that could cause this:

  • An application is running as 32 bit and the TLS 1.1/1.2 and/or SchUseStrongCrypto registry settings are only applied to 64-bit, or vice versa. The regedit script in our docs will apply the correct settings to both 32 and 64 bit apps.

  • The .NET targeted framework version can be a factor, or whether or not it’s a WCF app, as detailed in that Microsoft doc.

  • The Windows Server version and even the security updates applied on the server can factor into this.

  • The application can be hard-coded to use a specific version of TLS.

  • Other reasons ¯\(ツ)

Next Steps in Troubleshooting

I hope this helps, and if you are still running into trouble, feel free to reply here or create a ticket; however, aside from some basic troubleshooting as described above, New Relic support may not be able to delve too much into network troubleshooting as many networking related issues are environment issues rather than agent or New Relic server issues, and tend to veer outside the scope of support.

2 Likes