Your Azure private network starts with a VNet. Azure Virtual Machines (VMs) can securely interact with each other, the internet, and on-premises networks using VNet. VNet is like a data center network but with Azure’s size, availability, and isolation.
Subnets allow you to implement logical divisions inside of your virtual network in a manner that is manageable. Your network can be divided up into different subnets, which will help improve its security, boost its performance, and make it much simpler to handle.
Reserved addresses
Azure reserves five IP addresses per subnet.
| Reserved address | Reason |
|---|---|
192.168.1.0 | This value identifies the virtual network address. |
192.168.1.1 | Azure configures this address as the default gateway. |
192.168.1.2 and 192.168.1.3 | Azure maps these Azure DNS IP addresses to the virtual network space. |
192.168.1.255 | This value supplies the virtual network broadcast address. |
when using subnets
- Service requirements Each service directly deployed into a virtual network has routing and traffic needs for associated subnets. A service may need or build a subnet. There must be enough unallocated space for support. If you use Azure VPN Gateway to link a virtual network to an on-premises network, The virtual network’s router needs a subnet.
- Network virtual appliances Azure routes network data between all virtual network subnets by default. To avoid Azure routing between subnets, override its default routing. You can also route subnet data through a network virtual appliance. If you need traffic between resources in the same virtual network to flow through a network virtual appliance, deploy the resources to separate subnets.
- Service endpoints With a virtual network service endpoint, you can restrict access to Azure services like storage accounts and SQL databases to specific subnets. You can also block internet services. You can enable a service endpoint for some subnets but not others after creating numerous subnets.
- Network security groups Virtual network subnets can have zero or one network security group. Each subset can have a network security group. Each network security group allows or denies data to and from sources and destinations.
- Private links Azure Private Link connects virtual networks to Azure PaaS, customer-owned, or Microsoft partner services. Private Link streamlines and ensures Azure endpoint connections. The service prevents internet data exposure.
IP address
There are two types of Azure IP addresses: private and public.
Private IP addresses In order to exchange data between your on-premises network and an Azure virtual network, you will need a private IP address. When you expand your network to Azure via a VPN gateway or an Azure ExpressRoute circuit, you generate a private IP address for your resource.
Public IP addresses enable internet communication for your resource. Azure public-facing services can be accessed with a public IP address.
Network security groups
By utilizing a network security group, you will be able to restrict the network activity that is allowed to resources within your virtual network. A network security group can be assigned to a subnet or a network interface, and security rules can be defined within the group to regulate the flow of network traffic.
Network security groups and subnets A subnet can be protected by network security groups (also referred to as a demilitarised zone or DMZ). DMZs protect virtual network resources from the internet.
- Use the network security group to restrict traffic flow to all machines that reside within the subnet.
- Each subnet can have a maximum of one associated network security group.
Network security groups and network interfaces
- Define network security group rules to control all traffic that flows through a NIC.
- Each network interface that exists in a subnet can have zero, or one, associated network security groups.
Network security group rules
In network security groups, security rules allow you to filter network traffic. You can define rules to regulate the flow of traffic between virtual network subnets and network interfaces.
Characteristics of security rules
Azure defaults inbound and outbound data security rules for each network security group. DenyAllInbound and AllowInternetOutbound are preset rules.
Azure creates the default security rules in each network security group that you create.
You can add more security rules to a network security group by specifying conditions for any of the following settings:
- Name
- Priority
- Port
- Protocol (Any, TCP, UDP)
- Source (Any, IP addresses, Service tag)
- Destination (Any, IP addresses, Virtual network)
- Action (Allow or Deny)
Security rules are prioritized. Network security group security rules are prioritized. Low Priority rules have higher order execution priority.
You can override a default security rule by making a security rule with a higher Priority for your network security group but You can’t remove the default security rules.
Effective security rules
The Azure portal’s Effective security rules link can help you determine which security rules are applied to multiple network security groups. The link shows your machines, subnets, and network interfaces’ security rules.
Application security groups
In order to properly categorize your virtual machines in Azure by workload, you can create application security groups. Once you have established your application security groups, you can use them to outline the guidelines for your network security groups.
Azure Firewall
Azure Firewall secures Azure Virtual Network resources with managed, cloud-based network security. It’s a stateful firewall as a service with unlimited cloud scaling and high availability. Across subscriptions and virtual networks, you can centrally define, enforce, and log application and network connectivity rules.
| Feature | Description |
|---|---|
| Public IP address | Azure Firewall uses a static public IP address for your virtual network resources. External firewalls identify traffic originating from your virtual network by the IP address. Note: You can associate multiple public IP addresses with your firewall. |
| Built-in high availability | With Azure Firewall, you gain built-in high availability without any extra configuration requirements. You don’t need to implement other load balancers. |
| Availability zones | Configure Azure Firewall during deployment to span multiple availability zones for increased availability. |
| Unrestricted cloud scalability | Azure Firewall offers unrestricted cloud scalability to scale as needed to accommodate changing network traffic flows. You don’t need to budget for your peak traffic. |
| Application FQDN filtering rules | Azure Firewall lets you limit outbound HTTP/S traffic or Azure SQL traffic to a specified list of fully qualified domain names (FQDN) including wild cards. |
| Network traffic filtering rules | Create network filtering rules in Azure Firewall to allow or deny traffic by source and destination IP address, port, and protocol. Azure Firewall is fully stateful. The service can distinguish legitimate packets for different types of connections. Rules are enforced and logged across multiple subscriptions and virtual networks. |
| Threat intelligence | Azure Firewall supports threat intelligence-based filtering. Configure your firewall to alert and deny traffic from/to known malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed. |
| Azure Monitor integration | Azure Firewall is fully integrated with Azure Monitor for logging and analytics. |
Hub-spoke network topology
Hub: Your on-premises network is connected to Azure’s hub.
Spokes: Workloads can be isolated using spokes, virtual networks that peer with the hub.
Azure ExpressRoute, VPN Gateway, or Bastion connects an on-premises server to the hub network.
Azure Firewall rules
All communication attempts to pass through your virtual network will be blocked by default by the Azure Firewall. The purpose of the behavior that is set as the default is to offer the highest degree of protection possible against access that is either malicious or unknown. In order to enable traffic for a specific resource or service, you will first need to specify the rules that will be used to manage that traffic.
Azure Firewall Rules : NAT, Network, and Application
NAT rules
Convert your firewall’s public IP and port to private ones.
- Name: Provide a label for the rule.
- Protocol: Choose the TCP or UDP protocol.
- Source Address: Identify the address as * (internet), a specific internet address, or a classless inter-domain routing (CIDR) block.
- Destination Address: Specify the external address of the firewall for the rule to inspect.
- Destination Ports: Provide the TCP or UDP ports that the rule listens to on the external IP address of the firewall.
- Translated Address: Specify the IP address of the service (virtual machine, internal load balancer, and so on) that privately hosts or presents the service.
- Translated Port: Identify the port that the inbound traffic is routed to by Azure Firewall.
Network rules
Your firewall must have a network rule for non-HTTP/S data. In a scenario where subnet resources must interact, You can set a network rule from the source to the destination in this case.
- Name: Provide a friendly label for the rule.
- Protocol: Choose the protocol for the rule, including TCP, UDP, ICMP (ping and traceroute), or Any.
- Source Address: Identify the address or CIDR block of the source.
- Destination Addresses: Specify the addresses or CIDR blocks of the destination(s).
- Destination Ports: Provide the destination port of the traffic.
Application rules
Accessible fully qualified domain names (FQDNs) from a given subnet are specified by application rules. For instance, you may need to permit Windows Update network activity through the firewall.
- Name: Provide a friendly label for the rule.
- Source Addresses: Identify the IP address of the source.
- Protocol:Port: Specify HTTP or HTTPS and the port that the web server is listening on.
- Target FQDNs: Provide the domain name of the service, such as www.contoso.com. Wildcards (*) can be used. An FQDN tag represents a group of FQDNs associated with well-known Microsoft services. Example FQDN tags include Windows Update, App Service Environment, and Azure Backup.
Domain name system (DNS)
Azure DNS gives you the ability to host your DNS domains in Azure and obtain name resolution for your domains.
Azure Private DNS zones
Azure Private DNS zones can be made using custom domain names instead of Azure. With custom domain names, you can tailor your virtual network design to your organization’s needs. You can resolve virtual machine names within and between virtual networks. Split-horizon DNS zone names allow a private and public DNS zone to share the same domain name.
Azure Virtual Network peering
Peering in Azure Virtual Networks gives users the ability to combine virtual networks located in the same region or in different regions
Private network connections, Strong performance, Simplified communication, Seamless data transfer, No resource disruptions
Azure account must be assigned to the Network Contributor or Classic Network Contributor role
Gateway transit and connectivity
When virtual networks are peering with one another, you will have the option to establish Azure VPN Gateway in the peering virtual network to act as a transit point.
- A virtual network can have only one VPN gateway.
- Gateway transit is supported for both regional and global virtual network peering.
- When you allow VPN gateway transit, the virtual network can communicate to resources outside the peering. In our sample illustration, the gateway subnet gateway within the hub virtual network can complete tasks such as:
- Use a site-to-site VPN to connect to an on-premises network.
- Use a vnet-to-vnet connection to another virtual network.
- Use a point-to-site VPN to connect to a client.
- Gateway transit allows peered virtual networks to share the gateway and get access to resources. With this implementation, you don’t need to deploy a VPN gateway in the peer virtual network.
- You can apply network security groups in a virtual network to block or allow access to other virtual networks or subnets. When you configure virtual network peering, you can choose to open or close the network security group rules between the virtual networks.
Extending peering
Hub and spoke network
When you deploy a hub-and-spoke network, the hub virtual network can host infrastructure components like a network virtual appliance (NVA) or Azure VPN gateway. All the spoke virtual networks can then peer with the hub virtual network. Traffic can flow through NVAs or VPN gateways in the hub virtual network.
User-defined route (UDR)
Virtual network peering enables the next hop in a user-defined route to be the IP address of a virtual machine in the peered virtual network or a VPN gateway.
Service chaining
Service chaining lets you define UDRs. These routes direct traffic from one virtual network to an network virtual appliance or VPN gateway.
Azure VPN Gateway
A virtual private network (VPN) provides a secure internet link for organizations and their users. To avoid unauthorized access and attacks, a VPN hides or changes an IP address. Azure VPN Gateway encrypts data between Azure virtual networks and on-premises locations over the internet or the Microsoft network.
When using VPN gateways
Site-to-site (S2S)
- Connect your on-premises data centers to your Azure virtual networks through an IPsec/IKE (IKEv1 or IKEv2) VPN tunnel
- Support cross-premises and hybrid configurations
- Configure S2S VPN and Azure ExpressRoute for the same virtual network
- Configure S2S VPN as a secure failover path for ExpressRoute
- Use S2S VPNs to connect to sites outside your network that are connected through ExpressRoute
Point-to-site (P2S or User VPN)
- Connect individual devices to your Azure virtual networks
- Create a secure connection to your virtual network from an individual client computer
- Useful for remote or traveling workers who want to connect to Azure virtual networks from their current location
- Support a few clients that need to connect to a virtual network
Virtual network to virtual network (VNet-to-VNet)
- Connect one virtual network to another virtual network through an IPsec/IKE VPN tunnel
- Build a network that integrates cross-premises connectivity with inter-virtual network connectivity by combining VNet-to-VNet communication with multi-site connection configurations
- Connect virtual networks in the same or different regions
- Connect virtual networks in the same or different subscriptions
- Connect virtual networks that have the same or different deployment models
Highly available
- Support high availability for cross-premises and VNet-to-VNet connections
- Implement high availability for multiple on-premises VPN devices
- Implement high availability for an active-active Azure VPN gateway
- Implement high availability for a combination of multiple on-premises VPN devices and an active-active Azure VPN gateway
VPN gateway type
Route-based VPNs use IP forwarding or routing tables to send packets to their tunnel interfaces. The VPN tunnel interfaces then encode or decrypt packets. Route-based VPNs use any-to-any data selectors (or wild cards).
Policy-based VPNs use IPsec rules to encrypt and route packets. Your on-premises network and Azure virtual network address prefixes are used to set the policies. In the VPN device setup, the policy (traffic selector) is an access list.
Azure ExpressRoute and Azure Virtual WAN
Your on-premises networks can link to Microsoft cloud services via Azure ExpressRoute’s high-speed private connection. The Azure Virtual WAN networking tool integrates networking, security, and routing into a single interface.
In active-active mode, the Microsoft network manages Azure ExpressRoute circuits’ primary and secondary connections. Administrators can cause redundant ExpressRoute circuit connections to work in active-passive mode.
Azure Virtual WAN inter-site connections reach Azure virtual networks. Azure ExpressRoute connects on-premises. Several branches link site-to-site, and remote users connect point-to-site (User VPN).
Network routing and Endpoints
System routes are used by Azure to route data between virtual computers, on-premises networks, and the internet. A route table keeps track of the routes that the system uses.
All network traffic routing is done automatically by Azure, but in some cases, a custom configuration is better. You can set up user-defined routes (UDRs) and next hop targets for these situations.
characteristics of user-defined routes
- UDRs control network traffic by defining routes that specify the next hop of the traffic flow.
- The next hop can be one of the following targets:
- Virtual network gateway
- Virtual network
- Internet
- Network virtual appliance (NVA)
- Similar to system routes, UDRs also access route tables.
- Each route table can be associated to multiple subnets.
- Each subnet can be associated to one route table only.
- There are no charges for creating route tables in Microsoft Azure.
Service Endpoints
A virtual network service endpoint gives the Azure service information about the identity of your virtual network. When you have finished enabling service endpoints in your virtual network, you can protect Azure service resources connected to your virtual network by adding a virtual network rule to the resources themselves.
The traffic to an Azure application from a virtual network originates from a public IP address. By configuring a service endpoint, traffic originating from a private virtual network can reach an Azure service without ever leaving the private network. Because this router uses private IP addresses, it eliminates the need for the designated public IP addresses required by most IP firewalls.
characteristics of service endpoints
- Service endpoints can extend your virtual network identity to your Azure services to secure your service resources.
- You secure your Azure service resources to your virtual network by using virtual network rules.
- Virtual network rules can remove public internet access to resources, and allow traffic only from your virtual network.
- Service endpoints always take service traffic directly from your virtual network to the service on the Microsoft Azure backbone network.
- Service endpoints are configured through the subnet. No extra overhead is required to maintain the endpoints.
Azure Load Balancer
Many applications necessitate the ability to recover quickly from failures and to simply expand to meet rising demand. Businesses can solve these problems by deploying an Azure Load Balancer.
Distribution modes
Azure Load Balancer uses a five-tuple hash-based distribution mode by default. Each session’s source port is included in the hash, so clients may be directed to a different virtual machine.
Five-tuple hash
- Source IP: The IP address of the requesting client.
- Source port: The port of the requesting client.
- Destination IP: The destination IP of the request.
- Destination port: The destination port of the request.
- Protocol type: The specified protocol type, TCP or UDP.
Source IP affinity
This delivery mode is called session affinity or client IP affinity. Source IP affinity mode uses a two- or three-tuple hash to map data to available servers (from the source IP address, destination IP address, and protocol type). A client’s requests are always sent to the same virtual server behind the load balancer grateful to the hash.
Public load balancer
Administrators use public load balancers to direct data from external IP addresses and ports to internal addresses and ports used by virtual machines. Virtual machine responses are also supported in the mapping configuration. Incoming web request traffic can be distributed evenly across numerous web servers using this method.
Internal Load Balancer
Internal load balancers route traffic to virtual network or VPN-accessible Azure resources. In this setup, internet endpoints never see front-end IP addresses or virtual networks. Azure hosts internal line-of-business applications, which are viewed from Azure or on-premises.
Back-end Pools
Each load balancer has one or more back-end pools that are used to distribute traffic. The IP addresses of the virtual NICs that are linked to your load balancer are in the back-end pools.
Health Probes
With a health probe, your load balancer can check on how your application is doing. The probe adds or removes virtual machines from your load balancer’s rotation based on how the machines respond to health checks. When a probe doesn’t respond, the load balancer stops sending new connections to the unhealthy instance.
Azure Application Gateway
Azure Application Gateway is a way to spread out the load of web traffic. Administrators use an application gateway to control how much traffic goes to their web apps.
An application gateway checks messages sent through protocols like HTTP/HTTPS that come in to web apps. Gateway rules send traffic to a back-end pool of resources.
About Azure Application Gateway
| Benefit | Description |
|---|---|
| Application layer routing | In order to route requests to a specific set of web servers in the backend, application layer routing must be used. In addition to Azure App Service, Azure Virtual Machine Scale Sets, and on-premises servers, Azure can also be used as part of the back-end pool. |
| Round-robin load balancing | Use round-robin load balancing to send new traffic to different servers. Send requests to the servers in each back-end pool to spread out the load. Client requests are sent in a loop through a group of servers to make sure that the server load is balanced. |
| Session stickiness | Session stickiness is a feature you can add to your application gateway to make sure that requests from clients in the same session are sent to the same back-end server. |
| Supported protocols | Build an application gateway that supports the HTTP, HTTPS, HTTP/2, or WebSocket protocols. |
| Firewall protection | Implement a web application firewall to protect against web application vulnerabilities. |
| Encryption | Support end-to-end request encryption for your web applications. |
| Load autoscaling | Dynamically adjust capacity as your web traffic load changes. |
Traffic Routing
Path-based routing sends requests to different pools of back-end servers based on the URL paths.
Multi-site routing sets up more than one web application on the same instance of the application gateway.
Path-based routing
Path-based routing routes URL queries to the right back-end pool. Path-based routing can send /video/* queries to a back-end pool of video streaming servers. A pool of servers can manage /images/* image requests.
Multi-site routing
Multi-site routing is the best choice when you need to support more than one web app on the same application gateway instance. Multi-site configurations are useful for supporting multi-tenant applications, where each user has their own set of virtual machines or other resources that host a web application.
Application Gateway components
The front-end IP address receives the client’s requests.
An optional web application firewall checks incoming traffic for common threats before the requests reach the listeners.
One or more listeners receive the traffic and route the requests to the back-end pool.
Routing rules define how to analyze the request to direct the request to the appropriate back-end pool.
A back-end pool contains web servers for resources like virtual machines or Virtual Machine Scale Sets. Each pool has a load balancer to distribute the workload across the resources.
Health probes determine which back-end pool servers are available for load-balancing.
Azure DNS
Azure DNS is a hosting service for DNS domains that provides name resolution by using Microsoft Azure infrastructure.
Azure routing
Network traffic in Azure is automatically routed through Azure subnets, virtual networks, and on-premises networks. This routing is controlled by system routes, which are given by default to each subnet in a virtual network. With these system routes, any Azure virtual machine that is put into a virtual network can talk to any other machine in the network. These virtual machines could also be accessed from on-premises using a hybrid network or the internet.
Azure Border gateway protocol
Through BGP, a network gateway on-premises can communicate with a network gateway in Azure to share routing information. By and large, BGP is the algorithm of choice for exchanging routing and information between multiple networks. Through the use of BGP, information can be transferred between various host nodes in a network, such as the internet or between autonomous systems.
BGP offers network stability, because routers can quickly change connections to send packets if a connection path goes down.
Network virtual appliance (NVA)
You will find a variety of providers of NVAs in the Azure Marketplace, from which you can select one to install. Companies like Cisco, Check Point, Barracuda, Sophos, WatchGuard, and SonicWall are examples of such companies. You can use a network virtual appliance (NVA) to filter traffic that is entering a virtual network, prevent requests that are malicious, and block requests that are made from unexpected resources.
A network virtual appliance (NVA) is a virtual appliance that consists of various layers like
- a firewall
- a WAN optimizer
- application-delivery controllers
- routers
- load balancers
- IDS/IPS
- proxies
There are different ways to put firewall appliances into a virtual network. You can put a firewall appliance in a subnet of a perimeter network in a virtual network, or you can use micro-segmentation to give you more control over security.
ππ’π¬ππ₯ππ’π¦ππ« – All the post has only been shared for technology-related educational and knowledge-sharing purposes. Information was obtained from the source above and credited to the author or product/service company. There is no endorsement of any products or services.
