diff --git a/src/pages/about-netbird/how-netbird-works.mdx b/src/pages/about-netbird/how-netbird-works.mdx index fd475b9ff..da2324e97 100644 --- a/src/pages/about-netbird/how-netbird-works.mdx +++ b/src/pages/about-netbird/how-netbird-works.mdx @@ -8,7 +8,7 @@ connections, tunneling, authentication, and network management (IPs, keys, ACLs, It uses open-source technologies like [WireGuard®](https://www.wireguard.com/), [Pion ICE (WebRTC)](https://github.com/pion/ice), [Coturn](https://github.com/coturn/coturn), and [software](https://github.com/netbirdio/netbird) developed by NetBird to make secure private networks deployment and management simple. -NetBird relies on four components - **Client** application (or agent), **Management**, **Signal** and **Relay** services. +NetBird relies on four components - **Client** application, **Management**, **Signal** and **Relay** services. The combination of these elements ensures that direct point-to-point connections are established and only authenticated users (or machines) have access to the resources for which they are authorized. @@ -60,7 +60,7 @@ The Management service runs in the cloud NetBird-managed. It can also be self-ho ## Client Application -The NetBird Client application (or agent) is a software that is installed on the machines within a NetBird network. +The NetBird client is software installed on the machines within a NetBird network. It is an entry point to your private network that makes it possible for machines to communicate with each other. Once installed and registered, a machine becomes a peer within the network. diff --git a/src/pages/about-netbird/self-hosted-vs-cloud.mdx b/src/pages/about-netbird/self-hosted-vs-cloud.mdx index 54c431d53..fadade731 100644 --- a/src/pages/about-netbird/self-hosted-vs-cloud.mdx +++ b/src/pages/about-netbird/self-hosted-vs-cloud.mdx @@ -40,7 +40,7 @@ e.g., control network access. When running the self-hosted version, you are responsible for installing and maintaining all the components as well as backing up and securing the data. With local user management built into the Management service, this burden is significantly reduced—you no longer need to maintain separate identity provider infrastructure. -The cloud-hosted NetBird only requires you to install the client software (NetBird agent) on your machines and log them in to the network. +The cloud-hosted NetBird only requires you to install the NetBird client on your machines and log them in to the network. The cloud-hosted version is more suitable for organizations that want a hassle-free solution that is easy to set up and maintain. ## Features @@ -65,7 +65,7 @@ SCIM provisioning and some enterprise features require a [Commercial License](ht NetBird uses relay servers to establish connections between machines when a direct point-to-point connections isn't possible. When using the cloud-hosted version, you benefit from the geo-distributed relay server clusters that are located in multiple regions -around the world ensuring that your machines can always establish a connection. The NetBird agents pick the closest relay server. +around the world ensuring that your machines can always establish a connection. The NetBird clients pick the closest relay server. When using the self-hosted version, you need to set up your own relay servers. This a complex task and requires additional maintenance effort. diff --git a/src/pages/client/desktop-app.mdx b/src/pages/client/desktop-app.mdx index 261327d18..40d9701fd 100644 --- a/src/pages/client/desktop-app.mdx +++ b/src/pages/client/desktop-app.mdx @@ -4,7 +4,7 @@ export const description = "Overview of the redesigned NetBird desktop app: Defa # NetBird Desktop App -Starting with NetBird v0.75.0, the desktop app uses a [Wails](https://wails.io/) webview with a React frontend. The management server and wire protocol are unchanged, but the UI and agent need to be updated together. If their versions do not match, the app displays an update notification. +Starting with NetBird v0.75.0, the desktop app uses a [Wails](https://wails.io/) webview with a React frontend. The management server and wire protocol are unchanged, but the UI and the daemon need to be updated together. If their versions do not match, the app displays an update notification. ## First Launch @@ -38,7 +38,7 @@ Clicking a peer opens a detail panel with the information you would otherwise lo ## A Reactive UI -Changes made by the NetBird agent or the CLI are reflected in the app immediately. Connect or disconnect from the CLI and the toggle flips on its own. Switch profiles and the window catches up. There is no need to refresh or relaunch the app. +Changes made by the NetBird daemon or the CLI are reflected in the app immediately. Connect or disconnect from the CLI and the toggle flips on its own. Switch profiles and the window catches up. There is no need to refresh or relaunch the app. ## System Tray diff --git a/src/pages/client/mdm-integration.mdx b/src/pages/client/mdm-integration.mdx index 947f4e5b8..d601fda05 100644 --- a/src/pages/client/mdm-integration.mdx +++ b/src/pages/client/mdm-integration.mdx @@ -9,7 +9,7 @@ NetBird's client honors policies pushed by your Mobile Device Management (MDM) channel, so an administrator can enforce configuration across a fleet of devices instead of touching each machine. On every supported platform the daemon reads from the **OS-native managed-configuration -store** that your MDM already writes to. No agent of ours sits between +store** that your MDM already writes to. No extra NetBird software sits between you and the MDM provider; whatever you can push to that store (manually, via Group Policy, via a Configuration Profile, via your MDM console) becomes effective NetBird policy. diff --git a/src/pages/client/post-quantum-cryptography.mdx b/src/pages/client/post-quantum-cryptography.mdx index e64a8f625..d34315088 100644 --- a/src/pages/client/post-quantum-cryptography.mdx +++ b/src/pages/client/post-quantum-cryptography.mdx @@ -14,7 +14,7 @@ The software is [open-source](https://github.com/rosenpass/rosenpass) and design It ensures future-proof security against quantum threats by continuously generating and rotating WireGuard pre-shared keys every two minutes. Rosenpass can also be used as a generic key-exchange mechanism for other protocols. -Starting [v0.25.4](https://github.com/netbirdio/netbird/releases), the NetBird agent runs an embedded Rosenpass server +Starting [v0.25.4](https://github.com/netbirdio/netbird/releases), the NetBird client runs an embedded Rosenpass server that automatically rotates and applies WireGuard pre-shared keys to every point-to-point connection. NetBird uses a [Golang implementation](https://github.com/cunicu/go-rosenpass) of the Rosenpass protocol by the [cunīcu](https://cunicu.li) project. @@ -41,7 +41,7 @@ Rosenpass respects a provided pre-shared key and uses it for its initial key gen ```bash netbird up --enable-rosenpass --preshared-key ``` -This configuration is persistent and preserved by the agent during restarts. +This configuration is persistent and preserved by the client during restarts. If the Rosenpass feature is enabled on a peer it will only be able to communicate with other peers that have Rosenpass enabled. diff --git a/src/pages/get-started/index.mdx b/src/pages/get-started/index.mdx index 7b3f062a9..ab9b9c791 100644 --- a/src/pages/get-started/index.mdx +++ b/src/pages/get-started/index.mdx @@ -134,7 +134,7 @@ A [routing peer](https://docs.netbird.io/manage/network-routes) is a NetBird pee 1. The dashboard will now prompt you to "Add a routing peer." First, click Generate Setup Key. This creates a one-time key used to enroll the gateway machine into your NetBird account. 2. Next, click Install Routing Peer. Select the operating system of your gateway machine (the video uses Linux). -3. The installation modal will provide two commands: a curl script to install the NetBird agent and a netbird up command that includes your setup key. +3. The installation modal will provide two commands: a curl script to install the NetBird client and a netbird up command that includes your setup key. 4. SSH into your gateway machine (which must be inside the 10.0.0.0/24 subnet) and run the commands: 5. SSH into your Linux server and run the commands: diff --git a/src/pages/get-started/install/docker.mdx b/src/pages/get-started/install/docker.mdx index d9c3da645..e5cc3bff0 100644 --- a/src/pages/get-started/install/docker.mdx +++ b/src/pages/get-started/install/docker.mdx @@ -2,7 +2,7 @@ import {Note} from "@/components/mdx"; # Docker Installation -The NetBird client (agent) allows a peer to join a pre-existing NetBird deployment. If a NetBird deployment is not yet available, there are both managed and [self-hosted](https://docs.netbird.io/selfhosted/selfhosted-quickstart) options available. +The NetBird client allows a peer to join a pre-existing NetBird deployment. If a NetBird deployment is not yet available, there are both managed and [self-hosted](https://docs.netbird.io/selfhosted/selfhosted-quickstart) options available. ## Docker Run Command diff --git a/src/pages/get-started/install/index.mdx b/src/pages/get-started/install/index.mdx index 839cb35b4..6c5e81bab 100644 --- a/src/pages/get-started/install/index.mdx +++ b/src/pages/get-started/install/index.mdx @@ -6,7 +6,7 @@ If you're a new user you should visit the [Quickstart Guide](https://docs.netbir
diff --git a/src/pages/manage/access-control/index.mdx b/src/pages/manage/access-control/index.mdx index 8cb7843e4..e8892242b 100644 --- a/src/pages/manage/access-control/index.mdx +++ b/src/pages/manage/access-control/index.mdx @@ -226,7 +226,7 @@ Understanding policy directionality is essential for implementing Zero Trust acc ### Policies Between Peers -When both source and destination are peers running the NetBird agent, you have full control over directionality: +When both source and destination are peers running the NetBird client, you have full control over directionality: **Unidirectional:** Traffic flows only from source to destination. In the NetBird UI, this appears as a single arrow (→). @@ -277,7 +277,7 @@ Direction: ALWAYS Source → Destination (cannot be bidirectional) **Why is this always unidirectional?** -Network resources don't have the NetBird agent installed. They don't know the NetBird network exists. The routing peer acts as a gateway, forwarding traffic from NetBird peers to these resources, but the resources themselves cannot initiate connections back through the NetBird network. +Network resources don't have the NetBird client installed. They don't know the NetBird network exists. The routing peer acts as a gateway, forwarding traffic from NetBird peers to these resources, but the resources themselves cannot initiate connections back through the NetBird network. Think of it this way: diff --git a/src/pages/manage/activity/index.mdx b/src/pages/manage/activity/index.mdx index 7f5f11db6..8d0355a44 100644 --- a/src/pages/manage/activity/index.mdx +++ b/src/pages/manage/activity/index.mdx @@ -115,7 +115,7 @@ The current version of NetBird tracks a wide range of network changes that occur -Future versions will also support connection events that occur in NetBird agents (e.g., peer A connected to peer B). +Future versions will also support connection events that occur in NetBird clients (e.g., peer A connected to peer B). The `unknown` name or `unknown@unknown.com` email address may be displayed in the activity event store if the encryption key has been corrupted or lost. This issue is most relevant for self-hosted setups. In this case, the events returned by the API could show `unknown@unknown.com` for the email address field and `unknown` for the name field. diff --git a/src/pages/manage/network-routes/index.mdx b/src/pages/manage/network-routes/index.mdx index 4d986cc59..ab1ddb018 100644 --- a/src/pages/manage/network-routes/index.mdx +++ b/src/pages/manage/network-routes/index.mdx @@ -194,7 +194,7 @@ In this example, peers in `berlin-office` use `aws-nb-europe-router-az-a` to acc Disable masquerade when you need source IP transparency or want to manage routing on your external network. The routing peer forwards packets with the original NetBird peer IP intact. -This requires configuring your external network router with a return route to your NetBird network through the routing peer. Devices without the agent can then communicate with your NetBird peers. +This requires configuring your external network router with a return route to your NetBird network through the routing peer. Devices without the client can then communicate with your NetBird peers.

Routes without masquerading diff --git a/src/pages/manage/networks/how-routing-peers-work.mdx b/src/pages/manage/networks/how-routing-peers-work.mdx index 4b48c3e16..56a50f63c 100644 --- a/src/pages/manage/networks/how-routing-peers-work.mdx +++ b/src/pages/manage/networks/how-routing-peers-work.mdx @@ -3,11 +3,11 @@ import { Tiles } from '@/components/Tiles' # How Routing Peers Work -A routing peer is a NetBird agent that bridges your overlay network to private networks and resources that do not run the agent. This page covers what routing peers are, how traffic flows through them, the requirements they impose on the host, how high availability and access control behave, and how to harden them. +A routing peer is a NetBird peer whose client bridges your overlay network to private networks and resources that do not run the client. This page covers what routing peers are, how traffic flows through them, the requirements they impose on the host, how high availability and access control behave, and how to harden them. ## What is a routing peer -A routing peer is a NetBird peer installed inside a private network that forwards traffic between the NetBird overlay and resources that cannot or should not run the agent themselves. It is the bridge between your Zero Trust mesh and the LANs, VPCs, datacenter networks, or individual hosts you need to reach. +A routing peer is a NetBird peer installed inside a private network that forwards traffic between the NetBird overlay and resources that cannot or should not run the client themselves. It is the bridge between your Zero Trust mesh and the LANs, VPCs, datacenter networks, or individual hosts you need to reach. A single peer can serve multiple roles at once. The same machine can be a client peer, a routing peer for one or more networks, and an exit node simultaneously. @@ -15,10 +15,10 @@ Because routing peers are typically headless servers, register them with [setup ## When to use a routing peer -- **Site or LAN access.** NetBird peers need to reach resources on a remote subnet, office network, datacenter, or cloud VPC without installing the agent on every host. +- **Site or LAN access.** NetBird peers need to reach resources on a remote subnet, office network, datacenter, or cloud VPC without installing the client on every host. - **Domain-based access.** Traffic must be routed by FQDN or wildcard domain to services whose IPs change. - **Exit node.** All internet-bound traffic from a group of peers must egress through a controlled location. -- **Kubernetes.** Pods or services need to be reachable from NetBird peers without putting an agent on every node. +- **Kubernetes.** Pods or services need to be reachable from NetBird peers without putting the client on every node. ## Networks vs Network Routes @@ -52,11 +52,11 @@ The walkthrough below describes the **Linux kernel-mode** path, where forwarding ### Operating system -Linux, Windows, macOS, FreeBSD, Android, tvOS, and Docker peers can act as routing peers. Linux is the most common production choice because the agent runs in kernel space and integrates with native kernel firewalls (`nftables` / `iptables`). On other platforms the forwarding path runs in userspace. +Linux, Windows, macOS, FreeBSD, Android, tvOS, and Docker peers can act as routing peers. Linux is the most common production choice because it uses the kernel WireGuard data path by default and integrates with native kernel firewalls (`nftables` / `iptables`). On other platforms the forwarding path runs in userspace. ### IP forwarding -The agent enables IP forwarding automatically on Linux. If the agent cannot modify sysctl on its own, set it yourself on the host and persist it: +The client enables IP forwarding automatically on Linux. If the client cannot modify sysctl on its own, set it yourself on the host and persist it: ```bash # Runtime @@ -167,7 +167,7 @@ For the full setup — the file-server scenario, the commands, the Active Direct ### Directionality is forced for routed traffic -Policies whose destination is a network resource are always unidirectional from source to destination. The resource has no agent and cannot initiate connections back through the overlay. The bidirectional toggle is disabled in the UI for these policies. +Policies whose destination is a network resource are always unidirectional from source to destination. The resource has no client and cannot initiate connections back through the overlay. The bidirectional toggle is disabled in the UI for these policies. ### Network Routes default-allow caveat diff --git a/src/pages/manage/networks/masquerade.mdx b/src/pages/manage/networks/masquerade.mdx index 27bf653a7..68ea0a47c 100644 --- a/src/pages/manage/networks/masquerade.mdx +++ b/src/pages/manage/networks/masquerade.mdx @@ -175,7 +175,7 @@ The return route points at one peer, so it has to follow whichever routing peer Two steps: 1. **Give the routing peers different metrics**, so the active peer is the same one for every client. With equal metrics each client picks its own by latency, and then no single next hop is correct for all of them. See [High availability](/manage/networks/how-routing-peers-work#high-availability). -2. **Make the route's next hop follow the active peer.** Either a shared virtual IP across the peers (VRRP, using `keepalived` on Linux, which needs them on the same subnet), or a router that moves the route when a health check fails. The mechanism lives outside NetBird. Whichever you choose, make its health check reach a destination through the tunnel rather than testing the peer itself: a routing peer whose agent is running and whose WireGuard interface is present can still be unable to forward, and neither NetBird nor an interface check notices. +2. **Make the route's next hop follow the active peer.** Either a shared virtual IP across the peers (VRRP, using `keepalived` on Linux, which needs them on the same subnet), or a router that moves the route when a health check fails. The mechanism lives outside NetBird. Whichever you choose, make its health check reach a destination through the tunnel rather than testing the peer itself: a routing peer whose daemon is running and whose WireGuard interface is present can still be unable to forward, and neither NetBird nor an interface check notices. Do not point the return route at both peers at once, as two static routes or an equal-cost pair. Replies reaching the peer a client is not using are silently discarded, so both ends look healthy while traffic fails. diff --git a/src/pages/manage/peers/add-machines-to-your-network.mdx b/src/pages/manage/peers/add-machines-to-your-network.mdx index 1e385d9da..2262243e6 100644 --- a/src/pages/manage/peers/add-machines-to-your-network.mdx +++ b/src/pages/manage/peers/add-machines-to-your-network.mdx @@ -4,7 +4,7 @@ Whether you have a network for personal use or manage your company's corporate network, you'd probably want to add machines (or peers in NetBird's terms) to your network. -NetBird peer is a machine that runs the [NetBird agent](/about-netbird/how-netbird-works#client-application) +NetBird peer is a machine that runs the [NetBird client](/about-netbird/how-netbird-works#client-application) and is connected to the network. NetBird peer can be a virtual machine running in the cloud like AWS or Google Cloud, an Android or iOS device, a personal laptop, a single-board computer like Raspberry Pi, a docker container, or even a router. diff --git a/src/pages/manage/peers/auto-update.mdx b/src/pages/manage/peers/auto-update.mdx index bb006b429..3fec21b9e 100644 --- a/src/pages/manage/peers/auto-update.mdx +++ b/src/pages/manage/peers/auto-update.mdx @@ -5,7 +5,7 @@ import {Note, Warning} from "@/components/mdx"; The Automatic Updates feature allows the NetBird client to notify users when a new version is available and prompt them to install it. This ensures that users always have the latest features and security patches without needing to manually download and install updates. - Minimum supported agent version: v0.61.0. + Minimum supported client version: v0.61.0. This or higher version must also be installed on the peers you need to Automatically Update. diff --git a/src/pages/manage/reverse-proxy/index.mdx b/src/pages/manage/reverse-proxy/index.mdx index 8fad98eac..d8ab9e104 100644 --- a/src/pages/manage/reverse-proxy/index.mdx +++ b/src/pages/manage/reverse-proxy/index.mdx @@ -69,7 +69,7 @@ A target defines where proxied traffic is sent within your NetBird network. Ever | Type | Description | How to select | |------|-------------|---------------| -| **Peer** | A machine running the NetBird agent directly | Select from the peer list | +| **Peer** | A machine running the NetBird client directly | Select from the peer list | | **Host** | A network resource identified by an IP address | Select from your network resources | | **Domain** | A network resource identified by a domain name | Select from your network resources | | **Subnet** | A network resource within a CIDR range | Select from your network resources, then specify an IP within the range | diff --git a/src/pages/manage/settings/ipv6.mdx b/src/pages/manage/settings/ipv6.mdx index d45aa3177..faf2dd2c1 100644 --- a/src/pages/manage/settings/ipv6.mdx +++ b/src/pages/manage/settings/ipv6.mdx @@ -96,7 +96,7 @@ The following API fields relate to IPv6: ### Peers report no IPv6 address after enabling the setting -Peers only get an IPv6 address if they belong to at least one group listed in **IPv6 Enabled Groups** and if the client version supports the IPv6 overlay capability (v0.71.0+). Older agents don't advertise the capability, so management leaves them out of IPv6 distribution: they don't get the address on their interface, and other peers don't receive AAAA records or IPv6 firewall rules for them. +Peers only get an IPv6 address if they belong to at least one group listed in **IPv6 Enabled Groups** and if the client version supports the IPv6 overlay capability (v0.71.0+). Older clients don't advertise the capability, so management leaves them out of IPv6 distribution: they don't get the address on their interface, and other peers don't receive AAAA records or IPv6 firewall rules for them. ### Routing peer has an IPv6 address but traffic doesn't reach the backend diff --git a/src/pages/selfhosted/marketplaces/index.mdx b/src/pages/selfhosted/marketplaces/index.mdx index e76d22041..b14ae7799 100644 --- a/src/pages/selfhosted/marketplaces/index.mdx +++ b/src/pages/selfhosted/marketplaces/index.mdx @@ -5,7 +5,7 @@ import { Tiles } from '@/components/Tiles' Deploy a self-hosted NetBird control plane from your VPS provider's marketplace. Marketplace listings let you launch a pre-configured NetBird instance in a few clicks, without manually installing Docker, configuring a reverse proxy, or running the quickstart script. -Marketplace deployments install the self-hosted NetBird management server. For installing the NetBird agent on an existing VPS, see the [Install guides](/get-started/install). +Marketplace deployments install the self-hosted NetBird management server. For installing the NetBird client on an existing VPS, see the [Install guides](/get-started/install). -e NB_USE_NETSTACK_MODE=true -e NB_SOCKS5_LISTENER_PORT=1080 -v netbird-client:/var/lib/netbird netbirdio/netbird:latest @@ -39,13 +39,16 @@ This is useful when you want to configure a simple routing peer without adding p The SOCKS5 proxy binds to `127.0.0.1` by default, so it is reachable only from within the same container. If your application runs in a **separate** container -and connects to the agent's proxy over the Docker network, set -`NB_SOCKS5_LISTENER_ADDRESS=0.0.0.0` on the agent so the proxy accepts those +and connects to the client's proxy over the Docker network, set +`NB_SOCKS5_LISTENER_ADDRESS=0.0.0.0` on the client so the proxy accepts those connections. The proxy is unauthenticated, so only do this on trusted networks. +In that setup, point the application at the NetBird client container's service +name or IP; `127.0.0.1` only reaches the proxy when the application runs in the +same container as the client. ## How to use the SOCKS5 proxy? -Once you have the agent running in netstack mode, you need to configure your application to use the SOCKS5 proxy. The following is an example of a python 3 application: +Once you have the client running in netstack mode, you need to configure your application to use the SOCKS5 proxy. The following is an example of a python 3 application: ```python import socks import socket diff --git a/src/pages/use-cases/kubernetes/routing-peers-and-kubernetes.mdx b/src/pages/use-cases/kubernetes/routing-peers-and-kubernetes.mdx index 6d325cac2..4ecae1cc8 100644 --- a/src/pages/use-cases/kubernetes/routing-peers-and-kubernetes.mdx +++ b/src/pages/use-cases/kubernetes/routing-peers-and-kubernetes.mdx @@ -1,7 +1,7 @@ import {Note} from "@/components/mdx"; # Deploy routing peers to a Kubernetes cluster -This guide provides instructions on how to use NetBird agent within a Kubernetes cluster to establish secure, peer-to-peer +This guide provides instructions on how to use the NetBird client within a Kubernetes cluster to establish secure, peer-to-peer networking between your Kubernetes pods and external services or other clusters. @@ -68,9 +68,9 @@ Click on Name & Description to give your policy a name and description. Then cli

### Step 4: Deploy the NetBird agent -You can deploy the NetBird agent using a daemon set or a deployment. Below is an example of a deployment configuration with 1 replica. +You can deploy the NetBird client using a daemon set or a deployment. Below is an example of a deployment configuration with 1 replica. -The example below enrolls the agent with a setup key. To also pre-populate the client config so it starts fully configured, see [Bootstrap peers via config file](/manage/peers/bootstrap-via-config-file). +The example below enrolls the client with a setup key. To also pre-populate the client config so it starts fully configured, see [Bootstrap peers via config file](/manage/peers/bootstrap-via-config-file). ```yaml --- @@ -179,15 +179,15 @@ Apply the updated deployment file to your Kubernetes cluster using the following kubectl apply -f deployment.yml ``` ### Step 6: Verify the deployment -After deploying the NetBird agent, you can verify that the agent is running by checking the logs of the pods. +After deploying the NetBird client, you can verify that the client is running by checking the logs of the pods. ```shell kubectl logs -l app=netbird ``` -You can also verify that the agent is connected to the NetBird management dashboard by checking the dashboard. +You can also verify that the client is connected to the NetBird management dashboard by checking the dashboard.

- k8s-netbird-agent-connected + NetBird client pod shown as connected in the dashboard

## Conclusion