February 26, 2026

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

„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.

Table of Contents

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

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

Routing: Der Client muss Ziele über das VPN routen (Split/Full korrekt), und das interne Netz muss Rückwege zum VPN-Clientnetz kennen.
Firewall/Policies: Der Traffic muss zwischen den richtigen Zonen erlaubt sein (Client-VPN-Zone ↔ App-/Data-Zone).
NAT: Es darf kein ungewolltes NAT den Datenverkehr verändern oder Selektoren brechen.
Namensauflösung: DNS muss zu Routing und Policies passen, sonst wirkt „alles tot“, obwohl IP-Verbindungen gehen würden.

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:

Geht gar nichts intern? (z. B. weder Ping noch HTTPS zu irgendeinem internen Ziel)
Gehen manche Ziele, andere nicht? (z. B. Intranet geht, Fileserver nicht)

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

Split Tunnel: Sie müssen Routen zu internen Netzen sehen (z. B. 10.10.0.0/16 via VPN-Interface).
Full Tunnel: Default Route (0.0.0.0/0) zeigt auf das VPN-Interface; zusätzlich muss DNS passend gesetzt sein.

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

Falsches Profil: Nutzer ist im falschen VPN-Profil (z. B. „Internet-only“ statt „Corp“), bekommt keine Routen gepusht.
Adresskonflikt: Das lokale Heimnetz nutzt denselben IP-Bereich wie das Firmennetz (z. B. 192.168.0.0/24). Dann geht Traffic ins lokale LAN statt ins VPN.
Mehrere VPNs: Parallel aktive VPNs erzeugen Routingkonflikte oder verändern DNS.

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

Kennt das interne Netzwerk eine Route zum VPN-Adresspool? (z. B. 10.8.0.0/24 via VPN-Gateway)
Ist das VPN-Gateway wirklich der Rückweg? (z. B. Server-Default-Gateway zeigt auf ein anderes Firewall-Cluster)
Gibt es asymmetrische Pfade? (z. B. Hinweg über Gateway A, Rückweg über Gateway B)

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:

Eine VPN-Zone oder ein VPN-Interface (z. B. tun0, vti0, ssl.root)
Interne Zonen (User, App, Data, Mgmt)
Regeln, die Traffic zwischen diesen Zonen erlauben oder blockieren

Die drei wichtigsten Policy-Fragen

Von welcher Zone kommt der VPN-Client wirklich? (VPN-Zone, nicht WAN)
In welche Zielzone geht der Traffic? (App-Zone vs. Server-Zone vs. Mgmt)
Welche Regel matcht? (Policy-ID/Rule-Name; Deny by default?)

Typische Policy-Stolperfallen

Zu restriktive Regeln: HTTPS erlaubt, aber DNS oder Kerberos/LDAP fehlt – Anwendungen wirken „kaputt“.
Falsches Zielobjekt: Regel erlaubt 10.10.0.0/24, Ziel liegt aber in 10.10.1.0/24.
Admin-Zone geschützt: Standardnutzer dürfen nicht in Management-Netze (korrekt), melden aber „VPN geht nicht“.

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:

Ungewolltes Source NAT: VPN-Client-Traffic wird beim Übergang in interne Zonen genattet (z. B. auf eine Interface-IP). Das kann Policies, Logging und (bei policy-based IPsec) sogar Selektoren brechen.
Fehlende NAT-Regel bei Full Tunnel: Wenn Clients über VPN ins Internet sollen, fehlt Masquerading/NAT – dann geht intern evtl. etwas, aber Internet nicht (oder umgekehrt je nach Design).

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.

Split Tunnel + DNS: Interne Domains müssen über interne Resolver auflösbar sein, und der Weg zum Resolver muss geroutet sein.
Full Tunnel + DNS: DNS muss konsistent über den Tunnel laufen, sonst entstehen Leaks oder falsche Antworten.

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

Schnelle DNS-Tests

Auf dem Client: Wird der interne DNS-Server genutzt?
Auf dem Client: Löst der interne Hostname auf eine interne IP auf?
Auf dem Gateway: Gibt es Regeln, die DNS vom VPN-Pool zum internen Resolver erlauben?

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.

Symptom: Ping mit kleinen Paketen geht, große Transfers scheitern; HTTPS lädt teilweise; SMB bricht ab.
Fix: MSS-Clamping auf dem Gateway, konservative Tunnel-MTU, PMTUD nicht blockieren.

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

Traffic Selectors/Proxy IDs müssen exakt spiegeln (lokales Subnet ↔ remote Subnet).
Wenn NAT die Quell-IP verändert, passt der Selector nicht mehr und Traffic wird verworfen.
Ergebnis: SAs existieren, aber nur für andere Netze oder gar nicht für den benötigten Traffic.

Route-based IPsec (VTI)

Child SA kann stehen, aber ohne Route über das Tunnelinterface geht kein Traffic.
Routingtabellen auf beiden Seiten müssen die richtigen Prefixes über VTI zeigen.
Bei dynamischem Routing (z. B. BGP) muss Nachbarschaft über das VTI funktionieren und in Policies erlaubt sein.

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:

Problem tritt nur nach Failover auf oder nur bei bestimmten Links.
Ein Teil der Nutzer geht, ein Teil nicht (je nach Pfad).
Logs zeigen „no session“ oder unerwartete Drops ohne klare Policy-Regel.

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:

Kommt der Traffic vom VPN-Interface an?
Geht er Richtung internes Ziel raus?
Kommt eine Antwort zurück?
Wird die Antwort zurück in den Tunnel geschrieben?

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“

1) Client routet das Zielnetz über VPN (Route Table prüfen).
2) VPN-Client-IP/Pool ist bekannt und kollisionsfrei (kein Overlap mit Heimnetz).
3) Rückroute zum VPN-Pool existiert in den internen Netzen (oder NAT ist bewusst gesetzt).
4) Firewall-Regel erlaubt VPN-Zone → Zielzone (Ports/Services passend).
5) Policy-Deny-Logs prüfen (welche Regel blockt?).
6) NAT-Exemptions für interne Ziele vorhanden; keine „heimliche“ SNAT-Regel greift.
7) DNS: interner Resolver gesetzt, erreichbar und erlaubt; interne Namen lösen korrekt auf.
8) MTU/MSS: große Transfers testen, MSS-Clamping/PMTUD prüfen.
9) Bei Site-to-Site: Selektoren/Proxy IDs (policy-based) oder Routen/VTI (route-based) prüfen.
10) Bei HA/Dual-WAN: Symmetrie und Failover-Verhalten prüfen.

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:

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.