惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
爱范儿
爱范儿
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 三生石上(FineUI控件)
大猫的无限游戏
大猫的无限游戏
Hugging Face - Blog
Hugging Face - Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Vercel News
Vercel News
人人都是产品经理
人人都是产品经理
G
Google Developers Blog
WordPress大学
WordPress大学
S
SegmentFault 最新的问题
雷峰网
雷峰网
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Jina AI
Jina AI
博客园 - 叶小钗
D
DataBreaches.Net
D
Docker
月光博客
月光博客
博客园 - 司徒正美
Last Week in AI
Last Week in AI
有赞技术团队
有赞技术团队
腾讯CDC
酷 壳 – CoolShell
酷 壳 – CoolShell

NetBird - Networking Knowledge Hub - RSS Feed

NetBird Is Now on the Vultr Marketplace Native NetBird on the GL.iNet Comet Pro (GL-RM10) NetBird Exit Nodes - Appear at Home, or Anywhere Else Reporting Bugs and Requesting Features in NetBird Setup and Use Local AdGuard Home Anywhere with NetBird DNS How to Set Up NetBird on PiKVM for Secure Remote KVM Access NetBird v0.69 - CrowdSec IP Reputation for the Reverse Proxy Cloudflare Mesh vs NetBird vs Tailscale: Performance Compared Self-Hosting Nextcloud with Docker and NetBird Implementing Zero Trust with NetBird NetBird v0.67 - Layer 4 Proxy Support for TCP, UDP, and TLS Solwr Enhances Remote Connectivity with NetBird Self-Hosting NetBird with Authentik Jellyfin Media Server - Self-Host Your Movies, TV, and Music Cloudflare Tunnels vs. NetBird Reverse Proxy INFITX Builds Zero-Touch Kubernetes Networking with NetBird NetBird v0.66 - Expose Local Services to the Internet from the CLI Pangolin vs. NetBird Home Assistant Setup Guide with EASY Remote Access NetBird v0.65 - Built-in Reverse Proxy with Custom Domains Docker for Beginners - Everything You Need to Get Started NetBird for SOC 2 Compliance NetBird v0.63 - Custom DNS Zones for Private Network Resolution Vibecode This in a Weekend and Take 5% of the Company NetBird v0.62 - Built-in Local Users with Optional IdP Integration NetBird v0.61.0 - Granular SSH Access Control and Automatic Updates Top 5 Alternatives to OpenVPN Top 5 Open Source Alternatives to Tailscale Top 5 Alternatives to ZeroTier How to Set Up ZeroByte and REST Server for Backups with NetBird
NetBird v0.71 - IPv6 Overlay Addressing
Written byBrandon Hopkins · 2026-05-14 · via NetBird - Networking Knowledge Hub - RSS Feed

NetBird's overlay has been IPv4-only since day one. Every peer got an address from , every ACL was an IPv4 ACL, every network route a v4 CIDR. That covered the vast majority of use cases, but it also meant IPv6-only services on the backend side, modern home networks that prefer v6, and dual-stack clouds had to be reached through v4 plumbing.

v0.71 changes that. The overlay is now dual-stack. Each account gets a unique IPv6 prefix, peers can receive both an IPv4 and an IPv6 overlay address, and the rest of the system, DNS, firewall rules, exit nodes, network routes, domain routes, follows along.

NetBird v0.71 IPv6 release

A Per-Account IPv6 Prefix

Every account on v0.71 gets its own IPv6 range alongside the existing IPv4 one. The default is a , which is plenty for any realistic peer count, but you can configure anything from down to if you have a reason to.

IPv4-only overlay compared to the new dual-stack overlay

The prefix is account-scoped, so two different accounts in the same management server have non-overlapping IPv6 space. This matches how IPv4 overlay addressing already worked and means cross-account routing scenarios behave the same regardless of address family.

One peer receiving both an IPv4 and an IPv6 overlay address

Group-Gated Rollout

IPv6 doesn't get force-fed to everyone the moment you upgrade. New accounts have IPv6 enabled for the All group by default, so a fresh install lights it up everywhere. Existing accounts opt in by selecting which groups should receive IPv6 addresses under Settings > Network.

IPv6 network settings in the dashboard

Only peers that belong to at least one selected group get an IPv6 address. Everyone else stays v4-only. This gives you a way to roll IPv6 out to a pilot group, validate things look right, then widen the scope, instead of flipping the whole network at once.

Assignment is also gated on a per-peer capability. The v0.71 client advertises IPv6 support to management on connect; older agents don't, so management skips IPv6 assignment for them even if their group is selected. Upgrade the client and the peer picks up an address on the next reconnect, no manual reassignment required.

Capability is platform-wide: the WireGuard interface picks up the v6 overlay address on Linux (both kernel and userspace WireGuard), macOS, Windows, iOS, Android, FreeBSD, and the netstack/userspace path used for sandboxed environments. There's no platform-specific cutout where v6 is silently disabled.

DNS, ACLs, and Routes Follow Along

The point of doing this properly is that IPv6 isn't a feature flag bolted onto one corner of the product. Once a peer has an IPv6 address, the rest of NetBird treats it the same way it treats IPv4:

  • DNS serves AAAA records alongside A records from the same NetBird zone, so resolves to both. Reverse DNS works too: PTR records are served from the standard nibble zone alongside the existing , so reverse lookups on overlay v6 addresses return the right peer name in logs and tooling.
  • ACLs apply to both address families. On nftables hosts the client runs a parallel table alongside the v4 one, with its own router and ACL manager; on iptables hosts the equivalent dispatch happens through with -suffixed ipsets to avoid colliding with v4 sets in the global ipset namespace. Either way, management generates the matching rules for v6 whenever a peer has an IPv6 address.
  • Network routes accept IPv6 CIDRs the same way as IPv4 subnets, including masquerade. A routing peer with masquerade enabled SNATs IPv6 egress traffic to its backend-side address, mirroring the v4 behavior.
  • Exit nodes that route automatically get a matching route when the peer supports IPv6, so a "send all traffic" exit node actually sends all traffic instead of leaking v6 around the tunnel.
  • Domain routes resolve both A and AAAA records, so v4-only and v6-only domains both route through the tunnel.

The headline value here is mostly that nothing about your existing policies needs to change. If you already have a group-based ACL letting reach , that policy now applies to v6 traffic too, automatically.

Peer detail page showing both IPv4 and IPv6 overlay addresses

Per-Client Opt-Out

Some hosts have reasons to stay off IPv6, single-stack environments, compliance constraints, or just buggy upstream IPv6 support that you'd rather sidestep. v0.71 ships a flag on the client:


When set, the client doesn't request an IPv6 address, doesn't advertise IPv6 support to management, and won't accept inbound IPv6 traffic from remote peers. The same toggle is available in the desktop UI under Settings > Disable IPv6 and in the iOS and Android apps under Advanced Settings.

CLI Status

now shows the IPv6 address when one is assigned:


If you only want the v6 address, for instance to feed it into a script, there's a flag for that:


NetBird client status showing IPv6 address and exit-node usage

A Note on Routability

NetBird's IPv6 prefixes are overlay addresses, not publicly routable. They work the same way as the existing IPv4 range: reachable inside the NetBird network, not announced to the public internet. If you want a peer to be reachable on the public IPv6 internet, that's still a job for whatever public addressing your host already has, the overlay isn't a replacement for that.

Routing Peers in Containers

One thing worth flagging if you run a routing peer inside a container: NetBird tries to set on startup, but in unprivileged containers or locked-down Kubernetes pods that sysctl is read-only, the write fails silently, and IPv6 forwarding stays off.

Set it at the orchestrator layer instead:



If a routing peer has an IPv6 address but traffic isn't reaching the backend, this is the first thing to check.

Under the Hood

A few details that came out of building this that are worth knowing about:

  • A new abstraction encapsulates header offsets, address lengths, ICMP protocol numbers, and nftables set key types, so packet-handling code in routing, conntrack, NAT/DNAT, the userspace TUN, and netstack stays family-agnostic.
  • MSS clamping uses the correct per-family overhead (40 bytes for v4, 60 for v6), so v6 traffic doesn't get its segments sized as if they were v4.
  • The SSH server listens on both the v4 and v6 overlay addresses, with the same DNAT redirection on each, and host matching resolves by v6 too. So and both land in the right place. The browser-based SSH client in the dashboard works over v6 as well.
  • Netflow / traffic-event logging tracks v6 flows, including ICMPv6 (proto 58), and uses both overlay networks when inferring flow direction. If you're using events for visibility or audit, v6 traffic now shows up alongside v4 instead of going dark.
  • The userspace packet filter (the path used on all non-Linux platforms) is dual-stack as well, with ICMPv6 conntrack, cross-family ICMP rule matching, IPv6 fragment detection, and a separate DNAT rewrite path for v6 (which has no header checksum to update). In practice, that's what makes plain things like between two peers work the same way always has.

API

Two new fields on the account settings, one new field on peers:

  • Account settings: (list of group IDs) and (CIDR string)
  • Peer: (read-only, the assigned address)

See the API reference for details.

Also in v0.71

IPv6 is the headline, but a few other things landed in this release worth calling out.

Bring your own proxy (backend ready). Management now supports a full per-account reverse-proxy lifecycle: proxy tokens you can create, list, and revoke, per-account cluster allow-lists, conflict detection, and one-proxy-per-account enforcement. Self-hosted deployments can already wire a proxy in through global tokens; BYOP is the GUI-driven path that works the same way on both Cloud and self-hosted, so accounts can register their own reverse proxy and route their services through it. The backend is in v0.71, but the dashboard UI is still being polished and will land in a near-future release. Background reading: Bring Your Own Proxy documentation .

MFA for local users. If you don't federate auth through an external IdP, local users can now enable multi-factor authentication directly in NetBird. This closes a long-standing gap for self-hosted deployments that don't run an external provider in front of the dashboard.

Client and management improvements. A handful of smaller items worth scanning if you operate NetBird at scale:

  • Debug bundles now include MTU, SSH auth config, and the peer's public key, which makes support tickets a lot easier to triage.
  • The userspace packet filter's conntrack and shared TCP relay paths were hardened.
  • DNS upstream failover now skips on a definitive EDE response instead of retrying into the wrong upstream.
  • defaults to the active profile path, so the flag does what you'd expect when you've got multiple profiles configured.
  • IPv6 reverse-proxy target hosts get bracketed when building URL Host fields, fixing a class of parse errors for v6 backends.
  • Embedded proxy peers now get IPv6 overlay addresses allocated and preserved like any other peer.
  • picked up short flags for its options.

Learn More and Connect