Configuring TLS and credentials doesn't work on Windows
how do you add the credentails and the tls to the eturnal.yml file on windows eturnal doesn't start when add the tls or credentials. File below.
# eturnal STUN/TURN server configuration file.
#
# This file is written in YAML. The YAML format is indentation-sensitive, please
# MAKE SURE YOU INDENT CORRECTLY.
#
# See: https://eturnal.net/doc/#Global_Configuration
eturnal:
## Shared secret for deriving temporary TURN credentials (default: $RANDOM):
secret: "mmtune"
## The server's public IPv4 address (default: autodetected):
relay_ipv4_addr: "192.168.1.10"
## The server's public IPv6 address (optional):
#relay_ipv6_addr: "2001:db8::4"
listen:
-
ip: "192.168.1.10"
port: 3478
transport: udp
-
ip: "192.168.1.10"
port: 3479
transport: tcp
-
ip: "192.168.1.10"
port: 5349
transport: tls
-
## TLS certificate/key files (must be readable by 'eturnal' user!):
tls_crt_file: /etc/eturnal/tls/turn_server_cert.pem
tls_key_file: /etc/eturnal/tls/turn_server_key.pem
Credentials:
mmtu: test
## UDP relay port range (usually, several ports per A/V call are required):
relay_min_port: 49152 # This is the default.
relay_max_port: 65535 # This is the default.
## Reject TURN relaying to the following addresses/networks:
blacklist_peers:
- recommended # Expands to various addresses/networks recommended
# to be blocked. This is the default.
## If 'true', close established calls on expiry of temporary TURN credentials:
strict_expiry: true # This is the default.
## Logging configuration:
log_level: info # critical | error | warning | notice | info | debug
log_rotate_size: 10485760 # 10 MiB (default: unlimited, i.e., no rotation).
log_rotate_count: 10 # Keep 10 rotated log files.
log_dir: "C:/Program Files/eturnal/log"
run_dir: "C:/Program Files/eturnal/run"
## See: https://eturnal.net/doc/#Module_Configuration
modules:
mod_log_stun: {} # Log STUN queries (in addition to TURN sessions).
#mod_stats_influx: {} # Log STUN/TURN events into InfluxDB.
#mod_stats_prometheus: # Expose STUN/TURN and VM metrics to Prometheus.
#ip: any # This is the default: Listen on all interfaces.
#port: 8081 # This is the default.
#tls: true # This is the default.
#vm_metrics: true # This is the default.
Credentials:
mmtu: test
The devil is in the details:
- The
credentialsoption must be written lower-case, i.e. the upper-caseCwon't work. - The file's YAML syntax is indentation-sensitive: There's an additional space character at the beginning of those two lines that you must remove.
eturnal doesn't work on windows. You can't add tls or credential to the yaml file. it won't start. full stop.
share secret doesn't work. $username = "1735686000" # For credentials valid until 2025-01-01. $secret = "secretuser" # As specified in your eturnal.yml.
$sha = [System.Security.Cryptography.KeyedHashAlgorithm]::Create("HMACSHA1") $sha.Key = [System.Text.Encoding]::UTF8.Getbytes($secret) $password = [Convert]::Tobase64String($sha.ComputeHash([System.Text.Encoding]::UTF8.Getbytes(${username})))
echo $username echo $password
eturnal doesn't work on windows.
We've tested eturnal on Windows successfully, so we should try to figure out how your setup is different from ours. Do you see any entries in C:\Program Files\eturnal\log\eturnal.log?
You can't add tls or credential to the yaml file. it won't start.
Does eturnal start if you use the default configuration file?
If so, could you try to make one change at a time: e.g., add only a TLS listener, check the log file, and if you see no entry at all, copy-paste the configuration file so that we can check it?
share secret doesn't work.
I'd suggest testing with static credentials first, and once that works, looking into shared secret authentication.
eturnal doesn't allow anyone to create TURN sessions by default. (Only STUN queries are accepted.)
Anyway, did you check the C:\Program Files\eturnal\log\eturnal.log file as I suggested above? If you see no log entries at all, eturnal is most likely still stumbling over invalid configuration syntax during startup. Unfortunately, eturnal's startup error messages are hidden by Windows, so spotting the issue without seeing your configuration is tricky.
One suggestion would be to copy-paste the following configuration, which works just fine for me on Windows, and continue from there.
# This file is written in YAML. The YAML format is indentation-sensitive, please
# MAKE SURE YOU INDENT CORRECTLY.
#
# See: https://eturnal.net/doc/#Global_Configuration
eturnal:
listen:
-
ip: "0.0.0.0"
port: 3478
transport: udp
-
ip: "::"
port: 3478
transport: udp
-
ip: "0.0.0.0"
port: 5349
transport: tls
-
ip: "::"
port: 5349
transport: tls
## TURN authentication (support both dynamic and static credentials):
secret: "change-this!"
credentials:
alice: "change-this-2"
## The server's public IPv4 address:
relay_ipv4_addr: "203.0.113.4"
## UDP relay port range, must be accessible from the outside:
relay_min_port: 50000
relay_max_port: 54999
log_dir: "C:/Program Files/eturnal/log"
run_dir: "C:/Program Files/eturnal/run"
modules:
mod_log_stun: {} # Log STUN queries (in addition to TURN sessions).
(You need to specify at least the relay_ipv4_addr to make TURN relaying work, though.)
It's a similar problem as mentioned above: The indentation is incorrect. This time, it's the listen: line that isn't indented correctly:
#relay_ipv6_addr: "2001:db8::4"
listen:
You removed the two leading spaces. It must look like this instead:
#relay_ipv6_addr: "2001:db8::4"
listen:
As mentioned at the top of the configuration file, the YAML format enforces correct indentation. With wrong indentation, eturnal won't be able to parse the configuration and will fail to start up.
Okay I see no obvious issue with that version and will test it on Windows.
Did you try copy-pasting my example above, which worked for me on Windows (just to track down the issue)?
Oh, actually eturnal started just fine with TLS enabled, according to your log snippet:
2025-03-27 18:06:55.166000+00:00 [notice] Starting eturnal 1.12.1 on Erlang/OTP 26 (ERTS 14.2.5.4)
2025-03-27 18:06:55.171000+00:00 [info] Got no NOTIFY_SOCKET, notifications disabled
2025-03-27 18:06:55.171000+00:00 [info] Relay IPv4 address: 81.133.133.94 (port range: 49152-65535)
2025-03-27 18:06:55.171000+00:00 [info] Relay IPv6 address not configured
2025-03-27 18:06:55.174000+00:00 [info] Listening on 127.0.0.1:52482 (tcp) (Erlang protocol version 6)
2025-03-27 18:06:55.175000+00:00 [warning] TLS enabled without 'tls_crt_file', creating self-signed certificate
2025-03-27 18:06:56.882000+00:00 [info] Started mod_log_stun
2025-03-27 18:06:56.984000+00:00 [info] Listening on 192.168.1.10:3478 (udp) (STUN/TURN)
2025-03-27 18:06:56.984000+00:00 [info] Listening on 192.168.1.10:3479 (tcp) (STUN/TURN)
2025-03-27 18:06:56.984000+00:00 [info] Listening on 192.168.1.10:5349 (tls) (STUN/TURN)
Why are you assuming it didn't start?
what are the software I need to run eturnal?
There are no external dependencies.
because eturnal run as a service and I have set it to auto start.
Note that it must currently be set to Automatic (Delayed Start), otherwise eturnal will fail to start up on system boot. See: https://github.com/erlang/otp/issues/6076
The Windows installer does that by default, though.
If the service stop our server display failed start warning.
I'm not sure I understand. The log file shows a success case, right? At the same time, SCM lists the service status as failed?
Yes. And despite this success, a "failed start warning" is displayed somewhere? Where exactly?
2025-03-27 18:22:26.598000+00:00 [warning] TLS enabled without 'tls_crt_file', creating self-signed certificate
This means TLS was enabled successfully.
This issue has been open for 30 days with no activity. Remove the "stale" label or comment, otherwise the issue will be closed in 5 days.
To remove the stale label.
To remove the stale label.
Why should it be removed? Without further feedback, we don't know whether there's still a problem, so there's no point in keeping the issue open. That's precisely what the stale label is supposed to take care of.
Unrelated: I'm confused by the fact that the last several comments of @mmtune seem to have vanished. Were they deleted (by @mmtune or someone else)?
I recently submitted a dummy comment here after your question, then I deleted it, and there is not message or sign indicating those facts.
However, I removed another person comment in https://github.com/processone/ejabberd/issues/4206#issuecomment-2849286604 and that one leaves a sign. Maybe github doesn't show any sign when the message is removed by the author itself, and only shows a sign when removed by a moderator?
Maybe github doesn't show any sign when the message is removed by the author itself, and only shows a sign when removed by a moderator?
I guess that's the case then, thanks. Was just a little worried that something (like github-actions) might've gone wrong and deleted random comments from the tracker.
I confirm:
- When the comment author removes this comment, there is no details.
- When a project admin removes a comment, it is specified.