Updating formatting, adding private endpoint traffic config.

Author: roygara

articles/storage/elastic-san/elastic-san-configure-private-endpoints.md

@@ -189,10 +189,13 @@ az network private-endpoint-connection approve \
 > Follow the steps in this [article](/azure/private-link/how-to-approve-private-link-cross-subscription) to approve and register private endpoints. 
 
 
+## Optional - network policies
+
+Virtual network rules don't apply to private endpoints. So, if you need to refine access rules and control traffic over a private endpoint, use network policies. By default, network policies are disabled for a subnet in a virtual network. To use network policies like user-defined routes and network security group support, enable network policy support for the subnet. This setting only applies to private endpoints in the subnet and affects all private endpoints in the subnet. For other resources in the subnet, access is controlled based on security rules in the network security group. For details, see [Network Policies](../../private-link/disable-private-endpoint-network-policy.md).
 
 ## 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.
+After you have enabled the desired endpoints, you're ready to configure your clients to connect to the appropriate Elastic SAN volumes.
 
 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.
 

articles/storage/elastic-san/elastic-san-configure-service-endpoints.md

@@ -12,7 +12,8 @@ ms.custom: references_regions, devx-track-azurecli, devx-track-azurepowershell
 # Configure service endpoints for Azure Elastic SAN
 
 A service endpoint enables secure connectivity to Elastic SAN from a subnet within your virtual network, without requiring a private IP. Virtual network service endpoints are public and accessible via the internet. You can [Configure virtual network rules](#configure-virtual-network-rules) to control access to your volume group when using storage service endpoints.
-To use a service endpoint, you must configure [Network Policies](../../private-link/disable-private-endpoint-network-policy.md) on your Elastic SAN volume group to allow traffic from specific subnets. These network rules apply only to the public endpoint of the volume group — they are not used for private endpoints. In other words, traffic from a subnet using a service endpoint must be explicitly permitted through a configured rule at the volume group level.Once network access is configured for a volume group, the configuration is inherited by all volumes belonging to the group. 
+
+To use a service endpoint, you must configure [Network Policies](../../private-link/disable-private-endpoint-network-policy.md) on your Elastic SAN volume group to allow traffic from specific subnets. These network rules apply only to the public endpoint of the volume group — they are not used for private endpoints. In other words, traffic from a subnet using a service endpoint must be explicitly permitted through a configured rule at the volume group level. Once network access is configured for a volume group, the configuration is inherited by all volumes belonging to the group. 
 
 This article configures service endpoint connections to your Elastic SAN.
 

articles/storage/elastic-san/elastic-san-networking-concepts.md

@@ -56,15 +56,15 @@ When you create a SAN, you can enable or disable public internet access to your
 
 To further secure access to your Elastic SAN volumes, you can create virtual network rules for volume groups configured with service endpoints to allow access from specific subnets. You don't need network rules to allow traffic from a private endpoint since the storage firewall only controls access through public endpoints.
 
-Each volume group supports up to 200 virtual network rules. If you delete a subnet that has been included in a network rule, it's 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. Clients granted access via these network rules must also be granted the appropriate permissions to the Elastic SAN to volume group. To learn how to define network rules, see [Managing virtual network rules](elastic-san-networking.md#configure-virtual-network-rules).
+Each volume group supports up to 200 virtual network rules. If you delete a subnet that has been included in a network rule, it's 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. Clients granted access via these network rules must also be granted the appropriate permissions to the Elastic SAN to volume group. To learn how to define network rules, see [Configure virtual network rules](elastic-san-configure-service-endpoints.md#configure-virtual-network-rules).
 
 Network rules only apply to the public endpoints of a volume group, not private endpoints. Approving the creation of a private endpoint grants implicit access to traffic from the subnet that hosts the private endpoint. To refine access rules and control traffic over private endpoints, use [Network Policies](../../private-link/disable-private-endpoint-network-policy.md).
 
 ## Data Integrity
 
 Data integrity is important for preventing data corruption in cloud storage. TCP provides a foundational level of data integrity through its checksum mechanism, it can be enhanced over iSCSI with more robust error detection with a cyclic redundancy check (CRC), specifically CRC-32C. CRC-32C can be used to add checksum verification for iSCSI headers and data payloads.
 
-Elastic SAN supports CRC-32C checksum verification when enabled on the client side for connections to Elastic SAN volumes. Elastic SAN also offers the ability to enforce this error detection through a property that can be set at the volume group level, which is inherited by any volume within that volume group. When you enable this property on a volume group, Elastic SAN rejects all client connections to any volumes in the volume group if CRC-32C isn't set for header or data digests on those connections. When you disable this property, Elastic SAN volume checksum verification depends on whether CRC-32C is set for header or data digests on the client, but your Elastic SAN won't reject any connections. To learn how to enable CRC protection, see [Configure networking](elastic-san-networking.md#enable-iscsi-error-detection).
+Elastic SAN supports CRC-32C checksum verification when enabled on the client side for connections to Elastic SAN volumes. Elastic SAN also offers the ability to enforce this error detection through a property that can be set at the volume group level, which is inherited by any volume within that volume group. When you enable this property on a volume group, Elastic SAN rejects all client connections to any volumes in the volume group if CRC-32C isn't set for header or data digests on those connections. When you disable this property, Elastic SAN volume checksum verification depends on whether CRC-32C is set for header or data digests on the client, but your Elastic SAN won't reject any connections. You can enable CRC protection when creating an Elastic SAN or enable it on an existing Elastic SAN.
 
 > [!NOTE]
 > Some operating systems may not support iSCSI header or data digests. Fedora and its downstream Linux distributions like Red Hat Enterprise Linux, CentOS, Rocky Linux, etc. don't support data digests. Don't enable CRC protection on your volume groups if your clients use operating systems like these that don't support iSCSI header or data digests because connections to the volumes will fail.
@@ -80,4 +80,5 @@ iSCSI sessions can periodically disconnect and reconnect over the course of the
 
 ## Next steps
 
-[Configure Elastic SAN networking](elastic-san-networking.md)
+- [Configure private endpoints for Azure Elastic SAN](elastic-san-configure-private-endpoints.md)
+- [Configure service endpoints for Azure Elastic SAN](elastic-san-configure-service-endpoints.md)

articles/storage/elastic-san/elastic-san-planning.md

@@ -50,7 +50,11 @@ Here's an example of how an autoscale policy works. Say you have an elastic SAN
 
 In the Elastic SAN, you can enable or disable public network access at the Elastic SAN level. You can also configure access to volume groups in the SAN over both public [Storage service endpoints](../../virtual-network/virtual-network-service-endpoints-overview.md) and [private endpoints](../../private-link/private-endpoint-overview.md) from selected virtual network subnets. Once network access is configured for a volume group, the configuration is inherited by all volumes belonging to the group. If you disable public access at the SAN level, access to the volume groups within that SAN is only available over private endpoints, regardless of individual configurations for the volume group.
 
-To allow network access or an individual volume group, you must [enable a service endpoint for Azure Storage](elastic-san-networking.md#configure-an-azure-storage-service-endpoint) or a [private endpoint](elastic-san-networking.md#configure-a-private-endpoint) in your virtual network, then [setup a network rule](elastic-san-networking.md#configure-virtual-network-rules) on the volume group for any service endpoints. You don't need a network rule to allow traffic from a private endpoint since the storage firewall only controls access through public endpoints. You can then mount volumes from [AKS](elastic-san-connect-aks.md), [Linux](elastic-san-connect-linux.md), or [Windows](elastic-san-connect-windows.md) clients in the subnet with the [internet Small Computer Systems Interface](https://en.wikipedia.org/wiki/ISCSI) (iSCSI) protocol.
+To configure networking access for an individual volume group, you must either [Configure private endpoints for Azure Elastic SAN](elastic-san-configure-private-endpoints.md) or [Configure service endpoints for Azure Elastic SAN](elastic-san-configure-service-endpoints.md). 
+
+fix this
+
+ then [setup a network rule](elastic-san-networking.md#configure-virtual-network-rules) on the volume group for any service endpoints. You don't need a network rule to allow traffic from a private endpoint since the storage firewall only controls access through public endpoints. You can then mount volumes from [AKS](elastic-san-connect-aks.md), [Linux](elastic-san-connect-linux.md), or [Windows](elastic-san-connect-windows.md) clients in the subnet with the [internet Small Computer Systems Interface](https://en.wikipedia.org/wiki/ISCSI) (iSCSI) protocol.
 
 ## Redundancy