Azure-in-bullet-points

Connecting VNets

You don’t need to have a Layer 3 router to route traffic from subnet to subnet
Azure system routes take care of the routing for you automatically

Options

VPN Gateway

Creates IPsec/IKEv2 tunnel and always-on connection
Used for connecting VPN’s in cloud or hybrid scenario.

Inside Azure

VNet-to-VNet VPN

Create isolation or administrative boundaries
Provide cross-region geo-redundancy and replication securely
No traffic crosses the public internet
Separate VPN gateways costs while VNet peering is free.
💡 Make sure your VNet address spaces do not overlap.
Troubleshooting
- Verify connectivity through peering
  - Set up Azure DNS

VNet peering

❗ Seamless connection between two Azure VNets.
- The peered networks appear as one, for connectivity purposes.
- Name resolution does not flow, requires own DNS zone
Runs on Azure backbone
💡 You can peer across regions and subcriptions
Peering can overcome misplaced VMs
Save money with service chaining (e.g. services’ communication are chained through a subnet)
❗ Peering must be done on both sites
- VNet1 <=> VNet2 and VNet2 <=> VNet1
Configuration
- Allow forwarded traffic
  - Am I peering from a hub VNet that’ll have IP-forwarder?
  - Allow peers (other VNets) to forward traffic to go through.
- Allow gateway transit
  - Am I hosting a VPN gateway?
- Use remote gateways
  - Is this network use peers gateway?
  - ❗ VNets must be in same region
Enables force tunnelling
- E.g. when all Internet traffic must go through on-premises firewall device.
- You can use user defined routes for all outbound traffic to go back through VPN gateway to on-premises.
❗ Peerings are not transitive
- If you peer spoke1 <=> spoke2 and spoke2 <=> spoke3 then spoke1 cannot communicate with spoke3 automatically.
- Common solution is transiting VNet with Hub and Spoke topology.
  - Topology is a segmentation
    - When to segment with VNets and when with subnets?
      - Depends on bureaucratic reasons
      - E.g. different VNets when
        
        Different cost centers/groups need management autonomy
        
        You want to completely isolate different workloads
  - Name resolution needs configurations
    - You can’t do with Azure provided DNS as all your hosts have then internal.cloudapp.net
    - In peering azure provided DNS won’t work
Troubleshooting tips
- Azure blocks ICMP between Vnets and the Internet
  - ICMP is used for ping
  - Microsoft blocks it because of DDoS attacks.
- Simplify NSGs as much as possible to reduce troubleshooting friction
- Azure portal Diagnose and solve problems/Resource health blade is useful
- Network Watcher and Network Permormance Monitor make troubleshooting much easier
  - Network Watcher
    - Shows where’s the traffic is captured/denied
    - Suite of tools
      - Topology: e.g. VNet’s, subnets, VM’s, NIC’s
      - Variable Packet Capture: Captures TCP packages at NIC level as wireshark files.
      - IP Flow Verify: Troubleshoots NSG
      - Next hop: Troubleshoots route tables
      - Connection troubleshoot: Why it does not connect?
      - Diagnostics Logging
      - Security Group View
      - NSG Flow Logging
      - VPN Gateway Troubleshooting
      - Network Subscription Limits
      - Role Based Access Control
    - In Portal you can search for Network Watcher and enable it on VM’s
  - Network Performance Monitor
    - E.g. top network health events, expressroute monitor, service endpoint monitor, performance monitor
    - It ties in logs/metrics with Log Analytics.
    - Part of Insights & Analytics Azure management solution.
    - Works with installing Microsoft Monitoring Agent (MMA) in VM.
    - Flow
      1. Deploy Insight & Analytics and then select Network Performance Monitor
      2. Choose VM and click on “Connect”, it’ll install MicrosoftMonitoringAgent

Hybrid Connections

Site-to-site VPN

Two VPN devices connect to each other.
Flow
1. Deploy a VPN Gateway resource in Azure
  - Requires gateway subnet (or DMZ subnet).
  - Different SKUs: Basic, VpnGw1, VpnGw2, VpnGw3
    - You get more bandwith, site-to-site and point-to-site points.
    - Don’t use basic for production
  - You can see the deployed VPN Gateway in Connected Devices in subnet.
2. Deploy a Local Network Gateway as well.
  - For your on-prem gateway device, you need to set up one of the route table configurations:
    - PolicyBased
    - Handle route tables manually
    - ❗ Does not work with BGP failover, active-to-active configurations
    - RouteBased
    - 💡 Always use if possible
      - Some VPN devices do not support it
      - What’s compatible is documented on Microsoft docs.
3. Create a connection between two gateways
  - Create local-to-azure in Local Network Gateway
  - Create azure-to-local in VPN Gateway
  - In Shared Key in connection blade, specify a key.

Point-to-site VPN

- ALlows access to Azure resources through VPN tunnel from a client agent.
- More portable way
- ***Flow***
    1. On Azure deploy VPN gateway
    2. In Point-to-site configuration blade download VPN client
    3. Deploy agent (a VPN Client) from VPN gateway
    4. Install on individual endpoints (e.g. laptops)
- Allows connection outside network perimeter

Express route

High speed secure connection between on-prem and cloud

Best practices for High Availability

Combine ExpressRoute and VPN
- In gateway subnet
  - Deploy ExpressRoute gateway
  - Deploy VPN Gateway
- Both gateways gives access to front-end tier and a jumpbox in a management subnet
- If ExpressRoute goes down VPN gateway gets activated
Deploy two VPN’s
- Requires enabling BGP in gateway link
  - Robust routing
  - Enable active-to-active connection configuration
  - ❗ Only allowed RouteBased routing configuration
- Two VPN gateways on-prem
  - Allows redundant active-to-active connection to single gateway.
  - You have one active and one stand-by gateway

Routing

System Routes vs. User-defined Routes
- Situations
  - You need to move one VM to another VNet.
    - It requires re-deploying
  - Isolation & segmentations
    - E.g. development / production VNet
  - Hub & Spoke Topology
    - Hub: VNet have Virtual Network Appliance (e.g. firewall), or gateway
      - You don’t want to have Virtual Network Appliance as it costs both money and resources.
    - Spokes
      - Other VNets (e.g. front-end, back-end)
      - You can force communicates with each other through Hub.
- Internet calls and calls from internet
  - Handled by Azure using system routes
  - You don’t need to manipulate them
- If you want to override system routes (e.g. for Hub & Spoke topology)
  - You need User Defined Routing
  - For network appliance you need to configure IP forwarding
    - Enables it to pass on traffic that it’s not destined for itself.

This site is open source. Improve this page.