AWS Client VPN SAML and Google Workspace: The Callback Gap

The app_not_configured_for_user page comes from Google Workspace, and it appears before a single tunnel packet is negotiated. That ordering is the whole diagnosis. Reinstalling the client, editing the profile or checking routes cannot clear a page the VPN endpoint has not seen yet. The failing step is a browser hand-off between the identity provider and a listener on the user's own machine, and there are exactly three things worth checking in that hand-off.

Read the page as an identity-provider statement

Google returns this when the SAML application is not enabled for the account that signed in. The app may be switched off, the user may sit outside the assigned organizational unit or group, or the service-provider settings may not match what the request asked for.

None of that is a certificate, route or tunnel problem, even though the VPN client is where the user noticed it.

The two values the client will accept

AWS Client VPN runs a service-provider-initiated SAML exchange, so the client opens a browser, the user authenticates, and the provider posts a signed assertion back to an Assertion Consumer Service URL. For the AWS-provided desktop client that URL is a listener on loopback, commonly port 35001, and the expected audience is the Client VPN SAML application's entity identifier rather than the AWS console sign-in entity.

Both values have to match what the client expects: where the assertion is posted and who it is addressed to. A configuration copied from a console SSO application can look entirely plausible and still target the wrong pair.

Take both values from the Client VPN SAML requirements, not from a generic AWS single sign-on guide. The console SSO entity looks similar enough to be tempting. It is a different application with a different audience, and the client rejects the assertion without explaining itself. Copy the pair once, and store it next to the profile.

Google will not accept the plain-HTTP callback

The admin console requires an HTTPS ACS URL, and the client's callback is plain HTTP on loopback. That value cannot be typed into the Workspace app configuration at all, which is why some teams try a reverse proxy that terminates TLS and forwards to the local listener. That does not repair the mismatch: the browser sees one origin, the client advertises another, and the returned response can arrive with the wrong destination.

The arrangement that works is a broker identity provider. The SAML application at the broker gets the loopback callback and the AWS audience, and the broker federates the Workspace account upstream. Google's HTTPS rule stays satisfied, and the assertion that reaches the client still names the address and audience it expects.

That broker is an administrative dependency someone has to own, monitor and include in offboarding. It is also a second place where an outage turns into a login failure. Price it before promising the design. If nobody will own it, the honest answer is that the AWS client cannot use Workspace as its only identity provider.

Assignment and two-step verification

Before redesigning anything, confirm the app is on for the right organizational unit or group, and that third-party SAML apps have their own assignment controls separate from the Google-side app list.

Also check whether the account has two-step verification enabled. Google can require it before a SAML app becomes usable for a user, and a single answer in the original thread was resolved exactly that way. It is the cheapest thing to rule out and the most annoying to discover last.

Verify with a clean session

After any change, test with a fresh browser profile and a clean client configuration. Cached assertions and reused sessions hide whether the fix landed.

Then compare two records side by side: the identity provider's audit event and the client log. A successful sign-in with no tunnel points back at the callback or the audience. A connected tunnel with an unreachable resource is a routing or authorization problem and belongs somewhere else entirely.

What not to change

Do not strip auth-federate from the profile or disable certificate checks to get past the page. Both change the authentication design rather than the failing callback, and both tend to break at the next client update.

Fix the hand-off instead, and leave a note that names the broker, the audience and the loopback port. The next person to see the page will need all three.