So first lets have a look at how the UDP proxy works before we move onto Jitsi Meet.
So I setup a basic ubuntu 18.04 container (running on ubuntu 18.04 HWE kernel) and added a proxy as follows:
lxc launch ubuntu:18.04 c1
lxc config device add c1 p1 proxy listen=udp:0.0.0.0:10000 connect=udp:0.0.0.0:10000
I then check the listening UDP ports on the LXD host and see, as you did, that its listening on the wildcard “udp6” port.
sudo netstat -ulpn
udp6 0 0 :::10000 :::* 30327/lxd
But lets try connecting to it using nc from another host on the network over IPv4. My PC’s local LAN IP is 192.168.1.109.
First, I run tcpdump inside the container so I can see if packets arrive from the proxy:
lxc exec c1 -- tcpdump -l -i any udp port 10000 -nn -A -s0
Now from another PC on the LAN 192.168.1.2 I launch an nc test:
echo "hello" | nc -u 192.168.1.109 10000
On the tcpdump window I see:
08:27:56.890335 IP 127.0.0.1.57105 > 127.0.0.1.10000: UDP, length 6
E.."W1@.@.............'....!hello
So I can see the proxy is working over IPv4, despite the apparent “udp6” listener (I think this is just the way the kernel reports a wildcard multiprotocol listening port).
Furthermore I can see that the wildcard connect address has been translated into 127.0.0.1.
So in this test at least, the proxy is working as expected.
Now onto Jitsi. I am not familiar with the networking requirements of Jitsi Meet, however something to be aware of when using the proxy device (that you can see from our test above) is that the source address of the proxied packets is changed to 127.0.0.1 (this is because the packets are literally copied and re-transmitted as new packets, they are proxied rather than forwarded).
This might be cause Jitsi Meet some issues as it may not be able to send packets back to the right source address.
You could try instead using the proxy device in NAT mode, which maintains the source address, e.g. as follows:
Proxy NAT mode requires the container has a static IP address and you cannot listen on the wildcard address on the host.
lxc ls
+--------+---------+--------------------+-----------------------------------------------+-----------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+--------+---------+--------------------+-----------------------------------------------+-----------------+-----------+
| c1 | RUNNING | 10.238.31.5 (eth0) | fd42:be3f:a937:9505:216:3eff:fed9:5698 (eth0) | CONTAINER | 0 |
+--------+---------+--------------------+-----------------------------------------------+-----------------+-----------+
lxc stop c1
lxc config device override c1 eth0 ipv4.address=10.238.31.5
lxc config device set c1 p1 nat=true listen=udp:192.168.1.109:10000 connect=udp:10.238.31.5:10000
lxc start c1
Now we repeat our earlier test and see from tcpdump
08:38:42.188826 IP 192.168.1.2.42831 > 10.238.31.5.10000: UDP, length 6
E..".m@.?.......
....O'.....hello
We can now see the the source address is our remote host’s IP. This may make Jitsi Meet happier.