SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-05-18 22:22:14 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Quickstart script - waiting for Zitadel to be ready. #1428

New Issue
Closed
opened 2025-11-20 05:30:11 -05:00 by saavagebueno · 3 comments
saavagebueno commented 2025-11-20 05:30:11 -05:00
Owner
Copy Link

Originally created by @mikebakke on GitHub (Nov 19, 2024).

Context: Self host on a Debian12 VM running on Proxmox attempting the quick-start install.

** important **
I run haproxy to manage SSL termination and forwarding for many other VMs so can't send 443 direct from the router to the netbird VM. What I am doing is looking for my domain and then sending the 443 traffic as https to :433 on the Netbird VM.

backend netbird-https
mode http
http-request set-header X-Forwarded-Proto https
server netbird 192.168.100.59:443 ssl verify none proto h2

All other ports required are forwarded direct from my router to the VM.

I run the script and watch caddy logs. All containers start and I see caddy obtain a certificate for my domain:
{"level":"info","ts":1732012228.4474425,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["netbird.mydomain.com"]}
{"level":"debug","ts":1732012228.4776874,"logger":"tls.cache","msg":"added certificate to cache","subjects":["netbird.mydomain.com"],"expiration":1739779862,"managed":true,"issuer_key":"acme-v02.api.letsencrypt.org-directory","hash":"9b8be60e9266c98467d6a21b1e79a3d74336e9b5c8335d7485f51c8301e67623","cache_size":1,"cache_capacity":10000}
{"level":"debug","ts":1732012228.4777367,"logger":"events","msg":"event","name":"cached_managed_cert","id":"6f1f71c2-8cc6-49fe-bfa8-f0ec529cf0b5","origin":"tls","data":{"sans":["netbird.mydomain.com"]}}

The script then enters the "Waiting for Zitadel to be ready" loop and never leaves. Watching Caddy I see the following errors repeating and if I kill the script and docker up, then browse to https://netbird.mydomain.com I see the same error so I know the 443 is directed.

{"level":"debug","ts":1732012331.5612886,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"172.18.0.3"}
{"level":"debug","ts":1732012331.561304,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"192.168.100.6","remote_port":"46334","server_name":"","remote":"192.168.100.6:46334","identifier":"172.18.0.3","cipher_suites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"cert_cache_fill":0.0001,"load_or_obtain_if_necessary":true,"on_demand":false}
{"level":"debug","ts":1732012331.5613418,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.100.6:46334: no certificate available for '172.18.0.3'"}
{"level":"debug","ts":1732012332.5661497,"logger":"events","msg":"event","name":"tls_get_certificate","id":"38e3d39c-c3ac-492d-b990-5bf978d77c7e","origin":"tls","data":{"client_hello":{"CipherSuites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"ServerName":"","SupportedCurves":[29,23,30,25,24,256,257,258,259,260],"SupportedPoints":"AAEC","SignatureSchemes":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,769,770,1026,1282,1538],"SupportedProtos":null,"SupportedVersions":[772,771,770,769],"RemoteAddr":{"IP":"192.168.100.6","Port":46336,"Zone":""},"LocalAddr":{"IP":"172.18.0.3","Port":443,"Zone":""}}}}

I see 2 IPs - 192.168.100.6 is my haproxy node and I assume 172.18.0.3 is the docker.

I'd be happy to try and finagle running behind haproxy terminating SSL as I found previous solutions for that. I'd hoped to hack the compose file which the script generated to just remove caddy but it seems the script hasn't yet populated the other required .env files so that's not going to work either.

Also considered using the "advanced" route with own proxy but that does not contain Zitadel in the compose and I really don't want to also setup an IDP if I can help it.

I know this is not running as intended but would appreciate any suggestions.

NB: I did click on the slack link but as noted elsewhere that has expired

Originally created by @mikebakke on GitHub (Nov 19, 2024). Context: Self host on a Debian12 VM running on Proxmox attempting the quick-start install. ** important ** I run haproxy to manage SSL termination and forwarding for many other VMs so can't send 443 direct from the router to the netbird VM. What I am doing is looking for my domain and then sending the 443 traffic as https to :433 on the Netbird VM. backend netbird-https mode http http-request set-header X-Forwarded-Proto https server netbird 192.168.100.59:443 ssl verify none proto h2 All other ports required are forwarded direct from my router to the VM. I run the script and watch caddy logs. All containers start and I see caddy obtain a certificate for my domain: {"level":"info","ts":1732012228.4474425,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["netbird.mydomain.com"]} {"level":"debug","ts":1732012228.4776874,"logger":"tls.cache","msg":"added certificate to cache","subjects":["netbird.mydomain.com"],"expiration":1739779862,"managed":true,"issuer_key":"acme-v02.api.letsencrypt.org-directory","hash":"9b8be60e9266c98467d6a21b1e79a3d74336e9b5c8335d7485f51c8301e67623","cache_size":1,"cache_capacity":10000} {"level":"debug","ts":1732012228.4777367,"logger":"events","msg":"event","name":"cached_managed_cert","id":"6f1f71c2-8cc6-49fe-bfa8-f0ec529cf0b5","origin":"tls","data":{"sans":["netbird.mydomain.com"]}} The script then enters the "Waiting for Zitadel to be ready" loop and never leaves. Watching Caddy I see the following errors repeating and if I kill the script and docker up, then browse to https://netbird.mydomain.com I see the same error so I know the 443 is directed. {"level":"debug","ts":1732012331.5612886,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"172.18.0.3"} {"level":"debug","ts":1732012331.561304,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"192.168.100.6","remote_port":"46334","server_name":"","remote":"192.168.100.6:46334","identifier":"172.18.0.3","cipher_suites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"cert_cache_fill":0.0001,"load_or_obtain_if_necessary":true,"on_demand":false} {"level":"debug","ts":1732012331.5613418,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.100.6:46334: no certificate available for '172.18.0.3'"} {"level":"debug","ts":1732012332.5661497,"logger":"events","msg":"event","name":"tls_get_certificate","id":"38e3d39c-c3ac-492d-b990-5bf978d77c7e","origin":"tls","data":{"client_hello":{"CipherSuites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"ServerName":"","SupportedCurves":[29,23,30,25,24,256,257,258,259,260],"SupportedPoints":"AAEC","SignatureSchemes":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,769,770,1026,1282,1538],"SupportedProtos":null,"SupportedVersions":[772,771,770,769],"RemoteAddr":{"IP":"192.168.100.6","Port":46336,"Zone":""},"LocalAddr":{"IP":"172.18.0.3","Port":443,"Zone":""}}}} I see 2 IPs - 192.168.100.6 is my haproxy node and I assume 172.18.0.3 is the docker. I'd be happy to try and finagle running behind haproxy terminating SSL as I found previous solutions for that. I'd hoped to hack the compose file which the script generated to just remove caddy but it seems the script hasn't yet populated the other required .env files so that's not going to work either. Also considered using the "advanced" route with own proxy but that does not contain Zitadel in the compose and I really don't want to also setup an IDP if I can help it. I know this is not running as intended but would appreciate any suggestions. NB: I did click on the slack link but as noted elsewhere that has expired
saavagebueno added the triage-needed label 2025-11-20 05:30:11 -05:00
saavagebueno commented 2025-11-20 05:30:12 -05:00
Author
Owner
Copy Link

@cosmadora commented on GitHub (Nov 29, 2024):

Sorry for necromancing, but...
@mikebakke did you find a fix? I have the same issue with debian12 on arm64

@cosmadora commented on GitHub (Nov 29, 2024): Sorry for necromancing, but... @mikebakke did you find a fix? I have the same issue with debian12 on arm64
saavagebueno commented 2025-11-20 05:30:13 -05:00
Author
Owner
Copy Link

@mikebakke commented on GitHub (Nov 29, 2024):

I'm afraid I didn't. I shut everything down on a small VPS I have and just ran it up on there. It worked, but honestly I found the UI somewhat clunky and there seemed to be some limitations compared to the hosted version. In the end I shut it down because the VPS was need to run stuff I need. I'll leave it a while then maybe try the original config here again.

If I get too bored I might try running headscale with one of the available UIs and see if I can get that working.

Sorry.

@mikebakke commented on GitHub (Nov 29, 2024): I'm afraid I didn't. I shut everything down on a small VPS I have and just ran it up on there. It worked, but honestly I found the UI somewhat clunky and there seemed to be some limitations compared to the hosted version. In the end I shut it down because the VPS was need to run stuff I need. I'll leave it a while then maybe try the original config here again. If I get too bored I might try running headscale with one of the available UIs and see if I can get that working. Sorry.
saavagebueno commented 2025-11-20 05:30:13 -05:00
Author
Owner
Copy Link

@cosmadora commented on GitHub (Nov 29, 2024):

Not a problem ^-^ thanks for anwering. I did the same actually. Currently trying netmaker and having some more success tbh, but idk if I like it

@cosmadora commented on GitHub (Nov 29, 2024): Not a problem ^-^ thanks for anwering. I did the same actually. Currently trying netmaker and having some more success tbh, but idk if I like it
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label triage-needed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#1428
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?