This configuration is provided AS-IS and as an example/reference for those who do not find a working configuration for themselves. It is not always kept up to date and no support is provided.
Assuming:
- Your Matrix domain:
example.org
- Your TURN domain (arbitrary):
turn.example.org
- Your Public IP:
1.2.3.4
- Your Private IP for the box hosing the services:
10.11.12.13
- A shared secret between synapse and coturn:
ThisIsASharedSecret-ChangeMe
- You want Firefox compatiblity (TURNS only is not supported)
homeserver.yaml
:
## Turn ##
# The public URIs of the TURN server to give to clients
turn_uris:
- "turns:turn.example.org?transport=udp"
- "turns:turn.example.org?transport=tcp"
- "turn:turn.example.org?transport=udp"
- "turn:turn.example.org?transport=tcp"
# The shared secret used to compute passwords for the TURN server
turn_shared_secret: "ThisIsASharedSecret-ChangeMe"
# How long generated TURN credentials last
turn_user_lifetime: "1h"
turnserver.conf
:
syslog
lt-cred-mech
use-auth-secret
static-auth-secret=ThisIsASharedSecret-ChangeMe
realm=example.org
cert=/etc/letsencrypt/live/turn.example.org/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.org/privkey.pem
no-udp
external-ip=1.2.3.4
min-port=64000
max-port=65535
Allow ports:
- TCP 3478
- UDP 3478
- TCP 3479
- UDP 3479
- TCP 5349
- UDP 5349
- UDP 64000 to 65535
Gives me another chance for embedded marketing! I think configuration and logging are way more straightforward with eturnal 😄
You typically see those when the TLS connection wasn't closed cleanly. Unfortunately, this log line alone isn't enough to understand the actual problem. The full log line also mentions a session ID. You could
grep
the log for that ID to check for earlier messages related to the same session in order to track down at what point the connection was closed. Two possible causes are: (1) The client closed the connection during the initial handshake, e.g. because certificate verification failed or it was unhappy with TLS parameters/ciphers. (2) TURN relaying actually worked fine, and the client just didn't close the session cleanly. This can happen during normal operation, in which case it wouldn't be a problem at all.Do you mean the client doesn't use TLS if you disable TLSv1.2, or do you mean it falls back to earlier TLS versions? Either may be true, the log output should tell you. However, as I explained above, TLS has no security advantage in this context anyway, and can add significant latency, which is the reason UDP is usually used for (end-to-end encrypted) media streaming.