Unsuccessful aws sso login --profile when using VPN

[Builder1978]

Hello,

I have problem to successfully perform command aws sso login --profile some-profile when I'm connected in VPN. When I'm not connected in VPN, everything works fine. Any suggestion how to make aws sso login --profile some-profile working in VPN? See attached detailed log: log.txt.

Thanks,
Peter

[uldyssian-sh]

From your debug log, the login fails when AWS CLI tries to exchange the auth code for a token against the SSO OIDC endpoint:

https://oidc.us-east-1.amazonaws.com/token

The error is a connection reset during the TLS handshake/request:

ConnectionResetError: [WinError 10054] ... forcibly closed by the remote host
botocore.exceptions.ConnectionClosedError: Connection was closed before we received a valid response ... oai_citation:1‡log.txt

That strongly indicates the VPN (or something on the VPN path: corporate proxy / TLS inspection / firewall) is interrupting HTTPS traffic to the AWS SSO OIDC endpoint, not an AWS CLI configuration problem.

What to do:

Ensure your VPN policy allows outbound HTTPS (TCP/443) to these AWS SSO endpoints, and ideally split-tunnel them (or allowlist them) so they do not go through an intercepting proxy:

oidc.us-east-1.amazonaws.com

and your IAM Identity Center start URL host (the d-xxxxxxxxxx.awsapps.com domain shown in your config/log).

If your VPN requires a proxy, make sure Windows/CLI is actually using it (or explicitly set it for the CLI process):

set HTTPS_PROXY=http://proxy-host:port
set HTTP_PROXY=http://proxy-host:port
set NO_PROXY=127.0.0.1,localhost

If your VPN performs TLS inspection, install the corporate root CA and make the AWS CLI trust it (otherwise some networks will drop/reset connections). You can test trust by running a simple HTTPS request to the OIDC endpoint from the same VPN session; if TLS interception is present, you must add the corporate root CA to the trusted store.

As a workaround to reduce “local callback” complexity on restricted networks, try the device-code flow:

aws sso login --profile solar-libra-dev --use-device-code

This uses a device authorization flow and often works better behind strict VPN/proxy setups.

Bottom line: the fix is on the network/VPN side (allowlist/split-tunnel or proxy/CA configuration) so HTTPS to oidc.us-east-1.amazonaws.com is not being reset. oai_citation:2‡log.txt

[uldyssian-sh]

Thanks! If this helps, please consider marking it as “Helpful” or “Accepted” 😊