|
1 | 1 | # Networks
|
2 | 2 |
|
3 |
| -With the `0.35.0` release, we are introducing a new concept in NetBird called `Networks`. This concept improves the administration of routed resources and provides greater visibility into what is shared with peers. |
| 3 | +NetBird provides a fast and secure peer-to-peer mesh network with end-to-end encryption, enabling devices and machines |
| 4 | +running the NetBird agent to connect directly. This setup allows for precise network segmentation, |
| 5 | +isolation of individual machines, and secure remote access without the need to open ports or expose resources to the |
| 6 | +internet. However, there are situations where installing the agent on every machine is not feasible or hasn't been |
| 7 | +completed, requiring access to entire LANs, office networks, or cloud VPCs instead. |
4 | 8 |
|
5 |
| -Below, we will review the essential concepts of Networks. |
| 9 | +Starting from version `0.35.0`, NetBird introduces Networks, a new concept that allows you to map your internal networks |
| 10 | +such as LANs, VPCs, or office networks, and manage access to internal resources without installing NetBird agent. |
| 11 | + |
| 12 | +<p> |
| 13 | + <img src="/docs-static/img/how-to-guides/netbird-network-routes.png" alt="high-level-dia" className="imagewrapper-big"/> |
| 14 | +</p> |
| 15 | + |
| 16 | +<Note> |
| 17 | + Networks replace the old [Network Routes](/how-to/routing-traffic-to-private-networks) concept, which is now deprecated. |
| 18 | + Existing Network routes will continue to work as before, but we recommend migrating to Networks for better access |
| 19 | + management to your resources. |
| 20 | +</Note> |
6 | 21 |
|
7 | 22 | ## Concepts
|
8 |
| -#### Networks |
9 |
| -Networks are configuration containers that map your on-premise or cloud networks in a logical set of configurations, making it easier to manage and share routes with your peers based on your infrastructure. |
| 23 | +### Networks |
| 24 | +Networks are configuration containers that map your on-premise or cloud networks in a logical set of configurations, |
| 25 | +making it easier to visualise and manage access to your internal resources. You can create multiple networks to represent your |
| 26 | +different environments, such as office networks, cloud VPCs, or on-premise LANs. |
10 | 27 |
|
11 |
| -#### Routing peers |
12 |
| -One or more peers selected to route traffic from your NetBird peers to your Network resources. You can add as many routing peers as you need using single peers or groups to ensure high availability and load balancing. |
| 28 | +<p> |
| 29 | + <img src="/docs-static/img/how-to-guides/networks/new-network-2.png" alt="high-level-dia" className="imagewrapper"/> |
| 30 | +</p> |
| 31 | + |
| 32 | +### Routing peers |
| 33 | +To access your internal resources, you need to route traffic from your NetBird peers to your internal networks. |
| 34 | +Routing peers are Linux machines that connect your NetBird peers and your internal networks. |
| 35 | +You can add as many routing peers as you need using single peers or groups to ensure high availability and load balancing. |
13 | 36 | You can define masquerading and priority for each routing peer.
|
14 | 37 |
|
| 38 | +<p> |
| 39 | + <img src="/docs-static/img/how-to-guides/networks/add-routing-peer-1.png" alt="high-level-dia" className="imagewrapper"/> |
| 40 | +</p> |
| 41 | + |
15 | 42 | <Note>
|
16 | 43 | Only Linux OS machines can be assigned as routing peers.
|
17 | 44 | </Note>
|
18 | 45 |
|
19 |
| -#### Resources |
20 |
| -Remote network resources that are routed via routing peers. They can be configured as single IP addresses, IP ranges, domain names, or wildcard domains (e.g., *.netbird.io) when enabling [DNS wildcard routing](#enable-dns-wildcard-routing). |
| 46 | +### Resources |
| 47 | +Resources are individual machines, services, or subnets within your internal network. You can define resources as single |
| 48 | +IP addresses, IP ranges, domain names, or wildcard domains (e.g., *.company.internal) when enabling [DNS wildcard routing](#enable-dns-wildcard-routing). |
21 | 49 |
|
22 |
| -See examples of resources below: |
23 | 50 | <p>
|
24 | 51 | <img src="/docs-static/img/how-to-guides/networks/resources-1.png" alt="resources" className="imagewrapper-big"/>
|
25 | 52 | </p>
|
26 | 53 | <Note>
|
27 |
| - Support to exit nodes and site-2-site VPNs may become available in future releases. In the meantime you can use [Network routes](/how-to/routing-traffic-to-private-networks) add your exit-node routes and site2site routes. |
| 54 | + Support to exit nodes and site-2-site VPNs may become available in future releases. In the meantime you can use [Network routes](/how-to/routing-traffic-to-private-networks) add your exit-node routes and site-2-site routes. |
28 | 55 | </Note>
|
29 | 56 |
|
30 |
| -You can assign a Group to a resource that allows you to manage access control policies for the resources. See the image below with an example of the resource *.netbird.io: |
| 57 | + |
| 58 | +## Manage access to resources |
| 59 | + |
| 60 | +To manage access to resources, you can assign them to groups and create [access control policies](/how-to/manage-network-access#creating-policies) to define which peers can access them. |
| 61 | +See the image below with an example resource `CRM`: |
31 | 62 | <p>
|
32 | 63 | <img src="/docs-static/img/how-to-guides/networks/resources-2.png" alt="resource-group" className="imagewrapper"/>
|
33 | 64 | </p>
|
34 |
| -#### Access control policies |
| 65 | + |
35 | 66 | 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).
|
36 | 67 | The groups assigned to resources should always be placed in the destination input field of the policy.
|
37 | 68 | 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.
|
38 |
| -See the example below with a policy that allows the group `berlin-office` to access the resource `*.netbird.io`: |
| 69 | +See the example below with a policy that allows the group `Berlin Office` to access the internal CRM system: |
39 | 70 |
|
40 | 71 | <p>
|
41 | 72 | <img src="/docs-static/img/how-to-guides/networks/resource-acl-1.png" alt="resource-acl" className="imagewrapper-big"/>
|
42 | 73 | </p>
|
43 | 74 |
|
44 | 75 | <Note>
|
45 |
| - Policies that for `domains` or `wildcard domains` that are applied to the peers of `IP ranges` might influence the access control for those peers since they have as destination ranges any IPs. |
46 |
| - Due to this, we recommend to create networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access to take place. In the coming releases, we will provide a fix for that behavior. |
| 76 | + 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. |
47 | 77 | </Note>
|
48 | 78 |
|
49 |
| -#### Enable DNS wildcard routing |
| 79 | +## Enable DNS wildcard routing |
50 | 80 | 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.
|
51 |
| -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. |
| 81 | +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. |
52 | 82 | <Note>
|
53 | 83 | (1) Support for more restricted rules will be available in future releases.
|
54 | 84 | </Note>
|
|
0 commit comments