paket restore does not properly populate the NuGet cache

Description

My company has build servers that do not have direct outbound internet access. After deploying new build servers with an updated version of the .NET Core SDK, package restore fails.

We have an internal mirror of the gallery using ProGet that we have instructed Paket to use as it's source.

Paket appears to download the NuGet packages into the user's NuGet cache, but NuGet ignores them and forces a fresh download.

Repro steps (1)

This is the scenario as replicated from my actual issue.

1. Set up two PCs (VMs are OK) with a clean installation of Windows 10 v1803
2. On PC 1, install the .NET Core SDK v2.1.201
3. On PC 1, create a netcoreapp2.0 project with paket.dependencies and paket.lock
4. Copy the project from PC 1 to PC 2
5. On PC 2, install the .NET Core SDK v2.1.400
6. On PC 2, run paket restore
7. On PC 2, note that %USERPROFILE%\.nuget\packages is populated with packages that paket has downloaded
8. Disconnect PC 2 from the internet
9. On PC 2, run dotnet restore.

Repro steps (2)

This is a simpler repro that I came across when building the first repro above:

1. Set up a PC with .NET Core SDK v2.1.201
2. Create a netcoreapp2.0 project with paket.dependencies and paket.lock
3. Run paket restore
4. Run dotnet restore. Observe that it completes successfully.
5. Clear the cache with dotnet nuget locals all --clear
6. Run paket restore
7. Disconnect the PC from the internet
8. Run dotnet restore

Expected behavior

dotnet restore uses packages from the local cache that paket has prepopulated.

Actual behavior

dotnet fails to build with a NuGet error:

Unable to load the service index for source https://api.nuget.org/v3/index.json

If PC 2 is reconnected to the internet, then it redownloads many if not all dependent packages in their entirety. This can be observed by using Fiddler with SSL/TLS interception enabled.

Known workarounds

Adding a NuGet.config can force NuGet to connect to the proget server and NuGet to download packages.

Start with the two offline reproduction scenarios: run paket restore, clear the NuGet cache where specified, disconnect the machine, and run dotnet restore. Trace how Paket populates the user's NuGet cache and compare that with what dotnet restore expects. Done means dotnet restore succeeds offline using packages fetched by Paket; no source files or tests are named in the issue.