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

[SELF-HOSTED] Wrong public IP for client on a VPS #872

New Issue
Open
opened 2025-11-20 05:19:00 -05:00 by saavagebueno · 13 comments
saavagebueno commented 2025-11-20 05:19:00 -05:00
Owner
Copy Link

Originally created by @kalwadi on GitHub (May 11, 2024).

Describe the problem

NetBird Client (Debian 12 server hosted on Hetzner) shows wrong IP as Public IP. 172.21.0.1 is shown as Public IP
Wrong IP is sometimes shown with docker client as well

To Reproduce

Steps to reproduce the behavior:

  1. Create VPS on Hetzner (debian 12)
  2. Install native netbird client
  3. Join network
  4. Assigned Public IP is 172.21.0.1

Expected behavior

Actual Public IP is shown

Are you using NetBird Cloud?

No, Self-host NetBird

NetBird version

0.27.5

Additional context
https://github.com/netbirdio/netbird/issues/1728#issuecomment-2105639940

My controller is running on Hetzner VPS (arm CPU)
DNS record for subdomain is directly pointed to this IP
Authentik is used for authentication

Running NetBird client on Debian 12 VM (in Proxmox) at home shows correct public IP

On a clean VPS (no docker installed) I have tried running native client and wrong IP was showing

After that I installed docker and created container with this docker-compose.yml file, correct IP was showing in dashboard

volumes:
 netbird-client:

services:
  netbird:
    image: netbirdio/netbird:latest
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
      - SYS_RESOURCE
    environment:
      - NB_SETUP_KEY=xxxx
      - NB_MANAGEMENT_URL=https://netbird.my-domain.tld:33073
    volumes:
      - netbird-client:/etc/netbird
    restart: always

Some findings after a bit of testing:

  • New VPS (tried in 3 different Hetzner locations) 2x ARM CPU, 1x x86 CPU

    • Native client shows 172.21.0.1 as public IP
    • docker client with above shown docker-compose.yml shows correct IP

  • VPS where I run my NetBird controller shows wrong IP with native client and docker client

    • only thing running on this VPS is the controller (and broken netbird client)
    • this VPS was created for this and no other things were setup on this before
Originally created by @kalwadi on GitHub (May 11, 2024). **Describe the problem** NetBird Client (Debian 12 server hosted on Hetzner) shows wrong IP as Public IP. `172.21.0.1` is shown as Public IP Wrong IP is sometimes shown with docker client as well **To Reproduce** Steps to reproduce the behavior: 1. Create VPS on Hetzner (debian 12) 2. Install native netbird client 3. Join network 4. Assigned Public IP is 172.21.0.1 **Expected behavior** Actual Public IP is shown **Are you using NetBird Cloud?** No, Self-host NetBird **NetBird version** `0.27.5` **Additional context** https://github.com/netbirdio/netbird/issues/1728#issuecomment-2105639940 My controller is running on Hetzner VPS (arm CPU) DNS record for subdomain is directly pointed to this IP Authentik is used for authentication Running NetBird client on Debian 12 VM (in Proxmox) at home shows correct public IP On a clean VPS (no docker installed) I have tried running native client and wrong IP was showing After that I installed docker and created container with this `docker-compose.yml` file, correct IP was showing in dashboard ```yml volumes: netbird-client: services: netbird: image: netbirdio/netbird:latest cap_add: - NET_ADMIN - SYS_ADMIN - SYS_RESOURCE environment: - NB_SETUP_KEY=xxxx - NB_MANAGEMENT_URL=https://netbird.my-domain.tld:33073 volumes: - netbird-client:/etc/netbird restart: always ``` Some findings after a bit of testing: - New VPS (tried in 3 different Hetzner locations) 2x ARM CPU, 1x x86 CPU - Native client shows `172.21.0.1` as public IP - docker client with above shown `docker-compose.yml` shows correct IP - VPS where I run my NetBird controller shows wrong IP with native client and docker client - only thing running on this VPS is the controller (and broken netbird client) - this VPS was created for this and no other things were setup on this before
saavagebueno added the self-hosting label 2025-11-20 05:19:00 -05:00
saavagebueno commented 2025-11-20 05:19:01 -05:00
Author
Owner
Copy Link

@nuterum commented on GitHub (May 12, 2024):

To make sure we speak of the same thing i will describe what i understand and explain what happen.

If i understand correctly you have install netbird client on the same server as netbird server (self-hosted).
In my case it what i have done.

Then in this case you find a strange IP (in fact local IP) in your netbird peer.

It is not really a bug in itself but a problem with the understanding of public IP.
The "Public IP" show in the peer is the IP that is use to join the server in the IP header when connecting.

Normally you will pass by internet that why the "Public IP" is correct but in case of local machine or even local network because you can use netbird in local network too then the IP on the IP header will be a local one and will not have been change by a NAT.

That why in my case my server having netbird client show a public IP of "172.19.0.1".
The only downside is that without going to change the "location_country_code text,location_city_name text,location_geo_name_id integer" manually in the sqlite db then my peer will be unknow for region.

The only thing not test for now is another netbird client on another VPS of the same provider.

To test further i may need the configuration of your netbird server because depending on how its configure and how the provider handle VPS maybe the VPS exchange packet without going on internet but by local network of the provider (even if in different location it can be connect together by virtual network) and in this case it will depend of the configuration of your server but i guess your self-hosted netbird is a docker using the network 172.21.0.0/16 and the server have an interface "br-XXXXX" with ip "172.21.0.1/16" and local network NAT the source IP to 172.21.0.1.

You can at least check what ip is resolve for "netbird.my-domain.tld" on your different VPS with or without docker before posting your configuration.

If my guess is right docker may not use the DNS of the provider and find the public IP of "netbird.my-domain.tld" then pass by internet and without docker we use the provider DNS that answer a local IP for "netbird.my-domain.tld".

But to realize this test i need your server configuration and to know if you domain is register on Hetzner or not to be able to reproduce the same environement.

@nuterum commented on GitHub (May 12, 2024): To make sure we speak of the same thing i will describe what i understand and explain what happen. If i understand correctly you have install netbird client on the same server as netbird server (self-hosted). In my case it what i have done. Then in this case you find a strange IP (in fact local IP) in your netbird peer. It is not really a bug in itself but a problem with the understanding of public IP. The "Public IP" show in the peer is the IP that is use to join the server in the IP header when connecting. Normally you will pass by internet that why the "Public IP" is correct but in case of local machine or even local network because you can use netbird in local network too then the IP on the IP header will be a local one and will not have been change by a NAT. That why in my case my server having netbird client show a public IP of "172.19.0.1". The only downside is that without going to change the "`location_country_code` text,`location_city_name` text,`location_geo_name_id` integer" manually in the sqlite db then my peer will be unknow for region. The only thing not test for now is another netbird client on another VPS of the same provider. To test further i may need the configuration of your netbird server because depending on how its configure and how the provider handle VPS maybe the VPS exchange packet without going on internet but by local network of the provider (even if in different location it can be connect together by virtual network) and in this case it will depend of the configuration of your server but i guess your self-hosted netbird is a docker using the network 172.21.0.0/16 and the server have an interface "br-XXXXX" with ip "172.21.0.1/16" and local network NAT the source IP to 172.21.0.1. You can at least check what ip is resolve for "netbird.my-domain.tld" on your different VPS with or without docker before posting your configuration. If my guess is right docker may not use the DNS of the provider and find the public IP of "netbird.my-domain.tld" then pass by internet and without docker we use the provider DNS that answer a local IP for "netbird.my-domain.tld". But to realize this test i need your server configuration and to know if you domain is register on Hetzner or not to be able to reproduce the same environement.
saavagebueno commented 2025-11-20 05:19:01 -05:00
Author
Owner
Copy Link

@xrehpicx commented on GitHub (May 22, 2024):

Is there any way i can manually set the peer public IP, or whatever ip i want the peer to advertise as it's public IP

@xrehpicx commented on GitHub (May 22, 2024): Is there any way i can manually set the peer public IP, or whatever ip i want the peer to advertise as it's public IP
saavagebueno commented 2025-11-20 05:19:01 -05:00
Author
Owner
Copy Link

@remogeissbuehler commented on GitHub (May 25, 2024):

I had a smilar issue where some of my clients showed up as having the docker gateway IP (172.17.0.1 in this example) as their public IP (cf. #1728). I looked at the Caddy logs and saw that the X-Forwarded-For Headers were also set to this IP (172.17.0.1).

I checked the upstream caddy issues and this appears to occur when clients connect via IPv6 (see this issue: https://github.com/caddyserver/caddy/issues/4339). This happens since docker containers by default don't communicate over IPv6, so the docker gateway "NATs" these connections which then have the gateway address as a source.

I added IPv6 to the docker setup, by adding the following to /etc/docker/daemon.json

{
	"experimental": true,
	"ip6tables": true,
	"default-address-pools": [
		{ "base": "172.17.0.0/16", "size": 16 },
		{ "base": "172.18.0.0/16", "size": 16 },
		{ "base": "172.19.0.0/16", "size": 16 },
		{ "base": "172.20.0.0/14", "size": 16 },
		{ "base": "172.24.0.0/14", "size": 16 },
		{ "base": "172.28.0.0/14", "size": 16 },
		{ "base": "fd42:1234:5678::/48", "size": 64 }
	]
}

Note that adding address pools isn't strictly necessary, you can also set them on container creation (i.e. in the docker-compose file in this scenario). I used an IPv6 ULA, but I'm sure there's other / better ways ;)

We also need to enable IPv6 networking in the docker compose file:

networks:
  netbird:
    enable_ipv6: true

With those changes, the peers show up correctly with their IPv6 listed as the public IP.

@remogeissbuehler commented on GitHub (May 25, 2024): I had a smilar issue where some of my clients showed up as having the docker gateway IP (172.17.0.1 in this example) as their public IP (cf. #1728). I looked at the Caddy logs and saw that the X-Forwarded-For Headers were also set to this IP (172.17.0.1). I checked the upstream caddy issues and this appears to occur when clients connect via IPv6 (see this issue: https://github.com/caddyserver/caddy/issues/4339). This happens since docker containers by default don't communicate over IPv6, so the docker gateway "NATs" these connections which then have the gateway address as a source. I added IPv6 to the docker setup, by adding the following to `/etc/docker/daemon.json` ``` { "experimental": true, "ip6tables": true, "default-address-pools": [ { "base": "172.17.0.0/16", "size": 16 }, { "base": "172.18.0.0/16", "size": 16 }, { "base": "172.19.0.0/16", "size": 16 }, { "base": "172.20.0.0/14", "size": 16 }, { "base": "172.24.0.0/14", "size": 16 }, { "base": "172.28.0.0/14", "size": 16 }, { "base": "fd42:1234:5678::/48", "size": 64 } ] } ``` Note that adding address pools isn't strictly necessary, you can also set them on container creation (i.e. in the docker-compose file in this scenario). I used an IPv6 [ULA](https://en.wikipedia.org/wiki/Unique_local_address), but I'm sure there's other / better ways ;) We also need to enable IPv6 networking in the docker compose file: ``` networks: netbird: enable_ipv6: true ``` With those changes, the peers show up correctly with their IPv6 listed as the public IP.
saavagebueno commented 2025-11-20 05:19:01 -05:00
Author
Owner
Copy Link

@cipherw0lf commented on GitHub (Aug 9, 2024):

I'm having the same issue.
I used a Ubuntu 22.04 VPS and simply ran (as root) the getting-started-with-zitadel.sh script as per the self-host quickstart guide.

Relevant info:

  • Im not using IPv6
  • Im not running any clients on the server
  • ISSUE: All Public WAN addresses show the docker IP address of Caddy container instead of actual WAN address of the clients
  • I do believe the WAN address was showing correctly immediately after deployment (running script)
  • I attempted to update the server recently when v0.28.7 dropped
  • Issued commands as root:
    • docker compose down
    • docker compose pull
    • docker compose up -d
  • After this i believe issue started occurring
  • No other options were changed
  • All firewalls off

Note: the VPN is still working and connectivity doesn't seem to be affected as this point.

Caddy log snippet:

DBG ts=1723207925.2943292 logger=http.handlers.reverse_proxy msg=upstream roundtrip upstream=management:80 duration=0.072324231 request={"remote_ip":"172.18.0.1","remote_port":"33864","client_ip":"172.18.0.1","proto":"HTTP/2.0","method":"GET","host":"netbird.MYDOMAIN.net","uri":"/api/routes","headers":{"Sec-Gpc":["1"],"Authorization":["REDACTED"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Fetch-Mode":["cors"],"X-Forwarded-Host":["netbird.MYDOMAIN.net"],"X-Forwarded-For":["172.18.0.1"],"Cookie":["REDACTED"],"Sec-Ch-Ua":["\"Not)A;Brand\";v=\"99\", \"Google Chrome\";v=\"127\", \"Chromium\";v=\"127\""],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36"],"Dnt":["1"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Ch-Ua-Mobile":["?0"],"Content-Type":["application/json"],"X-Forwarded-Proto":["https"],"Priority":["u=1, i"],"Accept-Language":["en-US,en-ZA;q=0.9,en;q=0.8,th;q=0.7"],"X-Real-Ip":["172.18.0.1"],"Sec-Fetch-Dest":["empty"],"Referer":["https://netbird.MYDOMAIN.net/peers"],"Accept":["application/json"],"Sec-Fetch-Site":["same-origin"]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"netbird.MYDOMAIN.net"}} headers={"Vary":["Origin"],"Date":["Fri, 09 Aug 2024 12:52:05 GMT"],"Content-Length":["1425"],"Content-Type":["application/json; charset=UTF-8"]} status=200
@cipherw0lf commented on GitHub (Aug 9, 2024): I'm having the same issue. I used a Ubuntu 22.04 VPS and simply ran (as root) the getting-started-with-zitadel.sh script as per the self-host quickstart guide. ## Relevant info: - Im not using IPv6 - Im not running any clients on the server - ISSUE: All Public WAN addresses show the docker IP address of Caddy container instead of actual WAN address of the clients - I do believe the WAN address was showing correctly immediately after deployment (running script) - I attempted to update the server recently when v0.28.7 dropped - Issued commands as root: - `docker compose down` - `docker compose pull` - `docker compose up -d` - After this i believe issue started occurring - No other options were changed - All firewalls off Note: the VPN is still working and connectivity doesn't seem to be affected as this point. Caddy log snippet: ``` DBG ts=1723207925.2943292 logger=http.handlers.reverse_proxy msg=upstream roundtrip upstream=management:80 duration=0.072324231 request={"remote_ip":"172.18.0.1","remote_port":"33864","client_ip":"172.18.0.1","proto":"HTTP/2.0","method":"GET","host":"netbird.MYDOMAIN.net","uri":"/api/routes","headers":{"Sec-Gpc":["1"],"Authorization":["REDACTED"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Fetch-Mode":["cors"],"X-Forwarded-Host":["netbird.MYDOMAIN.net"],"X-Forwarded-For":["172.18.0.1"],"Cookie":["REDACTED"],"Sec-Ch-Ua":["\"Not)A;Brand\";v=\"99\", \"Google Chrome\";v=\"127\", \"Chromium\";v=\"127\""],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36"],"Dnt":["1"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Ch-Ua-Mobile":["?0"],"Content-Type":["application/json"],"X-Forwarded-Proto":["https"],"Priority":["u=1, i"],"Accept-Language":["en-US,en-ZA;q=0.9,en;q=0.8,th;q=0.7"],"X-Real-Ip":["172.18.0.1"],"Sec-Fetch-Dest":["empty"],"Referer":["https://netbird.MYDOMAIN.net/peers"],"Accept":["application/json"],"Sec-Fetch-Site":["same-origin"]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"netbird.MYDOMAIN.net"}} headers={"Vary":["Origin"],"Date":["Fri, 09 Aug 2024 12:52:05 GMT"],"Content-Length":["1425"],"Content-Type":["application/json; charset=UTF-8"]} status=200 ```
saavagebueno commented 2025-11-20 05:19:01 -05:00
Author
Owner
Copy Link

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

Do you still have issues with latest/relatively recent NetBird versions?

@nazarewk commented on GitHub (Apr 23, 2025): Do you still have issues with latest/relatively recent NetBird versions?
saavagebueno commented 2025-11-20 05:19:01 -05:00
Author
Owner
Copy Link

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

I don't have issues with other clients anymore, everything shows up correctly. (0.41.3)

Only client running on Netbird Server shows with local IP as PublicIP, but that is expected.

Image

@kalwadi commented on GitHub (Apr 23, 2025): I don't have issues with other clients anymore, everything shows up correctly. (0.41.3) Only client running on Netbird Server shows with local IP as PublicIP, but that is expected. ![Image](https://github.com/user-attachments/assets/6ccedd77-ea8b-422e-a6fa-ce94448821d0)
saavagebueno commented 2025-11-20 05:19:02 -05:00
Author
Owner
Copy Link

@arthur-lbchn commented on GitHub (Jul 11, 2025):

I have the similar issue on Ubuntu 24.04 LTS peers

Image 
root@wol1-manage01:~# systemctl status netbird
● netbird.service - Netbird mesh network client
     Loaded: loaded (/etc/systemd/system/netbird.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-07-11 12:46:18 BST; 2min 13s ago
   Main PID: 515388 (netbird)
      Tasks: 11 (limit: 4598)
     Memory: 29.3M (peak: 30.2M)
        CPU: 766ms
     CGroup: /system.slice/netbird.service
             └─515388 /usr/bin/netbird service run --config /etc/netbird/config.json --log-level info --daemon-addr unix:///var/run/netbird.sock --log-file /var/log/netbird/client.log

I've also wiped all iptables rules to verify it's not client related.

PS. I don't have such issue on my MacOS personal device, the public IP address is properly recognized.

@arthur-lbchn commented on GitHub (Jul 11, 2025): I have the similar issue on Ubuntu 24.04 LTS peers <img width="900" height="900" alt="Image" src="https://github.com/user-attachments/assets/622fe341-9ea2-4d46-b03b-564c25eec6ee" /> ``` root@wol1-manage01:~# systemctl status netbird ● netbird.service - Netbird mesh network client Loaded: loaded (/etc/systemd/system/netbird.service; enabled; preset: enabled) Active: active (running) since Fri 2025-07-11 12:46:18 BST; 2min 13s ago Main PID: 515388 (netbird) Tasks: 11 (limit: 4598) Memory: 29.3M (peak: 30.2M) CPU: 766ms CGroup: /system.slice/netbird.service └─515388 /usr/bin/netbird service run --config /etc/netbird/config.json --log-level info --daemon-addr unix:///var/run/netbird.sock --log-file /var/log/netbird/client.log ``` I've also wiped all iptables rules to verify it's not client related. PS. I don't have such issue on my MacOS personal device, the public IP address is properly recognized.
saavagebueno commented 2025-11-20 05:19:02 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jul 11, 2025):

Thinking about it, it kind of makes sense when the "public" IP detection never exits the local network (both client and server are on the same LAN/router). There is no reasonable way to detect the "really public" IP without a 3rd party service running on the internet.

@nazarewk commented on GitHub (Jul 11, 2025): Thinking about it, it kind of makes sense when the "public" IP detection never exits the local network (both client and server are on the same LAN/router). There is no reasonable way to detect the "really public" IP without a 3rd party service running on the internet.
saavagebueno commented 2025-11-20 05:19:02 -05:00
Author
Owner
Copy Link

@arthur-lbchn commented on GitHub (Jul 11, 2025):

@nazarewk I'm afraid both client and server are not the same router, its devices located in the different datacenters

@arthur-lbchn commented on GitHub (Jul 11, 2025): @nazarewk I'm afraid both client and server are not the same router, its devices located in the different datacenters
saavagebueno commented 2025-11-20 05:19:02 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jul 11, 2025):

I heard back from the dev team, your issue is most likely caused by a reverse proxy misconfiguration of X-Forwarded-For HTTP header forwarding and/or assembling it.

The specific line seems to be:
9fbad7dbad/management/cmd/management.go (L241-L241)
coming from go-grpc-middleware

You might also want to take a look at X-Real-IP in addition to X-Forwarded-For

@nazarewk commented on GitHub (Jul 11, 2025): I heard back from the dev team, your issue is most likely caused by a reverse proxy misconfiguration of `X-Forwarded-For` HTTP header forwarding and/or assembling it. The specific line seems to be: https://github.com/netbirdio/netbird/blob/9fbad7dbade7683a907af173546699a8ae765ac2/management/cmd/management.go#L241-L241 coming from [go-grpc-middleware](https://github.com/grpc-ecosystem/go-grpc-middleware/blob/cc754e60cb814827ec3915e8e27c9822d7856745/interceptors/realip/realip.go#L21-L25) You might also want to take a look at `X-Real-IP` in addition to `X-Forwarded-For`
saavagebueno commented 2025-11-20 05:19:02 -05:00
Author
Owner
Copy Link

@arthur-lbchn commented on GitHub (Jul 11, 2025):

I just actually followed your guide https://docs.netbird.io/selfhosted/selfhosted-quickstart, so its all coming with default settings. I'll have a look into the headers, thank you.

@arthur-lbchn commented on GitHub (Jul 11, 2025): I just actually followed your guide https://docs.netbird.io/selfhosted/selfhosted-quickstart, so its all coming with default settings. I'll have a look into the headers, thank you.
saavagebueno commented 2025-11-20 05:19:02 -05:00
Author
Owner
Copy Link

@arthur-lbchn commented on GitHub (Jul 11, 2025):

Ah, looks like Netbird doesn't really support IPv6 which has a preference over IPv4 if its set, so docker wasn't able to get real IP until added to docker-compose.yml and recreated all containers:

networks:
  netbird:
    enable_ipv6: true

I hope IPv6 support is something on your to-do list. Thank you again!

@arthur-lbchn commented on GitHub (Jul 11, 2025): Ah, looks like Netbird doesn't really support IPv6 which has a preference over IPv4 if its set, so docker wasn't able to get real IP until added to docker-compose.yml and recreated all containers: ``` networks: netbird: enable_ipv6: true ``` I hope IPv6 support is something on your to-do list. Thank you again!
saavagebueno commented 2025-11-20 05:19:03 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jul 11, 2025):

NetBird isn't "officially" supporting external IPv6 (as opposed to internal NetBird IP range, which it officially does not support yet, see #46), but it seems to work just fine for most people in most settings they come up with.

With Could I'm connecting my dual-stack home network to dual-stack Hetzner VPN just fine, it's reporting IPv6 public IPs in the Dashboard and currently establishing P2P over IPv4 (I'm pretty sure it does occasionally establish v6 connectivity over my local ULA range and public IPs):

Image 
 moss.netbird.cloud:
  NetBird IP: 100.79.63.47
  Public key: TWq...CdNX1lU=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): srflx/prflx
  ICE candidate endpoints (Local/Remote): 94.000.000.123:7251/195.000.000.123:51819
  Relay server address: rels://streamline-de-fra1-1.relay.netbird.io:443
  Last connection update: 3 hours, 39 minutes ago
  Last WireGuard handshake: 10 seconds ago
  Transfer status (received/sent) 33.2 KiB/50.4 KiB
  Quantum resistance: false
  Networks: -
  Latency: 38.263351ms

I guess you have found the first not fully supported external IPv6 use case: running IPv6-based self-hosted management.

Thanks for the debugging effort so far. I would be eager to hear in case you got it fully working to update the deployment docs for v6.

@nazarewk commented on GitHub (Jul 11, 2025): NetBird isn't "officially" supporting external IPv6 (as opposed to internal NetBird IP range, which it officially does not support yet, see #46), but it seems to work just fine for most people in most settings they come up with. With Could I'm connecting my dual-stack home network to dual-stack Hetzner VPN just fine, it's reporting IPv6 public IPs in the Dashboard and currently establishing P2P over IPv4 (I'm pretty sure it does occasionally establish v6 connectivity over my local ULA range and public IPs): <img width="1409" height="757" alt="Image" src="https://github.com/user-attachments/assets/dfa74753-301f-4e3b-9f26-5c201858647e" /> ```text moss.netbird.cloud: NetBird IP: 100.79.63.47 Public key: TWq...CdNX1lU= Status: Connected -- detail -- Connection type: P2P ICE candidate (Local/Remote): srflx/prflx ICE candidate endpoints (Local/Remote): 94.000.000.123:7251/195.000.000.123:51819 Relay server address: rels://streamline-de-fra1-1.relay.netbird.io:443 Last connection update: 3 hours, 39 minutes ago Last WireGuard handshake: 10 seconds ago Transfer status (received/sent) 33.2 KiB/50.4 KiB Quantum resistance: false Networks: - Latency: 38.263351ms ``` I guess you have found the first not fully supported external IPv6 use case: running IPv6-based self-hosted management. Thanks for the debugging effort so far. I would be eager to hear in case you got it fully working to update the deployment docs for v6.
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 self-hosting
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#872
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?