Exposing management endpoints (RDP, SSH, HTTP, and others) over a public IP address is not a good idea. Any kind of management access should be controlled and allowed only over a secure connection. Usually, this is done by connecting to a private network (via S2S or P2S) and accessing resources over private IP addresses. In some situations, this is not easy to achieve. The cause of this can be insufficient local infrastructure, or in some cases, the scenario may be too complex. Fortunately, there are other ways to achieve the same goal. We can safely connect to our resources using Azure Bastion, Azure Virtual WAN, and Azure Private Link.

Create a bastion instance

Azure Bastion allows us to connect securely to our Azure resources without additional infrastructure. All we need is a browser. It is essentially a PaaS service provisioned in our VNet that provides a secure RDP/SSH connection to Azure VMs. The connection is made directly from the Azure Portal over Transport Layer Security (TLS). Using TLS, it provides a secure RDP and SSH connection to all resources on that network. The connection is made through a browser session, and no public IP address is required. This means that we don’t need to expose any of the management ports over a public IP address.

Connect to a VM with bastion

With Azure Bastion, we can connect to a VM through the browser without a public IP address and without exposing it publicly. Azure Bastion uses a subnet in the VNet to connect to VMs in that specific network. It provides a safe connection over TLS and allows a connection to a VM without exposing it over a public IP address.

Hybrid Connection allows us to create secure connections with VNets. These connections can either be from on-premises or from other VNets. Establishing connections to VNets enables the exchange of secure network traffic with other services that are located in different VNets, different subscriptions, or outside Azure (in different clouds or on-premises). Using secure connections removes the need for publicly exposed endpoints that present a potential security risk. This is especially important when we consider management, where opening public endpoints creates a security risk and presents a major issue.

For example, if we consider managing VMs, it’s a common practice to use either Remote Desktop Protocol (RDP) or PowerShell for management. Exposing these ports to public access presents a great risk. A best practice is to disable any kind of public access to such ports and use only access from an internal network for management. In this case, we use either a Site-to-Site or a Point-to-Site connection to enable secure management.

In another scenario, we might need the ability to access a service or a database on another network, either on-premises or via another VNet. Again, exposing these services might present a risk, and we use either Site-to-Site, VNet-to-VNet, or VNet peering to enable such a connection in a secure way.

Most Azure networking components used for security are there to stop unwanted incoming traffic. Whether we use NSGs, ASGs, or a WAF, they all have one single purpose—to stop unwanted traffic from reaching our services. Azure Firewall has similar functionality, including one extension that we can use to stop outbound traffic from leaving the VNet.

Create a firewall

Azure Firewall gives us total control over our traffic. Besides controlling inbound traffic, with Azure Firewall, we can control outbound traffic as well. Azure Firewall uses a set of rules to control outbound traffic. We can either block everything by default and allow only whitelisted traffic, or we can allow everything and block only blacklisted traffic. It’s essentially the central point where we can set network policies, enforce these policies, and monitor network traffic across VNets or even subscriptions. As a firewall as a service, Azure Firewall is a managed service with built-in high availability and scalability.

Configure rules

If we want to allow specific traffic, we must create an allow rule. Rules are applied based on priority level, so a rule will be applied only when there is no other rule with higher priority. An allow rule in Azure Firewall will whitelist specific traffic. If there is a rule that would also block this traffic, the higher-priority rule will be applied.

The deny rule is the most commonly used option with Azure Firewall. An approach where you block everything and allow only whitelisted traffic isn’t very practical, as we may end up adding a great many allow rules. Therefore, the most common approach is to use deny rules to block certain traffic that we want to prevent.

Azure DNS allows us to host Domain Name System (DNS) domains in Azure. When using Azure DNS, we use Microsoft infrastructure for the name resolution, which results in fast and reliable DNS queries. Azure DNS infrastructure uses a vast number of servers to provide great reliability and availability of service. Using anycast networking, each DNS query is answered by the closest available DNS server to provide a quick reply.

Create a DNS zone

To start using Azure DNS, we must first create a DNS zone. A DNS zone holds a DNS record for a specific domain, and it can hold records for a single domain at a time. A DNS zone will hold DNS records for this domain and possible subdomains. DNS name servers are set up to reply to any query on a registered domain and point to a destination.

A DNS zone is required to start using Azure DNS. A new DNS zone is required for each domain we want to host with Azure DNS, as a single DNS zone can hold information for a single domain. After we create a DNS zone, we can add records, record sets, and route tables to a domain hosted with Azure DNS. Using these, we can route traffic and define destinations using a Fully Qualified Domain Name (FQDN) for Azure resources (and other resources as well).

Create a private DNS zone

A private DNS zone operates very similarly to a DNS zone. However, instead of operating on public records, it operates inside a VNet. It is used to resolve custom names and domains inside your Azure VNet. When a VNet is created, a default DNS zone is provided. The default DNS zone uses Azure-provided names, and we must use a private DNS zone to use custom names. A private DNS zone is also required for name resolution across VNets, as default DNS doesn’t support such an option.

Local and virtual network gateways are Virtual Private Network (VPN) gateways that are used to connect to on-premises networks and encrypt all traffic going between a VNet and a local network. Each VNet can have only one virtual network gateway, but one virtual network gateway can be used to configure multiple VPN connections.

Create a local network gateway

When a Site-to-Site connection is created, we have to provide configuration for both sides of the connection—that is, both Azure and on-premises. Although a Local Network Gateway is created in Azure, it represents your local (on-premises) network and holds configuration information on your local network settings. It’s an essential component for creating the VPN connection that is needed to create a Site-to-Site connection between the VNet and the local network.

The local network gateway is used to connect a virtual network gateway to an on-premises network. The virtual network gateway is directly connected to the VNet and has all the relevant Azure VNet information needed to create a VPN connection. On the other hand, a local network gateway holds all the local network information needed to create a VPN connection.