Connect to on-prem or another VPC
Reach a private network from the cluster by running a VPN from inside the cluster to the remote side. That remote network is an on-prem site (servers you run yourself), a database in another cloud, or a corporate VPC (a private network inside a cloud account). There is no Hetzner private network to rely on: the platform runs over the public internet with every connection authenticated, so a cluster-to-network link is an application-level VPN you run yourself. See Minimal provider dependency for why the platform works this way.
Run a VPN gateway pod#
Deploy a VPN gateway as a workload: a WireGuard or IPsec pod that holds the tunnel to the remote peer. Pods that need the private network route to it, and it forwards over the encrypted tunnel. WireGuard is the common choice for its small configuration and good throughput; IPsec fits when the remote side requires it.
The tunnel wraps traffic in its own header on top of the cluster's VXLAN overlay, so set the tunnel's MTU to leave room for both. See Understand MTU and the VXLAN tunnel .
Give the tunnel a stable peer IP#
The remote firewall usually allows one address for the tunnel, so the tunnel needs a stable IP. Which side of the cluster that IP lives on depends on who opens the connection:
- The remote peer connects to you. Expose the VPN gateway with a
type: LoadBalancerService and give the remote side its load-balancer IP. That IP is a stable public address on cloud and bare metal alike, and it survives node replacement, so nothing extra is needed. - Your cluster connects out to the remote peer. The stable address must now be a source IP, which a load balancer does not provide. Pin the gateway pod's egress with a Cilium egress gateway . A bare-metal gateway node retains its IP across reinstalls and carries far more bandwidth, which is the main reason to prefer bare metal here.
Plan CIDRs before you create the cluster#
This is the step that causes problems late. The cluster's pod and service ranges are fixed at creation, so if they overlap the remote network, routing is ambiguous and there is no remedy short of rebuilding the cluster.
Warning
Check for CIDR overlap before you create the cluster. Once the cluster runs, the pod and service ranges cannot change, so an overlap with the remote network means rebuilding onto new ranges and migrating your workloads.
Before you create the cluster:
- Choose pod and service CIDRs that do not overlap the on-prem or VPC ranges you will reach. The default RFC 6598 space (
100.64.0.0/10) already avoids the common RFC 1918 office and VPC ranges, which is one reason it is the default. - Decide which remote ranges the tunnel will carry, and advertise routes for them so return traffic finds its way back.
Resolve private names#
Hosts on the remote side often have internal DNS names that public resolvers cannot answer. Forward only those zones from the cluster's DNS to the remote resolver, so a pod resolves db.internal.example.com over the tunnel while everything else resolves normally. See Set up private and split DNS .
When to use a bastion instead#
If only a few pods need to reach one or two remote hosts, a full site-to-site VPN can be more than you need. A bastion or jump host that those pods connect through, or exposing the specific remote service over its own authenticated endpoint, is simpler to run and reason about. Use the VPN when many workloads need broad, ongoing access to the remote network.