Additional eturnal whitelist option

[daniele-barresi]

Hi there,
I'm using NextcloudAIO and it really makes it easy to install and maintain, so big thanks for the huge efforts!

I'm currently using Nextcloud on premise, behind a NAT. I know it's not fully recommended for Talk STUN/TURN setup, but I believe it works with the right config on NAT, firewall and DNS. In my opinion it's an ok setup when most of the time the call participants are actually on premise, and occasionally some participants connect from the Internet.

The problem I'm currently facing is with TURN server for call participants that are "inside" of the network, meaning they are connecting behind the same firewall as the Nextcloud server (although on different subnets). I have found it works properly when I add the LAN network CIDR in the "whitelist" section of eturnal configuration file, to override the corresponding blacklist: -recommended setting, which implicitly includes all local networks.
I did so by adding a line in the whitelist section of /conf/eturnal.ym file on the running nextcloud-aio-talk container and reloading with 'eturnalctl reload`. This then allows local clients to establish a connection with the TURN server.
This configuration, off course, wont survive a restart of the docker container.

In my scenario, it would be very useful to have an additional line in the /containers/talk/start.sh script to include an environment variable to define an additional whitelist value. Another option could be to mount the start.sh script from a configuration file, so that it could be expanded if necessary.

I'm also open to know if I'm missing any alternative solution to add a whitelist option to eturnal in the nextcloud-aio-talk container.

Cheers

[szaimen]

Hi, I am wondering since when is this necessary? Since we switchted to eturnal?

How long are you using AIO already?

---

I'm using NextcloudAIO and it really makes it easy to install and maintain, so big thanks for the huge efforts!

Thanks, this is great to hear!

[daniele-barresi]

I started using AIO recently, I migrated from snap package.
I never used the TURN server before, as Talk was not being used at all in the organization.
We are currently testing Talk as a more private alternative to other popular video conferencing services. It also integrates nicely with the calendar app, which we have been using for a while now.

With the current configuration of the nextcloud-aio-talk container, start.sh includes the recommended option in blacklist for eturnal, which implicitly blocks every private network address space. This is why eturnal will refuse to respond to participants in the local network, as they are behind the same firewall/router as the Nextcloud server, so they connect tu eturnal with local IPs (no NAT involved). I'm not sure when TURN server was switched to eturnal, but I guess the same applied to coTurn as well.

I understand the default is to block local network addresses, as there are security concerns about it (https://www.rtcsec.com/article/cve-2020-26262-bypass-of-coturns-access-control-protection/#further-concerns-what-else). Still, it would be good to have the option to configure a network as whitelisted for specific use cases.

[daniele-barresi]

Hi, I am wondering since when is this necessary? Since we switchted to eturnal?

I was checking the Dockerfile for Talk container in Nextcloud AIO repository. In 7.0.0 it uses strukturag/nextcloud-spreed-signaling:1.1.3, which I believe uses coTurn. Since 7.1.0 the Dockerfile also includes eturnal/eturnal:1.11.1.

I believe the adoption of eTurnal and the default blacklist for all private network addresses is very likely the cause of the issues of Talk calls with Nextcloud behind the same firewall as the call participants, as others are reporting in #3350

I also added more information on my current setup (with Talk calls working) here:
#3350 (comment)

[szaimen]

Hi @sando38, glad to see you here! 👋

We may provide a quick fix for the separation of client/ peer which was on our list anyway.

This would be amazing so that we dont need to add a workaround on our side :)

[daniele-barresi]

In TURN we have to distinguish between clients and peers. Clients are basically those that request a TURN relay which then may be consumed by a peer. The peer is the addressee of a communication which should be protected. The client side authenticates itself usually by the authentication mechanisms, like with ephemeral credentials. So this could be a sufficient protection already.

Thank's for this clarification. It makes a lot more sense to me now.

The issues observed seem to be with clients connecting to eturnal from internal/ local network addresses which will be blocked by eturnal's blacklist. The workaround would be like described in this discussion.

I can confirm that the workaround works indeed. In my case, I added a cronjob on Nextcloud server that will periodically check if the local network is whitelisted in eturnal's configuration. In case it's not, the script adds the whitelist and reloads eturnal. It's an attempt to make this configuration as "persistent" as possibile, by making the change in the running Docker container, but without tampering with the image itself, so the config will survive a reboot or an upgrade.

We may provide a quick fix for the separation of client/ peer which was on our list anyway.

This is great news! Thank you for the effort!
It will be the best solution, no workarounds needed.
🙏 👏

[szaimen]

PR is here: #3426

[tuetenk0pp]

I see the PR has been merged. I am in the middle of setting up a new instance and I think I ran into this issue as well. How long until the next release? Just so that I know how long before I can migrate our users to the new instance.

[szaimen]

I let you know as soon as a new beta release is available that includes the fix

[szaimen]

This is now fixed with v7.4.0 Beta. Testing and feedback is welcome! See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel

[sol8712]

Very nice! I'm switching now and will report any issues. Thank you for all your work!

[ralfrupf1976]

I just updated to v7.4.1 - and YES - the connection test doesn't fail anymore!! Thank you

[daniele-barresi]

I just updated to NC AIO 7.5.1, left default black/whitelisting in /conf/eturnal.yml and everything works smoothly!

Thank you again!

[ollioddi]

Hi @szaimen.

I am running v7.12.1 and is still facing this issue.

/conf # cat eturnal.yml
eturnal:
  listen:
    - ip: "::"
      port: 3478
      transport: udp
    - ip: "::"
      port: 3478
      transport: tcp
  log_dir: stdout
  log_level: warning
  secret: "verysecret"
  relay_ipv4_addr: "172.20.0.2"
  blacklist_peers:
  - recommended
  whitelist_peers:
  - 127.0.0.1
  - ::1
  - "172.20.0.2"

I simply cannot use it locally, on 192.168.0.0/24. It seems everything is read-only or reset upon restart. Do you have any suggestions? Otherwise i might need a new discussion?

Thanks in advance.

[sol8712]

When i get home from work in about 5 hours i will test this on my local install and report back.

…

-------- Original Message --------

On Feb 16, 2024, 9:33 AM, Oliver Roed Schøler wrote: Hi ***@***.***(https://github.com/szaimen). I am running v7.12.1 and is still facing this issue. /conf # cat eturnal.yml eturnal: listen: - ip: "::" port: 3478 transport: udp - ip: "::" port: 3478 transport: tcp log_dir: stdout log_level: warning secret: "verysecret" relay_ipv4_addr: "172.20.0.2" blacklist_peers: - recommended whitelist_peers: - 127.0.0.1 - ::1 - "172.20.0.2" I simply cannot use it locally, on 192.168.0.0/24. It seems everything is read-only or reset upon restart. Do you have any suggestions? Otherwise i might need a new discussion? Thanks in advance. — Reply to this email directly, [view it on GitHub](#3395 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ADDTIG3MQ3GTXWM6GFLDTZTYT6J57AVCNFSM6AAAAAA5B2PWPKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DIOJVGM3DO). You are receiving this because you commented.Message ID: ***@***.***>