Lost in Translation – Azure Networking

In today’s highly connected world, many professionals use Cisco’s terminology to discuss networking. Using the wrong terms can lead to lengthy, confusing arguments. The goal of this post, is to help those of us who don’t speak the language, to communicate effectively with others about Azure Networking.

I’ve been dabbling in the IT Pro space for a few months now, and it’s been a challenge to discuss Azure Networking. Coming from a development background, my reference to networking was Azure. That definitely made it difficult, because I spoke about Virtual Networks, Subnets and Network Security Groups. To help me sort things out, I asked a colleague of mine to identify the equivalencies between Cisco and Azure Networking terminology.

Let’s dive in!

Azure Virtual Network (VNET)

Typically a network with no or little restriction between VLANs and Subnets. In Azure, a Virtual Network (VNET) is identified by a network/mask (CIDR notation) like 10.0.0.0/16. These blocks are further divided in Subnets (VLANs) like we find in Cisco switches.

See Also : Virtual Network Overview

Subnet (within virtual network)

Equivalent to a broadcast domain (VLAN) in Cisco world. You can create as many subnets (VLAN) as needed in a VNet, as long as CIDR blocks don’t overlap. We can name our Subnets in Azure to provide a familiar naming convention.

Network Security Group (NSG)

Similar to an ACL in the Cisco world (allow/deny for ip src/dst + ports and protocol) for inbout/outboud control on a network interface. Typically, an NSG can be allocated to a Subnet (VLAN in Cisco’s terminology) or to a single Virtual Machine within a VNet. A Virtual Machine or Subnet can be assigned only one NSG and an NSG can contain up to 200 rules. We can have a maximum of 100 NSG per subscriptions.

When an NSG is applied to a Subnet, it will automatically be applied to all Virtual Machines that live within that Subnet. If we apply an NSG to a Subnet and to a Virtual Machine from the same Subnet, the rules are applied in the order in that the packet goes. For inbound traffic, rules from the Subnet NSG are applied first and then the Virtual Machine NSG is applied. For traffic flowing in opposite direction the rules from the Virtual Machine NSG are applied first and then the Subnet NSN is applied.

The following post is a great example of the a possible implementation.

Note that NSGs do not perform deep inspection on packets. A traditional firewall appliance can be used (with multiple NICs, deployed in a VNet) to perform deep inspection.

NSG Features And Constraints Summary

• 100 NSGs per Azure subscription
• One Virtual Machine / Subnet can only be associated with One NSG
• One NSG can contain up to 200 Rules
• Rule Characteristics:
  • Name
  • Type: Inbound/Outbound
  • Priority: Integer between 100 and 4096
  • Source IP Address: CIDR of Source IP Range
  • Source Port Range: Range between 0 and 65000
  • Destination IP Range: CIDR of Destination IP Range
  • Destination Port Range: Integer or Range between 0 and 65000
  • Protocol: TCP, UDP or use * for Both
  • Access: Allow/Deny
  • Rules processed in the order of priority. Rule with lower priority is processed before rules with higher priority numbers.

Virtual Network Gateway

A  Virtual Router appliance used to connect (through site to site VPN or ExpressRoute) to on-premise networks and to other VNets.

Manage Key

A preshared key in the IPSEC world (used when configuring site-to-site VPN)

Virtual IP Address (VIP)

A Public shared IP address. This uses port redirection to internal addresses for UDP and TCP traffic. All the hosts in a Cloud Service share the same VIP.

Instance Public IP Address (PIP)

Public IP addresses are allocated to specific Virtual Machines in a one-to-one NAT fashion. When we use a PIP, the traffic to the host does not pass through the Azure Load Balancer. This can be useful for certain protocols exchanges that require multiple ports.

Dynamic IP Address (DIP)

A Dynamic IP address is an IP that is assigned by the Azure DHCP. Since we often require static addresses, we may feel compelled to disable the DHCP on Virtual Machines. Doing so is a mistake and will result in an unaccessible Virtual Machine. The right way to go about securing a private IP address, is to reserve it in the DHCP.

This reservation can be done though PowerShell, Azure Resource Manager, CLI, REST and even through the Azure Portal.

Load Balancers

On Azure we can use three types of load balancers. The first is the External load balancer. It is used to load balance traffic in order to provide high availability for IaaS Virtual Machines and PaaS role instances accessed from the public Internet. The second is the Internal load balancer. we use this load balancer to provide high availability for IaaS Virtual Machines and PaaS role instances accessed from other services in your VNet. The third is the Azure Traffic Manager. We use this DNS based load balancer to distribute traffic between geographies and deployments.

Endpoint

There are two types of Endpoints. The first is Port-Forwarded. This connection point forwards traffic from a port on a VIP to a specific Cloud Service Virtual Machine instance. The second is Load-Balanced. This uses the Azure Load Balancer to distribute traffic from the VIP over a number of Virtual Machine instances.

Application Gateway

Application Gateway provides an Azure-managed HTTP load balancing service based on layer 7 load balancing. It handles HTTP load balancing, Cookie based session affinity and SSL offload for high-availability Internet-facing and internal-only web frontends.

Application-level routing is based on policies such as cookies, URL hash and weight (load). This can be quite useful for applications like a CDN, that require multiple HTTP requests on the same long-running TCP connection to be routed/load balanced to different backend servers.

See Also : What is Application Gateway

Cloud Service

Logical grouping of VMs and Web and Worker roles.

ACL (Access Control List) in Context of Virtual Network

ACL can be applied to Endpoints, which essentially act as an Access Control List to filter traffic. They are not applied to internal traffic, and only affect traffic going through the Endpoint itself. Hence, you should prefer to use NSG over ACL whenever possible.

Note: When it comes to Cloud Services, we benefit from using both NSGs and ACLs.

Virtual appliances

A virtual appliance is a Virtual Machine in a VNet that runs a software based appliance and functions, such as a firewall, WAN optimization, or for intrusion detection. We can create a route in Azure to route the VNet traffic through a virtual appliance to use its capabilities.

For instance, NSGs can be used to provide security on the VNet. However, NSGs provide layer 4 Access Control List (ACL) to incoming and outgoing packets. If you want to use a layer 7 security model, you need to use a firewall virtual appliance.

Additional Notes

1. You can use regular Firewalls deployed as appliances as well in the Datacenter.
2. Virtual Machines cannot send layer-2 traffic.
3. VNets do not span multiple region.
4. A basic and standard gateway can connect to a max of 10 (or more for the high performance GW depending on the scenario and if using ExpressRoute) VNet and on-premise.
5. No IP address can overlap amongst VNets
6. Changes on NSG aren’t applied instantly unlike on a typical Cisco device. They are applied within minutes.
7. VNet to VNet is routed using IPsec gateways.
8. ACLs aren’t definable for Subnets (VLAN interfaces in Cisco’s terminology) within a VNet.
9. Static Routing is Policy based
10. Dynamic Routing is Routing based