NAT Gateway
NAT Gateway gives workloads on a private-network cluster a managed outbound egress path.
Use it when workers should send internet-bound traffic through dedicated NAT gateway hosts instead of relying on each node’s public address. With Floating IPv4 enabled, workloads can also use a stable egress IP for external allowlists.
NAT Gateway is for outbound traffic. It does not replace Gateway API, LoadBalancer services, MetalLB, Tailscale, or Cloudflare Zero Trust for inbound traffic.
Requirements
Section titled “Requirements”NAT Gateway can be enabled when:
- the cluster is active
- private networking is enabled
- Host Firewall is disabled
- Edka has a valid Hetzner token for the operation
- the control plane remains reachable through the configured API allowed networks
Private-only control plane nodes are not supported. Edka keeps control plane management access available while routing workload egress through the NAT gateway.
Host Firewall and NAT Gateway are separate operating modes:
- Use NAT Gateway for private-network clusters that need managed outbound egress.
- Use Host Firewall for large public-network clusters that need node-level ingress protection without Hetzner private-network attachment limits.
Architecture
Section titled “Architecture”When NAT Gateway is enabled, Edka provisions one or more gateway hosts on the cluster private subnet and configures private-network routes so workload egress uses the active NAT member.
In Single mode, one NAT member owns the egress route.
In HA mode, Edka provisions two members:
- one active member that owns the route
- one standby member that can take over during failover
If Floating IPv4 egress is enabled, Edka assigns the Floating IPv4 to the active member and moves it during failover. This keeps the observed egress IP stable even when the active member changes.
Enable During Cluster Creation
Section titled “Enable During Cluster Creation”In Create Cluster > NAT Gateway, enable NAT Gateway and configure:
- High Availability: enable to use two NAT gateway members with standby failover
- NAT Gateway Node Type: the Hetzner server type used for NAT gateway members
- Floating IPv4: create or attach a Floating IPv4 for stable egress
- NAT Gateway IPv6: attach public IPv6 to the gateway instance when needed
Security defaults are applied automatically. Forwarded metadata traffic is blocked, outbound SMTP port 25 is blocked, the metrics endpoint is private-only, and NAT hosts fail closed if the forwarding policy cannot be applied. Outbound SMTP port 25 blocking is on by default and can be toggled on the NAT Gateway tab via Block SMTP 25.
Enable On Existing Clusters
Section titled “Enable On Existing Clusters”For an existing private-network cluster, open Cluster Settings > NAT Gateway and choose Enable NAT Gateway.
Edka performs a scoped networking reconfigure for NAT Gateway:
- provisions the NAT gateway members
- configures private-network routes to the active member
- preserves Kubernetes API reachability
- updates VictoriaMetrics scraping when managed metrics are installed
- restarts VictoriaMetrics so the updated scrape configuration is loaded
Existing-enable is intentionally limited to private-network clusters. It is not available for Host Firewall clusters because those use a different public-node security model.
Operations
Section titled “Operations”The NAT Gateway page exposes operational actions:
| Action | Purpose |
|---|---|
| Refresh | Reload the current NAT state from Edka and the cluster. |
| Health Check | Check member health and fail over only when the active member is unhealthy. |
| Reconcile | Reapply the expected route, Floating IPv4, firewall, and runtime configuration. |
| Repair | Replace missing or deleted NAT gateway members. |
| Failover | Force the standby member to become active on HA gateways. |
Use Health Check for normal validation. Use Reconcile when state has drifted. Use Repair when a NAT host was deleted or cannot be recovered. Use Failover only when you intentionally want to move traffic to the standby member.
Status And Diagnostics
Section titled “Status And Diagnostics”The overview shows:
- availability mode
- active member
- Floating IPv4 and route owner
- private subnet
- member health
- connectivity result and observed egress IP
- security defaults, including forwarded metadata and SMTP/25 blocking
The advanced diagnostics view shows runtime data from the active member, including interfaces, forwarding state, NAT rules, conntrack usage, drops, and recent failovers.
Metrics
Section titled “Metrics”When VictoriaMetrics is installed, the NAT Gateway page shows NAT-specific metrics:
- forward, return, and NAT traffic rates
- egress latency
- conntrack entries and utilization
- conntrack events
- interface drops and errors
- forwarded metadata and SMTP/25 drops
After enabling NAT Gateway on an existing cluster, metrics can take one or more scrape intervals to appear. Edka updates the VictoriaMetrics scrape config and restarts VictoriaMetrics so new NAT targets are picked up.
Security Defaults
Section titled “Security Defaults”NAT Gateway applies security defaults without requiring advanced overrides:
- the NAT metrics endpoint listens on the private network only
- forwarded workload traffic to
169.254.169.254is blocked at the gateway - outbound TCP port 25 is blocked by default
- gateway hosts fail closed if forwarding policy cannot be applied
- SSH access to NAT hosts is restricted to Edka management access
- runtime drift is surfaced in health and diagnostics
Worker-node metadata access is not blocked by this feature. The gateway blocks metadata traffic only when it is forwarded from workloads through the NAT path.