this a fresh docker-compose setup on CentOS7.9. TLS seem to be setup properly - the website can be reached without TLS errors. Still the login is not working. Only errors I was able to find inside logs:
Feb 17, 2021 11:30:33 AM org.jitsi.utils.logging2.LoggerImpl log SEVERE: Health check failed in PT0S: java.lang.Exception: Address discovery through STUN failed at org.jitsi.videobridge.health.Health.performCheck(Health.java:156)
auth-pod:responding with HTTP 500 to authentication requests
Regarding STUN-error message: I am aware of this. Network team did not yet allow UDP traffic for 10.000 & 19.302. But regardless of this error the "DHParams"-error should not appear. I remember from one of my test envoirnments that I was able to login - eventhough UDP traffic is denied. Also DHParams-error message should not appear in relation to UDP connections.
Any ideas what is causing the error message ?
I have already used cert, key & dhparams from another envoirnment: same issue. Any other problems in the envoirnment ? I had a few NTP-related problems earlier this week, but time is fine now. After rebuilding the pods error still appears in logs.
I have already removed dhparams file. Error message is the typical HTTP 500 message "oops that didn't work". As mentioned in the description: I have also tried different certs from a working envoirnment (including re-using and re-creating the DHParams file). I am not sure what you mean by "proxy server is in DNS": We have a proxy configured, I did also apply this proxy/the env variables for docker daemon.
Fist suggestion here is to open a case so we can review. We will need to see configuration as well as look at the logs in more detail.
Until STUN is fixed, you will not be able to join a meeting - and there may be other authentication issues if you are not able to hit the proxy correctly. We will need AUTH and NGINX logs for authentication issues.
If STUN will remain broken, and you want to test with a local address - comment out STUN in .env and add an appropriate DOCKER_HOST_ADDRESS to custom.env (and then restart).
I will have to look into the other error - but we must deal with STUN first.
Thanks for the reply. I have already created a case (CS0207712). Actually my intention was to really concentrate on this DH error since STUN-error will approx. exist for the next 2 weeks. The network guys will need time to complete the change and allow UDP traffic from external clients to be routed inside the company LAN (at least 2 weeks is what I am expecting based on experiences I have made in the past). Docker-Host is already set to IP address of docker node
If you have docker-host set- comment out STUN until the network is solved - that will atleast allow you to get everything 'functional' and you could test with clients that can reach the docker_host_address.
Request the case be passed on up to L3 and I'll look at the data.
After reinstalling the Meetings server login to Meetings is now working. Bad configured NTP probably caused the problem (time gap of >1min during initial setup). Eventhough the DHParams error is still seen inside the logs.
The dhparams.pem files are created during the initial start of the environment. But not immediately... In our case it took a few minutes until the files were created and the size was > 0 kb.
If you just start the environment for the first time and immediately shut it down again (e.g. for inserting the proper the SSL-certs), you will end up with empty dhparams.pem files.
Our solution: Watch the size of the dhparams.pem files (location: see below) and only stop the environment after their size is > 0 kb.