"Login did not succeed" error running Docker Desktop on macOS with SEP Web and Cloud Access Agent in tunnel mode

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users access internet via Cloud SWG using the SEP Web and Cloud Access Protection Agent in tunnel mode.

Launching the Docker Desktop on macOS devices fails and returns a docker login error shown below - running the following 'docker run hello-world' or 'docker login' commands from the terminal also fail:

abcd123@321NMD6T % docker login
Authenticating with existing credentials...
Login did not succeed, error: Error response from daemon: Get "https://registry-1.docker.io/v2/": Get "https://auth.ipv6.docker.com/token?account=davidashby547&client_id=docker&offline_token=true&service=registry.docker.io": Service Unavailable
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username (abcd123): abcd123
Password: 
Error response from daemon: Get "https://registry-1.docker.io/v2/": Get "https://auth.ipv6.docker.com/token?account=davidashby547&client_id=docker&offline_token=true&service=registry.docker.io": Service Unavailable

Opening https://registry-1.docker.io/v2/library/hello-world/manifests/latest in a browser and looking at the response headers, it always seems to get bearer token from the ipv6 site:

www-authenticate Bearer realm="https://auth.ipv6.docker.com/token",service="registry.docker.io",scope="repository:library/hello-world:pull"

Docker appears to try and log user in using IPv6 instead of IPv4 endpoints.

When host disables the SEP Web and Cloud Access Agent, user is able to login successfully.

abcd123@321NMD6T % docker login
Authenticating with existing credentials...
Login Succeeded

With the SEP Web and Cloud Access Agent disabled, user is redirected to a different, non IPv6 endpoint at auth.docker.io.

Environment

SEP Web and Cloud Access Agent on macOS (all versions).

WSS Agent on macOS (all versions).

 

Cause

Docker back end parses an X-Forwarded-For (XFF) HTTP header that includes an IPv6 address and redirects to IPv6 endpoints.

When Cloud SWG Header modification is enabled to 'Anonymize IP', it will always include a random IPv6 address in the XFF header even though the HTTP request comes from an IPv4 egress IP address (Cloud SWG does not support IPv6 at the current time). Docker uses the XFF header and not the inbound IP address to determine what IP version is being used, and hence challenges via an IPv6 endpoint.

Resolution

The following solutions will address the issue:

1. Make sure that the 'Header modification' Policy does NOT 'Anonymize IP': When doing this, the XFF header will always include a random IPv6 address.

2. Disable SSL interception for the docker domains: Doing so will prevent Cloud SWG from injecting the X-Forwarded-For IP address.

3. For UPE customers, the request.header.X-Forwarded-For CPL can be used with any of the following actions - append( ),delete( ),delete_matching( ),rewrite( ),set( ) - to manipulate the addresses.

Additional Information

When launching the docker commands, it attempted to do a DNS A request for what appeared to be an IPv6 only domain. In all cases, the response was empty (WSS / SEP Agent does not tamper with the response).

At not point did PCAPs show an Ipv6 DNS AAAA record for the auth.ipv6.docker.com domain - only DNS A record over IPv4 - indicating that the info came from elsewhere.

Docker favoured connection to IPv6 auth endpoints because of the XFF header including a random IPv6 address.