Azure VPN Client 3.0.100 macOS: Always On feature causes 20-second disconnect/reconnect loop

Hi Andre Gomes ,

Welcome to Microsoft Q&A Platform.

It looks like you’ve hit a confirmed bug in the macOS 3.0.100 client’s Always On implementation. The Network Extension is respawning the tunnel every ~20 seconds—which kills an otherwise healthy connection—and the client mangles the <any> element in your profile XML so you can’t override it.

Alternatively, you can

• Disable “Connect automatically”
• Open the Azure VPN Client for macOS
• Select your profile and uncheck Connect automatically
• This will stop the 20 sec reconnect loop. You’ll need to connect manually each time, but once you’re on 3.0.100 it won’t cycle any longer.

Remove & re-import the profile (optional)

• In the client UI, click the “…” next to the profile and choose Remove
• Re-import the P2S profile and ensure Connect automatically is off

Reference:

Azure VPN Client versions (shows 2.8.100 vs 3.0.100): https://learn.microsoft.com/azure/vpn-gateway/azure-vpn-client-versions#azure-vpn-client---macos

Configure Always On device tunnel (macOS): https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-howto-always-on-device-tunnel-macos

Pleaseand “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

Hello Andre Gomes,

Greetings! Thanks for raising this question in Q&A forum.

You have done an excellent job of diagnosing this issue. Based on your log analysis, this is a confirmed bug in Azure VPN Client 3.0.100 for macOS where the new Always On implementation incorrectly signals the macOS Network Extension framework to cycle the tunnel every ~20 seconds. The key evidence is the from main app: false log line this proves macOS itself is restarting the tunnel process, not the app, and the XML rewrite of <any> from i:nil="true" to <any>true</any> is the likely trigger that missets the Always On flag, causing the system-level tunnel cycling. This did not exist in 2.8.100 and is entirely a regression introduced in 3.0.100.

Here are the steps to work around this and get it escalated to Microsoft:

Step 1: Try disabling Always On via the profile XML directly

Since the 3.0.100 client is rewriting the <any> element to <any>true</any>, try manually editing the VPN profile XML before importing it into the client. Open the .xml profile file in a text editor and locate the <any> element. Try setting it explicitly as:

<any>false</any>

Save the file and re-import the profile into the VPN client. If this avoids the "Invalid server configuration" error, it may prevent the Always On flag from being set and stop the cycling loop.

Step 2: Re-download a fresh profile from your VPN Gateway

Sometimes profile re-downloads resolve XML element issues. Go to:

Azure Portal → Your Virtual Network Gateway → Point-to-site configuration → Download VPN Client

Download a fresh profile package, extract the .xml file, import it directly without any edits, and test if the cycling persists. A freshly generated profile may have different element formatting that 3.0.100 handles better.

Step 3: Obtain version 2.8.100 via direct PKG download

You correctly noted the App Store does not allow downgrades. However, older versions of the Azure VPN Client PKG are sometimes available directly from Microsoft's download servers. Try:

https://aka.ms/azvpnclientdownload

or check:

https://www.microsoft.com/en-us/download/details.aspx?id=45119

If a PKG installer is available there, you can install it outside the App Store and it will take precedence over the App Store version. If neither link works, mention this in your support ticket and ask Microsoft to provide the 2.8.100 PKG directly.

Step 4: Check if macOS Tahoe (26.5.0) compatibility is a factor

You are running macOS 26.5.0 (Tahoe), which is a very recent release. It is possible that the Network Extension framework behavior changed in Tahoe in a way that interacts badly with 3.0.100's Always On implementation. Check if other users on earlier macOS versions (Sequoia/Sonoma) are experiencing the same issue — if they are not, this points to a Tahoe-specific compatibility bug that Microsoft needs to address urgently.

Step 5: Collect and preserve the full PacketTunnel log

Before raising your support ticket, collect the complete log from:

~/Library/Group Containers/UBF8T346G9.group.com.microsoft.AzureVpnMac.shared/LogFiles/

Archive the entire folder. The log entries you have already captured — especially the 20-second cycle pattern and the from main app: false indicator — are exactly what the engineering team needs to identify the regression.

Step 6: Open an Azure Support Ticket and report via the Mac App Store

This needs to be escalated on two fronts simultaneously:

For Azure Support, go to Azure Portal → Help + Support → New Support Request and fill in:

• Issue type: Technical
• Service: Azure VPN Gateway
• Problem type: Point-to-Site VPN
• Problem subtype: VPN Client connectivity issue
• Severity: B (Moderate)

In the description include:

• Client version: 3.0.100 (regressed from 2.8.100)
• macOS version: 26.5.0 Tahoe, Apple Silicon arm64
• The exact 20-second disconnect/reconnect loop behavior
• The from main app: false log evidence proving macOS Network Extension is cycling the tunnel
• The XML <any> element rewrite from i:nil="true" to <any>true</any>
• Request: (1) a hotfix build of 3.0.x, (2) or access to the 2.8.100 PKG as a temporary workaround

Additionally, submit feedback directly through the Mac App Store review for the Azure VPN Client app — engineering teams actively monitor App Store reviews for regression reports and it helps prioritize a hotfix release faster.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.