Skip to content

Hybrid WAN Edge and Site Extension

Executive summary

  • Uses a Hetzner-hosted VyOS edge pair as the fixed public WAN anchor for a site that does not control a stable on-prem public IP.
  • Extends on-prem prefixes over site-extension tunnels rather than pushing that instability directly into the cloud hub.
  • Exchanges routes with the GCP hub over redundant BGP sessions across both WAN legs.
  • Establishes a reusable routing control plane for DR and later burst paths without depending on vendor-specific black boxes.

Case study – how this was used in practice

  • Context: The platform needed stable public edge addresses even though the on-prem side could not guarantee a fixed public IP.
  • Challenge: The routing story had to be resilient, cost-aware, and operator-controlled rather than hidden behind cloud-managed abstractions.
  • Approach: Hetzner VyOS edges were used as the public anchor, with on-prem site extension and GCP hub peering built as separate but connected layers.
  • Outcome: On-prem routes now reach the cloud hub across both WAN legs, and the routing baseline is ready for DR and burst scenarios.

Demo

Video walkthrough

  • Video placeholder: replace VIDEO_URL_HERE with the published walkthrough URL.
  • Suggested embed target: VIDEO_URL_HERE

Show the Hetzner edge pair, the on-prem site-extension state, BGP establishment on both WAN legs, and the GCP hub learning on-prem prefixes.

Screenshots

Add these files when they are ready:

![Hetzner edge status with tunnel and BGP summaries](./images/hybrid-wan-edge-site-extension-01-hetzner-edge-status.png)
![GCP Cloud Router view showing learned on-prem prefixes](./images/hybrid-wan-edge-site-extension-02-gcp-cloud-router.png)
![On-prem VyOS view showing established site-extension neighbors](./images/hybrid-wan-edge-site-extension-03-onprem-vyos-neighbors.png)

Architecture

  • Hetzner edge layer: two VyOS nodes provide the fixed public anchor and upstream WAN control.
  • On-prem extension layer: site-extension tunnels originate outbound from on-prem to the Hetzner edges.
  • Cloud hub layer: GCP receives the on-prem prefixes through the Hetzner edge pair.
  • Operational role: this path supports controlled DR and later burst patterns without reworking the network baseline.

Implementation highlights

Evidence and run records

Relevant run records typically live under:

  • envs/dev/logs/module/org__hetzner__vyos-edge-foundation/...
  • envs/dev/logs/module/platform__network__vyos-edge-wan/...
  • envs/dev/logs/module/platform__network__vyos-site-extension-onprem/...
  • envs/dev/logs/module/platform__network__edge-observability/...

Learning outcomes

  • Understand how a fixed public edge can stabilize a hybrid routing story.
  • See how BGP, site extension, and cloud hub routing are separated into reusable layers.
  • Recognize why this pattern is useful when the on-prem site does not control a stable public IP.

Reuse and extensions

  • Extend this baseline with DR cutover logic, PowerDNS, or additional cloud hubs.
  • Reuse the edge pair as the routing control plane for later burst and failover paths.

Status and versioning

Validated against the current Hetzner VyOS edge, on-prem site-extension, and GCP hub routing path. Video and screenshots are still to be added.

Maintainer

  • Owner: HybridOps
  • Primary contact: platform-docs
  • Last reviewed: 2026-03-09