February 24, 2026

Cloud Connectivity Troubleshooting: VPN, Peering und Routing prüfen

Cloud Connectivity Troubleshooting ist in hybriden IT-Architekturen eine der häufigsten Ursachen für „mysteriöse“ Störungen: Anwendungen sind in der Cloud erreichbar – aber nur aus manchen Netzen. VPN-Tunnel sind „up“, trotzdem gibt es Timeouts. Peering-Verbindungen bestehen, aber bestimmte Subnetze bleiben unsichtbar. Oder Routing wirkt korrekt, doch Sessions brechen ab und Firewalls melden State-Probleme. Der Grund ist, dass Cloud-Konnektivität aus mehreren Schichten besteht, die ineinandergreifen: Underlay (Internet/Carrier), Tunnel- oder Peering-Transport (IPsec, GRE, Cloud-Backbone), Routing (statisch oder dynamisch via BGP), Security (Security Groups, NACLs, Firewalls), DNS sowie häufig NAT und Overlays (SD-WAN, Zero Trust). Kleine Abweichungen – etwa eine Route, die im On-Prem-Core fehlt, ein falsches BGP-Filter, ein asymmetrischer Pfad über zwei Gateways oder eine MTU, die durch Encapsulation zu klein wird – reichen aus, um die Verbindung scheinbar „teilweise“ kaputt zu machen. Dieser Leitfaden zeigt eine praxiserprobte Vorgehensweise, mit der Sie VPN, Peering und Routing sauber prüfen, Fehler schnell eingrenzen und Beweise sammeln, die sowohl für interne Teams als auch für Provider oder Cloud-Support verwertbar sind.

Table of Contents

Erst trennen: Connectivity, Routing und Policy sind drei unterschiedliche Fehlerklassen

Viele Cloud-Störungen wirken gleich („geht nicht“), haben aber unterschiedliche Ursachen. Ein schneller Gewinn entsteht, wenn Sie die Symptome in eine der folgenden Klassen einsortieren:

Connectivity-Problem: Tunnel/Link kommt nicht hoch oder bricht ständig ab (IKE/IPsec, BGP-Session, Peering-State).
Routing-Problem: Tunnel ist up, aber Verkehr findet keinen Weg (fehlende Routen, falsche Prefixe, falscher Next-Hop, Blackhole).
Policy-/Security-Problem: Routing stimmt, aber Traffic wird geblockt (Security Groups, NACLs, Firewalls, UDR/Route Tables, Mikrosegmentierung).

In der Praxis ist „Tunnel up, aber nichts geht“ meist Routing oder Policy. „Nur eine Richtung geht“ ist oft Asymmetrie oder Stateful-Firewall. „Nur große Transfers hängen“ deutet häufig auf MTU/PMTUD hin.

Die typischen Cloud-Konnektivitätsmodelle und ihre Stolperfallen

Bevor Sie debuggen, klären Sie, welches Modell Sie haben. Das bestimmt die wahrscheinlichsten Fehlerquellen.

Site-to-Site IPsec VPN: On-Prem ↔ Cloud Gateway (klassisch, schnell implementiert, aber anfällig für MTU, NAT-T, IKE-Parameter und ISP-Schwankungen).
Private Peering/Backbone: Cloud-Provider-eigene Peering-Mechanismen oder dedizierte Verbindungen (stabiler, aber mit klaren Routing- und Filterregeln).
Hub-and-Spoke (Cloud Transit): Zentraler Hub (Transit Gateway/Virtual WAN/Cloud Router) verbindet mehrere VPC/VNets/Projekte und On-Prem.
Multi-Cloud oder Multi-Region: Mehrere Hubs, Peering zwischen Clouds/Regionen, häufig BGP und strenge Route-Policies.

Je komplexer das Modell, desto wichtiger wird konsistentes Routing, klare Route-Propagation und eine definierte „Source of Truth“ für IP-Adressplanung und Prefix-Listen.

Standard-Workflow: Cloud Connectivity Troubleshooting als Runbook

Der folgende Ablauf ist bewusst herstellerneutral. Er funktioniert für AWS, Azure, GCP und private Clouds gleichermaßen. Ziel ist, schnell von Symptomen zu Fakten zu kommen.

Schritt: Scope definieren

Welche Richtung ist betroffen (On-Prem → Cloud, Cloud → On-Prem, beides)?
Welche Quellen und Ziele (Subnetze, IPs, Ports, Protokolle)?
Ist es ein einzelnes Subnetz/Service oder „alles“?
Seit wann tritt es auf, und gab es Changes (Routing, Firewall, Cloud-Policy, ISP)?

Schritt: Datenpfad skizzieren

On-Prem: Client → Access → Core → Edge Firewall/Router → VPN/Peering
Cloud: Gateway/Hub → Route Table → NACL/SG/Firewall → Workload
Rückweg: exakt mitdenken (Asymmetrie ist häufig der Kernfehler)

Schritt: Health-Status der Verbindung prüfen

IPsec: IKE-SA und IPsec-SA stabil? Rekey-Events? DPD/Keepalive?
BGP: Session up? Prefix-Anzahl plausibel? Flaps?
Peering: Status „Active“? Route-Exchange/Propagation aktiv?

Schritt: Routing verifizieren (beide Richtungen)

On-Prem Routing Table: Existiert eine Route zum Cloud-Subnetz via den richtigen Next-Hop?
Cloud Route Tables: Existiert eine Route zum On-Prem-Prefix via Gateway/Hub?
Propagation/Association: Ist die Route Table am richtigen Subnetz/VNet/Attachment gebunden?
BGP Policies: Filtern Sie versehentlich Prefixe weg (in/out)?

Schritt: Security und NAT prüfen

Cloud Security Groups/NACLs oder Azure NSGs: Ports/Protokolle erlaubt?
On-Prem Firewall: Stateful Regeln, Zone-Policies, NAT-Regeln, Session-Timeouts?
NAT in der Cloud oder On-Prem: Verändert es die Quell-IP und bricht dadurch Rückwege/Policies?

Schritt: MTU/PMTUD und Fragmentierung prüfen

Nur große Transfers betroffen? HTTPS-Login hängt? SMB/DB-Replikation bricht ab?
Encapsulation (IPsec/GRE/SD-WAN) reduziert effektive MTU.
ICMP „Fragmentation Needed“ wird häufig geblockt – dann scheitert Path MTU Discovery.

Schritt: Beweise sammeln (messbar statt Bauchgefühl)

Traceroute/MTR aus beiden Richtungen (On-Prem und Cloud-VM) – soweit möglich
Routing Table Dumps (On-Prem und Cloud Route Table Export)
BGP Neighbor/Route Summaries (Prefix Counts, Flaps, Policies)
Firewall Logs (Deny, NAT Hits, Session Drops)
Paketmitschnitt an einem definierten Punkt (Edge oder Cloud Firewall) bei schwer greifbaren Problemen

VPN Troubleshooting: IPsec/IKE, Rekey und häufige Ursachen

Beim Site-to-Site VPN sind zwei Ebenen entscheidend: IKE (Aushandlung) und IPsec (Datenkanal). Ein Tunnel kann „up“ sein, aber trotzdem keinen Traffic transportieren, wenn SAs nicht passen oder Policies zu eng sind.

Parameter-Mismatch

Symptom: Tunnel kommt nicht hoch oder flapped beim Rekey.
Ursachen: IKE-Version (v1/v2), Proposal/Cipher, PFS, Lifetime, Hash, DH-Gruppe, PSK/Zertifikate.
Fix: Parameter harmonisieren und Rekey-Intervalle sauber abstimmen (Lifetimes nicht „gegeneinander“ konfigurieren).

Als Protokollreferenz sind RFC 7296 (IKEv2) und für IPsec-Architektur RFC 4301 hilfreich.

NAT-T und Provider-Edge

Symptom: VPN läuft im Büro, aber nicht aus bestimmten Internetanschlüssen oder nach Providerwechsel.
Ursachen: NAT zwischen den Peers, UDP/500 und UDP/4500 blockiert, aggressive Timeouts in Carrier-NAT.
Fix: NAT-T aktiv, Ports freischalten, DPD/Keepalives sinnvoll konfigurieren.

DPD/Keepalive und Idle Timeouts

Symptom: Tunnel ist „up“, aber beim ersten Traffic nach Ruhephase Timeouts; danach wieder ok.
Ursache: Stateful Device oder ISP löscht UDP-State bei Inaktivität; SAs existieren logisch, aber Pakete kommen nicht durch.
Fix: Keepalives, DPD und ggf. kurze Idle-Intervalle oder regelmäßige Health-Probes.

Selektive Erreichbarkeit: „Nur manche Subnetze“

Symptom: Subnetz A funktioniert, Subnetz B nicht.
Ursachen: Traffic Selectors/Proxy IDs zu eng, fehlende Routen, falsche ACLs/NAT, fehlende Route Propagation.
Fix: Selectors erweitern oder route-based VPN nutzen; Prefix-Liste end-to-end prüfen.

Peering Troubleshooting: Wenn „private Verbindung“ trotzdem nicht routet

Peering – innerhalb einer Cloud oder zwischen Netzdomänen – ist oft stabiler als IPsec, aber dafür strikt in Routing und Policy. Typische Fehler sind fehlende Route Tables, fehlende Propagation oder überlappende IP-Adressräume.

Überlappende IP-Adressräume

Symptom: Peering steht, aber Traffic geht „in die falsche Richtung“ oder wird verworfen.
Ursache: On-Prem und Cloud nutzen identische oder sich überschneidende RFC1918-Prefixe (z. B. 10.0.0.0/8 überall).
Fix: IP-Adressplanung bereinigen oder Übergangslösung mit NAT/Translation – idealerweise mit klarer Roadmap.

Private Adressräume sind in RFC 1918 beschrieben – die operative Konsequenz ist: ohne saubere Planung wird Hybrid-Routing teuer.

Route Tables und Propagation

Symptom: Cloud-Workloads in Subnetz X erreichen On-Prem, Subnetz Y nicht.
Ursache: Subnetze sind an unterschiedliche Route Tables gebunden; Propagation/Association fehlt; Attachment nicht in der richtigen Route Table.
Fix: Route Table Bindings und Propagation konsistent machen, Änderungen dokumentieren.

Transitives Routing: Erwartung vs. Realität

Viele erwarten, dass Peering „transitiv“ ist (A↔B↔C). In vielen Clouds gilt das nicht automatisch oder nur über spezielle Transit-Konstrukte. Ergebnis: A kann B erreichen, B kann C erreichen, aber A kann nicht C erreichen.

Fix: Transit-Hub (Cloud Transit/Virtual WAN/Transit Gateway) nutzen oder Peering-Design explizit transitiv planen.

Routing Troubleshooting: Statisch vs. BGP, Filter und Blackholes

Routing ist der häufigste Root Cause bei „Tunnel up, aber Service down“. Der Schlüssel ist, Routing nicht nur „irgendwo“ zu prüfen, sondern genau dort, wo Forwarding entscheidet: am Edge und im Cloud-Hub.

Statische Routen: Einfach, aber fehleranfällig

Typische Fehler: falscher Next-Hop, Route nur in eine Richtung, Route vergessen nach Subnetz-Erweiterung, falsche Priorität/Administrative Distance.
Blackhole-Routen: bewusst oder unbewusst; sehr häufig bei Summarization ohne passende spezifische Routen.

BGP: Dynamisch, skalierbar – aber Policy-getrieben

BGP ist in Cloud-Hybrid-Szenarien Standard, weil es Prefixe dynamisch verteilt. Dafür müssen Policies sauber sein:

Inbound Filter: Blocken Sie versehentlich On-Prem-Prefixe oder Cloud-Prefixe?
Outbound Filter: Advertisen Sie alles Notwendige – aber nicht zu viel (Least Privilege auch im Routing)?
Prefix Limits: Manche Setups droppen bei Überschreitung oder schalten Sessions ab.
As-PATH/LocalPref/Med: beeinflusst Pfadwahl, kann asymmetrische Wege erzeugen.

Als Hintergrund für BGP ist RFC 4271 die maßgebliche Referenz.

Asymmetrisches Routing: Der stille Killer

Wenn Hin- und Rückweg unterschiedliche Pfade nehmen, ist das für viele Anwendungen ok – aber nicht für stateful Firewalls, NAT und manche Load Balancer. Dann sehen Sie typische Symptome: SYN geht raus, SYN/ACK kommt nicht zurück (oder wird gedroppt), oder Sessions brechen nach Sekunden ab.

Indizien: Firewall-States passen nicht, Logs zeigen „asymmetric route“, TCP Retransmissions steigen, Einweg-Audio bei VoIP.
Fix: Pfade symmetrieren (Policy Routing, BGP Attributes), HA/State-Sync korrekt, NAT konsistent.

Security Checks: Warum Routing stimmt, aber nichts durchkommt

In Cloud-Umgebungen ist Security oft „layered“: Security Groups/NSGs, NACLs, zentrale Firewalls, Mikrosegmentierung, WAF, Private Endpoints. Dadurch kann ein einziger fehlender Port die komplette Anwendung blockieren.

Stateful vs. stateless: Security Groups/NSGs sind häufig stateful, NACLs häufig stateless. Stateless bedeutet: Rückverkehr muss explizit erlaubt sein.
Ephemeral Ports: Viele Anwendungen benötigen Rückverkehr auf dynamischen Ports. Wenn nur „443 out“ erlaubt ist, kann der Rückweg trotzdem scheitern.
DNS und Identity: Häufig wird DNS (53) oder NTP (123) vergessen, was TLS/SSO indirekt bricht.

MTU/PMTUD in der Cloud: Wenn „klein geht, groß hängt“

Cloud-Konnektivität nutzt oft Encapsulation (IPsec, GRE, VXLAN, SD-WAN). Jeder Header reduziert die effektive MTU. Wenn PMTUD nicht sauber funktioniert, scheitern große Pakete – typisch bei TLS-Handshakes, SSO-Redirects, SMB oder API-Requests mit großen Payloads.

Indizien: kleine Pings gehen, große Payloads hängen; TCP Retransmissions bei großen Segmenten; sporadische Timeouts.
Fix: MTU entlang des Pfades prüfen, ICMP nicht pauschal blocken, MSS-Clamping in VPN/Firewalls nutzen.

Für PMTUD ist RFC 1191 ein guter Einstieg.

Cloud-spezifische Diagnostik: Praktische Tools und Messpunkte

In der Cloud haben Sie oft bessere Telemetrie als On-Prem – wenn Sie sie nutzen. Eine robuste Praxis ist, mindestens eine „Diag-VM“ oder ein Test-Endpoint pro Segment zu betreiben, um Messungen aus Cloud-Sicht durchführen zu können.

Ping/MTR/Traceroute aus Cloud-VM und On-Prem (Richtung vergleichen)
Flow Logs (VPC/VNet Flow Logs) zur Validierung von Accept/Deny auf Netzwerkebene
Gateway-/Tunnel-Logs (IPsec/BGP Events, Rekey, DPD, Flaps)
Route Table Exports (welche Route wird wirklich verwendet?)

Für praxisnahe Cloud-Dokumentation zu Connectivity und Routing sind die offiziellen Quellen sehr hilfreich:

Beispiel-Checkliste für den Incident: „On-Prem erreicht Cloud-Service nicht“

Ist der Tunnel/Peering-Link up (IKE/IPsec/BGP/Peering-State)?
Existiert On-Prem eine Route zum Cloud-Subnetz über den richtigen Edge?
Existiert in der Cloud eine Route zum On-Prem-Prefix (und ist sie am richtigen Subnetz gebunden)?
Ist Rückweg identisch (Asymmetrie ausgeschlossen)?
Blockt Security Group/NSG/NACL oder On-Prem Firewall den Port/Protokoll?
Gibt es NAT, das Quell-IP verändert und Policies/Return-Routes bricht?
Gibt es MTU/PMTUD-Symptome (große Payloads hängen)?
Gibt es DNS-Abweichungen (On-Prem löst andere IPs auf als Cloud)?

Best Practices: So bauen Sie Cloud-Konnektivität troubleshootbar

Adressplanung diszipliniert: Keine Überlappungen, klare Prefix-Listen pro Domäne, dokumentierte Summaries.
Ein Transit-Design: Hub-and-Spoke mit klaren Regeln statt „Wildwuchs“ aus Peerings.
Routing-Policies versionieren: BGP Filter, Route Tables und Attachments als Code (IaC) mit Review-Prozess.
Observability: Flow Logs, Gateway-Logs, BGP-Status, Metriken zu Tunnel-Stabilität und Drops.
MTU bewusst setzen: Overhead einkalkulieren, MSS-Clamping standardisieren, ICMP sinnvoll erlauben.
Redundanz testen: Zweiter Tunnel/Link ist nur dann Redundanz, wenn Failover-Pfade und Routen sauber getestet sind.
Diag-Endpoints: Test-VMs oder kleine „probe“-Instanzen in jedem Segment für schnelle Messungen.

Outbound-Links zur Vertiefung

Checkliste: Cloud Connectivity Troubleshooting für VPN, Peering und Routing

Scope klären: welche Subnetze, welche Richtung, welche Ports/Protokolle, seit wann, welche Changes?
Health prüfen: IPsec (IKE/IPsec SAs, Rekey, DPD), BGP (Session, Prefix Counts, Flaps), Peering (Active, Propagation).
Routing beidseitig prüfen: On-Prem RIB/FIB und Cloud Route Tables (Bindings/Associations/Propagation).
Prefix-Listen/Filter prüfen: BGP in/out Filter, Prefix Limits, Summarization/Blackholes.
Asymmetrie prüfen: Hin- und Rückweg identisch? Stateful Firewall/NAT kompatibel?
Security prüfen: SG/NSG/NACL, On-Prem Firewall, Ephemeral Ports, Richtungen und Stateful/Stateless-Verhalten.
NAT prüfen: Quell-IP-Änderung, Return-Routes, Policy-Matches, Split-Tunnel vs. Full-Tunnel.
MTU/PMTUD prüfen: große Payloads, TLS/SSO-Hänger, MSS-Clamping, ICMP-Handling.
Beweise sammeln: Flow Logs, Gateway-Logs, Routing-Exports, Firewall-Hits, kurzer Packet Capture am Engpasspunkt.
Fix verifizieren: identischer Testfall, Vorher/Nachher messen, Dokumentation/IaC aktualisieren und Monitoring/Alerts für Tunnel- und Routing-Drift setzen.

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.