Azure Networking: new features to know to better design network architectures

Cloud solutions evolve very quickly and staying up to date is a key element in innovating and responding effectively to technological changes. With the change of pace imposed by the digital transformation, network infrastructures must also be increasingly efficient, flexible and able to best provide the services required by the company business. To modernize your Azure Networking design and implementation strategy, it is therefore important to evaluate how the various technologies evolve. This article describes the news recently released by Microsoft that may affect Azure networking design, with references to real use cases.

Azure Bastion and VNet peering

Azure Bastion is a PaaS service that provides secure and reliable RDP and SSH access to virtual machines, directly through the Azure portal. Azure Bastion service provisioning is done within an Azure Virtual Network and allows access without having to assign public IP addresses directly to systems.

The news is that Azure Bastion can now work in synergy with Virtual Network (VNet) peering. This means that it is possible to activate Azure Bastion on a specific VNet and the same service can also be used to connect to virtual machines attested on the VNet in peering with this.

Azure Bastion works both in the presence of network peering that connects VNets to the same Azure region, both with VNet peering type Global, that connect VNets located in different Azure regions. From the point of view of network architectures, this possibility opens up new possible scenarios. In the typical and widely used network model, defined hub-and-spoke, you have a virtual network in Azure of Hub which acts as a point of connectivity to the on-premises network and the virtual networks that perform peering with the Hub are definedspoke, useful for isolating workloads. By adopting this model it is possible to activate Azure Bastion on the network of Hub. In this way it will be possible to reach with a single Azure Bastion service also all the virtual machines distributed in the VNets of spoke.

Figure 1 – Azure Bastion in a hub-and-spoke architecture

The following diagram shows the Azure Bastion deployment in a hub-and-spoke network architecture where:

• The Bastion host is activated in the Hub centralized virtual network.
• Communications are allowed, per TCP port 3389 and 22, from the Azure Bastion subnet in the Hub virtual network, to the private IPs of the Spoke virtual networks.
• No public IP is required to access virtual machines.

With this configuration, you can simplify your architecture and reduce Azure costs, as only one Azure Bastion service will be required for the entire hub-and-spoke network topology.

Furthermore, Azure Bastion can also be provisioned in full-mesh network topologies, obtaining the same experience of accessing systems in RDP / SSH for VMs attested on all virtual networks in peering.

Some observations are reported in this regard:

• It is possible to have several Bastion hosts active simultaneously between virtual networks in peering. This can happen particularly during the transition period, when you want to consolidate several Bastion hosts according to the hub-and-spoke topology described above. In the presence of multiple Bastion hosts, when connecting, you will be offered to choose which Bastion host to use.
• Azure Bastion currently supports peered virtual network scenarios only if they reside in subscriptions belonging to the same tenant.

Azure Firewall: new DNS settings

Azure Firewall is the firewall-as-a-service solution (FWaaS) present in Microsoft's public cloud, which allows you to secure the resources present in the Azure Virtual Networks and to govern the related network flows. Azure Firewall features have been enhanced by adding support for custom DNS and DNS proxy.

Custom DNS

By default Azure Firewall uses Azure DNS for name resolution. The ability to configure Azure Firewall to use specific DNS servers has now been included.

In the settings, you can configure a single DNS server or multiple DNS servers:

Azure Firewall can also perform name resolution by using Azure Private DNS. In this scenario it is required that the VNet within which Azure Firewall resides is connected to the Azure Private Zone.

DNS proxy

Azure Firewall can now be configured to play the role of DNS proxy. By enabling this new feature, you can configure the Azure Firewall private IP address as the DNS of the virtual network. In this way all DNS traffic is directed to Azure Firewall, which acts as an intermediary between the systems that make DNS requests and the DNS servers themselves, in this way avoiding possible inconsistencies in name resolutions if custom DNS are used.

When the Azure firewall acts as a DNS proxy, there are two types of caches:

• Positive cache: DNS resolution is successful. In this case Azure Firewall uses TTL (time to live) of the package or object.
• Negative cache: DNS resolution is not successful. In this case, the information is stored in the Azure Firewall cache for one hour.

This feature allows you to evaluate a new usage scenario for Azure Firewall, very useful when you need to manage DNS resolution in the presence of Private link, the mechanism that allows you to establish a private connection to services in Azure.

Each Azure PaaS service that uses Azure Private Link is assigned a mapped FQDN and stored in an Azure Private DNS zone. Requests sent to Azure DNS Private Zones are routed to the platform IP 168.63.129.16, which can only be reached from within the Azure environment. For this reason, if the DNS request originates from on-premises systems (or in any case from outside Azure), it is necessary to activate a DNS proxy within an Azure virtual network connected to the on-premise environment. With this new Azure Firewall DNS proxy feature, you can manage this challenge of name resolution of PaaS servers using Private Link with the following steps:

• The VNet within which Azure Firewall resides is connected to the Azure Private Zone.
• Azure Firewall is configured to use the Azure default DNS and enable the DNS Proxy functionality.
• You configure your local DNS server to conditionally forward requests to Azure Firewall for the requested zone name.

Azure Firewall: using FQDN filtering in network rules

In Azure Firewall Network Rules, you can now use fully qualified domain names (FQDN) based on Azure Firewall DNS resolution. This feature allows you to filter outbound traffic for any protocol TCP / UDP (NTP, SSH, RDP, etc.) and requires the DNS proxy functionality described in the previous paragraph to be active. Azure Firewall, when configured as a DNS proxy, stores all IP addresses resolved by the FQDNs used in the network rules. For this reason it is good practice to use FQDNs in the network rules as a best practice.

Azure Firewall, for both application rules and network rules, converts the FQDN into one or more IP addresses based on the selected DNS server (Azure DNS or custom DNS). When a new DNS resolution occurs, the new IP addresses are added to the firewall rules, IP addresses that are no longer returned by the DNS server have an expiration of 15 minutes. Azure Firewall Network Rules are updated every 15 seconds using DNS resolution. If you need to apply FQDN filters, it is still a good idea to always use the Azure Firewall application rules for HTTP / S or MSSQL protocols, while for all the remaining protocols it is possible to use both the application rules and the network rules.

New features for Azure VPN gateways

Following, are reported the new features that can be adopted in the presence of Azure VPN gateways:

• High availability of RADIUS servers in point-to-site VPNs: this feature allows you to configure high availability for customers who use RADIUS / AD authentication for point-to-site VPNs.
• Custom IPsec/IKE policies with DPD timeouts: the IKE DPD timeout setting (Dead Peer Detection) adjusts the IKE session timeout value based on connection latency and traffic conditions. This configuration is useful for minimizing tunnel disconnections, improving the reliability and user experience.
• APIPA support for BGP speaker: this feature allows you to establish Border Gateway Protocol sessions (BGP), with Azure VPN gateways, using APIPA addresses (169.254.x. x). This feature is especially useful for customers with legacy VPN routers, Amazon Web Service (AWS) VGW, Google Cloud Platform (GCP) VPN that use APIPA addresses (Automatic Private IP Addressing) to announce BGP addresses.
• FQDN support for site-to-site VPNs: this feature allows you to configure site-to-site VPN in the presence of devices that do not have static public IP addresses to connect to Azure VPN gateways. It is in fact possible to use the fully qualified domain name (FQDN) instead of IP addresses. Azure VPN gateway will be able to do DNS name resolution, automatically updating the destination to establish the VPN's IPsec / IKE connections.
• Session management and user revocation for point-to-site VPNs: the ability to list and revoke individual user connections to VPN gateways is given, directly from the Azure portal and in real time.

Conclusions

There are several innovations recently released by Microsoft in Azure networking and it is advisable to carefully evaluate them to make an accurate design. In this way it will be possible to realize effective network architectures, optimizing costs and able to exploit all the potential offered by the Azure platform.