Skip to main content

Technical Lab: Identify when to use a policy-based VPN versus a route-based VPN connection

Questions​

Question 1 — Multiple Choice​

A company needs to connect its on-premises network to a VNet in Azure. The local VPN device is legacy equipment that supports only IKEv1 and requires traffic to be controlled based on statically defined source and destination prefixes. Which type of VPN Gateway meets this requirement?

A) Route-based VPN, as it supports IKEv1 and IKEv2 natively
B) Policy-based VPN, as it uses traffic selectors based on prefixes and is compatible with IKEv1
C) Route-based VPN with BGP enabled, as it offers more routing flexibility
D) Policy-based VPN with IKEv2 forced via custom IPsec policy

Question 2 — Technical Scenario​

A network architect is designing a hybrid connectivity solution in Azure. The requirements are:

  • Active simultaneous connections with multiple on-premises sites
  • Support for Point-to-Site (P2S)
  • Fault tolerance with active-active gateway

After reviewing the available options, the architect recommends using a route-based VPN. What is the most accurate technical justification for this choice?

A) Route-based VPN is the only type that supports the IKEv2 protocol, necessary for P2S
B) Policy-based VPN does not allow more than one simultaneous Site-to-Site connection, and does not support P2S or active-active configuration
C) Route-based VPN uses static routing tables, which ensures predictability in multi-site environments
D) Policy-based VPN requires BGP on all connections, making it incompatible with P2S

Question 3 — True or False​

A VPN Gateway configured as policy-based in Azure can be used simultaneously as an endpoint for a Site-to-Site connection and a Point-to-Site connection.

Question 4 — Technical Scenario​

An infrastructure team is reviewing the configuration below for a VPN Gateway in Azure:

Gateway Type : Vpn
VPN Type      : PolicyBased
SKU           : Basic
Connections   : 1 (Site-to-Site)
BGP           : Disabled
IKE Version   : IKEv1

During expansion planning, the need arises to add a second Site-to-Site connection for a new office. The team tries to create the connection, but the portal returns an error. What is the root cause of the problem?

A) The Basic SKU does not support BGP, which is mandatory for multiple connections
B) Policy-based gateways in Azure support at most one Site-to-Site connection
C) IKEv1 is not compatible with multiple simultaneous connections in Azure
D) It is necessary to migrate to IKEv2 before adding a second Site-to-Site connection

Question 5 — Multiple Choice​

When comparing policy-based and route-based VPNs in Azure, which of the statements below correctly describes a fundamental difference between the two types?

A) Route-based VPN defines which packets are encrypted through static prefix policies, while policy-based uses routing tables
B) Policy-based VPN is compatible with any VPN Gateway SKU, while route-based requires VpnGw1 or higher SKU
C) Route-based VPN utilizes virtual tunnel interfaces and makes forwarding decisions based on routes, while policy-based uses static traffic selectors based on prefixes
D) Both types support BGP, but only route-based allows using IKEv2

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The policy-based VPN in Azure encrypts and directs packets based on traffic selectors defined as combinations of source and destination prefixes, which corresponds exactly to the model required by the legacy device described. Additionally, policy-based gateways in Azure support IKEv1, making them compatible with older equipment.

Alternative A is incorrect because, although route-based supports IKEv1 in some scenarios, it does not use prefix-based traffic selectors as the primary decision mechanism. Alternative C adds BGP, which is incompatible with policy-based and unnecessary for the scenario. Alternative D is invalid because policy-based gateways in Azure do not support IKEv2 via custom policy.

Answer Key — Question 2​

Answer: B

The precise technical justification is that policy-based VPN in Azure is limited to exactly one Site-to-Site connection, does not support Point-to-Site (P2S) and cannot be configured in active-active mode. These three requirements together completely eliminate policy-based as a viable option.

Alternative A is partially true (IKEv2 is used in P2S), but is not the most complete and precise justification for the choice. Alternative C reverses the logic: route-based uses dynamic routing tables, not static ones as a predictability advantage. Alternative D is false: policy-based does not require BGP; in fact, it does not support BGP.

Answer Key — Question 3​

Answer: False

Policy-based gateways in Azure do not support Point-to-Site connections. This limitation is structural: P2S requires a dynamic routing model based on virtual tunnel interfaces, which is an exclusive characteristic of route-based VPN. Additionally, policy-based gateways allow at most one Site-to-Site connection, which reinforces that they were designed for simple connectivity scenarios and with specific legacy devices.

The common misconception is to assume that, because both are types of VPN Gateway, they share all functionalities. In practice, policy-based is a quite restricted subset of capabilities.

Answer Key — Question 4​

Answer: B

The root cause is direct: policy-based gateways in Azure support at most one Site-to-Site connection. This is an architectural limitation of the type, regardless of SKU, IKE version, or BGP configuration.

Alternative A confuses two distinct problems: the Basic SKU indeed does not support BGP, but BGP is not mandatory for multiple connections. Alternative C is incorrect because IKEv1 does not impose this limit by itself. Alternative D is a plausible distractor, but the IKE version is not the limiting factor in this case; the correct solution would be to migrate to a route-based gateway, not just change the IKE version.

Answer Key — Question 5​

Answer: C

The fundamental difference lies in the forwarding decision mechanism. The route-based VPN creates virtual tunnel interfaces (like VTI on physical devices) and uses the routing table to decide which traffic passes through which tunnel. The policy-based VPN uses static traffic selectors, explicit combinations of source and destination prefixes, to determine what is encrypted and sent through the tunnel.

Alternative A reverses the concepts of the two types. Alternative B is incorrect: policy-based gateways in Azure require the Basic SKU and are not compatible with higher SKUs like VpnGw1. Alternative D is false: policy-based does not support BGP, while route-based does.