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

[Problem] STUN Issues: user self credentials are incorrect - Unable to connect to other servers #1946

New Issue
Closed
opened 2025-11-20 06:10:00 -05:00 by saavagebueno · 9 comments
saavagebueno commented 2025-11-20 06:10:00 -05:00
Owner
Copy Link

Originally created by @Codixer on GitHub (Jun 8, 2025).

Describe the problem

I have no full idea where this is coming from, but currently. All our clients on 0.46.0 are reporting issues. Everything says it's connected just fine.

Image

But when we try to connect to ANY server at all, it's refusing the connection. I've enabled an ALL <-> ALL rule, and even that is not being processed by the clients. We're unable to connect to ANY side of the infrastructure.

We get the following error spammed in the console:
session 005000000000000013: check_stun_auth: user self credentials are incorrect

Image

To Reproduce

Unfortuanly, this is in no way explainable on how to reproduce, all I can say is that all clients are now on 0.46.0, and since then we've had this issue.

Expected behavior

Being able to connect to other servers. My best assumption is that the TURN server is having an issue that causes correct credentials to not be accepted for some reason. I checked the management.json and turnserver.conf. Both contain the same password. Down to the capital letter:
Image

My best guess is that TURN is the one client that manages the communication of stuff like the NB firewall rules and stuff, and since that's unable to connect now. It's unable to tell who can connect to whom.
'

Are you using NetBird Cloud?

Selfhosted netbird.

NetBird version

C:\Users\Gebruiker>netbird version
0.46.0

Is any other VPN software installed?

No

Debug output

To help us resolve the problem, please attach the following anonymized status output

 server-name.anon-EO3sq.domain:
  NetBird IP: 100.126.209.13
  Public key: 7ec0aVbGZTt1FlDVa1YH0wrEqNXapONIFesnknjWigw=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): srflx/host
  ICE candidate endpoints (Local/Remote): 198.51.100.0:63204/198.51.100.29:51820
  Relay server address: rel://relay.anon-8G5pv.domain:33080
  Last connection update: 13 minutes, 50 seconds ago
  Last WireGuard handshake: 1 minute, 20 seconds ago
  Transfer status (received/sent) 708 B/2.3 KiB
  Quantum resistance: false
  Networks: -
  Latency: 89.8727ms

 client-name.anon-EO3sq.domain:
  NetBird IP: 100.126.246.128
  Public key: BRFX+Yjx4iHfNIIcsVl7UEZ4gfoXMulSMql4Sc74njw=
  Status: Connecting
  -- detail --
  Connection type:
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address:
  Last connection update: 13 minutes, 51 seconds ago
  Last WireGuard handshake: -
  Transfer status (received/sent) 0 B/0 B
  Quantum resistance: false
  Networks: -
  Latency: 0s

 client-namet.anon-EO3sq.domain:
  NetBird IP: 100.126.248.99
  Public key: nJ6jc2w+JIfstwrFR3pAqvpIPGpGsnWUyF+UDQ8fzBU=
  Status: Connecting
  -- detail --
  Connection type:
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address:
  Last connection update: 13 minutes, 51 seconds ago
  Last WireGuard handshake: -
  Transfer status (received/sent) 0 B/0 B
  Quantum resistance: false
  Networks: -
  Latency: 0s

 client-name.anon-EO3sq.domain:
  NetBird IP: 100.126.254.195
  Public key: UyM3dsQXphPvBImTinbJc+pa1vIQSoZo52ibbeyMk0Q=
  Status: Connecting
  -- detail --
  Connection type:
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address:
  Last connection update: 13 minutes, 51 seconds ago
  Last WireGuard handshake: -
  Transfer status (received/sent) 0 B/0 B
  Quantum resistance: false
  Networks: -
  Latency: 0s

Events:
  [INFO] SYSTEM (a01d2052-ec5f-4c72-a75c-e55bda8e56f8)
    Message: Network map updated
    Time: 34 minutes, 6 seconds ago
  [INFO] SYSTEM (0983a6cf-bd4b-415f-b6d6-4260eff9b458)
    Message: Network map updated
    Time: 32 minutes, 39 seconds ago
  [INFO] SYSTEM (b0f51528-a42b-4525-a43d-1eacf1e8f2c5)
    Message: Network map updated
    Time: 28 minutes, 4 seconds ago
  [INFO] SYSTEM (e62b22fd-d42a-4564-a4d8-135e7371d7aa)
    Message: Network map updated
    Time: 21 minutes, 29 seconds ago
  [INFO] SYSTEM (ee912ce4-6b9b-4beb-9cd6-dad5ff94f8cf)
    Message: Network map updated
    Time: 19 minutes, 50 seconds ago
  [INFO] SYSTEM (2cc6b4ed-cd4b-4bcf-a390-5d582002d1a3)
    Message: Network map updated
    Time: 18 minutes, 51 seconds ago
  [INFO] SYSTEM (1e5d5395-5311-43de-8ccc-91ff9bcbda07)
    Message: Network map updated
    Time: 16 minutes, 15 seconds ago
  [INFO] SYSTEM (9edd86d7-93fa-4bf7-8e57-62c656f6758c)
    Message: Network map updated
    Time: 13 minutes, 51 seconds ago
  [INFO] SYSTEM (3c3a3577-22b6-4f2b-9147-6699a6c171db)
    Message: Network map updated
    Time: 13 minutes, 47 seconds ago
  [INFO] SYSTEM (385a40da-9e31-4cc2-a02e-3996cc1599e2)
    Message: Network map updated
    Time: 5 minutes, 41 seconds ago
OS: windows/amd64
Daemon version: 0.46.0
CLI version: 0.46.0
Management: Connected to https://vpn.anon-8G5pv.domain:443
Signal: Connected to https://vpn.anon-8G5pv.domain:443
Relays:
  [stun:turn.anon-8G5pv.domain:3478] is Available
  [turn:turn.anon-8G5pv.domain:3478?transport=udp] is Available
  [rel://relay.anon-8G5pv.domain:33080] is Available
Nameservers:
  [100.126.212.168:53] for [anon-gWSDF.domain] is Available
  [100.126.212.168:53] for [anon-sY1kn.domain] is Available
  [100.126.212.168:53] for [anon-BBsyE.domain] is Available
  [100.126.212.168:53] for [anon-mWH6A.domain] is Available
  [100.126.212.168:53] for [anon-HxJzh.domain] is Available
  [100.126.212.168:53] for [anon-fD284.domain] is Available
  [100.126.212.168:53] for [anon-aoJFH.domain] is Available
  [100.126.212.168:53] for [anon-OoEEi.domain] is Available
  [8.8.8.8:53, 8.8.4.4:53] for [.] is Available
  [100.126.212.168:53] for [anon-3mv7w.domain] is Available
  [100.126.212.168:53] for [anon-5lKlX.domain] is Available
  [100.126.212.168:53] for [anon-shjqQ.domain] is Available
  [100.126.212.168:53] for [anon-GpMtB.domain] is Available
  [100.126.212.168:53] for [anon-duN5v.domain] is Available
  [100.126.212.168:53] for [anon-Dh3uA.domain] is Available
  [100.126.212.168:53] for [anon-cEzrm.domain] is Available
  [100.126.212.168:53] for [anon-CGm1p.domain] is Available
  [100.126.212.168:53] for [anon-yFgf7.domain] is Available
  [100.126.212.168:53] for [anon-JvJ5C.domain] is Available
  [100.126.212.168:53] for [anon-g1OPh.domain] is Available
  [100.126.212.168:53] for [anon-Xo9qB.domain] is Available
  [100.126.212.168:53] for [anon-qocsH.domain] is Available
FQDN: stefanocoding-gamepc.anon-EO3sq.domain
NetBird IP: 100.126.136.200/16
Interface type: Userspace
Quantum resistance: false
Lazy connection: true
Networks: -
Forwarding rules: 0
Peers count: 33/90 Connected

Create and upload a debug bundle, and share the returned file key:

75bd102f54b54fcf4ff96d803496c5382cec871b9e8b71286220cf0104cd7d61/c9d04749-85fb-46a7-acb0-05b3c63e2e88

Uploaded files are automatically deleted after 30 days.

Additional Information:
Downgrading a client back down to 0.45.3 makes me able to connect to a 0.46.0 server. Something may have gone wrong on the clients, as all other machines (servers) have been setup with a setup key. Rather then SSO. However, this is roughly tested and I'm not 100% sure if this is applicable.
Downgrading did not work, both client and server on 0.45.3 (with management on 0.46.0) still does not allow people to connect.

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 @Codixer on GitHub (Jun 8, 2025). **Describe the problem** I have no full idea where this is coming from, but currently. All our clients on 0.46.0 are reporting issues. Everything says it's connected just fine. ![Image](https://github.com/user-attachments/assets/a6d52a17-bf77-47f0-ad80-459ea8401465) But when we try to connect to ANY server at all, it's refusing the connection. I've enabled an ALL <-> ALL rule, and even that is not being processed by the clients. We're unable to connect to ANY side of the infrastructure. We get the following error spammed in the console: session 005000000000000013: check_stun_auth: user self credentials are incorrect ![Image](https://github.com/user-attachments/assets/6b89faf3-19e9-4f70-8f3e-26119660606e) **To Reproduce** Unfortuanly, this is in no way explainable on how to reproduce, all I can say is that all clients are now on 0.46.0, and since then we've had this issue. **Expected behavior** Being able to connect to other servers. My best assumption is that the TURN server is having an issue that causes correct credentials to not be accepted for some reason. I checked the management.json and turnserver.conf. Both contain the same password. Down to the **capital letter**: ![Image](https://github.com/user-attachments/assets/d9980d48-ba98-4524-a417-eb4d1dfdc772) My best guess is that TURN is the one client that manages the communication of stuff like the NB firewall rules and stuff, and since that's unable to connect now. It's unable to tell who can connect to whom. ' **Are you using NetBird Cloud?** Selfhosted netbird. **NetBird version** C:\Users\Gebruiker>netbird version 0.46.0 **Is any other VPN software installed?** No **Debug output** To help us resolve the problem, please attach the following anonymized status output ``` server-name.anon-EO3sq.domain: NetBird IP: 100.126.209.13 Public key: 7ec0aVbGZTt1FlDVa1YH0wrEqNXapONIFesnknjWigw= Status: Connected -- detail -- Connection type: P2P ICE candidate (Local/Remote): srflx/host ICE candidate endpoints (Local/Remote): 198.51.100.0:63204/198.51.100.29:51820 Relay server address: rel://relay.anon-8G5pv.domain:33080 Last connection update: 13 minutes, 50 seconds ago Last WireGuard handshake: 1 minute, 20 seconds ago Transfer status (received/sent) 708 B/2.3 KiB Quantum resistance: false Networks: - Latency: 89.8727ms client-name.anon-EO3sq.domain: NetBird IP: 100.126.246.128 Public key: BRFX+Yjx4iHfNIIcsVl7UEZ4gfoXMulSMql4Sc74njw= Status: Connecting -- detail -- Connection type: ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: 13 minutes, 51 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Networks: - Latency: 0s client-namet.anon-EO3sq.domain: NetBird IP: 100.126.248.99 Public key: nJ6jc2w+JIfstwrFR3pAqvpIPGpGsnWUyF+UDQ8fzBU= Status: Connecting -- detail -- Connection type: ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: 13 minutes, 51 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Networks: - Latency: 0s client-name.anon-EO3sq.domain: NetBird IP: 100.126.254.195 Public key: UyM3dsQXphPvBImTinbJc+pa1vIQSoZo52ibbeyMk0Q= Status: Connecting -- detail -- Connection type: ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: 13 minutes, 51 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Networks: - Latency: 0s Events: [INFO] SYSTEM (a01d2052-ec5f-4c72-a75c-e55bda8e56f8) Message: Network map updated Time: 34 minutes, 6 seconds ago [INFO] SYSTEM (0983a6cf-bd4b-415f-b6d6-4260eff9b458) Message: Network map updated Time: 32 minutes, 39 seconds ago [INFO] SYSTEM (b0f51528-a42b-4525-a43d-1eacf1e8f2c5) Message: Network map updated Time: 28 minutes, 4 seconds ago [INFO] SYSTEM (e62b22fd-d42a-4564-a4d8-135e7371d7aa) Message: Network map updated Time: 21 minutes, 29 seconds ago [INFO] SYSTEM (ee912ce4-6b9b-4beb-9cd6-dad5ff94f8cf) Message: Network map updated Time: 19 minutes, 50 seconds ago [INFO] SYSTEM (2cc6b4ed-cd4b-4bcf-a390-5d582002d1a3) Message: Network map updated Time: 18 minutes, 51 seconds ago [INFO] SYSTEM (1e5d5395-5311-43de-8ccc-91ff9bcbda07) Message: Network map updated Time: 16 minutes, 15 seconds ago [INFO] SYSTEM (9edd86d7-93fa-4bf7-8e57-62c656f6758c) Message: Network map updated Time: 13 minutes, 51 seconds ago [INFO] SYSTEM (3c3a3577-22b6-4f2b-9147-6699a6c171db) Message: Network map updated Time: 13 minutes, 47 seconds ago [INFO] SYSTEM (385a40da-9e31-4cc2-a02e-3996cc1599e2) Message: Network map updated Time: 5 minutes, 41 seconds ago OS: windows/amd64 Daemon version: 0.46.0 CLI version: 0.46.0 Management: Connected to https://vpn.anon-8G5pv.domain:443 Signal: Connected to https://vpn.anon-8G5pv.domain:443 Relays: [stun:turn.anon-8G5pv.domain:3478] is Available [turn:turn.anon-8G5pv.domain:3478?transport=udp] is Available [rel://relay.anon-8G5pv.domain:33080] is Available Nameservers: [100.126.212.168:53] for [anon-gWSDF.domain] is Available [100.126.212.168:53] for [anon-sY1kn.domain] is Available [100.126.212.168:53] for [anon-BBsyE.domain] is Available [100.126.212.168:53] for [anon-mWH6A.domain] is Available [100.126.212.168:53] for [anon-HxJzh.domain] is Available [100.126.212.168:53] for [anon-fD284.domain] is Available [100.126.212.168:53] for [anon-aoJFH.domain] is Available [100.126.212.168:53] for [anon-OoEEi.domain] is Available [8.8.8.8:53, 8.8.4.4:53] for [.] is Available [100.126.212.168:53] for [anon-3mv7w.domain] is Available [100.126.212.168:53] for [anon-5lKlX.domain] is Available [100.126.212.168:53] for [anon-shjqQ.domain] is Available [100.126.212.168:53] for [anon-GpMtB.domain] is Available [100.126.212.168:53] for [anon-duN5v.domain] is Available [100.126.212.168:53] for [anon-Dh3uA.domain] is Available [100.126.212.168:53] for [anon-cEzrm.domain] is Available [100.126.212.168:53] for [anon-CGm1p.domain] is Available [100.126.212.168:53] for [anon-yFgf7.domain] is Available [100.126.212.168:53] for [anon-JvJ5C.domain] is Available [100.126.212.168:53] for [anon-g1OPh.domain] is Available [100.126.212.168:53] for [anon-Xo9qB.domain] is Available [100.126.212.168:53] for [anon-qocsH.domain] is Available FQDN: stefanocoding-gamepc.anon-EO3sq.domain NetBird IP: 100.126.136.200/16 Interface type: Userspace Quantum resistance: false Lazy connection: true Networks: - Forwarding rules: 0 Peers count: 33/90 Connected ``` Create and upload a debug bundle, and share the returned file key: `75bd102f54b54fcf4ff96d803496c5382cec871b9e8b71286220cf0104cd7d61/c9d04749-85fb-46a7-acb0-05b3c63e2e88` *Uploaded files are automatically deleted after 30 days.* **Additional Information**: ~~Downgrading a **client** back down to 0.45.3 makes me able to connect to a 0.46.0 server. Something may have gone wrong on the clients, as all other machines (servers) have been setup with a setup key. Rather then SSO. However, this is roughly tested and I'm not 100% sure if this is applicable.~~ Downgrading did not work, both client and server on 0.45.3 (with management on 0.46.0) still does not allow people to connect. **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [x] Checked for newer NetBird versions - [x] Searched for similar issues on GitHub (including closed ones) - [x] Restarted the NetBird client - [x] Disabled other VPN software - [x] Checked firewall settings
saavagebueno added the coturn label 2025-11-20 06:10:00 -05:00
saavagebueno commented 2025-11-20 06:10:01 -05:00
Author
Owner
Copy Link

@Codixer commented on GitHub (Jun 8, 2025):

So after... several hours of debugging. We think we've found the issue.
The turnserver recently had an update, I think it has to do with https://github.com/coturn/coturn/releases/tag/4.7.0

We have checked, and a new (or old) behavior of Turn just kicked into high grear.
Inside of the turnserver.conf there is a value that's used to specify the realm you connect with. This is set to wiretrustee's domain by default.
https://github.com/netbirdio/netbird/blame/main/infrastructure_files/turnserver.conf.tmpl#L347

We've updated the line to have it go to our own turn domain. And this seems to have resolved our issue, because TUrn is expecting the realm to be inside of the authentication request. If this is a change from 4.7.0. I do not know, but this is now solved. If anyone else is experiencing this issue. Check your config on the realm section. I will make a pull request for the resolution of this issue.

@Codixer commented on GitHub (Jun 8, 2025): So after... several hours of debugging. We **think** we've found the issue. The turnserver recently had an update, I think it has to do with https://github.com/coturn/coturn/releases/tag/4.7.0 We have checked, and a new (or old) behavior of Turn just kicked into high grear. Inside of the turnserver.conf there is a value that's used to specify the realm you connect with. This is set to wiretrustee's domain by default. https://github.com/netbirdio/netbird/blame/main/infrastructure_files/turnserver.conf.tmpl#L347 We've updated the line to have it go to our own turn domain. And this seems to have resolved our issue, because TUrn is expecting the realm to be inside of the authentication request. If this is a change from 4.7.0. I do not know, but this is now solved. If anyone else is experiencing this issue. Check your config on the realm section. I will make a pull request for the resolution of this issue.
saavagebueno commented 2025-11-20 06:10:01 -05:00
Author
Owner
Copy Link

@Codixer commented on GitHub (Jun 8, 2025):

Nevermind the above comment partially, still facing the same issue now. It didn't report the error, but after another restart. The error has returned. I'm back at where I started.

Image

I changed it to another domain (our main vpn. domain) and suddenly we're not getting this error anymore. But I recon once I restart the server. It'll do this again.

@Codixer commented on GitHub (Jun 8, 2025): Nevermind the above comment **partially**, still facing the same issue now. It didn't report the error, but after another restart. The error has returned. I'm back at where I started. ![Image](https://github.com/user-attachments/assets/6183850e-a8e6-4b94-bd53-b0e3a0eea75f) I changed it to another domain (our main vpn. domain) and suddenly we're not getting this error anymore. But I recon once I restart the server. It'll do this again.
saavagebueno commented 2025-11-20 06:10:01 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 8, 2025):

@Codixer This is a common case for stun and usually doesn't mean an issue with coturn. There is no authentication, but the turn session should have a session, and in some cases, you may get permission denied when the management server is changing your relay credentials if you are using time-based creds with a very short expiration date.

When you run netbird status -d do you see a specific error on stun and turn status output? or you see another behavior?

@mlsmaycon commented on GitHub (Jun 8, 2025): @Codixer This is a common case for stun and usually doesn't mean an issue with coturn. There is no authentication, but the turn session should have a session, and in some cases, you may get permission denied when the management server is changing your relay credentials if you are using time-based creds with a very short expiration date. When you run `netbird status -d` do you see a specific error on stun and turn status output? or you see another behavior?
saavagebueno commented 2025-11-20 06:10:01 -05:00
Author
Owner
Copy Link

@Codixer commented on GitHub (Jun 8, 2025):

@mlsmaycon
No errors in specific:

STUN errors from issue above:
Image

Current:

Management: Connected to https://vpn.anon-JHcgA.domain:443
Signal: Connected to https://vpn.anon-JHcgA.domain:443
Relays:
  [stun:vpn.anon-JHcgA.domain:3478] is Available
  [turn:vpn.anon-JHcgA.domain:3478?transport=udp] is Available
  [rel://relay.anon-JHcgA.domain:33080] is Available

No specific issues from TURN/STUN.

@Codixer commented on GitHub (Jun 8, 2025): @mlsmaycon No errors in specific: STUN errors from issue above: ![Image](https://github.com/user-attachments/assets/3f088926-aee8-4e32-8cc5-8b4b08b80ad5) Current: ``` Management: Connected to https://vpn.anon-JHcgA.domain:443 Signal: Connected to https://vpn.anon-JHcgA.domain:443 Relays: [stun:vpn.anon-JHcgA.domain:3478] is Available [turn:vpn.anon-JHcgA.domain:3478?transport=udp] is Available [rel://relay.anon-JHcgA.domain:33080] is Available ``` No specific issues from TURN/STUN.
saavagebueno commented 2025-11-20 06:10:01 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 8, 2025):

If you are not experiencing some connectivity issues between your peers, then it should be ok.

You can confirm that by running netbird debug for 1m and then checking the generated logs for OnRemoteCandidate XXXX udp4 srflx and discovered local candidate udp4 srflx which indicates that stun functionally is working as expected.

@mlsmaycon commented on GitHub (Jun 8, 2025): If you are not experiencing some connectivity issues between your peers, then it should be ok. You can confirm that by running `netbird debug for 1m` and then checking the generated logs for `OnRemoteCandidate XXXX udp4 srflx` and `discovered local candidate udp4 srflx` which indicates that stun functionally is working as expected.
saavagebueno commented 2025-11-20 06:10:02 -05:00
Author
Owner
Copy Link

@Codixer commented on GitHub (Jun 9, 2025):

If you are not experiencing some connectivity issues between your peers, then it should be ok.

You can confirm that by running netbird debug for 1m and then checking the generated logs for OnRemoteCandidate XXXX udp4 srflx and discovered local candidate udp4 srflx which indicates that stun functionally is working as expected.

So even if coturn reports the error. People should be fine with connecting? Because we've had reports from people not being able to connect outside of their own nat. Or is the relay responsible for that.

@Codixer commented on GitHub (Jun 9, 2025): > If you are not experiencing some connectivity issues between your peers, then it should be ok. > > You can confirm that by running `netbird debug for 1m` and then checking the generated logs for `OnRemoteCandidate XXXX udp4 srflx` and `discovered local candidate udp4 srflx` which indicates that stun functionally is working as expected. So even if coturn reports the error. People should be fine with connecting? Because we've had reports from people not being able to connect outside of their own nat. Or is the relay responsible for that.
saavagebueno commented 2025-11-20 06:10:02 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 9, 2025):

It could have been relay, but the best step is to troubleshoot these cases individually since it depends on different factors.

@mlsmaycon commented on GitHub (Jun 9, 2025): It could have been relay, but the best step is to troubleshoot these cases individually since it depends on different factors.
saavagebueno commented 2025-11-20 06:10:02 -05:00
Author
Owner
Copy Link

@Codixer commented on GitHub (Jun 9, 2025):

It has been the relay, it looks like I missed updating the infrastructure files. SInce this is not included in the updates. I assume the system was expecting the relay to be accecible over /relay but my nginx config had a /relay/ location. Causing it to ignore /relay. I still get the error.
Image

I do experience a different issue however. A user is suddenly authenticating over Authentik's groups JWT instead of Netbirds, but I'll make a seperate issue when it comes to it. For now, it should be fine.

@Codixer commented on GitHub (Jun 9, 2025): It has been the relay, it looks like I missed updating the infrastructure files. SInce this is not included in the updates. I assume the system was expecting the relay to be accecible over <domain>/relay but my nginx config had a /relay/ location. Causing it to ignore /relay. I still get the error. ![Image](https://github.com/user-attachments/assets/2e3a9d6a-0c4a-4f26-ac64-7447439ab5ea) I do experience a different issue however. A user is suddenly authenticating over Authentik's groups JWT instead of Netbirds, but I'll make a seperate issue when it comes to it. For now, it should be fine.
saavagebueno commented 2025-11-20 06:10:02 -05:00
Author
Owner
Copy Link

@Codixer commented on GitHub (Jun 9, 2025):

Anyways, thanks for the help @mlsmaycon!

@Codixer commented on GitHub (Jun 9, 2025): Anyways, thanks for the help @mlsmaycon!
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 coturn
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#1946
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?