Networks

NetBird creates a secure peer-to-peer mesh network where devices running the NetBird agent connect directly with end-to-end encryption. This enables precise network segmentation and secure remote access without exposing resources to the internet.

However, installing the agent on every machine is not always feasible. Networks solve this by letting you route traffic to entire LANs, office networks, or cloud VPCs without requiring the NetBird agent on each device.

high-level-dia

Networks vs. Network Routes

Networks is the newer, simpler replacement for Network Routes. We encourage you to use Networks where possible; however, Networks do not yet support all remote access scenarios. Network Routes will continue to be actively maintained, so use whichever fits your use case.

For a detailed comparison, see our site-to-site documentation.

Concepts

Networks

A Network is a configuration container that maps your on-premise or cloud infrastructure into a logical set of resources and routing peers. You can create multiple networks to represent different environments such as office networks, cloud VPCs, or data center LANs.

high-level-dia

Routing Peers

Routing peers are machines that bridge your NetBird peers to your internal networks. They forward traffic from NetBird clients to resources that do not have the NetBird agent installed.

You can add multiple routing peers using individual peers or groups to ensure high availability and load balancing. Each routing peer can be configured with masquerading and priority settings.

high-level-dia

Resources

Resources are the machines, services, or subnets you want to access within your internal network. You can define resources as:

  • Single IP addresses
  • IP ranges
  • Domain names (e.g., example.com)
  • Wildcard domains (e.g., *.company.internal) when DNS wildcard routing is enabled

resources

Domain Resources

In addition to IP-based resources, NetBird supports routing domain names. In the Dashboard, you can enter a domain name (e.g., example.com) or wildcard domain (e.g., *.example.com) instead of an IP range. NetBird clients will then resolve and route traffic to that domain.

For troubleshooting, see Debugging access to Domain Resources.

How Domain Resolution Works

  1. When NetBird connects, it configures the operating system to use NetBird for resolving the specified domains. No routing rules are set up yet.
  2. When an application requests a domain (e.g., example.com):
    • The OS sends the DNS query to NetBird's Local DNS Forwarder, which runs on:
      • macOS and Windows: The highest available IP in your NetBird range (typically 100.xxx.255.254:53)
      • Other systems: Your local NetBird client IP (e.g., 100.xxx.123.45:53)
    • The Local DNS Forwarder sends the query to the Remote DNS Resolver on the routing peer using:
      • Port 22054 for NetBird client versions 0.59.0 and newer
      • Port 5353 for NetBird client versions 0.58.x and older
    • The routing peer resolves the domain using its local DNS configuration and returns the result.
    • The Local DNS Forwarder creates routing rules for the returned IP addresses before sending them to the applicatioxn. See Trigger the Domain Resource to observe this behavior.
  3. The application receives the response normally, with a slight delay on the first request.
  4. Subsequent requests are served instantly from the Local DNS Forwarder's cache.

Manage Access to Resources

To control access to resources, assign them to groups and create access control policies. A peer can only see a resource when a policy grants access from one of the peer's groups (source) to one of the resource's groups (destination).

Example resource CRM assigned to a group:

resource-group

Access control policies define which peers can access which resources based on source groups, destination groups, and allowed traffic types (TCP, UDP, ICMP). When creating a policy:

  • Place the resource's group in the destination field
  • Place the peer's group in the source field
  • Peers in the source groups will receive the resource routes and corresponding firewall rules

Example policy allowing the Berlin Office group to access the internal CRM system:

resource-acl

Enable DNS Wildcard Routing

To use wildcard domains as resources, you must enable DNS wildcard routing. This setting changes how domains are resolved: instead of the client resolving domains locally, the routing peer performs DNS resolution.

This is also useful for regular domain resources when you want to:

  • Resolve domain names using the routing peer's DNS infrastructure
  • Route traffic through a geographically nearby routing peer
  • Enable more restrictive access control rules (support coming in future releases)

To enable DNS wildcard routing, go to Settings > Networks > Enable DNS wildcard routing:

settings-acl

Use Cases

Get Started