Bei Site-to-Site-Verbindungen (meist IPsec) reicht „Tunnel steht“ nicht aus: Du brauchst eine klare Security-Policy für den Verkehr zwischen lokalen und entfernten Netzen. Auf Cisco Routern wird diese Policy entweder klassisch mit ACLs umgesetzt (zustandslos, interface-basiert) oder moderner/strukturierter über Firewall-Zonen (Zone-Based Firewall, zustandsbehaftet). Welche Variante besser passt, hängt von Komplexität, Audit-Anforderungen, Troubleshooting und dem gewünschten Sicherheitsniveau ab.
Was genau muss bei Site-to-Site „abgesichert“ werden?
Ein Tunnel ist nur der Transport. Die eigentliche Sicherheitsfrage ist: Welche Protokolle/Ports dürfen zwischen Site A und Site B laufen? Ohne explizite Policy kann ein Tunnel schnell zu einer „flachen“ Verbindung werden, in der sich Malware oder Fehlkonfigurationen ungehindert ausbreiten.
- Segmentierung: nur benötigte Subnetze und Services erlauben
- Least Privilege: Ports/Protokolle minimal halten
- Monitoring: nachvollziehbare Regeln und Logs
- Resilienz: keine ungewollten Seiteneffekte auf Internet-Traffic
ACLs: Einfach, schnell, aber zustandslos
ACLs sind auf Routern der klassische Weg: Du filterst Traffic auf einem Interface (in/out) oder über spezielle Kontexte (z. B. crypto ACL ist jedoch keine Security-ACL). ACLs sind aber zustandslos: Rückverkehr wird nicht automatisch erlaubt, und komplexe Policies werden schnell unübersichtlich.
- Vorteile: schnell, transparent, wenig Overhead
- Nachteile: zustandslos, schwerer zu pflegen bei vielen Regeln
- Bestens geeignet: wenige, klare Freigaben (z. B. „nur RDP/SMB“)
Wichtige Klarstellung: Crypto ACL ≠ Firewall-Policy
Die Crypto ACL (interesting traffic) definiert, was verschlüsselt wird. Sie ist keine Zugriffskontrolle. Du brauchst zusätzlich ACL/ZBF, um Traffic zu erlauben oder zu blockieren.
Beispiel: ACL zwischen lokalen und Remote-Subnetzen (inbound am LAN)
ip access-list extended S2S_POLICY_IN
permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 445
permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 3389
deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
permit ip any any
interface gigabitEthernet0/0
ip access-group S2S_POLICY_IN in
Firewall-Zonen (Zone-Based Firewall): Strukturierter und zustandsbehaftet
Zone-Based Firewall (ZBF) arbeitet mit Zonen und Policies zwischen Zonen. Der zentrale Vorteil ist Statefulness: Rückverkehr zu erlaubten Sessions wird automatisch zugelassen. Außerdem ist die Policy-Logik für Audits oft klarer, weil du „LAN → VPN“, „LAN → Internet“ usw. als Zonenbeziehungen modellierst.
- Vorteile: zustandsbehaftet, klare Zonenlogik, bessere Skalierung
- Nachteile: komplexer, mehr Konfig, mehr Betriebsdisziplin nötig
- Bestens geeignet: mehrere Zonen, viele Services, Audit/Compliance
Merker: ZBF ist „Policy zwischen Zonen“
Beispiel: Zonen und Zone-Pair (Prinzip)
zone security Z_LAN
zone security Z_VPN
class-map type inspect match-any CM_S2S_ALLOWED
match protocol tcp
match protocol icmp
policy-map type inspect PM_LAN_TO_VPN
class type inspect CM_S2S_ALLOWED
inspect
class class-default
drop
zone-pair security ZP_LAN_VPN source Z_LAN destination Z_VPN
service-policy type inspect PM_LAN_TO_VPN
Einordnung: Wann ACLs reichen – und wann Zonen sinnvoll sind
In vielen kleinen Site-to-Site-Setups reichen ACLs aus, wenn du nur wenige, gut verstandene Freigaben brauchst. Sobald du aber mehrere Netze, unterschiedliche Trust-Zonen oder komplexe Protokolle hast, wird ZBF oft übersichtlicher und sicherer, weil sie zustandsbehaftet arbeitet.
- ACL: wenige Regeln, wenig Zonen, schnelle Umsetzung
- ZBF: mehrere Segmente (LAN/DMZ/VPN/Internet), viele Services
- ZBF: besser bei Statefulness-Anforderungen (weniger „Rücktraffic-Fallen“)
Typische Denkfehler in Site-to-Site-Policies
Viele Probleme entstehen durch falsche Zuständigkeiten: Crypto ACL wird als Security missverstanden, oder eine ACL wird am falschen Interface in falscher Richtung gesetzt. ZBF kann dagegen „alles blocken“, wenn Zone-Pairs fehlen.
- Crypto ACL als Firewall genutzt (falsch)
- ACL auf falscher Seite (LAN statt VPN/oder falsche Richtung)
- Zu breite Permits („permit ip any any“) innerhalb des Tunnels
- ZBF: fehlendes Zone-Pair → Traffic wird gedroppt
- ZBF: falsche Zone-Zuordnung am Interface
Praxis-Muster: Minimal sichere Site-to-Site Policy
Ein praxistauglicher Minimalstandard ist: nur definierte Subnetze in der Crypto ACL, zusätzlich eine Security-Policy (ACL oder ZBF), die nur benötigte Dienste erlaubt, und Logging/Verifikation der Counters.
- Crypto ACL: nur „interessante“ Subnetze (kein Wildcard-Overreach)
- Security Policy: Ports/Protokolle minimal, deny für Rest zwischen Sites
- Logging: Drops sichtbar machen, aber gezielt (nicht alles loggen)
Verifikation: Woran erkennst du, dass die Policy wirklich wirkt?
Nach dem Rollout prüfst du: Tunnel/SAs stehen, Counters steigen bei legitimen Verbindungen, und unerlaubter Traffic wird geblockt (mit Hits/Logs). Ohne Verifikation ist eine Policy nur Theorie.
IPsec Status prüfen
Router# show crypto isakmp sa
Router# show crypto ipsec saACL-Hits oder ZBF-Counters prüfen
Router# show ip access-lists
Router# show policy-map type inspect zone-pairTraffic-Tests (Beispiel)
Router# ping 192.168.20.10 source 192.168.10.1
Client$ nc -vz 192.168.20.10 445
Client$ nc -vz 192.168.20.10 3389Quick-Reference: Entscheidungsfragen
- Brauchst du Statefulness und saubere Zonenmodelle? → ZBF
- Hast du nur wenige, klar definierte Freigaben? → ACL kann reichen
- Musst du Audits/Compliance sauber abbilden? → ZBF oft besser
- Willst du schnell und minimalistisch bleiben? → ACL
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.
