Virtual Network

• VNet enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other.

• Virtual networks and subnets span all availability zones in a region. You don't need to divide them by availability zones to accommodate zonal resources

Default communication to Internet

All resources in a VNet can communicate outbound to the internet, by default. You can communicate inbound to a resource by assigning a public IP address or a public Load Balancer.

VNet components

Address space

When creating a VNet, you must specify a custom private IP address space using public and private addresses. Azure assigns resources in a virtual network a private IP address from the address space that you assign. For example, if you deploy a VM in a VNet with address space, 10.0.0.0/16, the VM will be assigned a private IP like 10.0.0.4.

Address range

Largest is x.x.x.x/8 and smallest is x.x.x.x/29

Subnets:

Subnets enable you to segment the virtual network into one or more subnetworks and allocate a portion of the virtual network’s address space to each subnet. Reserved IP addresses are x.x.x.0-3 and x.x.x.255.

Some tips for VNets

• Private IP addresses are supported using in-built DHCP server.
• Vnet supportes IPv4 and IPV6 public IPs
• VNET Subnet: They are used as Gateway subnets
• We can have a default subnet
• Vnet has Azure provided DNS, we can also use the custom DNS too.
• At the subnet level, you can configure Network Security Groups (NSGs) to secure your workloads

A DMZ subnet use case

In this typical use case, our goal is to make sure that all traffic coming from the public subnet should be routed to the DMZ before it gets routed to the private subnet.

The reason for this is that a public subnet contains workloads that are Internet facing, and a private subnet contains workloads that are not exposed to the Internet, such as databases, application logic, backend servers, etc. By default, the communication from the public subnet is allowed to the private subnet; however, we need to make sure that the traffic is filtered before it reaches the private subnet. This will help us to protect the private workloads, as all traffic is matched against the rules that you have set up in the NVA (WAF in this case). If there is any attack or malicious traffic, NVA will take care of it.

Now, the question is, how can we implement this? As you can see in above diagram, we have used the routing table with User Defined Route (UDR) to accomplish this task. By default, the traffic from the public subnet to the private subnet is allowed, but using UDR, you are forcing the packets to go through the DMZ subnet.

Regions

VNet is scoped to a single region/location; however, multiple virtual networks from different regions can be connected together using peering.

Choose region with care

When you create a virtual network in Azure, you will get an option to choose the region. Depending on the region you choose, the virtual network will be deployed to the respective region, and the virtual machines deployed to the virtual network will also fall under the same region.

Subscription

VNet is scoped to a subscription. You can implement multiple virtual networks within each Azure subscription and Azure region.

VNET peering

Virtual network peering enables you to seamlessly connect two or more Virtual Networks in Azure. The virtual networks appear as one for connectivity purposes. The traffic between virtual machines in peered virtual networks uses the Microsoft backbone infrastructure. Like traffic between virtual machines in the same network, traffic is routed through Microsoft's private network only.

VNET non-reciprocal and non-trasitive connection

If we setup a connection between 2 VNets, that connection is non-reciprocal as shown in the diagram below. That is why we have to setup 2 connections in this case.

The connction between different VNETS is non-trasitive as shown below.

Active-passive and active-active peering are possible. Lets take an example of on-site and cloud peering with active-passive mode as shown below

Azure supports the following types of peering:

1. Virtual network peering: Connecting virtual networks within the same Azure region.
2. Global virtual network peering: Connecting virtual networks across Azure regions.

Express Route

ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider. With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure and Microsoft 365.

Remember

ExpressRoute connections don't go over the public Internet. This allows ExpressRoute connections to offer more reliability, faster speeds

We have 2 options in Express routes

1. ExpressRoute Direct: It does not require connectivity provider (service provider), it directly connects to Microsoft Edge Routers

What is FastPath?

FastPath is an additional feature that can be used with ExpressRoute Direc. When enabled, FastPath sends network traffic directly to virtual machines in the virtual network, bypassing the gateway (ExpressRoute gateway is still needed though)

1. ExpresRoute Circuit: It uses a service provider.

Points to remember

• Allocate two /30 subnets that are not used anywhere else in your network topology. One subnet will be used for the primary connction; the other will be used for the secondary connction as shown in the diagram above. From each of these subnets, you will assign the first usable IP address to your router because Microsoft uses the second usable IP for its router.

• A valid VLAN ID is required to establish this peering on. Ensure that no other peering in the circuit uses the same VLAN ID. For both primary and secondary links you must use the same VLAN ID. This information is provided from your provider.

Circuits and Peering

Circuit

• ExpressRoute circuit is a logical connection between on-premises infrastructure and Microsoft cloud services through a connectivity provider
• ExpressRoute circuits do not map to any physical entities
• A circuit is uniquely identified by a standard GUID called as a service key (s-key)
• There is a 1:1 mapping between an ExpressRoute circuit and the s-key
• The service key is the only piece of information exchanged between Microsoft, the connectivity provider, and you (s-key is not a secret for security purposes)
• A circuit consists of 2 connections:
  • Primary connection: main
  • Secondary connection: redundent for HA

Peering

A peering is the interconnection between on-premise network and Microsoft cloud services (Azure, Microsoft 365). ExpressRoute circuits can include two independent peerings: - Private peering: Azure VNet - Microsoft peering: Microsoft 365, Dynamics 365 etc.

Basics

NIC

Virtual machines have one or more network interface cards (NICs) that exist in the same region as the virtual network. You assign an IP address (either statically or dynamically) from a subnet in the virtual network. This action allows the virtual machine to communicate with other resources in the virtual network (and any peered network).

Public IPs

Public IP addresses are associated with a virtual machine NIC, public load balancer, VPN gateways, application gateways, and any other resource that can be accessed from the Internet.

Here also we can choose the allocation method to be static or dynamic. However, the availability of allocation methods depends on which SKU of public IP address we are using. The SKU is more like a pricing tier, where you will find different prices based on which SKU you are selecting

• Basic SKU: Static or Dynamic IP that is accessible by default and needs NSG to configure
• Standard SKU: Static PIP, that is not accessible by defult and needs NSG to allow traffic

Private Endpoint

Before defining private endpoint, lets clear some basics terms:

Some basics: revised

1. Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a Private Endpoint in your virtual network. Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet.
2. Azure Private Link service is the reference to your own service that is powered by Azure Private Link.
3. A private-link resource is the destination target of a specified private endpoint.
4. A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that's powered by Azure Private Link. By enabling a private endpoint, you're bringing the service into your virtual network. Private endpoint has NIC attached to it.

• The value of the private IP address remains unchanged for the entire lifecycle of the private endpoint.
• The private endpoint must be deployed in the same region and subscription as the virtual network.
• The private-link resource can be deployed in a different region than the one for the virtual network and private endpoint.

Private Endpoint Example

Imgine that there is a virtual network using the address range 10.10.0.0/16. Inside this virtual network are two subnets, SubnetA (10.10.5.0/24) and SubnetB (10.10.6.0/24).

One or more virtual machines reside in SubnetA. A storage account has a private endpoint with an IP address of 10.10.6.5 inside SubnetB. The virtual machines inside SubnetA access the storage account through the storage account’s private endpoint IP address located in SubnetB.

Resources in other networks can access the storage account through the private endpoint IP address.

Using private endpoints we can drill down to a sub-resource as shown below. This can't be done using Service Endpoint as it will allow access to the resource level instead of sub-resource level.

When to use Private endpoint?

Private endpoints enable connectivity between the customers from the same:

• Virtual network
• Regionally peered virtual networks
• Globally peered virtual networks
• On-premises environments that use VPN or Express Route
• Services that are powered by Private Link

Private Link Service

Azure Private Link service is the reference to your own service that is powered by Azure Private Link. Your service that is running behind Azure Standard Load Balancer can be enabled for Private Link access so that consumers to your service can access it privately from their own VNets. Your customers can create a private endpoint inside their virtual network and map it to this service.

Service Endpoint

• Service endpoints direct VNet traffic off the public Internet and to the Azure backbone network.
• They are enabled per subnet using policies.
• This service does not provide private IPs to the services.
• Service Endpoints enables private IP addresses in the their VNet to reach the endpoint of an Azure service without needing a public IP address on the their VNet. These VM's will connect to public IP of the service though.
• Service endpoints apply to all instances of the Azure resource, not just the ones you create. If you want to limit virtual network traffic to specific instances or regions of a resource, you need a service endpoint policy.

Example of service endpoint

Review the image below representing service endpoints in action. In this example, you have enabled a service endpoint for the Microsoft.SQL service on SubnetA. A virtual machine in SubnetA uses its private IP address to access a SQL server hosting several databases. The virtual machine connects using the public IP addresses associated with the Microsoft.SQL service

Notice that Subnet B does not have service endpoints enabled for its subnet for the Microsoft.SQL service. Compute resources in this subnet use the public IP address for the virtual network to connect to the public IP address of the Azure service.

Service Endpoint Policies

Virtual Network (VNet) service endpoint policies allow you to filter egress virtual network traffic to Azure Storage accounts over service endpoint, and allow data exfiltration to only specific Azure Storage accounts. Endpoint policies provide granular access control for virtual network traffic to Azure Storage when connecting over service endpoint.

Private Vs Service Endpoints

Public and Private IPs in service/private endpoints

With service endpoints, you're still connecting to the target resource's public endpoint. This effectively extends the identity of the VNet to the target resource. With private endpoints, you're assigning the target resource a private IP address from the VNet, essentially bringing it into the network. The target resource's public IP address doesn't go away, but you can lock it down so all traffic from the internet is denied.

Here are some tips on when to use which endpint

When to use which endpoint?

1. If you want to be able to block all internet traffic to a target resource, use a private endpoint.
2. If you're dealing with traffic from on-premises, use a private endpoint.
3. If you want to secure a specific sub-resource to your VNet resources, use a private endpoint.
4. If you want to secure a specific storage account to your VNet resources, you can use a private endpoint, or a service endpoint with a service endpoint policy.
5. If you don't need a private IP address at the destination, service endpoints are considerably easier to create and maintain, and they don't require special DNS configuration.
6. if cost is a concern, note that service endpoints are free.

Network Routing types

Network routes or route tables have existed in traditional networks for an exceptionally long time. The routes that are part of the route table decide how to direct a packet to the destination.

System routes

They are built in routes which cannot be modified

VM's default communicaiton to internet

Whenever we create a VM in Azure, the VM will be able to communicate with the Internet without setting up any routes. In AWS, we need to create different gateways like NAT Gateway or Internet Gateway to facilitate the connection from a VM to the Internet. However, in Azure this is enabled by default with the help of system routes

Custom/ User defined routes (UDR)

User defined routes (UDR) or BGP routes which can override the system routes.

Precenence order of the routes

Custom routes > BGP routes > System routes

Block access to public internet

We can block access to public internet by adding a custom route from 0.0.0.0/0 to None as shown below

NSG (L3 and L4)

Tldr

They are used to control the flow of traffic inside the VNET and are similar to Firewalls

An NSG is a collection of security rules that can be used to allow or deny inbound or outbound traffic.

Is NSG associted with subnet?

As shown in the diagram, NSG can be associated with a subnet, or a NIC based on your requirement. NSGs are reusable, which means you can have multiple NICs or subnet associations to a single NSG.

NSG as no effect unless its associated with either NIC or a Subnet.

Priorities are used in NSG to evaluate; lower the number, higher the priority.

NSG Effective rules

When you apply NSG to both subnet and NIC, then effective rules come into the picture. If you are using NSGs at both the subnet and NIC level, the rules will be evaluated at both levels.

Rules evaluation order

Inbound Traffic: Each security rule will be evaluated independently when the NSG is applied to both the subnet and NIC levels. Incoming traffic will be first evaluated against the rules applied on the subnet level; if there is an allow rule, then the packet will be sent to the NIC. The rules set at the NIC level will be evaluated now, and only if there is an allow rule then the packet is allowed; otherwise, it will be dropped. In short, first at Subnet then NIC

Outbound Traffic: all outgoing traffic will be first evaluated against the NIC rules; if there is an allow rule, then the traffic is evaluated at the subnet level. In short, first at NIC then Subnet

NVA

Network Virtual Appliance NVAs are VMs that can optimize our networks with routing and firewall capabilities.

Azure Firewall (L7 and L4)

Using Azure Firewall, we can create, enforce, and manage network policies across virtual networks and subscriptions. Azure Firewall provides more features then NSG. Also, Azure firewall is different than WAF

Setting for Azure firewall is shown below

Do we need WAF in addition to NSG?

Yes, we need both. The main difference is that NSG operates at layers 3 and 4 of the OSI layer; on the other hand, Azure Firewall works at layers 7 and 4.

It comes in 3 flavours

• Standard
• Premium
• Basic

FQDN Tags

We can use FQDN tag in the Azure firewall rules. An FQDN tag represents a group of fully qualified domain names (FQDNs) associated with well known Microsoft services.

Service tags

A service tag represents a group of IP address prefixes to help minimize complexity for security rule creation. You can’t create your own service tag, nor specify which IP addresses are included within a tag. Microsoft manages the address prefixes encompassed by the service tag, and automatically updates the service tag as addresses change.

How to use service tags?

You can use service tags to define network access controls on network security groups, Azure Firewall, and user-defined routes. Use service tags in place of specific IP addresses when you create security rules and routes.

By specifying the service tag name, such as Storage, in the appropriate source or destination field of a security rule, you can allow or deny the traffic for the corresponding service. 2 tags are used in the below diagram in the destination fields

Firewall Policy/Rules

• Rule collection group: It is used to group rule collections. They're the first unit to be processed by the Azure Firewall and they follow a priority order based on values
• Rule collection: it belongs to a rule collection group, and it contains one or multiple rules. They're the second unit processed by the firewall and they follow a priority order based on values. Rule collections must have a defined action (allow or deny) and a priority value

Rules used in Firewall are of 3 types

1. NAT
2. Network (L4)
3. Application (L7)

Priority of Firewall rules

NAT rule > Network rule > Application rule

NAT rules

Using a NAT rule collection, you will be able to translate a public IP and port to a private IP and port

NAT example using VM

Assume you have a Ubuntu server with private IP address, say, 10.0.0.2, and the SSH server is available on port 22. Instead of exposing this port and IP to the Internet, you can create a NAT rule on the firewall. Using the public IP of the firewall and a random port, you can set up a NAT rule. Let’s assume that the public IP address of the firewall is 66.142.43.02; using NAT rule you can redirect all traffic hitting port 5000 of the firewall to be translated to 10.0.0.2 and port 22. In short, translate 66.142.43.02:5000 to 10.0.0.2:22. In this way, you can translate the public IP address and port to a private IP address and port.

Inbound DNAT

Inbound Internet network traffic to your firewall public IP address is translated (Destination Network Address Translation) and filtered to the private IP addresses on your virtual networks.

Outbound SNAT

All outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP (Source Network Address Translation). You can identify and allow traffic originating from your virtual network to remote Internet destinations.

Network rules

A network rule should be in place for any non-HTTP/S traffic to be allowed through the firewall. For a source to communicate with a destination deployed behind a firewall, you need to have a network rule configured from the source to the destination. If there is no rule that specifically calls out this incoming traffic, then it will be dropped.

Tldr

You can use a network rule when you want to filter traffic based on IP addresses, any ports, and any protocols.

Application rules

Application rules allow or deny outbound and east-west traffic based on the application layer (L7). You can use an application rule when you want to filter traffic based on fully qualified domain names (FQDNs), URLs, and HTTP/HTTPS protocols.

if you configure network rules and application rules, then network rules are applied in priority order before application rules. The rules are terminating. So, if a match is found in a network rule, no other rules are processed.

ASG

Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses.

---

Was this page helpful?

Yes No