AZ-700<\/a>, mature VPN design is AZ gateway \u2192 active-active \u2192 redundant customer devices \u2192 BGP where useful \u2192 capacity\/limits \u2192 monitored routes \u2192 measured failover.<\/p>\nA tunnel is infrastructure; the user-visible requirement is reliable application connectivity through failure.<\/p>\n
IPsec parameters should be standardized where custom policy is required. Mismatched IKE version, encryption, integrity, DH group, lifetime, or traffic selectors can create brittle connections that fail after a device change. Prefer supported defaults unless compliance or interoperability requires customization.<\/p>\n
VPN Gateway is often a good backup to ExpressRoute when the business can tolerate the internet path and lower capacity. Preconfigure and test that backup before an ExpressRoute incident rather than building it during the outage.<\/p>\n
Forced tunneling, Azure Firewall, Route Server, and Virtual WAN can all change hybrid traffic paths. Keep the VPN gateway role clear so route propagation does not unintentionally bypass security inspection or create loops.<\/p>\n
Document tunnel ownership across cloud and network teams. One side should know which Azure connection maps to which customer device, provider circuit, peer IP, and BGP session so incidents do not become a two-team guessing exercise.<\/p>
Gateway subnet design is part of the architecture. Reserve enough address space for the current SKU and future changes so the environment is not forced into a disruptive VNet redesign during a gateway migration. Keep unrelated workloads out of the GatewaySubnet.<\/p>\n
Active-active mode is most useful when the on-premises side is equally redundant. Two Azure gateway instances connected to one physical VPN appliance still leave a single customer-side failure point. The strongest pattern uses redundant customer devices, separate internet providers where justified, and tunnels to both Azure instances.<\/p>\n
BGP route design should include route filters and ownership. Advertising the entire corporate routing table can exceed limits or unintentionally make Azure a transit path. Send only the prefixes the connected workloads require and monitor changes in route count.<\/p>\n
Point-to-site architecture should consider split versus forced tunneling, DNS, client address pools, authentication, and device management. Remote-user connectivity is an identity and endpoint-security problem as well as a networking problem.<\/p>\n
Network address translation can help when acquired companies or partners use overlapping prefixes, but NAT adds translation state and troubleshooting complexity. Use it selectively and document which side sees original versus translated addresses.<\/p>\n
Gateway upgrades or SKU migrations should have maintenance and rollback plans. Some changes require public IP or gateway replacement behavior that affects tunnels. Read the current migration path before treating the gateway as easily mutable infrastructure.<\/p>\n
VPN monitoring should correlate Azure metrics with the customer device logs. A tunnel can appear connected while packet loss, negotiation churn, or route mismatch makes the application unusable. End-to-end probes provide stronger evidence than one green connection status.<\/p>\n
When VPN backs up ExpressRoute, route preference should be tested before a real circuit outage. The VPN path should become active automatically or through a documented process, carry the intended prefixes, and have enough capacity for the critical subset of traffic.<\/p>\n
Security policy should not assume IPsec alone provides authorization. The tunnel protects the path, but workload firewalls, NSGs, identity, and application authorization still decide what a connected branch or user may access.<\/p>\n
Document the complete hybrid path, including Azure gateway, connection, local network gateway, customer devices, provider links, BGP, routes, DNS, and inspection. This makes incident ownership and failover testing far more predictable.<\/p>\n
Gateway resiliency should be tested during planned Azure maintenance as well as simulated customer-side failure. Active-active designs should keep traffic flowing when one Azure instance or one customer device is unavailable, and monitoring should prove the alternate tunnel actually carried the session.<\/p>\n
Packet fragmentation and MTU can become important across IPsec, especially when applications send large packets or when additional encapsulation is present. A tunnel can appear healthy while certain workloads fail because path MTU is wrong. Include large-packet and application tests in validation.<\/p>\n
Gateway configuration should be deployed as code where feasible so connection objects, BGP settings, local network gateways, and diagnostic settings can be reviewed and reproduced. Manual portal-only configuration makes recovery and peer comparison harder.<\/p>\n
Point-to-site address pools must not overlap with VNet, on-premises, or other remote-user ranges. Plan these addresses centrally so a later merger or branch connection does not create ambiguous routing.<\/p>\n
The architecture is complete when the enterprise can lose one tunnel, one Azure gateway instance, one customer device, or one provider path and still understand exactly which route, tunnel, and security controls the application will use next.<\/p>\n
Authentication key rotation should be documented for site-to-site connections. Pre-shared keys, certificates, or device credentials need an agreed rotation process across Azure and the customer endpoint so a security change does not cause an avoidable outage.<\/p>\n
Use diagnostics and packet captures selectively when a tunnel is up but traffic fails. Check learned routes, effective routes, NSGs, firewall rules, NAT, and return path before assuming the IPsec negotiation is the problem.<\/p>\n
Availability tests should include planned gateway maintenance scenarios because Microsoft can service individual gateway instances. An active-active design with both customer tunnels established is specifically intended to reduce impact during those events.<\/p>\n
For global estates, multiple VPN gateways can be necessary because the service is regional. Place gateways near connected workloads and branches and decide whether Virtual WAN provides a simpler managed model once the number of branches and regions grows.<\/p>\n
VPN Gateway is mature when it is treated as a routable, monitored, redundant network service with capacity and ownership\u2014not as a one-time tunnel configuration.<\/p>\n
Document the gateway’s critical application prefixes and normal route preferences so failover tests can verify not only that tunnels remain established but that the same protected business traffic still follows the intended path.<\/p>\n
Review the design after new branches, mergers, address-space changes, or gateway SKU migrations because hybrid routing complexity tends to grow faster than the original tunnel diagram.<\/p>","protected":false},"excerpt":{"rendered":"
Azure VPN Gateway provides encrypted connectivity for site-to-site, point-to-site, and VNet-to-VNet scenarios. A production design is not complete when one IPsec tunnel connects. The architecture needs an appropriate gateway SKU, zone strategy, active-active or active-standby mode, BGP where dynamic routing adds value, redundant on-premises VPN devices, connection and route limits, authentication choices, and a tested failure path. Microsoft’s current VPN Gateway guidance recommends AZ-capable gateway SKUs for new deployments and documents active-active designs where both Azure gateway instances use separate public IPs. For maximum site-to-site reliability, Microsoft shows dual-redundancy active-active…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11737","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t