Skip to content

Hybrid WAN Edge and Site Extension

Overview

Hybrid WAN Edge and Site Extension establishes a reusable routing baseline for sites that do not control a stable public IP. A Hetzner-hosted VyOS edge pair anchors public connectivity, the on-prem site extends into that edge, and the GCP hub exchanges routes over the same control plane.

It is the network foundation behind the burst and DR lanes.

Case study

  • Context: the on-prem site had no stable public IP. Every time a DR or burst path was scoped, connectivity had to be re-established from scratch because there was no fixed WAN anchor to build on.
  • Challenge: without a reusable routing baseline, each upstream service (burst, cloud DR, VPN peering) was solving the same connectivity problem independently and inconsistently.
  • Approach: a Hetzner-hosted VyOS edge pair provides the fixed public anchor through org/hetzner/vyos-edge-foundation. GCP exchanges routes through org/gcp/wan-vpn-to-edge. The on-prem site extends into the edge through platform/network/vyos-site-extension-onprem rather than directly into the cloud hub, keeping the layers independent.
  • Outcome: the recorded exercise established one reusable WAN baseline for both DR and burst. Both GCP BGP sessions established successfully, and on-prem reachability to the recovery subnet was confirmed without rebuilding the route path for each service.

Shows the fixed public edge pair, GCP hub peering, the on-prem site-extension layer, and confirmed reachability from the on-prem runner to the GCP recovery subnet.

Outcome

The result is a reusable routing foundation that does not depend on a stable on-prem public IP.

  • A fixed public edge pair anchors the WAN posture.
  • Site extension and cloud hub routing remain separate but connected control layers.
  • Cloud recovery and burst paths reuse the same network baseline instead of rebuilding connectivity for each service.

Operating model

  • Hetzner-hosted VyOS nodes provide the fixed public edge.
  • The on-prem site extends outbound to that edge instead of pushing local address instability directly into the cloud hub.
  • GCP exchanges routes through redundant HA VPN and BGP peers.
  • Observability and control remain separate from the routed data path.

Architecture

Hybrid WAN architecture showing the on-prem site extension, stable Hetzner VyOS edge pair, bidirectional HA VPN and BGP peer links, GCP Cloud Router, and downstream recovery and burst subnets.

The site extension and HA VPN links are peer relationships, so the diagram uses endpoint ports rather than directional arrows. The on-prem site reaches a stable Hetzner edge anchor; that edge terminates the GCP VPN path, and Cloud Router propagates learned routes to recovery and burst subnets.

Routing sequence

  1. The Hetzner edge pair establishes the fixed public WAN anchor.
  2. The GCP hub exchanges routes with that edge through HA VPN and BGP.
  3. The on-prem site extends into the same edge through its own routed layer.
  4. On-prem workloads can then reach cloud recovery or burst subnets through the shared WAN baseline.

Platform state

GCP Cloud Router overview showing both BGP sessions up and the shared WAN hub routing state
GCP Cloud Router with both BGP sessions established.
Hetzner private network resources view showing the control host and the edge pair attached to the WAN anchor network
Hetzner control host and edge pair attached to the WAN anchor network.
Recorded VyOS show bgp summary from the exercise, with the Hetzner edge peers to GCP HA VPN established and prefixes exchanged
VyOS peers established with prefixes exchanged through GCP HA VPN.

IP addresses, hostnames, and instance identifiers visible in screenshots and recordings reflect the ephemeral infrastructure provisioned during the recorded exercise.

Implementation

  • Public edge anchor: the Hetzner VyOS pair provides a stable public WAN anchor.
  • Cloud hub routing: GCP HA VPN and BGP handle route exchange with the cloud side.
  • On-prem extension: site extension keeps the local edge independent from the cloud hub.
  • Observability: Grafana and Thanos provide the operator view of edge and control state.

Key components

  • Edge foundation: org/hetzner/vyos-edge-foundation
  • GCP hub peering: org/gcp/wan-vpn-to-edge
  • Edge WAN control: platform/network/vyos-edge-wan
  • On-prem site extension: platform/network/vyos-site-extension-onprem
  • Observability: platform/network/edge-observability

Where it fits

  • hybrid estates without a stable on-prem public IP
  • branch, campus, or customer sites that need reusable cloud connectivity
  • DR and burst designs that require a reusable routing control plane first

References

Further reading
Implementation references
  • org/hetzner/vyos-edge-foundation
  • org/gcp/wan-vpn-to-edge
  • platform/network/vyos-edge-wan
  • platform/network/vyos-site-extension-onprem
  • platform/network/edge-observability

What was verified

Verified during the recorded HybridOps v1.0.1 WAN exercise with the fixed public edge pair, GCP hub peering, on-prem site extension, and reachability to the GCP recovery subnet confirmed.