search

docker / for-win

Bug reports for Docker Desktop for Windows
https://www.docker.com/products/docker#/windows
1.87k stars 289 forks source link

Docker Desktop 4.15.0 proxies all HTTP traffic #13127

Open ben-page opened 1 year ago

ben-page commented 1 year ago

Actual behavior

On Docker Desktop 4.15.0 all HTTP traffic from within Docker appears as proxied traffic and is blocked by our corporate firewall.

Expected behavior

Information

This did not happen on Docker Desktop 4.14.1. This happens on a fresh install with default settings. The manual proxy is not enabled.

Output of & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" check

[2022-12-13T18:10:25.701511900Z][com.docker.diagnose.exe][I] set path configuration to OnHost Starting diagnostics

[PASS] DD0027: is there available disk space on the host? [PASS] DD0028: is there available VM disk space? [PASS] DD0002: does the bootloader have virtualization enabled? [SKIP] DD0018: does the host support virtualization? [PASS] DD0001: is the application running? [PASS] DD0022: is the Virtual Machine Platform Windows Feature enabled? [PASS] DD0021: is the WSL 2 Windows Feature enabled? [PASS] DD0024: is WSL installed? [PASS] DD0025: are WSL distros installed? [PASS] DD0026: is the WSL LxssManager service running? [PASS] DD0029: is the WSL 2 Linux filesystem corrupt? [PASS] DD0035: is the VM time synchronized? [PASS] DD0017: can a VM be started? [PASS] DD0016: is the LinuxKit VM running? [PASS] DD0011: are the LinuxKit services running? [PASS] DD0004: is the Docker engine running? [PASS] DD0015: are the binary symlinks installed? [PASS] DD0031: does the Docker API work? [PASS] DD0013: is the $PATH ok? [PASS] DD0003: is the Docker CLI working? [PASS] DD0005: is the user in the docker-users group? [PASS] DD0014: are the backend processes running? [PASS] DD0007: is the backend responding? [PASS] DD0008: is the native API responding? [PASS] DD0009: is the vpnkit API responding? [PASS] DD0010: is the Docker API proxy responding? [PASS] DD0006: is the Docker Desktop Service responding? [PASS] DD0012: is the VM networking working? [SKIP] DD0030: is the image access management authorized? [PASS] DD0033: does the host have Internet access? [PASS] DD0002: does the bootloader have virtualization enabled? [PASS] DD0018: does the host support virtualization? [PASS] DD0001: is the application running? [PASS] DD0022: is the Virtual Machine Platform Windows Feature enabled? [PASS] DD0021: is the WSL 2 Windows Feature enabled? [PASS] DD0024: is WSL installed? [PASS] DD0025: are WSL distros installed? [PASS] DD0026: is the WSL LxssManager service running? [PASS] DD0029: is the WSL 2 Linux filesystem corrupt? [PASS] DD0035: is the VM time synchronized? [PASS] DD0017: can a VM be started? [PASS] DD0016: is the LinuxKit VM running? [PASS] DD0011: are the LinuxKit services running? [PASS] DD0004: is the Docker engine running? [PASS] DD0015: are the binary symlinks installed? [PASS] DD0031: does the Docker API work? [PASS] DD0032: do Docker networks overlap with host IPs? No fatal errors detected.

Steps to reproduce the behavior

  1. Install Docker Desktop 4.15.0
  2. Run docker -it --rm debian:latest
  3. Run apt-get update
  4. Get a 403 from our firewall
DavideNardone commented 1 year ago

Hi, I have a similar problem. After updated from Docker Desktop 4.12 to Docker Desktop 4.15, HTTP requests from inside containers to web server placed on the host machine return "404 not found". Firewall rules all disabled. Any suggestion would be very appreciated. Thank you. D

desincarnage commented 1 year ago

We are experiencing the same problem here. DPI rules on our firewall blocks outgoing traffic from Docker Desktop for Windows. It is detected as a Proxy application.

ben-page commented 1 year ago

Disabling Automatic proxy detection in Windows works around the issue.

ben-page commented 1 year ago

To be clear, we do not have normal proxy. But our firewall does have a transparent proxy.

And even though no proxy server is detected, simply enabling Automatic proxy detection changes the packets sent by Docker. Which gets it blocked by the firewall.

RichardDavies commented 1 year ago

Our corporate network does TLS/SSL decryption and inspection and this change is impacting our Docker usage as well. Fortunately disabling automatic proxy detection is working as a workaround for us.

djs55 commented 1 year ago

Thanks for the report. The HTTP requests must be being modified in some unexpected way when they pass through Docker (which does have an HTTP proxy inside, but in this case it should be invisible)

RichardDavies commented 1 year ago

@djs55 FYI, based on our debugging, it seemed that the HTTP requests in Docker were being forcefully "upgraded" to HTTPS.

djs55 commented 1 year ago

@RichardDavies that's very interesting! Could you share the raw HTTP request (anonymised if necessary) with something like curl -vvv? If I can reproduce it locally then I should be able to sort it out.

RichardDavies commented 1 year ago

@djs55 Sorry, I guess I misspoke a bit. Here's what we're experiencing in the container: image

However, if I try that same command outside of the container, that's where we see the upgrade to HTTPS due to HSTS policy for that domain: image

JAZ-013 commented 1 year ago

I have been experiencing something similar to this. This proxy in Docker Desktop was changing HTTP/1.0 requests into HTTP/1.1. Normally shouldn't be a problem, but under PHP7.4 HTTP/1.0 is the default and is used by the HTTP stream functions (such as file_get_contents()).

What I am seeing happen here is the client (PHP) is issuing a "Connection: close" header and expecting the server to close the connection, but this is not supported behavior on HTTP/1.1 so the server never closes the connection and both ends just sit there waiting until the connection timeout is hit. This is causing all my applications that have HTTP functions to hang.

I have just updated to 4.16.2 and noticed that this behavior has changed and requests are staying as HTTP/1.0. Just thought I would comment that here to see if anyone is able to confirm that updating the 4.16.2+ fixes their issues as well.

Daveography commented 1 year ago

Just encountered the same problem where our company firewall believes my containers are attempting to proxy http connections through the company firewall; upgrading to 4.16.2 did not fix the issue.

azriek commented 1 year ago

Hi, I have the same issue with fresh install of 4.16.2 on windows 11.

Disabling automatic proxy detection workaround did the trick.

Sniffing packet with wireshark when executing curl -I http://deb.debian.org/debian/dists in a fresh container :

root@27129d446020:/# curl -Ivvvv http://deb.debian.org/debian/dists

  • Trying 151.101.122.132:80...
  • Connected to deb.debian.org (151.101.122.132) port 80 (#0)

    HEAD /debian/dists HTTP/1.1 Host: deb.debian.org User-Agent: curl/7.74.0 Accept: / ....

HEAD /debian/dists HTTP/1.1 Host: deb.debian.org User-Agent: curl/7.74.0 Accept: /

HTTP/1.1 301 Moved Permanently Connection: keep-alive Content-Length: 307 .....

HEAD http://deb.debian.org/debian/dists HTTP/1.1 Host: deb.debian.org User-Agent: curl/7.74.0 Accept: /

HTTP/1.1 403 Forbidden X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block ....

jeffska commented 1 year ago

I'm also having issues with the automatic proxy where the proxy is changing Transfer-Encoding to chunked and web service requests are failing since the service doesn't expect them to be chunked.

djs55 commented 1 year ago

There have been some fixes in the development branch (which will become 4.17) if you have some time to test: https://desktop-stage.docker.com/win/main/amd64/96699/Docker%20Desktop%20Installer.exe

Previously the HTTP proxy was regenerating requests (which it shouldn't have been), which caused problems e.g. insertion of Transfer-encoding headers and other problems.

Let me know if the development build is any better. If not, could you share some more wireshark traces and I'll investigate further on monday.

Thanks for your patience with this!

jeffska commented 1 year ago

I tried the development build, and with both Windows and Docker proxy settings set to auto the request went through unmodified. So that solved my issue.

However, if a proxy is active (i.e. Fiddler), the request does get rewritten; including changing the Content-Encoding; which then fails. I am dealing with a service that's technically not compliant w/ HTTP 1.1. But I'm not sure it's really a good practice to be re-encoding the payload in cases like that. I'm also thinking that it could be an issue if the proxy in use only supports HTTP 1.0 and the internal proxy is re-writing requests as HTTP 1.1.

azriek commented 1 year ago

My issue is solved too with the development build. No URL transformation anymore.

hlourencomarques commented 1 year ago

In my case, this development build still doesn't work with the Docker "Manual proxy configuration" enabled and I suspect that not all the cases are fixed. However, this manual proxy configuration was working before version 4.15.0.

gremo commented 1 year ago

Same problem here, but I’ve got it working with Docker desktop 4.17 only if I disable Windows automatic proxy detection.

I don't want to mess with Windows settings. How this could be solved only changing Docker settings?

Scherlac commented 1 year ago

How can we disable automatic proxy detection / transparent proxy in vpnkit? Does this automatic proxy support no_proxy configuration somehow? My issue is with connecting to an on-premises service. The last version of Docker Desktop we are able to connect to this service is 4.13.1. We are using WLS2 on Windows.

Update: As a workaround I moved the on-premises service to a different port and that solved the issue for this particular case.

drpauldixon commented 1 year ago

This is the same for me and my colleagues working behind a corporate proxy on Mac. We have all had to downgrade to version 4.14.1 as all network requests are sent via the system proxy (we cannot disable the system proxy). During build/run we set a specific proxy to pull down artefacts from an artefact store and for any version above 4.14.1, this results in all requests to get those assets failing with [Errno 14] HTTP Error 403 - Forbidden.

A simple test we have been performing:

docker run -it centos:7 /bin/bash
yum -y install curl
curl -s -v -x proxy:port http://repo.internaldomain/x -o /dev/null

4.14.1 works fine (200 response). Anything above 4.14.1 fails with a 403 because the request is routed via the system proxy on the Mac instead of the proxy:port used in the curl command.

drpauldixon commented 1 year ago

This is still happening with version 4.23.0.

curl -s -v -x 10.12.12.100:80 http://repo.internaldomain.com
* About to connect() to proxy 10.12.12.100 port 80 (#0)
*   Trying 10.12.12.100...
* Connected to 10.12.12.100 (10.12.12.100) port 80 (#0)
> GET http://repo.internaldomain.com/ HTTP/1.1
> User-Agent: curl/7.29.0
> Host: repo.internaldomain.com
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 403 connecting to repo.internaldomain.com:80: resolving host repo.internaldomain.com: lookup repo.internaldomain.com: no such host
< Connection: close
<
* Closing connection 0
connecting to repo.internaldomain.com:80: resolving host repo.internaldomain.com: lookup repo.internaldomain.com: no such host

Workaround

  1. Uninstall Docker Desktop
  2. Install Rancher Desktop
  3. Test
curl -s -v -x 10.12.12.100:80 http://repo.internaldomain.com
* About to connect() to proxy 10.12.12.100 port 80 (#0)
*   Trying 10.12.12.100...
* Connected to 10.12.12.100 (10.12.12.100) port 80 (#0)
> GET http://repo.internaldomain.com/ HTTP/1.1
> User-Agent: curl/7.29.0
> Host: repo.internaldomain.com
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< Date: Tue, 19 Sep 2023 14:44:56 GMT
< Content-Type: text/html;charset=ISO-8859-1
< Connection: keep-alive
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
...
drpauldixon commented 1 year ago

Just tested on an M1 Mac and same issue as my Intel Mac.

rhastie commented 9 months ago

I'm also seeing this with version 4.27.2... Exact same error on Docker Desktop for Windows but obviously a different internal FQDN. Any suggestions to bypass or disable the proxy would be great