Introduction

Connecting two Kubernetes clusters over a VPN is really a network-design problem, not a Kubernetes feature toggle. The clusters already manage pod and service networking inside their own boundaries; the VPN's job is to create secure routed connectivity between those network ranges without overlapping CIDRs or breaking DNS and service assumptions.

Start with the Network Plan

Before installing any VPN software, define:

• pod CIDR for cluster A
• pod CIDR for cluster B
• service CIDR for cluster A
• service CIDR for cluster B
• node network ranges

These ranges must not overlap. If cluster A and cluster B both use the same pod network, routing across the VPN becomes ambiguous and painful to debug.

You also need to decide what traffic should cross the VPN:

• node-to-node only
• pod-to-pod
• service-to-service
• API server access

The scope determines whether simple routing is enough or whether you also need DNS, service discovery, or multi-cluster ingress patterns.

A Typical WireGuard Topology

WireGuard is a common choice because it is relatively simple and fast. One practical pattern is:

1. run a WireGuard endpoint on a reachable node or gateway in each cluster network
2. exchange public keys
3. configure peer routes for the remote cluster CIDRs
4. allow traffic through security groups, firewalls, and node routing

A simplified WireGuard configuration on one side might look like:

1[Interface]
2Address = 10.200.0.1/24
3PrivateKey = SERVER_PRIVATE_KEY
4ListenPort = 51820
5
6[Peer]
7PublicKey = REMOTE_PUBLIC_KEY
8AllowedIPs = 10.200.0.2/32, 10.50.0.0/16, 10.60.0.0/16
9Endpoint = vpn-b.example.com:51820
10PersistentKeepalive = 25

Here, the AllowedIPs field includes both the peer tunnel address and the remote cluster ranges that should be routed through the VPN.

What Kubernetes Needs

Kubernetes itself usually does not need special manifests just because a VPN exists. The cluster needs the underlying network to be able to reach the other side. In practice, that means:

• routes must exist to remote pod or node networks
• network policies must allow the traffic
• cloud firewalls or security groups must allow the tunnel and forwarded packets

If you expose services across clusters by IP, DNS resolution becomes important too. Two clusters can have VPN connectivity and still fail at application communication because service names do not resolve cross-cluster.

A Service Test

Once the VPN and routes are in place, verify from a pod:

kubectl run netcheck --rm -it --image=busybox -- sh

Inside the pod:

ping 10.50.12.8
wget -qO- http://10.60.3.15:8080/health

This checks whether traffic can actually reach a remote address over the tunnel. Do not skip this step. Many "VPN problems" are really route, firewall, or policy problems.

When a VPN Is Not Enough

A VPN only solves private connectivity. It does not automatically solve:

• cross-cluster service discovery
• traffic failover
• identity and policy consistency
• multi-cluster load balancing

If your goal is active multi-cluster application networking, you may also need a service mesh, gateway layer, or dedicated multi-cluster networking product. The VPN is the transport foundation, not the whole architecture.

Common Pitfalls

The biggest mistake is ignoring overlapping CIDRs. If the address ranges overlap, no amount of YAML polishing will make the routing clean.

Another common issue is connecting only the nodes while expecting pod CIDRs to route automatically. The remote cluster must actually know how to return traffic to the originating pod network.

People also forget cloud-level controls. A WireGuard tunnel can come up successfully while security groups still block forwarded application traffic.

Finally, do not assume Kubernetes service names in one cluster are automatically meaningful in the other. Cross-cluster naming needs explicit design.

Summary

• A cluster-to-cluster VPN starts with non-overlapping pod, service, and node CIDRs.
• WireGuard or similar tools can provide the private tunnel and routes.
• Kubernetes depends on the underlying network being routed correctly; it does not create the VPN for you.
• Test connectivity from pods, not just from nodes or VPN endpoints.
• A VPN gives transport security, not full multi-cluster service discovery or traffic management.