Networks

NetBird provides a fast and secure peer-to-peer mesh network with end-to-end encryption, enabling devices and machines running the NetBird agent to connect directly. This setup allows for precise network segmentation, isolation of individual machines, and secure remote access without the need to open ports or expose resources to the internet. However, there are situations where installing the agent on every machine is not feasible or hasn't been completed, requiring access to entire LANs, office networks, or cloud VPCs instead.

Starting from version 0.35.0, NetBird introduces Networks, a new concept that allows you to map your internal networks such as LANs, VPCs, or office networks, and manage access to internal resources without installing NetBird agent.

Concepts

Networks

Networks are configuration containers that map your on-premise or cloud networks in a logical set of configurations, making it easier to visualise and manage access to your internal resources. You can create multiple networks to represent your different environments, such as office networks, cloud VPCs, or on-premise LANs.

Routing peers

To access your internal resources, you need to route traffic from your NetBird peers to your internal networks. Routing peers are machines that connect your NetBird peers and your internal networks. You can add as many routing peers as you need using single peers or groups to ensure high availability and load balancing. You can define masquerading and priority for each routing peer.

Resources

Resources are individual machines, services, or subnets within your internal network. You can define resources as single IP addresses, IP ranges, domain names, or wildcard domains (e.g., *.company.internal) when enabling DNS wildcard routing.

Domain Resources

In addition to routing IP addresses, NetBird also supports routing domain names. In the Dashboard you can just pass a domain name (eg: example.com) or a wildcard domain (eg: *.example.com) in place where you would normally put an IP address range. Then NetBird clients will start responding to and routing the given domain.

Please consult the Debugging access to Domain Resources documentation to troubleshoot common issues with this type of resources yourself.

On a technical level the feature works as follows:

1. Initially (when NetBird connects) the operating system is instructed to use NetBird to resolve the requested domain(s). No routing rules are configured yet.
2. An Application (could be a web browser) requests a domain example.com from the Operating System
   1. the Operating System requests a name from NetBird's Local DNS Forwarder, by default running on port 53 of:
      • for MacOS & Windows: the highest available IP address in your NetBird range, usually 100.xxx.255.254:53
      • for other systems: local NetBird client's IP address, eg: 100.xxx.123.45
   2. the Local DNS Forwarder forwards the query to Remote DNS Resolver running on Routing Peer's address and the following port:
      • 22054 for version 0.59.0 and newer
      • 5353 for versions below 0.58.x and older
   3. the Routing Peer resolves the domain name using its local configuration (often independent of NetBird) and returns the result.
   4. the Local DNS Forwarder sets up routing rules for IP addresses returned from the query, before returning them to the Application
      • see Trigger the Domain Resource to observe this behaviour "in action".
3. the Application receives the result "as usual", except for a slight delay before all of the above takes place the first time a domain name is requested,
4. all subsequent requests to example.com will be served instantly from the Local DNS Forwarder's cache

Manage access to resources

To manage access to resources, you can assign them to groups and create access control policies to define which peers can access them. See the image below with an example resource CRM:

Access control policies are rules that define which peers can access the resources in your network. You can create policies based on the source and destination groups, and the type of traffic allowed (e.g., TCP, UDP, ICMP). The groups assigned to resources should always be placed in the destination input field of the policy. The peers belonging to the source groups will receive the resources linked to the policy and the firewall rules will be applied according to what is defined. See the example below with a policy that allows the group Berlin Office to access the internal CRM system:

Enable DNS wildcard routing

When you configure wildcard domains as resources, you need to enable DNS wildcard routing. Which has an additional effect in comparison to the previous DNS routes behavior from Network routes; it switches the DNS resolution to the routing peer instead of the local client system. This is also useful for regular DNS routes when you want to resolve the domain names using the routing peer's IP infrastructure, which will allow for more restricted access control rules in newer versions of the clients (1) and for the traffic to go to a near routing peer service.

You can enable DNS resolution on the routing peer by accessing your account Settings > Networks > Enable DNS wildcard routing. See example below:

Differences between Networks and Network Routes

Use cases

• Routing traffic to multiple IP resources
• Accessing restricted website domain resources
• Accessing entire domains within networks

Get started

Use NetBird

• Make sure to star us on GitHub
• Follow us on X
• Join our Slack Channel
• NetBird latest release on GitHub