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

[RELAY] [turn:xxx.yyy.com:3478?transport=udp] is Unavailable, reason: allocate: attribute not found #2383

New Issue
Open
opened 2025-11-20 07:08:59 -05:00 by saavagebueno · 2 comments
saavagebueno commented 2025-11-20 07:08:59 -05:00
Owner
Copy Link

Originally created by @TomGudman on GitHub (Oct 17, 2025).

Describe the problem

After upgrading to Debian 13 (was 12) and to Netbird 0.59.6 (was 0.55.1), the TURN relay stopped working with the following error on the client side (netbird status -d) : [turn:xxx.yyy.com:3478?transport=udp] is Unavailable, reason: allocate: attribute not found

By upgrade, I mean keeping the data on a volume and redeploying the VM and redeploying the docker containers with the same data (volume) than before.

To Reproduce
I am not sure.

Expected behavior
In netbird status -d I expect to have Relays: 3/3 Available instead of 2/3 Available relays
Expected

Relays: 
  [stun:netbird.xxx.yyy:3478] is Available
  [turn:netbird.xxx.yyy:3478?transport=udp] is Available
  [rels://netbird.xxx.yyy:443/relay] is Available

Current issue

Relays: 
  [stun:netbird.xxx.yyy:3478] is Available
  [turn:netbird.xxx.yyy:3478?transport=udp] is Unavailable, reason: allocate: attribute not found  <<<<<
  [rels://netbird.xxx.yyy:443/relay] is Available

Are you using NetBird Cloud?
No. I am selfhosted on Debian with docker containers and traefik taking the inbound traffic on port 443 and coturn on port 3478.

NetBird version
Server side: 0.59.6
See images below
image: netbirdio/dashboard:v2.20.0
image: netbirdio/signal:0.59.6
image: netbirdio/relay:0.59.6
image: netbirdio/management:0.59.6
image: coturn/coturn:4.7-bookworm (I tried 4.7, then 4.7-trixie, then 4.7-bookworm, same issue)

Client side: 0.59.6 (I tried with a 0.55.1 client and the issue remains hinting a the server)

Is any other VPN software installed?

No. Anyway it's a server side problem.

Debug output

Peers detail:
...
Events:
  [INFO] SYSTEM (0e01c26f-4381-4f3d-a3f3-102dd18ce6b0)
    Message: Network map updated
    Time: 6 minutes, 53 seconds ago
  [INFO] SYSTEM (a811eb36-4f07-4769-8ef7-a33c134f75c2)
    Message: Network map updated
    Time: 6 minutes, 24 seconds ago
OS: linux/amd64
Daemon version: 0.59.6
CLI version: 0.59.6
Profile: default
Management: Connected to [https://netbird.xxx.yyy:443](https://netbird.xxx.yyy/)
Signal: Connected to [https://netbird.xxx.yyy:443](https://netbird.xxx.yyy/)
Relays: 
  [stun:netbird.xxx.yyy:3478] is Available
  [turn:netbird.xxx.yyy:3478?transport=udp] is Unavailable, reason: allocate: attribute not found  <<<<<<<<<<<<<<<<<<
  [rels://netbird.xxx.yyy:443/relay] is Available
Nameservers:  
FQDN: <redacted>
NetBird IP: 100.93.xxx.zzz/16
Interface type: Kernel
Quantum resistance: false
Lazy connection: false
Networks: -
Forwarding rules: 0
Peers count: 1/17 Connected    (only 1 connected because it was the middle of the night and I was the only client, people can connect fine without TURN, for now)

I'll upload files on demand.

Screenshots
N/A

Additional context
I've also noted that the coturn:4.7 container which I used prior and still use now got updated 5 days ago... so it could be it the culprit but I tried a few different 4.7 versions and I still have the issue. As a result, I cannot tell where this issue comes from. However I am 100% certain that I had NO issues with Debian 12 and NetBird 0.55.1 and 'old' coturn 4.7. Everything was sweet. I regret not checking netbird status -d after the Debian 13 upgrade and prior to upgrading the NetBird containers...

I also saw on Slack #general that Micha recommends to ditch the coturn TURN for something done by NetBird maybe there is some incompatibility with the new code? Ref: https://www.reddit.com/r/selfhosted/comments/1o2czam/comment/njgqhu6/

When checking the client logs, I do observe some errors, I am unsure if they are fully related since the QUIC (HTTP3?) issue is on port 443 but the error returned by the clients seems to be on the coturn port 3478... If port 443 relay stuff is the culprit then it could be traefik which was unfortunately set a traefik:latest so I dunno which version I was using prior (I deployed NetBird in August so it's likely Traefik 3.4.x instead of 3.5.x).

2025-10-15T10:39:23+10:00 INFO client/server/server.go:451: active profile: default for
2025-10-15T10:39:25+10:00 INFO client/server/server.go:685: active profile: default for
2025-10-15T10:39:25+10:00 INFO client/internal/connect.go:124: starting NetBird client version 0.59.6 on linux/amd64
2025-10-15T10:39:25+10:00 INFO client/net/env_linux.go:70: system supports advanced routing
2025-10-15T10:39:28+10:00 INFO client/internal/connect.go:463: using 34843 as wireguard port: 0 is in use
2025-10-15T10:39:28+10:00 INFO client/internal/connect.go:265: connecting to the Relay service(s): rels://netbird.xxx.yyy:443/relay
2025-10-15T10:39:28+10:00 INFO shared/relay/client/picker.go:71: try to connecting to relay server: rels://netbird.xxx.yyy:443/relay
2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/client.go:168: create new relay connection: local peerID: umEQJENvLP7Mc3nGgQQvfffF1S9lcziguWuivAslVhY=, local peer hashedID: sha-B0lg32NkKoIVyZIp5lbWrIK/xZre743FOTBqU7LJ4/o=
2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/client.go:174: connecting to relay server
2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:66: dialing Relay server via quic 
2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:66: dialing Relay server via WS
2025-10-15T10:39:28+10:00 ERRO shared/relay/client/dialer/quic/quic.go:56: failed to resolve UDP address: lookup udp/443/relay: unknown port <<<<<<<<<<<<<<<<<<<
2025-10-15T10:39:28+10:00 ERRO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:79: failed to dial via quic: lookup udp/443/relay: unknown port
2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:91: successfully dialed via: WS
2025-10-15T10:39:29+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/client.go:196: relay connection established
2025-10-15T10:39:29+10:00 INFO shared/relay/client/picker.go:89: connected to Relay server: rels://netbird.xxx.yyy:443/relay
2025-10-15T10:39:29+10:00 INFO shared/relay/client/picker.go:63: chosen home Relay server: rels://netbird.xxx.yyy:443/relay
2025-10-15T10:39:29+10:00 INFO client/internal/engine.go:269: I am: umEQJENvLP7Mc3nGgQQvfffF1S9lcziguWuivAslVhY=

Ref: https://netbirdio.slack.com/archives/C02KHAE8VLZ/p1760487675530229

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
    --> I've found https://github.com/netbirdio/netbird/issues/2566 that could relate maybe...
  • 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 @TomGudman on GitHub (Oct 17, 2025). **Describe the problem** After upgrading to Debian 13 (was 12) and to Netbird 0.59.6 (was 0.55.1), the TURN relay stopped working with the following error on the client side (netbird status -d) : `[turn:xxx.yyy.com:3478?transport=udp] is Unavailable, reason: allocate: attribute not found` By upgrade, I mean keeping the data on a volume and redeploying the VM and redeploying the docker containers with the same data (volume) than before. **To Reproduce** I am not sure. **Expected behavior** In `netbird status -d` I expect to have `Relays: 3/3 Available` instead of `2/3 Available` relays _Expected_ ``` Relays: [stun:netbird.xxx.yyy:3478] is Available [turn:netbird.xxx.yyy:3478?transport=udp] is Available [rels://netbird.xxx.yyy:443/relay] is Available ``` _Current issue_ ``` Relays: [stun:netbird.xxx.yyy:3478] is Available [turn:netbird.xxx.yyy:3478?transport=udp] is Unavailable, reason: allocate: attribute not found <<<<< [rels://netbird.xxx.yyy:443/relay] is Available ``` **Are you using NetBird Cloud?** No. I am selfhosted on Debian with docker containers and traefik taking the inbound traffic on port 443 and coturn on port 3478. **NetBird version** Server side: 0.59.6 See images below image: netbirdio/dashboard:v2.20.0 image: netbirdio/signal:0.59.6 image: netbirdio/relay:0.59.6 image: netbirdio/management:0.59.6 image: coturn/coturn:4.7-bookworm (I tried 4.7, then 4.7-trixie, then 4.7-bookworm, same issue) Client side: 0.59.6 (I tried with a 0.55.1 client and the issue remains hinting a the server) **Is any other VPN software installed?** No. Anyway it's a server side problem. **Debug output** ``` Peers detail: ... Events: [INFO] SYSTEM (0e01c26f-4381-4f3d-a3f3-102dd18ce6b0) Message: Network map updated Time: 6 minutes, 53 seconds ago [INFO] SYSTEM (a811eb36-4f07-4769-8ef7-a33c134f75c2) Message: Network map updated Time: 6 minutes, 24 seconds ago OS: linux/amd64 Daemon version: 0.59.6 CLI version: 0.59.6 Profile: default Management: Connected to [https://netbird.xxx.yyy:443](https://netbird.xxx.yyy/) Signal: Connected to [https://netbird.xxx.yyy:443](https://netbird.xxx.yyy/) Relays: [stun:netbird.xxx.yyy:3478] is Available [turn:netbird.xxx.yyy:3478?transport=udp] is Unavailable, reason: allocate: attribute not found <<<<<<<<<<<<<<<<<< [rels://netbird.xxx.yyy:443/relay] is Available Nameservers: FQDN: <redacted> NetBird IP: 100.93.xxx.zzz/16 Interface type: Kernel Quantum resistance: false Lazy connection: false Networks: - Forwarding rules: 0 Peers count: 1/17 Connected (only 1 connected because it was the middle of the night and I was the only client, people can connect fine without TURN, for now) ``` I'll upload files on demand. **Screenshots** N/A **Additional context** I've also noted that the coturn:4.7 container which I used prior and still use now got updated 5 days ago... so it could be it the culprit but I tried a few different 4.7 versions and I still have the issue. As a result, I cannot tell where this issue comes from. However I am 100% certain that I had NO issues with Debian 12 and NetBird 0.55.1 and 'old' coturn 4.7. Everything was sweet. I regret not checking netbird status -d after the Debian 13 upgrade and prior to upgrading the NetBird containers... I also saw on Slack #general that Micha recommends to ditch the coturn TURN for something done by NetBird maybe there is some incompatibility with the new code? Ref: https://www.reddit.com/r/selfhosted/comments/1o2czam/comment/njgqhu6/ When checking the client logs, I do observe some errors, I am unsure if they are fully related since the QUIC (HTTP3?) issue is on port 443 but the error returned by the clients seems to be on the coturn port 3478... If port 443 relay stuff is the culprit then it could be traefik which was unfortunately set a `traefik:latest` so I dunno which version I was using prior (I deployed NetBird in August so it's likely Traefik 3.4.x instead of 3.5.x). ``` 2025-10-15T10:39:23+10:00 INFO client/server/server.go:451: active profile: default for 2025-10-15T10:39:25+10:00 INFO client/server/server.go:685: active profile: default for 2025-10-15T10:39:25+10:00 INFO client/internal/connect.go:124: starting NetBird client version 0.59.6 on linux/amd64 2025-10-15T10:39:25+10:00 INFO client/net/env_linux.go:70: system supports advanced routing 2025-10-15T10:39:28+10:00 INFO client/internal/connect.go:463: using 34843 as wireguard port: 0 is in use 2025-10-15T10:39:28+10:00 INFO client/internal/connect.go:265: connecting to the Relay service(s): rels://netbird.xxx.yyy:443/relay 2025-10-15T10:39:28+10:00 INFO shared/relay/client/picker.go:71: try to connecting to relay server: rels://netbird.xxx.yyy:443/relay 2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/client.go:168: create new relay connection: local peerID: umEQJENvLP7Mc3nGgQQvfffF1S9lcziguWuivAslVhY=, local peer hashedID: sha-B0lg32NkKoIVyZIp5lbWrIK/xZre743FOTBqU7LJ4/o= 2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/client.go:174: connecting to relay server 2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:66: dialing Relay server via quic 2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:66: dialing Relay server via WS 2025-10-15T10:39:28+10:00 ERRO shared/relay/client/dialer/quic/quic.go:56: failed to resolve UDP address: lookup udp/443/relay: unknown port <<<<<<<<<<<<<<<<<<< 2025-10-15T10:39:28+10:00 ERRO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:79: failed to dial via quic: lookup udp/443/relay: unknown port 2025-10-15T10:39:28+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/dialer/race_dialer.go:91: successfully dialed via: WS 2025-10-15T10:39:29+10:00 INFO [relay: rels://netbird.xxx.yyy:443/relay] shared/relay/client/client.go:196: relay connection established 2025-10-15T10:39:29+10:00 INFO shared/relay/client/picker.go:89: connected to Relay server: rels://netbird.xxx.yyy:443/relay 2025-10-15T10:39:29+10:00 INFO shared/relay/client/picker.go:63: chosen home Relay server: rels://netbird.xxx.yyy:443/relay 2025-10-15T10:39:29+10:00 INFO client/internal/engine.go:269: I am: umEQJENvLP7Mc3nGgQQvfffF1S9lcziguWuivAslVhY= ``` Ref: https://netbirdio.slack.com/archives/C02KHAE8VLZ/p1760487675530229 **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) --> I've found https://github.com/netbirdio/netbird/issues/2566 that could relate maybe... - [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 triage-needed label 2025-11-20 07:08:59 -05:00
saavagebueno commented 2025-11-20 07:09:00 -05:00
Author
Owner
Copy Link

@TomGudman commented on GitHub (Oct 18, 2025):

Kinda look similar - closed without a resolution : https://github.com/netbirdio/netbird/issues/1898 except I don't have any HA setup nor alternate relay server.

@TomGudman commented on GitHub (Oct 18, 2025): Kinda look similar - closed without a resolution : https://github.com/netbirdio/netbird/issues/1898 except I don't have any HA setup nor alternate relay server.
saavagebueno commented 2025-11-20 07:09:01 -05:00
Author
Owner
Copy Link

@ghazyami commented on GitHub (Oct 19, 2025):

I am seeing the same on a new setup. Still investigating why.

Update: Just SELinux issue mounting turnserver.conf, working for me now

Relay is the homegrown relay developed by netbird that kinda replaces TURN.
Which you already have running here

[rels://netbird.xxx.yyy:443/relay] is Available
@ghazyami commented on GitHub (Oct 19, 2025): ~~I am seeing the same on a new setup. Still investigating why.~~ Update: Just SELinux issue mounting turnserver.conf, working for me now --- `Relay` is the homegrown relay developed by netbird that kinda replaces `TURN`. Which you already have running here ``` [rels://netbird.xxx.yyy:443/relay] is Available ```
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#2383
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?