Audio/Video Call Issues with STUN/TURN behind Reverse Proxy (nextcloud-aio-talk)

[Does-This-Work]

Hi,

I'm currently testing Nextcloud AIO, and the setup has been smooth so far. Since I have a reverse proxy in my network, I opted to use the SSL certificate from there instead of creating a new one on the Nextcloud instance. This worked well.

However, I'm experiencing issues with Nextcloud Talk. While the app works fine for texting, I can't get audio and video calls to work. I suspect the problem is related to DNS resolution. When I use cloud.example.com, it resolves to my HAProxy instead of directly to Nextcloud AIO, where the STUN and TURN container is located.

I tried setting up talk.example.com to go directly to Nextcloud AIO, but that didn't work either.

Here's the output from https://webrtc.github.io/. I got some private IPs and ports as results:

Note: Errors from onicecandidateerror above are not necessarily fatal. For example, an IPv6 DNS lookup may fail, but relay candidates can still be gathered via IPv4.
The server stun:talk.example.com:3478 returned an error with code=701: STUN host lookup received an error.

Would it be best to create a separate STUN/TALK container and manually configure it? If not, any suggestions on how to fix this issue?

[szaimen]

You can manually overwrite the stun and turn server in the talk admin settings. E.g. adding a second subdomain and pointing that via cname at the public ip without overwriting it locally should probably make it work.

[Fuseteam]

the main issue as far as i can tell is that the reverse proxy needs to forward udp traffic; nginx is capable of from a certain version but i am unsure how the configuration would look like

[iamtherobin]

I been trying to figure this out for a day now. Finally, got it to clear when I used my reverse proxy to send 3478/tcp back to the container.

In my setup I have nextcloud.domain.com for nextcloud and talk.domain.com for the talk STUN and TURN server.

• nextcloud.domain.com has public A and AAAA records pointing to my firewall where HAProxy lives and has no split DNS since that will bypass the certs
• talk.domain.com has public A record to my WAN IPv4 and AAAA record directly to my host machine's listening IPv6
• talk.domain.com is set in the admin panel for Talk
• I have port forwarded 3478 TCP/UDP on IPv4 to my host machine's internal IP and allowed traffic for the IPv6 listening address of the host machine
• I have setup split DNS on the firewall for talk.domain.com to point to the host machine directly so devices inside the network will connect on IPv4 internally since port forwarding will not work from inside

With this setup, Talk is working successfully. I have confirmed devices are using the internally set split DNS records to access the host machine directly and use the public records when outside to reach the firewall on port 3478. Despite the working result, the container still shows unhealthy.

It seems the container only accepts a response from nextcloud.domain.com:3478/tcp for the health check to pass. I can only get it to show healthy if I add port 3478 as TCP proxy in HAproxy send it back to the host machine. This tells me the container is only checking nextcloud.domain.com:3478/tcp for the health check and not the configured STUN/TURN address or for UDP connectivity.

This behavior should be corrected so health check works against the address entered in the admin panel for the STUN/TURN server as well as checking for UDP connectivity.

[szaimen]

There is now a fix available with v9.0.0 Beta. Testing and feedback is welcome! See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel

[iamtherobin]

There is now a fix available with v9.0.0 Beta. Testing and feedback is welcome! See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel

Just switched to beta and disabled my TCP 3478 proxy. I can confirm it now shows healthy without the need for TCP 3478 in the reverse proxy.

I assume the change was to perform the health check using the address in the talk admin panel? Does it also check UDP or just TCP?

[ZoltrixGFC]

I been trying to figure this out for a day now. Finally, got it to clear when I used my reverse proxy to send 3478/tcp back to the container.

In my setup I have nextcloud.domain.com for nextcloud and talk.domain.com for the talk STUN and TURN server.

* nextcloud.domain.com has public A and AAAA records pointing to my firewall where HAProxy lives and has no split DNS since that will bypass the certs

* talk.domain.com has public A record to my WAN IPv4 and AAAA record directly to my host machine's listening IPv6

* talk.domain.com is set in the admin panel for Talk

* I have port forwarded 3478 TCP/UDP on IPv4 to my host machine's internal IP and allowed traffic for the IPv6 listening address of the host machine

* I have setup split DNS on the firewall for talk.domain.com to point to the host machine directly so devices inside the network will connect on IPv4 internally since port forwarding will not work from inside

With this setup, Talk is working successfully. I have confirmed devices are using the internally set split DNS records to access the host machine directly and use the public records when outside to reach the firewall on port 3478. Despite the working result, the container still shows unhealthy.

It seems the container only accepts a response from nextcloud.domain.com:3478/tcp for the health check to pass. I can only get it to show healthy if I add port 3478 as TCP proxy in HAproxy send it back to the host machine. This tells me the container is only checking nextcloud.domain.com:3478/tcp for the health check and not the configured STUN/TURN address or for UDP connectivity.

This behavior should be corrected so health check works against the address entered in the admin panel for the STUN/TURN server as well as checking for UDP connectivity.

Thank you for outlining this. Was very helpful. The Nextcloud AIO doco just says to open port 3478 on your firewall, which is only part of the story.

[j-norwood-young]

This might help someone who just wants to forward the ports using HAProxy:

# STUN server config (NextCloud Talk)

frontend stun_tcp_fwd
    bind *:3478
    mode tcp
    default_backend stun_tcp_backend

backend stun_tcp_backend
    mode tcp
    server srv1 <nextcloud ip>:3478 check