I made the same observation with the DNS port 53/UDP example, and saw it again with my TFTP port 69/UDP example.
So far, I could not figure out the reason or a countermeasure why UDP fails to work when external & internal ports differ and port address translation becomes necessary. From the logs, it looks as if requests make it to the server inside the microVM OK. But its answers do not make it back to the client somehow.
Eventually, is it connected to the speciality with UDP on Fly.io, where the server must bind to the address fly-global-services. Or, does eBPF fail at the reverse port address translation of outgoing reply packets “somehow”?