This is part 5 of a series of networking posts:
Azure Networking Overview
Azure data centers manage the physical hardware for you. You configure virtual networks through software, which enables you to treat a virtual network just like your own network. For example, you can choose which other networks your virtual network can reach, whether that's the public internet or other networks in the private IP address space.
Azure Foundation Networking
- Virtual Network: logically isolated network on Azure that enables the flow of communication between different resources/subnets/VMs, other VNets, or to on-premises (depending on how you set it up). This is the foundation of Azure Networking and it is a Layer-3 overlay. Virtual networks are segmented into one or more subnets. Limitation of VNets: VNets cannot span regions or subscriptions. VNet Peering, ExpressRoute, or VNet-to-VNet can connect regions or subscriptions together, however.
- Address Space: usable IP addresses within your virtual network. Mainly an IPv4 environment. Public and private available.
- VNets are isolated by default. If you deploy two or more VNets in the same address space, it is fine as long as you do not intend to ever try to connect them.
- If you need to add multiple address spaces, go to your VNet resource > Settings > Address Space and add more. As you add more, you can make subnets from all added address spaces.
- Azure Reserved Addresses are needed for Azure core connectivity. /29 is the smallest and /9 is the largest you can use in Azure. Typically x.0.0.4 will be the first usable address space.
- Subnet: Subnets can help you organize and secure your resources.
- In the Portal when you create a VNet it has you define your first subnet, you can add more later or delete/modify the one you created initially.
- Network Security Group: controls ingress and egress traffic (allows or denies) to your Azure resources such as a NIC or subnet. Think of a network security group as a cloud-level firewall for your network. Prioritized set of rules based on a 5-tuple rule-set: source + destination IP, source + destination port, and protocol. Can expose only certain ports of a subnet or NIC to the Internet as well as secure the flow of traffic between subnets/NICs on the same subnet. Stateful rules and will keep track of your requests.
- Route Tables: A route table contains a set of rules, called routes, that specifies how packets should be routed in a virtual network. Route tables are associated to subnets, and each packet leaving a subnet is handled based on the associated route table. Each route table can be associated to multiple subnets, but a subnet can only be associated to a single route table.
- DNS Servers: References to DNS servers that will be assigned to the VMs or cloud server instances in the VNet. DNS resolution service is provided by default out of the box with your VNet in Azure.
- You can specify a custom DNS service
- User Defined Routes (UDR): control traffic to a much finer degree.
- Send traffic to/from IPS or IDS for monitoring/auditing.
Security
1. Policies - Azure Policies can be setup for general security to ensure that your company/team follows rules that you setup. Below are some good practices for networking specific policies:
- Keep resources within a specific region
- Prevent resources from being provision with Public IPs
- Force resources location to match their resource group
- Force certain users/prefixes to be deployed only to certain subnets (like dev/qa/prod networks)
- Constrain the Azure regions that is allowed to be deployed to (whitelisting)
2. Setup RBAC for user access.
3. Setup a User Defined Route (UDR).
4. Setup a Network Security Group (NSG).
IPSec Tunnels
Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts the packets of data sent over an internet protocol network. It is used in virtual private networks (VPNs). In tunnel mode, the entire IP packet is encrypted and authenticated. It is then encapsulated into a new IP packet with a new IP header. Tunnel mode is used to create virtual private networks for network-to-network communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access) and host-to-host communications (e.g. private chat). -
https://en.wikipedia.org/wiki/IPsec#Tunnel_mode
Connectivity Within Azure Options
- VNet Peering within Region - Connects two VNets in the same region via the backend network in Azure. No extra overhead with this and almost no latency.
- Global VNet peering - connecting VNets across Azure regions
- VNet to VNet via VPN Gateway - Leverages the Azure VPN gateway in each VNet to make the IPSec tunnel across regions or within the same region. Can also span to other customers or subscriptions easily.
- VNet to VNet via ExpressRoute - Associate multiple VNets to the same circuit. Behind the scenes, Azure will enable routing between these VNets and their different regions to all connect to each other easily. Could cause security concerns with default behavior, but can be controlled.
Hybrid Connectivity from On Premises to Azure Options
- Internet Connectivity - resources are public facing directly to Internet and you can connect from anywhere. While possible, not usually preferred by companies.
- Secure point-to-site connectivity - IPSec based tunnel that based from a client machine. Really good for individuals traveling and outside of the corp network and need to access private resources. Individual developers can use this.
- Secure site-to-site VPN connectivity - Most enterprises start here, simple IPSec tunnel over public Internet connectivity from your on-premises gateway and Azure. Connect to private IaaS and PaaS resources seamlessly, should just feel like an extension from your network.
- ExpressRoute private connectivity - Enterprise solution geared towards customer who need high throughput (~10GB range) / low latency connections. Dedicated direct connection from your datacenter to Azure (pretend there's a big cable going from your datacenter to Azure datacenter). Backed by SLA.
