NAT und ACLs werden auf Cisco Routern oft gleichzeitig eingesetzt: NAT für Adress-/Port-Übersetzung, ACLs für Security-Policy. Viele „Internet geht nicht“-Fehler entstehen nicht durch NAT oder ACL allein, sondern durch falsche Annahmen darüber, wann welche Regel greift und welche Adressen eine ACL tatsächlich sieht (vor oder nach NAT). Dieser Beitrag zeigt die häufigsten Denkfehler und gibt dir praxistaugliche Muster, wie du NAT und ACL sauber kombinierst.
Grundverständnis: NAT ist keine Firewall
NAT übersetzt Adressen und Ports. Es entscheidet nicht automatisch, was „erlaubt“ ist. Wenn du Dienste veröffentlichst (Static NAT/Port Forwarding), brauchst du eine explizite ACL-Policy am Outside, sonst ist der Dienst unter Umständen für das ganze Internet erreichbar.
- NAT = Übersetzung, nicht Zugriffskontrolle
- ACL = Zugriffskontrolle, nicht Übersetzung
- Sicheres Design: NAT + Outside-ACL + Logging
Denkfehler 1: „Ich erlaube die private Server-IP in der Outside-ACL“
Bei Port Forwarding ist die Outside-ACL fast immer auf die öffentliche (translated) Adresse zu schreiben, nicht auf die interne. Von außen sieht der Client die öffentliche IP. Wenn du in der ACL die private IP erlaubst, matcht sie nicht.
Falsch (ACL auf Inside Local)
ip access-list extended OUTSIDE_IN
permit tcp any host 192.168.10.10 eq 443Richtig (ACL auf Public IP)
ip access-list extended OUTSIDE_IN
permit tcp any host 203.0.113.10 eq 443
deny ip any anyDenkfehler 2: „PAT braucht eine Extended ACL“
Für klassisches PAT (NAT Overload) reicht meist eine Standard-ACL, weil sie nur die Inside-Quellnetze auswählt. Ports und Ziele werden in der NAT-Regel nicht gefiltert, sondern in einer separaten Security-ACL.
PAT-ACL ist Auswahl, nicht Security
ip access-list standard NAT_INSIDE
permit 192.168.10.0 0.0.0.255
ip nat inside source list NAT_INSIDE interface gigabitEthernet0/1 overload
Security-Policy separat (Extended ACL)
ip access-list extended USERS_OUT
permit tcp 192.168.10.0 0.0.0.255 any eq 443
permit udp 192.168.10.0 0.0.0.255 any eq 53
deny ip any anyDenkfehler 3: „ACL und NAT greifen in beliebiger Reihenfolge“
Die Reihenfolge ist entscheidend. Ein typischer Fehler ist, dass du eine restriktive ACL so platzierst, dass sie Traffic blockiert, bevor NAT überhaupt eine Translation aufbauen kann – oder du filterst in der falschen Richtung (in/out) und wunderst dich über fehlende Translations.
- Interface-Richtung prüfen:
ip access-group … in/out - Verifikation: Hit-Counter + NAT-Translations
- Change-Ansatz: erst Traffic erlauben, dann schärfen
Verifikation der Platzierung
show ip interface gigabitEthernet0/0
show ip interface gigabitEthernet0/1
show running-config | include access-groupDenkfehler 4: „Deny am Outside blockiert Rücktraffic immer“
Viele erwarten, dass eine einfache Outside-ACL automatisch „stateful“ ist. Eine klassische ACL ist aber zustandslos. In typischen Edge-Designs ist das trotzdem okay, weil du am Outside meistens nur eingehende neue Verbindungen blockst und ausgehend keine ACL oder eine andere Policy nutzt. Wenn du jedoch inbound sehr restriktiv bist, musst du Rückverkehr korrekt berücksichtigen oder stateful Firewall-Funktionen nutzen.
- ACLs sind zustandslos (kein automatisches Session-Tracking)
- Für Internet-Edge: inbound nur benötigte Ports erlauben
- Für komplexe Policies: Zone-Based Firewall statt reiner ACL
Denkfehler 5: „NAT geht nicht“ – dabei ist es DNS/Default Route
Wenn Clients keine Webseiten laden, ist NAT oft nur der erste Verdacht. Sehr häufig fehlt die Default Route oder DNS ist falsch. Dann entstehen entweder keine Translations oder es gibt Translations ohne funktionierenden Rückweg.
Basischecks vor NAT/ACL-Debug
show ip route | include Gateway|0.0.0.0
ping 8.8.8.8
show ip nat translations
show ip nat statisticsDenkfehler 6: „Die NAT-ACL ist gleichzeitig meine No-NAT/VPN-ACL“
Für VPNs brauchst du meist NAT Exemption (No-NAT) für die Tunnel-Subnetze. Wenn du dieselbe ACL für PAT und für No-NAT verwendest oder No-NAT vergisst, wird VPN-Traffic genattet und die Crypto-Policy matcht nicht.
- VPN-Subnetze: No-NAT (Exemption) zuerst
- Danach: normales PAT für Internet
- Verifikation: keine NAT-Translations für VPN-Subnets
Indiz: VPN-Traffic taucht in NAT-Translations auf
show ip nat translations | include 192.168.10.|192.168.20.
show crypto ipsec saDenkfehler 7: „Ich veröffentliche einen Server und brauche keine zusätzliche ACL“
Static NAT/Port Forwarding macht Dienste erreichbar. Ohne Outside-ACL oder Firewall-Policy ist der Dienst ggf. für jeden erreichbar. Best Practice ist: nur benötigte Ports, optional Quellnetze begrenzen, Logging aktivieren.
Port Forwarding + Outside-ACL (Best Practice)
ip nat inside source static tcp 192.168.10.10 443 203.0.113.10 443
ip access-list extended OUTSIDE_IN
permit tcp 198.51.100.0 0.0.0.255 host 203.0.113.10 eq 443
deny ip any any log
interface gigabitEthernet0/1
ip access-group OUTSIDE_IN in
Praxis-Muster 1: Sicheres PAT für Clients (Inside → Internet)
Dieses Muster trennt sauber: NAT-ACL wählt nur die Inside-Netze, Security-ACL regelt, was ins Internet darf. NAT hängt am Outside-Interface, Security-ACL am Inside (oder an der Zone/Firewall).
ip access-list standard NAT_INSIDE
permit 192.168.10.0 0.0.0.255
ip nat inside source list NAT_INSIDE interface gigabitEthernet0/1 overload
ip access-list extended USERS_OUT
permit udp 192.168.10.0 0.0.0.255 any eq 53
permit tcp 192.168.10.0 0.0.0.255 any eq 53
permit tcp 192.168.10.0 0.0.0.255 any eq 443
deny ip any any log
interface gigabitEthernet0/0
ip access-group USERS_OUT in
Praxis-Muster 2: Sicheres Port Forwarding (Internet → Server)
Dieses Muster stellt sicher, dass nur explizite Ports auf die öffentliche IP zugelassen werden. Die ACL wird gegen die öffentliche Adresse geschrieben.
ip nat inside source static tcp 192.168.10.10 443 203.0.113.10 443
ip access-list extended OUTSIDE_IN
permit tcp any host 203.0.113.10 eq 443
deny ip any any log
interface gigabitEthernet0/1
ip access-group OUTSIDE_IN in
Verifikation: So siehst du, ob NAT und ACL zusammenpassen
Im Troubleshooting prüfst du immer (1) ACL-Hit-Counter, (2) NAT-Translations und (3) Routing. Damit erkennst du schnell, ob Traffic an der ACL hängt oder ob NAT/Routing das Problem ist.
ACL prüfen
show ip access-lists
show ip interface gigabitEthernet0/0
show ip interface gigabitEthernet0/1NAT prüfen
show ip nat translations
show ip nat statistics
clear ip nat translation *Routing prüfen
show ip route | include Gateway|0.0.0.0
traceroute 8.8.8.8Quick-Reference: Häufige Denkfehler als Checkliste
- Outside-ACL auf öffentliche IP schreiben, nicht auf private
- NAT-ACL = Auswahl, Security-ACL = Zugriffskontrolle
- Richtung (in/out) prüfen, sonst matcht nichts
- VPN-Traffic darf nicht genattet werden (No-NAT zuerst)
- Default Route und DNS immer zuerst verifizieren
- Hit-Counter + NAT-Translations sind die schnellste Wahrheit
Konfiguration speichern
Router# copy running-config startup-configKonfiguriere 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.
