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

NetBird DNS Forwarded listens on a well-known mDNS port 5353 #1822

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

Originally created by @nazarewk on GitHub (Apr 17, 2025).

Describe the problem

NetBird DNS Forwarded tries to listen on a well-known mDNS port 5353.

systemd-resolved already claims the port (0.0.0.0:5353 & [::]:5353) as soon as you set MulticastDNS=true.

This is probably true for all (or at least most) multicast DNS servers.

A lot of operating system firewalls have rules (accidentally) preventing access to 5353 port on wt0 interface too.

To Reproduce

any of the following on machines acting as Routing Peers:

  • enable MulticastDNS=true in systemd-resolved
  • run Avahi (Linux) or Bonjour (MacOS) daemons

Expected behavior

NetBird DNS forwarder listens (or at least retries with) a custom port, which does not match any of the well-known ports used for other purposes.

Are you using NetBird Cloud?

Yes, n/a

NetBird version

0.40.0

Is any other VPN software installed?

no

Debug output

2025-04-17T14:33:33+02:00 ERRO client/internal/dnsfwd/manager.go:51: failed to start DNS forwarder, err: listen udp :5353: bind: address already in use

Screenshots

n/a

Additional context

Add any other context about the problem here.

Have you tried these troubleshooting steps?

  • 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 @nazarewk on GitHub (Apr 17, 2025). **Describe the problem** NetBird DNS Forwarded tries to listen on a well-known mDNS port 5353. `systemd-resolved` already claims the port (`0.0.0.0:5353` & `[::]:5353`) as soon as you set `MulticastDNS=true`. This is probably true for all (or at least most) multicast DNS servers. A lot of operating system firewalls have rules (accidentally) preventing access to 5353 port on `wt0` interface too. **To Reproduce** any of the following on machines acting as Routing Peers: - enable `MulticastDNS=true` in `systemd-resolved` - run Avahi (Linux) or Bonjour (MacOS) daemons **Expected behavior** NetBird DNS forwarder listens (or at least retries with) a custom port, which does not match any of the well-known ports used for other purposes. **Are you using NetBird Cloud?** Yes, n/a **NetBird version** 0.40.0 **Is any other VPN software installed?** no **Debug output** ``` 2025-04-17T14:33:33+02:00 ERRO client/internal/dnsfwd/manager.go:51: failed to start DNS forwarder, err: listen udp :5353: bind: address already in use ``` **Screenshots** n/a **Additional context** Add any other context about the problem here. **Have you tried these troubleshooting steps?** - [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 bugclient labels 2025-11-20 06:07:22 -05:00
saavagebueno commented 2025-11-20 06:07:23 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Sep 5, 2025):

Over the last month, I have stumbled upon multiple customer's VM Linux images occupying this port by default, requiring systemd units to be turned off with systemctl disable --now avahi-daemon.service avahi-daemon.socket, possibly followed by systemctl mask avahi-daemon.service avahi-daemon.socket.

Those included at least Ubuntu and Fedora images, but I can't tell which flavors exactly were those (server, desktop or something else).

We will be addressing this issue in near future.

@nazarewk commented on GitHub (Sep 5, 2025): Over the last month, I have stumbled upon multiple customer's VM Linux images occupying this port by default, requiring systemd units to be turned off with `systemctl disable --now avahi-daemon.service avahi-daemon.socket`, possibly followed by `systemctl mask avahi-daemon.service avahi-daemon.socket`. Those included at least Ubuntu and Fedora images, but I can't tell which flavors exactly were those (server, desktop or something else). We will be addressing this issue in near future.
saavagebueno commented 2025-11-20 06:07:23 -05:00
Author
Owner
Copy Link

@TonyBostonTB commented on GitHub (Sep 5, 2025):

We had this issue with Fedora 42 Server and yes the service needs to be masked it seems, otherwise it'll be up again after a reboot, at least that's what happend with us.

@TonyBostonTB commented on GitHub (Sep 5, 2025): We had this issue with Fedora 42 Server and yes the service needs to be masked it seems, otherwise it'll be up again after a reboot, at least that's what happend with us.
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 bug client
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#1822
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?