These are the notes taken during preparation of AZ-700 exam. These notes are useful for anyone taking the Microsoft Exam, a refresher to understand most of Azure Networking concepts, might help you with the interview preparation as well.
The topics are not in order as notes are taken on the go based on the scenario and topics which I went through. I highly believe this might be useful for everyone!
Virtual Network Peering
In order to enable inter-VNet communication, you need to configure virtual network peering between VNET’s(for example, VNetA and VNetB).
Azure Network Watcher:
Azure Network Watcher service enables you to monitor conditions at a network level in and from Azure
Packet capture is a feature within Azure Network Watcher enables you to capture packets on virtual machines and capture traffic.
‘IKEErrors.txt’ file
This file will only report issues and errors relating to the Internet Key Exchange (IKE) component of the VPN tunnel. The IKE process allows VPN peers at both ends to successfully encrypt and decrypt network packets traveling over the VPN tunnel, using a mutually agreed pre-shared key or certificate. This process consists of two phases: phase 1 and phase 2. Each phase uses encryption algorithms and keys. The IKEErrors.txt file will list any issues encountered during either phase initiation.
‘CPUStats.txt’ file
This file will provide you with CPU utilization and memory usage at the time of troubleshooting.
‘ConnectionStats.txt’ file
When you troubleshoot VPN connectivity, this file will contain statistics for the connection, which includes ingress and egress byte data
Network Security Group(NSG)
A NSG is an Azure service that enables you to secure the premises of your network against threats. This inspects traffic and has the ability to allow or deny traffic from accessing a network packet.
Load Balancer:
A Standard Load Balancer enables you to load balance protocol flows on all ports when using an Internal Load Balancer through High Availability ports, but cannot be used to direct traffic.
Network Security Group flow logs
This is an optional feature that comes bundled with Network Watcher. These logs will allow you to analyze network traffic that passes through a Network Security Group.
Border Gateway Protocol:
The Border Gateway Protocol (BGP) is the routing protocol for exchanging routing and reachability information between networks.
When this protocol is used within Vnets, it enables your Virtual Private Network (VPN) devices to exchange routes with your VPN gateways.
BGP will tell the VPN gateways that the prefixes of the VPN devices are allowed to go through them
Virtual Private Network:
Downloading the VPN client configuration for users should only be done if the topology of a network is modified so that the changes of the topology can be implemented again to the client.
In most cases, VPN is the extension of the private internal network to remote locations or users. The traffic that flows via a virtual network is encrypted, thus it provides maximum security against traffic sniffing or replay attacks. VPN is a tunneling protocol and it cannot be used to detect the link failure events at L2 or L3.
Private Endpoint:
A private endpoint allows you to completely isolate an Azure Platform as a Service (PaaS) service, such as a web app, so that it can only be contacted by an internal Azure resource. A private endpoint also allows traffic from on-premises networks to securely connect to the resource without traversing via the internet.
Service Endpoint:
A service endpoint allows you to directly connect a subnet to a public Azure service such as storage accounts.
A service endpoint can be used to force connectivity from a virtual network to a PaaS resource, using the Azure backbone network. This ensures that the optimal network route is being taken each time instead of introducing additional network hops across the internet.
Azure Firewall Policy Rules and Rule sets
An application rule is based on Layer 7 of the Network OSI model. This will allow administrators to add a fully qualified domain name (FQDN) in the rule. For connectivity to www.website.com to work, DNS on port 53 is also required, in the form of a network rule.
Destination Network Address Translation (DNAT)
Destination Network Address Translation (DNAT) rules allow users to connect to private IP addresses behind Azure Firewall via the public interface (IP address).
A common scenario for this type of rule is for Remote Desktop Protocol (RDP) connections to an Azure virtual machine from the internet. For instance, a business need could surface that requires a third party support provider to connect to one of your Azure virtual machines over the internet using RDP. This would be needed so that the third party support provider could efficiently support the application that is running on the virtual machine and to hit any agreed Service Level Agreements (SLAs). All the third party would require is the public IP address in order to connect via RDP to the virtual machine from their headquarters.
Network security Groups
The Remote Desktop Protocol allows remote users to connect to another Microsoft Windows machine from another location. This can either be over the public internet or a local network.
service tags
A service tag is a collection of IP address prefixes that can be used to simplify the creation of security rules.
NSG flow logs helps to find details related to incoming IP traffic through NSG1. The flow logs of a Network Security Groups (NSG) map IP traffic through an NSG. Flow logs can be used for monitoring your network, validating isolation within your network, and detecting compromised IP addresses. Using this feature, you can know more about incoming and outgoing IP traffic passing by an NSG.
Application security groups:
Application security groups are used for configuring network security.
ASG is a feature that provides network security based on workloads rather than definite IP addresses. It also enables you to group VMs and filter the traffic inside them. ASG is used within Network Security Groups (NSG) to define security rules for VMs and workloads.
Internet Protocol (IP) flow is a feature that enables you to know when packets can access a VM or not, but cannot be used to direct internet traffic as required.
Azure Network Watcher is a service that enables you to monitor the health of your network and collect diagnostic logs.
Synapse Link:
A Synapse Link is a service provided by Azure to monitor data analytics for operations within Azure Cosmo DB. Azure Cosmo DB is a NoSQL database used within mobile apps and web apps.
Application Insights:
This is an Azure Monitor feature that is used for monitoring the performance anomalies of live apps.
Azure Front Door:
Azure Front Door handles requests at layer 7 and is a global service.
Azure Front Door is a global Layer 7 load-balancing service. Layer 7 refers to the Application layer of the Open Systems Interconnect model (OSI model). This can be useful if you have a number of virtual machines in different regions. Azure Front Door can be used to direct traffic (load balance) to the most appropriate virtual machine based on the source region of the end user. This ensures that the end user is always connecting to the closest virtual machine.
Azure Front Door can be further customized by adding custom rules using the rules engine. A rules engine rule can be used to redirect users to a mobile friendly website if the source device is a mobile.
The Split Transmission Control Protocol (TCP) feature of the Azure Front Door optimizes web performance for global users. Split TCP is a technique where the incoming TCP requests that have a large round-trip time (RTT) are split into two connections. The first TCP connection is maintained between the end user and the Frontend, and the second connection is maintained between the Frontend and the Backend. This set-up results in minimizing latency between the end users and Azure Front Door.
The caching feature of Azure Front Door optimizes web performance for global users. By caching the data retrieved from the backend servers, Azure Front Door greatly reduces the response time towards the end users.
The backend health probes are useful to keep track of the availability of internal resources.
The URL rewrite feature of Azure Front Door can be used to modify the incoming URL path and add different parameters to it.
You should use the Session Affinity feature of Azure Front Door to make sure a specific transaction or Transmission Control Protocol (TCP) stream from the same source IP is always relayed to the same backend server. Azure Front Door use cookies to create session affinity between the end user and Azure Front Door
Azure Front Door Rules Engine:
Rules Engine can be used to provide a more granular control on how HTTP traffic is handled by Azure Front Door. For example, if a user is browsing on a mobile device, then a rule can be configured to re-direct users to a mobile friendly site. Rules Engine will not, however, present users with blocked messages.
In Azure Front Door, Rules Engine can be used to configure a number of rules that get triggered after the WAF but before the Azure Front Door routes. One of the rules that can be created is HTTP to HTTPS redirection rules. This is useful if you need to force all connectivity to be secure.
To map a custom domain to the Azure Front Door Fully Qualified Domain Name (FQDN) we can create a Canonical Name (CNAME) record. The CNAME record is like an alias record,
which you can use to map one domain name to another domain name.
Azure Front Door uses Microsoft edge locations and provides load balancing and site acceleration functions. SSL offload, path-based routing, quick failover, caching, and other Layer 7 capabilities are available to boost web application performance.
Custom WAF Rules
Custom WAF rules take priority over Microsoft managed rules. Administrators can block incoming traffic to Azure Front Door using custom rules, based on conditions such as geolocation and IP address. If a blocked error message is presented, then it will be related to an Azure Front Door WAF policy.
RADIUS Server:
Remote Authentication Dial-In User Service (RADIUS) is a network protocol that protects a network by allowing centralized dial-in user authentication and authorization.
Azure Private Link
Azure Private Link provides private access from an Azure virtual network to Platform as a Service (PaaS) services and Microsoft Partner services in Azure. Azure Private Link cannot be used to establish an any-to-any connection.
Azure Private Link allows accessing Azure Platform as a Service (PaaS) over a private IP address within the VNet. Private Link creates a Private Endpoint within a VNet, which gives it a private IP address attached to a Network Interface (NIC).
Private Link can extend for on-premises network traffic using ExpressRoute or VPN tunnels. Since Private Link creates a private IP in the VNet, it is similar to any other resource within the VNet. So any resource part of the VNet can reach the desired resource easily. Similarly, resources deployed on the on-premises network can directly reach the desired resources on the secure channel.
Private Link can integrate with Private DNS. The NIC associated with the Private Link contains the information to configure your DNS. It provides you with the private IP address and Fully Qualified Domain Name (FQDN) of the private link resource. Using this information, you can override the DNS resolution for the private endpoint.
Though Azure private links help you to keep your Azure services secure and private, they are not easy to set up and imply additional costs for Private Endpoint, inbound, and outbound traffic.
Traffic Manager:
Traffic Manager is a DNS load balancer. A typical use case for traffic manager would be to automatically failover web services from one region to another in the event of a disaster. Nested profiles can be configured to combine different routing methods together, e.g. performance and weighted.
Network Address Translator (NAT)
NAT functionality provides an option to Azure resources to communicate with the public internet without exposing their internal IP addresses. This provides an additional layer of security. Public internet users only see the NAT Gateway IP(s) and are not capable of retrieving any information regarding the internal network.
NAT is generally used to keep virtual machines private. Virtual machines can utilize a static public IP address associated with the NAT virtual network for outbound connectivity. A common use case for this feature is to address issues where conflicting IP address spaces are used.
Azure Network Address Translation (NAT) gateway:
NAT gateway can be used to map a range of IP addresses, defined by an IP prefix, to internal resources.
Public IP addresses with a Standard Stock-keeping Unit (SKU) or IP prefixes are compatible with an Azure Network Address Translation (NAT) gateway. Azure Virtual Network NAT ensures that virtual machines in an Azure virtual network can communicate to external services using the NAT gateway’s public IP address. This saves administrators assigning the virtual machines a public IP address, which would increase the security threats in an environment. IP addresses with a basic SKU cannot be configured with NAT gateway
Azure Virtual Network Gateway:
The Azure Virtual Network Gateway entity is used to configure the Virtual Private Network (VPN) gateway and the ExpressRoute gateway.
The Virtual Network Gateway type configuration parameter is used to declare it as either a VPN gateway or an ExpressRoute gateway.
You should use a VPN gateway to allow the virtual network to communicate with the on-premises environment. A Virtual Private Network (VPN) gateway is a solution provided by Azure that uses site-to-site VPN to connect virtual networks with on-premises networks. It sends traffic between Azure and the on-premises network over a public internet connection.
Using a site-to-site VPN connection enables you to achieve traffic encryption when the connection is established between the virtual network and the on-premises environment. To add a VPN gateway connection, you should access the Azure portal, and navigate to the Virtual network gateways page, where you can create a new VPN gateway.
A Point-to-Site VPN creates a secure connection from individual workstations directly to Azure. It is beneficial when there are only a small number of users that require access.
Azure Express Route allows you to extend your on-premises network directly to Azure utilizing a private connection.
A self-signed certificate authority is one of the three authentication methods that point-to-site Virtual Private Network (VPN) uses. This is the only method that does not use OpenVPN but instead, it requires you to generate client certificates from a root certificate, then upload the root certificate to Vnet gateway that authenticate the client certificates. This would achieve a secure connection between the users within the company and the virtual network that contains the resources.
OpenVPN is a open source VPN solution available on Azure market that enables you to connect your workstation securely to your virtual network over the public internet.
Active-active VPN gateway:
This is used to create highly available VPN connections between your networks and Azure. It is achieved by deploying a minimum of two VPN gateways and public IP addresses.
A NAT gateway can be used to forward traffic from private Azure resources to external services. This can be done by linking the NAT gateway to subnets. When NAT is configured, it uses Source Network Address Translation (SNAT) to translate private IP addresses in an Azure network to a static public IP Address. This allows private IP addresses to communicate with public hosts using the internet. When Azure Virtual NAT has been deployed and configured, outbound connectivity is automatically managed, without the need for additional configuration or user defined routes (UDR).
Next-Hop Types:
The Internet next hop type is used to reach the public Internet. Therefore, any source address prefix that needs to reach the internet should be
routed to this next hop address.
You should not use none as a next hop type. The None next hop type is a sinkhole, which you can use to drop traffic from a particular source IP/address space to a specific destination IP/address space.
ExpressRoute Direct:
ExpressRoute Direct is used to connect you directly to the global network of Microsoft.
Azure Bastion:
The Azure Bastion service is a fully managed PaaS service that you can deploy within your virtual network. It allows you to connect to your virtual machines
through Remote Desktop Protocol/Secure Shell (RDP/SSH) over Secure Sockets Layer (SSL) directly from the Azure site
Virtual Network:
OpenVPN is a free open-source VPN system that can be used to deploy a fully working virtual private network setup. The OpenVPN cannot be used to relay the authentication messaging between the client and the AD servers.
IPSec is the protocol used by the VPN clients or nodes to create security associations with remote VPN servers. As it is a protocol itself, it cannot be used to solve the problem in the scenario.
Subnet delegations
A subnet delegation will allow you to label a specified subnet for an Azure Platform as a service (PaaS) that requires to be injected within a virtual networks
Subnet Reserved Address:
By default, Azure will reserve five addresses from each subnet.
The following addresses will be reserved from the subnet (for e.g, In this subnet 10.1.0.0/24)
10.1.0.0 – Network Address
10.1.0.1 – Default Gateway Address
10.1.0.255 – Broadcast Address
The above addresses will not be allocated by Azure Dynamic host configuration protocol (DHCP) to any Azure virtual machine.
A few other addresses that will be reserved from a subnet are: x.x.x.2, x.x.x.3: Reserved by Azure to map the Azure DNS IPs to the virtual network (VNet) space.
Azure DataBricks:
Azure Databricks is a data analytics platform that contains applications related to Structured Query Language (SQL), data science, and machine learning.
Azure Application Gateway
Azure Application Gateway is a regionally-based Azure service.
An Application Gateway is a load-balancing solution that is used to load balance between servers at an application level. Application Gateway operates at layer 7 of the OSI model. The usage of an Application Gateway is beneficial in case you need to protect and secure the traffic sent and received by your app.
Traditional load balancers operate at the transport layer (OSI layer 4 – TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.
ExpressRoute Global
You should create an ExpressRoute Global Reach circuit to configure on-premises connectivity between Azure regions located in different geopolitical locations. ExpressRoute Global Reach uses the Microsoft global backbone network to route traffic from one organization in a global location to another using a fully secure private Microsoft network.
ExpressRoute Premium
You can use ExpressRoute Premium to extend connectivity across geopolitical boundaries. For example, if you connect to Microsoft in one location through ExpressRoute, you will have access to all Microsoft cloud services hosted in all regions throughout the world. However, it will not provide on-premises connectivity between Azure regions located in different geopolitical locations.
ExpressRoute Local
This circuit can be used to transfer data cost-effectively to a specific region. With ExpressRoute Local, you can create the connectivity with an ExpressRoute location near the Azure region you want. However, it will not provide on-premises connectivity between Azure regions located in different geopolitical locations.
ExpressRoute Direct
This circuit provides customers with the opportunity to connect directly to Microsoft’s global network at various peering locations depending on customer preference. However, it will not provide on-premises connectivity between Azure regions located in different geopolitical locations.
Azure DNS
You can use the following Domain Name System (DNS) records as alias records in Azure DNS:
A
AAAA
CNAME
DNS is used to assign human-readable names to different resources, which can then be mapped to an IP address identifier. An Address A record is used to map the IP address to a domain name.
An AAAA record is used to map an IPv6 IP address to a domain name. The Canonical Name or CNAME record is used to map different aliases to a parent domain, for example mapping www.xyz.com to xyz.com. So, if you type www.xyz.com, the DNS will resolve it to xyz.com and eventually the domain IP address.
The benefit of using alias records in Azure is that they allow you to directly access the virtualized resources. For example, you can configure an alias record to directly access the Azure virtual machine public IP from the DNS zone directly. The advantage is that, if the public IP changes, you will not need to manually update the DNS record. It will automatically get updated.
You cannot use mail exchange (MX) records as alias records in Azure DNS. MX records are used to configure your mail exchange servers. MX records are not supported to configure alias records in Azure DNS.
You cannot use Name Server (NS) records as alias records in Azure DNS. NS records are used to configure the authoritative DNS server detail that contains the actual domain information. The following are an examples of Azure DNS Name servers:
ns1-35.azure-dns.com.
ns2-35.azure-dns.net.
ns3-35.azure-dns.org.
ns4-35.azure-dns.info.
NS records cannot be configured as alias records.
Azure Load Balancer:
An Azure load balancer is recommended for non-HTTPS traffic.
A public load balancer can be useful if you have a web tier in your virtual network, comprising of two or more virtual machines. Users may then need to reach these web servers from the internet on port 80. A public load balancer can be used to achieve this.
Azure provides a suite of fully managed load-balancing solutions for your scenarios.
If you are looking to do DNS based global routing and do not have requirements for Transport Layer Security (TLS) protocol termination (“SSL offload”), per-HTTP/HTTPS request or application-layer processing, review Traffic Manager.
If you need to optimize global routing of your web traffic and optimize top-tier end-user performance and reliability through quick global failover, see Front Door.
To do transport layer load balancing, review Load Balancer.
Reference:
https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview
Azure Load Balancers operate at layer 4 of the Open Systems Interconnection (OSI) model. An internal Azure load balancer is used to distribute traffic to a group of Azure resources or servers. An internal load balancer will only distribute traffic to resources in the Azure virtual network and will not allow external outbound connectivity
Azure Firewall:
Azure Firewall is an Azure network security service that can be used to filter both inbound and outbound network traffic.
Azure Firewall is a layer 4 stateful firewall. It filters traffic based on application, network and Destination Network Address Translation (DNAT) rules.
DNAT rules can be used to translate inbound traffic. For instance, if you need to connect to a virtual machine from the internet, a DNAT rule can be used to forward traffic from the internet to the virtual machine. It is commonly used in conjunction with a VPN gateway or Network Virtual Appliance (NVA). An NVA can be used for advanced levels of security and traffic flow control. For instance, Azure Firewall can be used alongside an NVA to force traffic via it so that any traffic entering or leaving the Azure network will get validated against the NVA rule set too.
Azure Firewall is a fully stateful Firewall as a Service (FWaaS) and provides SNAT automatically for all outbound connectivity. SNAT essentially translates all outbound network traffic to the Azure Firewall public IP address.Azure Firewall is costly in comparison to the other answer choices provided.
Web Application Firewall(WAF)
WAF is an Azure web protection service that provides protection for web-based apps against vulnerabilities and exploits. WAF can be used in conjunction with a number of Azure services, including Application Gateway and Azure Front Door. Administrators can block incoming traffic to Azure Front Door using custom rules, based on conditions such as geolocation and IP address.
WAF Custom rules provide Azure administrators with granularity and additional control, which can enhance protection to meet various business requirements. For instance, you may have data sovereignty requirements that dictate that your web app should not be available in certain geographical locations, and this could be a result of legal or political issues.
Web App Services:
Azure web apps are available in the following plans: Free and Shared, Basic, Standard, Premium v2, Premium v3 and Isolated service plans.
VNet integration is only supported on the following plans: Standard, Premium v2, Premium v3.
Only Azure web apps that have been deployed with Standard, Premium v2, or Premium v3 service plans are compatible with Azure Traffic Manager.
Access Restriction
Access restriction rules provide an additional layer of security for Azure App Service workloads. It allows Azure administrators to create a list of allow or deny rules based on IP address or Azure virtual network subnets. Priorities can also be assigned to each rule. However, geographic locations cannot be blocked using access restriction rules.
App Service Environment:
An ASE allows you to fully isolate an Azure App Service and integrate it with an Azure virtual network. This offers full inbound and outbound connectivity control to and from your web app. This is useful when there are strict business and technical security requirements for a web app that needs to integrate with your virtual networks. For instance, there may be an on-premise application that needs inbound and outbound communication with the Azure web app without exposing it to the internet.
Azure virtual WAN
Azure Virtual WAN allows organizations to leverage the Microsoft backbone network, by connecting multiple branch offices to Azure. This is particularly useful if an organization has many offices spanning multiple geographic locations.
Hubs are critical in a Virtual WAN deployment. They offer a termination point for VPN connections for example Site-to-Site and Point-to-Site. They also offer routing for inter-VNet communication. A Hub-to-hub topology would be viable here. When you create more than one WAN hub in a single virtual WAN instance, then both hubs can communicate with each other automatically. In this scenario and with the options presented, you require a hub in each region to fulfil the requirement.
Azure virtual WAN is typically used in large organizations that consist of many branch offices across different regions. In the past, the different offices would need to connect to network resources using a combination of different technologies, including VPN tunnels and traditional Software Defined Area Network (SD WAN). Azure virtual WAN combines all of these different methods and utilizes the Microsoft backbone network to connect multiple geographical locations and offices together. Azure virtual WAN is available in two SKUs: Basic and Standard. Standard virtual WAN supports more functionality and scenarios, including the incorporation of Azure Firewall, Network Virtual Appliances, inter-virtual network connectivity and ExpressRoute.
A basic WAN SKU does not support inter-VNet connectivity. A common use case for a basic WAN is when only site-to-site VPN connectivity is required.
The typical use case for an isolated virtual WAN hub is for single-region deployments only. When two or more regions need to be connected together in an Azure virtual WAN, then a hub is required in each region. This facilitates VPN connectivity from branch offices into Azure.
You should perform the following steps in order to create S2S VPN in an Azure virtual WAN:
- Create a virtual hub.
- Create a VPN site.
- Connect the VPN site to the virtual hub.
- Add a virtual network connection to the virtual hub.
The first step is to create a virtual hub.
Azure Virtual WAN is typically used in large organizations that consist of many branch offices across different regions. In the past, the different offices would need to connect to network resources using a combination of different technologies, including VPN tunnels and traditional Software Defined Area Network (SD WAN).
Azure virtual WAN combines all of these different methods and utilizes the Microsoft backbone network to connect multiple geographical locations and offices together. A virtual hub is required in an Azure virtual WAN configuration, as it is the termination point for various connections coming into Azure.
Next, you should create a VPN site. A site is essentially a representation of your physical datacenter(s). This is required when configuring a virtual WAN.
Then, you should connect a VPN site to the virtual hub. Once the VPN site has been created and established, the next order of events in the workflow is to associate the site to the previously created virtual hub.
Finally, you should add the virtual network connection to the virtual hub. This step can only be completed once the above steps have been completed.
Otherwise, there will be no connections available to connect to.
Azure virtual WAN is available in two stock keeping units (SKUs): Basic and Standard.
Standard virtual WAN supports more functionality and scenarios, including the incorporation of Azure Firewall, Network Virtual Appliances, inter-virtual network connectivity and ExpressRoute.
Basic virtual WAN supports Site-to-Site (S2S) VPN tunnels only.
User Defined Route:
UDR is an Azure service that enables you to create and control network routes where your NVA can manage the traffic between separate subnets and direct them to the internet. When the traffic routes from the webserver to the NVA, through UDR, the firewall within the NVA will determine whether this traffic should be allowed or denied from being routed to the Application Programming Interface (API) server.
Azure Network Analysis:
Traffic Analytics is an Azure network analysis service that processes Network Security Group (NSG) flow logs. It outputs data in format that is visually digestible and readable.
To successfully use Traffic Analytics, you must also have Network Watcher and a Log Analytics workspace and, to enable this tool, your account must be a member of one of the following Azure built-in roles: Owner, Contributor, Reader, or Network Contributor.
Traffic Manager requires the following prerequisites are also in place: Network Watcher, NSG Flow logs, Storage account, and an Azure Log Analytics Workspace.
Traffic Manager Routing methods:
When you configure Azure Traffic Manager, a routing method must be selected. Choosing a performance-based routing method will ensure users get connected to the appropriate endpoint with the lowest network latency.
With the geographic routing method, an Azure administrator can analyze where the original DNS request was made from and then route traffic to the appropriate endpoint. This can assist organizations with strict data sovereignty requirements.
The Subnet routing method can be used to analyze IP ranges the traffic is originating from and then redirect traffic to the most appropriate endpoint. For example, all users from a particular branch office can be routed to the endpoint in South UK if required.
With priority routing method, a priority number can be assigned to each endpoint (for example 1,2,3). The endpoint with an assigned priority number of 1 will receive all the traffic. In the event where the primary endpoint is down, the secondary endpoint can be configured with a priority number of 2. Priority routing can be useful if you may have a critical web app running across three virtual machines. In this scenario you only have one virtual machine that is sized appropriately; the other two virtual machines have lower CPU and RAM due to budgeting cuts. In this case, you would want all traffic to be routed based on priority to the first virtual machine with adequate CPU and RAM. In the event of a failure, it may be acceptable to the business to operate on the other two virtual machines until the issue is resolved
VNET Integration:
Virtual Network integration requires a dedicated subnet in your Virtual Network. The subnet should have a minimum of /28 blocks.
Virtual Network integration requires Standard, Premium, Premium v2, or Premium v3 App service plans.
With Virtual Network integration, you can control the outbound traffic from your App Service using NSG rules. Inbound rules do not apply to the
App Service. This also means that even if you enable Virtual Network integration, the App Service does not become private to your Virtual Network.
Regional VNet integration does not require a Virtual Network Gateway. If the Virtual Network is in a different region or is deployed using a classic model, then a gateway is required to establish connectivity.
Creating a site-to-site connection:
You should perform the following steps in order:
- Deploy and configure a Virtual Network Gateway and Local Network Gateway.
- Instruct the customer to configure the on-premises VPN device and provide the shared key.
- Create a VPN connection within the Virtual Network Gateway settings.
- Connect to an Azure virtual machine from the on-premises network.
First, you should deploy and configure a Virtual Network Gateway and Local Network Gateway. As a VNet already exists in the subscription, there is no need to create a new one. A gateway needs to be created first, which will allow you to progress with the other steps. A Local Network Gateway is required in Azure as it references the on-premises network and allows Azure to communicate with the on-premises specified address ranges.
Next, you should instruct the customer to configure the on-premises VPN device and provide the shared key. Before a tunnel can be configured, the on-premises team must configure the on-premises VPN device. A shared key will also need to be created, which must be identical in Azure and on the on-premises VPN device.
Then, you should create a VPN connection within the Virtual Network Gateway settings. A VPN connection can only be created once the local network gateway and a shared key has been established.
Finally, you should connect to an Azure virtual machine from the on-premises network. The requirement states that you need to prove that the VPN tunnel works. Connecting to a virtual machine from the on-premises network is the best way to prove connectivity.
You should not generate a root certificate. This is used for point-to-site VPN connections only. When configuring a point-to-site VPN connection, you must upload the public key for a root certificate to Microsoft Azure. This ensures that the certificate will then be trusted for any point-to-site connectivity.
You should not download and configure the Azure VPN client. This is used for point-to-site VPN connections only.
You should not verify that ‘Enabled’ is showing under circuit status. This connection status is only a valid option for ExpressRoute connections. ExpressRoute is used to connect on-premises networks to Azure directly over a private connection.
Troubleshooting a site-to-site VPN connection
You should take the following steps to troubleshoot the issue:
Verify the Shared Key.
Reset the VPN Gateway.
Reset the VPN Connection.
When you reset the Virtual Private Network (VPN) Gateway, it will help to reboot the Active instance of the gateway. If this does not work, you should then reset the VPN Gateway again. This time, it will reset the standby instance also and will failover to the active instance. Note that the Azure VPN Gateway uses two instances that run an Active/Standby mode.
When you simply reset the VPN connection, the VPN tunnel is disconnected and the connection is re-established. The VPN gateway is not rebooted in this operation. Lastly, you must ensure that you use the same pre-shared key on both Azure VPN Gateway and the on-premises VPN device.
You should not change the Virtual Network Gateway type. The Virtual Network Gateway type option is used to define the role of the gateway. You can either define VPN or ExpressRoute. As the type is already set to VPN, you do not need to modify it to ExpressRoute.
You should not change the Virtual Network Gateway SKU. You can select different virtual network gateway SKUs depending on your requirements for the number of IPSec tunnels and the throughput. In the current scenario, the gateway SKU selection is fine as you are troubleshooting the problem with basic VPN connectivity.
Troubleshooting Network Traffic
You should perform the following actions in any order:
Enable Network Watcher.
Register the Microsoft.Insights provider.
Create a storage account.
Enable NSG flow log.
To enable NSG flow logs, you should enable Network Watcher in the region where your VMs are deployed. Network Watcher provides tools to monitor and collect metrics and logs from your Azure resources deployed inside a Virtual Network. Currently, Network Watcher only supports IaaS (Infrastructure as a Service) and is not intended to be used with PaaS (Platform as a Service) resources.
You should register the Microsoft.Insights provider. NSG flow logs use Azure Monitor internally to collect the logs and metrics. You should enable the Microsoft.Insights provider for the subscription where the resources are deployed.
To store the flow logs, you should create a storage account. This storage account should be in the same region and all the logs collected from NSG will be shipped to the storage account. The logs are stored in JSON format and can be viewed by downloading the files locally or shipping the files to a Security Information and Event Management system (SIEM) or an Intrusion Detection System (IDS).
You should also enable NSG flow logs. Once the flow logs are enabled, you can go and check the logs in the insights-logs-networksecuritygroupflowevent container in your storage account. In the container, navigate the folder hierarchy to find the JSON file. It follows the following naming convention for the folder hierarchy:
https://{storageAccountName}.blob.core.windows.net/insights-logs-networksecuritygroupflowevent/resourceId=/SUBSCRIPTIONS/{subscriptionID}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUP{year}/m={month}/d={day}/h={hour}/m=00/macAddress={macAddress}/PT1H.json
Bidirectional Forwarding Detection (BFD)
BFD is a link failure detection mechanism that providers a faster failover from the primary link to the secondary link in case of link failure. The Border Gateway Protocol (BGP) keep-alive and hold-time play a role in determining the link failure detection time between MSEE and customer edge routers. In most cases, the link failure detection can take up to three minutes. To reduce this link failure detection time to a few seconds, it is recommended that you enable BFD. On the MSEE, the BFD is configured by default;you only need to configure it on the local edge routers and then associate it with the BGP session.
BGP timers
BGP is the protocol that runs the internet. This protocol helps to create links with next-hop autonomous systems (AS) and keep a map of the whole internet topology. The BGP neighbors will update each other about any routing changes they might detect. BGP keep-alive is used to keep track of its neighbors. By configuring a lower BGP keep-alive timer, the link detection failure time can be improved, but this will cause significant overhead on the routers because BGP is a resource-intensive protocol.
Open Shortest Path First (OSPF):
OSPF is an Interior Gateway Protocol (IGP) based on the shortest path first algorithm. The OSPF uses concepts of an area, which comprises routing nodes, and maintains a list of all the optimal and suboptimal routes in its database. OSPF cannot be used to form peers with public internet routers.