Cisco-Router-Konfiguration + Firewall: Wann sinnvoll – und wann nicht?

Ob Sie bei einer Cisco-Router-Konfiguration zusätzlich eine Firewall benötigen, hängt nicht von „Best Practice“-Dogmen ab, sondern von Risiko, Segmentierung, Compliance und Betriebsmodell. In kleinen Büros kann ein Router mit ACLs ausreichend sein, während in Enterprise-, Retail- oder regulierten Umgebungen eine dedizierte Firewall oft Pflicht ist, um stateful Policies, Application Control und Audit-Nachweise sauber abzubilden. Dieser Leitfaden zeigt praxisnah, wann die Kombination Router + Firewall sinnvoll ist, wann sie unnötige Komplexität bringt und wie Sie die Verantwortlichkeiten zwischen Router (Routing/WAN) und Firewall (Policy/Security) sauber trennen.

Router vs. Firewall: Rollen klar definieren

Ein Router ist primär für Routing, WAN-Anbindung, Pfadsteuerung und oft NAT zuständig. Eine Firewall ist primär für Security-Policies (stateful), Segmentierung, Threat-Prevention und Audit geeignet. Überschneidungen gibt es, aber ein sauberes Design trennt Verantwortlichkeiten.

• Router: WAN, Routing (OSPF/BGP), Failover (IP SLA/Tracking), QoS, VPN (je nach Design)
• Firewall: stateful Filtering, Zonen/Policies, Application Control, IDS/IPS (plattformabhängig), zentrale Policy-Logs
• Gemeinsam: NAT kann auf beiden liegen – idealerweise dort, wo Policy-Kontext und Logging am besten passt

Wann Router + Firewall sinnvoll ist

Die Kombination ist besonders sinnvoll, wenn Security-Anforderungen über einfache Segment-ACLs hinausgehen oder wenn Audit- und Compliance-Nachweise gefordert sind. Ebenso, wenn viele Segmente und Partnerzugänge kontrolliert werden müssen.

• Compliance/Regulierung: Audit-Logs, Policy-Nachweise, Change-Management
• Viele Segmente: Guest, IoT/OT, POS, Verwaltung, Server – mit granularen Regeln
• Externe Anbindungen: Partner-VPNs, Remote Access, DMZ-Services, Inbound-Publishing
• Enterprise-Edge/DC: BGP am Router, Policy/Inspection auf der Firewall
• Security-Operations: zentrale Policy-Verwaltung, konsistente Logging-Ketten

Praxisregel: Je höher das Business-Risiko, desto eher eine dedizierte Firewall

Wenn Ausfall oder Kompromittierung hohe Kosten verursacht (POS, Klinik, Produktion), ist eine Firewall meist nicht optional. Router-ACLs bieten Kontrolle, aber weniger Tiefe für stateful Policies und Protokoll-Auditing.

Wann Router + Firewall eher nicht sinnvoll ist

In sehr kleinen Umgebungen kann eine zusätzliche Firewall unnötige Komplexität schaffen: mehr Geräte, mehr Policies, mehr Betriebsaufwand. Dann ist ein „Router mit minimaler Segmentierung + sichere Defaults“ oft ausreichend.

• Kleines Büro ohne externe Services, wenig Segmente, geringe Compliance-Anforderungen
• Kein eigenes Betriebsteam: zusätzliche Firewall erhöht Betriebsrisiko durch Fehlkonfiguration
• Single-WAN, keine Partnerzugänge, keine DMZ, keine Remote-Access-Anforderungen
• Budgetfokus: Kosten für Betrieb/Updates/Monitoring der Firewall nicht eingeplant

Typische Architekturmodelle

Welche Rolle Router und Firewall übernehmen, lässt sich in wenigen Standardmodellen abbilden. Das reduziert Designfehler und erleichtert Betrieb, Monitoring und Troubleshooting.

Modell A: Router als Edge, Firewall als Security-Gateway (klassisch)

• Router: Provider/Carrier, BGP/Failover, Routing zum internen Netz
• Firewall: Policies zwischen Internet/DMZ/LAN, NAT (häufig), Remote Access
• Vorteil: klare Policy-Zone auf der Firewall, Router bleibt stabil und schlank

Modell B: Firewall direkt am ISP, Router intern (selten, aber möglich)

• Firewall: WAN, NAT, Security, evtl. VPN
• Router: internes Routing/IGP, WAN nicht im Fokus
• Risiko: BGP/Carrier-Features können auf Firewalls komplexer sein (modellabhängig)

Modell C: Router macht Routing/VPN, Firewall macht Segment-Policies

• Router: Site-to-Site VPNs, WAN-Failover, ggf. QoS
• Firewall: Segmentierung (Zonen) und Application-Policies
• Wichtig: klare Zuständigkeit für NAT und No-NAT definieren

Wichtiger Designpunkt: NAT-Ownership und No-NAT für VPN

NAT ist eine häufige Fehlerquelle, wenn Router und Firewall beide NAT „ein bisschen“ machen. Für Stabilität sollte im Design festgelegt sein, wer NAT verantwortet und wo No-NAT für VPN umgesetzt wird.

• Empfehlung: NAT dort, wo auch die Security-Policy liegt (oft Firewall)
• No-NAT für VPN verpflichtend, sonst „Tunnel up, kein Traffic“
• Portweiterleitungen nur mit zusätzlicher Inbound-Policy (NAT ist keine Freigabe)

Beispiel: NAT Overload auf dem Router (wenn Router NAT-Owner ist)

ip access-list standard NAT_INSIDE
 permit 10.10.0.0 0.0.255.255
interface GigabitEthernet0/0

ip nat outside

interface GigabitEthernet0/1

ip nat inside
ip nat inside source list NAT_INSIDE interface GigabitEthernet0/0 overload

Segmentierung: Router-ACLs vs. Firewall-Zonen

Router-ACLs sind gut für einfache, klare Regeln (z. B. Guest darf nicht intern). Für viele Zonen, komplexe Protokolle oder auditierbare, stateful Policies ist eine Firewall meist besser geeignet.

Wann Router-ACLs ausreichen können

• Wenige Segmente (z. B. Users, Guest, IoT) mit einfachen Block-Regeln
• Keine komplexen Inbound-Services, keine DMZ
• Kein Bedarf an Application Control, kein zentrales Policy-Management

Beispiel: Guest blockt interne Netze (Router-ACL)

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

ip access-group ACL-GUEST-IN in

Verfügbarkeit und Failover: Router kann Vorteile bringen

Gerade bei Dual-ISP ist der Router oft die beste Stelle für Failover-Logik, weil IP SLA/Tracking, Routing-Prioritäten und BGP-Policies dort sehr kontrolliert umgesetzt werden können. Die Firewall profitiert dann von einem stabilen Upstream-Pfad.

Beispiel: Path-Failover am Router (IP SLA + Tracking)

ip sla 10
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability

ip route 0.0.0.0 0.0.0.0 198.51.100.1 track 10

ip route 0.0.0.0 0.0.0.0 203.0.113.1 200

VPN: Wo gehört es hin – Router oder Firewall?

Beide können VPN terminieren, entscheidend ist das Betriebsmodell. Wenn VPNs eng mit Security-Policies, Benutzergruppen und Audit-Logs verknüpft sind, ist die Firewall oft sinnvoll. Wenn VPNs hauptsächlich Standortkopplung mit Routing und Failover sind, kann der Router passend sein.

• Router-VPN sinnvoll: viele Standorte, VTI + Routing, WAN-Failover stark im Fokus
• Firewall-VPN sinnvoll: Remote Access, Benutzer-/Gruppen-Policies, zentrale Security-Logs
• Wichtig: No-NAT und Pfadpräferenzen sauber dokumentieren und testen

VPN-Checks (betrieblich relevant)

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

Betrieb und Kosten: Der versteckte Faktor

Die Kombination Router + Firewall ist technisch oft optimal, aber betrieblich anspruchsvoller: zwei Geräte, zwei Konfigurationsdomänen, mehr Monitoring und mehr Change-Aufwand. Das ist sinnvoll, wenn die Security-Anforderungen den Mehraufwand rechtfertigen.

• Mehr Komplexität: Policies, NAT, Routing, Troubleshooting über zwei Hops
• Mehr Updates: Patches/Upgrades auf beiden Systemen
• Mehr Monitoring: Interface-/Pfadstatus, Logs, Alerts, Abhängigkeiten
• Dafür: höhere Security-Tiefe und bessere Auditierbarkeit

Abnahme und Runbook: Was Sie testen und dokumentieren sollten

Wenn Router und Firewall kombiniert werden, muss die Abnahme beide Komponenten abdecken: Pfade, Policies, NAT, VPN und Failover. Ein Runbook verhindert, dass Störungen in der Verantwortungsabgrenzung „hängen bleiben“.

Abnahme-Checks (Router-Seite)

show ip interface brief
show ip route 0.0.0.0
show interfaces counters errors
show ip nat statistics
show logging | last 50

Abnahme-Checks (VPN/Routing – wenn im Scope)

show crypto ikev2 sa
show crypto ipsec sa
show bgp summary
show ip ospf neighbor

Entscheidungshilfe: Schnellcheck für die Praxis

Mit diesen Kriterien können Sie schnell entscheiden, ob Router + Firewall sinnvoll ist oder ob ein Router mit schlanker Segmentierung genügt.

• Pflicht für Firewall: DMZ/Inbound-Services, viele Zonen, Compliance, Remote Access, Partnerzugänge
• Optional: kleines Büro, wenig Segmente, keine externen Services, geringes Risiko
• Router bleibt sinnvoll: Dual-ISP, BGP, präzises Failover/Path-Steuerung
• Wichtig: NAT-Ownership, Logging-Kette und Change-Prozess klar festlegen

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.