Has anyone else with this same pairing encountered this issue? It’s not effecting my Mac users but Windows users are receiving a very unhelpful “Unknown Error” following authenticating in Chrome, using another browser or an older version of Chrome allows the client to connect. Latest version is 123.0.6312.59
Edit: Issue appears to be fixed in Chrome version 123.0.6312.86
Same problem with the Mac. It’s due to using an external IDp and the auth URL callback coming back to hit http not HTTPS. Browsers now block this
We saw this problem back on Feb with the chrome beta and reported it to AWS but no fix was issued alas. So now we are all unable to use the VPN client with either chrome or safari (still works with Firefox which is our current ugly workaround).
We weren’t getting much response from support on the issue so went via our account rep -
The newest rollouts of Safari ver 17.4 and Chrome ver 123.x are impacting the SAML auth flow for AWS client VPN (different reasons), for which you should be getting a PHD notification shortly.
So at least it’s moved to the point where its internally tracked and being worked on.
On MacOS14.4 here running Chrome Version 123.0.6312.59 (Official Build) (arm64).
Found some CLI switches that resolve it on an official Chromium issue thread: open -a "Google Chrome" --args --disable-features=PrivateNetworkAccessForNavigations,PrivateNetworkAccessForNavigationsWarningOnly https://issues.chromium.org/issues/330500719
Hope that helps, it looks like they’re reverting it shortly as it’s been raised to a P1/S1 issue on the Chromium side.
Other windows users in my office are experiencing a similar issue with the chrome upgrade this morning, I’m running on ubuntu, which installed google-chrome-stable:amd64 123.0.6312.58-1, this morning too. I’m experiencing the same issue.
The newest rollouts of Safari version
17.4 and Chrome version 123.x are
impacting the SAML authentication
flow for AWS client VPN, for which
you should be getting a PHD notification
shortly.These rollouts from Google and
Apple have been slow over the past few
days but will quickly ramp up and there
are many impacted customers. Our service
team is tracking the issue and we hope to
have more information on an impending fix
soon. In the meantime, the workaround has
been to use either Microsoft Edge or Firefox
as the default browser for the users, or
rollback to earlier versions of chrome/safari.
Based on some debugging I did with v123 (latest) and v122 of Chrome, it appears to be a CORS issue. In v123, an OPTIONS pre-flight request is being sent to http://127.0.0.1:35001 prior to the POST. In v122, there was no OPTIONS call made. I tested v123 with the --disable-web-security flag for debugging purposes only (which disables the pre-flight calls), and was able to connect successfully.
I’m assuming this change was to address a security bug with Chrome, but at least we know it’s an issue that will have to be addressed on Amazon’s end.
The AWS Client VPN team is aware of an issue affecting customers that use Chrome version 123 and SAML authentication. [1] We are working a new client release to address this issue, and as a workaround, we recommend using another browser, such as Firefox.
Please if possible use Firefox or Edge. AWS is currently working to identify and resolve the issue. Thank you for your patience.
On macOS Sonoma (fully updated) Safari and Chrome now work for me again. A Chromium forum thread indicated they were going to slowly roll out a reversal of some feature flag that broke SAML and I guess Apple has done something similar? Chrome no longer throws an unknown error and Safari properly resolves http://127.0.0.1:35001 without trying to redirect to HTTPS.
From a technical perspective I understand feature flags, but this is still creepy to me. Mainly because AWS, Apple, and Google are giant companies with no real customer service when weird shit like this happens. Though, in fairness, to a lesser extent Google given they are working in the open on their Chromium forum.
My companies SRE team raised this to AWS a couple of days ago and we’re responded to today. AWS are aware of the issue affecting the vpn client working with the latest version of chrome and are working on a patch. At this time their only advice for a workaround is to use another non-chromium browser.
I’ve received confirmation that the aws client vpn team is aware of the issue and are addressing it. I’ve also found that this chrome update is affecting other sso clients I use.
It is still possible to use chrome and work around this, while the clients address their underlying issues, disable the chrome flag (chrome://flags/) “Reduce waiting time for Private Network Access preflights response”
The new version of Chrome (123.0.6312.86) seems to have resolved the issue for me on Windows, can’t speak to other Chromium browsers/operating systems.
For our org it has stopped working after 2024-03 Cumulative Update for Windows 11 Version 23H2 for x64-based Systems ( was working with all versions of Chrome though)
Same issue on Linux (Arch). My last update actually included bumping AWS VPN Client to 3.12.1-1 and I got stuck during one day trying to fix it and was really confused by the downgrade to the previous version not working…
Downgrade of Chromium to 122.0.6261.94 works for now.