Troubleshooting Lab: Virtual Network Gateway SKU Selection for Point-to-Site VPN
Diagnostic Scenarios
Scenario 1 — Root Cause
A company deployed a VPN gateway six months ago with the Basic SKU to serve a group of 40 remote users. The environment worked without incidents during this period. Recently, the company acquired a subsidiary and the number of expected simultaneous P2S connections jumped to 200. The network team decided to upgrade the gateway to the VpnGw1 SKU through the Azure portal.
During the upgrade attempt, the operation fails with the following message:
Code: GatewaySkuNotSupported
Message: Resize operation is not supported from Basic to VpnGw1.
The gateway must be deleted and recreated with the desired SKU.
Target SKU: VpnGw1
Current SKU: Basic
The responsible analyst reviews the history and confirms that the gateway is healthy, active connections are working, and there are no alerts in the diagnostic dashboard. He considers that the error might be related to the gateway generation version (Generation1 versus Generation2) or some virtual network configuration preventing the resize.
What is the root cause of the failure?
A) The Basic gateway belongs to Generation1 and VpnGw1 to Generation2, and upgrades between different generations are not supported by the portal
B) The Basic SKU does not support resize operation to any other SKU; migration requires deletion and recreation of the gateway
C) The resize operation failed because there are active P2S connections at the time of the attempt, and the gateway needs to be connection-free to be resized
D) The error indicates that the gateway subnet (GatewaySubnet) has a prefix smaller than /27, preventing resource allocation for the higher SKU
Scenario 2 — Action Decision
A company's network team identified that the P2S VPN gateway, currently with VpnGw1 SKU, is consistently consuming 94% of simultaneous connection capacity over the last five days. The VpnGw1 SKU supports 650 P2S connections. Analysis shows peaks occur between 9 AM and 11 AM and between 2 PM and 4 PM in local time zone.
The cause has been confirmed: the volume of remote users has grown beyond the planned capacity for this SKU.
The environment has the following constraints:
- The gateway is in production with active contractual SLA
- A scheduled maintenance window is available next Friday at 11 PM
- The team has permission to execute SKU upgrades without additional approval
- There is an urgent internal request to resolve the problem today
What is the correct action to take at this moment?
A) Execute the SKU upgrade immediately to VpnGw2, taking advantage that resize operation between VpnGw family SKUs is supported and does not cause prolonged unavailability
B) Create a second VPN gateway in a separate VNet and manually redirect half of the users, distributing the load before the maintenance window
C) Wait for the scheduled maintenance window on Friday to execute the upgrade, since resize operation causes temporary unavailability and should be done during controlled hours
D) Increase the number of P2S connections configured in the current gateway without changing the SKU, adjusting the connection limit parameter in the portal's advanced settings
Scenario 3 — Root Cause
An administrator reports that remote clients with Windows 11 are successfully connecting via P2S VPN, but clients with macOS Ventura receive the following message when trying to establish the connection:
VPN Connection Failed
Error: The network connection between your computer and the VPN server
could not be established because the remote server is not responding.
Error code: 800
The gateway is configured with VpnGw1 SKU. The root certificate was correctly exported and uploaded to the gateway. macOS clients received the client VPN profile generated by the portal. The administrator verifies that the gateway is operational and that other network protocols in the VNet work normally. He also confirms that the Azure subscription has not reached any gateway quota.
The team additionally reports that the gateway was created two years ago with default configuration and has never been modified since then.
What is the root cause of the problem?
A) The root certificate uploaded to the gateway has expired and needs to be renewed for new clients to authenticate
B) The gateway is configured to accept only the SSTP protocol, which is not natively supported by macOS; macOS clients require IKEv2 or OpenVPN
C) The client VPN profile for macOS needs to be generated separately using Azure CLI, as the portal does not generate profiles compatible with macOS Ventura
D) The VpnGw1 SKU has a limit of 10 simultaneous connections for non-Windows clients, and this limit has been reached
Scenario 4 — Diagnostic Sequence
A client reports being unable to establish a P2S connection with the VPN gateway. The support analyst needs to investigate the problem. Below are five possible diagnostic steps, presented out of order:
[P] Verify if the protocol configured on the gateway (SSTP, IKEv2 or OpenVPN)
is compatible with the user's client
[Q] Verify if the VPN gateway is in "Running" state in the Azure portal
[R] Confirm if the client certificate was correctly installed
in the correct repository of the operating system
[S] Verify if the client VPN profile was generated after the last
gateway configuration change
[T] Analyze gateway diagnostic logs to identify
rejected connection attempts and their error codes
Which sequence represents the correct order of progressive diagnosis?
A) R, P, S, Q, T
B) Q, P, R, S, T
C) T, Q, P, R, S
D) S, R, Q, T, P
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The error message is direct and unambiguous: Resize operation is not supported from Basic to VpnGw1. The Basic SKU is an isolated category in the Azure VPN gateway SKU hierarchy. Unlike the VpnGw1 to VpnGw5 family SKUs, which allow resize between them within the same generation, Basic does not participate in this incremental upgrade model. The only way to migrate from Basic to any other SKU is to delete the existing gateway and recreate it with the desired SKU, causing unavailability.
The decisive clue in the scenario is the error message itself, which explicitly names the resize restriction. The six-month history of healthy operation and absence of alerts are irrelevant information for diagnosis: they describe the gateway's operational state, not the cause of the upgrade failure.
Alternative A confuses the cause with a real but incorrect detail: while different generations have compatibility restrictions, the impediment here is not inter-generation, it's the isolated nature of the Basic SKU. Alternative C is technically false: the presence of active connections does not block resize operations in SKUs that support them. Alternative D introduces a subnet requirement that has no relation to the resize operation.
The most dangerous distractor is A, as it leads the analyst to investigate gateway generation and compatibility, wasting time before executing the correct action: recreate the gateway.
Answer Key — Scenario 2
Answer: C
The cause has already been confirmed in the scenario (capacity exceeded), but the environment constraints determine the correct action. The critical point is that resize operations on Azure VPN gateways, even between VpnGw family SKUs that support it, cause temporary unavailability. Executing this operation during peak hours in an environment with active contractual SLA represents unnecessary risk when a maintenance window is available in a few days.
The urgent internal request is contextual pressure information, not a technical constraint that justifies ignoring the SLA and the risk of production unavailability. Sound diagnostics and planning include resisting urgency when immediate action violates contracts or increases risk.
Alternative A represents the technically correct action applied at the wrong time: resize is supported and eventual, but executing it outside maintenance window in production is imprudent. Alternative B describes a valid architectural solution in other contexts, but is complex, time-consuming and doesn't solve the problem within the given constraints. Alternative D is false: there is no adjustable connection limit parameter independent of the SKU; capacity is determined by the chosen SKU.
Answer Key — Scenario 3
Answer: B
The central symptom is the exclusive failure in macOS clients, while Windows 11 clients work normally. This asymmetric behavior by operating system is the decisive diagnostic clue. The SSTP protocol is exclusive to Windows and is not supported by macOS. If the gateway was created with default configuration two years ago and never modified, it's highly likely that the default configuration at the time enabled only SSTP, which was the predominant protocol for P2S before widespread adoption of IKEv2 and OpenVPN. macOS clients need IKEv2 or OpenVPN to establish P2S connection.
The information about the subscription not reaching quota and the gateway being operational is irrelevant for diagnosis: it only confirms that the problem is not infrastructure availability.
Alternative A is plausible as a generic cause of authentication failure, but would not explain why the problem affects only macOS and not Windows. Alternative C is false: the Azure portal generates client profiles compatible with multiple operating systems. Alternative D is completely fictitious: there is no differentiated connection limit by operating system in VpnGw SKUs.
The most dangerous distractor is A, as it leads the analyst to investigate and renew certificates, which will not solve the problem and consumes valuable time.
Answer Key — Scenario 4
Answer: B
The correct sequence is Q, P, R, S, T, which follows the logic of diagnosis from simplest and most comprehensive to most specific and deep.
The correct progressive reasoning is:
- Q — Confirm that the gateway is operational before any configuration or client investigation. If the gateway is not in "Running" state, all other steps are irrelevant.
- P — Verify protocol compatibility between gateway and client. A protocol mismatch will block any attempt regardless of certificates or profiles.
- R — With protocol confirmed, verify if the client certificate is installed in the correct location of the operating system, as this is a frequent client configuration error.
- S — Confirm if the VPN profile is updated relative to the current gateway configuration. An outdated profile may contain obsolete addresses or configurations.
- T — Only after exhausting configuration verifications, analyze diagnostic logs to identify rejection patterns not covered by previous steps.
Alternatives A, C and D reverse or shuffle this progression, making the analyst dive into specific details (certificates, logs) before validating basic prerequisites (active gateway, compatible protocol), which wastes time and can generate incorrect diagnoses.
Troubleshooting Tree: Virtual Network Gateway SKU Selection for Point-to-Site VPN
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question (verifiable decision) |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node describing the observed symptom and follow the branches by answering each diagnostic question with what you can directly verify in the environment. Closed questions (yes or no, all or some) force elimination of hypotheses before advancing to the next level. When you reach a red node, the cause is identified; the immediately subsequent green node indicates the corresponding corrective action. Orange nodes indicate points where investigation can deepen before concluding the diagnosis.