Configure network access for Azure Elastic SAN

You can control access to your Azure Elastic storage area network (SAN) volumes. Controlling access allows you to secure your data and meet the needs of your applications and enterprise environments.

This article describes how to configure your Elastic SAN to allow access from your Azure virtual network infrastructure.

To configure network access to your Elastic SAN:

Prerequisites

  • If you're using Azure PowerShell, install the latest Azure PowerShell module.
  • If you're using Azure CLI, install the latest version.
  • Once you've installed the latest version, run az extension add -n elastic-san to install the extension for Elastic SAN. There are no extra registration steps required.

Limitations

The following list contains the regions Elastic SAN is currently available in, and which regions support both zone-redundant storage (ZRS) and locally redundant storage (LRS), or only LRS:

  • Australia East - LRS
  • Brazil South - LRS
  • Canada Central - LRS
  • Central US - LRS
  • East Asia - LRS
  • East US - LRS
  • East US 2 - LRS
  • France Central - LRS & ZRS
  • Germany West Central - LRS
  • India Central - LRS
  • Japan East - LRS
  • Korea Central - LRS
  • North Europe - LRS & ZRS
  • Norway East - LRS
  • South Africa North - LRS
  • South Central US - LRS
  • Southeast Asia - LRS
  • Sweden Central - LRS
  • Switzerland North - LRS
  • UAE North - LRS
  • UK South - LRS
  • West Europe - LRS & ZRS
  • West US 2 - LRS & ZRS
  • West US 3 - LRS

Elastic SAN is also available in the following regions, but without Availability Zone support:

  • Canada East - LRS
  • Japan West - LRS
  • North Central US - LRS

To enable these regions, run the following command to register the necessary feature flag:

Register-AzProviderFeature -FeatureName "EnableElasticSANRegionalDeployment" -ProviderNamespace "Microsoft.ElasticSan"

Configure public network access

You enable public Internet access to your Elastic SAN endpoints at the SAN level. Enabling public network access for an Elastic SAN allows you to configure public access to individual volume groups over storage service endpoints. By default, public access to individual volume groups is denied even if you allow it at the SAN level. You must explicitly configure your volume groups to permit access from specific IP address ranges and virtual network subnets.

You can enable public network access when you create an elastic SAN, or enable it for an existing SAN using the Azure PowerShell module or the Azure CLI.

Use the Azure PowerShell module or the Azure CLI to enable public network access.

Configure iSCSI error detection

Enable iSCSI error detection

To enable CRC-32C checksum verification for iSCSI headers or data payloads, set CRC-32C on header or data digests for all connections on your clients that connect to Elastic SAN volumes. To do this, connect your clients to Elastic SAN volumes using multi-session scripts generated either in the Azure portal or provided in either the Windows or Linux Elastic SAN connection articles.

If you need to, you can do this without the multi-session connection scripts. On Windows, you can do this by setting header or data digests to 1 during login to the Elastic SAN volumes (LoginTarget and PersistentLoginTarget). On Linux, you can do this by updating the global iSCSI configuration file (iscsid.conf, generally found in /etc/iscsi directory). When a volume is connected, a node is created along with a configuration file specific to that node (for example, on Ubuntu it can be found in /etc/iscsi/nodes/$volume_iqn/portal_hostname,$port directory) inheriting the settings from global configuration file. If you have already connected volumes to your client before updating your global configuration file, update the node specific configuration file for each volume directly, or using the following command:

sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n $iscsi_setting_name -v $setting_value

Where

  • $volume_iqn: Elastic SAN volume IQN
  • $portal_hostname: Elastic SAN volume portal hostname
  • $port: 3260
  • $iscsi_setting_name: node.conn[0].iscsi.HeaderDigest (or) node.conn[0].iscsi.DataDigest
  • $setting_value: CRC32C

Enforce iSCSI error detection

To enforce iSCSI error detection, set CRC-32C for both header and data digests on your clients and enable the CRC protection property on the volume group that contains volumes already connected to or have yet to be connected to from your clients. If your Elastic SAN volumes are already connected and don't have CRC-32C for both digests, you should disconnect the volumes and reconnect them using multi-session scripts generated in the Azure portal when connecting to an Elastic SAN volume, or from the Windows or Linux Elastic SAN connection articles.

Note

CRC protection feature isn't currently available in North Europe and South Central US.

To enable CRC protection on the volume group:

Enable CRC protection on a new volume group:

Screenshot of CRC protection enablement on new volume group.

Enable CRC protection on an existing volume group:

Screenshot of CRC protection enablement on an existing volume group.

Configure a virtual network endpoint

You can configure your Elastic SAN volume groups to allow access only from endpoints on specific virtual network subnets. The allowed subnets can belong to virtual networks in the same subscription, or those in a different subscription, including a subscription belonging to a different Microsoft Entra tenant.

You can allow access to your Elastic SAN volume group from two types of Azure virtual network endpoints:

A private endpoint uses one or more private IP addresses from your virtual network subnet to access an Elastic SAN volume group over the Microsoft backbone network. With a private endpoint, traffic between your virtual network and the volume group are secured over a private link.

Virtual network service endpoints are public and accessible via the internet. You can Configure virtual network rules to control access to your volume group when using storage service endpoints.

Network rules only apply to the public endpoints of a volume group, not private endpoints. The process of approving the creation of a private endpoint grants implicit access to traffic from the subnet that hosts the private endpoint. You can use Network Policies to control traffic over private endpoints if you want to refine access rules. If you want to use private endpoints exclusively, don't enable service endpoints for the volume group.

To decide which type of endpoint works best for you, see Compare Private Endpoints and Service Endpoints.

Once network access is configured for a volume group, the configuration is inherited by all volumes belonging to the group.

The process for enabling each type of endpoint follows:

Configure a private endpoint

Important

There are two steps involved in configuring a private endpoint connection:

  • Creating the endpoint and the associated connection.
  • Approving the connection.

You can also use Network Policies to refine access control over private endpoints.

To create a private endpoint for an Elastic SAN volume group, you must have the Elastic SAN Volume Group Owner role. To approve a new private endpoint connection, you must have permission to the Azure resource provider operation Microsoft.ElasticSan/elasticSans/PrivateEndpointConnectionsApproval/action. Permission for this operation is included in the Elastic SAN Network Admin role, but it can also be granted via a custom Azure role.

If you create the endpoint from a user account that has all of the necessary roles and permissions required for creation and approval, the process can be completed in one step. If not, it requires two separate steps by two different users.

The Elastic SAN and the virtual network could be in different resource groups, regions, and subscriptions, including subscriptions that belong to different Microsoft Entra tenants. In these examples, we're creating the private endpoint in the same resource group as the virtual network.

You can create a private endpoint connection to your volume group in the Azure portal either when you create a volume group or when modifying an existing volume group. You need an existing virtual network to create a private endpoint.

When creating or modifying a volume group, select Networking, then select + Create a private endpoint under Private endpoint connections.

Fill out the values in the menu that pops up, select the virtual network and the subnet that your applications will use to connect. When you're done, select Add, and Save.

Screenshot of the volume group private endpoint creation experience.

Configure an Azure Storage service endpoint

To configure an Azure Storage service endpoint from the virtual network where access is required, you must have permission to the Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action Azure resource provider operation via a custom Azure role to configure a service endpoint.

Virtual network service endpoints are public and accessible via the internet. You can Configure virtual network rules to control access to your volume group when using storage service endpoints.

Note

Configuration of rules that grant access to subnets in virtual networks that are a part of a different Microsoft Entra tenant are currently only supported through PowerShell, CLI and REST APIs. These rules cannot be configured through the Azure portal, though they can be viewed in the portal.

  1. Navigate to your virtual network and select Service Endpoints.

  2. Select + Add.

  3. On the Add service endpoints screen:

    1. For Service select Microsoft.Storage.Global to add a cross-region service endpoint.

    Note

    You might see Microsoft.Storage listed as an available storage service endpoint. That option is for intra-region endpoints which exist for backward compatibility only. Always use cross-region endpoints unless you have a specific reason for using intra-region ones.

  4. For Subnets select all the subnets where you want to allow access.

  5. Select Add.

Screenshot of the virtual network service endpoint page, adding the storage service endpoint.

Configure virtual network rules

All incoming requests for data over a service endpoint are blocked by default. Only applications that request data from allowed sources that you configure in your network rules are able to access your data.

You can manage virtual network rules for volume groups through the Azure portal, PowerShell, or CLI.

Important

If you want to enable access to your storage account from a virtual network/subnet in another Microsoft Entra tenant, you must use PowerShell or the Azure CLI. The Azure portal does not show subnets in other Microsoft Entra tenants.

If you delete a subnet that has been included in a network rule, it will be removed from the network rules for the volume group. If you create a new subnet with the same name, it won't have access to the volume group. To allow access, you must explicitly authorize the new subnet in the network rules for the volume group.

  1. Navigate to your SAN and select Volume groups.
  2. Select a volume group and select Create.
  3. Add an existing virtual network and subnet and select Save.

Configure client connections

After you have enabled the desired endpoints and granted access in your network rules, you're ready to configure your clients to connect to the appropriate Elastic SAN volumes.

Note

If a connection between a virtual machine (VM) and an Elastic SAN volume is lost, the connection will retry for 90 seconds until terminating. Losing a connection to an Elastic SAN volume won't cause the VM to restart.

Next steps