Azure File Sync for a Hybrid Environment

I’ve configured Azure File Sync in my home lab quite a few times, and the setup is pretty straightforward. By default Azure File Sync will send data over the internet, which although it is encrypted (if you have set it up) is not ideal. Below is a step by step guide in setting up Azure File Sync with private endpoints and to ensure the data flows over a VPN.

In the following scenario we already have the following setup:

  • VPN from on-premise into Azure
  • Storage account to and Azure file
  • Subnet for the Private Link Endpoints
  • Storage account to and Azure file share
  • On-Premise file share

Storage Sync Service

First we need to create a Storage Sync Service, which in itself is a little strange as you need to go to the marketplace and its called Azure File Sync:

Click create, and add the resource group, stroage sync service name and region, add any tags and create:

Add a sync group, this will contain the cloud endpoint (File share) and server endpoint (on -premise file server). Give the sync group and name and select the storage account and file share created previously, and click create.

Once the sync group has been created, you will notice the cloud endpoint has already been created.

Before installing the server endpoint we are going to create the Private Link Endpoints, which will associate an IP address with the storage account and each of the File Sync services..

At the top of the screen type Private Link Center, once the page loads, click on the Private Endpoints on the left hand side.

We will be adding 2 Private endpoints, one for the storage account and one for the storage sync service. For the first you add the resource group, name and region.

Next we need to add the resource type, resource and target sub-resource. In the below screenshot you can see I have selected Microsoft.Storage/storageAccounts as the resource type. It is important to make sure you select the correct storage account and target sub-resource.

On te configuration page, select the VNet and subnet which will contain the Private Endpoint IP addresses.

Once you have added any tags you can click create.

Next is to create another Private endpoint for the Storage Sync Service,. The steps are the same as above except on the resource page you select Microsoft.StorageSync/storaageSyncService as the resource type, select the Storage Sync Service as the resource and AFS as the target sub-resource.

Before moving to the server endpoints we have two last steps, first is to obtain the FQDN and IP address for the storage endpoint and each of the Storage Sync Service services. The best place to get these is to Private DNS Zones:

First we will get the Storage private endpoint FQDN and IP address. Click on, and then the storage account name:

Take a note of the name and IP address:

Do the same for the Private Link Endpoint services, note there will be 4 of these, so make sure you capture the name and IP details of each one.

Before adding the details captured above as DNS entries you need to remove “privatelink” from the FQDN.





We can now go to the storage account, networking and Private endpoint to ensure the Private Endpoint has been created.

Going to the Firewall and Virtual Networks on the storage account, select “Selected Networks” but do not add any networks.

Lastly step is to run the following script in Azure Powershell which forces all traffic over the VPN and not the internet, replacing the resource group name and Storage Sync Service in the top 2 lines.

$storageSyncServiceResourceGroupName = "<storage-sync-service-resource-group>"
$storageSyncServiceName = "<storage-sync-service>"

$storageSyncService = Get-AzResource `
        -ResourceGroupName $storageSyncServiceResourceGroupName `
        -ResourceName $storageSyncServiceName `
        -ResourceType "Microsoft.StorageSync/storageSyncServices"

$storageSyncService.Properties.incomingTrafficPolicy = "AllowVirtualNetworksOnly"
$storageSyncService = $storageSyncService | Set-AzResource -Confirm:$false -Force -UsePatchSemantics

Finally on to the Server Endpoint. Download the FileSync agent from here, and run the installer. During the installation you can select automatic updates, and a proxy if required. Once the installation is complete, log in with your Azure credentials.

Select the Azure Subscription, Resource Group and Storage Sync Service created previously.

Final step is to go back to the Storage Sync Service in Azure, and to the Sync group. Select Add Server Endpoint at the top of the screen.

Add the registered server, share path and cloud tiering requirements.

Once its finished processing, the health should turn green, and thats it all done.

Setting up File Sync to run over a VPN/ExpressRoute does take a bit of configuration, but its well worth it to ensure the data is not synced over the internet.

Below is some additional Microsoft documentation.

Deploy Azure File Sync

Planning for an Azure File Sync Deployment

Azure File Sync Networking Considerations

Azure Private Endpoint DNS Configuration

Troubleshoot Azure File Sync

Azure Firewall Routing

I recently had a customer who had a small Azure environment and was looking to add an Azure Firewall with the following requirements:

  • All traffic between their on-premise environment and Azure via an Azure firewall.
  • All VM to internet traffic should utilise the firewall’s public IP address.

As you may be aware all VM’s in Azure are connected to the internet via the Azure backbone. VM’s do not require a public IP address to connect to the internet. This obviously raises some major security concerns. There are a couple of ways around this, either by using forced tunnelling which lets you redirect all internet traffic back to your on-premise network either via S2S VPN or ExpressRoute for inspection with your on-premise firewall. The other option is to add a firewall in Azure. This allows you to direct all internet traffic via the firewall in Azure, and also allow you to direct all traffic between Azure and on-premise and vice versa via the Azure firewall.

Below is a quick overview of the design. Red is the flow from VM to the internet, Blue is the flow between on-premise and Azure.

In the above example we have a Hub VNet on with a S2S VPN and an Azure firewall on, and a subnet on and a single VM on The spoke Vnet is peered to the hub Vnet with gateway transit enabled. The spoke VNet contains one subnet with a single VM on

Next step is to ensure all internet traffic is via the firewall and not directly over the Azure backbone. A quick way to do this is to find which IP address the VM’s are using to access the internet. Log into each VM and open your favourite browser and browse . Both Vm’s will most likely have the same IP address.

In order to route all internet traffic to the firewall you will need to create a default route to the internet.

First for the hub VNet:

  • Route Table: hubtofirewall
  • Route Name: hubtointernet
  • Address Prefix:
  • Next hop type: Virtual Appliance
  • Next Hop Address:
  • Associated subnet:

Next the spoke VNet:

  • Route Table: spoketofirewall
  • Route Name: spoketointernet
  • Address Prefix:
  • Next hop type: Virtual Appliance
  • Next Hop Address:
  • Associated subnet:

To ensure the traffic to the internet is now traversing the firewall you can log back into the VM’s, browse to, you will notice the IP has changed to the firewalls public IP address.

Next step is to route all traffic between Azure and on-premise via the firewall, this involves route traffic destined to the on-premise network to the firewall. In the first route table named hubtofirewall add the following route:

  • Route Name: hubtoonprem
  • Address Prefix:
  • Next hop type: Virtual Appliance
  • Next Hop Address:

Add the same details to the 2nd Route table, changing the name:

  • Route Name: spoketoonprem
  • Address Prefix:
  • Next hop type: Virtual Appliance
  • Next Hop Address:

These routes can be confirmed by viewing the effective routes:



Now that you all traffic from Azure is routed to the firewall the last step is to route the traffic from the gateway to the firewall,

  • Route Table: gateway
  • Route Name: gatewaytohub
  • Address Prefix:
  • Next hop type: Virtual Appliance
  • Next Hop Address:
  • Associated subnet: GatewaySubnet

Finally add the last route to the same Route Table:

  • Route Name: gatewaytospoke
  • Address Prefix:
  • Next hop type: Virtual Appliance
  • Next Hop Address:

Provided the firewall is configured to allow traffic in both directions, all traffic should now traverse the firewall.

Job done 🙂