Network_solutions

Purpose

This page covers notes, labs, personal setup items, deviations, etc. covered in the Design network solutions Learn module.

General Info

Apart from the standard Azure decisions like naming conventions, regions and subscription governance, networking requires a few other high level items to keep in mind.

  • IP addresses - Know your IP ranges and establish a convention (if appropriate) do visually and logically segment networks
    • e.g. 192.168.x.x are LAN (physical) networks
    • 10.x.0.0 are cloud subnet ranges
    • 10.xx.0.0 are cloud gateway
    • 10.xx.y.0 are cloud LAN subnets
    • 10.xx.z.0 are DMZ subnets
  • NEVER overlap ranges with on-prem
  • Have a clear traffic filtering strategy and stick to it
    • public systems exist only on public subnets, multi-nic deployments as needed, etc.
  • Lean on service endpoints to keep traffic on the Azure backbone and not the internet
    • Be aware that monitoring and filtering systems will not govern this traffic in user defined routing

Azure Firewall

  1. Azure Firewall is the native control mechanism for networks.
    • It’s ridiculously expensive and borderline unaffordable for most SMBs so plan on using an NVA.
      • Basic firewall is barely worth mentioning as far as features go and the huge jump in cost for Standard is a hard pill to swallow. That being said, there are security features, layer 7 routing, TLS proxy, etc. that are included in the Standard and Premium SKUs that are worth it for larger orgs.
  2. Azure Firewall controls layer 3 through layer 7 traffic
    1. This is the root difference between NSGs and Firewall. NSGs only operate on Layer 3 (Packet/IP address)
  3. You can plan policies in Azure Firewall Manager and apply across any/all Azure Firewalls
    • Policy is region unique - so three regions will require three policies with each policy scoped to 1:n Azure Firewalls in each region

Network Topology

Azure networks typically go with a single network or move into a hub and spoke deployment model. Some important things to keep in mind.

  • VNETs cannot span regions
  • Peering connections can group vnets across regions and subscriptions
  • hub-spoke design can bet accomplished via user defined routes, peering, etc. and is recommended for a more zero-trust approach to network segmentation.

Outbound Traffic

  1. Azure Virtual NAT (NAT Gateway) is pretty slick for outbound traffic. e.g. throw a NAT gateway in front of resources so other systems can create access rules based on the NAT gateway’s public IP.
    • Works great for other services than just VNETs. AKS, Container groups, function apps, App Services, etc.
  2. Simple setup - configure the subnet to use a NAT gateway and all routing is done.
  3. User Defined Routes are necessary to override default system routes.
    • e.g. NVA appliance is supposed to filter traffice between Subnet 1 and Subnet 2: Subnet 1 and Subnet 2 must both have custom routes defined to route traffic to each subnet through the NVA appliance as the next hop address

On-Prem Connections

A lot of this is AZ-104 information, basically, know what the options are and what features are unlocked at different standard/premium tiers.

  1. Azure VPN Gateway
  2. Azure ExpressRoute
  3. Azure ExpressRoute with VPN Failover
    1. Premium feature
  4. Azure Virtual WAN

Load Balancing

There are two primary dimensions that determine the type of load balancing solution to use.

  1. Global or Regional
  2. HTTP(s) or non-HTTP(S)

These then fall into a few other considerations with a handy flowchart that serves as a starting point to help choose.

  • Public or Private
  • Availability (SLA requirements)
  • Routing
  • Cost load balance flow chart load balance flow chart

Load Balancing Options

  1. Azure CDN - A global content delivery network - cache your content adjacent to your Azure services (all eggs in one basket though). Useful to project presence closer to users, reduce latency along with custom domains, file compression and geo-filtering.
  2. Front Door
    • Global routing for web traffic with global failover. Layer 7 routing and TLS offloading.
    • Integrated WAF
  3. Traffic Manager
    • DNS-based traffic load balancing across azure regions. Use this for cross region traffic that doesn’t require TLS offloading.
  4. Load Balancer
    • Internal network load balancing between appliances and scenarios. e.g. back-end routing/balancing between front end systems and database systems.
  5. Application Gateway
    • Regional layer 7 routing with SSL/TLS termination but not offloading. The little brother to Azure Front Door where the requirement is not a global one.
    • Path-based routing (URL endpoint routing)
      • Front Door in front of regional Application Gateways is also a thing but that’s a huge edge case.

Protection Services

Some minimal information here until design solutions call for a deeper dive.

  • Azure DDoS: It’s a service, it exists and you get access to DDoS experts during an attack
    • Always-on traffic monitoring and adaptive tuning
  • Azure Private Link - A really nifty way to access PaaS services (Storage, SQL Database, etc.) via IP address.
    • It also integrates with on-premises and peered networks
    • A private endpoint in your VNET is created that routes to (for example) an Azure SQL Database
    • VNET resources can route traffic to that IP address
    • Traffic is sent over the Azure backbone (not public internet) to the PaaS resource
  • Azure WAF - A mini firewall and OWASP filter for web applications.
    • Deploy with Application Gateway, Front Door and/or CDN
  • NSGs - pretty well known, restrict access and monitor traffic
  • Service Endpoints
    • Similar to the Private Link but without the IP address
    • Service Endpoint is added to the NSG for a resource and traffic is routed to the appropriate Azure PaaS options on the Azure backbone
  • Azure Bastion - Another slick but cost-prohibitive solution to enable RDP/SSH access to resources in Azure from the Azure Portal.
    • Pretty asinine that Azure doesn’t even provide a “local” desktop viewer for services like VMWare and charges you through the nose for private access.
  • Just In Time access - Integrates with RBAC mechanisms and NSG rules to allow traffic to a resource from your public IP address when requested. If user requests access, is not explicitly denied access, NSG rules are enabled for the users public IP to grant access for a specific amount of time.