IP address given to container is not routable in bridge mode

Expected behavior

When launching a container which has HostConfig.NetworkMode=default (which ends up using the bridged network), I can connect to exposed ports via the container’s IP address.

Actual behavior

The container appears to be using the bridged network but the IP address cannot be connected to from the host.

        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "f0638e5bd88c370e6128bde1b35b173cb96d7644fb2719e2bd02785a6f197fbd",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {
                "8080/tcp": [
                        "HostIp": "",
                        "HostPort": "24142"
            "SandboxKey": "/var/run/docker/netns/f0638e5bd88c",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "05af5b877f62bf6dbd951ed44813cb84978c6ddc9f15aea06e59ba62342b6d38",
            "Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "MacAddress": "02:42:ac:11:00:03",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "9dcb93c83e3ee5f37ed6522cc23d730f2c295703f40e12d9223e427335c0b852",
                    "EndpointID": "05af5b877f62bf6dbd951ed44813cb84978c6ddc9f15aea06e59ba62342b6d38",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:11:00:03"
$  ping
PING ( 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
76 bytes from 80.239.169-193.customer.teliacarrier.com ( Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 97e7   0 0000  3f  01 0bad

Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
--- ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss


$ pinata diagnose -u
OS X: version 10.11.4 (build: 15E65)
Docker.app: version v1.11.1-beta12
Running diagnostic tests:
[OK]      Moby booted
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      db
[OK]      slirp
[OK]      menubar
[OK]      environment
[OK]      Docker
[OK]      VT-x
Docker logs are being collected into /tmp/20160519-124613.tar.gz
Most specific failure is: No error was detected
Your unique id is: DBEB5305-D47A-4DF5-B381-B476CECD36A0
Please quote this in all correspondence.

Steps to reproduce the behavior

  1. Install Docker for Mac
  2. Start a container with an exposed port, using default network settings
  3. Attempt to connect to the 172.17.x.x address.

Some more info:

$ docker network ls
NETWORK ID          NAME                DRIVER
9dcb93c83e3e        bridge              bridge
4938213ca670        host                host
75c77e1faa41        none                null

$ docker network inspect bridge
        "Name": "bridge",
        "Id": "9dcb93c83e3ee5f37ed6522cc23d730f2c295703f40e12d9223e427335c0b852",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                    "Subnet": ""
        "Internal": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        "Labels": {}

Yep, Docker staff is aware of the situation. Please have a look at these threads for more information:

Thanks. Is there any way to track the issue? I saw a reference to an issue number in one of the threads but not a link.

The internal issue number is #2216. I don’t think there’s a way for us common folk to track the issue apart from looking at those threads (but there’s then handy “track” feature though).