Getting "Server did not respond properly to VPN Control Packets. Session State Key Material sent" after migrating from manual to Microsoft-registered Azure VPN Client (Entra ID User VPN)

Hello chathulankagamage

From migration workflow, this typically happens if the VPN gateway configuration wasn’t fully updated or saved before downloading the new client profile, or if the client is still using a profile generated when the gateway still had the old audience. The gateway and client configurations must consistently use the same Audience value.

Also, you must download a fresh P2S client configuration after updating the gateway and re‑import it to the Azure VPN Client

The behavior is expected if the Audience migration isn’t applied consistently on both the gateway and the client. According to Microsoft documentation, when moving from a manually registered Azure VPN Client to the Microsoft‑registered client (c632b3df-fb67-4d84-bdcf-b95ad541b5c8), the P2S VPN gateway and the client profile must both be updated to the new Audience value and a new VPN client configuration package must be downloaded and imported.

NOTE: If the gateway or client still references the old App ID (for example 41b23e61-6c1e-4545-b367-cd054e0ed4b4), tunnel negotiation can fail even though authentication succeeds. Additionally, the Issuer URL must include the required trailing slash and the gateway can only support one Audience value at a time.

1. Run the built-in diagnostics • In the Azure portal, go to your VPN gateway → Troubleshooting → Point-to-site connection checks. • Look for any errors under P2S-error or control-plane failures—this can confirm if it’s a token/authority mismatch.
2. After you update the Tenant/Audience in your P2S config, you must click “Download VPN client” and import the new package (Windows) or extract the .ovpn (Linux). • Don’t manually tweak any values in the downloaded XML/OVPN—let the client import the exact file.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

Hello @ chathulankagamage,

Thank you for reaching out to Microsoft Q&A.

Thanks for the clear details and screenshots.

The error “Server did not respond properly to VPN Control Packets. Session State: Key Material sent” almost always points to an Audience / Issuer mismatch between the gateway configuration and the VPN client profile. Because reverting to the old Audience (41b23e61-6c1e-4545-b367-cd054e0ed4b4) instantly fixes the connection, your Virtual Network Gateway is still set to expect the manually registered app.

To finish the migration to the supported Microsoft-registered app, you just need to update the gateway first, then grab a fresh client profile:

1. In the Azure portal, go to your Virtual Network Gateway → Point-to-site configuration → Configure now.
2. Change the Audience to: c632b3df-fb67-4d84-bdcf-b95ad541b5c8
3. Make sure the Issuer ends with a trailing / (e.g. https://sts.windows.net/{tenant-id}/).
4. Click Save (brief <5 min downtime).
5. After the save completes, click Download VPN client and import the new azurevpnconfig.xml into the Azure VPN Client (Windows and Linux).

Reference Documents:

Full step-by-step migration guide (exactly for your scenario): Migrate a manually registered Azure VPN Client to the Microsoft-registered Azure VPN Client

For reference on the client-side config: Configure Azure VPN Client – Microsoft Entra ID authentication (Windows) (Linux version is linked from the same page.)

If the steps above did not resolve the issue, please check the private message and provide the requested information there.

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

When migrating from the manually registered Azure VPN Client app ID to the Microsoft‑registered app ID, the Audience/Application ID must be updated in both places:

1. The P2S VPN gateway configuration in Azure.
2. Every VPN client profile (azurevpnconfig.xml) that was created with the old audience.

If the gateway is using the Microsoft‑registered audience c632b3df-fb67-4d84-bdcf-b95ad541b5c8 but the client profile still contains the old audience, the OpenVPN control channel completes authentication but fails when establishing the tunnel, which surfaces as:

Server did not respond properly to VPN Control Packets. Session State: Key Material sent

To fix the issue:

1. Confirm the gateway is configured for Microsoft‑registered app
   • In the P2S configuration, set Authentication type to Microsoft Entra ID.
   • Set Audience to c632b3df-fb67-4d84-bdcf-b95ad541b5c8.
   • Set Issuer to https://sts.windows.net/{TenantID}/ (note the required trailing /).
   • Save the configuration.
   • This matches the documented Microsoft‑registered audience value.
2. Regenerate and distribute a fresh client profile
   • On the same Point‑to‑site configuration page, select Download VPN client and wait for the package to be generated.
   • Extract the zip and locate azurevpnconfig.xml in the AzureVPN folder.
   • Import this new profile into Azure VPN Client on Windows (and Linux, if used) instead of reusing any profile that was created before the audience change.
   • Ensure there are no old profiles still pointing at the gateway with the old audience.
3. Verify client‑side Entra settings
   • In Azure VPN Client (Linux or Windows), open the imported profile and check:
     • Tenant is https://login.microsoftonline.com/{TenantID} (no trailing backslash; a trailing forward slash is allowed).
     • Audience is c632b3df-fb67-4d84-bdcf-b95ad541b5c8 (or a supported custom App ID if intentionally using custom audience).
     • Issuer is https://sts.windows.net/{TenantID}/ with the trailing /.
4. For Linux clients using a custom audience (if applicable)
   • If a custom audience is configured on the gateway and the app is associated with the Microsoft‑registered Azure VPN Client app ID, edit the Linux profile XML and ensure both are present:

      <aad>
         <audience>{customAudienceID}</audience>
         <issuer>https://sts.windows.net/{tenant ID value}/</issuer>
         <tenant>https://login.microsoftonline.com/{tenant ID value}/</tenant>
         <applicationid>c632b3df-fb67-4d84-bdcf-b95ad541b5c8</applicationid>
      </aad>
   

   • This prevents repeated auth prompts and control‑channel failures when using custom audiences.
5. Re‑test the connection
   • Delete any old, non‑working profiles from Azure VPN Client.
   • Import only the newly downloaded profile and connect.

If reverting the gateway audience back to 41b23e61-6c1e-4545-b367-cd054e0ed4b4 immediately restores connectivity, that confirms the failure is due to a mismatch between the gateway’s audience and the client profile’s audience/application ID. Ensuring they are aligned using the Microsoft‑registered value and a freshly generated profile resolves the error.

References:

• Migrate a manually registered Azure VPN Client to the Microsoft-registered client for Microsoft Entra ID User VPN connections
• Configure the Azure VPN Client – Microsoft Entra ID authentication – Linux (Preview)
• Configure P2S VPN gateway for Microsoft Entra ID authentication – manually registered app
• Migrate a manually registered Azure VPN Client to the Microsoft-registered client
• Configure P2S VPN Gateway for Microsoft Entra ID authentication
• Configure Azure VPN Client – Microsoft Entra ID authentication – Windows