Talk HPB with NPM reverse proxy

ℹ️ Support 💬 Talk (spreed)
, ,
1
Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Some useful links to gather information about your Nextcloud Talk installation:
Information about Signaling server: /index.php/index.php/settings/admin/talk#signaling_server
Information about TURN server: /index.php/settings/admin/talk#turn_server
Information about STUN server: /index.php/settings/admin/talk#stun_server

Nextcloud version (eg, 24.0.1): 25
Talk Server version (eg, 14.0.2): 2.0.4
Custom Signaling server configured: no
Custom TURN server configured: no
Custom STUN server configured: no

I’m using the ghcr .io/nextcloud-releases/aio-talk:latest docker image.

The issue you are facing: I need some help configuring the HPB behind Nginx proxy manager. I’m kind of a beginner so probably I’m missing the logic here.

My Talk docker config

Summary

services:
nc-talk:
container_name: nc-talk
image: ghcr. io/nextcloud-releases/aio-talk:latest
init: true
ports:

  • 3478:3478/tcp
  • 3478:3478/udp
  • 8181:8081/tcp
    environment:
  • NC_DOMAIN=nextcloud.example.com
  • TALK_HOST=signal.example.com
  • TURN_SECRET=longkey #this must be a long secretpasswordkey
  • SIGNALING_SECRET=longkey #this must be a long secretpasswordkey
  • TZ=Europe/Berlin
  • TALK_PORT=3478
  • INTERNAL_SECRET=longkey #this must be a long secretpasswordkey
    restart: unless-stopped
    networks:
    default:
    external: true
    name: cloud
  1. Nextcloud is reachable from external network.
  2. Signal server is reachable from external network
  3. Talk (calls, chat, video) works with the internal network if I use the localhost:3478 in the Talk settings.
  4. nextcloud.example.com:3478 is not reachable from the external network and calls and video does not work if I put this in Talk settings.
  5. Port 3478 is open in my router and pointed to my NAS running my Nextcloud and Talk dockers, however I cant really point it directly to the Talk docker container.

I kind of understand why it doesnt work, on one hand NPM only handles TCP but not UDP and on the other, there is nothing set up to send the incoming traffic to the Turn server on port 3478.
I tried to search for a solution but I cant seem to find anything which is weird because I believe my setup is pretty common for home labs.

I think the obvious solution is to just install an external Turn server like coturn which I can reverse proxy with NPM, but maybe there is a different solution here I’m missing.

2

Hey @nemlehet4 welcome back :waving_hand:

see High Performance Backend for Talk on Nextcloud with Docker

its not necessary to forward that port via NPM, allow inbound bypass for TURN & STUN on port 3478 tcp/udp which must be internet facing in router/firewall (i.e your.domain.tld:3478), encryption is optional for TURN & STUN as it will be handled by encrypted Nextcloud

3

Thanks. I had to look what exactly inbound bypass is :smiley:

Looks like my router from the internet provider makes this impossible. Its not possible to set up bypass the option simply doesnt exist.
I set up DMZ as a test, but checking nextcloud.mydomain.com with nmap it still shows this port filtered so it doesnt seem to be removing all rules for the wan side.

I will try to use coturn as a separate docker image and set it up in NPM.

4

there is no way “localhost” STUN/TURN server works.. calling works just because clients can connect to each other and don’t need a STUN/TURN server.

please review how both work

what you need is direct access like port forwarding - reverse proxy doesn’t work for this connections.

1 Like
5

FYI: For Turn/tcp, an l4-proxy works but Stun which works via UPN must be accessed directly.

Also see caddy-l4 · Issue #93 · szaimen/aio-caddy · GitHub for more details

1 Like
6

I agree sometimes and somehow part it might work over reverse proxy like straight TCP proxy in traefik but to keep it simple I would say in consumer setup with frequent lack of knowledge and understanding simple statement is better.

1 Like
7

This was useful resource and you were correct.

I did some additional searching (hail insomnia :D) and found a github comment talking about cloudflare proxy interfering.
I turned off proxying in cloudflare for my nextcloud cname entry, restarted everything and it works now.
Tested successfully with my friend using external networks (which was not working before). So my internal network setup is OK, thats good to know.

I’m not enthusiastic about exposing my IP so I’m looking into how to setup rules within cloudflare to allow this traffic through. It should be possible, although I have no clue yet how to do it :smiley:

8

please explain.. I’m really curious what is the reason to really hard try to hide your already public IP..

9

I consider this as an additional layer of security. I dont have a high degree of confidence in the security of the home router I got from my provider, in my mind if malicious actors have just a slightly harder time probing/attacking my network, the better.
I’m not a security expert so its possible it absolutely doesnt matter or I overestimate the Cloudflare proxy/DDos protection.

When I was a teen and played COD2 online there were petty players who DDos attacked you if you played too well. It was super easy because you could get the public IP from the console really easily.

10

I expected to get such answer.. let me try to sort out some points.

Each public IPv4 in the internet is scanned many times per day. some of this scans are from good guys some are from bad ones.. today it is not only theoretically possible but also affordable to scan the whole IPv4 address range within hours and there is little difference if you “expose” the IP with a DNS name.

Cloudflare has some cool offerings e.g. SoHo admin will never compete with them absorbing DDoS attacks.. but at the same time I would be really surprised if a DoS attack hits such SoHo customer.. and if yes.. you just wait until it is over.. no real harm. I think in most cases Cloudflare adds complexity and issues without real security improvement.. IMO the only good use of Cloudflare for self-hosting is when you don’t get a public IP (DSL-Lite, CG-NAT) and use them to tunnel the traffic..

And in turn just because you setup your public IP/DNS in your Nextcloud as STUN/TURN it doesn’t become “exposed” - only people who are allowed to participate in a call get access to this information (if you allow anonymous users it is in fact not protected) but I think there are more implications if too many “unauthorized” people get access to your Talk.

2 Likes
11

Good insight, thank you. I’m still pretty new to hosting services and IT security and there is an overwhelming amount of information online. Also my impression is there no universal best practice there is a lot of differing opinion what is sufficient or what is necessary :smiley:

Anyway just to summarize the final setup/solution for posteriority sake:

  1. Port 3478 is forwarded on my router to my homeserver running both Nextcloud and Talk (DMZ is also an option if your hosting a lot of stuff, but obviously read about the risks)
  2. in NPM nothing new is needed if your Nextcloud is reachable from external networks you are good.
  3. On cloudflare you have turn off proxying under DNS →Records for your nextcloud cname entry otherwise its not gonna work.