talk turnserver connection test fails #3350
Answered
by
szaimen
ralfrupf1976
asked this question in
Questions
-
|
Steps to reproduce
Expected behavior Actual behavior Host OS Nextcloud AIO version Current channel Other valuable info |
Beta Was this translation helpful? Give feedback.
Answered by
szaimen
Sep 26, 2023
Replies: 23 comments 18 replies
-
|
Hi is port 3478/tcp and 3478/udp correctly opened and forwarded? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I have the same problem as the original post. Identical description. Ports are open on the router. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Can you check if the connection works from a different network with a different browser? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Also are you behind Cloudflare, use a VPN on the client or server, or have a local DNS server running? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I usually use Vivaldi Browser. From the Chrome browser I could sort of connect for a video call. It would connect to the server, but never establish the video/audio connection. Instead it would try for maybe 10 seconds, then retry, repeatedly. But when I checked the connection in settings I got the red exclamation point (same as Vivaldi). This server is not behind any sort of VPN or Tunnel nor local DNS. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Can you post the talk container logs here? |
Beta Was this translation helpful? Give feedback.
0 replies
-
click here |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Putting it all in a code window didn't work :( Sorry about that. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I did: Checked with Google Chrome and Firefox. One Cloud @home, one Cloud @church, different network - same issue... |
Beta Was this translation helpful? Give feedback.
0 replies
-
Yes, it is - nothing changed on firewall, it was working till Version 7.0 or 7.1 - sorry, don't know exactly |
Beta Was this translation helpful? Give feedback.
0 replies
-
This seems to be the culprit |
Beta Was this translation helpful? Give feedback.
0 replies
-
click here |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
So I've done a bit of reasesrch on this and seems like NAT is involved on the solution. @ralfrupf1976 and @Bruceumba can you please enable ipv6 in your docker installation correctly by following https://github.com/nextcloud/all-in-one/blob/main/docker-ipv6-support.md? This might resolve it. |
Beta Was this translation helpful? Give feedback.
5 replies
-
|
EnableIPv6 was false. I followed these instructions, did not find the /etc/docker/docker.json file so I created it. Restarted docker and EnableIPv6 was still false. Wondering if there might be a different location for the docker.json file and that /etc/docker/docker.json I made wasn't read? |
Beta Was this translation helpful? Give feedback.
-
|
You named it wrongly. Please read the instructions again. |
Beta Was this translation helpful? Give feedback.
-
|
Alas. I got EnableIPv6 to be "true" but the behavior hasn't changed. I'll look into it more. I did notice that the ipv6 network address was "fd12:3456:789a:2::a/64" as specified in #2045, while the link above has it as "fd12:3456:789a:1::/64". Might that be a problem? I'm not familiar with ipv6 address protocols. |
Beta Was this translation helpful? Give feedback.
-
|
I never got mine working. I have ipv6 running fine (it was an ISP problem) but I can't connect video calls. In the end I deleted the talk containers, and will retry later. Very few of the users needed it. |
Beta Was this translation helpful? Give feedback.
-
|
Mine was working, no ipv6 configured... turnserver test was ok, connections with larger from different places, even smartphones in the calls did work. Since an update - bye bye signaling server, not running anymore. ice test fails, connections from outside the lan are not longer possible |
Beta Was this translation helpful? Give feedback.
-
OK, I'll check that next week - need some time - currently working on different projekts. Feedback on Tuesday... |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Moving to discussions while waiting as I cannot reproduce the problem on my test instance |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
A few more thougths Have you seen: My network Supporter is not so happy of enabeling something that is introduced with the above words... Why is this necessary now if it was working before without? |
Beta Was this translation helpful? Give feedback.
-
|
Any news? A solution in sight. I know - i gave no feedback to the ipv6 story - it's hard to test for me in the described setting. |
Beta Was this translation helpful? Give feedback.
-
|
I think a different solution would be to remove the AAAA record from your domain and also disable ipv6 in your router |
Beta Was this translation helpful? Give feedback.
-
|
Ive been having the same issue recently, at one point it was working then one day it was not, i cannot recall the exact update when it stopped working(as ive switched from betas to non betas a few times recently). Apache reverse proxy |
Beta Was this translation helpful? Give feedback.
-
|
There is no AAAA record on my domains - clouds @ home and @ business. Modem is in Bridge Mode, Firewall IPV6 disabled. |
Beta Was this translation helpful? Give feedback.
-
|
I am anxiously waiting for a solution and I am surprised that there haven't been any more updates. Video meetings are no longer possible - a big problem in our company. Are there others there who are stressed by this or urgently need a solution? |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Maybe you run into this? |
Beta Was this translation helpful? Give feedback.
-
|
As described i added unter whitelist in the talk container the ip adress and reloaded with "eturnalctl reload" - no change still the same issue. XXX = blacked IPs addresses and secrets. eturnal:
|
Beta Was this translation helpful? Give feedback.
-
That is my issue, after reading new comments there i tried 2 devices both off of the network of the AIO and video calls worked. Can anyone else suffering from the issue comfirm this behaviour? |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
I wonder is this only happening sincs the switch to eturnal? Since when are you using AIO? |
Beta Was this translation helpful? Give feedback.
-
|
I restored a backup of nextcloud aio from 31.08.2023 - running Nextcloud AIO v7.0.0. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
I was checking the Dockerfile for Talk container in Nextcloud AIO repository. In 7.0.0 it uses 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 if you have Nextcloud behind the same firewall as the call participants. Checkout #3395 |
Beta Was this translation helpful? Give feedback.
-
|
In #3395 I proposed to add an option for eturnal whitelisting, as that solves one part of the problem. My current setup is as follows:
So the important detail I wanted to share on this thread is that I needed to specify an internal DNS record for talk.my-company.com, to override the public DNS record, that will resolve with internal Nextcloud IP address for participants inside the company network. By default Nextcloud AIO will configure the same domain for STUN/TURN server as the main Nextcloud domain (cloud.my-company.com), so I changed it to a specific talk domain (talk.my-company.com). The moment I did this, the TURN connection check in Nextcloud administration page started to work (green check mark). With internal NAT, even if some firewalls/gateways will support "NAT reflection", didn't work for TURN traffic for internal participants. With the internal DNS record, I pointed internal clients directly to Nextcloud server, so they don't need any NAT at all. Than added the whitelist in eturnal and video calls work perfectly. |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
My Setup:
I can make calls within the network - checked with two phones - no problem As described i added under whitelist in the talk container the ip adress and reloaded with "eturnalctl reload" - no change still the same issue. XXX = blacked IPs addresses and secrets. eturnal:
|
Beta Was this translation helpful? Give feedback.
-
|
If I understand correctly, you have all traffic going through the NPM, even TURN traffic. That means that you need to whitelist che proxy IP in the eturnal.yml file. |
Beta Was this translation helpful? Give feedback.
-
|
I personally chose to avoid proxying TCP/UDP traffic on port 3478 with Nginx, wasn't sure it would work correctly for TURN. I preferred to expose TURN server directly for internal participants, that's why I have to whitelist the LAN range on eturnal. |
Beta Was this translation helpful? Give feedback.
-
YES - it works again! Thank you, I had to add IP Adress of the NPM to the whitelist. The NPM is in VLAN99, exposed to WAN, VLAN10 is intern network... So adding 192.168.99.xxx to the whitelist solved the problem. Calls are possible again! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi, seems like the underlying issue was found: #3395 (reply in thread) |
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
szaimen
-
|
I had the same error after the switch from coturn to eturnal. But it was not related to IPs only as it did persist with the latest 7.4.1 Finally it was the secret that I had chosen. It contained an "_" within the phrase. After changing to alphanumerical only, it is working again. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, seems like the underlying issue was found: #3395 (reply in thread)