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
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