DYNR/netbird
2
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-08-07 02:29:06 -04:00
Code Issues 23.5k Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #2253] DNS issue inside a docker container #4497

New Issue
Open
opened 2026-08-05 00:58:01 -04:00 by saavagebueno · 7 comments
saavagebueno commented 2026-08-05 00:58:01 -04:00
Owner
Copy Link

Originally created by @wgfilho on GitHub (Jul 10, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2253

Originally assigned to: @nazarewk on GitHub.

Hi,

Consider the following case:

  • Computer 1 (C1) running Debian with Netbird installed directly bare metal. This computer runs docker with a container D1.

  • Computer 2 (C2) running Debian with Netbird installed directly bare metal.

  • From C1 I can ping c2.netbird.cloud and the c2's Netbird ip without problems, everything works as expected.

  • From D1 I can ping the IP of C2 (the Netbird ip); I can nslookup c2.netbird.cloud, it resolves correctly; but I can't ping c2.netbird.cloud. This returns "bad address". If I try to access c2.netbird.cloud in any way other than nslookup, it fails.

What am I doing wrong? Is there any way to make it work? Do you need any more information to be able to better understand the issue?

Thanks!

Originally created by @wgfilho on GitHub (Jul 10, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2253 Originally assigned to: @nazarewk on GitHub. Hi, Consider the following case: - Computer 1 (C1) running Debian with Netbird installed directly bare metal. This computer runs docker with a container D1. - Computer 2 (C2) running Debian with Netbird installed directly bare metal. - From C1 I can ping c2.netbird.cloud and the c2's Netbird ip without problems, everything works as expected. - From D1 I can ping the IP of C2 (the Netbird ip); I can nslookup c2.netbird.cloud, it resolves correctly; but I can't ping c2.netbird.cloud. This returns "bad address". If I try to access c2.netbird.cloud in any way other than nslookup, it fails. What am I doing wrong? Is there any way to make it work? Do you need any more information to be able to better understand the issue? Thanks!
saavagebueno added the triage-needed label 2026-08-05 00:58:01 -04:00
saavagebueno commented 2026-08-05 00:58:01 -04:00
Author
Owner
Copy Link

@codingCoffee commented on GitHub (Apr 4, 2025):

Hey! I'm facing the same issue. Did you figure out a fix for this by any chance?

<!-- gh-comment-id:2778632493 --> @codingCoffee commented on GitHub (Apr 4, 2025): Hey! I'm facing the same issue. Did you figure out a fix for this by any chance?
saavagebueno commented 2026-08-05 00:58:01 -04:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Apr 7, 2025):

I know for a fact that Podman's iptables/nftables integration can interfere with Netbird client rules. It might be a similar case for Docker.

I can try to reproduce and see what's going on, but I can't give you any estimate on when that would happen.

If you have the technical capabilities to figure out below, it would help tremendously to:

  • figure out what kind of routing table and firewall rules:
    • the container has
    • the host has (in context of Docker/Netbird interactions)
  • run tcpdump to see where the packet gets dropped
  • try to figure out which firewall rules are responsible for the packets not arriving to the host
<!-- gh-comment-id:2782808278 --> @nazarewk commented on GitHub (Apr 7, 2025): I know for a fact that Podman's `iptables`/`nftables` integration can interfere with Netbird client rules. It might be a similar case for Docker. I can try to reproduce and see what's going on, but I can't give you any estimate on when that would happen. If you have the technical capabilities to figure out below, it would help tremendously to: - figure out what kind of routing table and firewall rules: - the container has - the host has (in context of Docker/Netbird interactions) - run `tcpdump` to see where the packet gets dropped - try to figure out which firewall rules are responsible for the packets not arriving to the host
saavagebueno commented 2026-08-05 00:58:01 -04:00
Author
Owner
Copy Link

@hakansa commented on GitHub (Apr 7, 2025):

can you try ping -4 <domain> ?
if it works docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 ...might be a workaround.

<!-- gh-comment-id:2782835703 --> @hakansa commented on GitHub (Apr 7, 2025): can you try `ping -4 <domain>` ? if it works `docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 ...`might be a workaround.
saavagebueno commented 2026-08-05 00:58:01 -04:00
Author
Owner
Copy Link

@folivaud-raliance commented on GitHub (Sep 9, 2025):

Hello, i have the same issue.
@hakansa the ping -4 <domain> works on my side, but your workaround does not

<!-- gh-comment-id:3269788104 --> @folivaud-raliance commented on GitHub (Sep 9, 2025): Hello, i have the same issue. @hakansa the `ping -4 <domain>` works on my side, but your workaround does not
saavagebueno commented 2026-08-05 00:58:02 -04:00
Author
Owner
Copy Link

@nmapx commented on GitHub (Sep 23, 2025):

@folivaud-raliance @hakansa
This is actually not a Netbird issue but how Docker and systemd-resolved interact.
If you want more details please dig into it - there are some docs describing dns inheritance in Docker.
As a quick fix I can recommend you:

  • edit /etc/systemd/resolved.conf and add DNSStubListenerExtra=172.17.0.1 - make sure to use your docker0 ip addr
  • restart systemd-resolved service systemd-resolved restart
  • add { "dns": ["172.17.0.1"] } to your /etc/docker/daemon.json
  • restart docker service service docker restart

Simple as that, containers will now use your host dns resolver.

<!-- gh-comment-id:3325369565 --> @nmapx commented on GitHub (Sep 23, 2025): @folivaud-raliance @hakansa This is actually not a Netbird issue but how Docker and systemd-resolved interact. If you want more details please dig into it - there are some docs describing dns inheritance in Docker. As a quick fix I can recommend you: - edit `/etc/systemd/resolved.conf` and add `DNSStubListenerExtra=172.17.0.1` - make sure to use your docker0 ip addr - restart systemd-resolved `service systemd-resolved restart` - add `{ "dns": ["172.17.0.1"] }` to your `/etc/docker/daemon.json` - restart docker service `service docker restart` Simple as that, containers will now use your host dns resolver.
saavagebueno commented 2026-08-05 00:58:02 -04:00
Author
Owner
Copy Link

@jfrconley commented on GitHub (Jan 22, 2026):

@folivaud-raliance @hakansa This is actually not a Netbird issue but how Docker and systemd-resolved interact. If you want more details please dig into it - there are some docs describing dns inheritance in Docker. As a quick fix I can recommend you:

* edit `/etc/systemd/resolved.conf` and add `DNSStubListenerExtra=172.17.0.1` - make sure to use your docker0 ip addr

* restart systemd-resolved `service systemd-resolved restart`

* add `{ "dns": ["172.17.0.1"] }` to your `/etc/docker/daemon.json`

* restart docker service `service docker restart`

Simple as that, containers will now use your host dns resolver.

This solution does not seem to work, perhaps due to changes in local resolver config with more recent netbird versions. I am not able to access DNS at all from any docker container on linux systems with systemd-resolve. I have verified that the host ip is reachable in the container and that cloudflare dns does work (1.1.1.1). I have also tried the ports 53, 5353, and 22053 to no avail.

The only current fixes I can get working are:

  1. disabling netbird from the host (not great)
  2. host networking (even worse)
  3. explicitly specifying a dns server when starting the container
<!-- gh-comment-id:3786943579 --> @jfrconley commented on GitHub (Jan 22, 2026): > [@folivaud-raliance](https://github.com/folivaud-raliance) [@hakansa](https://github.com/hakansa) This is actually not a Netbird issue but how Docker and systemd-resolved interact. If you want more details please dig into it - there are some docs describing dns inheritance in Docker. As a quick fix I can recommend you: > > * edit `/etc/systemd/resolved.conf` and add `DNSStubListenerExtra=172.17.0.1` - make sure to use your docker0 ip addr > > * restart systemd-resolved `service systemd-resolved restart` > > * add `{ "dns": ["172.17.0.1"] }` to your `/etc/docker/daemon.json` > > * restart docker service `service docker restart` > > > Simple as that, containers will now use your host dns resolver. This solution does not seem to work, perhaps due to changes in local resolver config with more recent netbird versions. I am not able to access DNS at all from any docker container on linux systems with systemd-resolve. I have verified that the host ip is reachable in the container and that cloudflare dns does work (1.1.1.1). I have also tried the ports 53, 5353, and 22053 to no avail. The only current fixes I can get working are: 1. disabling netbird from the host (not great) 2. host networking (even worse) 3. explicitly specifying a dns server when starting the container
saavagebueno commented 2026-08-05 00:58:02 -04:00
Author
Owner
Copy Link

@jfrconley commented on GitHub (Mar 12, 2026):

I was able to fix this by adding a rule to ufw that allows traffic from the docker bridge on port 53

sudo ufw allow in on docker0 to 172.17.0.1 port 53

<!-- gh-comment-id:4049556133 --> @jfrconley commented on GitHub (Mar 12, 2026): I was able to fix this by adding a rule to ufw that allows traffic from the docker bridge on port 53 ` sudo ufw allow in on docker0 to 172.17.0.1 port 53`
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2021 Q4
2021 Q4
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
accessibility
accessibility
accessibility
acl
acl
acl
agent
agent
agent
agent
agent
agent
Android
Android
Android
Android
Android
Android
api
api
api
authentik
authentik
authentik
automation
automation
automation
azure
azure
azure
battery-usage
battery-usage
battery-usage
bug
cache
cache
cache
client
client
client
client-ui
client-ui
client-ui
cloud
cloud
cloud
cloud-only
cloud-only
cloud-only
cloudflare
cloudflare
cloudflare
community
community
community
compatibility
compatibility
compatibility
config-idp
config-idp
config-idp
config-issue
config-issue
config-issue
connection
connection
connection
contribution
contribution
contribution
coturn
coturn
coturn
cross-vpn
cross-vpn
cross-vpn
dashboard
dashboard
dashboard
data-usage
data-usage
data-usage
distribution
distribution
distribution
dns
dns
dns
docker
docker
docker
documentation
documentation
documentation
duplicate
duplicate
duplicate
enhancement
enhancement
event-stream
event-stream
event-stream
feature-request
feature-request
feature-request
freebsd
freebsd
freebsd
getting-started
getting-started
getting-started
go
go
go
good first issue
good first issue
good first issue
gui
gui
gui
help wanted
help wanted
help wanted
home-assistant
home-assistant
home-assistant
idp
idp
idp
inconsistency
inconsistency
inconsistency
integration
integration
integration
integrations
integrations
integrations
ios
ios
ios
ipv6
ipv6
ipv6
jwt
jwt
jwt
k8s
k8s
k8s
keycloak
keycloak
keycloak
linux
linux
linux
login
login
login
macos
macos
macos
management-service
management-service
management-service
Medium
Medium
Medium
missing-docs
missing-docs
missing-docs
mobile
mobile
mobile
moved-internal
moved-internal
moved-internal
needs-review
needs-review
needs-review
netbird-ui
netbird-ui
netbird-ui
networking
networking
networking
new-platform
new-platform
new-platform
nginx
nginx
nginx
notification
notification
notification
okta
okta
okta
openwrt
openwrt
openwrt
P2
P2
P2
packaging
packaging
packaging
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
performance
performance
performance
postgres
postgres
postgres
posture-checks
posture-checks
posture-checks
psk
psk
psk
pull-request
Mirrored from GitHub Pull Request
 question
question
question
refactor
refactor
refactor
relay
relay
relay
release
release
release
rfc
rfc
rfc
routes
routes
routes
security
security
security
security-improvement
security-improvement
security-improvement
security-related
security-related
security-related
self-hosting
self-hosting
self-hosting
server
server
server
signal
signal
signal
sleep-issue
sleep-issue
sleep-issue
ssh
ssh
ssh
ssl
ssl
ssl
status
status
status
store
store
store
synology
synology
synology
system-compatibility-issue
system-compatibility-issue
system-compatibility-issue
test-suite
test-suite
test-suite
third-party-integration
third-party-integration
third-party-integration
triage
triage
triage
triage
triage
triage
triage-needed
triage-needed
triage-needed
troubleshooting
troubleshooting
troubleshooting
UX
UX
UX
waiting-feedback
waiting-feedback
waiting-feedback
windows
windows
windows
wontfix
wontfix
wontfix
zitadel
zitadel
zitadel
No Label triage-needed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dynr-servers saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#4497
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?