The Hybrid Reality Most Organisations Are Living In
Despite years of cloud-first mandates, the majority of enterprise Azure environments are hybrid. Active Directory is still on-premises. Some databases haven't moved. Legacy line-of-business applications are too expensive or too risky to modernise. Finance systems require low-latency access to local infrastructure. The list of reasons to maintain on-premises connectivity is real and legitimate.
What is not always legitimate is how that connectivity gets secured. The same Azure environment that has a carefully designed hub-spoke topology with Azure Firewall Premium often has an ExpressRoute circuit or VPN Gateway that routes traffic directly into spoke VNets with no inspection at all. The cloud perimeter is hardened. The hybrid connection is a hole.
A compromised on-premises server with a routed path into Azure can move laterally through your Azure environment if hybrid traffic isn't inspected. Likewise, a compromised Azure workload can pivot back to your datacentre. Hybrid connectivity without inspection in both directions is a bidirectional risk.
ExpressRoute vs VPN Gateway: The Security Perspective
The choice between ExpressRoute and VPN Gateway is usually framed as a performance and cost decision. From a security standpoint both have distinct characteristics worth understanding before you choose.
ExpressRoute
ExpressRoute is a private dedicated circuit between your on-premises network and Microsoft's network — it does not traverse the public internet. Traffic flows through a connectivity provider's infrastructure directly into Azure. This gives you:
- No public internet exposure — the connection itself cannot be intercepted or attacked from the internet
- Consistent, predictable bandwidth — no contention with internet traffic
- Lower latency — critical for latency-sensitive workloads like SAP or SQL Server
- MACsec encryption available on ExpressRoute Direct circuits for Layer 2 encryption at the port level
The security caveat: ExpressRoute does not encrypt traffic at Layer 3 by default. Anyone with access to the connectivity provider's infrastructure or your co-location facility can theoretically inspect your traffic. For most organisations the private nature of the circuit is sufficient. For highly regulated industries or government environments, running IPSec over ExpressRoute adds encryption at the cost of some bandwidth overhead.
VPN Gateway
VPN Gateway connects your on-premises network to Azure over an encrypted IPSec/IKE tunnel across the public internet. The encryption is the default — you get it without any additional configuration. Key security characteristics:
- Encrypted by default — IPSec AES-256 end-to-end
- Internet-traversing — encrypted but still crosses public networks
- Lower bandwidth ceiling — up to 10 Gbps on the highest VpnGw5 SKU vs 100 Gbps on ExpressRoute Direct
- Higher latency variability — subject to internet conditions
- Built-in redundancy — active-active configuration provides gateway-level HA
| Factor | ExpressRoute | VPN Gateway |
|---|---|---|
| Encryption | Layer 3 optional (IPSec over ER) | IPSec by default |
| Internet exposure | None — private circuit | Encrypted tunnel over internet |
| Max bandwidth | Up to 100 Gbps (Direct) | Up to 10 Gbps (VpnGw5) |
| Latency | Consistent, low | Variable (internet-dependent) |
| Cost | Higher — circuit + port fees | Lower — gateway SKU only |
| Setup complexity | Higher — provider required | Lower — self-service |
| Best for | Enterprise, regulated, latency-sensitive | SMB, DR, branch connectivity |
| SLA | 99.95% with redundancy | 99.9% active-active |
Many enterprises run both: ExpressRoute as the primary path for production traffic, VPN Gateway as a failover for when the ExpressRoute circuit goes down. This coexistence pattern gives you the performance and privacy of ExpressRoute with the encrypted failover of VPN. Configure BGP route weights appropriately so traffic prefers ExpressRoute under normal conditions.
Firewall Placement in Hybrid Architectures
Where you place your firewall relative to your hybrid connection determines whether on-premises-to-Azure traffic is inspected. This is the single most consequential architectural decision in a hybrid security design, and it is surprisingly often done wrong.
Firewall in the Hub, All Hybrid Traffic Inspected
The ExpressRoute Gateway or VPN Gateway sits in the hub VNet's GatewaySubnet. A User Defined Route forces all traffic arriving from on-premises toward Azure Firewall before it reaches any spoke. Spoke VNets cannot be reached from on-premises without the traffic passing through the firewall first.
How it works: Create a UDR on the GatewaySubnet with a default route (0.0.0.0/0) pointing to Azure Firewall's private IP. This intercepts all traffic arriving via the gateway before it is forwarded to spokes. Azure Firewall then applies network rules, application rules, and IDPS signatures to that traffic.
Why it matters: A compromised on-premises server attempting lateral movement into Azure hits the firewall first. Malicious traffic — C2 callbacks, lateral movement attempts, data exfiltration — can be blocked before it reaches a spoke workload.
Gateway Directly Peered to Spokes — No Inspection
The ExpressRoute or VPN Gateway is in a hub VNet but the hub has no firewall. Spokes are peered with AllowGatewayTransit enabled. On-premises traffic routes directly to spoke workloads with no inspection at all.
This is the default configuration if you deploy a hub VNet with a gateway and enable VNet peering without adding Azure Firewall and a UDR. It is also the configuration that leaves your spoke workloads directly reachable from your on-premises network with no inspection in between.
The fix: Deploy Azure Firewall in the hub, create a UDR on the GatewaySubnet routing to the firewall's private IP, and disable the default BGP route propagation on spoke subnets (replacing it with explicit UDRs).
Dual Inspection — Azure Firewall and On-Premises Firewall
For environments with strict compliance requirements, you may need inspection at both ends — Azure Firewall inspects traffic entering Azure from on-premises, and your on-premises firewall inspects traffic entering your datacentre from Azure. This gives you full visibility in both directions and satisfies most regulatory frameworks that require perimeter inspection regardless of network type.
This pattern requires careful BGP and routing design to ensure traffic flows through both firewalls without creating routing loops or asymmetric paths that can break stateful inspection.
Three Configuration Mistakes That Silently Open Your Network
BGP Route Propagation Left Enabled on Spoke Subnets
When you create a route table in Azure and associate it with a subnet, BGP route propagation is enabled by default. This means on-premises routes learned via ExpressRoute or VPN Gateway are automatically propagated to that subnet — bypassing any UDR you have created that routes traffic through Azure Firewall.
The result: your firewall UDR says traffic should go to Azure Firewall, but BGP propagation advertises a more specific route directly to the on-premises network, and Azure follows the more specific route. Traffic bypasses the firewall entirely. This is one of the most common causes of unexplained firewall bypass in hybrid environments.
On every spoke subnet route table, set Propagate gateway routes to Disabled. Use explicit UDRs to control all routing, including the default route toward Azure Firewall. Never rely on BGP propagation to provide routing in security-sensitive environments.
GatewaySubnet Has No UDR — Or Has the Wrong One
The GatewaySubnet is where your ExpressRoute Gateway or VPN Gateway lives. If this subnet has no UDR, or the UDR does not route traffic toward Azure Firewall, then traffic arriving from on-premises routes directly to its destination without inspection.
A subtlety that trips teams up: the GatewaySubnet cannot have a UDR with a default route (0.0.0.0/0) pointing to a virtual appliance if that appliance is not in the same VNet as the gateway. In hub-spoke designs where Azure Firewall is in the hub, the UDR on the GatewaySubnet must point to Azure Firewall's private IP — and Azure Firewall must be in the same hub VNet as the gateway.
Create a dedicated route table for the GatewaySubnet. Add a route for each spoke address space pointing to Azure Firewall's private IP. Do not add a 0.0.0.0/0 default route on the GatewaySubnet — this breaks gateway functionality. Route specific spoke prefixes only.
ExpressRoute Private Peering Authorised Without IP Filtering
ExpressRoute private peering connects your on-premises network to your Azure VNets at Layer 3. By default, once the peering is established, your on-premises network can reach any IP address in any VNet connected to that ExpressRoute circuit — including VNets you may not have intended to expose.
In environments with multiple subscriptions linked to the same ExpressRoute circuit, a new VNet added to the circuit becomes immediately reachable from on-premises without any additional configuration. If the team adding that VNet doesn't realise the circuit is already connected to other environments, they have just inadvertently exposed a new workload to the on-premises network.
Use Azure Firewall in the hub to filter which on-premises IP ranges can reach which spoke resources. Implement network rules that explicitly allow only the specific on-premises subnets that need access to specific Azure resources — deny everything else. Audit the VNets connected to your ExpressRoute circuit quarterly.
Hardening Your VPN Gateway Configuration
If you are using VPN Gateway, the default IKE/IPSec policy is a good starting point but not always sufficient for regulated environments. Here are the specific settings worth reviewing:
- IKE version — use IKEv2 exclusively. IKEv1 has known weaknesses and should not be used in new deployments.
- Encryption algorithm — AES-256 is the minimum. AES-256-GCM is preferred for its performance and authenticated encryption properties.
- Integrity algorithm — SHA-256 minimum. SHA-384 for higher security requirements.
- DH group — Group 14 (2048-bit MODP) minimum. Group 24 or ECP-384 for environments requiring stronger forward secrecy.
- SA lifetime — review your organisation's key rotation requirements. Shorter SA lifetimes mean more frequent rekeying, which limits the exposure window if a key is compromised.
- Active-active configuration — always deploy VPN Gateway in active-active mode with two public IPs. Active-standby requires manual failover; active-active fails over automatically.
Monitoring Hybrid Connectivity for Security Events
A hybrid connection you cannot monitor is a blind spot. These are the specific signals worth capturing for hybrid network security visibility:
- Azure Firewall logs — network rule hits, application rule hits, and IDPS alerts for traffic transiting the hub from on-premises should be sent to a Log Analytics Workspace and surfaced in Microsoft Sentinel.
- VPN Gateway diagnostics — GatewayDiagnosticLog and TunnelDiagnosticLog capture tunnel events including connections, disconnections, and authentication failures. Enable these in Diagnostic Settings on the gateway.
- ExpressRoute circuit metrics — BitsInPerSecond and BitsOutPerSecond metrics can detect unexpected traffic spikes that may indicate data exfiltration. Set metric alerts for thresholds that exceed normal traffic patterns.
- NSG Flow Logs on hub subnets — capture all traffic accepted and denied on the GatewaySubnet and the AzureFirewallSubnet for forensic analysis.
Add a Sentinel analytics rule that alerts when traffic from an on-premises IP range is seen hitting a spoke resource directly — bypassing Azure Firewall. If this alert fires, you have a routing misconfiguration and traffic is not being inspected. This single rule has caught firewall bypass in multiple customer environments.
Real-World Scenarios
Enterprise Migrating SAP from On-Premises to Azure
A global manufacturing company is migrating SAP S/4HANA to Azure. The SAP system requires sub-10ms latency to on-premises warehouse management systems that cannot be migrated yet. The company has 15,000 employees with on-premises Active Directory.
Architecture decision: ExpressRoute with 2Gbps dedicated bandwidth connects the primary datacentre to Azure. A second ExpressRoute circuit in a different peering location provides geographic redundancy. VPN Gateway in active-active mode provides encrypted failover. Azure Firewall Premium in the hub inspects all traffic from on-premises before it reaches the SAP spoke VNet.
Security outcome: All on-premises-to-SAP traffic is inspected. IDPS rules flag any anomalous lateral movement attempts. The SAP spoke is only reachable from specific on-premises IP ranges defined in Azure Firewall network rules — the rest of the on-premises network has no path to SAP workloads even though they share the same ExpressRoute circuit.
Multi-Branch Retail with VPN Connectivity
A retail organisation has 80 branch locations connecting to Azure for POS system connectivity, inventory management, and centralized printing. Each branch has a basic internet connection and a compatible VPN device.
Architecture decision: VPN Gateway in active-active mode in a hub VNet. Each branch establishes a site-to-site IKEv2 IPSec tunnel. A custom IKE policy enforces AES-256-GCM and DH Group 14. Azure Firewall network rules restrict each branch's VPN tunnel to only the specific Azure resources it needs — POS connectivity routes, not the full Azure environment.
Security outcome: A compromised POS device at one branch can only reach the specific resources its VPN tunnel is permitted to access. Lateral movement to other branches or to back-office systems in other spokes is blocked at the firewall. Each branch has a separate, named network rule collection so the audit trail is clean.
What to remember from this article
- →Hybrid connectivity without firewall inspection is a bidirectional risk — a compromised on-premises host has a direct path into Azure and vice versa
- →ExpressRoute is private but not encrypted by default — add IPSec over ExpressRoute for regulated environments that require Layer 3 encryption
- →Always deploy a UDR on the GatewaySubnet routing spoke-bound traffic through Azure Firewall — never let on-premises traffic reach spokes uninspected
- →Disable BGP route propagation on all spoke subnets — leave it enabled and your firewall UDRs can be silently bypassed by more specific BGP routes
- →Use IKEv2 with AES-256-GCM and DH Group 14 minimum for VPN Gateway — never leave the IKE policy at defaults in a production environment
- →Monitor your hybrid connection — VPN diagnostics, ExpressRoute metrics, and Azure Firewall logs together give you the visibility to detect anomalies before they become incidents