I have a nextcloud server which I’ve made to be accessible only to members of my openvpn network. So, the nextcloud server is a client on an openvpn network, with for example a vpn address of 10.8.0.6, and all clients would have a 10.8.0.x address and only that set of addresses can access it.
This worked, with group video chats through the Talk app, throughout 2019. But then this spring something changed and some clients can no longer get the video or audio streams, though they can text. I liked that group video chats were possible without me having to do anything complicated or looking under the hood. But now, I’ve had to go on an adventure to figure out just what went wrong this year, and it means having to go under the hood a bit
I think that the problem would be solved if Nextcloud and/or Talk can be configured to only use one particular network, like say the tun0 interface with the 10.8.0.x set of addresses.
The documentation mentions that Talk is supposed to find the easiest way for clients to communicate with each other, and will avoid using STUN/TURN if it can. I assumed that since the group video was working for us, that the system saw that every client was part of the same vpn and defaulted to just that vpn. But now that things have gone wrong and I have to look into it, I can see that this is not the case.
After troubleshooting, I noticed in firefox’s “about:webrtc” section, with the ICE data, that the vpn address wasn’t even attempted. It was only trying 2 addresses: 1) the LAN address and 2) an interface address for a subscription proxy which can’t even connect to the outside world anyway.
I’ve configured the turn server, coturn, to only listen on the vpn address, but this doesn’t help. I assumed the Talk system would only try the network that the turn server listens on, if it only listens on one. Nope.
Instead, it tries the LAN interface/address of the client first, then moves on to another interface, then goes back to that LAN interface, without even trying more. I don’t get it. Why does it not even attempt a 3rd or 4th interface? Is this a bug? But the thing is, there are some clients that don’t have a problem. They just connect through my vpn and they can use video chat just fine.
The problem could come from the fact that a computer that doesn’t work is behind a 2nd router, which is a client on the network that the nextcloud server and turn server are running on. Though that shouldn’t be a problem because a turn server is supposed to figure that stuff out, plus, it should just stick to the vpn network (10.8.0.x) so any extra router-networks shouldn’t be considered.
So, is it possible to explicitly tell Talk/Spreed/ICE/TURN/Nextcloud or whatever to not bother with any other interfaces, just one explicitly stated one?
Also, I’m wondering if someone look into clients with multiple interfaces, say multiple openvpn interfaces, and behind a 2nd router, and see if that causes issues with Talk connectivity, particularly ICE not attempting some of the interfaces?