Category Archives: Azure Networking

Azure Firewall: automation to manage your backups

Azure Firewall is the firewall-as-a-service solution exists in the Microsoft public cloud, which allows you to secure the resources present in the Azure Virtual Networks and to govern the related network flows. This article provides a mechanism designed to make the scheduled backup of this component configuration using Azure Automation.

Azure Firewall is a solution that is increasingly being used in Azure architectures, for the advantages over firewall solutions by third party vendors and thanks to a constant enrichment of features offered. From the moment it is adopted, this service becomes the government center of your Azure networking environment and will contain different rules to comprehensively manage the network traffic. It is therefore essential to have a strategy that allows you to restore the configuration of the service quickly. The service currently does not have an integrated feature to make full backup periodically. For this reason I made a runbook in Azure Automation that backup the Azure Firewall configuration on a Azure blob storage account.

In the following paragraphs there is the procedure for enabling periodic configuration backup using this methodology.

Prerequisites

If you do not have an Azure Automation Account is necessary to proceed with its creation:

Figure 1 – Creating Azure Automation Account

It is also necessary to have a blob storage account on which the Azure Firewall backups will be saved.

Figure 2 — Create blob storage account

In the firewall account storage settings must be enabled the exception "Allow trusted Microsoft services to access this storage account".

On the storage account you can also consider creating policies that enable you to prevent the deletion of backups.

Configuring modules on Azure Automation

Azure Automation supports the ability to use the moduleAzure Powershell Az in runbooks. The module AZ is currently not automatically imported into Automation Accounts. For this reason it is necessary procedures with its configuration as described by this Microsoft's document, in particular by following the procedure given below.

Figure 3 – Start process of adding modules

Figure 4 - Selection of the necessary modules and starting the import process

These are the modules required for this automation:

Figure 5 – Required modules

Import and publish of runbook

The next step is to create the Runbook in Azure Automation:

Figure 6 – Creation of Runbook

You can find the code of the runbook in this GitHub page. Once you have created the runbook is appropriate to proceed with its publication.

Figure 7 - Publication of the Runbook.

Runbook schedule

As last step you should schedule the periodic execution of the runbook.

Figure 8 - Creation of schedule

Figure 9 - Adding the scheduling to the runbook

Figure 10 - Configuration of parameters required by the runbook

Backups in JSON format of the Azure Firewall configuration is automatically saved in the storage accounts indicated and are retained for the number of days expressed in the parameter "RetentionDays".

Figure 11 - Azure Firewall Backups inside the container

Restoring your configuration

In case you need to restore the Azure Firewall configuration is sufficient to deploy the JSON file in the specific resource group, using the following command:

New-AzResourceGroupDeployment -name “RestoreAzureFirewall” -ResourceGroupName “AFW-RGNamexxx” -TemplateFile “.xxx-afwxxxxx.json”

Conclusions

Thanks to the adoption of this automation is possible to backup Azure Firewall configuration on a Azure blob storage account. All this is particularly useful and strategic in case of wrong modification of the rules, or if there is a partial or total cancellation of Azure Firewall configuration, which can be accidental or carried out by unauthorized persons.

How to remote access virtual machines in Azure

Being able to access via RDP (Remote Desktop Protocol) or via SSH (Secure SHel) to virtual machines present in Azure is a basic requirement for system administrators. Direct exposure of these protocols on Intenet is definitely a practice to be avoided as a high risk security. This article shows the different methodologies that can be taken to gain remote access to systems present in Azure and the characteristics of each of it.

Recently Microsoft has released a security update rated critical and directed to resolution of the vulnerability CVE-2019-0708 identified on the Remote Desktop service for different operating systems. The vulnerability allows code execution via RDP protocol allowing you to take full control of the remote system. This vulnerability is taken as an example to highlight how is actually risky to publish on Internet these access protocols. For this reason you should consider adopting one of the solutions below for even more security.

Figure 1 – RDP/SSH attack

VPN access

To have an easy administrative access to the Azure Virtual Network you can enable a Point-to-Site VPN (P2S). Through the P2S VPN can establish connectivity from one location to the Azure environment, easily and securely. When the VPN connection is established you will have the ability to remotely access to systems in Azure. For more information on VPN P2S I invite you to read the article Azure Networking: Point-to-Site VPN access and what's new. Adopting this methodology you should take into consideration the maximum number of connections for each Azure VPN Gateway.

Figure 2 - Protocols available for P2S VPN

Just-in-Time VM Access

It is a feature available in Azure Security Center Standard Tier, allowing you to apply the necessary configurations to the Network Security Groups (NSG) and more recently to Azure Firewall to allow administrative access to systems, properly filtered for source IP and for a certain period of time. Just-in-Time VM Access allows to perform the configurations needed to access remotely to systems quickly, targeted and only for a very specific time period. Without the use of this feature you would need to manually create the appropriate rules within the NSG or Azure Firewall (NAT Rule), and remember to remove them when no longer needed.

Figure 3 - Request access via Just-in-Time VM Access

Jumpbox

A scenario that is used in some situations is the presence of a virtual machine (Jumpbox) accessible remotely and dislocated in a suitably isolated subnet, that is used to access several other systems in communication with that subnet. In a network architecture that reflects the hub-and-spoke topology, typically this system is positioned in the hub network, but it is recommended to apply filters to make sure that this system is only accessible from certain public IP addresses, without exposing it directly on the Internet. In this scenario you should take into consideration that you will have a maximum of two remote connections simultaneously for single JumpBox.

Figure 4 - Positioning of the JumpBox in a hub-spoke architecture

Azure Bastion

It is a PaaS service, recently announced by Microsoft in preview, offering a safe and reliable SSH and RDP access to virtual machines, directly through the Azure portal. The provisioning of Azure Bastion service is carried out within a Virtual Network of Azure and it supports access to all the virtual machines on it attested, without exposing the public IP addresses.

Figure 5 - Azure Bastion Architecture

For more details on this please read the article Azure Bastion: a new security model created by Silvio Di Benedetto.

Azure Bastion is a paid service, to get cost details you can access the page Azure Bastion pricing.

At the time you should take into account that Azure Bastion and Just-in-Time VM Access can not be used to access the same systems.

SSL Gateway

A very valid solution in terms of security is an implementation of a Remote Desktop Services environment in Azure, which includes the use of Remote Desktop Gateway role, specially designed to be directly exposed to the Internet (TCP port 443). With this component you can encapsulate RDP traffic in an HTTP over TLS / SSL tunnel. The Remote Desktop Gateway also supports Multi-Factor Authentication that allows to further increase the level of security for remote access to resources. A similar solution is also available in Citrix environment. In this area you will need to consider, in addition to the costs associated with Azure components, also the license costs.

Figure 6 - Possible Remote Desktop Services architecture in Azure environment

Conclusions

There are several possibilities for providing a secure remote access to virtual machines in the Azure environment. The new Azure Bastion service is a safe and simple method, but that needs to be expanded with more features, the most important are certainly support for Virtual Networks in peering and for multi-factor authentication. These features probably will be available when the solution will be globally available. Waiting to use Azure Bastion in a production environment you can use the other methods listed, thus avoiding having to expose unprotected systems to the Internet.

Azure Networking: all you should know about the new Application Gateway

The Application Gateway is the offer for application delivery controller as-a-service present in Azure that enables customers to make the application republishing, with integrated layer-7 load balancing, Security and Web Application Firewall (WAF). Microsoft recently announced the availability of a fully revised version of Azure Application Gateway and its Web Application Firewall module (WAF). This article lists the improvements and additional features that are present in the new SKUs, calls respectively Standard_v2 and WAF_v2.

Enhancements and new features

The following section shows the areas where the new Azure Application Gateway version has made improvements and additional features.

Figure 1 - Diagram with the new features of SKU V2

Scalability

The new version of Azure Application Gateway allows you to automatically perform a scale-up or a scale-down of the number of instances to use, based on traffic detected towards the applications republished. In this way the size of the Application Gateway will always be suitable to support the necessary traffic and will not be more appropriate sizing this component to maximum capacity to sustain moments with traffic spikes. Consequently, with this feature you can get significant cost savings in scenarios where there are workloads that do not have a homogeneous flow, but subject to change.

Zone redundancy

In the new SKU it is possible to do the deployment of the Application Gateway in different areas of availability (availability zone) so as not to be subject to disruptions in the event of problems related to the single zone of Azure. This method of deployment allows increasing the resilience of published applications.

Public Static IP Assignment

The Virtual IP Address assigned to the Application Gateway can be static, thus ensuring a constant IP address assignment for the lifetime of the component. This feature is particularly useful for managing rules on Azure external firewall systems and for web publishing scenarios of Azure Web App.

Header Rewrite

Header Rewrite functionality allows you to easily manage the publications of applications as it is allowed to add, remove or modify HTTP request and response headers, directly from the Application Gateway and without needing to change the code of the application.

Performance

The adoption of the new Application Gateway SKU allows a significant improvement in performance during the provisioning and during the configuration update activities. Furthermore, it shows an improvement in performance, up to 5 times higher than the previous SKU, in SSL offloading scenarios.

The recommendation

For all new implementations is raccomanded to consider the adoption of the new Azure Application Gateway SKU, while for those who are making application publications by Application Gateway V1, it is recommended that you migrate the SKU V2 quickly, for the following reasons:

New features and improvements: Migrating to new SKU you can benefit from the improvements and new features listed above.
Cost: view the new pricing policy adopted for the SKU V2, based on consumption and no longer on the size and the number of instances, this may be generally more convenient than SKU V1. For more information on the costs of the new Azure Application Gateway version, you can see the relative costs page.
Platform support: soon Microsoft will disable the ability to create new Application Gateway V1. Furthermore, in the future, Microsoft will release additional new features, but most of these will be released exclusively for the SKU V2.

As migration occurs to the SKU V2

Currently the Azure platform does not provide an automatic procedure to migrate from V1 to V2 SKU, but it is necessary to proceed with a side-by-side migration. To proceed with this activity is necessary a suitable preliminary analysis to verify the presence of all the necessary requirements. The migration of existing configuration can be done through Special scripts of support, but may still be required manual activities. Completed the configuration of all settings to the new Azure Application Gateway V2 you need to redirect the flow of traffic coming from client to the new Application Delivery Service.

Conclusions

The introduction of the new features described above makes the offer of application delivery controller as-a-service available in Azure platform even more complete and functional, to the point of being highly competitive with other vendor solutions, long established on the market. To be constantly updated with the rapid evolution of the cloud is recommended to determine as soon as possible the transition to the new Application Gateway version in order to benefit from the advantages mentioned above.

Azure Networking: Point-to-Site VPN access and what's new

Among the different possibilities to establish a hybrid connectivity with the Azure cloud exist VPN Point-to-Site (P2S). Through the VPN P2S you can enable connectivity from one location to the Azure environment, easily and securely. It is a useful solution to allow communication from remote locations to the Virtual Network of Azure, mostly used for test and development purposes. Can be activated alternatively to Site-to-Site VPN if you must provide connectivity to Azure for a very limited number of systems. This article describes the features of this connectivity and displays the latest news about.

To establish hybrid connectivity with Azure we can use different methodologies, each of which has different characteristics and may be eligible for specific scenarios, providing different levels of performance and reliability.

Figure 1 – Options to enable hybrid connectivity with Azure

The Point-to-Site VPN definitely provide a more limited set of features compared to other hybrid connectivity options and are appropriate in specific cases, where only a limited number of places should be connected to the Azure environment. The P2S connection is established by starting directly from the remote system and in the solution are not expected native systems to activate it in an automatic way.

Figure 2 – Comparison of hybrid connectivity options

Protocols used by the P2S VPN

The Point-to-site VPNs can be configured to use the following protocols:

OpenVPN®: is a protocol recently added in Azure, but already widely used by different solutions, that enriches this type of connectivity. This is an SSL/TLS based VPN Protocol, that due to its characteristics more easily traverses firewalls. Furthermore, it is compatible with different platforms: Android, IOS (version 11.0 and above), Windows, Linux and Mac devices (OSX version 10.13 and later).
Secure Socket Tunneling Protocol (SSTP): This is a Microsoft proprietary VPN protocol based on SSL and it can easily cross firewalls, but has the limitation that can only be used by Windows systems. In particular, Azure supports all versions of Windows that include SSTP (Windows 7 and newer).
IKEv2: This is an IPsec VPN solution that can be used by different client platforms, but in order to function it requires that in the firewall are permitted specific communications. IKEv2 is supported on Windows 10 and Windows Server 2016, but in order to use it you need to install specific updates and set certain registry keys. Previous versions of the OS are not supported and can only use SSTP, orOpenVPN®.

Figure 3 – OpenVPN Protocols® and IKEv2 compared

The Point-to-Site VPN require the presence of a VPN gateway on the active virtual network of Azure and depending on the SKU vary the maximum number of possible connections. It should also be taken into account that the VPN Gateway Basic does not support IKEv2 and OpenVPN protocols.

Figure 4 – Gateway SKU in comparison for VPNs P2S

Coexistence between the P2S VPN and S2S VPN for the same virtual network is possible only in the presence of VPN gateway RouteBased.

Supported client authentications

Point-to-site VPN access provides the ability to use the following authentication methods:

Azure native authentication using certificates. With this mode, the authentication takes place via a client certificate present on the device that needs to connect. Client certificates are generated by a trusted root certificate and must be installed on each system to connect. The root certificate can be issued by an Enterprise solution, or you can generate a self-signed certificate. The client certificate validation process is performed by the VPN gateway while attempting to connect the P2S VPN. The root certificate must be loaded into the Azure environment and is required for the validation process.
Authentication using Active Directory (AD) Domain Server. Thanks to this type of authentication users can authenticate using domain credentials. This methodology requires a RADIUS server integrated with AD. RADIUS system can be deployed on-premises or in the VNet of Azure. Using this mechanism, during the authentication process, the Azure VPN Gateway communicates with the RADIUS system, therefore it is essential to provide this communication flow. If the RADIUS server is deployed on-premises, must therefore be a connectivity through S2S VPN with on-premises systems. The RADIUS server can use certificates issued by an internal Certification Authority as an alternative to certificates issued by Azure, with the advantage that it is not necessary to manage Azure upload root certificates and certificate revocation. Another important aspect is that the RADIUS server can be integrated with third-party authentication mechanisms, thus opening the possibility of also use multifactor authentication for P2S VPN access. At the moment the OpenVPN® Protocol is not supported with RADIUS authentication.

Conclusions

Point-to-Site VPNs (P2S) can be very useful to provide connectivity to the Azure Virtual Networks in very specific scenarios. Thanks to the introduction of the support to OpenVPN® protocol it is possible to activate more easily and from different devices (Windows, Mac and Linux), without neglecting safety aspects.

Azure DNS overview

The Microsoft public cloud offers various services including Azure DNS, that allows you to host and manage domains DNS (Domain Name System) public and private in the Azure environment. This article lists the characteristics of the solution, the possible use cases and discusses the advantages of adopting this solution.

Public name resolution

The Azure DNS service can be used to resolve public domain names. Azure does not allow direct purchase of public domains, but assuming that you have a public domain, you can use the Azure DNS to resolve domain names.

To do so you need to proceed with the creation of a Dns Zone, this is the procedure to activate it from the portal Azure:

Figure 1 – Creation of DNS Zone

In the activation process of a DNS zone you are prompted to specify the location of the Resource Group, that determines where the metadata associated with the DNS zone are maintained. The Azure DNS service is indeed global and not associated with a specific Azure location.

The creation process is very quick and, at the end of the service creation, you can identify the name servers that you can use for the zone created.

Figure 2 - Name Servers for DNS zone created

After you create the DNS zones in Azure, you must delegate the name resolution for the domain to name servers in Azure. Every Registar has its own tool for managing names, where you can specify NS records, making them point to the four Name Servers provided by Azure DNS service.

At this point you can add and manage any public DNS records on yours DNS zone hosted in Azure environment.

Figure 3 — Add a DNS record

Private name resolution

In Azure Virtual Networks the DNS is integrated into the platform and it is available by default, which allows the resolution of the system names on them attested (Azure-provided). Alternatively, you can specify custom DNS Servers. The Azure DNS service extends these capabilities by enabling new scenarios, thanks to the possibility to use the Azure DNS service, not only to handle name resolution for public domains, currently in preview, you are given the option to enable a private DNS zone. For private DNS zones the virtual networks that can take advantage of the name resolution service, are called resolution virtual networks. While the registration virtual network are those VNet for which it is expected the maintenance of the hostname when you create a VM, when this changes its IP address, or when it is removed.

The creation of a private DNS zone can be done with PowerShell commands and not by the portal Azure.

Figure 4 – PowerShell commands for creating a private DNS zone

By using the PowerShell command New-AzDnsZone you can specify that it is a private zone with parameter ZoneType valued at Private. If you want to use the private zone just for name resolution, without making any future automatic creation of DNS records, you can specify the parameterResolutionVirtualNetworkId, otherwise, if you want the automatic registration of names you should specify the parameterRegistrationVirtualNetworkId. In this regard, currently the initial pairing as RegistrationResolution Virtual Network is only possible if the VNet has not attested systems on it.

At the end of the execution of the PowerShell commands it will be possible to see the private zone also in the Azure portal. The private zones at the moment are distinguished from the others because it does not have the list of Name Servers. It is still possible to register and manage your DNS records, not only using PowerShell or CLI, but also from the portal.

Figure 5 -Example of private DNS zone in the Azure Portal.

Usage scenarios

The presence of the Private Zone in the Azure DNS service allows to be adopted in different scenarios.

Name resolution for a single Virtual Network

This scenario has a single virtual network that takes advantage of the Azure private DNS to resolve internal names. That resolution is totally private and can be used by all resources attested on that specific VNet.

Figure 6 - Azure Private DNS for a single VNet

Name resolution between different Virtual Networks

This scenario is commonly used when multiple virtual networks have access to the same Azure private DNS service. The adoption of this scenario is typical in the presence of architectures Hub-Spoke, where the Hub network can be associated with the private Azure DNS zone in mode Registration, while the various spoke networks may be associated as Resolution virtual network.

Figure 7 – Azure Private DNS for two VNet

Split-Horizon capabilities

It falls in this scenario when for the same DNS zone there is the need to obtain different resolution of the names depending on where the client is located, Azure environment or in Internet.

Figure 8 – Azure Private DNS in a Split-Horizon scenario

The Cost of the Solution

The Azure DNS cost is given by two elements:

Number of DNS zones hosted in Azure (public or private).
Number of DNS queries received.

To get the details of the Azure DNS costs you can see the official page.

Advantages

The ability to host DNS zones in Azure introduces a number of benefits, including:

The DNS service can be provided using the native tools offered by the Azure platform, without having to use custom DNS solutions, thus saving on time and costs.
The service allows you to use all the most common types of DNS records: In, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT.
It provides automatic management of the DNS records for virtual machines on specific Azure Virtual Networks.
Private DNS name resolution can be shared between different Virtual Networks, unlike as it offers the service of name resolution provided by default on the VNet. This expands possible usage scenarios and simplify the architecture, thanks to the Split-horizon capabilities.
The solution can be fully managed via the Azure tools (PowerShell, Azure Resource Manager templates, and REST API), reducing the learning curve for the actual adoption.

Conclusions

The Azure DNS service allows you to host your own DNS domains in Azure, providing the ability to manage them with the same credentials, the same billing policies and support of the other Azure services. The introduction of Private Azure DNS Zones introduces an important element that, when it is officially released, will be taken into consideration in the design of Azure architectures, in order to simplify them and make them more efficient. Azure DNS also provides reliability, scalability, security and availability, as it is based on the Microsoft global network, hardly obtainable with third-party solutions.

Azure Networking: security services overview

In the modern era of cloud computing, the tendency is to move more frequently workloads in the public cloud and to use hybrid cloud. Security is often perceived as an inhibitor element for the use of cloud environments. Can you extend the datacenter to the cloud while maintaining a high level of network security? How to ensure safe access to services in the cloud and with which tools? One of the main reasons to use Azure, for your own applications and services, is the possibility to take advantage of a rich set of functionality and security tools integrated in the platform. This article will be a overview of network security services in Azure, reporting guidelines and useful tips to best utilize the potential of the platform, in order to structure the network in Azure respecting all security principles.

In field Azure Networking are available different services for enabling connectivity to distinct environments, according to different modes, to activate the protection of the network and to configure the application delivery. All these services are integrated with monitor systems offered by Azure, going to create a complete ecosystem for the provision of network services.

Figure 1 – Azure Networking Services

In order to configure the network protection for Azure we find the following services, available natively in the platform.

Network Security Group (NSG)

Network Security Groups (NSGs) are the main tool to control network traffic in Azure. Through the rules of deny and permit you can filter communications between different workloads on an Azure virtual network. Furthermore, you can apply filters on communications with systems that reside on-premises, connected to the Azure VNet, or for communications to and from Internet. Network Security Groups (NSGs) can be applied on a specific subnet of a Azure VNet or directly on the individual network adapters of Azure virtual machines. The advice is to apply them if possible directly on the subnet, to have a comprehensive and more flexible control of ACLs. The NSGs can contain rules with Service Tags, that allow you to group with predefined categories of IP addresses, including those assigned to specific Azure services (ex. AzureMonitor, Appservice, Storage, etc.).

The rules of the Network Security Groups can also be referenced Application Security Groups (ASGs). These are groups that contain network adapters of virtual machines on Azure. ASGs allow you to group multiple servers with mnemonic names, useful in particular for dynamic workloads. The Application Security Groups also enable you no longer have to manage in the rules of NSGs IP addresses of Azure virtual machines , as long as these IPs are related to VMs attested on the same VNet.

Figure 2 -Example of a NSG rule that contains a Service Tag and ASG

Figure 3 - Graphical display of network traffic segregation via NSG

Service Endpoints

Through the Virtual Network (VNet) service endpoints, you can increase the level of security for Azure Services, preventing unauthorized access. The vNet Service Endpoints allow you to isolate the Azure services, allowing access to them only by one or more subnets defined in the Virtual Network. This feature also ensures that all traffic generated from the VNet towards the Azure services will always remain within the Azure backbone network. For the supported services and get more details about this you can see the Microsoft documentation.

Figure 4 – Summary of Sevice Endpoints

Azure Firewall

The Azure Firewall is a firewall, fully integrated into the Microsoft public cloud, of type stateful, which makes it possible to centrally control, through policy enforcement, network communication streams, all cross subscriptions and cross virtual networks. Azure Firewall also allows you to filter traffic between the virtual networks of Azure and on-premises networks, interacting with connectivity that is through the Azure VPN Gateway and with Express Route Gateway. For more details about it you can see the article Introduction to Azure Firewall.

Figure 5 – Placement of Azure Firewall

Web Application Firewall

The application delivery may be made using the Azure Application Gateway, a service managed by the Azure platform, with inherent features of high availability and scalability. The Application Gateway is a application load balancer (OSI layer 7) for web traffic, that allows you to govern HTTP and HTTPS applications traffic (URL path, host based, round robin, session affinity, redirection). The Application Gateway is able to centrally manage certificates for application publishing, using SSL and SSL offload policy when necessary. The Application Gateway may have assigned a private IP address or a public IP address, if the application must be republished in Internet. In particular, in the latter case, it is recommended to turn on Web Application Firewall (WAF), that provides application protection, based on rules OWASP core rule sets. The WAF protects the application from vulnerabilities and against common attacks, such as X-Site Scripting and SQL Injection attacks.

Figure 6 – Overview of Application Gateway with WAF

DDoS protection

In Azure, DDoS protection is available in two different tiers: Basic oppure Standard.

The protection Basic is enabled by default in the Azure platform, which constantly monitors traffic and applies mitigations to the most common network attacks in real time. This tier provides the same level of protection adopted and tested by Microsoft's online services and is active for Azure Public IP addresses (Pv4 and IPv6). No configuration is required for the Basic tier.

Typology Azure DDoS Protection Standard provides additional mitigation features over the Basic tier, that are specifically optimized for resources located in Azure virtual networks. The protection policies are self-configured and are optimized by carrying out specific monitoring of network traffic and applying machine learning algorithms, that allow you to profile your application in the most appropriate and flexible way by studying the traffic generated. When the thresholds set in the DDoS policy are exceeded, the DDoS mitigation process is automatically started, which is suspended when it falls below the established traffic thresholds. These policies are applied to all public IP of Azure (IPv4) associated with resources present in the virtual network, like: virtual machines, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway and Azure Service Fabric instances.

For more details about it you can see the article Protection from DDoS attacks in Azure.

Synergies and recommendations for the use of the various protection services

In order to obtain an effective network security and direct you in the use of the various components, are reported the main recommendations which is recommended to consider:

Network Security Groups (NSGs) and the Azure Firewall are complementary and using them together you get a high degree of defense. The NSGs is recommended to use them to filter traffic between the resources that reside within a VNet, while the Azure Firewall is useful for providing network and application protection between different Virtual Networks.
To increase the security of Azure PaaS services is advised to use the Service endpoints, which can be used in conjunction with Azure Firewall to consolidate and centralize access logs. To do this, you can enable the service endpoint in the Azure Firewall subnet, disabling the subnet present in the Spoke VNet.
Azure Firewall provides network protection Layer 3 for all ports and protocols, it also guarantees a level of application protection (Layer 7) for outbound HTTP/S traffic. For this reason, if you wish to make a secure application publishing (HTTP/S in inbound) you should use the Web Application Firewall present in the Application Gateway, then placing it alongside Azure Firewall.
Azure Firewall can also be supported by third-party WAF / DDoS solutions.

All these protection services, suitably configured in a Hub-Spoke network architecture allow you to perform a segregation of network traffic, achieving a high level of control and security.

Figure 7 – Security services in a Hub-and-Spoke architecture

Conclusions

Azure provides a wide range of services that allow you to achieve high levels of security, acting on different fronts. The security model that you decide to take, you can resize it and adapt flexibly, depending on the type of application workloads to be protected. A winning strategy can be obtained by applying a mix-and-match of different network security services, to get a protection on more layers.

Azure Virtual WAN: introduction to the solution

Azure Virtual WAN is a new network service that allows you to optimize and automate the branch-to-branch connectivity through Azure. Thanks to this service you can connect and configure network devices in branch to allow communication with Azure (branch-to-Azure). This article examines the components involved in Azure Virtual WAN and shows the procedure to be followed for its configuration.

Figure 1 – Azure Virtual WAN overview

The Azure Virtual WAN configuration includes the creation of the following resources.

Virtual WAN

The Virtual WAN resource represents a virtual layer of Azure network and collect different components. It is a layering that contains links to all the virtual hubs that you want to have inside the Virtual WAN. Virtual WAN resources are isolated and cannot contain common hubs.

Figure 2 – Start the process of creating Azure Virtual WAN

Figure 3 – Creating Azure Virtual WAN

When creating the Virtual WAN resource you are prompted to specify a location. In reality it is a global resource that does not reside in a particular region, but you are prompted to specify it just to be able to manage and locate more easily.

By enabling the option Network traffic allowed between branches associated with the same hub allows traffic between the various sites (VPN or ExpressRoute) associated with the same hub (branch-to-branch).

Figure 4 – Branch-to-branch connectivity option

Site

The site represents the on-prem environment. You will need to create as many sites as are the physical location. For example, if you have a branch office in Milan, one in New York and one in London, you will need to create three separate sites, which contain their endpoints of network devices used to establish communication. If you are using Virtual WAN partner network equipment, provides solutions to natively export this information into the Azure environment.

Figure 5 – Creating a site

In the advanced settings you can enable BGP, which if activated becomes valid for all connections created for the specific site . Among the optional fields you can specify device information, that may be of help to the Azure Team in case of any future enhancements or Azure support.

Virtual Hub

A Virtual Hub is a Microsoft-managed virtual network. The hub is the core component of the network in a given region and there can be only one hub for Azure region. The hub contains different service endpoints to allow to establish connectivity with the on-prem environment. Creating a Virtual Hub involves the generation of a new VNet and optionally a new VPN Gateway. The Hub Gateway is not a classic virtual network gateway that is used for ExpressRoute connectivity and VPN and it is used to create a Site-to-site connection between the on-prem environment and the hub.

Figure 6 – Creating a Hub

Figure 7 -Association of the site with a Hub

The Hubs should be associated with sites residing in the same region where there are the VNet.

Hub virtual network connection

The resource Hub virtual network connection is used to connect the hub with the virtual network. Currently you can create connections (peering) with virtual networks that reside in the same region of the hub.

Figure 8 – Connection of the VNet to a hub

Configuring the VPN device on-prem

To configure the VPN on-prem device, you can proceed manually, or if you are using Virtual WAN partner solutions, the configuration of the VPN devices can occur automatically. In the latter case the device controller gets the configuration file from Azure and applies the configuration to devices, avoiding the need to proceed with manual configurations. It all feels very comfortable and effective, saving time. Among the various virtual WAN partners we find: Citrix, Riverbed, 128 Technology, Barracuda, Check Point, NetFoundry and Paloalto. This list is intended to expand soon with more partners.

By selecting Download VPN configuration creates a storage account in the resource group 'microsoft-network-[location]’ from which you can download the configuration for the VPN device on-prem. That storage account can be removed after retrieving the configuration file.

Figure 9 - Download the VPN configuration

Figure 10 – Download the configuration file on the storage account

After configuration of the on-prem device, the site will be connected, as shown in the following figure:

Figure 11 - State of the connected site

It also provides the ability to establish ExpressRoute connections with Virtual WAN, by associating the circuit ExpressRoue to the hub. It also provides for the possibility of having Point-to-Site connections (P2S) towards the virtual Hub. These features are now in preview.

The Health section contains useful information to check the connectivity for each Hub.

Figure 12 – Check Hub health

Conclusions

Virtual WAN is the new Azure service that enables centralized, simple and fast connection of several branch, with each other and with the Microsoft public cloud. This service allows you to get a great experience of connectivity, taking advantage of the Microsoft global network, which can boast of reaching different region around the world, more than any other public cloud providers.