- 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
- Creates IPsec/IKEv2 tunnel and always-on connection
- Used for connecting VPN's in cloud or hybrid scenario.
- 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
- Verify connectivity through 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
- Allow forwarded traffic
- 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
- When to segment with VNets and when with subnets?
- 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
- You can't do with Azure provided DNS as all your hosts have then
- Topology is a segmentation
- 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
- Deploy Insight & Analytics and then select Network Performance Monitor
- Choose VM and click on "Connect", it'll install
MicrosoftMonitoringAgent
- Network Watcher
- Azure blocks ICMP between Vnets and the Internet
- Two VPN devices connect to each other.
- Flow
- 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.
- 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.
- For your on-prem gateway device, you need to set up one of the route table configurations:
- 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.
- Deploy a VPN Gateway resource in Azure
- 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
- High speed secure connection between on-prem and cloud
- 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
- In gateway subnet
- 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
- Requires enabling BGP in gateway link
- 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.
- Hub: VNet have Virtual Network Appliance (e.g. firewall), or gateway
- You need to move one VM to another VNet.
- 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.
- Situations