WireGuard Site-to-Site: Routing, AllowedIPs und Skalierungsgrenzen

WireGuard Site-to-Site ist für viele Unternehmen ein attraktives Architekturpattern, weil es mit wenig Protokollkomplexität sehr hohe Performance und eine klare Konfigurationslogik liefert. Im Gegensatz zu klassischen IPSec-Setups mit umfangreichen Negotiation-Optionen und herstellerspezifischen Sonderwegen arbeitet WireGuard bewusst minimalistisch: feste moderne Kryptografie, ein schlanker Handshake und eine zentrale Steuergröße namens AllowedIPs. Genau hier liegt jedoch die Enterprise-Herausforderung: AllowedIPs ist nicht nur „eine Route“, sondern gleichzeitig Routing-Entscheidung, Zugriffskontrolle und – in vielen Betriebsmodellen – auch der Mechanismus, der Skalierung begrenzt oder ermöglicht. Wer WireGuard für Standortvernetzung (Branch-to-Hub, Hub-and-Spoke, Dual-Hub, Teil-Mesh) einsetzen will, muss daher Routing und Governance sauber entwerfen: Welche Präfixe werden wo announced? Wie vermeiden Sie Overlaps und Route Leaks? Wie umgehen Sie Full-Mesh-Explosionen? Wie bauen Sie Failover ohne Tunnel-Flapping? Und wie bleiben Design und Betrieb auditierbar, wenn die Anzahl der Standorte steigt? Dieser Artikel erklärt WireGuard Site-to-Site auf Profi-Niveau: Routing-Grundmuster, AllowedIPs-Design, typische Skalierungsgrenzen und bewährte Betriebsmodelle, damit WireGuard nicht nur „läuft“, sondern langfristig stabil bleibt.

Grundlagen: WireGuard als Overlay – Routing entscheidet über Reichweite

WireGuard ist ein Layer-3-Overlay: Es transportiert IP-Pakete verschlüsselt über UDP. Im Unterschied zu vielen klassischen VPN-Stacks gibt es bei WireGuard keine „Policy“-Aushandlung. Stattdessen definieren Sie pro Peer statisch, welche Zielnetze (Präfixe) über diesen Peer erreichbar sein sollen. Diese Definition ist AllowedIPs. Sie wirkt in der Praxis wie eine Kombination aus Routingtabelle und Access Control List.

• Underlay: Internet/MPLS/LTE/5G, NAT/Firewalls, MTU/PMTUD, Provider-Variabilität.
• Overlay: WireGuard-Tunnel, Peer-Keys, AllowedIPs, Routing/Forwarding im Betriebssystem oder Router.
• Identität: Der Peer wird primär über den Public Key identifiziert (nicht über Benutzername/Passwort).

Als offizielle Einstiegsreferenz lohnt ein Blick auf wireguard.com sowie auf die Linux-Dokumentation WireGuard im Kernel, weil dort die Funktionsweise (Peers, AllowedIPs, Handshake, Roaming) sehr klar beschrieben ist.

AllowedIPs: Routing-Mechanismus und Policy in einem

AllowedIPs ist die wichtigste Stellschraube bei WireGuard Site-to-Site. Für jeden Peer definieren Sie eine Liste von IP-Präfixen, die über diesen Peer gesendet werden dürfen. Gleichzeitig akzeptiert WireGuard eingehende Pakete nur dann als „legitim für diesen Peer“, wenn sie aus einer Quelle stammen, die zu dessen AllowedIPs passt. Das ist eine starke Sicherheitsidee, aber sie hat Konsequenzen:

• Least Privilege by Design: Wenn AllowedIPs klein und präzise sind, ist Exposition minimal.
• Overlaps sind gefährlich: Überschneidende AllowedIPs zwischen Peers erzeugen unklare Pfade und können Traffic „umleiten“.
• Skalierung über Listen: In großen Umgebungen wachsen AllowedIPs-Listen; ohne Governance und Automatisierung wird Betrieb teuer.

AllowedIPs als „Routing-Tabelle“ interpretieren

In vielen Implementierungen verhält sich AllowedIPs wie ein Lookup: „Für Zielpräfix X nutze Peer Y“. Das ist der Grund, warum Sie bei Site-to-Site eine saubere IP-Adressplanung und eindeutige Präfixzuordnung benötigen. Wenn zwei Peers dasselbe Präfix beanspruchen, ist das nicht nur ein Routingfehler, sondern ein Policy-Fehler.

Topologien: Hub-and-Spoke, Dual-Hub und Teil-Mesh mit WireGuard

WireGuard eignet sich für verschiedene Topologien. Entscheidend ist, welche davon Sie langfristig betreiben wollen, denn die Topologie bestimmt direkt, wie AllowedIPs und Routingregeln wachsen.

Hub-and-Spoke als Standard für Skalierung

• Pattern: Jeder Spoke (Branch) peert zu einem Hub. Optional: zwei Hubs für Redundanz.
• Stärke: Lineare Skalierung in der Anzahl der Peers am Hub; Templates für Spokes sind gut machbar.
• Schwäche: Spoke-to-Spoke-Traffic hairpint über den Hub, sofern keine Direktpfade existieren.

Dual-Hub (Primary/Secondary) für Resilienz

• Pattern: Spokes peeren zu Hub A und Hub B. Ein Hub ist primär, der andere übernimmt bei Failure.
• Stärke: Sehr stabile Failover-Logik, wenn Routingpräferenzen und Health-Checks sauber sind.
• Schwäche: Mehr Konfigurationsobjekte pro Spoke; erfordert Hysterese, um Failback-Flapping zu vermeiden.

Teil-Mesh für kritische Direktpfade

• Pattern: Hub-and-Spoke bleibt Standard, aber wenige Spokes haben zusätzliche Direktpeers für latenzkritische Workloads.
• Stärke: Performance dort, wo nötig – ohne Full Mesh Explosion.
• Schwäche: Mehr Komplexität bei AllowedIPs und Routing; Governance ist Pflicht, damit kein Wildwuchs entsteht.

Full Mesh: Warum es selten Enterprise-Default ist

Ein Full Mesh bedeutet, dass jeder Standort zu jedem anderen peert. Die Anzahl der Peer-Beziehungen wächst ungefähr quadratisch:

$P=\frac{n(n–1)}{2}$

Bei 50 Standorten sind das bereits 1225 Peerings. Selbst wenn WireGuard „einfach“ ist, sind Keys, AllowedIPs, Monitoring und Change-Prozesse in einem Full Mesh selten dauerhaft beherrschbar. Deshalb ist Hub-and-Spoke (mit optionalen Direktpfaden) in Enterprise-Szenarien meist die bessere Standardtopologie.

Routing über WireGuard: Statisch vs. dynamisch

WireGuard selbst ist kein Routingprotokoll. Routing passiert im Betriebssystem/Router. Für Site-to-Site haben sich zwei Grundmodelle etabliert:

• Statisches Routing: Präfixe werden manuell oder via Template auf Hubs/Spokes als statische Routen gesetzt.
• Dynamisches Routing über Tunnel: BGP oder OSPF laufen über die WireGuard-Interfaces und verteilen Präfixe automatisch.

Statisches Routing: robust, aber begrenzt

• Geeignet: Kleine bis mittlere Umgebungen, wenige Präfixe pro Standort, seltene Änderungen.
• Risiko: Drift und manuelle Fehler (falsche Maske, vergessene Rückroute), besonders bei Wachstum.
• AllowedIPs-Konsequenz: Muss exakt zu statischen Routen passen – sonst erreichen Sie Netze nicht oder exponieren zu viel.

BGP über WireGuard: Skalierung und kontrollierte Policies

In großen Site-to-Site-Landschaften ist BGP häufig das skalierbarste Routingmodell, weil Sie Präfixe dynamisch verteilen und gleichzeitig Policies (Filter, Preferenzen) sauber implementieren können. BGP ist in RFC 4271 beschrieben.

• Vorteil: Weniger manuelle Routenpflege, klare Failover-Mechanik über Withdraw/Preferenzen.
• Wichtig: Prefix-Filter inbound/outbound sind Pflicht, sonst drohen Route Leaks und ungewollte Transitivität.
• AllowedIPs-Integration: Viele Designs setzen AllowedIPs so, dass nur Tunnel-Subnetze oder stark begrenzte „Routing-Overlay“-Präfixe erlaubt sind, während die eigentlichen Reachability-Entscheidungen über BGP laufen.

OSPF über WireGuard: möglich, aber empfindlicher

OSPF kann funktionieren, ist aber über Internet-Underlays sensibler gegenüber Jitter, Loss und MTU-Problemen. OSPFv2 ist in RFC 2328 beschrieben. In Enterprise-Site-to-Site-Overlays wird OSPF häufig nur in klar begrenzten Domänen empfohlen, in denen Underlay-Qualität gut kontrolliert ist.

AllowedIPs-Designmuster für Site-to-Site

Die größte praktische Frage ist: Was tragen Sie in AllowedIPs ein, wenn Sie skalieren wollen? Es gibt drei Muster, die sich in der Praxis bewährt haben.

Muster 1: Präfixe pro Standort explizit (kleine Umgebungen)

• Beschreibung: Jeder Peer enthält die exakten LAN-Präfixe des Gegenübers.
• Pro: Sehr transparent, starke Least-Privilege-Eigenschaft.
• Contra: Skaliert schlecht, weil AllowedIPs-Listen wachsen und Änderungen manuell/automatisiert ausgerollt werden müssen.

Muster 2: Segment-/Summary-Präfixe mit strenger Governance

• Beschreibung: AllowedIPs nutzt Summaries oder Segmentpräfixe (z. B. pro Region oder pro Standortklasse).
• Pro: Weniger Einträge, bessere Skalierung.
• Contra: Erhöht Exposition, wenn Summaries zu grob sind; erfordert sehr saubere Segmentierung und Firewall-Policies.

Muster 3: AllowedIPs minimal, Routing entscheidet (für große Umgebungen)

• Beschreibung: AllowedIPs enthält primär nur die Tunnel-IP(s) bzw. ein sehr begrenztes Overlay-Präfix, während BGP/Policies die LAN-Präfixe verteilen.
• Pro: Reduziert AllowedIPs-Komplexität, skaliert besser in großen Netzen.
• Contra: Verlangt konsequente Routing- und Firewall-Policy-Disziplin, sonst wird die Reichweite zu groß.

Skalierungsgrenzen: Wo WireGuard im Enterprise „wehtun“ kann

WireGuard ist performant, aber Skalierung ist nicht nur Durchsatz. In Enterprise-Site-to-Site treten Grenzen meist an organisatorischen und operativen Punkten auf:

• Konfigurationsmanagement: Viele Peers bedeuten viele Keys und AllowedIPs. Ohne zentralen Workflow (GitOps/IaC/Controller) steigt Drift.
• Key Rotation: Statische Peer-Keys müssen rotierbar sein. Rotation ist in großen Netzen ohne Automatisierung riskant.
• Adressüberlappungen: Branch-Netze mit gleichen RFC1918-Präfixen (z. B. „alle haben 192.168.1.0/24“) sind Gift für AllowedIPs und Routing – hier brauchen Sie NAT, VRFs oder eine saubere Re-IP-Strategie.
• Multi-ISP und Degradation: Ohne Hysterese und Health-Checks entstehen Flaps bei wechselnder Underlay-Qualität.
• Observability: WireGuard ist minimalistisch; Sie müssen Telemetrie aus System, Routing und Flow-Logs ergänzen, um Root Causes zu finden.

Failover ohne Flapping: Dual Uplinks und Dual Hubs mit WireGuard

WireGuard-Roaming hilft bei wechselnden Client-IPs, ersetzt aber kein sauberes Failover-Design für Site-to-Site. Für stabile Umschaltung brauchen Sie deterministische Preferenzen und Hysterese.

• Primary/Secondary statt „alles aktiv“: Besonders bei stateful Firewalls/NAT ist deterministische Pfadwahl stabiler als ECMP.
• Health-Gating: Routen/Announcements nur aktiv, wenn Servicepfade gesund sind (DNS/TCP/HTTP-Checks), nicht nur „Interface up“.
• Hold-down für Failback: Rückschaltung erst nach stabilem Green-Fenster, sonst Ping-Pong.

NAT, Keepalive und Real-World Underlays

In mobilen oder providergeprägten Netzen (CGNAT, Hotel-WLAN) laufen UDP-Mappings aus. Für Site-to-Site über solche Underlays kann Persistent Keepalive entscheidend sein, um den Tunnel „warm“ zu halten.

• Wann nötig: Wenn ein Peer hinter NAT sitzt und kaum Traffic erzeugt (Idle-Phasen).
• Trade-off: Zu häufige Keepalives erzeugen unnötigen Traffic; zu seltene führen zu „nach Idle tot“.
• Monitoring: Messen Sie Idle-Drops und Reconnect-Raten, um Keepalive-Werte datengetrieben zu setzen.

MTU/MSS und PMTUD: Stabilität für BGP, TLS und große Transfers

Encapsulation senkt die effektive MTU. Wenn PMTUD durch gefiltertes ICMP scheitert, entstehen Blackholes. Besonders kritisch ist das bei TCP-basierten Control-Planes (BGP), bei TLS-Handshakes und bei großen Transfers. PMTUD-Hintergründe: RFC 1191 und RFC 8201.

• Konservative MTU pro Profil: Einheitlich für alle Standorte oder pro Underlay-Klasse (Internet vs. PPPoE vs. LTE).
• MSS-Clamping: Für TCP-Traffic sinnvoll, damit Segmente nach Encapsulation nicht fragmentieren.
• ICMP gezielt erlauben: PMTUD braucht ICMP/ICMPv6, sonst entstehen schwer debugbare Fehler.

Security und Audit-Readiness: WireGuard Site-to-Site als „Produkt“

In Enterprise-Umgebungen muss Site-to-Site nicht nur funktionieren, sondern prüfbar sein. Das betrifft insbesondere Key Management und AllowedIPs-Governance.

• Ownership: Jeder Peer-Key hat einen Owner (Site/Team), ein Ticket/Change-Referenz und einen Zweck.
• Rezertifizierung: AllowedIPs und Routen werden regelmäßig überprüft; Ausnahmen haben Enddatum.
• Rotation/Revocation: Prozesse für Key Rotation und schnelles Offboarding (z. B. bei Device Loss).
• Segmentierung: VRFs/Zonen und servicebasierte Firewalls verhindern, dass „Routing“ automatisch „Zugriff“ bedeutet.

Als Architekturleitplanke für „minimale Rechte“ und „kontinuierliche Verifikation“ ist NIST SP 800-207 hilfreich, auch wenn WireGuard selbst kein Zero-Trust-System ist.

Observability: Was Sie messen müssen, um Skalierung zu beherrschen

WireGuard liefert bewusst wenige Protokollsignale. Enterprise-Betrieb braucht deshalb ergänzende Telemetrie:

• Systemmetriken: CPU, PPS, Drops, Interface Errors, Memory, UDP Socket Counters.
• WireGuard-Status: Handshake-Zeitpunkte, Transfer-Zähler, Peer-Liveness-Indikatoren (als Basis, nicht als alleinige Wahrheit).
• Routingmetriken: BGP/OSPF Session State, Prefix Counts, Flap Rates, Withdraw/Announce Events.
• Flow-Logs: NetFlow/IPFIX oder Äquivalente, um Traffic-Muster und Anomalien zu erkennen.
• Synthetische Checks: DNS/TCP/HTTP-Checks über den Tunnel, um „Tunnel up, Service down“ zu erkennen.

Häufige Anti-Patterns bei WireGuard Site-to-Site

• AllowedIPs = „alles intern“: Erhöht Exposition und macht Audits schwer; besser: Segment-/Servicepräfixe.
• Adressüberlappungen ignorieren: Overlapping RFC1918 führt zu Routing- und Security-Problemen; lösen via Re-IP, NAT oder VRF-Isolation.
• Kein Rotation-/Offboarding-Prozess: Statische Keys bleiben jahrelang aktiv.
• Dual-ISP ohne Hysterese: Flapping bei Degradation, Sessions brechen, Rekonvergenz wird unruhig.
• MTU/PMTUD nicht standardisiert: Blackholes erzeugen „nur manche Apps“.
• Kein Prefix-Filter bei dynamischem Routing: Route Leaks und ungewollte Transitivität.

Checkliste: WireGuard Site-to-Site sauber skalieren

• Topologie wählen: Hub-and-Spoke als Default, Dual-Hub für Resilienz, Teil-Mesh nur für kritische Pfade.
• AllowedIPs-Strategie definieren: explizite Präfixe (klein), Summaries (mit Governance) oder minimal + Routing (groß).
• Routingmodell festlegen: statisch für kleine Netze, BGP über Tunnel für große Netze mit strikten Prefix-Filtern.
• Adressplanung prüfen: Overlaps vermeiden; sonst VRFs/NAT/Neuadressierung einplanen.
• HA/Failover stabilisieren: Primary/Secondary, Health-Gating, Hold-down, keine Ping-Pong-Failbacks.
• NAT/Keepalive planen: Persistent Keepalive dort einsetzen, wo UDP-Timeouts relevant sind.
• MTU/MSS standardisieren: konservative MTU, MSS-Clamping, PMTUD-fähige ICMP-Policy.
• Key Management operationalisieren: Provisioning, Rotation, Revocation, Ownership, Audit-Trails.
• Observability einbauen: Routing-, System- und Flow-Telemetrie plus synthetische Service-Checks.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.