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.
Networks replace the old Network Routes concept, which is now deprecated. Existing Network routes will continue to work as before, but we recommend migrating to Networks for better access management to your resources.
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 Linux 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.
Only Linux OS machines can be assigned as routing peers.
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.
Support to exit nodes and site-2-site VPNs may become available in future releases. In the meantime you can use Network routes add your exit-node routes and site-2-site routes.
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:
Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior.
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.
(1) Support for more restricted rules will be available in future releases.
You can enable DNS resolution on the routing peer by accessing your account Settings > Networks > Enable DNS wildcard routing. See example below:
The Enable DNS wildcard routing is supported by routing peers and routing clients running version 0.35.0 or later.
Once the feature is enabled, you may need to restart your routing peers and clients to apply the changes.
Differences between Networks and Network Routes
| Networks | Network routes | |
|---|---|---|
| Requires extra policy connecting routing peers to distribution peers? | No, the connection is implied when a policy is added to control access to resources | Yes, the routing peers need to have a policy that connects them to peers in the distribution groups |
| Needs distribution groups? | No, the source groups in the policies define the distribution groups | Yes, they need to be explicitly defined per network route configured |
| Requires adding full sets of configurations per routed resource? | No, the routing peers in a Network are used to route all resources in that network | Yes, every network route needs to have a routing peer, distribution group, access control group, and the network range or DNS route |
| Allows edit routed resources? | Yes, you can edit ranges or domains | No, you can't edit IP ranges or DNS routes once created |
| Allows edit names? | Yes, names are editable | No, names are defined once while creating the route |
| Support to wildcard domains? | Yes, wildcard domains are supported | No, network routes are limited to individual domains |
| Support for exit-nodes? | No, even though that exit-nodes can be linked to on-premises or cloud networks, they invalidate other resources | Yes, but the same note is valid when using an exit-node to route other traffic to the same resources |
| Support for site-2-site IP ranges routing? | No, but support is planned | Yes, when you create a network route without access control groups |
Get started
- Make sure to star us on GitHub
- Follow us on Twitter
- Join our Slack Channel
- NetBird latest release on GitHub