SYS.DOCS // DOCS

Private Networking with MetalLB, NAT Gateway, Cloudflare, and Tailscale

Edka supports three private traffic models:

Subnet-routed private networking built around the cluster private subnet. In this model, MetalLB allocates private VIPs and the Cloudflare connector advertises that subnet through Cloudflare Zero Trust so WARP clients can reach it.
Private egress through NAT Gateway for workloads that should send outbound internet traffic through managed NAT hosts and, optionally, a stable Floating IPv4.
Tailnet-published private networking built around the Tailscale operator. In this model, Tailscale publishes private Gateway API traffic into your tailnet or exposes workloads directly with the tailscale traffic class.

These paths solve different problems. The Cloudflare + MetalLB path is best when you want inbound traffic to stay on the cluster private subnet. NAT Gateway is best when private-network workloads need managed outbound egress. The Tailscale path is best when you want traffic published directly into your tailnet.

Prerequisites

For subnet-routed private networking:
- Cluster private networking must be enabled.
- The cluster must have a private subnet configured.
- Install MetalLB when you need private VIPs.
- Install the Cloudflare connector when you want Cloudflare WARP clients to reach the cluster private subnet.
For tailnet-published private networking:
- A Tailscale account with MagicDNS enabled.
- The Tailscale operator installed in the cluster.
- OAuth credentials and tag policy configured as described in the Tailscale guide.
For NAT Gateway private egress:
- Cluster private networking must be enabled.
- Host Firewall must be disabled.
- Edka must have a valid Hetzner token for the operation.

Subnet-routed private networking

Use this model when you want private IPs on the cluster subnet and clients reach those IPs through routed private-network access.

MetalLB private VIPs

MetalLB is the Edka path for private LoadBalancer endpoints on the cluster private subnet.

Use it in two ways:

Gateway API private VIP classes

From Cluster > Gateway, create a Gateway class with exposure mode MetalLB private VIP.

This gives Envoy Gateway a private VIP on the cluster subnet. Use this when you want:

private hostname routing through Gateway API
wildcard domains on a private Gateway class
DNS-01 managed TLS on a private traffic path
one or more private entry points separate from the primary public eg class

Service-level private LoadBalancers

From a deployment networking form, choose Private LoadBalancer.

Edka will request a MetalLB-backed Kubernetes LoadBalancer service and show the assigned private IPs in the UI. This is the simplest option when you need a private IP but do not need hostname routing through Envoy Gateway.

Cloudflare Zero Trust routing

The Cloudflare connector (cloudflared) advertises the cluster private subnet as a Cloudflare Zero Trust CIDR route.

Install it from Cluster > Gateway or Cluster > Add-ons and provide:

your Cloudflare Account ID
a Cloudflare API token
optionally, an existing Cloudflare Tunnel ID and tunnel name

If you do not provide a tunnel ID, Edka can create and manage the tunnel for you. The API token is used during install and update, and is not persisted by Edka.

Operationally, this means:

WARP clients can reach MetalLB private VIPs and other private services on the cluster subnet.
The connector routes the subnet itself, not individual public DNS names.
Public DNS and TLS still belong to the Domains and Gateway flows.

Private DNS and TLS on the cluster subnet

When you need private hostnames on top of a MetalLB private VIP Gateway class:

Install MetalLB.
Create a Gateway class with MetalLB private VIP.
Add a wildcard domain in Cluster > Domains and select that private Gateway class.
Route the cluster private subnet through the Cloudflare connector or another private network so clients can actually reach the VIP.

Important limitations:

Wildcard domains work on public and private Gateway classes because Edka uses DNS-01 for wildcard certificates.
Single hostname domains remain public-only because HTTP-01 validation needs public reachability.
If you only need a private IP, use Private LoadBalancer instead of a private Gateway class.

Private egress with NAT Gateway

Use NAT Gateway when workloads on private-network nodes need outbound internet access through a controlled egress point.

NAT Gateway provisions managed gateway hosts on the cluster private subnet and routes workload egress through the active member. In HA mode, a standby member can take over if the active member fails.

Use it when you need:

stable outbound egress for external allowlists
HA egress for private-network workloads
egress health checks and repair operations
NAT-specific metrics and diagnostics
security defaults for forwarded metadata traffic and outbound SMTP/25

NAT Gateway is not an inbound traffic path. For private inbound traffic, use MetalLB private VIPs, Cloudflare Zero Trust subnet routing, or Tailscale.

Tailnet-published private networking

Use this model when you want Tailscale to publish traffic directly into your tailnet instead of routing the entire cluster private subnet.

Tailscale tailnet Gateway classes

From Cluster > Gateway, create a Gateway class with exposure mode Tailscale tailnet (BYOD).

This keeps the normal Gateway API workflow while publishing the Gateway service into your tailnet. Use it when you want:

private hostname routing through Gateway API
wildcard domains that resolve through your tailnet
your own DNS and certificate flow managed in Edka
multiple workloads behind one private Gateway entry point

Operationally:

Envoy stays in the cluster.
Tailscale publishes the Gateway service to your tailnet.
This is the recommended Tailscale option when you want private Gateway API traffic.

Direct Tailscale ingress

From a deployment networking form, choose the tailscale traffic controller.

This gives a workload its own tailnet hostname using your configured tailnet DNS name. Use it when you want:

private exposure without custom domains
one workload per tailnet hostname
Tailscale-managed routing and certificates

This is the simplest Tailscale path for internal tools, dashboards, and single-service endpoints.

Choose the right private path

Pattern	Best for	DNS / TLS	Reachability
`MetalLB private VIP` Gateway class	Private Envoy Gateway entry points on the cluster subnet	Wildcard domains and DNS-01 TLS supported	Requires routed access to cluster private subnet
`Private LoadBalancer` service	Private service IPs without Gateway routing	No domain flow required	Requires routed access to cluster private subnet
`NAT Gateway`	Private-network workload egress and stable outbound IPs	No domain flow required	Routes outbound traffic through managed NAT hosts
Cloudflare connector	Remote private access through WARP	Does not manage DNS or certs by itself	Advertises cluster private subnet through Cloudflare Zero Trust
`Tailscale tailnet (BYOD)` Gateway class	Private Gateway API traffic in your tailnet	Wildcard domains managed in Edka	Published directly into your tailnet
`tailscale` ingress class	Per-workload tailnet hostnames	Managed by Tailscale	Published directly into your tailnet