The underlying connection was closed: An unexpected error occurred on a send.--- NuGet

Question

Whilst trying to restore nuget packages I am getting the following:-

Error 1 The underlying connection was closed: An unexpected error occurred on a send.

Error 2 The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Error 3 The command ""D:\root\.nuget\NuGet.exe" install "D:\root\packages.config" -source "" -NonInteractive -RequireConsent -solutionDir "D:\root\"" exited with code 1.

Error 4 Metadata file 'D:\root\project.Website.dll' could not be found D:\root\project.UnitTests\CSC

I tried the solutions provided on: Visual Studio 2010 nuget error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel

I tried the solutions provided on: https://nuget.codeplex.com/discussions/275537

None of them work, I was wondering if anyone else is currently having this issue? If so has anyone come up with a solution?

It seemingly, may be a waiting game, for the SSL certificates to be fixed.

After some further debugging with Fiddler I got the following response:

fiddler.network.https> HTTPS handshake to az320820.vo.msecnd.net failed. System.IO.IOException Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. < An existing connection was forcibly closed by the remote host

If I am correct, it seems like I am being rejected but the server, not sure why and I am hopeful this will soon resolve it self.

For now I have managed to get copies of packages from other developers who hadn't cleared their package cache and continue developing this way.

Someone has kindly raised the issue on code plex so hopefully we get somewhere soon: https://nuget.codeplex.com/workitem/4372

Update

As of 17th November, this seems to be working again. NuGet correctly telling me it's having issues getting an older version of Ninject.Web.Common.3.2.0.0 but we have the updated edition which is fine.

Stoddard

I'm running into the same issue just starting today. I have tried all the other fixes and nothing works. Have you solved this yet? – Decant

Sorry no, seems like one of the nuget nodes are down. We managed to get a copy of our packages off another developers machine and are going off those. You can use fiddler to identify which packages are missing and manually download those packages and put them into your packages folder. – Stoddard

I tried disabling nuget restore upon build, but now I get an error saying that nuget package restore is disabled and the build will not continue. Anyone know how to get around that while we wait for nuget to resolve it's issue? – Karolynkaron

@Karolynkaron is it just you or is anyone else using it? Do you have continuous deployment environments that may have done a pull recently and have a copy of the packages folder where nuget stores all the dependencies? Do you check packages into version control? Potentially could get it from there. Additionally I previously mentioned get from other developers who haven't cleared there packages cache. – Stoddard

Seems like a server outage on NuGet side of things, not really an answerable question on our part. – Stoddard

I've hit a similar wall, utter nightmare! – Silken

Links to nuget.codeplex.com are dead. – Dahl

Answer 1

I was having the same problem until I invoked my network admins. We found that our IPS flagged the domain as malware and we blocked it at our internal network level.

Once we removed the block, everything is now working again.

We also had problems getting images and css from codeplex project sites and this fixed that issue as well.

Dachau

Yeah this is what I thought at first, but the fiddle logs clearly stated the remote host rejected me. If it was internal blocking I would of gotten a host not found or unable to reach destination related issues. – Stoddard

Depends on what type of blocking is in place. My network admins basically put the domain into an internal DNS black hole. I figured out what the problem was on my end because the IP Address was in one of the private IP ranges (172.16.x.x). – Dachau

True point. I've confirmed with our network admins lucky for me it's not an issue. Up'd because it is a potential issue for people. – Stoddard

Is there any way we can get the nuget logs. Just connection closed messages doesn't tell what is happening. – Avra

Answer 2

I'm seeing this issue behind a corporate proxy using Visual Studio 2015 which utilizes the new v3 API (https://api.nuget.org/v3/index.json). In my instance, it has to do with an SSL intercepting corporate proxy (BlueCoat) that doesn't know how to handle a newer cipher protocol (eg: TLS 1.2 plus some newer key exchange cipher) being negotiated by that API endpoint I believe.

Linell

@ryanwebjackson I wasn't able to get the corporate proxy changed and had to use a workaround if I recall correctly – Linell

Answer 3

A quick fix for Visual Studio 2015 users is to change the URL from https to http. I have a feeling that this may not work if the package has a https license file.

Alternatively, switch to Visual Studio 2013 for package installation and updates.

Tollmann

Yes. Switched from https:// to http:// url and the packages flowed down. (Note: this was when communicating with an internal "ProGet" nuget server.) – Nine

I agree, thanks for sharing this. It works like a charm now :) – Kielce

Answer 4

Check if your internet connection is working and your proxy is setup and enabled in Internet Explorer LAN settings. In my case it was trying to download it from internet and failing, as my proxy was disabled! Hope this helps...

Moskow