LXD Proxy device UDP issue, does not always forward packets [invalid]

LXD
,
1

Question is invalid, I forgot to check tcpdump in the container itself and there the packets arrive. Ignore the full post then. (netcat seems to only listen to one “session”, there is a “-k” option for nc to allow multiple connections)

Hello, I don’t know if this is an understanding issue on my side or a bug in LXD 4.0.9. When using a proxy device with UDP, once the source port changes (at least thats the only thing I see right now), the packets are not forwarded to the container. This example tries to illustrate reconnection issues I have with an application which heavily uses UDP - its possible that it doesn’t reflect the real issue, but the issue/question in the example still applies.

First: The device is added:

root@snoot:~# lxc config show ts3
...
devices:
  debug-udp-10234:
    bind: host
    connect: udp:127.0.0.1:10234
    listen: udp:0.0.0.0:10234
    type: proxy

Second: In the container I listen to this UDP port (includes all output of the sender below):

root@ts3:~# nc -l -u 10234
foo
foo

Third: On the host I tcpdump this port:

root@snoot:~# tcpdump -i any -nv port 10234
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
22:36:59.714736 eno1  In  IP (tos 0x0, ttl 128, id 1505, offset 0, flags [none], proto UDP (17), length 32)
    192.168.0.36.53316 > 192.168.0.61.10234: UDP, length 4
22:37:06.433663 eno1  In  IP (tos 0x0, ttl 128, id 1506, offset 0, flags [none], proto UDP (17), length 32)
    192.168.0.36.53316 > 192.168.0.61.10234: UDP, length 4
22:37:11.324447 eno1  In  IP (tos 0x0, ttl 128, id 1507, offset 0, flags [none], proto UDP (17), length 32)
    192.168.0.36.63445 > 192.168.0.61.10234: UDP, length 4

Fourth: On my windows pc I try to send those packets, but after the second one I’ll open nc freshly:

C:\Users\Dionysius
λ ncat.exe -u snoot.fritz.box 10234
foo
foo
^C
C:\Users\Dionysius
λ ncat.exe -u snoot.fritz.box 10234
bar

As you can see, messages of the second instance of nc do not get through. Am I missing something?

(The same behaviour can be observed also when the host itself is the nc sender, to rule out my local network)