Docker seems to ignore no_proxy settings

[xaverkapeller]

Docker seems to ignore Bypass proxy settings when it is configured using the system proxy. However adding the IP instead of the domain to the bypass proxy settings fixes the issue.

• [x] I have tried with the latest version of my channel (Stable or Edge)
• [x] I have submitted Diagnostics
• [x] I have included the Diagnostics ID in this Issue

The example in this issue assume I have a service nexus.mydomain.com with the ip 192.168.0.10 in my local network and I need to add that service to my bypass proxy settings.

Expected behavior

1. Configure proxy bypass settings, include nexus.mydomain.com in bypass settings.
2. Start container and run curl nexus.mydomain.com in it.
3. Curl yields expected results.

Actual behavior

1. Configure proxy bypass settings, include nexus.mydomain.com in bypass settings.
2. Start container and run curl nexus.mydomain.com in it.

3. Curl fails with one of these errors:

   After 60 to 90 seconds the call fails with an error like this:

   SSL: certificate subject name '192.168.0.10' does not match target host name 'nexus.mydomain.com'

   Or a different SSL error like this:

   Host name 'nexus.mydomain.com' does not match the certificate subject provided by the peer (CN=192.168.0.10)

Information

Diagnostic ID: 55D9FA91-D8A9-4BDF-A8A6-1171CF6BB11F

Docker for Mac: version: 17.12.0-ce-mac55 (18467c0ae7afb7a736e304f991ccc1a61d67a4ab)
macOS: version 10.13.3 (build: 17D102)
logs: /tmp/55D9FA91-D8A9-4BDF-A8A6-1171CF6BB11F/20180326-083123.tar.gz
[OK]     vpnkit
[OK]     vmnetd
[OK]     dns
[OK]     driver.amd64-linux
[OK]     app
[OK]     virtualization VT-X
[OK]     moby
[OK]     system
[OK]     moby-syslog
[OK]     kubernetes
[OK]     env
[OK]     virtualization kern.hv_support
[OK]     moby-console
[OK]     osxfs
[ERROR]  logs
#ffb2b2#         logs check failed with: (Failure
  "exec: /usr/bin/log show --debug --info --style syslog --last \"1d\" --predicate \"process matches \\\".*(ocker|vpnkit).*\\\" || (process in {\\\"taskgated-helper\\\", \\\"launchservicesd\\\", \\\"kernel\\\"} && eventMessage contains[c] \\\"docker\\\")\" >\"/tmp/55D9FA91-D8A9-4BDF-A8A6-1171CF6BB11F/20180326-083123/docker-system-os.log\" 2>&1: exit 65")##
[OK]     docker-cli
[OK]     disk

Steps to reproduce the behavior

Again this example assumes I have a service nexus.mydomain.com with the ip 192.168.0.10 in my local network and I need to add that service to my bypass proxy settings.

1. Configure proxy settings for you network in the System Preferences. Add nexus.mydomain.com to the Bypass proxy settings
2. Start a container and run this curl: curl nexus.mydomain.com
3. Curl fails with the following error after 60 to 90 seconds:

     SSL: certificate subject name '192.168.0.10' does not match target host name 'nexus.mydomain.com'

4. Add 192.168.0.10 (the ip of nexus.mydomain.com) to the Bypass proxy settings in my System Preferences
5. Run the curl again and now it works just fine.

To elaborate on why I think this is a case of the bypass proxy settings being ignored: When just the domain - not the IP - is configured in my bypass proxy settings then as I explained the curl fails. If I run the curl with -vvv and look at the server certificate information it is not the certificate of nexus.mydomain.com, but the certificate of the proxy I am sitting behind. So when you are just adding the domain of the server your are trying to reach to your bypass proxy settings the connection is still trying to go through the proxy - only adding the IP of the server itself fixes that.

[xaverkapeller]

I just tested it again with the newest version: 18.03.0-ce-mac59. The error persists. Here again the Diagnostic ID and DIagnose Output:

ID: 55D9FA91-D8A9-4BDF-A8A6-1171CF6BB11F

Docker for Mac: version: 18.03.0-ce-mac59 (dd2831d4b7421cf559a0881cc7a5fdebeb8c2b98)
macOS: version 10.13.3 (build: 17D102)
logs: /tmp/55D9FA91-D8A9-4BDF-A8A6-1171CF6BB11F/20180327-090308.tar.gz
[OK]     vpnkit
[OK]     vmnetd
[OK]     dns
[OK]     driver.amd64-linux
[OK]     virtualization VT-X
[OK]     app
[OK]     moby
[OK]     system
[OK]     moby-syslog
[OK]     kubernetes
[OK]     files
[OK]     env
[OK]     virtualization kern.hv_support
[OK]     osxfs
[OK]     moby-console
[ERROR]  logs
#ffb2b2#         logs check failed with: (Failure
  "exec: /usr/bin/log show --debug --info --style syslog --last \"1d\" --predicate \"process matches \\\".*(ocker|vpnkit).*\\\" || (process in {\\\"taskgated-helper\\\", \\\"launchservicesd\\\", \\\"kernel\\\"} && eventMessage contains[c] \\\"docker\\\")\" >\"/tmp/55D9FA91-D8A9-4BDF-A8A6-1171CF6BB11F/20180327-090308/docker-system-os.log\" 2>&1: exit 65")##
[OK]     docker-cli
[OK]     disk

[akimd]

Hi!

This is a known issue. @djs55 is working on it for the next release.

[brymon68]

Can we get an update? @akimd

[leetrout]

Any update @akimd or @djs55 ??

[docker-robott]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[leetrout]

/remove-lifecycle stale /lifecycle frozen

[jonathanunderwood]

Any progress on this?

[roi972]

Also encountered this issue..

[open-developer-services]

same here

[Perdjesk]

Cross-linking https://github.com/moby/vpnkit/issues/408 which is required to resolve this issue.

Similar issues open :https://github.com/docker/for-mac/issues/2732

One workaround is as said before to use IP addresses instead of domains in the no_proxy configuration.

Another option is to inject the proxy configuration explicitly to the containers instead of relying on the transparent proxy (i.e the configuration in the GUI). See https://docs.docker.com/network/proxy/#configure-the-docker-client

This client configuration will propagate the explicit configuration to any started container:

% docker run -it alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=4ddc3e73c3ab
TERM=xterm
http_proxy=http://127.0.0.1:3001
HTTPS_PROXY=http://127.0.0.1:3001
https_proxy=http://127.0.0.1:3001
NO_PROXY=*.test.example.com,.example2.com
no_proxy=*.test.example.com,.example2.com
HTTP_PROXY=http://127.0.0.1:3001
HOME=/root

However the documented behavior here: https://docs.docker.com/docker-for-mac/#proxies, doesn't seem to work at all. The MacOS host proxy configuration is no automatically propagated to the container when not set to manual in the GUI settings.

[gfairchild]

I just encountered this on my Mac as well. I have to turn on the proxy settings during my docker build process so that I can reach out to the public internet for stuff, but then I have to disable my proxy settings when I docker push my built image to a local container registry. It's kind of a pain, and it would be wonderful if this got fixed.

[mrmijus]

Not exactly related, but let me just throw it out there. If you have no_proxy set in ~/.docker/config.json, it will override you Dockerfile ENV no_proxy. Someone from my team copied this from docker docs: { "proxies": { "default": { "httpProxy": "http://192.168.1.12:3128", "httpsProxy": "http://192.168.1.12:3128", "noProxy": "*.test.example.com,.example2.com,127.0.0.0/8" } } }

And left it on the server...

[bmakan]

Same issue on CentOS linux. Why does a default value overwrite a specific value? Shouldn't it be the other way around?

[chkpnt]

I had the same issue that no_proxy can't be used for https requests using the transparent proxy. Setting the proxy settings explicitly to empty value might be an work around for the connections from within the containers, but this has the drawback the proxy is disabled for the connection to the registry, too.

Hence I've just disabled the transparent proxy via "vpnKitTransparentProxy": false, in ~/Library/Group\ Containers/group.com.docker/settings.json. In my opion, there should be an option in the GUI for that.

[rwjack]

Testing with curl shows the following:

WORKS(goes directly, without proxy): no_proxy=service.home.arpa curl service.home.arpa -Lk DOESN'T WORK(tries going through proxy): no_proxy=*.home.arpa curl service.home.arpa -Lk

Might be a problem with how the shell interprets * in variables?

These also work: no_proxy=home.arpa curl service.home.arpa -Lk - if you want to catch https://home.arpa no_proxy=.home.arpa curl service.home.arpa -Lk - if you want to catch https://*.home.arpa I did both: no_proxy=.home.arpa,home.arpa

[varunkamath]

Any update on this?

[rwjack]

@varunkamath Not on mac, but this worked for me:

{
    "proxies": {
        "default": {
            "httpProxy": "http://proxy-host:1234",
            "httpsProxy": "http://proxy-host:1234",
            "noProxy": "localhost,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12, .local, .domain.tld, domain.tld"
        }
    }
}