Networking

This page walks through how Baseguard networking works — from a device joining the network to traffic flowing between nodes.

Authentication

Before anything else, a new device must prove its identity. Baseguard uses a device-authorization flow — similar to signing in to a smart TV. The client gives you a URL and a code, you open it in your browser, and authorize the device.

The auth request is encrypted end-to-end with the control plane's public key — even the transport layer cannot read it.

For headless environments (servers, CI), nodes can skip the browser flow and authenticate directly using a pre-shared node auth key.

Control Plane Connection

After authentication, the client establishes a persistent connection to the control plane over the Node Control Protocol (NCP). This is the signaling channel — it carries the node list, ACL distribution, and ICE signaling, but never user traffic.

NCP runs over the Noise protocol, which handles both encryption and authentication. The IK handshake pattern provides mutual authentication — both sides verify each other's identity using their static keys during the handshake. See Security for cryptographic details.

Real-Time Updates

From this point on, the connection stays open. The control plane pushes updates as they happen:

ACL rules created, updated, or deleted
Nodes joining, leaving, or changing status
ICE offers forwarded from other nodes (for P2P connection establishment)

If the connection drops, the client reconnects and receives a fresh sync.

P2P Connections

The data plane is the actual traffic between your devices. It flows directly between nodes over WireGuard tunnels — the control plane is not in the path.

Connections are established on-demand. Each client already has a list of reachable nodes from the control plane (distributed via NCP and kept up to date in real time). When a packet targets another node's overlay IP and no tunnel exists yet, the connection process starts automatically:

Node A sends a packet to Node B's overlay IP — the first packet is dropped and triggers a handshake
The client adds Node B as a WireGuard peer (it already has B's public key and overlay IP from the node list)
Two things happen in parallel:
- Relay: A relay connection is established immediately — traffic starts flowing right away
- P2P: ICE candidates are gathered and exchanged through the control plane's NCP channel
ICE runs connectivity checks to find a direct path
When a direct path is found, the connection upgrades to P2P transparently

NAT Traversal

Baseguard uses ICE (Interactive Connectivity Establishment) to find direct paths through NATs and firewalls.

NAT Type	P2P Support	Description
Full Cone	Works easily	Any external host can send to mapped port
Restricted Cone	Works with simultaneous open	Only hosts we've sent to can respond
Symmetric	May fail, relay used	Different mapping per destination

For successful P2P: firewalls must permit outbound UDP, and both sides should not be behind symmetric NAT.

Relay

When ICE cannot find a direct path (e.g., both nodes behind symmetric NAT), traffic routes through a relay server. The relay forwards encrypted WireGuard packets — it cannot read, modify, or inject them. Only the sender and receiver can decrypt the traffic.

Baseguard provides default relay servers distributed globally. Clients automatically select the lowest-latency relay by measuring the total path (source → relay → destination). Baseguard periodically retries P2P in the background and switches transparently when a direct path becomes available.

Self-Hosted Relays

Organizations can deploy their own relay servers for lower latency and dedicated bandwidth.

Requirements: Public IP address, TCP/UDP port 80/443 open, adequate bandwidth.

Contact Baseguard support for deployment and registration documentation.