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. The GCP hub peered at 34.127.187.198 and 34.184.53.36, 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 can reuse the same network baseline instead of rebuilding connectivity from scratch.

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 operating model showing the on-prem site extending into a Hetzner-hosted VyOS edge pair, which then exchanges routes with the GCP hub over HA VPN and BGP.

The public anchor, the routed site extension, and the cloud hub are intentionally separate layers. Each can be updated independently, and both DR and burst paths reuse the same WAN baseline.

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 Hetzner private network resources view showing the control host and the 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

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.