Tenkai
Sign inStart for free

How Tenkai isolates your networks

See how Tenkai links servers with WireGuard, what the firewall allows, and how applications reach databases on a private network.

Tenkai links the nodes of a cluster with WireGuard, even across providers or from home. This encrypted Cluster network carries traffic between the applications and services running on different nodes. Firewalls keep runtime ports off the public internet.

Your project's production environment also gets a private application network. Applications reach their databases there without opening database ports to the internet. Trusted infrastructure, such as the edge router, joins this network too.

The cluster network

A provider's private network does not connect servers at other providers or at home. Tenkai builds its own network over reachable IPv4 addresses. These are usually public addresses, but nodes that share a private network can use its addresses instead.

When a server joins a cluster, Tenkai sets up WireGuard on it:

  • The server creates its own key pair. The private key never leaves the server. Tenkai only reads the public key.
  • The server gets a private address, its mesh address, in 10.210.0.0/16.
  • Each pair of nodes uses an encrypted tunnel on UDP port 51820. Tenkai updates peers when a node joins or leaves, without restarting the other tunnels.

Docker Swarm, application networks and the cluster registry use the mesh addresses between nodes. WireGuard encrypts this traffic. The registry also uses TLS.

A server alone in its cluster gets a cluster network too. When its first worker node joins, no address changes.

What the firewall opens

Server setup configures the firewall to deny incoming connections by default, then allows:

  • the SSH port, so Tenkai and you can log in;
  • TCP ports 80 and 443. Tenkai publishes them through the edge router's front on the edge node;
  • UDP port 51820, only from the other nodes of the cluster. A node that leaves loses its access.

The firewall blocks public access to Swarm ports, which Docker can bind on all interfaces. The cluster registry listens on a mesh address. Local access does not need a tunnel.

Docker-published ports bypass these firewall rules. Tenkai does not publish database ports directly. External access opens a separate relay on the edge node for up to 4 hours. The relay accepts only the IPv4 addresses or networks you list. A web application's optional TCP port is different: it is public and has no source filter.

The production network

The production environment gets a private application network in its cluster. This network connects containers on different nodes. Web applications, workers and scheduled jobs join it and reach managed services by their runtime names.

Traffic between nodes crosses the cluster network. Tenkai does not connect application networks across clusters.

The edge router joins each environment network whose web applications it routes. Tenkai disables IP forwarding in its container. The router can access these networks, so their separation does not protect them if the router is compromised.

MySQL managed services also share a Cluster-wide external access network with their relays. Applications do not join it. MySQL requires TLS and a password for logins from that network.

You configure none of this. Tenkai creates environment networks as resources need them and removes them when unused.

What isolation does not cover

  • Public addresses. Anyone can call an application's public HTTPS address. Protect what must stay private with authentication.
  • Shared hosts and infrastructure. Environment networks do not block access to nodes, the cluster network or provider metadata. They do not protect against compromised trusted infrastructure or a container escape.
  • Rules per port. Tenkai adds no per-port rules within an environment network. Services still need to listen and may require authentication.
  • NAT. Each node needs one WireGuard endpoint that all its peers can reach. Home routers need port forwarding unless the nodes share a reachable private network. If your internet provider uses carrier-grade NAT, or CGNAT, ordinary port forwarding on your router will not make the server reachable.
  • Distance. A replica in Amsterdam that queries a database in Falkenstein waits for each round trip.

When another option suits better

  • Code you do not trust. Use a separate cluster on separate servers.
  • Rules per port or per service. Kubernetes supports these network rules, but using it means choosing a platform other than Tenkai's Docker Swarm setup.

Go further