UDP Broadcast not working in docker bridge network

[akhil-paleri]

• This is a bug report
• This is a feature request
• I searched existing issues before opening this one

Expected behavior

UDP Broadcast request from docker container should reach external systems in same network.

Actual behavior

Broadcast from docker not forwarded to outside world in docker bridge network. It works fine in host network.

Steps to reproduce the behavior

Create a udp socker broadcast docker server/client

Docker network created using :

docker network create --driver bridge iot-edge

Docker run using host network (status : working)

docker run --name udpbroadcast --net=host -d udpbroadcast:latest

Docker run using created Bridge network (status : not working)

docker run --name udpbroadcast --net=iot-edge -p 808:808/udp -d udpbroadcast:latest

Output of Docker network inspect:

[
    {
        "Name": "iot-edge",
        "Id": "742cc706871bed7ddd8bb5e055712fc666324d664f1ab11f367aa5914c60aef7",
        "Created": "2019-03-28T18:07:31.165602753+05:30",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "f9475868ed2be90a6958e6d03a10691684cef276bdd5cb0a67e25fb8c4e1193f": {
                "Name": "udpbroadcast",
                "EndpointID": "20f7ba699ccaed718995c171fa8ad931bc009c6e10a30d776ddbf38fb12f4efd",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_forwarding": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "iot-edge",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {
            "com.docker.compose.network": "iot-edge",
            "com.docker.compose.project": "docker-compose",
            "com.docker.compose.version": "1.21.2"
        }
    }
]

Output of docker version:

Docker version 18.06.0-ce, build 0ffa825

Output of docker info:

Containers: 202
 Running: 13
 Paused: 0
 Stopped: 189
Images: 605
Server Version: 18.06.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d64c661f1d51c48782c9cec8fda7604785f93587
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.6.7-040607-generic
Operating System: Ubuntu 16.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.663GiB
Name: akhil-X556UR
ID: WMER:NGJV:OUEI:Q5DZ:YCSN:G22N:CCS2:YQDZ:LXCH:2TTL:RBFT:GEAG
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: akhil
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.)

[makidoll]

I've been having a similar problem. I've been looking everywhere for a solution why UDP packets get dropped

[krasowskir]

It is a linux issue.
You have to be root on a container and disable a the icmp_echo_ignore_broadcast variable.

to disable it
sysctl net.ipv4.icmp_echo_ignore_broadcasts=0

to control the output
sysctl net.ipv4.icmp_echo_ignore_broadcasts

after that you can try to ping the broadcast address.
ping -b 192.168.178.255

[jason-e-gross]

It is a linux issue.
You have to be root on a container and disable a the icmp_echo_ignore_broadcast variable.

to disable it
sysctl net.ipv4.icmp_echo_ignore_broadcasts=0

to control the output
sysctl net.ipv4.icmp_echo_ignore_broadcasts

after that you can try to ping the broadcast address.
ping -b 192.168.178.255

From inside the container or on the host?

[krasowskir]

inside of the container

[ghost]

I have a similar issue with Docker 19.03.5 when trying to send a WoL magic packet from inside the container. The /proc file system is R/O, so it cannot be changed inside the container.
Also, switching to to default Docker bridge network didn't help.

Obviously, it works with network_mode: host...

[readmodifywrite]

This issue persists on Docker version 19.03.12, build 48a66213fe

It is not an issue with the Linux host - it can broadcast just fine. We don't care about ICMP broadcasts, it's UDP.

[stef011]

I have the same problem, it would be useful to find a solution.

That's become weirder as it is outgoing traffic, which is usually permitted, every other IP address works...

The solution to switch to a host network isn't really a solution, because you loose a security layer :/

[davidjmstewart]

I'm experiencing exactly the same issue.

I have a NodeJS IoT app that can successfully perform UDP broadcasting on the host (a Raspberry-Pi v4), and in containers running in WSL, but do not seem to make it out of the container when running on the Raspberry-Pi v4. Running Docker Version 20.10.6

[FritschAuctores]

Any news, the problem is still present in the latest Docker version.

[WaywardWizard]

Isnt the docker bridge network a different broadcast domain?

Am i misunderstanding something here or are you expecting the udp broadcast to cross a broadcast domain boundary? Thats not happening because broadcasts have an extent of a broadcast domain by design