Vendor compatibility
Azure VPN Gateway post-quantum VPN support
Azure VPN Gateway site-to-site connections, including custom IPsec/IKE policy on connection objects, across the supported gateway SKUs.
Last reviewed
1 compatibility record
Direct answer
Azure VPN Gateway is a managed service whose cryptographic options are governed by the custom IPsec/IKE policy the connection accepts, and by the gateway SKU. Establish which key exchange methods the current policy surface accepts, whether the SKU supports custom policy at all, and what the on-premises device at the other end can negotiate.
Practical status
What this means in a real estate
Azure estates commonly mix connections that use a default policy with connections that carry a hand-set custom policy, and the two behave differently under change. An inventory has to record which is which, because a connection on default policy will follow whatever the service defaults become, while a connection with a pinned custom policy will not. Both are legitimate; only one of them changes without a customer action.
What to establish about key exchange
Establish which key exchange methods the custom IPsec/IKE policy surface accepts on the relevant SKU, and whether the estate's connections currently use default or custom policy. A pinned custom policy is an explicit statement of what will be negotiated and must be updated deliberately.
Why authentication is a separate question
Azure site-to-site connections authenticate with a preshared key. The key exchange method and the authentication method are configured independently, and improving the former does not alter the latter.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| Azure VPN Gateway site-to-site connections | Post-quantum key establishment: Unknown |
Azure VPN Gateway site-to-site connections
Managed service, current custom IPsec/IKE policy surfaceWhat a connection negotiates is governed by the custom IPsec/IKE policy where one is set, and by service defaults where one is not. Establish which applies per connection before assessing.
Migration implication: Inventory must distinguish default-policy from pinned-policy connections, because only one of those two categories will ever change without a customer action.
Caveats
- Connections on default policy follow service defaults; pinned connections do not
- Policy changes cause renegotiation and a brief interruption
- SKU can constrain available policy options
Last reviewed · low confidence · 1 source
Prerequisites
Establish these before assessing migratability.
- Gateway SKU for every VPN gateway in scope
- Whether each connection uses default or custom IPsec/IKE policy
- Current custom policy values where set, exported rather than assumed
- On-premises device model and release for each connection
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- The on-premises device governs what the connection can actually negotiate
- A custom policy that the peer cannot match will prevent the tunnel from establishing
- Active-active gateway configurations require both instances to be considered
Operational limitations
Constraints that shape the plan rather than block it.
- Capability is set by the service and its supported policy values
- Changing a connection's policy causes renegotiation and a brief interruption
- Some SKUs constrain which policy options are available
Migration paths
The routes available when the current state is not the target.
- Update the custom IPsec/IKE policy on the connection through infrastructure as code
- Migrate or upgrade the on-premises device where it is the constraint
- Change gateway SKU where the current SKU constrains policy options
- Defer and track where the service does not expose the required method
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm the negotiated parameters from the on-premises device, where visibility is better
- Check connection status and negotiated policy after the change
- Verify each connection separately; policy is per connection, not per gateway
Sources
- 1. About VPN devices and IPsec/IKE parameters for Site-to-Site VPN Gateway connections(opens in a new tab)
Microsoft · verified by PQVPN
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Need this mapped to your actual Azure VPN Gateway estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.