Linux Training in Coimbatore & Best Linux Server Administration Training Institute NUX SOFTWARE SOLUTIONS FREE DEMO CLASSES AVAILABLE Call us 096263 53489
Create a virtual network and an Azure Bastion host
The following procedure creates a virtual network with a resource subnet, an Azure Bastion subnet, and a Bastion host:
In the portal, search for and select Virtual networks.
On the Virtual networks page, select + Create.
On the Basics tab of Create virtual network, enter, or select the following information:
Setting
Value
Project details
Subscription
Select your subscription.
Resource group
Select Create new. Enter test-rg for the name. Select OK.
Instance details
Name
Enter vnet-1.
Region
Select East US 2.
Select Next to proceed to the Security tab.
In the Azure Bastion section, select Enable Bastion.
Bastion uses your browser to connect to VMs in your virtual network over Secure Shell (SSH) or Remote Desktop Protocol (RDP) by using their private IP addresses. The VMs don't need public IP addresses, client software, or special configuration. For more information, see What is Azure Bastion?.
Note
Hourly pricing starts from the moment that Bastion is deployed, regardless of outbound data usage. For more information, see Pricing and SKUs. If you're deploying Bastion as part of a tutorial or test, we recommend that you delete this resource after you finish using it.
In Azure Bastion, enter or select the following information:
Setting
Value
Azure Bastion host name
Enter bastion.
Azure Bastion public IP address
Select Create a public IP address. Enter public-ip-bastion in Name. Select OK.
Select Next to proceed to the IP Addresses tab.
In the address space box in Subnets, select the default subnet.
In Edit subnet, enter or select the following information:
Setting
Value
Subnet purpose
Leave the default of Default.
Name
Enter subnet-1.
IPv4
IPv4 address range
Leave the default of 10.0.0.0/16.
Starting address
Leave the default of 10.0.0.0.
Size
Leave the default of /24 (256 addresses).
Select Save.
Select Review + create at the bottom of the window. When validation passes, select Create.
Repeat the previous steps to create a second virtual network with the following values:
Setting
Value
Name
vnet-2
Address space
10.1.0.0/16
Resource group
test-rg
Subnet name
subnet-1
Subnet address range
10.1.0.0/24
Create virtual network peer
Use the following steps to create a two way network peer between vnet1 and vnet2.
In the search box at the top of the portal, enter Virtual network. Select Virtual networks in the search results.
Select vnet-1.
In Settings select Peerings.
Select + Add.
Enter or select the following information in Add peering:
Setting
Value
Remote virtual network summary
Peering link name
Enter vnet-2-to-vnet-1.
Virtual network deployment model
Leave the default of Resource Manager.
Subscription
Select your subscription.
Virtual network
Select vnet-2.
Remote virtual network peering settings
Allow 'vnet-2' to access 'vnet-1'
Leave the default of selected.
Allow 'vnet-2' to receive forwarded traffic from 'vnet-1'
Select the checkbox.
Allow gateway or route server in 'vnet-2' to forward traffic to 'vnet-1'
Leave the default of cleared.
Enable 'vnet-2' to use 'vnet-1's' remote gateway or route server
Leave the default of cleared.
Local virtual network peering summary
Peering link name
Enter vnet-1-to-vnet-2.
Local virtual network peering settings
Allow 'vnet-1' to access 'vnet-2'
Leave the default of selected.
Allow 'vnet-1' to receive forwarded traffic from 'vnet-2'
Select the checkbox.
Allow gateway or route server in 'vnet-1' to forward traffic to 'vnet-2'
Leave the default of cleared.
Enable 'vnet-1' to use 'vnet-2's' remote gateway or route server
You can troubleshoot most Azure VM connectivity issues by checking its components and configurations.
Azure virtual network — This is the foundation for your private network in Azure. It provides an isolated network environment to run VMs, letting you control traffic flow and implement network-level security measures.
If you place a VM in the wrong virtual network, it may hinder connectivity. The VM may be unable to access necessary resources, exposing itself to unnecessary traffic.
Network security groups (NSGs) — An NSG contains security rules to filter the Azure VM’s inbound and outbound traffic. You can configure these rules to filter inbound and outbound traffic-based parameters like the source and destination IP addresses, ports, and protocols.
When troubleshooting your connection issues, verify that the NSG rules allow the necessary traffic for your VM. For example, if there’s a blocked connection on port 80, check if an NSG rule is denying the connection.
Network interface card (NIC) — An NIC contains the public and private IP of the Azure VM and bridges the VM and its virtual network. It lets the VMs securely communicate with each other, additional Azure resources, the Internet, and on-premises resources.
Associating a NIC to the correct virtual network ensures the VM obtains the correct IP address and connects to the network successfully.
Azure managed disks — These managed disks are block-level storage areas that Azure automatically manages. You only need to select the disk size and type and provision the disk, while Azure creates the disk and handles scaling and maintenance.
A managed disk’s performance can affect connectivity. For instance, slow disk read and writes can impact a VM’s ability to process network traffic. Misconfigured OS disk firewalls might restrict incoming traffic, denying a connection.
CPU and memory resources — High consumption of resources can negatively impact VM connectivity. A VM consuming plenty of processing power and memory might struggle to process network traffic. It may also become unresponsive, causing a connection loss.
Your operational efficiency and user experience may decline when misconfigured NSG rules, incorrect firewall settings, NIC issues, resource exhaustion, and other issues go unaddressed. Connectivity disruptions, downtime, and unreliable access to Azure VMs can lead to reduced productivity and revenue loss.
The upcoming sections review connectivity issues and demonstrate how to troubleshoot them. To follow along, ensure you have the following:
An active Azure resource. This guide uses a pay-as-you-go subscription and a Windows server Azure VM.
Windows PowerShell
Misconfigured network security group (NSG) rules
Misconfigured NSG rules can cause unexpected connectivity problems. They can occur when you erroneously set up inbound or outbound rules to block desired traffic or allow unintended access.
Suppose you have an Azure VM hosting a web server and want to ensure users can access your site from a browser. However, you discover that the connection is blocked, potentially driving away users who can’t connect.
To address this connectivity issue, grant users access to the site from the browser by creating an NSG rule to allow inbound HTTP traffic to your VM. The section below demonstrates how to do so.
Note that allowing HTTP traffic to your VM is just one use case for NSG rules. These rules also control access to your VM by letting you restrict traffic to and from specific sources. When you implement precise NSG rules that permit only the necessary traffic, you can secure your Azure VMs effectively.
Start the troubleshooting process by checking the current security rules associated with your VM using the steps below. Note that this process might vary depending on your use case and the rule you want to create. You may need to modify the rule’s properties to meet your security requirements.
First, open the Azure Portal and sign in to your account. Then, in the search box at the top, type “Network Security Groups.” In the Services section, select Network security groups. This action lists all the NSGs and their associated resource groups and subscriptions.
Fig. 1: Searching for network security groups
From the list, click the NSG associated with your VM.
Fig. 2: List of network security groups
Then, to check your VM’s NSG, click the Networking tab on your VM’s dashboard.
In the dashboard’s sidebar, click Inbound security rules under Settings to view all the NSG rules for inbound traffic.
Fig. 3: Inbound security rules for a VM
This VM has a default rule named DenyAllInBound that denies all inbound traffic from outside the virtual network. This traffic may come from the Internet, other VMs, or other Azure resources. This rule isn't problematic if the VM doesn’t need to receive any data from outside networks. However, if it does, the rule becomes an obstacle by denying connectivity, affecting the VM’s performance.
Because DenyAllInbound is a default rule, you can’t delete it. However, you can override it by adding a new rule with a lower priority number. The lower the number, the higher the priority, and the earlier the VM will process that rule.
To add the new rule that allows inbound traffic from the Internet, click + Add at the top of the NSG inbound security rules dashboard. You should see a form similar to the image below.
Fig. 4: Add inbound security rules
Fill in the form as follows:
Source: Service tag — A service tag is a predefined identifier for a category of IP addresses. Microsoft manages and automatically updates a service tag’s address as it changes. If you want more control or the available service tags don’t meet your needs, specify a source, such as an IP range or application security group from which you want to allow traffic.
Source service tag: Internet — This option selects the IP address space outside the virtual network that the public Internet can reach. Depending on your needs, you can choose other service tags, including Storage and Power BI, for traffic from Azure Storage and Microsoft Power BI, respectively.
Source port ranges: * — This option specifies which ports allow Internet-based traffic for this rule. Using * allows all port numbers.
Destination: Any — You can also use a predefined service tag, IP address, or application security group to restrict the destination port ranges.
Service: HTTPS — Choosing HTTPS allows Azure to automatically select TCP as the protocol and the destination port range as 443.
Action: Allow — This option permits traffic.
Priority number: 300 — Assigning the rule a priority number of 300 overrides the DenyAllInbound rule, which is priority 65500. You can’t have two rules with the same priority number—they must be unique.
Name: AllowTagHTTPSInbound — This field is the rule’s name.
Finally, click Add to create the rule.
You can now establish a connection from the Internet to the Azure VM.
The above steps outline adding, reviewing, and modifying an NSG rule to allow inbound HTTP traffic. Note that it’s just one of many troubleshooting use cases for NSG rules. For example, you may want to limit inbound Secure Shell Protocol (SSH) access to specific IP addresses to secure the VM. Additionally, if you have segmented your virtual network into subnets, you can apply NSG rules to a particular subnet to control the traffic there.
Operating System (OS) firewall issues
Firewall settings at the OS level can interfere with Azure VM connectivity. For instance, an overzealous inbound rule could block necessary traffic.
To resolve this issue, inspect your current firewall settings from the command line and modify the rule to allow the necessary traffic. Start by connecting to the Azure VM via Remote Desktop Protocol (RDP), SSH, or Bastion.
This demonstration uses RDP to connect to a Windows VM. First, click Connect in the Azure Portal, then download the RDP file. Next, open the file to connect to the Azure VM. This action prompts you to enter the username and password you provided when you created the VM. The username should follow the vmname/username format.
From your Windows OS start menu, run Windows PowerShell as an administrator, then run the following command to check the current firewall configuration.
Get-NetFirewallProfile -Name Public
This command displays the firewall configuration for the public network profile, including the enabled state (set to on or off), the inbound and outbound rules, and other settings for actions like logging.
Fig. 5: Firewall configuration for a public network profile of an Azure Windows VM
To enable the firewall, use the following command.
Set-NetFirewallProfile -Profile Public -Enabled True
To turn off the firewall, run the following command.
Set-NetFirewallProfile -Profile Public -Enabled False
Although you can turn off the firewall, it's best to keep it enabled for security and instead allow or block specific ports. For example, use the following command to allow traffic on port 80 for incoming HTTP traffic.
You should output similar to the following image with the details of the new rule.
Fig. 6: New firewall rule added to a Windows VM
Here’s what each part of the command does:
DisplayName 'Allow-HTTP-Inbound' — This command specifies the name of the rule you’re creating. In this example, it’s Allow-HTTP-Inbound.
Profile @('Domain', 'Private') — This command specifies the network profiles the rule applies to—in this case, the Domain and Private profiles.
Direction Inbound — This command specifies the traffic direction the rule applies to. Here, Inbound refers to incoming traffic.
Action Allow — This command specifies the action on traffic that matches the rule. In this case, the action is to allow the traffic.
protocol=TCP — This command specifies the protocol for the traffic the rule applies to. Here, it applies to TCP traffic. You can select other protocols, such as UDP or ICMP.
Localport=80 — This command specifies the rule’s local port.
If you want to remove a rule that’s restricting access, use the Remove-NetFirewallRule cmdlet command and specify the rule’s name, like below.
Executing this command removes the restriction on port 80, letting you connect to the VM successfully.
If you’re using a Linux Azure VM, start by checking the firewall status using Uncomplicated Firewall (ufw), a tool that simplifies working with firewall rules in Linux.
The example below uses an Ubuntu 20.04 Linux VM. Ubuntu has UFW installed by default.
To troubleshoot the firewall rules, run the command given below on the terminal to check if the firewall is enabled.
sudo ufw status
The output of this command is either active if the firewall is enabled or inactive if disabled. If it’s inactive, enable the firewall using the command below.
sudo ufw enable
For security purposes, it’s better to allow all outgoing traffic and deny all incoming traffic. Do so using the following commands.
sudo ufw default allow outgoing
sudo ufw default deny incoming
Run the following command to allow incoming traffic on a specific port, such as HTTP traffic on port 80.
sudo ufw allow port 80
Then, check whether you successfully added the rule using the following command.
sudo ufw status verbose
You should see an output similar to the image below, with To “80”, Action “ALLOW IN”, and From “Anywhere.”
Fig. 7: Verbose status of an Ubuntu firewall
To deny a connection on port 80, run the following command.
sudo ufw deny 80
To delete this rule, run the following command.
sudo ufw delete deny 80
For a secure system, configure the OS firewall rules to allow only the incoming connections your VM needs and deny any unnecessary ones.
Problems with the network interface card (NIC)
A NIC allows your VM to communicate with other networks, so if it has issues, your connection breaks down.
Azure Network Watcher can diagnose these issues via several tools to monitor, analyze, and debug connectivity problems. To troubleshoot issues with the NIC, use a tool like IP flow verify to detect traffic filtering issues at the VM level. The tool checks whether a packet is allowed to or from an IP address and tells you which rule allowed or denied it.
To use Azure Network Watcher, go to the Azure Portal and select Network Watcher on the overview page. Under Network diagnostic tools, select IP flow verify from the sidebar. Azure Network Watcher’s IP flow verify feature will confirm if a rule in your NSG blocks traffic to or from your VM.
On the IP flow verify page, fill in the required details:
Virtual machine — The target VM you want to test.
Network interface — The target VM’s network interface. If you used the Azure portal to create the VM, the portal names the network interface for you.
The protocol — Select the protocol the traffic uses. For this example, choose TCP.
Direction — Select the traffic’s direction, outbound or inbound. For incoming traffic, select inbound.
Local port — For this demonstration, select 6000.
Remote IP address — This is the traffic source’s IP address. Enter 102.217.126.3, the public IP address of a physical machine.
Remote port — Select port 80 for HTTP traffic.
Now, click Verify IP flow to check if an NSG rule is blocking the traffic.
The results (in the following image) indicate that traffic isn’t allowed from 102.217.126.3 because of the DenyAllInBound security rule.
Fig. 8: IP flow verify results
To fix this issue, add a new NSG rule with a lower priority number that allows inbound traffic from this IP address on port 80.
Start by installing the Azure PowerShell module using the following command.
Install-Module -Name Az
If it’s your first time installing a module from PowerShell Gallery, it prompts you to allow the installation. Select yes or yes to all to continue.
Then, sign in to your Azure account using the command below.
Connect-AzAccount -UseDeviceAuthentication
The tool you need is Test-AzNetworkWatcherIPFlow, which tells you if a packet is allowed or denied to or from a particular destination.
First, retrieve the Network Watcher resource using the command below.
Now, use the following command to verify the IP flow for HTTP traffic using the first IP from the first network interface for inbound traffic on port 80.
In this case, the result shows that access is denied for all inbound traffic. You can add a new NSG rule with a lower priority number to allow traffic.
Azure VM resource exhaustion
Resource exhaustion, a result of depleting CPU, memory, or disk space, can lead to Azure VM connectivity issues. Azure’s built-in diagnostic tools help identify if your VM is suffering from resource exhaustion, allowing you to take remedial action, such as resizing the VM or reducing the workload.
To perform the diagnosis, go to the Azure portal and select Virtual Machines. Then, select the VM you’d like to check.
In the Help section, select Performance diagnostics, then click Install performance diagnostics. After it finishes installing, click Run diagnostics. This action presents four options: quick performance analysis, performance analysis, advanced performance analysis, and Azure files analysis.
Fig. 9: Running diagnostics on an Azure VM
Each option analyzes the VM at a different level. For this demonstration, select the performance analysis, which monitors high resource consumption—including high CPU and memory usage. Select the analysis’ duration. The longer you specify, the larger the output file’s size.
Click OK to start the analysis. Then, open the generated report, which should look similar to the image below.
