Root cause of Rejecting permission creation request: Forbidden

[cbrhaze]

Hi there! I switched to Eturnal from Coturn and it's logging looks much more useful. However, when using both TURNS (udp,tcp) + TURN (udp,tcp), for some calls made via Matrix I'm getting the errors below. Users are LTE/various Wi-Fi mobile devices. All Eturnal tls/udp/tcp ports are defaults. I'm using ZeroSSL certs. What theoretically may be causing such errors?

They occur only for around 5% of calls and I spent weeks on trying to make it work properly. All errors below are about the same Matrix user and the same session (unsuccessfull)

Rejecting permission creation request: Forbidden [UDP, session bv95wke8p61e
Rejecting permission creation request: Forbidden [UDP, session bv95wke8p61e
Accepting long-term STUN/TURN authentication [TCP, session k15qtohtxcnt
Rejecting permission creation request: Forbidden [TCP, session k15qtohtxcnt
Accepting long-term STUN/TURN authentication [TLS, session 4minwbljwqj8
Rejecting permission creation request: Forbidden [TLS, session 4minwbljwqj8
Accepting long-term STUN/TURN authentication [TLS, session grbshvs74cwb
Rejecting permission creation request: Forbidden [TLS, session grbshvs74cwb

But just after that on the same session with the same user with the same IP it's ok: Accepting long-term STUN/TURN authentication [UDP - no errors Accepting long-term STUN/TURN authentication [UDP - no errors

[weiss]

Just to make sure: Are you actually seeing failing A/V calls or are you 'just' worried about those log entries?

Because if you configured e.g. blacklist: recommended (did you?), those messages are to be expected. A/V stream negotiation between client A and client B typically works something like this: A puts together a list of IP address/port pairs B might try to contact for streaming data to A. This includes:

1. The IP addresses configured on the local device. This will often include a local LAN address such as 192.168.0.42 (as A cannot be sure it won't be reachable just because it's within a private address range: B might be on the same LAN).
2. The device's external IP address returned by the STUN server.
3. The TURN server's relay address/port allocated on A's request for relaying traffic from B.

A then communicates the resulting list to B (in your case, via Matrix message events).

B does the same for the other direction. So, just like A, B asked their TURN server to allocate a relay address/port for relaying traffic from A. Now that B received the list of A's IP addresses, B will ask their TURN server to actually allow those IP addresses to talk to the TURN relay address/port (initially, the TURN server would reject any traffic sent to that port). As mentioned above, the list of As IP addresses may well include private addresses such as 192.168.0.42. However, blacklist: recommended would reject adding those to the list of permitted addresses, which would yield the error message you mentioned. Since the private address wouldn't work for talking to the TURN server anyway, that's not a problem at all (except in the case where the TURN server is on the local LAN, in which case you'd want to whitelist the LAN).

I agree it's a bit ugly to have error messages during normal operation, but at least in the scenario I outlined, everything is working as expected. I'm very much open to ideas on how to handle that case more nicely :smile:

However, if calls actually fail to be established, we're talking about a different case and we'd have to take a closer look.

[weiss]

I'll close this issue for the moment. Feel free to add a comment or open a new issue in case there's still a problem or something is unclear.