[go: up one dir, main page]

Skip to content

UI bug: Self-hosted Duo config gives option of direct or indirect connection when only indirect works

Summary

Self-hosted Duo always uses indirect connections per this internal Slack thread, but the UI still gives the option to use direct connections, even in an air-gapped environment where contacting GitLab servers is not possible. Selecting direct connection does not change the behavior, as all requests are still routed through the self-hosted model. I believe this to be a UI bug, not a functional bug.

Steps to reproduce

  • Configure self-hosted GitLab 18.3.1 in an air-gapped environment
  • Configure self-hosted Duo
  • In the GitLab UI, go to Admin > Settings > General > GitLab Duo Features, and under Connection method observe that both direct and indirect are present
  • Toggling between direct and indirect does not change behavior; observe in llm.log that all Duo requests still go through the GitLab instance

What is the current bug behavior?

Direct and indirect connection options are both shown in settings when direct is not possible due to running in a network-restricted environment.

What is the expected correct behavior?

Direct connection should not be an option in air-gapped environments when changing the setting has no effect.

Relevant logs and/or screenshots

Screenshot_2025-09-09_at_08.27.10

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.