Cannot Deploy Cloudflare CCF Azure Storage Blob Connector: NSP Enforced Mode Blocks Scuba Poller IPv6 Traffic Due to IPv4-Only Inbound Rule Limitation

Question

PRODUCT / SERVICE

Microsoft Sentinel — Codeless Connector Framework (CCF)
Azure Storage Blob Connector (StorageAccountBlobContainer kind)
Azure Network Security Perimeter (NSP)

ISSUE

Connector deployment is completely blocked

PROBLEM SUMMARY

The Cloudflare CCF connector deployment is failing with a persistent "Internal error" during the ARM deployment connectivity check. This occurs regardless of the storage account public network access configuration (both "Secured by Perimeter" and "Enable from all networks" have been tested). The NSP diagnostic logs confirm that the Scuba poller is connecting to the storage account via an IPv6 address, which cannot be accommodated by NSP inbound IP address range rules as they only support IPv4 CIDR notation.

DEPLOYMENT ERROR MESSAGE

Deployment Failed
                At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.
{
  "status": "Failed",
  "error": {
    "code": "ResourceDeploymentFailure",
    "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.",
    "details": [
      {
        "code": "DeploymentFailed",
        "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
        "details": [
          {
            "code": "Conflict",
            "message": "{\r\n  \"status\": \"Failed\",\r\n  \"error\": {\r\n    \"code\": \"ResourceDeploymentFailure\",\r\n    \"message\": \"The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.\",\r\n    \"details\": [\r\n      {\r\n        \"code\": \"Internal error\",\r\n        \"message\": \"The operation failed due to an internal server error. The initial state of the impacted resources (if any) are restored. Please try again in few minutes. If error still persists, report Correlation ID:Timestamp to our forums for assistance or raise a support ticket .\"\r\n      }\r\n    ]\r\n  }\r\n}"
          }
        ]
      }
    ]
  }
}

ROOT CAUSE IDENTIFIED

NSP diagnostic logs (NSPAccessLogs table) captured the following denial entry during the connector deployment attempt:

Category: NspPublicInboundPerimeterRulesDenied
Location: eastus
Profile: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ServiceResourceId: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ResultDescription: AuthorizationFailure
MatchedRule: {"accessRule": "DefaultDenyAll"}
SourceParameters: {"ServiceEndpointIP": "2001:0db8:85a3:0001:0005:8a2e:1ef:9"}

DestinationParameters:{"ServiceEndpointIP": "2001:0db8:85a3:0001:0005:8a2e:1ef:9"}

ResultDirection: Inbound
ResultAction: Denied
TrafficType: Public
RuleType: NSP

The Scuba poller (CCF connector traffic) is connecting to the storage account via IPv6 address 2001:0db8:85a3:0001:0005:8a2e:1ef:9. The NSP inbound access rule "IP address ranges" Source type only accepts IPv4 CIDR notation. As a result, IPv6 traffic from the Scuba poller cannot be matched by any configured inbound rule and falls through to DefaultDenyAll — blocking the connector deployment connectivity check.

The official NSP documentation supports this, stating: "Find the Scuba service tag and copy the associated IPv4 ranges."

Reference: https://learn.microsoft.com/en-us/azure/sentinel/enable-storage-network-security#rule-2-allow-scuba-service-ip-ranges

TROUBLESHOOTING STEPS PERFORMED

Step 1: RBAC

The ScubaSentinelToStorageProd service principal was assigned the following roles on the storage account:

• Storage Blob Data Reader (blobs)

• Storage Queue Data Contributor (queues)

Reference: https://learn.microsoft.com/en-us/azure/sentinel/azure-storage-blob-connector-troubleshoot#solution-verify-permissions-and-networking

Step 2: NSP Creation and Association

A Network Security Perimeter was created in the same region as the storage account and associated with the storage account.
Reference: https://learn.microsoft.com/en-us/azure/sentinel/enable-storage-network-security

Step 3: NSP Inbound Access Rules Configured

The following inbound access rules were added to the NSP profile (storage-account-ccf-connector-profile):

• Allow-Subscription: Source type = Subscription, covers Event Grid delivery

• Allow-Scuba: Source type = IP address ranges, Scuba service tag IPv4 ranges added

(Note: IPv6 ranges from the Scuba service tag JSON could not be added as the field only accepts IPv4 CIDR notation)

Step 4: NSP Diagnostic Settings Enabled

Diagnostic settings were configured to send NSP logs to the Log Analytics workspace:

• NspPublicInboundPerimeterRulesAllowed

• NspPublicInboundPerimeterRulesDenied

• NspPublicOutboundPerimeterRulesDenied

• NspPublicOutboundPerimeterRulesAllowed

Step 5: NSP Access Mode set to Enforced

The NSP access mode was changed from Transition to Enforced after the inbound rules were configured, as per the official documentation.

Step 6: Storage Account set to "Secured by Perimeter" (Most Restricted)

The storage account public network access was set to "Secured by Perimeter" as documented under the optional step. The connector deployment was retried and failed with the Internal error. NSP diagnostic logs confirmed the Scuba poller IPv6 traffic was denied by DefaultDenyAll.

Reference: https://learn.microsoft.com/en-us/azure/sentinel/enable-storage-network-security#set-secured-by-perimeter-on-the-storage-account-optional

Step 7: Reverted to "Enable from all networks"

The storage account public network access was reverted from "Secured by Perimeter" to "Enable" with scope set to "Enable from all networks", while keeping NSP in Enforced mode and all inbound rules in place. The connector deployment was retried and still failed with the same Internal error.

KEY QUESTIONS

1. The Scuba poller is connecting to the storage account via IPv6 (2001:0db8:85a3:0001:0005:8a2e:1ef:9). The NSP inbound IP address range rule only supports IPv4 CIDR. How should the NSP be configured to allow Scuba poller IPv6 traffic?
2. Is there a supported NSP configuration for the StorageAccountBlobContainer CCF connector kind that allows the Scuba poller IPv6 traffic while keeping the storage account network-restricted?
3. The NSP concepts documentation states: "Inbound IP-based rules: (check respective onboarded private link resources for v6 support)." Does Azure Storage support IPv6 in NSP IP-based inbound rules? If not, what is the recommended alternative?

Answer 1

Hi ,

Thanks for reaching out to Microsoft Q&A.

Based on the evidence provided, the issue appears to be related to the interaction between Azure Network Security Perimeter (NSP) enforcement and the Scuba poller connectivity validation used by the Sentinel CCF Azure Storage Blob connector.

1. How should NSP be configured to allow Scuba poller IPv6 traffic?

From the documentation and the behavior shown in the NSP logs, NSP inbound IP address range rules are configured using IPv4 CIDR ranges for the Scuba service tag. The logs you provided show the connection attempt originating from an IPv6 address that was denied by the default perimeter rule.

As of the currently published guidance, I am not aware of documentation describing how to explicitly allow Scuba IPv6 addresses through NSP inbound IP-based rules for Azure Storage. Therefore, I cannot identify a documented NSP configuration that would allow the specific IPv6 source address shown in the logs.

2. Is there a supported NSP configuration that allows the StorageAccountBlobContainer connector while keeping the storage account network restricted?

The Microsoft guidance for securing the Azure Storage Blob connector with NSP relies on:

• Assigning the required Scuba service principal permissions.
• Creating inbound NSP rules for the Scuba service tag IP ranges.
• Associating the storage account with the perimeter.

However, your diagnostics indicate that the actual connectivity validation is reaching the storage account via IPv6 and is being denied by NSP. Given that behavior, the deployment failure appears consistent with NSP enforcement blocking the connectivity check.

I could not find documentation describing an alternative supported NSP rule type for this specific scenario that accommodates the Scuba IPv6 source while maintaining the same IP-based restriction model.

3. Does Azure Storage support IPv6 in NSP inbound IP based rules?

The NSP documentation mentions checking resource-specific support for IPv6, but I could not find documentation confirming IPv6 support for Azure Storage NSP inbound IP-based rules. Based on the information provided, and the observed denial of the IPv6 source address, it would be advisable to obtain confirmation from Microsoft Support regarding:

• Whether Azure Storage currently supports IPv6 matching for NSP inbound rules.
• Whether Sentinel Scuba traffic using IPv6 is a known limitation.
• Whether a service-side change or alternative configuration is available.

Recommendation:

At this point, the evidence suggests the connector deployment is being blocked by NSP enforcement rather than RBAC configuration. To move forward, I would recommend opening a Microsoft support case and providing:

• The ARM deployment correlation ID.
• The NSPAccessLogs entries showing NspPublicInboundPerimeterRulesDenied.
• The denied IPv6 address observed for the Scuba poller.
• Confirmation that the Scuba IPv4 ranges were already configured per the official guidance.

This will allow the product team to verify whether the behavior is a known limitation, a documentation gap, or a service defect.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.