eturnal v1.0.0: say hello to a new STUN/TURN server

This is a guest post by Holger Weiß, the author of eturnal. Holger works as a professional server administrator at Freie Universität Berlin and operates the Conversations.im service
(together with Daniel Gultsch). He’s a regular contributor to ejabberd and various other Open Source projects.

Today, we released version 1.0.0 of our new STUN/TURN server called eturnal! It’s based on the STUN/TURN support that has been bundled and used successfully with the ejabberd XMPP/MQTT/SIP server for several years now. As WebRTC use cases continue to increase in popularity, we figured it makes sense to offer our STUN/TURN code to a broader audience by providing a stand-alone version.

Note that nothing changes for ejabberd users: STUN/TURN support will continue to be shipped as a built-in component with future ejabberd releases. Since both eturnal and ejabberd are now backed by the same STUN/TURN library, both will benefit from improvements to that library in the same way.

So what does eturnal have to offer? It’s a clean, straightforward piece of server software that fully supports the TURN features used by modern WebRTC applications such as Jitsi Meet, Big Blue Button, Nextcloud Talk, Movim, Conversations, and many others (without carrying around a baggage of features no longer in use these days). TURN clients can connect using UDP, TCP, or TLS over IPv4 or IPv6. Relaying to IPv6 peers is supported as well. Administrators can choose to limit the bandwidth of TCP and TLS connections, and to blacklist specific networks (or individual IP addresses) altogether. Configuration and TLS certificate files can be reloaded without interrupting A/V calls. eturnal integrates nicely with systemd and offers admin-friendly logging, either to a file or to the systemd journal.

For TURN authentication, the mechanism described in the REST API for Access to TURN Services specification is implemented. This is an IETF Draft that allows WebRTC services to easily generate short-lived TURN credentials without sharing any state with the TURN server. In a nutshell: If you’re creating your own WebRTC service, all you have to do is give your clients a username that’s comprised of the expiry timestamp and a password that’s derived from a secret shared with eturnal. To generate the password, you perform a Base64(HMAC-SHA1($secret, $timestamp)) operation, and eturnal does the same to verify the credentials. Depending on feedback, a future release of eturnal might even bundle a built-in REST interface that offers those credentials.

eturnal is freely available as Open Source software, well-documented and easy to set up. To get started, just grab the latest DEB or RPM package for Linux/x64 distributions (see the README file for other platforms), install the package (using dpkg -i eturnal*.deb or rpm -i eturnal*.rpm), and create an /etc/eturnal.yml file such as the following:

eturnal:
  secret: "long-and-cryptic"     # Shared secret, change this!
  relay_ipv4_addr: "203.0.113.4" # The server's public IPv4 address.
  relay_ipv6_addr: "2001:db8::4" # The server's public IPv6 address (optional).

Run systemctl reload eturnal to activate the new configuration. Or, if the service wasn’t running yet:

$ sudo systemctl daemon-reload
$ sudo systemctl enable eturnal
$ sudo systemctl start eturnal

If you try it out and have any feedback or feature wishes, please let us know!