I have a UDP server on a Windows 10 host, on a fixed port (let's say 1234). All I want is to set up a communication between this server and a client in a Docker (Debian-based) container (Docker version 20.10.6). This is using WSL2.
Note that my UDP client can't use a specific source port, it takes a random one.
Using the default docker networking option (docker run --net bridge ...), the docker container has IP address 172.17.0.2 on its eth0@if10 interface. The Windows host has IP address 172.27.192.1 on its Ethernet adapter vEthernet (WSL) interface. The UDP packets arrive to the server, the server replies, but receives an ICMP port unreachable message. This is because the packets have been rewritten somewhere on their path. The packets as seen on the eth0@if10 interface inside the Docker container are normal: 172.17.0.2:some random port => 172.27.192.1:1234. From the Windows host, I see them (as well as the replies from the server) on the Adapter for loopback traffic capture in Wireshark. But there, they have been rewritten to 172.27.192.1:another port => 172.27.192.1:1234! So the replies never make it to the container.
What puzzles me is that TCP and pinging (from the container to the host) work just fine. The packets are identically rewritten... But they make their way safely back to the container.
Now I would like to try disabling this NAT, but this is complicated by the fact that if I send packets from the Windows host to the container (172.17.0.2), the packets are sent over the Ethernet interface and lost in the void. I've tried adding a static route to tell that 172.17.0.0/24 should go through the 172.27.192.1 gateway, but then I see the gateway sending ARP packets asking who has 172.17.0.2.
Using docker run --net host ... suffers from essentially the same issue. I see the IP address of the host from this container is 192.168.65.2 (with dig host.docker.internal). I also see that the packets will take the eth0 interface. Watching this interface and Adapter for loopback traffic capture from the host, I see the packets are rewritten from 192.168.65.3:some random port => 192.168.65.2:1234 to 127.0.0.1:another port => 127.0.0.1:1234. And again the UDP server receives destination unreachable ICMP messages after trying to reply.
