Intermittent Azure Virtual WAN P2S SSL (OpenVPN) connectivity failure after adding a new VNet connection to vHub

Question

Hello,

After connecting a new Virtual Network (VNet) to our Azure Virtual WAN Virtual Hub (vHub), our Point-to-Site VPN (P2S) SSL/OpenVPN users experienced abnormal behavior: VPN connection attempts failed with timeouts when connecting to the VPN endpoint.

The issue started immediately after the new Hub Virtual Network Connection was created. The behavior lasted approximately ~1 hour, then the service returned to normal without any configuration change on the client side.

No default route (0.0.0.0/0) was introduced in our routing configuration.

When attempting to connect using Azure VPN Client, authentication with Microsoft Entra ID succeeds, but the client fails to establish the network connection to the VPN server endpoint (TCP 443 timeout).

Error received:

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

During failures, the VPN client reports:

Connection lifetime = 0 seconds
Bytes sent/received = 0

This indicates the VPN endpoint was not reachable at network level during that time.

Failure example :

[2/19/2026 11:36:40 AM UTC] [Verbose] Attempting to connect to VPN server @ 
[2/19/2026 11:37:01 AM UTC] [Error] Connecting to VPN server failed with exception:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
[2/19/2026 11:37:02 AM UTC] [Verbose] Disconnectedtype: FailureDisconnect, Connection Life Time 0 secs,
Bytes sent 0, Bytes Received 0

Impact

Users were unable to establish P2S SSL VPN sessions during the incident window.

Service disruption duration: ~1 hour.

The issue resolved automatically.

Have you seen a similar case? Is this expected behavior?

Regards,

Answer 1

Hello @Nassim Cherifi,

Thanks for reaching out to Microsoft Q&A.

Based on your description, this is a known behavior in Azure Virtual WAN. Adding a new Virtual Network connection to the hub can cause temporary disconnections for Point-to-Site clients if a VPN gateway is present. The hub undergoes a reconfiguration, which may result in TCP 443 timeouts during connection attempts, even though authentication is successful. This issue is related to the hub update process, not routing changes.

Reference Document: https://learn.microsoft.com/en-us/azure/virtual-wan/howto-connect-vnet-hub

To prevent similar issues for users in the future:

• Consider scheduling hub changes (such as adding VNets) during off-peak times or maintenance windows.
• Monitor the Virtual WAN hub’s status using Azure Monitor or portal insights to detect updates early.

If the issue continues longer than expected, you can reset the VPN gateway in the Azure portal. This reboot is designed to minimize downtime (usually less than a minute), but it’s best to test this in a low-impact scenario first. Afterward, users should redownload their VPN profiles if needed.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "Accept the Answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hello @Nassim Cherifi,

To answer your follow-up question, yes, this behavior primarily impacts P2S connections. While the addition of VNets can lead to reconfigurations that might affect other types of connections, like ExpressRoute links or VHub connections, it is less common. However, it's always good to monitor those connections when such changes occur.

if you're making broader changes like scaling gateways or updating ExpressRoute configs, those could have their own minor effects (e.g., TCP reconnects), but nothing tied directly to VNet additions

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

Answer 3

It appears that the intermittent connectivity issues you experienced with the Point-to-Site (P2S) VPN after adding a new Virtual Network (VNet) connection to your Azure Virtual WAN Virtual Hub (vHub) could be related to routing or network configuration changes that occurred when the new connection was established. Here are a few points to consider:

1. Routing Configuration: Even though you mentioned that no default route (0.0.0.0/0) was introduced, the addition of a new VNet connection may have altered the routing paths or priorities. Ensure that the routes for the existing connections are still valid and that there are no conflicts.
2. Network Security Groups (NSGs): Check if there are any NSGs associated with the new VNet that could be affecting traffic to the VPN endpoint. Ensure that the necessary inbound and outbound rules are correctly configured to allow traffic on TCP port 443.
3. VPN Gateway Configuration: Verify that the VPN gateway settings are still intact and that the gateway is configured to handle the new VNet connection without issues. Sometimes, adding a new connection can inadvertently affect existing configurations.
4. Service Health: Monitor Azure service health during the time of the incident to see if there were any outages or service disruptions in the Azure region that could have impacted your VPN connectivity.
5. Logs and Diagnostics: Utilize Azure diagnostics and logs to gather more information about the connection attempts during the failure period. This can provide insights into whether the issue was on the client side or the Azure infrastructure.

The fact that the issue resolved itself after about an hour suggests that it may have been a transient issue, possibly related to Azure's internal routing or service stability. If this behavior continues or recurs, consider reaching out to Azure support for a deeper investigation.

---

References:

• Troubleshooting: Azure Site-to-Site VPN disconnects intermittently
• Troubleshooting: An Azure site-to-site VPN connection can't connect and stops working