> ## Documentation Index > Fetch the complete documentation index at: https://docs.galtea.ai/llms.txt > Use this file to discover all available pages before exploring further. # Connecting to the Galtea VPN > Link your network and the Galtea platform privately, with the NetBird client. A private network link between your network and the Galtea platform, so that neither side has to expose anything to the public internet. Use it in either direction: * **Galtea reaches your AI product.** Your endpoint stays private, reachable only inside your own network, and there is no public URL and no source address to allowlist. * **Your team reaches the platform.** The dashboard and API stay internal, with no public ingress. [Connectivity implementation](/deployment/connectivity-implementation) covers the alternative, which is a public endpoint with an egress allowlist, and when each is the better answer. ## What it is A WireGuard mesh. WireGuard is the encryption and tunnelling protocol built into the Linux kernel; the mesh on top of it is [NetBird](https://docs.netbird.io), which Galtea self-hosts rather than consuming as a service. Self-hosting matters here: the control plane runs inside the Galtea infrastructure for your deployment, so no third-party SaaS sits in the path of your credentials or your traffic. Two planes, and the distinction decides your firewall rules: | Plane | Carries | Transport | | ------- | ----------------------------------------- | ------------------------------------ | | Control | Identity, keys, and which routes exist | Outbound HTTPS 443 from your side | | Data | Your actual traffic, encrypted end to end | WireGuard UDP, direct where possible | **The control plane never carries application traffic.** It hands out keys and policy. Peers then talk to each other directly. ## The endpoints you connect to Both are per deployment, with `` replaced by your deployment's name, which Galtea gives you: | Purpose | Address | | ---------------------------------------------- | -------------------------------------------------- | | Management, which is what the client points at | `https://vpn.platform..galtea.ai` | | Relay, used only as a fallback | `rels://relay-vpn.platform..galtea.ai:443` | What you open on your side: | Direction | Port | Required | | -------------------------------------------------- | ----- | ----------------------------- | | Outbound TCP 443 to both addresses above | 443 | Yes | | Outbound UDP 51820, for a direct peer-to-peer path | 51820 | No, improves latency | | Inbound anything | none | **No inbound rule is needed** | If no direct path can be established, and a strict NAT or a symmetric gateway on either side is enough to prevent one, the tunnel falls back to the relay over TLS 443. **The relay forwards packets it cannot decrypt**, so the fallback costs latency, never confidentiality. ## Three ways to connect Pick by what you need to reach, not by preference. | Way | You install | Reaches | | ---------------------- | ------------------------------------------ | ------------------------------ | | Host to host | The NetBird client on one machine | That machine only | | Routing peer on a node | The client on one VM in your cloud network | Whole subnets you advertise | | Kubernetes | The NetBird operator in your cluster | Kubernetes services you select | They combine. A routing peer for your cloud network and a client on two engineers' laptops is a normal setup, and each peer is authorized separately. **You install and run the peers. Galtea operates the control plane.** That split is the same in all three, and it means you need no account, no console and no administrative access to the mesh itself: | Yours | Galtea's | | ------------------------------------------------------- | ---------------------------------------------------------------- | | Install the client or the operator, and keep it running | Run the management, signal and relay services | | Say what should be reachable, and from where | Create the routes, the groups and the access rules | | Enrol each peer, with a login or a setup key | Issue the setup keys and the tokens, and revoke them | | Confirm your side can reach what it needs | Confirm the platform side, and keep the configuration reviewable | So every step below that needs a change in the control plane is a request to Galtea, which makes it. Galtea agrees the routes and groups with you before anything is enabled, and holds them in configuration rather than clicking them in, so what is reachable can be reviewed at any time. All three are standard NetBird client-side setups: Galtea operates and validates the management, signal and relay services, and each mode follows NetBird's own documentation in your environment. Galtea works with your team on the client-side setup for whichever mode you choose. ### Host to host One machine joins the mesh and gets an address on it. Nothing else in your network becomes reachable, and nothing else needs to change. Pick it when a named machine is the endpoint: a jump host your engineers use, or a single server that hosts the AI product you want evaluated. How it is done: 1. Install the client. There are packages for Linux, macOS and Windows, and a Docker image. See [Installation](https://docs.netbird.io/how-to/installation). 2. Join the mesh, pointing it at your management address instead of the hosted service. ```bash theme={"system"} netbird up --management-url https://vpn.platform..galtea.ai ``` 3. A browser opens for you to sign in. On a machine with no browser, use a setup key instead, as in [Authentication and enrolment](#authentication-and-enrolment) below. 4. Confirm it worked. `netbird status` lists the peers you can reach and whether each path is direct or relayed. Day to day the client runs as a service and reconnects on its own. `netbird down` leaves the mesh without uninstalling anything. The full command set is in the [CLI reference](https://docs.netbird.io/how-to/cli). ### Routing peer on a node in your cloud network One virtual machine inside your own virtual network joins the mesh and **advertises routes** to subnets behind it. Traffic to those subnets flows through it, so the machines behind it need no client installed and no change at all. Pick it when the platform must reach several services, or something that cannot run a client, such as a managed database or an appliance. This is the usual answer for a cloud network, and the least intrusive: one VM, and no change to any workload. How it is done: 1. Create a small virtual machine in the network you want reachable. It forwards packets rather than running workloads, so the smallest instance type is normally enough. 2. Enable IP forwarding on it, at the operating system level and, on most clouds, on the network interface as well. A cloud that drops traffic whose destination is not the instance itself will silently break the route otherwise. 3. Install the client and join the mesh with a setup key, so the peer needs no interactive login and survives a reboot without a person. 4. **Galtea declares the route**, in the control plane. Tell Galtea: | What Galtea needs from you | Example | | -------------------------------------------------------------- | ----------------------------------------- | | The subnet to expose, in CIDR notation | `10.20.0.0/16` | | Which peers should be able to use it | the platform only, or also your engineers | | Whether the destination has to see the original source address | normally no | That last one decides one setting. By default the routing peer replaces the source address of forwarded traffic, which needs no configuration on your side. Preserving the original address is possible and then your network needs a return route back to the mesh, so it is worth saying up front rather than discovering it during a test. 5. Check from the other side that the destination answers, rather than that the peer is connected. A connected peer with a route not yet in place looks identical to a working one until traffic flows. For a path that survives losing the VM, run a second one the same way and tell Galtea: both then advertise the same range and traffic follows whichever is available. Nothing changes on the machines behind them. What the routes and groups mean, and the settings Galtea configures on your behalf, are described in [Routing traffic to private networks](https://docs.netbird.io/how-to/routing-traffic-to-private-networks). ### Kubernetes The NetBird operator runs in your cluster and exposes selected Kubernetes services to the mesh, resolvable by name, without giving the mesh access to the rest of the cluster. Pick it when the thing to reach is a service in Kubernetes and you would rather declare that in your cluster, next to the service, than maintain a VM. How it is done: 1. Install the operator with Helm, from the NetBird project's own registry: ```bash theme={"system"} helm upgrade --install netbird-operator \ oci://ghcr.io/netbirdio/helm-charts/netbird-operator \ --namespace netbird --create-namespace ``` 2. Store the credential **Galtea issues you** for the management API. The operator reads a token from a Kubernetes secret named `netbird-mgmt-api-key`, and its pod does not start without it. The token is scoped to your deployment and Galtea revokes and reissues it on request. 3. Declare what to expose, in your own cluster. The operator adds custom resources; a `NetworkRouter` makes selected `ClusterIP` services reachable from the mesh, named `service.namespace.` in a DNS zone the operator manages. Nothing else in the cluster becomes reachable. This is the one mode where you declare what is exposed rather than asking Galtea, which is the reason to pick it. 4. Resolve that name from a connected peer to confirm it, not just the operator's own logs. The trade-off against a routing peer on a VM: this is declarative and lives with the service, and it needs permission to install cluster-scoped custom resource definitions plus a stored API token. Details are in the [Kubernetes operator guide](https://docs.netbird.io/how-to/kubernetes-operator). ## Authentication and enrolment Two ways a peer joins, for two different situations: | Peer | How it authenticates | | -------------------------------------------------------- | -------------------------------------------------------------- | | A person's machine | Interactive browser login against the Galtea identity provider | | An unattended peer, such as a routing VM or the operator | A setup key, issued per purpose | The interactive login uses the OAuth Authorization Code flow with PKCE, the standard browser flow, so no long-lived credential is stored on the machine. If your organization uses its own identity provider, it can be federated into the Galtea one over SAML or OpenID Connect, which means your directory stays the source of truth: **removing a person there removes their access to the mesh**, with no separate offboarding step. Setup keys are for machines rather than people, and **Galtea issues them**, one per purpose. A peer enrols with one command, with no browser and no person: ```bash theme={"system"} netbird up \ --management-url https://vpn.platform..galtea.ai \ --setup-key ``` The key Galtea gives you already carries the group that decides what the peer may reach, so enrolling is the last step on your side: there is nothing to configure afterwards. Each key can be single-use or reusable, and revoking one does not affect any other peer. Background in [Register machines using setup keys](https://docs.netbird.io/how-to/register-machines-using-setup-keys). ## What is reachable, and what is not Only the routes a peer advertises, and only for the peers your policy allows. * The dashboard and the API, yes, when that is what you asked for. * Databases, internal services and everything else in the same network, no, even for a connected peer, unless a route for them was advertised deliberately. Access is granted per group rather than per peer, so adding a machine to a group is what grants it a path and removing it is what revokes one. Ask Galtea for either and it takes effect without reinstalling or reconfiguring anything on the peer. The rule model is described in [Manage network access](https://docs.netbird.io/how-to/manage-network-access). ## Where to read more | Topic | Page | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | | Installing the client on each platform | [Installation](https://docs.netbird.io/how-to/installation) | | Command reference, including `status` and `down` | [CLI](https://docs.netbird.io/how-to/cli) | | Routing peers and network routes | [Routing traffic to private networks](https://docs.netbird.io/how-to/routing-traffic-to-private-networks) | | Enrolling a machine without a person | [Setup keys](https://docs.netbird.io/how-to/register-machines-using-setup-keys) | | The Kubernetes operator | [Kubernetes operator](https://docs.netbird.io/how-to/kubernetes-operator) | | Groups and access rules | [Manage network access](https://docs.netbird.io/how-to/manage-network-access) | Two things to keep in mind while reading them. Point the client at your own management address rather than the hosted service, and treat the pages about routes, groups and access rules as background: they describe the control plane, which Galtea operates for you, so the steps there are what Galtea does rather than what you do. ```bash theme={"system"} netbird up --management-url https://vpn.platform..galtea.ai ```