How Netzilo works

Zero Trust Networking is the connectivity layer of Netzilo's Secure Workplace and replaces the legacy VPN. The Enterprise Browser, the Enterprise Workspace, clientless access and AI Detection & Response use the same client and control plane. This page describes how the network works.

Architecture

Overview

The Zero Trust Networking module is a collection of components responsible for handling peer-to-peer connections, tunneling, authentication, and network management (IPs, keys, ACLs, etc).

It uses other technologies like WireGuard®, Pion ICE (WebRTC), Coturn, and software developed by Netzilo to make secure private networks deployment and management simple.

Netzilo relies on these components: the Client application, the Management, Signal and Relay services, an identity provider for sign-in, and the dashboard where you manage the network.

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.

A Peer is a machine or any device that is connected to the network. It can be a Linux server running in the cloud or on-premises, a personal laptop, mobile phone, or even a Raspberry PI.

Diagram of Netzilo clients connected to the Management, Signal and relay (STUN/TURN) services, with an identity provider for sign-in

With Netzilo clients installed and authorized on the Management service, machines form a mesh network connecting to each other directly via an encrypted point-to-point WireGuard tunnel.

Diagram of peers connected to each other directly in a mesh of WireGuard tunnels

While it is possible to create a full mesh network, it might be not a desirable outcome. In this case, groups and access controls can be utilized to limit the access to certain machines.

Let's now take a closer look at each of Netzilo's components.

Management Service

The Management service is the central coordination component for Netzilo with a UI dashboard. It keeps the network state, public WireGuard keys of the peers, authenticates and distributes network changes to peers.

The Management Service's responsibilities include:

  • Registering and authenticating new peers. Every new machine has to register itself in the network in order to connect to other machines. After installation, the Netzilo client signs in through the identity provider, or with a setup key. A self-hosted Netzilo Server bundles its own identity provider, which can federate to Okta, Microsoft Entra ID, Google and others.
  • Keeping the network map. The Management service stores information about all the registered peers including WireGuard public key that was sent during the registration process.
  • Managing private IP addresses. Each peer receives a unique private IP with which it can be identified in the network. We use Carrier Grade NAT address space with an allocated address block 100.64.0.0/10.
  • Synchronizing network changes to peers. The Management Service keeps a control channel open to each peer sending network updates. Whenever a new peer joins the network, all other peers that are authorized to connect to it receive an update. After that, they are able to establish a connection to the new peer.
  • Creating and managing access control rules.
  • Managing private DNS. DNS allows referring to each of the peers with a fully qualified domain name (FQDN).
  • Logging network activity.
  • Managing users.

On Netzilo Cloud the Management service runs at srv.netzilo.com, and the dashboard at go.netzilo.com. A self-hosted Netzilo Server serves management, signal, the dashboard and the sign-in on one domain, on port 443.

Diagram of the Management service with the identity provider and the dashboard

Client Application

The Netzilo client is the software you install on your machines. It is the 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 in the network.

The Client's roles are the following:

  • Generating private and public WireGuard keys. These keys are used for packet encryption between peers and for WireGuard Cryptokey Routing. To accept the incoming connections, peers have to know each other, therefore, the generated public keys have to be pre-shared on the machines. The client application sends its public key to the Management service which then distributes it to the authorized peers.
  • Handling peer registration and authentication. Each peer has to be authenticated and registered in the system. The client application asks the user to sign in through the identity provider, or uses a setup key so that the peer can be associated with the organization's account.
  • Receiving network updates from the Management service. Each peer receives initial configuration and a list of peers with corresponding public keys and IP addresses so that it can establish a point-to-point connection.
  • Establishing point-to-point WireGuard connection. To establish a connection with a remote peer, the Client first discovers the most suitable connection candidate, or simply address (IP:port) that other peer can use to connect to it. Then sends it to the remote peer via Signal. This message is encrypted with the peer's private key and a public key of the remote peer. The remote peer does the same and once the peers can reach each other, they establish an encrypted WireGuard tunnel.
  • Applying access control policies. The client application applies access control rules that are received from the Management service. On Linux it uses the system's firewall manager, such as nftables, to apply the rules.
  • Applying DNS settings. The client application runs an embedded DNS resolver and ensures that the machine can resolve other peers' FQDNs in the netzilo.network namespaces. It also applies other DNS settings that are received from the Management service.

Signal Service

The Signal Service or simply Signal is a lightweight piece of software that helps peers to negotiate direct connections. It does not store any data and no traffic passes through it.

The only Signal's responsibility is:

  • Serve as a notification mechanism for peers. Before a connection can be established, peers need to find each other and exchange the most suitable connection candidates. This is done through Signal. After a connection has been established, Signal steps out.

Diagram of two peers exchanging connection candidates through the Signal service

Netzilo Signal is very similar to the signaling servers used in WebRTC. Netzilo runs it for Netzilo Cloud. A self-hosted Netzilo Server includes it.

Relay Service

The Relay service is a TURN server in WebRTC terminology. The purpose of this service is to be a "plan B" and relay traffic between peers in case a point-to-point connection isn't possible.

Diagram of two peers whose encrypted traffic passes through the relay

Netzilo runs the relays for Netzilo Cloud. On a self-hosted Netzilo Server the relay is the coturn container, which needs TCP and UDP 3478 and 5349 open to the clients.

Other ways into the network

The same network serves devices without the Netzilo client. Each of these appears as a peer of your account and follows the same policies:

  • Clientless access. A browser with only the Netzilo extension reaches internal web resources through the Netzilo gateway. Each browser session is a short-lived peer of its user, named vp-<n>-PROXY. See Clientless Access.
  • Published applications. A private web application opens at an address of its own in any browser, through the Netzilo reverse proxy. Each user's requests travel through a peer of that user named vp-<n>-RPROXY. See Applications.
  • The Netzilo AI Gateway is a peer of your account that sits between AI agents and your LLM providers and MCP servers. See AI Gateway.