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

Docker routing peers #1059

New Issue
Open
opened 2025-11-20 05:23:15 -05:00 by saavagebueno · 5 comments
saavagebueno commented 2025-11-20 05:23:15 -05:00
Owner
Copy Link

Originally created by @chris-si on GitHub (Jul 12, 2024).

I have a netbird client (container) deployed in a docker network to access the services from this specific docker network. To access these services, I manually assigned a network to the docker network, static ip addresses to every container and set a network route to the appropriate routing peer. With this setup I can reach every container via its ip address.

I have a second (managed) docker network in which I cannot manually assign a network and ip addresses for different reasons. But every container can reach every other container via the defined name of the service (via default docker network communication).
If I'm not mistaken, at the moment there is no viable way to access other containers in the same docker network where the netbird container is running in.

The netbird ssh server is not a viable option to e.g. proxy requests, since the application which tries to access the containers can't use ssh clients.

For this case it would be great if there would be a new network route type option. This new option would allow setting new routes via e.g. a custom name or directly the container name, so the netbird docker container would route to the appropriate container in the docker network.

Example:

There are three containers (including the netbird client) with the following names in a docker network on a remote server:

  • containerA
  • containerB
  • netbird-client (which is also the netbird client peer name)

Now I'd like to be able to define a new route via the dashboard that either

  • just says containerA is reachable via the routing peer client netbird-client
    • if I e.g. do ping containerA from another device connected to the netbird network, netbird-client should route the requests via the docker network to containerA
    • since e.g. the current domain routing peer type option requires a TLD it can't be used to reflect just container/service names
  • or define some kind of CNAME record or additonal device names (like the netbird client names) that allows to map a custom name or domain to a container/service name and route the requests accordingly
    • e.g.
      • myContainer → containerA
      • my-custom.domain.tld → containerA
Originally created by @chris-si on GitHub (Jul 12, 2024). I have a netbird client (container) deployed in a docker network to access the services from this specific docker network. To access these services, I manually assigned a network to the docker network, static ip addresses to every container and set a network route to the appropriate routing peer. With this setup I can reach every container via its ip address. I have a second (managed) docker network in which I cannot manually assign a network and ip addresses for different reasons. But every container can reach every other container via the defined name of the service (via default docker network communication). If I'm not mistaken, at the moment there is no viable way to access other containers in the same docker network where the netbird container is running in. The netbird ssh server is not a viable option to e.g. proxy requests, since the application which tries to access the containers can't use ssh clients. For this case it would be great if there would be a new network route type option. This new option would allow setting new routes via e.g. a custom name or directly the container name, so the netbird docker container would route to the appropriate container in the docker network. --- Example: There are three containers (including the netbird client) with the following names in a docker network on a remote server: - `containerA` - `containerB` - `netbird-client` (which is also the netbird client peer name) Now I'd like to be able to define a new route via the dashboard that either - just says `containerA` is reachable via the routing peer client `netbird-client` - if I e.g. do `ping containerA` from another device connected to the netbird network, `netbird-client` should route the requests via the docker network to `containerA` - since e.g. the current `domain` routing peer type option requires a TLD it can't be used to reflect just container/service names - or define some kind of CNAME record or additonal device names (like the netbird client names) that allows to map a custom name or domain to a container/service name and route the requests accordingly - e.g. - `myContainer` → `containerA` - `my-custom.domain.tld` → `containerA`
saavagebueno added the feature-request label 2025-11-20 05:23:15 -05:00
saavagebueno commented 2025-11-20 05:23:16 -05:00
Author
Owner
Copy Link

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

@chris-si this might be covered by the new Networks feature when specifying domains for the specific Resources?

@nazarewk commented on GitHub (Apr 23, 2025): @chris-si this might be covered by the new Networks feature when specifying domains for the specific Resources?
saavagebueno commented 2025-11-20 05:23:16 -05:00
Author
Owner
Copy Link

@soleuniverse101 commented on GitHub (May 7, 2025):

@chris-si this might be covered by the new Networks feature when specifying domains for the specific Resources?

I'm running into a similar issue and I currently can't route traffic for a specific domain to the client inside Docker because domain names must be valid (e.g. example.com), they can't be only the target container's name

@soleuniverse101 commented on GitHub (May 7, 2025): > [@chris-si](https://github.com/chris-si) this might be covered by the new Networks feature when specifying domains for the specific Resources? I'm running into a similar issue and I currently can't route traffic for a specific domain to the client inside Docker because domain names must be valid (e.g. example.com), they can't be only the target container's name
saavagebueno commented 2025-11-20 05:23:16 -05:00
Author
Owner
Copy Link

@davide-acanfora commented on GitHub (Nov 11, 2025):

Here's how I currently solved this for my setup, where I need to expose a Postgres container via the NetBird client container.

First, I added both containers to the same network called postgres. Then I added an alias for the Postgres container for that network, so that the NetBird container can always contact it via the hostname database.internal.mydomain.com, regardless of its IP address. Here is my (simplified) docker-compose.yml:

services:
  database:
    container_name: database
    image: postgres:18.0-alpine3.21
    networks:
      postgres:
        aliases:
          - database.internal.mydomain.com <-- additional hostname in the 'postgres' network

  netbird-client:
    container_name: netbird-client
    image: netbirdio/netbird:latest
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
      - SYS_RESOURCE
    environment:
      - NB_MANAGEMENT_URL=https://netbird.mydomain.com
      - NB_SETUP_KEY=...
    volumes:
      - ./netbird-data:/var/lib/netbird
    networks:
      - postgres

networks:
  postgres:
    external: true

Finally, I used the Networks feature, where I declared a network called Internal containing a resource called Database at the address database.internal.mydomain.com, accessible through the NetBird client container:

Image

Note that if the DNS domain of your NetBird network is, for example, netbird.mydomain.com, you may encounter issues if you declare your resources as database.netbird.mydomain.com (instead of database.something.else), as peers will be unable to resolve that domain. I assume this occurs because peers believe that the resource is another peer as well, since it shares the same DNS domain in its hostname.

That's why I came up with the prefix internal to add to my domain to access the resources. To be honest, the alias in docker-compose could have been anything, even just database.internal. But if I had used it for a web service and entered it as a URL in the browser, something like my-web-app.internal would not be immediately recognized as such without adding the HTTP protocol in front of it. However, with the FQDN my-web-app.internal.mydomain.com, it would be

@davide-acanfora commented on GitHub (Nov 11, 2025): Here's how I currently solved this for my setup, where I need to expose a Postgres container via the NetBird client container. First, I added both containers to the same network called `postgres`. Then I added an **alias** for the Postgres container for that network, so that the NetBird container can always contact it via the hostname `database.internal.mydomain.com`, regardless of its IP address. Here is my (simplified) `docker-compose.yml`: ```yaml services: database: container_name: database image: postgres:18.0-alpine3.21 networks: postgres: aliases: - database.internal.mydomain.com <-- additional hostname in the 'postgres' network netbird-client: container_name: netbird-client image: netbirdio/netbird:latest cap_add: - NET_ADMIN - SYS_ADMIN - SYS_RESOURCE environment: - NB_MANAGEMENT_URL=https://netbird.mydomain.com - NB_SETUP_KEY=... volumes: - ./netbird-data:/var/lib/netbird networks: - postgres networks: postgres: external: true ``` Finally, I used the **Networks** feature, where I declared a network called `Internal` containing a resource called `Database` at the address `database.internal.mydomain.com`, accessible through the NetBird client container: <img width="1246" height="873" alt="Image" src="https://github.com/user-attachments/assets/09694def-2d12-4b0a-b52a-619f05abb327" /> Note that if the **DNS domain** of your NetBird network is, for example, `netbird.mydomain.com`, you may encounter issues if you declare your resources as `database.netbird.mydomain.com` (instead of `database.something.else`), as peers will be unable to resolve that domain. I assume this occurs because peers believe that the resource is another peer as well, since it shares the same DNS domain in its hostname. That's why I came up with the prefix `internal` to add to my domain to access the resources. To be honest, the alias in docker-compose could have been anything, even just `database.internal`. But if I had used it for a web service and entered it as a URL in the browser, something like `my-web-app.internal` would not be immediately recognized as such without adding the HTTP protocol in front of it. However, with the FQDN `my-web-app.internal.mydomain.com`, it would be
saavagebueno commented 2025-11-20 05:23:16 -05:00
Author
Owner
Copy Link

@ddesmond commented on GitHub (Nov 12, 2025):

For some strange reasons I have mixed results with similar setup. I cant exactly pinpoint what is wrong. I may need some directions if unable to debug this.

@ddesmond commented on GitHub (Nov 12, 2025): For some strange reasons I have mixed results with similar setup. I cant exactly pinpoint what is wrong. I may need some directions if unable to debug this.
saavagebueno commented 2025-11-20 05:23:16 -05:00
Author
Owner
Copy Link

@davide-acanfora commented on GitHub (Nov 13, 2025):

For some strange reasons I have mixed results with similar setup. I cant exactly pinpoint what is wrong. I may need some directions if unable to debug this.

I don't know if you have the same problem, but one thing I've noticed with resources is that in my case if I try to contact database.internal.mydomain.com immediately after connecting to NetBird, I'm likely to get an “Unknown Host” error. Probably I do it so quickly that I don't give the Docker NetBird client time to announce its routes to my peer.

The worst thing is that the unknown host is saved in the cache, and even after waiting several seconds, I continue to receive the same error. The quickest solution in these cases is to clear the DNS cache.

On the contrary, if I wait 3 to 5 seconds after connecting to NetBird, when I try to contact the same resource, its hostname is resolved correctly on the first attempt.

@davide-acanfora commented on GitHub (Nov 13, 2025): > For some strange reasons I have mixed results with similar setup. I cant exactly pinpoint what is wrong. I may need some directions if unable to debug this. I don't know if you have the same problem, but one thing I've noticed with resources is that in my case if I try to contact `database.internal.mydomain.com` immediately after connecting to NetBird, I'm likely to get an “Unknown Host” error. Probably I do it so quickly that I don't give the Docker NetBird client time to announce its routes to my peer. The worst thing is that the unknown host is saved in the cache, and even after waiting several seconds, I continue to receive the same error. The quickest solution in these cases is to clear the DNS cache. On the contrary, if I wait 3 to 5 seconds after connecting to NetBird, when I try to contact the same resource, its hostname is resolved correctly on the first attempt.
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 feature-request
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#1059
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?