Category: Azure

Azure Network Security Groups (NSGs) can be complex to configure and troubleshoot. We will try to explain how they work, what components they consist of, and how to manage them.

Microsoft Certified Azure Administrator Associate Exam (AZ-104) expects good knowledge of the topics in the list below.

• create security rules
• associate an NSG to a subnet or network interface
• evaluate effective security rules

The exam groups these topics under “Secure access to virtual networks” section along with Azure Bastion and Azure Firewall, which we will not cover in this article.

This blog post provides an overview of Azure security concepts such as NSGs and security rules, as well as practical step-by-step examples of how to implement and validate their configuration.

Network Security Groups and Security Rules

An administrator can protect Azure resources by applying a Network Security Group (NSG) to a network interface or a subnet.

Figure 1 shows components of a Network Security Group.

Each security rule consists of the following fields:

• Rule name and description
• Priority number, which defines a position of the rule in the ruleset. Rules on the top are processed first, therefore, the smaller number has a higher preference
• Source and destination with port numbers (for TCP and UDP)
• IP protocol type, such as TCP, UDP, and ICMP. These 3 protocols cover almost all application requirements. “Any” keyword permits all IP protocols

A Network Security Group can be applied to a network interface and to a Subnet. Applying an NSG to a Subnet simplifies the rule management if all VMs in the subnet requires the same security rules.

There is a common incorrect understanding that Subnet-level NSGs work as ACLs on a default gateway device (such as a switch or a firewall) in a traditional network, which protects traffic as it enters subnet and doesn’t check connectivity within a subnet. Subnet level NSGs should be treated as a template mechanism, they do affect traffic between VMs in the same subnet.

If no NSG is applied, then all traffic is allowed to and from a virtual machine.

Microsoft recommends applying an NSG to either interface or subnet, but not to both.

As the diagram above shows, a single NSG can associate with multiple network interfaces and subnets. Each network interface or subnet can have 0 or 1 NSGs associated with it.

Inbound vs Outbound

An NSG contains two ordered lists of Security Rules – inbound and outbound.

NSG ruleset direction is evaluated from a VM perspective. For example, rules in inbound direction affect traffic that is being initiated from external sources, such as the Internet or another VM, to a virtual machine. Outbound security rules affect traffic sent from a VM.

Return traffic for an established session is automatically allowed and is not validated against rules in the reverse direction. So we only need to focus on allowing (or denying) client-to-server direction of the session.

Default Security Rules

There are 6 default inbound (3) and outbound (3) rules that exist in each NSG. They cannot be removed or edited. An administrator can create custom rules to override the default ones.

Figure 2 extends the conceptual diagram shown in Figure 1 by adding the default rules. In addition to custom rules that users can define shown on the left side, the additional 3 rules can be seen.

The first default rule with priority (or sequence number) of 65000 allows internal communication. It permits the traffic with the source and destination IP prefixes identified by a service tag called VirtualNetwork.

VirtualNetwork service tag includes IP addresses of:

• Local VNet address space
• Peered VNets’ address space (configurable, see this link for details)
• Address space of VNets connected to Virtual Network Gateway
• User-defined routes
• On-premises address spaces
• and a default route (this can make NSG become “permit any” if, for example, the default route is advertised from the on-premises network)

The second rule in inbound security ruleset allows access from Azure Load Balancer to any destination. In the outbound security ruleset, the rule with the same sequence number of 65001 allows unrestricted access to the Internet.

The very last default rule in both inbound and outbound rulesets is the “Deny all” rule. It means that if there are no “allow” rules that match the specific traffic, it will be dropped.

Evaluation Order

A packet is compared sequentially against each security rule until the first match is found. The further rules are not processed and the action in the matching rule is applied.

If an NSG is applied to a subnet and another one to a network interface, then both NSGs are processed. Subnet NSG is processed first. If a packet hits deny rule, including the default “Deny Any” rule, then the packet is dropped straight away. If the packet is allowed by subnet NSG, then the network interface’s NSG is evaluated.

NSG and Security Rules Step-by-Step Configuration

To create a Network Security Group start typing “network security” in the search bar and select Network security groups in the list of Azure services.

Create a new NSG

In the Network Security Groups window, press Add to create an NSG. Select a Resource Group and a name for NSG and press Review + Create button, as shown in Figure 3.

Once NSG is created, it will appear in the list shown in the upper part of Figure 3. Click on NSG to display its properties. As the screenshot below shows, the overview window of NSG-A provides summary information, as well as inbound and outbound security rule content.

NSG configuration menu provides access to:

1. Inbound security rules management
2. Outbound security rules management
3. Network interfaces to create an association with the NSG. This operation can also be performed via Network interface configuration pages
4. Subnets to create an association with the NSG. This operation can also be performed via VNet > Subnet menu configuration
5. Effective security rules display

Modify Security Rules in NSG

During VM provisioning new NSG can be automatically created with the common management ports, such as RDP and SSH, as shown in Figure 5.

For this example, let’s assume that an administrator didn’t select any of the ports and we cannot connect to the VM remotely. To address this issue we will use NSG created in the previous step, allow RDP, and associate the NSG with the VM’s NIC.

To add a new inbound security rule, click on the menu (#1). Then press Add (#2). Fill the information, as shown in the screenshot below, and press Add.

Associate NSG with a Network Interface

In the next step, we will associate the NSG with the network interface of the VM, as shown in Figure 7. To enable this, within the NSG configuration window, click on the Network interfaces side menu (#1) and press the Associate button (#2) and select the network interface.

In some cases, the network interface will be greyed out. If this is the case, the configuration can be performed from the Network Interface configuration window. Navigate to the network interfaces list and select the one that you want to change NSG for. Choose the Network security group menu (#1) and select choose the NSG that we created earlier.

Associate NSG with a Subnet

As with the Network Adapter association, the configuration can be performed via the properties of NSG or from the Subnet configuration page. To associate with a subnet via NSG properties, open Subnets menu and click on Associate and then select the virtual network and the subnet as shown in Figure 9.

In this example, we have an NSG called NSG-A-SUBNET created earlier, which we will associate with the subnet.

To perform the same procedure using Subnet properties, navigate to the subnet configuration page via its parent VNet. Then select a Network security group drop-down box and choose the NSG.

View Effective Security Rules

Azure Network Interface properties have a button called “Effective security rules”. To be able to display this page the virtual machine that has the interface attached must be powered on.

The opened window doesn’t display rules correctly currently, as shown in Figure 11. For example, we have RDP port opened inbound on both network interface and subnet level, which is not shown in the list of rules.

This page, however, allows us to download ruleset in CSV format, so an administrator can use Excel or some automation tool to analyze it. As shown in Figure 11, we can see our RDP rules, as well as expanded service tags. For example, we can see which IP addresses are included in the Virtual Network service tag.

The other way to check what rules are currently applied at different levels is to use the Networking properties of a VM, as shown in Figure 12. Notice how this page correctly displays subnet-level and network interface-level rules.

Recommended Links

See our other posts on Azure networking:

Implement and Manage Virtual Networking

Azure VNet Route Selection

Self-Test Questions

In this blog post, we continue the discovery of virtual networking in Microsoft Azure including in-depth coverage of VNet route tables, subnets, and the process of route selection.

Microsoft Azure Administrator Associate Exam (AZ-104) includes these topics in its blueprint:

• configure private and public IP addresses, network routes, network interface, subnets, and virtual network
• create and configure VNet peering

We covered basic concepts listed in the first bullet point in the previous article.

This article starts with discussing VNet peering and then dives into additional topics not covered in the first part of the article, such as Azure route tables, network routes, and best route selection process.

VNet Peering

VNet peering connects two VNets together, so resources, such as virtual machines deployed in different networks can communicate with each other. VNet peering provides high-speed, private connectivity using Microsoft backbone.

The peering VNets can be in the same or different regions. If VNets are in the same region, the communication performance between VMs via VNet peering matches the speed and latency of Intra-VNet connectivity.

VNet peering is configured by the provisioning of a peering link in each of the VNets. If VNets are under the same account, the second link can be automatically created. In all other cases, each side needs to be provisioned separately using Resource IDs of the peer VNet. In the lab section, we will demonstrate both options.

For the practical part of this blog post, we will use the lab topology shown in Figure 1.

Create VNet Peering Step-by-Step

Let’s start this example by creating 2 sets of VNets and subnets. Both VNets will be under the same subscription and in the same region. The detailed procedure on how to create a VNet is available here.

To create a peering open one of the created VNets and select Peerings in the side menu and click Add.

On the “Add peering” page we configured the following settings:

1. Descriptive name of the peering link on the source VNet side. This is the VNet-A that we selected in the previous screenshot.
2. Peering virtual network using a drop-down box to select VNET-B, which is accessible from our account.
3. A descriptive name for the peering that will be automatically added to the target VNet.

To create a peering to VNet that is not in our account, select a checkbox called “I know my resource ID”. Then, instead of Steps 2 and 3, enter the resource ID of the partner VNet. The operation must be repeated in the peering VNet.

To get the Resource ID of a VNet, navigate to the Properties menu and press the copy to clipboard button next to Resource ID field.

Once peering links are created we can navigate to VNET-A and to VNET-B to validate settings on each side. The screenshot in Figure 5 shows the information on peering status and provisioned state and address space behind the peer. The page also has several configurable parameters.

Virtual network access setting controls if the IP range of a peer is classified as a VirtualNetwork service tag. Both inbound and outbound traffic is allowed between the networks with this tag.

Forwarded traffic, if enabled, permits entry of the traffic that is not originated in the peer VNet. Such traffic usually comes via VPN or ExpressRoute Gateways in the peer VNet. This setting is often used with combination with other two checkboxes:

• Allow gateway transit
• Use remote gateway

Allow gateway transit allows the peer to use the local VNet’s gateways. Such peering VNet must have “Use remote gateway” checkbox enabled on the peering toward the VNet containing a gateway.

Deploy VMs and Testing

Let’s deploy VMs into corresponding VNets and Subnets according to Figure 1. Use this article for information on how to do it.

Let’s validate IP address of VM-A by running Windows ipconfig command.

Let’s test that we can ping the VM-B from VM-A. To make this test work we had to disable Windows Firewall on VM-B. In the production environment, it is recommended to keep Windows Firewall enabled, and create a specific rule that allows ICMP through.

Notice that the traceroute doesn’t display any hops between two VMs. This is related to how Azure operates on the back-end. It is different from how packet forwarding works in the traditional data center, where traceroute displays a default gateway as the first hop.

Let’s check Azure VMs security rules and effective routes. Click on the Networking menu of the VM-A. The displayed window has tabs for Inbound and Outbound port rules. They are applied via the Network security group to the network interface, which we will cover in one of the future articles.

In the default configuration, both Inbound and Outbound security rules include a rule (#65000) that allows traffic with the source and destination tagged with VirtualNetwork.

As we discussed earlier, peering’s Access Control Setting checkbox, if enabled, classifies IPs in the peering VNet as part of VirtualNetwork. This effectively allows the traffic to be allowed on Azure level. Guest OS configuration is still required to allow the traffic in.

Click on the Network Interface name to proceed to the next step, red rectangle #2 in Figure 8.

Once the Network interfaces window opens, click on the Effective routes menu, as shown in Figure 9. The routing table has a route to 10.1.0.0/16 with the next hop type of VNet peering.

Routes and route tables

When you create a subnet, it has a default implicit route table associated with it. The Azure portal will not display such tables, and an administrator cannot add custom routes into them. The default route tables contain only system routes, which are automatically added by Azure.

To define a custom route an administrator must create a custom route table and associate it with the subnet. The custom route table will also have automatically added system routes, but these routes can be overridden.

To display routes, use the Effective routes tab of a network adapter, as described in the previous section, and shown in Figure 9. The system routes have Default as their source.

Figure 10 shows a conceptual diagram of relationships between subnets and route tables. Each subnet can have one route table associated with it. A route table, however, can be associated with multiple subnets at the same time.

(Mandatory) Default System Routes

Azure populates every route table, including the custom route tables, with the following routes.

Route	Next hop type	Comments
Local VNet's address space	Virtual network	In our example, 10.0.0.0/16 for subnets in VNET-A and 10.1.0.0/16 in VNET-B. Note that no subnet-specific routes are created
0.0.0.0/0	Internet	Default route points to Internet. Traffic to Azure public services uses this route, however, it doesn't traverse Internet and stays within Microsoft Azure network
10.0.0.0/8	None	Private RFC 1918 range
100.64.0.0/10	None	Similar to RFC 1918 ranges (reserved for Shared Address Space, see RFC 6598)
192.168.0.0/16	None	Private RFC 1918 range

Table 1. Mandatory Azure System Routes

The default system routes from Table 1 ensure that there is communication within VNet and all traffic is sent to the Internet, with the exception of private address space. Traffic to 3 private ranges is basically discarded.

Interestingly, 172.16.0.0/12 (also part of Private RFC 1918 range) is not among the default null routes. Traffic to this range matches 0.0.0.0/0 and sent to the Internet next hop. It is not routable on the Internet, so it should be discarded somewhere upstream.

(Optional) Default System Routes

Certain routes are only added by Azure into route tables when there is a specific configuration is enabled. For example, in Figure 9 route to a peered VNet was automatically added by Azure. Table 2 lists such routes that can appear in a route table.

Route	Next hop type	Comments
Peered VNet's CIDR block	VNet Peering	Created in route tables of every subnet of a VNet
Public IP addresses of Azure Services	VirtualNetworkServiceEndpoint	Created only in a route table of the subnet that has service endpoint enabled

Table 2. Optional Azure System Routes

Network Gateway Propagated Routes

Figure 11 shows a sample topology with a Virtual Network Gateway.

Virtual Network Gateways provide connectivity to on-premises and external networks connected over VPN or ExpressRoute. The routes to remote networks can (with ExpressRoute gateways – must) be exchanged using Border Gateway Protocol (BGP).

A gateway propagates this information by installing learned routes into route tables. The next-hop type in this case is set to Virtual network gateway.

 The propagation is enabled by default, and can be disabled for custom route table using a setting called “Virtual network gateway route propagation”.

Custom Routes

In addition to Network Gateway Propagated routes, an administrator can manually create custom ones. Custom routes are preferred in Azure VNet Route Selection Process. We will discuss this in detail in one of the sections below.

To perform this operation a route table must be first created and associated with a subnet. We will demonstrate how to do it in the practical part of this section.

A custom route is identified by its name and requires address prefix and next-hop type to be selected. There are 5 types of next-hops available for Azure custom route:

• Virtual network gateway
• Virtual network
• Internet
• Virtual appliance
• None

Virtual network gateway next-hop type can be used only for VPN gateways. ExpressRoute must use BGP-based network propagation, so no custom routes can be created to use ExpressRoute Gateway. Notice that there is also no VNet Peering type of the next-hop, which can be created only by Azure. You can, however, create a route that will be pointing to Virtual appliance with Next-hop IP in a peered VNet.

Virtual network next-hop type is used in topologies when you want to make traffic flowing between subnets within a single VNet to go via the virtual appliance. For example, traffic from one subnet to another within a VNet by default is routed via the default system route as discussed in the system routes section. You can override this by selecting the next hop as a virtual appliance. To keep direct traffic flow within the subnet, you can create a custom route with the next hop of the virtual network for the subnet prefix.

Internet next-hop can be used in situations when the default route is overridden and, for example, is sent to the on-premises network to use corporate Internet breakout. To send a subset of traffic via Azure Internet, you create a route for a specific prefix to go via Azure Internet.

Virtual appliance next-hop type requires specifying an IP address of the appliance which will receive traffic. Useful for introducing firewalls and traffic analysis devices.

None next-hop type drops the matching traffic.

Create a Custom Route Table Step-by-Step

Start typing in “route table” in Microsoft Azure search bar and click on Route tables service. Click on the Add button to create a route table. Fill-in required parameters, including route table name, resource group, and press Create.

As the next step, we will associate the created route table with Subnet A. Click on the newly created route table and then on the Subnets button on the side menu. Click on the associate button and select the VNet and the Subnet. After this step, SUBNET-A-123 will have a default implicit route table replaced with the custom one.

At this stage, the content of the new custom route table will be exactly the same as the routes in the implicit route table. Let’s create a custom route by pressing the Routes button on the side menu and then clicking Add.

We will create a test route that will discard any packets sent to the Google DNS server IP address of 8.8.8.8/32. To accomplish this, select None as the Next hop type. There are also different types of next-hop types available as we discussed in the theory section.

Once we press ok, let’s validate that the route was added and we can also confirm from the virtual machine if the connectivity to 8.8.8.8 no longer works. To validate routes in the custom table, we can use Effective routes accessible via network interface menu or route table menu directly. To display routes via both options, we need to have a network interface attached to a powered-on VM in a subnet that the route table associated with.

The next screenshot shows that connectivity to 8.8.8.8/32 no longer works after we applied a custom route to None.

Azure Best Route Selection Process

The final topic of this article is how the best matching route is selected in Azure.

The route selection is intuitive if you follow the rule of not advertising more specific (or the same length) routes that are used in Azure using BGP from an on-premises network or remote VPN networks. If this restriction is maintained, the route selection can be summarized as the following list with the preferred conditions on the top:

1. Longest match

2. User-defined routes

3. BGP-derived

4. System routes

Condition is violated if a network gateway injects via BGP a network that is more specific than (or the same as) VNet address space or a peered VNet prefix. In this case, the routes with the next-hop type of Virtual Network or VNet Peering are preferred over more specific BGP routes. We recommend to design network, so prefixes from Azure VNet address space is not used anywhere else on the network. As a workaround in migration scenarios, remote networks can be network address translated (NAT-ed) to the non-overlapping range.

Let’s consider a few simple examples with 2 Azure VNets with the address prefixes of 10.0.0.0/16 and 10.1.0.0/16. All other networks do not overlap with VNets’ address spaces.

To identify the best route for a specific destination there are several steps, with each minimizing number of candidate routes to select from. Once a single route is left the process stops and this route is used.

In the diagram below, a packet with the destination of 10.1.0.20 matches 3 routes of different lengths. The most specific route (with the longest prefix length of /16) is selected.

The next example shows a packet with a destination of 10.30.1.34. After selecting all matching candidates, we have 4 routes left. In the second step, we keep only the longest prefix routes (/24). Out of two remaining routes, we know that user-defined routes are more preferred. The single route that points to a virtual appliance with an IP address of 10.0.0.100 is used to forward the traffic.

The final example is for a packet with the destination of 192.168.1.100. There are 2 routes left after step 2 with the same length. As BGP routes are preferred over system routes, the packet will be sent to a Virtual network gateway.

Self-Test Questions

In this blog post, we will explore the basics of Azure Virtual Networking. The target audience of this article is the candidates preparing for the Microsoft Azure Administrator Associate exam (AZ-104).

The exam topic comprises of 2 objectives:

• configure private and public IP addresses, network routes, network interface, subnets, and virtual network
• create and configure VNet peering

In this post, we will review only basic network configuration, which partially covers the first bullet point. The rest will be covered in the follow-up articles.

Azure Virtual Networking Basics

Figure 1 demonstrates how different components are working together. In the practical section of this blog post, we will go through the process of creating every element shown in this diagram.

Virtual Network (VNet)

Virtual Network (VNet) is an isolated virtual network environment within the Microsoft Azure cloud. VNETs provide connectivity to other Azure resources, the Internet, and the on-premises network.

A virtual network is scoped to a specific region and subscription. It is identified by a name and has one or many address spaces assigned (IPv4 CIDR block).

Subnets

An administrator can create one or multiple subnets within a single VNet. In the diagram above, a VNet named “vnet_dev_east_us” contains a subnet called “subnet_web_servers”. IP address prefix of a subnet is part of the larger VNet’s prefix.

Virtual Machines and Network Interfaces

Virtual machines can connect to a VNet and a subnet sharing the same region and subscription. Each virtual machine can have one or multiple network interfaces. A network interface is a virtual adapter that connects VM to a subnet.

A network interface is created automatically during VM provisioning. Network interfaces can be detached from VM and it is also possible to create a standalone network interface and attach it to a VM after its creation.

IP Configuration

Both private and public IP addresses are allocated to a network interface using IP configuration. Each IP configuration must have a private IPv4 address and optionally public IPv4 address assigned.

Additional IP configurations provide the ability to add multiple IP addresses to the interface. These IP addresses share the same subnet with the primary IP address.

Private IPs

An IP configuration of a network interface can have a static or a dynamically assigned private IP address in the Azure portal. The dynamic IP address should be used in scenarios when it is acceptable not to have a pre-defined IP address for a VM.

Setting up a static IP address ensures that the VM will be reachable using a pre-defined IP address. The setting in the Azure portal doesn’t enforce dynamic or manual configuration of an IP address within a virtual machine. For example, if the guest Operating System is configured as a DCHP client and Azure portal set to static, the Azure client will still get the address via DHCP. This behavior is similar to a DHCP reservation.

While the type of address assignment can be different, the IP address within the virtual machine must match the one configured in the Azure portal. For example, setting a private IP address statically, that mismatches Azure portal configuration will stop connectivity to that machine.

The First 4 IP addresses (subnet address + first 3 useable addresses) in every subnet are reserved.

Public IPs

Public IP is not configurable within the guest Operating System, which can only see private IP addresses. Azure performs address rewrite, so VM’s private IP address can receive traffic that sent from the Internet to its public IP address, and vice versa – traffic sent to the Internet from a VM is seen as originating from VM’s public IP.

Azure Public IP addresses provide both inbound and outbound connectivity from the Internet to the VM.

Public IPs can be of 2 types – basic SKU and standard SKU (SKU stands for Stock Keeping Unit).

Basic SKU Public IPs can be statically or dynamically allocated. VM with dynamically assigned public IP will release this address when it is stopped.

Standard SKU support high availability with zones and are slightly more expensive than basic SKUs. Standard SKU Public IPs support only static assignments.

Let’s perform simple hands-on configuration to apply the learned concepts to practice.

Create an Azure Virtual Network Step-by-Step

This section shows how to create an Azure Virtual Network step-by-step.

Navigate to Virtual networks administrative page, by selecting it in the left-side menu. In a newly created account, there will be no virtual networks. Click on “Create virtual network” to add one.

We will choose the only available subscription in our account, which is Free Trial. A subscription can contain resource groups; which have the purpose of grouping together resources with the same lifecycle. Let’s create a new resource group and name it rg_dev_environment_1.

Type-in a name for the VNet and region in which it will exist.

We will use an IPv4 address space of 10.90.0.0/16 and create a new subnet. It must be within VNet’s IP address space. In the example below, we’ve added subnet 10.90.0.0/24 and named it “subnet_web_servers”.

As shown in the screenshot below, it is possible to allocate multiple IPv4 address spaces to a virtual network.

The next step provides an option to enable security features, such as DDoS protection and Firewall. For the purpose of this demonstration, we will keep the default settings.

Tagging provides the ability to add custom metadata to different resources, which can be used for management and billing purposes. We will proceed to the next step without applying any tags.

The final step of the wizard provides summary information. Click on Create button to add the network.

The Virtual networks list is now populated with the new VNet we’ve created.

Attaching a VM to Azure Virtual Network

This section demonstrates how to connect a virtual machine to a subnet in a virtual network while creating a new VM. Only network-relevant details will be shown and discussed.

To add a new virtual machine, open the side menu, and select Virtual Machines. Click on the “Create virtual machine” button.

In the “Basics” dialogue window define general VM parameters, such as the subscription, resource group, and the virtual machine name. The regions of a VM should match the region of VNet, otherwise, the subnet will not be available for selection in the Networking step.

We moved straight to the Network configuration step skipping Disks configuration.

Figure 11 shows the configuration section related to networking. The virtual network drop-down menu will contain only VNets that are in the same region as the VM. We also select a subnet in which VM’s interface will be placed.

All remaining settings are left unchanged and VM has been created.

Reviewing the VM Configuration

After a few minutes VM is provisioned and we can check its settings. As Figure 12 shows, the machine was assigned a private IP address of 10.90.0.6 with the public IP address of 13.82.128.158.

The networking submenu of the virtual machine displays network interface and Network Security Group (NSG) settings. Let’s click on the interface to see its configuration.

Network adapter settings include IP configurations. During the machine provisioning process, we could only access the primary IP configuration.  This menu allows for creating additional IP configurations, which are similar to secondary IP addresses. It can be useful for adding multiple IP addresses, for example, for a web server with multiple websites, each available on different IP addresses.

This configuration menu also exposes the IP forwarding setting, which allows network adapter to accept packets that don’t have destination IP addresses matching any of the interface’s addresses. This configuration is required for devices that perform routing functions, such as 3^rd party firewalls or intrusion protection systems.

Inbound Internet Connectivity

Public IP addresses provide inbound connectivity to a virtual machine over the Internet.

We can now use Remote Desktop Connection (RDP) client to access this virtual machine. To launch RDP client on Windows 10 machine start typing “Remote Desktop” and select the built-in application.

Type in the public IP address of the VM and press Connect in RDP client. Use credentials provided during VM provisioning (default username is AzureUser).

Outbound Internet Connectivity

After connecting to a VM’s remote desktop, let’s open a web browser to test outbound Internet connectivity and check the public IP address that the VM uses.

To perform this testing, type in “what is my IP” request into the Google search bar. As shown in Figure 15, the outbound IP address matches the one we saw in the previous example.

Validating Routing Table in Azure portal

VNet uses the default route table to decide where to send Internet traffic when VM tries to connect to external resources. Subnets and route tables interaction will be a subject of one of the next blog posts, however, for now, we can check the effective routes as seen from VM’s network adapter point of view.

To do it navigate to Network interfaces menu, select Network adapter attached to the virtual machine, and click on Effective routes.

As shown in the screenshot, we can see that the default route has a Next Hop Type of Internet.

Self-Test Questions