Site icon bintorosoft.com

VPN läuft, aber kein Zugriff: Routing- und Firewall-Checks

Red Snapper

Internet connections and wires connected to ports may be seen in the vertical server cabinet background image created using generative AI.

„VPN läuft, aber kein Zugriff“ ist eines der häufigsten Tickets im Netzwerkbetrieb: Der Tunnel steht, der Client zeigt „verbunden“, vielleicht sieht man sogar aktive SAs (bei IPsec) oder Handshakes (bei WireGuard/OpenVPN) – und trotzdem erreichen Nutzer keine internen Systeme. Genau hier trennt sich VPN-Grundwissen von echter Betriebspraxis: Ein VPN ist nur der geschützte Transportkanal. Ob Anwendungen funktionieren, entscheidet der Datenpfad danach: Routing, Rückwege, Firewall-Policies, NAT-Ausnahmen, DNS, MTU/MSS und in HA-Setups auch Symmetrie und State. Das Gute: Wenn der Tunnel wirklich steht, sind die Ursachen in der Regel nicht mehr „mystisch“, sondern lassen sich sehr systematisch eingrenzen. Dieser Leitfaden zeigt Ihnen die wichtigsten Routing- und Firewall-Checks, die Sie in 10–20 Minuten sauber abarbeiten können – herstellerneutral, aber mit konkreten Kommandos, Denkmodellen und typischen Fehlerbildern. Sie lernen außerdem, wie Sie Split Tunnel vs. Full Tunnel korrekt beurteilen, warum „Rückroute fehlt“ der Klassiker ist, wie NAT eine VPN-Verbindung unbemerkt sabotieren kann und welche Logsignale im Gateway Ihnen sofort sagen, ob Sie gerade ein Routing- oder ein Policy-Problem vor sich haben.

Bevor Sie starten: „Tunnel up“ bedeutet nicht „Traffic allowed“

Damit Anwendungen über VPN funktionieren, müssen mindestens vier Dinge gleichzeitig stimmen:

Merksatz: Erst Routen prüfen, dann Policies, dann NAT, dann DNS/MTU. Wer diese Reihenfolge einhält, spart in der Praxis sehr viel Zeit.

Schritt 1: Problem sauber klassifizieren

Bevor Sie Logs wälzen, klären Sie mit zwei Tests, wie groß das Problem ist:

Diese Unterscheidung entscheidet, ob Sie eher ein Routing-/DNS-Problem (alles betroffen) oder eher ein Firewall-/Policy-Problem (selektiv betroffen) vor sich haben. Zusätzlich wichtig: Tritt es bei allen Nutzern auf oder nur bei einzelnen? Wenn nur einzelne betroffen sind, prüfen Sie zuerst Profil/Gruppen/Assigned-IP und lokale Client-Routen.

Schritt 2: Clientseitige Routing-Checks (Split Tunnel vs. Full Tunnel)

Viele „kein Zugriff“-Tickets entstehen, weil der Client die Zielnetze gar nicht in den Tunnel routet. Das ist besonders häufig bei Split Tunnel, aber auch bei Full Tunnel, wenn Routen überschrieben oder durch andere VPNs/Interfaces verdrängt werden.

Windows: Routen prüfen

route print
ipconfig /all

macOS/Linux: Routen und DNS prüfen

netstat -rn
ip route
scutil --dns # macOS
resolvectl status # viele Linux-Systeme

Wenn die Route zu einem internen Ziel nicht über das VPN zeigt, ist der Rest (Firewall, NAT, Server) zweitrangig: Der Traffic verlässt den Client gar nicht über den Tunnel.

Typische clientseitige Fehlerbilder

Schritt 3: Rückwege prüfen (der Klassiker schlechthin)

Der häufigste Grund, warum „VPN verbunden, aber kein Zugriff“ ist: Die Gegenseite weiß nicht, wie sie zum VPN-Clientnetz zurückkommt. Beispiel: Der Client erhält 10.8.0.25/32, greift auf 10.10.20.10 zu, der Server antwortet aber über sein Default Gateway – und dieses Gateway kennt 10.8.0.0/24 nicht. Ergebnis: Anfrage geht hin, Antwort kommt nicht zurück.

Was Sie prüfen müssen

Praktischer Test: Traceroute in beide Richtungen

Wenn möglich, testen Sie von einem Host im internen Netz zurück zum VPN-Client (oder wenigstens zum VPN-Pool). Wenn das nicht möglich ist, machen Sie es indirekt über Logs/Packet Capture am VPN-Gateway: Sie müssen sehen, ob Antworten am Gateway ankommen und ob sie in den Tunnel zurückgehen.

Schritt 4: Firewall- und Policy-Checks auf dem Gateway

Wenn Routing stimmt (Client routet korrekt, Rückroute existiert), bleibt sehr oft eine Policy-Frage. Moderne Gateways haben typischerweise:

Die drei wichtigsten Policy-Fragen

Typische Policy-Stolperfallen

Best Practice ist, Policy-Denies gezielt auszuwerten: Wenn Sie Deny-Logs mit Source=VPN-Pool und Destination=interne Server sehen, ist das Problem nicht Routing, sondern Regelwerk.

Schritt 5: NAT prüfen (und warum NAT oft heimlich schuld ist)

NAT ist in vielen Firewalls standardmäßig aktiv. Das kann VPN-Traffic unbemerkt verändern. Zwei typische Szenarien:

NAT-Exemption als Standard für interne Ziele

Für klassische Remote-Access-VPNs ist es üblich, Traffic zu internen Netzen nicht zu natten. Sonst verlieren Sie die echte Client-IP, erschweren SIEM-Korrelation und laufen Gefahr, dass Security-Regeln nicht korrekt greifen. Wenn NAT nötig ist (z. B. Overlapping Networks), muss es explizit dokumentiert und sauber getestet sein.

Schritt 6: DNS-Checks (wenn IP geht, aber Name nicht)

Ein sehr typisches Fehlerbild: „VPN verbunden, aber Intranet geht nicht“. Dann stellt sich oft heraus: Per IP wäre es erreichbar, aber Namen werden nicht aufgelöst oder falsch aufgelöst.

DNS-Grundlagen sind in RFC 1034 und RFC 1035 beschrieben.

Schnelle DNS-Tests

Schritt 7: MTU/MSS und „es geht nur teilweise“

Wenn VPN „geht“, aber bestimmte Anwendungen hängen, große Downloads abbrechen oder nur manche Webseiten funktionieren, ist MTU/Fragmentierung ein Top-Kandidat. VPN-Tunnel erzeugen Overhead; Pfade wie PPPoE, LTE/5G oder zusätzliche Encapsulation reduzieren die effektive MTU weiter.

PMTUD ist in RFC 1191 (IPv4) und RFC 8201 (IPv6) beschrieben.

Schritt 8: Besonderheiten bei Site-to-Site – policy-based vs. route-based

Bei Standortvernetzung ist „Tunnel up, kein Traffic“ oft ein Selektoren- oder Routingproblem:

Policy-based IPsec

Route-based IPsec (VTI)

Schritt 9: Asymmetrisches Routing und HA – wenn es nach Failover „komisch“ wird

In HA-Setups (Active/Active, Dual-Hub, Dual-WAN) kann ein VPN technisch stehen, aber der Rückweg läuft über einen anderen Knoten. Stateful Firewalls droppen dann Sessions, oder NAT-States fehlen. Typische Indikatoren:

Fixes sind meist: Symmetrie erzwingen (PBR/ECMP-Strategie), Session-Stickiness am Load Balancer, State Sync prüfen, Failover testen (mit echten Applikationen, nicht nur „Tunnel up“).

Schritt 10: Packet Capture – der endgültige Beweis

Wenn Sie trotz Checks unsicher sind, liefert ein gezielter Packet Capture am Gateway schnell Klarheit:

Damit können Sie Routing vs. Policy vs. NAT eindeutig trennen. Besonders hilfreich ist ein Capture auf beiden Interfaces: VPN-Interface und internes Interface.

Die 20-Minuten-Checkliste für „VPN läuft, aber kein Zugriff“

Outbound-Links zur Vertiefung

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:

Lieferumfang:

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.

 

Exit mobile version