IPv4-Adresse passt, aber kein Zugriff: DNS vs. Gateway erkennen

Wenn die IPv4-Adresse passt, aber kein Zugriff möglich ist, wirkt das Problem zunächst widersprüchlich: Der Client hat eine gültige Adresse, die Subnetzmaske sieht korrekt aus, vielleicht wurde die Konfiguration per DHCP bezogen – und trotzdem funktionieren Webseiten, Cloud-Dienste oder interne Server nicht. In sehr vielen Fällen steckt hinter diesem Fehlerbild entweder ein DNS-Problem (Namensauflösung liefert keine oder falsche Antworten) oder ein Gateway-Problem (der Weg aus dem lokalen Netz fehlt oder ist blockiert). Beide Ursachen fühlen sich für Endnutzer gleich an („Internet geht nicht“), erfordern aber völlig unterschiedliche Maßnahmen. Wer sauber zwischen DNS und Gateway unterscheidet, spart im Troubleshooting oft 80 % der Zeit. In diesem Artikel lernst du, wie du systematisch erkennst, ob die Störung bei der Namensauflösung oder bei der Weiterleitung (Default Gateway/Routing) liegt – mit klaren Tests, typischen Symptomen, Interpretationen und praxisnahen Checklisten. Du bekommst außerdem Hinweise auf häufige Sonderfälle wie Captive Portals, Split-DNS im VPN, falsche Subnetzmasken und lokale Proxy-Einstellungen, die DNS- oder Gateway-Probleme imitieren können.

Warum „IPv4-Adresse passt“ nicht bedeutet, dass alles funktioniert

Eine gültige IPv4-Adresse zeigt nur, dass die lokale Schnittstelle konfiguriert ist. Sie sagt noch nichts darüber aus, ob der Client:

• sein Default Gateway erreichen kann,
• eine Route zu anderen Netzen hat,
• einen DNS-Resolver erreichen kann,
• korrekte DNS-Antworten bekommt,
• oder ob Firewalls/Policies den Verkehr blockieren.

Das Grundprinzip ist einfach: Für jede Verbindung müssen zwei Dinge stimmen – der Weg (Routing/Gateway) und die Zielinformation (DNS, wenn du Namen statt IPs nutzt). Fehlt eines davon, kommt es zu „kein Zugriff“.

DNS vs. Gateway: Die zwei häufigsten Hauptursachen

In der Praxis lassen sich die meisten Fälle in zwei Kategorien einteilen:

• DNS-Problem: IP-Verbindungen funktionieren grundsätzlich, aber Namen lassen sich nicht auflösen oder lösen auf falsche Ziele auf.
• Gateway-/Routing-Problem: Der Client kommt nicht aus dem lokalen Subnetz heraus oder Rückwege funktionieren nicht.

Der wichtigste Trick ist deshalb: Tests immer in IP-Tests und Name-Tests trennen. Wenn du nur Hostnamen testest, kannst du DNS und Routing nicht sauber auseinanderhalten.

Schritt-für-Schritt: Der schnellste Entscheidungsweg (3-Minuten-Diagnose)

Diese Abfolge ist bewusst kurz und praxistauglich. Sie eignet sich, wenn du in wenigen Minuten entscheiden willst, ob DNS oder Gateway das Problem ist.

• 1) Gateway anpingen: Wenn das Default Gateway nicht erreichbar ist, ist DNS zunächst zweitrangig.
• 2) Externe IP anpingen: Wenn das Gateway erreichbar ist, prüfe einen IP-Only-Test außerhalb deines Netzes.
• 3) Einen Hostnamen testen: Erst danach testest du einen Namen (z. B. eine Website oder einen internen FQDN).

Auswertung als Faustregel:

• Gateway nicht erreichbar → sehr wahrscheinlich Gateway/Layer-2/Maskenproblem.
• Gateway erreichbar, externe IP nicht erreichbar → Gateway/WAN/Routing/Firewall.
• Externe IP erreichbar, Hostname nicht → DNS-Problem (Resolver, Split-DNS, Captive Portal, Proxy).

Gateway erkennen: Woran du Default-Gateway-Probleme zuverlässig siehst

Das Default Gateway ist die Standardroute für Ziele außerhalb des lokalen Subnetzes. Ist es falsch, nicht erreichbar oder blockiert, kann der Client zwar lokal kommunizieren, aber nicht „nach draußen“. Typische Merkmale:

• Ping auf das Gateway schlägt fehl (Timeout oder „Host unreachable“).
• Kommunikation funktioniert nur im eigenen Subnetz (z. B. Drucker im gleichen VLAN), aber nicht darüber hinaus.
• Traceroute (falls genutzt) endet sehr früh, häufig bereits beim ersten Hop.
• Mehrere Geräte im gleichen Netz sind gleichzeitig betroffen (häufig zentraler Router/WAN).

Typische Ursachen für Gateway-Probleme

• Falsche Subnetzmaske: Der Client glaubt, Ziele seien lokal und versucht ARP statt Routing.
• Falsches Default Gateway: Gateway-IP liegt nicht im Subnetz oder zeigt auf ein falsches Gerät.
• VLAN/SSID falsch: Client hängt in einem Netz ohne Internet-Routing (z. B. Gastnetz, Quarantäne).
• Router/WAN down: ISP-Störung, PPPoE getrennt, Upstream-Interface down.
• Firewall-Regel am Gateway: Ausgangsverkehr wird geblockt oder NAT ist defekt.
• Asymmetrisches Routing: Hinweg über Gateway A, Rückweg über Gateway B – problematisch bei stateful Firewalls.

Subnetzmaske als Fehlerquelle: Ein schnelles Denkmodell

Eine falsche Maske kann „zufällig passend“ aussehen und trotzdem alles ruinieren. Die Entscheidung „lokal oder via Gateway“ basiert darauf, ob Ziel-IP und Quell-IP in dasselbe Subnetz fallen. Vereinfacht ist das ein bitweiser Vergleich:

$\mathrm{Netz}=\mathrm{IP}AND\mathrm{Maske}$

Wenn der Client durch eine zu große Maske annimmt, ein Ziel sei lokal, sendet er ARP-Anfragen statt Pakete ans Gateway. Das wirkt wie „kein Zugriff“, obwohl die IPv4-Adresse formal korrekt wirkt.

DNS erkennen: Woran du Namensauflösungsprobleme sicher identifizierst

DNS-Probleme sind besonders tückisch, weil sie oft wie „kein Internet“ wirken. Dabei ist das Routing häufig in Ordnung – nur die Übersetzung von Namen in IP-Adressen klappt nicht oder liefert falsche Ziele. Typische Merkmale:

• Ping/Verbindung auf IP-Adressen funktioniert, aber nicht auf Hostnamen.
• Webseiten zeigen „Server nicht gefunden“ oder Anwendungen melden „Name resolution failed“.
• Manche Namen funktionieren, andere nicht (Split-DNS, mehrere Resolver, unterschiedliche Zonen).
• Das Problem tritt häufig nach VPN-Verbindungsaufbau auf (DNS wird überschrieben).

Typische Ursachen für DNS-Probleme

• DNS-Server nicht erreichbar: Resolver-IP falsch, Routing zum Resolver fehlt, Firewall blockt UDP/TCP 53.
• Falscher DNS-Server: Externer Resolver für interne Namen oder umgekehrt (Split-DNS nicht korrekt).
• Captive Portal: In Gäste-WLANs wird DNS/HTTP umgeleitet, bis eine Anmeldung erfolgt.
• DNS-Cache: Veraltete Einträge oder negative Caches führen zu scheinbar zufälligen Fehlern.
• Mehrdeutige Antworten: Mehrere A-Records, Anycast, Load Balancer – einzelne Ziele sind gestört.
• Lokaler Proxy: Browser nutzt Proxy, der nicht erreichbar ist; DNS scheint „kaputt“, obwohl es ein Proxy-Thema ist.

Der wichtigste Test: Name vs. IP sauber trennen

Wenn du nur einen einzigen Test mitnehmen willst, dann diesen: Teste immer einmal denselben Dienst per IP und per Name. Das kann so aussehen:

• IP-Test: Verbinde dich mit einer bekannten Ziel-IP (z. B. internes System oder ein externer Dienst, sofern verfügbar).
• Name-Test: Verbinde dich mit demselben Dienst über seinen Hostnamen.

Interpretation:

• IP geht, Name geht nicht: DNS (oder Proxy) ist sehr wahrscheinlich.
• Name geht, IP geht nicht: Ungewöhnlich, deutet oft auf Testfehler, ACLs oder spezielle Redirects hin.
• Beides geht nicht: Gateway/Routing, Firewall oder generelle Netzstörung.

Praktische Checkliste: So erkennst du in 10 Punkten DNS- vs. Gateway-Probleme

• Gateway erreichbar? Wenn nein: zuerst Layer 2/3 klären.
• Eine externe IP erreichbar? Wenn nein: Routing/WAN/Firewall/NAT prüfen.
• DNS-Server erreichbar? Wenn nein: DNS wirkt kaputt, ist aber oft ein Routing/Firewall-Thema zum Resolver.
• Nur Namen betroffen? Wenn ja: DNS/Proxy sehr wahrscheinlich.
• Nur bestimmte Namen betroffen? Split-DNS, Zonenproblem oder Resolver-Reihenfolge.
• Nur nach VPN? DNS-Override, Route-Metrik, Adressüberlappung.
• Nur im WLAN? Captive Portal, SSID im falschen VLAN, Client-Isolation.
• Mehrere Geräte gleichzeitig? Zentrale Ursache (Gateway, DHCP, zentraler DNS, ISP).
• IP-Adresse aus DHCP? Prüfen, ob DHCP-Optionen (Gateway/DNS) korrekt geliefert werden.
• Proxy-Einstellungen aktiv? Ein falscher Proxy erzeugt „kein Zugriff“, obwohl IPv4/DNS ok ist.

Sonderfall 1: Gateway ist erreichbar, aber „Internet“ nicht – warum das nicht DNS sein muss

Wenn du das Gateway anpingen kannst, ist der erste Hop ok. Trotzdem kann die Verbindung danach scheitern. Typische Gründe, die häufig mit DNS verwechselt werden:

• WAN-Interface down: Der Router ist da, aber die Upstream-Verbindung nicht.
• Keine Default Route am Router: Ohne Default Route kommt nichts ins Internet.
• NAT-Probleme: Ausgangsverbindungen werden nicht korrekt genattet, besonders nach Konfigänderungen.
• Firewall-Policy: Erlaubt DNS, blockt aber Web (TCP/443) – dann „DNS geht“, aber Browser nicht.
• Provider-DNS-Block/Filter: In manchen Umgebungen werden fremde DNS-Resolver blockiert oder umgeleitet.

Sonderfall 2: IP geht, aber Browser nicht – Proxy und HTTPS als häufige Imitatoren

Viele Anwender testen „Internet“ über den Browser. Wenn der Browser nicht lädt, wird schnell DNS verdächtigt. In Unternehmensumgebungen ist aber häufig ein Proxy oder TLS-Inspection der Grund:

• Proxy nicht erreichbar: Browser hängt, während Ping/andere Tools funktionieren.
• Falsches Proxy-Autokonfigurationsskript (PAC): Nach Netzwechsel greift eine falsche Proxyregel.
• Zertifikats-/TLS-Probleme: Wirkt wie „kein Zugriff“, ist aber ein Trust- oder Inspection-Thema.

Der Kern: Ein Browserfehler ist nicht automatisch DNS. Deshalb sind IP-Only-Tests und Porttests so wertvoll.

Sonderfall 3: VPN und Split-DNS – wenn intern oder extern „verschwindet“

VPNs ändern häufig gleichzeitig Routing und DNS. Dadurch entstehen Mischbilder:

• Full Tunnel: Alles geht über VPN. Wenn der Tunnel wackelt, wirkt es wie „kein Internet“.
• Split Tunneling: Nur bestimmte Netze gehen über VPN. Falsche Routen führen zu Zugriffslücken.
• Split-DNS: Interne Namen müssen über interne Resolver laufen, externe über öffentliche Resolver. Falsche Reihenfolge bricht entweder intern oder extern.
• Adressüberlappung: Lokales Netz (z. B. 192.168.0.0/24) überlappt mit Firmennetz – dann werden Ziele falsch als „lokal“ behandelt.

Sonderfall 4: Captive Portal – „IPv4 passt“, aber Zugriff wird umgeleitet

In Hotels, Gäste-WLANs oder öffentlichen Netzen ist Captive Portal sehr verbreitet. Der Client hat eine IPv4-Adresse und kann vielleicht sogar DNS-Anfragen senden, aber HTTP/HTTPS wird umgeleitet oder blockiert, bis eine Anmeldung erfolgt.

• Indiz: Andere Geräte zeigen eine Login-Seite, dein Gerät nicht.
• Indiz: Nur Web funktioniert nicht, aber lokale Ziele/ICMP teilweise schon.
• Indiz: DNS liefert unerwartete Ziele oder NXDOMAIN für viele Domains.

Fehlerbilder als Entscheidungshilfe: Häufige Kombinationen und ihre Bedeutung

• Gateway nicht pingbar + lokale Geräte auch nicht erreichbar → VLAN/Layer-2/Maskenproblem.
• Gateway pingbar + externe IP nicht erreichbar → WAN/Routing/Firewall/NAT am Gateway.
• Externe IP erreichbar + Hostnamen nicht → DNS/Resolver/Proxy.
• Einige Websites gehen, andere nicht → DNS (selektiv), MTU/PMTUD, Proxy-Regeln oder Filter.
• Nur nach VPN kein Zugriff → DNS-Override, Route-Metrik, Split-Tunnel-Regeln oder Overlap.

Outbound-Links für verlässliche Grundlagen

• DNS-Konzepte und Architektur (RFC 1034)
• DNS-Protokollspezifikation (RFC 1035)
• ICMP-Grundlagen für Diagnostik (RFC 792)
• ARP: Address Resolution Protocol (RFC 826)
• Anforderungen an IPv4-Router (RFC 1812)
• RFC Editor (zentrale Quelle für Internet-Standards)

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.