500 error when using wireguard to authorize ldap

How to Use GitLab
1

Gitlab is installed on the hetzner server. We have an ldap server in our corporate network and have an openvpn connection to connect them. We needed to change openvpn to wireguard and after that several times a day we started getting 500 errors when opening the web version.
The error occurs when you open gitlab for the first time, not during the process, after a few minutes the error disappears.

There is no difference in the settings of openvpn and wireguard in my opinion, both work steadily. But the errors only appear when using wireguard.

In production.log the error looks similar if vpn connection is disabled. But if vpn is disabled then in web version when trying to login it will say “Connection timed out - user specified timeout”. But if there is a problem communicating with ldap why do I see 500 error and nothing else in my browser?

production.log:

Summary

Completed 500 Internal Server Error in 5044ms (ActiveRecord: 5.7ms | Elasticsearch: 0.0ms | Allocations: 5398)

Net::LDAP::Error (Connection timed out - user specified timeout):

lib/gitlab/auth/ldap/authentication.rb:29:in login' lib/gitlab/auth.rb:119:in block (2 levels) in find_with_user_password’
lib/gitlab/auth.rb:118:in each' lib/gitlab/auth.rb:118:in find’
lib/gitlab/auth.rb:118:in block in find_with_user_password' lib/gitlab/auth/unique_ips_limiter.rb:19:in limit_user!’
lib/gitlab/auth.rb:95:in find_with_user_password' lib/gitlab/auth.rb:181:in user_with_password_for_git’
lib/gitlab/auth.rb:66:in find_for_git_client' app/controllers/repositories/git_http_client_controller.rb:131:in handle_basic_authentication’
app/controllers/repositories/git_http_client_controller.rb:49:in authenticate_user' lib/gitlab/metrics/elasticsearch_rack_middleware.rb:16:in call’
lib/gitlab/middleware/memory_report.rb:13:in call' lib/gitlab/middleware/speedscope.rb:13:in call’
lib/gitlab/database/load_balancing/rack_middleware.rb:23:in call' lib/gitlab/middleware/rails_queue_duration.rb:33:in call’
lib/gitlab/metrics/rack_middleware.rb:16:in block in call' lib/gitlab/metrics/web_transaction.rb:46:in run’
lib/gitlab/metrics/rack_middleware.rb:16:in call' lib/gitlab/jira/middleware.rb:19:in call’
lib/gitlab/middleware/go.rb:20:in call' lib/gitlab/etag_caching/middleware.rb:21:in call’
lib/gitlab/middleware/query_analyzer.rb:11:in block in call' lib/gitlab/database/query_analyzer.rb:37:in within’
lib/gitlab/middleware/query_analyzer.rb:11:in call' lib/gitlab/middleware/multipart.rb:173:in call’
lib/gitlab/middleware/read_only/controller.rb:50:in call' lib/gitlab/middleware/read_only.rb:18:in call’
lib/gitlab/middleware/same_site_cookies.rb:27:in call' lib/gitlab/middleware/handle_malformed_strings.rb:21:in call’
lib/gitlab/middleware/basic_health_check.rb:25:in call' lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in call’
lib/gitlab/middleware/request_context.rb:21:in call' lib/gitlab/middleware/webhook_recursion_detection.rb:15:in call’
config/initializers/fix_local_cache_middleware.rb:11:in call' lib/gitlab/middleware/compressed_json.rb:37:in call’
lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in call' lib/gitlab/middleware/sidekiq_web_static.rb:20:in call’
lib/gitlab/metrics/requests_rack_middleware.rb:77:in call' lib/gitlab/middleware/release_env.rb:13:in call’

2

This is a VPN problem, so nothing related to Gitlab whatsoever. You could instead create firewall rules, to allow access from your VPS to your Corporate LDAP server without using a VPN and it would pretty much work 100% without any issues. If your security policies don’t allow for this, then perhaps move your VPS to your Corporate network, so that it can communicate locally with your LDAP server without having to go over the internet via VPN or via firewall rules.

The problem here lies with the way your VPN connection is working, so it’s not a fault of Gitlab itself. If the VPN isn’t active or passing packets, then Gitlab won’t see the LDAP server and thus give the timeout messages that you are seeing. As to why you see 500 error, depends on how Gitlab reacts to that particular scenario. Either way, that’s purely cosmetic, since the cause of the problem here is the VPN or lack of communication via it.