Nextcloud / coturn find local IP of coturn server

ℹ️ 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.0.7
Talk Server version (eg, 14.0.2): 15.0.6
Custom Signaling server configured: no
Custom TURN server configured: yes/no
Custom STUN server configured: http://stun.nextcloud.com:443

In case the web version of Nextcloud Talk is involved:
Operating system (eg, Windows/Ubuntu/…): Windows 10
Browser name and version (eg, Chrome v101): Edge Version 113.0.1774.50 (Official build) (64-bit)

In case mobile Nextcloud Talk apps are involved:
Talk iOS version (eg, 14.0.2): not tested
Talk Android version (eg, 14.0.2): 16.0.1

The issue you are facing:

So I have Nextcloud, Nextcloud Talk & coturn all running on the same Windows 10 Hyper-V VM (running Ubuntu 20.04.6 LTS) in my home network. My home network is simple - one single subnet (192.168.1.0/24) with the Nextcloud/coturn server coexisting with the Nextcloud Talk clients. This config is working to the point where I can see coturn being used successfully to facilitate Internet/Intranet communication. That is to say a client on the internet used Nextcloud/coturn to call a client on my lan. The problem is the device on my Intranet is somehow finding the internal network IP address of my coturn server and communicating directly with it (when establishing a call with an outside caller). I don’t know how this is happening, but it prevents me from properly securing my coturn server using denied-peer-ip for my local lan addresses. Within the Nextcloud Talk admin settings I have configured it to use the externally valid DNS name for my Nextcloud & coturn install. This seems to happen with both the Android and Web (via Edge) versions of Nextcloud Talk.

Is this the first time you’ve seen this error? (Y/N): yes

Steps to replicate it:

  1. Install Nextcloud on Ubuntu on single subnet home network. Install coturn on same server (although I doubt it matters).
  2. Initiate a call with one person on the Internet and one person on the same LAN as the Nextcloud/coturn server.

The output of your Nextcloud log in Admin > Logging or errors in nextcloud.log in /var/www/:

There are no errors - the call is successful using the local lan IP address of the coturn server that the lan client shouldn't know or use.

The output of your Apache/nginx/system log in /var/log/____:

PASTE HERE

Your browser log if relevant (javascript console log, network log, etc.):

PASTE HERE
2

And this is not the expected behavior?

3

Well, that is partially my question because I don’t know but based on everything I’ve read - including Nextcloud’s own documentation - I’d say the answer is no. I don’t believe that local LAN clients should discover the turn server IP - or maybe it would be nice to turn such ability off (and I’m hoping one already exists). Instead, it would seem more appropriate that, if the local client has to use a turn server to communicate with the Internet client, that it do so via the external IP address of my coturn server - not the internal IP. Doing so would make it so, at most, I would just have to allowed-peer-ip my router’s local lan IP versus my entire subnet. With this configuration I can’t follow Nextcloud’s own best practice of denied-peer-ip banning and quite frankly - not being able to do that makes me not want to use coturn at all (because it seems particularly susceptible & vulnerable to attacks) which basically means I can’t use Nextcloud Talk. :frowning:

So, within all of that I have these questions.

  • Do local clients talking to Internet clients need to use the coturn server?
    ** My suspicion is yes.
  • Is it RFC appropriate to be discovering the local lan IP of the coturn server?
    ** This I wonder about but I’m guessing probably and I’m guessing it’s a coturn thing not a Nextcloud thing?
  • Can discovering the local IP be turned off?

And then bigger picture - let’s say this is by design … how do I do this without self-discovering the local lan IP of the coturn server? Is there another way? Maybe if I put the coturn server on its own isolated vlan making it non-routable (and non-broadcastable) to other local lan clients?

4

Is it not the same IP as Nextcloud? I don’t think there is any discovery taking place.

Ah, but this is actually not sound from a networking perspective. You should rely on NAT reflection and hairpin routing only as an absolute last resort. Many devices do not function as expected that way.

I don’t know all the inner workings of coturn, but my understanding was that both clients need to connect through the TURN server when at least one of them is behind NAT.

5

So I decided to run a Wireshark on the lan based Nextcloud Talk client which in this case is a Win11 Edge based Talk client … I probably should have done this first … What I saw was revealing … The network traffic actually does flow from the client to my external IP to the coturn server - there is no direct connection from my lan client to the coturn server as I originally suspected. Instead, it seems that communication is relaying my lan client’s internal IP to the coturn server and I can see coturn packets that say it’s a forbidden IP address. So this is more of a coturn thing I guess. That makes me less confident that I can work around it - still so surprising I’m the only one to encounter this - I’m still convinced I’m doing something wrong.

6

So, I’m looking at this trace more and … I see my local lan client sending four different CreatePermission Request XOR : PEER-ADDRESS packets one with the external IP address of my internet client I’m trying to communicate with - then three others … One of them is for 10.8.0.7 which I simply can’t explain … One for the coturn server’s IP address which the coturn server had relayed to the client in a prior packet and then 127.0.0.1. My client gets three forbidden IP responses but apparently one of the CreatePermission requests was successful as it lacks a forbidden IP response - and then there are dozens of packets sent after that … They are Send Indication XOR-PEER-ADDRESS: packets - they’re repeated over and over. So I dunno - maybe Nextcloud Talk is establishing the connection sub optimally? I dunno.

Quite frankly all of this network traffic is a bit too revealing … which leads me to my other problem about Nextcloud Talk that I plan to post about too - not properly recognizing the Let’s Encrypt CA that signs my certs. Still - Nextcloud says you don’t need to TLS encrypt because WebRTC is encrypted - apparently not enough for my liking.

7

there is nothing wrong when internal clients talk to the internal IP of the TURN server. a TURN server is designed t be a relay instance between clients without direct network visibility and it will try all possible network paths choosing the “shortest” one. This is definitely a good thing as real-time communication must use the shortest path for best quality.

You secure your TURN server using a secret and this is in general “good enough” ;).

8

OK - I came to an acceptable solution for myself (so far anyway) … In looking at the logs I thought it was off that the coturn server was denying itself …

27: A peer IP 192.168.1.170 denied in the range: 192.168.0.0-192.168.255.255

So I allow listed just it and it now solves the problem. You can see my denied-peer-ip and allowed-peer-ip lists below. The deny list introduced the problem and the allow list (which overrides the deny list) fixed it.

Incidentally and to reiterate … I had it all wrong at the beginning of my post and the subject. My local lan client is not talking directly to the coturn server using lan-ip-to-lan-ip communication. They are talking to each other through my router as I want them to. I was fooled into thinking they were when allow-listing the lan client’s IP address resulted in a successful connection (and never bothered to do a network capture). After I ran some captures and looked at some logs I managed to see what was going on and develop two solutions. The first was to allow-list the client IP which was unacceptable from a security perspective. The second is to allow list the coturn server’s local lan IP which is acceptable (as it’s just one IP versus all).

I can now make lan-to-lan calls just fine (always could) and internet-to-lan calls just fine … I’ve yet to try internet-to-internet calls yet but I sorta expect that will work.

no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=240.0.0.0-255.255.255.255
denied-peer-ip=::1
denied-peer-ip=64:ff9b::-64:ff9b::ffff:ffff
denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255
denied-peer-ip=100::-100::ffff:ffff:ffff:ffff
denied-peer-ip=2001::-2001:1ff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=2002::-2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fc00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fe80::-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

My only allowed-peer-ip is the local lan address of the all-in-one Netcloud/Talk/coturn server.

allowed-peer-ip=192.168.1.170