Nuget package restore error in Docker Compose build

Question

I am getting nugget restore error while building using docker-compose behind proxy. I have set proxy in docker for windows. Nuget restore works for command line dotnet restore and visual studio debug, but not using docker-compose.

:\Program Files\dotnet\sdk\2.1.104\NuGet.targets(104,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [C:\src\WebApp.sln]
:\Program Files\dotnet\sdk\2.1.104\NuGet.targets(104,5): error :   An error occurred while sending the request. [C:\src\WebApp.sln]
:\Program Files\dotnet\sdk\2.1.104\NuGet.targets(104,5): error :   A connection with the server could not be established [C:\src\WebApp.sln]
ERROR: Service 'idenityapi' failed to build: The command 'powershell -Command $ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; dotnet restore -nowarn:msb3202,nu1503' r
turned a non-zero code: 1

Answer 1

SOLVED:
It turns out to be a networking issue. I am behind a corporate firewall at work that leverages TLS packet inspection to break apart SSL traffic. The build process while debugging runs as "me" on my local machine, however, the release build (docker-compose) actually pulls down a aspnetcore-build docker image, copies your code to the docker container, then runs dotnet restore to get fresh nuget packages for your docker image. These actions can be found in the Docker File in your project. This "dotnet restore" inside the container, runs under a different security context, and therefore was getting hung up. We traced the network traffic which was hard for me to get to because of how docker networking works. Fiddler was not catching the traffic. Using wireshark, we were able to catch it from a device level and see the drop. The reason it continued to fail from my home network was due to the configuration with our hypervisor & networking.

RESOLUTIONS:
Add a firewall rule for https://api.nuget.org/v3/index.json (Preferred) OR Build the image from VSTS in the cloud OR Build from a different network.

PS4 please post back if you are able to resolve this the same way? Having spent 3 days on this, I'm curious about your status.

Answer 2

When I ran into this issue with dotnet restore adding the corporate cert file fixed the issue. (May or may not be the same in your case?). Before RUN dotnet restore I added to the container's certificate store i.e.

ADD your-proxy-certificate-file.crt /usr/local/share/ca-certificates/your-proxy-certificate-file.crt
RUN update-ca-certificates

In theory, if dotnet restore works on your local machine, there's no reason you shouldn't be able to configure your container to work (without firewall rules or changing network!). You essentially need to configure the container to work behind your proxy with the same setup as your local machine.

Answer 3

You can check network adapter indexes. docker uses last in the list. if it's disconnected - you will not be able to restore packages as image is not able to get to the internet to download ones.

check network interface list:

❯ Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric -Descending

Change index for LAN (ex. move it above Wi-Fi):

❯ Set-NetIPInterface -InterfaceAlias 'Local Area Connection* 1' -InterfaceMetric 100