Proxy device only creates IPv6 port

Hey folks,

I am trying to install a jitsi instance on my Raspberry Pi in LXD because I do not want to clutter my host os.

Worked well until the point where I need to interface all the nice ports which jitsi needs. 80 and 443 are handled by haproxy which seem to work quite fine. However, I cannot get port 10000 working for ipv4:

root@raspi:~# lxc list
+-------+---------+----------------------+-----------------------------------------------+-----------+-----------+
| NAME  |  STATE  |         IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
+-------+---------+----------------------+-----------------------------------------------+-----------+-----------+
| jitsi | RUNNING | 10.215.46.102 (eth0) | fd42:74fa:df6c:6b84:216:3eff:fe86:ad54 (eth0) | CONTAINER | 0         |
+-------+---------+----------------------+-----------------------------------------------+-----------+-----------+

root@raspi:~# netstat -tulpen | grep 10000
udp6       0      0 :::10000                :::*                                0          61896      5327/lxd            


root@jitsi:~# netstat -tulpen | grep 1000
udp6       0      0 10.215.46.102:10000     :::*                                999        63455      265/java            
udp6       0      0 fd42:74fa:df6c:6b:10000 :::*                                999        63454      265/java            


root@raspi:~# lxc config device show jitsi 
jitsi_10000:
  connect: udp:0.0.0.0:10000
  listen: udp:0.0.0.0:10000
  type: proxy

root@atlantis:~# nmap raspi
Host is up (0.031s latency).
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Cheers,
Sven

Can you try listening to a specific IPv4 address of your host machine and see if that works?

Yeah. Read something about this here:

root@raspi:~# netstat -tulpen | grep 10000
udp        0      0 192.168.188.28:10000    0.0.0.0:*                           0          108942     13985/lxd           

That at least fixed it. Yet, I would not expect this behavior.

Unfortunately, that does not fix the audio/video issue :confused:

Also nmap doesn’t show 10000. :-/

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.

Hi, for me not listening ipv4 explicitly cause problems. I created tcp proxy device for forwarding ssh port:

sudo lxc config device add <container-name> <device-name> proxy listen=tcp:0.0.0.0:10122 connect=tcp:127.0.0.1:22, it only shows listening to :::10122. I can connect to :10122 from Linux and Windows, but NOT from a SunOS system which is our dedicated server for tunneling ssh.

In the mean time, if I create ssh port forwarding on host (which listen to both 0.0.0.0:10122 and :::10122), I can connect to it from the SunOS system.