Cisco-Router-Konfiguration für Büro-Internet: NAT, DNS und Basis-Policies

Für stabiles Büro-Internet auf Cisco-Routern brauchen Sie drei Dinge, die sauber zusammenspielen: korrektes NAT (damit private Netze ins Internet kommen), funktionierende DNS-Auflösung (damit Dienste nicht „gefühlt langsam“ sind) und Basis-Policies (damit Gäste/IoT nicht ins interne Netz greifen und das Management abgesichert bleibt). Dieser Leitfaden zeigt eine praxiserprobte Grundkonfiguration für typische Office-Szenarien – inklusive erwarteter Ergebnisse und schneller Verifikation per CLI.

Voraussetzungen: Was Sie vor der Konfiguration kennen müssen

Viele „Internet geht nicht“-Fehler entstehen durch falsche Providerdaten oder unklare LAN-Struktur. Klären Sie daher vorab WAN-Übergabe und interne Netze.

• WAN: IP/Subnetz, Gateway, VLAN-Tagging oder PPPoE, MTU
• LAN: interne Subnetze/VLANs (z. B. Users, Guest, IoT)
• DNS: interne DNS-Server (empfohlen) oder externe Resolver
• Policy: Guest nur Internet, IoT eingeschränkt, Management nur aus MGMT-Netz

WAN-Basis: Interface, Default-Route und erste Pfadtests

Der Router muss zuerst selbst stabil „nach außen“ kommen. Ohne erreichbares Gateway und Default-Route funktioniert kein NAT und kein DNS-Forwarding zuverlässig.

Beispiel: WAN-Interface und Default-Route

interface GigabitEthernet0/0
 description WAN-ISP
 ip address 198.51.100.2 255.255.255.252
 no shutdown
ip route 0.0.0.0 0.0.0.0 198.51.100.1

Verifikation WAN (erwartete Ergebnisse)

• WAN-Interface ist up/up
• Gateway ist erreichbar (ARP/Ping)
• Default-Route zeigt auf den korrekten Next-Hop

CLI-Checks für WAN

show ip interface brief
show ip route 0.0.0.0
show ip arp | include 198.51.100.1
ping 198.51.100.1

NAT (PAT/Overload): Büro-Internet für private Netze

In Büros werden interne RFC1918-Netze über NAT Overload (PAT) ins Internet übersetzt. Entscheidend sind die Rollen „inside“ und „outside“ sowie eine NAT-ACL, die genau die Netze umfasst, die Internetzugang erhalten sollen.

Beispiel: NAT Overload für Users/Guest/IoT

interface GigabitEthernet0/0
 ip nat outside
interface GigabitEthernet0/1

ip nat inside
ip access-list standard NAT_INSIDE

permit 10.10.20.0 0.0.0.255

permit 10.10.50.0 0.0.0.255

permit 10.10.40.0 0.0.0.63
ip nat inside source list NAT_INSIDE interface GigabitEthernet0/0 overload

Erwartete Ergebnisse

• Bei aktivem Client-Traffic entstehen NAT-Translations
• Nur freigegebene Netze werden genattet (keine unerwünschten VLANs)
• Internet funktioniert aus den erlaubten VLANs stabil

CLI-Checks für NAT

show ip nat statistics
show ip nat translations
show running-config | include ip nat inside|ip nat outside|ip nat inside source

DNS: Warum „Internet langsam“ oft ein DNS-Problem ist

Wenn Webseiten „hängen“, liegt es häufig an langsamer oder falscher Namensauflösung. Für Büros ist ein klarer DNS-Plan wichtig: interne Resolver für interne Namen, optional Forwarding für externe Ziele. Der Router selbst braucht DNS nur, wenn er Namen auflösen soll (z. B. NTP-Server per FQDN).

DNS auf dem Router (nur wenn notwendig)

ip name-server 10.10.10.10
ip name-server 1.1.1.1
ip domain-name example.local

Praxisregel: DNS für Clients gehört meist nicht auf den Router

Üblicher ist, dass DHCP (Server) den Clients DNS-Server verteilt. Der Router stellt dabei „nur“ Routing, NAT und Policies bereit. In reinen Filialen ohne zentrale Dienste kann der Router-DNS jedoch hilfreich sein.

DNS-Verifikation (Router-Sicht)

ping 1.1.1.1
ping example.com

Basis-Policies: Guest isolieren und interne Netze schützen

Eine sinnvolle Basis-Policy im Büro ist die strikte Trennung von Guest. Gäste dürfen ins Internet, aber nicht auf interne Netze. Diese Regel reduziert Risiken deutlich und ist leicht zu implementieren.

Beispiel: Guest darf keine internen Netze erreichen

ip access-list extended ACL-GUEST-IN
 deny ip 10.10.50.0 0.0.0.255 10.10.0.0 0.0.255.255
 permit ip 10.10.50.0 0.0.0.255 any
interface GigabitEthernet0/1.50

ip access-group ACL-GUEST-IN in

Erwartete Ergebnisse

• Guest erreicht das Internet
• Guest erreicht keine internen Subnetze (Users/Server/Management)
• Policy ist nachvollziehbar (ACL-Hits steigen bei Test)

CLI-Checks für Policies

show access-lists
show running-config | include ip access-group

Management-Basis-Policy: SSH-only und Zugriff einschränken

Auch bei „nur Büro-Internet“ darf Management nicht offen sein. SSH-only und eine VTY-Access-Class sind Mindeststandard, damit der Router nicht aus beliebigen Netzen administriert werden kann.

Beispiel: SSH-only + Management-ACL

no ip http server
no ip http secure-server
ip ssh version 2
ip access-list standard MGMT_ONLY

permit 10.10.10.0 0.0.0.255

deny   any
line vty 0 4

transport input ssh

access-class MGMT_ONLY in

login local

exec-timeout 10 0

Optionaler Praxisbaustein: MTU/MSS für stabile Web- und VPN-Verbindungen

Wenn der WAN-Pfad PPPoE oder VPN enthält, können MTU-Probleme zu Timeouts führen. MSS-Clamping ist ein pragmatischer Fix, der häufig die Stabilität von HTTPS verbessert.

Beispiel: MSS-Clamping (optional)

interface GigabitEthernet0/1
 ip tcp adjust-mss 1360

End-to-End Abnahme: So prüfen Sie, ob Büro-Internet „fertig“ ist

Die Abnahme kombiniert Router-Checks mit einfachen Client-Tests. Damit stellen Sie sicher, dass NAT, DNS und Policies nicht nur konfiguriert, sondern auch wirksam sind.

• Client in Users-VLAN: IP, Gateway, DNS-Auflösung, Internet
• Client in Guest-VLAN: Internet ok, internes Netz blockiert
• Router: NAT-Translations sichtbar, Default-Route korrekt, keine Errors/Drops

Post-Checks (Mindestset)

show ip interface brief
show ip route 0.0.0.0
show ip nat statistics
show ip nat translations
show interfaces counters errors
ping 8.8.8.8 repeat 10
traceroute 1.1.1.1

Typische Fehlerbilder und schnelle Ursachen

Wenn Büro-Internet nicht funktioniert, liegt es meist an einem der drei Blöcke: WAN/Default, NAT oder DNS. Die folgenden Muster helfen beim schnellen Eingrenzen.

• Router kommt nicht ins Internet: Default-Route/Gateway/ARP falsch
• Clients ohne Internet: NAT inside/outside falsch oder NAT-ACL matcht nicht
• „Internet langsam“: DNS-Resolver falsch/zu langsam, MTU/MSS-Probleme
• Guest sieht interne Netze: ACL fehlt oder am falschen Interface/direction

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.