A bit of a deeper dive on this for you folks in the field. Our source agent logs will many times point directly at the culprit if it is an issue of ports/permissions/DNS. These are the most common reasons we see this behavior.
Look for: "Creating NFC download stream"
You'll first see the host and port the agent is attempting to communicate with:
Successfully logged in ( server: [Test-vc01], user: [test\bmilligan] )
This is the control connection above to the vCenter. Next you'll see the NFC connection to the host being made as determined by vCenter:
Native NFC file path: [[SAN-Test-LUN1] TestVM/TestVM.vmx].
Reconnecting to the NFC storage. Storage: [stg:datastore-25648,nfchost:host-458,conn:test-vc01]. Display name: [SAN-Test-LUN1].
Preferred NFC server: [host-458].
Connecting to NFC session. Target host: [ESX1.test.local]. Storage: [SAN-Test-LUN1]. VI SOAP connection ID: [test-vc01].
NFC service: [vpxa-nfc]. Port: .
If you see "failed" next to this line: Establishing connection with the host [ESX1.test.local]. Port: ., it's fairly clear you need to modify your firewall.
Next, you'll see the hostname DNS resolution attempt:
Resolving host name (ESX1.test.local) to IP address...
If you see failed next to the above line, you need to update your DNS records so that host is resolvable from the source proxy.
Lastly, you'll see the file begin to download:
Starting file download. File: [[SAN-Test-LUN1] TestVM/TestVM.vmx].
When it fails here, we're talking permissions to download the file at this point. As you can see, all three problems are fairly clear in logs context.
Hope this helps!