[GH-ISSUE #5869] getting-started.sh: infinite wait loop when using existing Traefik (option 1) #11210

Open
opened 2026-08-05 01:28:55 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @WalidDevIO on GitHub (Apr 13, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5869

Originally assigned to: @WalidDevIO on GitHub.

Describe the problem

When selecting reverse proxy option [1] Existing Traefik, the script calls wait_management_direct which attempts to reach http://127.0.0.1:8081/oauth2/.well-known/openid-configuration. However, render_docker_compose_traefik (used for type 1) does not expose port 8081 on the host, only UDP 3478 is published. As a result, the script loops indefinitely until timeout despite the netbird-server container being fully started and healthy.

To Reproduce

Steps to reproduce the behavior:

  1. Run getting-started.sh
  2. Select an existing Traefik instance (option 1)
  3. Observe: script blocks on Waiting for NetBird server to become ready until timeout despite server being up

Expected behavior

For type 1 (existing Traefik), the script should call wait_management_proxy and check via the domain (https://$NETBIRD_DOMAIN/oauth2/.well-known/openid-configuration), exactly like type 0 (builtin Traefik) does since in both cases a reverse proxy is handling TLS termination and routing.

Are you using NetBird Cloud?

Self hosted

Suggested fix

In start_services_and_show_instructions, replace wait_management_direct with wait_management_proxy for type 1. Since the external Traefik container name is unknown to the script, two approaches are possible:

Ask the user: add a read_traefik_container_name prompt during configure_reverse_proxy for type 1, alongside the existing network/entrypoint/certresolver prompts
Auto-detect: inspect running containers to find one using the traefik image with ports 80 and 443 exposed: docker ps --filter "ancestor=traefik" --format "{{.Names}}"

Option 2 is preferred for UX consistency but may fail if the user runs a custom-tagged Traefik image. A fallback to option 1 (or a default of traefik) would make it robust.

Note: wait_management_proxy already accepts the container name as a parameter, so the change is minimal once the name is resolved.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @WalidDevIO on GitHub (Apr 13, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5869 Originally assigned to: @WalidDevIO on GitHub. **Describe the problem** When selecting reverse proxy option [1] Existing Traefik, the script calls wait_management_direct which attempts to reach http://127.0.0.1:8081/oauth2/.well-known/openid-configuration. However, render_docker_compose_traefik (used for type 1) does not expose port 8081 on the host, only UDP 3478 is published. As a result, the script loops indefinitely until timeout despite the netbird-server container being fully started and healthy. **To Reproduce** Steps to reproduce the behavior: 1. Run getting-started.sh 2. Select an existing Traefik instance (option 1) 3. Observe: script blocks on Waiting for NetBird server to become ready until timeout despite server being up **Expected behavior** For type 1 (existing Traefik), the script should call wait_management_proxy and check via the domain (https://$NETBIRD_DOMAIN/oauth2/.well-known/openid-configuration), exactly like type 0 (builtin Traefik) does since in both cases a reverse proxy is handling TLS termination and routing. **Are you using NetBird Cloud?** Self hosted **Suggested fix** In start_services_and_show_instructions, replace wait_management_direct with wait_management_proxy for type 1. Since the external Traefik container name is unknown to the script, two approaches are possible: Ask the user: add a read_traefik_container_name prompt during configure_reverse_proxy for type 1, alongside the existing network/entrypoint/certresolver prompts Auto-detect: inspect running containers to find one using the traefik image with ports 80 and 443 exposed: docker ps --filter "ancestor=traefik" --format "{{.Names}}" Option 2 is preferred for UX consistency but may fail if the user runs a custom-tagged Traefik image. A fallback to option 1 (or a default of traefik) would make it robust. Note: wait_management_proxy already accepts the container name as a parameter, so the change is minimal once the name is resolved. **Have you tried these troubleshooting steps?** - [ ] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [ ] Checked for newer NetBird versions - [ ] Searched for similar issues on GitHub (including closed ones) - [ ] Restarted the NetBird client - [ ] Disabled other VPN software - [ ] Checked firewall settings
saavagebueno added the bug label 2026-08-05 01:28:55 -04:00
Sign in to join this conversation.
No Label bug
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11210