Which Client Can Complete an AWS Client VPN SAML Login

Two people ask the same question about AWS Client VPN and SAML, and get opposite answers. One signs in from an Ubuntu laptop every morning; the other has a phone, a downloaded profile, and a client that rejects a line in it. The difference is not luck and not a hidden dashboard switch. It comes down to three conditions: whether the platform is one AWS supports for its own client, whether the tool you are holding can run the federated browser exchange, and whether the endpoint is configured for SAML at all. Miss any of the three and the sign-in stalls at a different point.

Three conditions decide whether the login can finish

The platform comes first. AWS ships its own Client VPN client for Windows, macOS and Ubuntu on AMD64, and as of late October 2026 the Linux requirements page names Ubuntu 22.04, 24.04 and 26.04. A repackaged build, a converted package or a different distribution may run, but it is not a supported platform, and when it breaks you are the support line.

The client comes second. Federated sign-in is not a profile option that every OpenVPN-compatible app parses. The provided client opens your identity provider in a browser, receives the signed authentication response, and submits that response to the endpoint. An app that only reads the profile and dials a tunnel is not performing this step, however clean its connection log looks.

The endpoint comes third. An endpoint using Active Directory credentials or mutual certificates has a different arrangement entirely, and swapping clients will not change it. Confirm the authentication mode with whoever issued the profile before you debug anything else.

Taken together, the three conditions give a short decision table:

Why an OpenVPN import stops at auth-federate

An exported AWS Client VPN profile carries a directive telling the client that authentication happens outside the tunnel, through federation. A generic OpenVPN client either refuses the line outright or ignores it and then has no credential to offer. That is where most Android attempts end: the profile imports, the app objects, or the connection dies with a configuration error before a single packet leaves the device.

Deleting auth-federate is the tempting next move, and it turns a clear failure into a confusing one. Removing a directive does not convert a SAML endpoint into username-and-password authentication. The endpoint still expects a signed SAML response and rejects whatever the client sends instead. Your account password, the downloaded profile and a copied assertion are not interchangeable credentials.

Signing in to the identity provider in Chrome on the phone only proves that the identity provider accepted the user. It says nothing about the response reaching a client that can post it back to the endpoint. The federated authentication requirements make the provided client part of the flow for exactly that reason: the browser step is necessary and not sufficient.

What the supported Linux desktop path looks like

Install the package AWS publishes for Ubuntu AMD64 with your system package manager, then open the connection from that client rather than importing the profile into a general-purpose VPN app. Use the profile your administrator exported for this endpoint; do not substitute a callback URL or a client identifier from an older walkthrough, even if the client accepts it.

Start the connection, complete sign-in and any MFA prompt in the browser that opens, and let the browser-to-client return flow finish. Then request the private address you actually need, fresh. A page announcing a successful sign-in is not evidence that the tunnel came up.

The Linux client reserves local TCP ports 8096 through 8115 for SAML responses. When the hand-off hangs after the identity provider has accepted you, check what is already listening in that range:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

An occupied port, or endpoint security software that blocks the loopback listener, produces a sign-in that appears to complete and then never connects. Keep that range local. It is a client-side return path, not something to open in an EC2 security group or a gateway firewall rule, and opening it to the internet adds exposure while fixing nothing.

Read the failing stage before you change anything

Blaming the client is the usual reflex, but each failure point belongs to a different owner. Work out where you actually are first.

• No browser window opens. Check the profile authentication mode, the connection you selected, and the desktop default-browser integration.
• The identity provider rejects the account. Account assignment, MFA enrollment or the SAML application configuration, all administrator territory.
• The browser finishes but the client never connects. An expired or unusable authentication response, a blocked return port, or a failed hand-off.
• The tunnel is up but the application is unreachable. Endpoint routes, authorization rules, security groups, DNS. Repeating the browser login cannot add a missing network permission.

Keep the client error text and the time of the attempt when you escalate. The statement that SAML is broken and the statement that the client never received a valid authentication response send people to completely different places.

When the requirement is Android anyway

Android is not a platform AWS publishes its client for, so the honest answer is that there is no supported mobile client to install. That is a design constraint, not a puzzle to solve on the phone by editing the profile until something connects.

What can change is the access design behind it, and that decision belongs to the administrator: an approved application-access path to the one internal service the phone needs, a mobile-capable VPN product the organization already operates, or a supported desktop for the SAML-only endpoint. Each option brings its own endpoint configuration, identity enrollment and authorization rules, none of which a user can create from a downloaded profile.

Third-party tools that claim to close the gap need an explicit support and security review covering MFA, response handling, device policy and update cadence. Their existence does not make them an AWS-provided Android client, and you should not move reusable authentication material onto a phone to make one work.

Hand the administrator three facts instead of a long thread about directives: the endpoint authentication mode, the private resource the phone must reach, and the deadline. That is enough to choose between a desktop, an application-access path and a new VPN product.

Check the conditions in order before opening another ticket: platform on the provided-client list, a tool that can complete the browser exchange, an endpoint genuinely configured for federation, and, on Linux, the loopback port range. The first item that fails is the one to fix. Everything past it is guesswork.