Share via

Access to pandey is denied Network type is OnPremise IP: fe80::603a:ba7:ae5e:9ba0%13

pandey munna 0 Reputation points
2026-05-10T14:36:58.2+00:00

User's image

Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.


2 answers

Sort by: Most helpful
  1. Amira Bedhiafi 41,641 Reputation points MVP Volunteer Moderator
    2026-05-10T14:57:55.1433333+00:00

    Hello Pandey !

    Thank you for posting on MS Learn Q&A.

    ADF is trying to reach pandey but it resolves to an on-prem addressfe80::603a:ba7:ae5e:9ba0%13 and that is not reachable from the default AIR.

    For an on prem machine, local PC, VM or file share, you must use a SHIR.

    After you install it on pandey or on another machine in the same network, in the linked service you must set connect via integration runtime to that SHIR. The file system linked service uses connectVia to decide which IR connects to the source.

    If the folder is on the same machine where SHIR is installed, run PowerShell as admin on the SHIR machine:

    cd "C:\Program Files\Microsoft Integration Runtime\5.0\Shared"
    .\dmgcmd.exe -EnableLocalMachineAccess
    .\dmgcmd.exe -DisableLocalFolderPathValidation
    .\dmgcmd.exe -Restart
    

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  2. Q&A Assist
    2026-05-10T14:37:12.88+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The error indicates that the on-premises runtime (network type OnPremise, IP shown as a link-local IPv6 address) cannot reach the target resource “pandey” over the network, or that the target is rejecting access.

    Based on similar “access denied” and network-plane issues in the context, the following checks and fixes apply:

    1. Verify basic network connectivity from the self-hosted integration runtime (SHIR) machine to the target:
      • From the SHIR server, ping or nslookup the hostname pandey.
      • If DNS does not resolve, add or correct the DNS entry (on-prem DNS or hosts file) so that pandey resolves to the correct IPv4/IPv6 address.
      • Ensure the SHIR is not using only a link-local IPv6 (like fe80::...) path that cannot route to the target.
    2. Check firewalls, ACLs, and routing between SHIR and pandey:
      • Confirm that required ports for the target system are open (for example, 1433 for SQL Server, 445 for SMB, etc., depending on what “pandey” is).
      • Ensure no network ACLs or perimeter firewalls are blocking the SHIR subnet from reaching pandey.
      • If Private Link or managed private endpoints are used, validate routing and DNS so traffic goes over the correct private path, not the public internet.
    3. Validate access control on the target resource:
      • Confirm that the account used by the Data Factory linked service has permission to access pandey (for example, SQL login, Windows/AD account, or service account).
      • Check for policies like “Deny access from network” or “Deny access to this computer from the network” that might block the account, similar to the “user account is not allowed the Network Login type” scenario.
    4. If using Private Link / private endpoints to reach Azure resources from on-prem:
      • Verify that the private endpoint connection is approved and in a Succeeded state.
      • Confirm DNS for the Azure resource resolves to the private endpoint IP, not a public IP.
      • Use tools like nslookup or Test-NetConnection from the SHIR machine to confirm the path.
    5. If the error is coming from an Azure PaaS resource (for example, Key Vault, Storage, App Configuration):
      • Check that public network access and firewall rules allow the SHIR’s public IP or that a private endpoint is configured and reachable.
      • For “IP address rejected” / 403 scenarios, ensure the request originates from within the allowed virtual network or via the configured private endpoint and that DNS points to the private IP.
    6. Re-test from the SHIR host:
      • After fixing DNS, firewall, and permissions, re-run the Data Factory pipeline or linked service test connection.
      • If it still fails, capture the exact error message and HTTP status (for PaaS targets) or OS-level error (for on-prem targets) to narrow whether it is network, authentication, or authorization.

    These steps align with how similar “access denied” and network-plane errors are resolved for other Azure services when using private endpoints or restricted network access.


    References:

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.