Configuring Azure Firewall with a contiguous public IP Range

The Azure Firewall is a service offering available to customers in Azure. I'm not going to cover the details of the architecture or the basics of deploying Azure Firewall in this article. 

Many enterprise customers are adopting Azure Firewall to help control and manage the traffic flow for their services within a Azure and in hybrid locations across their WAN. A common ask for customers who are deploying edge facing services is around Public IP space, and how this differs in the cloud compared to on-premise with a traditional ISP.

Any customer with an active Azure Subscription can allocate and assign public addresses to their services from the portal. Many services, such as Azure Virtual Machines are provisioned with a public address as part of the automated deployment process.

Enterprise customers are usually looking for a little more control. This is where Public IP Prefixes come into the picture. It is possible for a customer to define a CIDR Block of public addresses directly in their subscription, to be used at their disposal. This is done by creating a new Public IP Prefix, as shown below.

You will see in the article below Public IP Prefixes can be provisioned with /31, /30, /29 or /28 CIDR Blocks giving a contiguous range of 2, 4, 8 or 16 public addresses. It is possible to bind one of these Public IP Prefixes to your Azure Firewall to ensure the public address range is contiguous.

Once you have you Public IP Prefix create, you must then use the Add IP Address option from the resource. This will create an actual usable address within the prefix range which can in turn be associated to Azure Firewall.

When you provision a new address you must give it a name and a resolveable DNS label.

Now head over to Azure Firewall and go to the Public IP Configuration section and click on Add a Public IP Configuration. This will guide you through binding this new public address to your Azure Firewall. It's worth noting that you cannot provision an Azure Firewall with a Public IP Prefix, you must first create the Azure Firewall with it's default of one random public address, then retrospectively configure the prefix like we are doing here.

From the Add Public IP Configuration window from within Azure Firewall you will notice from the drop down that the public addresses you provisioned as part of the prefix block are now available to be bound to the outside of the Azure Firewall. 

Azure StorSimple Failing Over a Physical Device to the Virtual Appliance for DR

Azure’s StorSimple device is a Hybrid Cloud Storage solution from Microsoft. I assume you already know what StorSimple is if you are reading this blog post on Disaster Recovery for the unit. If you do not, you can download a PowerPoint I created as an Introduction to people who are not familiar with StorSimple. You can download it here

In the event you StorSimple appliance (unlikely as it’s redundant at every component) fails, it is possible to failover your Volume Containers to a Virtual Appliance edition of the StorSimple software running in Azure. The Virtual Appliance (or VSA) is basically an Azure IaaS VM that is running a subset of the StorSimple code. You must have Cloud Snapshots already in Azure of your Volume Containers that reside on your physical appliance in order for this to work. You will probably have a Backup Policy configured to do Cloud Snapshots of your StorSimple at certain intervals.

As I am doing this failover in a test environment my physical appliance has not actually failed therefore I am going to simulate this by taking my Volume Container offline manually, this is done from the Volume Containers page. If your physical appliance had failed, you could miss this step.

You must also deploy a StorSimple VSA before you start, use the Create Virtual Device option from inside the StorSimple manager. When you run through creating a StorSimple VSA, you must provide it with an Azure vNet and Storage Account to be provisioned into. The Azure vNet is important as you will also need a Windows VM on that same network so that you can make a new iSCSI connection to the VSA once failover is complete.

Highlight the physical appliance and click Failover. Select the Volume Container you want to failover onto the VSA and click Next.

Select a Target Device (this should be your VSA that you provisioned), please note that if your VSA does not appear under this list it’s probably because you have not completed the configuration of the VSA. The VSA requires post deployment configuration for things like the Encryption Keys etc. Click Next.

Review the failover summary page and tick the I accept the ……….and click Next.

This will create a failover job for the Volume Container, you can view the progress under the Jobs menu.

Now highlight and click on the VSA.

Click on Volume Containers and then click onto the Volume, the next stage is to create an ACR (Access Control Record) for the new Azure iSCSI VM. Without this the Azure VM won’t have access to the iSCSI Initiator (VSA).

Click Modify.

I have already created an Azure VM and dropped it into the same network as the VSA. Connect to this VM as we will require the iSCSI IQN in order to create the ACR.

Launch the iSCSI Initiator and click on Configuration. Copy the iSCSI Initiator string.

Return to the Volumes page on the StorSimple Manager, you must take the Volume Offline before you can amend the ACR’s.

On the Additional Settings page, create a new ACR using the VM’s name and the iSCSI IQN.

Use the Bring Online button to bring the Volume back up.

Return to the Azure VM iSCSI Server and on the Quick Connect box, type the StorSimple VSA IP, you can get this from the device summary or from the Azure vNet itself. All going well it should make a connection to the VSA.

Rescan the disks from Disk Manager and you should be able to see the files that were stored on your StorSimple physical appliance.