Why Docker’s UDP Traffic Fails on Bridge Networks and How to Fix It

Problem Background

In a Docker environment an application that communicates over UDP stops working when the server listens on 0.0.0.0 on the host (or in a container with --network=host) while the client runs in the default bridge network. The same service works with TCP, and the issue does not appear when the server binds to a specific host interface.

Reproducing the Issue

On Ubuntu 16.04 the author starts a UDP server with nc -ul 56789 on the host, then runs a container using the default bridge network and sends data with nc -u 172.16.13.13 56789. The first packet is received, but subsequent packets are never delivered.

$ nc -ul 56789
$ ss -uan | grep 56789
udp UNCONN 0 0 *:56789 *:*

The container obtains IP 172.17.0.3 and is connected to docker0 (172.17.0.1). The host’s external interface is eth0 (172.16.13.13).

tcpdump Analysis

Capturing on docker0 shows the first client‑to‑server packet is transmitted, but the server’s reply triggers an ICMP “port unreachable” message, after which all further packets are dropped.

11:20:43.973286 IP 172.17.0.3.38908 > 172.16.13.13.56789: UDP, length 6
11:20:50.102018 IP 172.17.0.1.56789 > 172.17.0.3.38908: UDP, length 6
11:20:50.102129 IP 172.17.0.3 > 172.17.0.1: ICMP 172.17.0.3 udp port 38908 unreachable

Root Cause Analysis

The server’s reply uses the address of docker0 as the source IP instead of the host’s eth0. Because UDP is stateless, the kernel selects the source address based on the outgoing interface. When multiple interfaces exist, the kernel may pick the wrong one, and the client treats the packet as illegal, generating ICMP errors.

Comparing a working DNS server (dnsmasq) with the failing application reveals three differences:

dnsmasq uses IPv4, the failing app uses IPv6 (mapped to IPv4).

dnsmasq uses recvmsg / sendmsg, the failing app uses recvfrom / sendto.

dnsmasq sets the socket option IP_PKTINFO, the failing app does not.

Setting IP_PKTINFO allows the application to supply the desired source address (via ipi_spec_dst) in the ancillary data of sendmsg. Without it, the kernel’s routing lookup chooses the address of the interface the packet traverses (docker0), leading to the mismatch.

Additionally, the kernel’s conntrack module records UDP “connections” based only on the observed 5‑tuple. When the reply’s source address differs from what conntrack expects, the packet is dropped before NAT (SNAT) can rewrite it.

Solutions

Three practical ways to resolve the problem:

Switch to TCP, which does not suffer from the source‑address selection issue.

Bind the UDP server to a specific host interface instead of 0.0.0.0: $ nc -ul 172.16.13.13 56789 This forces the kernel to use the correct source IP.

Modify the application to enable IP_PKTINFO and use recvmsg / sendmsg for I/O, ensuring the intended source address is used.

References

Docker UDP issue: https://github.com/moby/moby/issues/15127 IOTA IRI issue: https://github.com/iotaledger/iri/issues/961 StackOverflow discussion on setting source IP for UDP sockets: https://stackoverflow.com/questions/3062205/setting-the-source-ip-for-a-udp-socket Linux man page for IP_PKTINFO and related kernel documentation.