19
Routing Problem von VLAN zu Firewall mittels PBR
Liebe Community,
Seit Tagen hänge ich bei der Konfiguration meines privaten Netzwerkes und bin langsam mit meinem Latein am Ende, weshalb ich auf eure Unterstützung hoffe.
Ich habe zur Zeit zwei ISPs, wobei Router 1 (DSL) zeitnah abgebaut werden soll. Als Ersatz ist Router 2 (Fiber) gedacht.
Beide sind momentan am Core-Switch angeschlossen, wobei Router 1 als statische Route eingetragen ist.
Da sich derzeit alle Geräte im Netzwerk 192.168.0.0 / 255.255.255.0 befinden, möchte ich die Gelegenheit nutzen und sie in mehrere VLANs verschieben. Die Migration möchte ich sukzessive machen, wobei ich einmal mit einem einfachen Szenario begonnen habe.
Zum Setup:
-) Router 2: Cisco Firepower 1010
-) Core-Switch: Cisco CBS350
FPR1010 (P2) <---> (P23) CBS350 (P15) <---> PC 2
Ich möchte von PC 2 (VLAN 40) über den Switch zur Firewall gelangen. Mein Plan wäre diese Anforderung mittels ACL und PBR zu realisieren. Leider will das PBR einfach nicht funktionieren...
Der Vollständigkeit halber: PC 1 ist auf P13 angeschlossen und dient zur Konfiguration des Switch.
Konfiguration am Switch
VLAN 40: 192.168.40.1 / 24
DHCP ist aktiviert
IPv4 Routing ist aktiviert
P15: VLAN 40 untagged, access-port
P23: Layer 3 Access-Port, IP 192.168.95.2 / 24
Konfiguration auf der Firewall:
P2: 192.168.95.1 / 24
Route von Firewall zu Switch ist konfiguriert.
Wie ist der Status quo:
Nun habe ich nachfolgende ACL konfiguriert und PBR für VLAN40 aktiviert. Sonderbarer Weise kann dann PC2 nicht mal mehr das Default-Gateway erreichen (?).
Die konfigurierte ACL:
Die konfigurierten Routen:
VLAN Tag
Ich denke ich habe zwei Probleme:
1. Warum "sperrt" mich der Switch aus sobald ich PBR auf VLAN40 aktiviere?
2. Warum wird der "next hop" vom PBR nicht ausgeführt?
Vielen Dank für eure Unterstützung.
Seit Tagen hänge ich bei der Konfiguration meines privaten Netzwerkes und bin langsam mit meinem Latein am Ende, weshalb ich auf eure Unterstützung hoffe.
Ich habe zur Zeit zwei ISPs, wobei Router 1 (DSL) zeitnah abgebaut werden soll. Als Ersatz ist Router 2 (Fiber) gedacht.
Beide sind momentan am Core-Switch angeschlossen, wobei Router 1 als statische Route eingetragen ist.
Da sich derzeit alle Geräte im Netzwerk 192.168.0.0 / 255.255.255.0 befinden, möchte ich die Gelegenheit nutzen und sie in mehrere VLANs verschieben. Die Migration möchte ich sukzessive machen, wobei ich einmal mit einem einfachen Szenario begonnen habe.
Zum Setup:
-) Router 2: Cisco Firepower 1010
-) Core-Switch: Cisco CBS350
FPR1010 (P2) <---> (P23) CBS350 (P15) <---> PC 2
Ich möchte von PC 2 (VLAN 40) über den Switch zur Firewall gelangen. Mein Plan wäre diese Anforderung mittels ACL und PBR zu realisieren. Leider will das PBR einfach nicht funktionieren...
Der Vollständigkeit halber: PC 1 ist auf P13 angeschlossen und dient zur Konfiguration des Switch.
Konfiguration am Switch
VLAN 40: 192.168.40.1 / 24
DHCP ist aktiviert
IPv4 Routing ist aktiviert
P15: VLAN 40 untagged, access-port
P23: Layer 3 Access-Port, IP 192.168.95.2 / 24
Konfiguration auf der Firewall:
P2: 192.168.95.1 / 24
Route von Firewall zu Switch ist konfiguriert.
Wie ist der Status quo:
- Ping von Firewall <-> Switch (P23) funktioniert.
- Solange PBR nicht aktiviert ist, kann ich von PC2 sowohl das Default-Gateway (192.168.40.1) als auch P23 (192.168.95.2) erreichen.
- Bis zur Firewall (192.168.95.1) komme ich von PC2 aus natürlich nicht
- Ausgehend vom VLAN40 am Switch kann ich die Firewall ebenfalls nicht erreichen.
Nun habe ich nachfolgende ACL konfiguriert und PBR für VLAN40 aktiviert. Sonderbarer Weise kann dann PC2 nicht mal mehr das Default-Gateway erreichen (?).
Die konfigurierte ACL:
switch#show access-lists
Extended IP access list VLAN_2_FW
permit ip 192.168.40.0 0.0.0.255 any ace-priority 10Die konfigurierten Routen:
switch#show ip route
Maximum Parallel Paths: 1 (1 after reset)
IP Forwarding: enabled
Codes: > - best, C - connected, S - static,
R - RIP
Policy Routing
vlan 40
Route Map: VLAN_2_FW
Status: Active
ACL Name: VLAN_2_FW
Next Hop: 192.168.95.1
Next Hop Status: Active
S 0.0.0.0/0 [1/4] via 192.168.0.1, 00:27:39, vlan 1
C 192.168.0.0/24 is directly connected, vlan 1
C 192.168.40.0/24 is directly connected, vlan 40
C 192.168.95.0/24 is directly connected, gi23VLAN Tag
switch#show vlan tag 40
Created by: D-Default, S-Static, G-GVRP, R-Radius Assigned VLAN, V-Voice VLAN
Vlan Name Tagged Ports UnTagged Ports Created by
---- ----------------- ------------------ ------------------ ----------------
40 Gäste WLAN gi25 gi15 SIch denke ich habe zwei Probleme:
1. Warum "sperrt" mich der Switch aus sobald ich PBR auf VLAN40 aktiviere?
2. Warum wird der "next hop" vom PBR nicht ausgeführt?
Vielen Dank für eure Unterstützung.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671212
Url: https://administrator.de/forum/routing-problem-von-vlan-zu-firewall-mittels-pbr-671212.html
Ausgedruckt am: 12.03.2025 um 04:03 Uhr
19 Kommentare
Neuester Kommentar
Moin,
stimmt, eigentlich sollte das so funktionieren. Aber eigentlich solltest Du auch bei deaktivierter PBR die FW aus dem VLAN40 heraus erreichen können (das Transit-Netz ist ja directly connected), vorausgesetzt die Rückroute zum Netz 192.168.40.0/24 via 192.168.95.2 ist in der FW korrekt eingetragen.
Zu Deinem PBR-Problem:
In Deinem Post hast Du in der ACL zwischen "permit" und "ip" zwei Leerzeichen. Ist das in der Konfiguration tatsächlich auch so? Da sollte nur ein Leerzeichen sein.
VG,
Torsten
stimmt, eigentlich sollte das so funktionieren. Aber eigentlich solltest Du auch bei deaktivierter PBR die FW aus dem VLAN40 heraus erreichen können (das Transit-Netz ist ja directly connected), vorausgesetzt die Rückroute zum Netz 192.168.40.0/24 via 192.168.95.2 ist in der FW korrekt eingetragen.
Zu Deinem PBR-Problem:
In Deinem Post hast Du in der ACL zwischen "permit" und "ip" zwei Leerzeichen. Ist das in der Konfiguration tatsächlich auch so? Da sollte nur ein Leerzeichen sein.
VG,
Torsten
Bis zur Firewall (192.168.95.1) komme ich von PC2 aus natürlich nicht
Das kämst du nur dann wenn...- Der Switch eine Default Route auf die .95.1 hat oder, wie in deinem Falle, die aktive Policy Route die alles an externen IP Traffic aus dem VLAN40 mit .40.x Absender IPs an die .95.1 forwardet.
- ICMP auf dem LAN P2 Port der FPR im Regelwerk erlaubt ist.
- Die FPR eine statische Route auf das .40.0er Netz mit Gateway .95.2 hat.
Vermutlich wird also 2.) ausgeführt aber wenn die FPR Rückroute in der FW fehlt oder ICMP dort geblockt ist scheitert der Reply. Irgendeiner der 3 o.a. Punkte ist falsch oder fehlerhaft.
Tip:
Im Zweifel mit der Switch Mirror Funktion den Port 23 spiegeln und dort mal einen Wireshark mitlaufen lassen.
Liebe Leute,
Nachdem ich, wie von Torsten angeregt, gleich mal die ACL auf die zwei spaces geprüft habe, hat sich Ernüchterung breit gemacht. Fehlanzeige - Egal ob die ACL über UI oder CLI angelegt wird, die spaces werden in der CLI immer angezeigt.
Als nächstes habe ich mich nochmal an die Rückroute der FW gemacht. Wie oben beschrieben habe ich der "Nicht-Erreichbarkeit" der FW aus dem VLAN40 keine Beachtung geschenkt und es mir mit dem Problem beim PBR erklärt. Da dies aber anscheinend funktionieren sollte (danke Torsten, danke aqui), habe ich mir das nochmal genauer angesehen.
Und liebe Leute, ich sags euch: Die Rückroute auf der FW war eingetragen. Da war ich mir auch 100%ig sicher. ABER - und jetzt haltet euch fest - Ich hatte übersehen sie zu deployen (beim Switch ist das nämlich nicht notwendig). Einmal deployed und siehe da: Ping von VLAN40 auf FW funktioniert.
Ich hatte dann noch ein Verständnisproblem mit ACL und PBR:
Um die Funktionsweise zu testen, habe ich PBR für VLAN40 deaktiviert und von PC2 auf *.95.1 gepingt. Das hat erfreudlicher Weise auch funktioniert.
Nun habe ich mein PBR in der obigen Konfigurationwieder aktiviert, Ping zur FW funktionierte wie erwartet.
Wie aus obigem Auszug ersichtlich, handelt es sich bei VLAN40 um das geplante Gäste-WLAN. Aus diesem Netz soll natürlich niemand direkt auf die FW zugreifen können. Ich habe deshalb meine ACL folgendermaßen angepasst und meinem PBR für VLAN40 zugeordnet:
Unerwarteter Weise konnte PC2 aber weiterhin die UI der Firewall aufrufen.
Den entscheidenden Hinweis für die Erklärung hat hier aqui geliefert (Stichwort statische Route).
Dadurch dass P23 als Layer 3 Port konfiguriert und eine IP Adresse bekommen hat (*95.2), ist das Transfernetz dem Switch bekannt. Deshalb legt er implizit eine "IPv4 Forwarding Table" an (siehe route map im ersten Post).
Meine Erklärung dafür: Die ACL blockt zwar den Zugriff auf die PBR, aber die statische Route leitete den Aufruf trotzdem weiter.
Ich habe mir dann überlegt, wenn der Weg aus dem VLAN40 zum Transfernetz bereits bekannt ist, dann ist ja meine PBR obsolet bzw. doppelt gemoppelt. Sie würde ja ohnehin nur auf P2 (*95.1) der FW weiterleiten. Ich habe deshalb meine PBR zurück gebaut und die ACL direkt an VLAN40 gebunden. Damit kann ich den https-Zugriff von VLAN40 auf die FW schon an dieser Stelle unterbinden.
Da ich das Prinzip nun (hoffentlich) verstanden habe, habe ich gleich mal eine neue PBR für meinen PC1 (*0.38) angelegt. Dieser konnte bisher nicht auf die FW zugreifen und ich musste jedes mal am Switch umstecken.
Mit dieser PBR (hier macht sie ja Sinn) kann ich nun auch direkt auf die FW zugreifen und muss nicht jedes mal laufen.
Nachfolgend nochmal meine aktuelle Konfiguration:
Vielen Dank für euren Beistand, eure Tipps und den anderen Blickwinkel auf das Problem.
Nachdem ich, wie von Torsten angeregt, gleich mal die ACL auf die zwei spaces geprüft habe, hat sich Ernüchterung breit gemacht. Fehlanzeige - Egal ob die ACL über UI oder CLI angelegt wird, die spaces werden in der CLI immer angezeigt.
Als nächstes habe ich mich nochmal an die Rückroute der FW gemacht. Wie oben beschrieben habe ich der "Nicht-Erreichbarkeit" der FW aus dem VLAN40 keine Beachtung geschenkt und es mir mit dem Problem beim PBR erklärt. Da dies aber anscheinend funktionieren sollte (danke Torsten, danke aqui), habe ich mir das nochmal genauer angesehen.
Und liebe Leute, ich sags euch: Die Rückroute auf der FW war eingetragen. Da war ich mir auch 100%ig sicher. ABER - und jetzt haltet euch fest - Ich hatte übersehen sie zu deployen (beim Switch ist das nämlich nicht notwendig). Einmal deployed und siehe da: Ping von VLAN40 auf FW funktioniert.
Ich hatte dann noch ein Verständnisproblem mit ACL und PBR:
Um die Funktionsweise zu testen, habe ich PBR für VLAN40 deaktiviert und von PC2 auf *.95.1 gepingt. Das hat erfreudlicher Weise auch funktioniert.
Nun habe ich mein PBR in der obigen Konfigurationwieder aktiviert, Ping zur FW funktionierte wie erwartet.
Wie aus obigem Auszug ersichtlich, handelt es sich bei VLAN40 um das geplante Gäste-WLAN. Aus diesem Netz soll natürlich niemand direkt auf die FW zugreifen können. Ich habe deshalb meine ACL folgendermaßen angepasst und meinem PBR für VLAN40 zugeordnet:
switch#show access-lists
Extended IP access list VLAN40_to_FW
deny tcp 192.168.40.0 0.0.0.255 any 192.168.95.1 0.0.0.1 443 ace-priority 5Den entscheidenden Hinweis für die Erklärung hat hier aqui geliefert (Stichwort statische Route).
Dadurch dass P23 als Layer 3 Port konfiguriert und eine IP Adresse bekommen hat (*95.2), ist das Transfernetz dem Switch bekannt. Deshalb legt er implizit eine "IPv4 Forwarding Table" an (siehe route map im ersten Post).
Meine Erklärung dafür: Die ACL blockt zwar den Zugriff auf die PBR, aber die statische Route leitete den Aufruf trotzdem weiter.
Ich habe mir dann überlegt, wenn der Weg aus dem VLAN40 zum Transfernetz bereits bekannt ist, dann ist ja meine PBR obsolet bzw. doppelt gemoppelt. Sie würde ja ohnehin nur auf P2 (*95.1) der FW weiterleiten. Ich habe deshalb meine PBR zurück gebaut und die ACL direkt an VLAN40 gebunden. Damit kann ich den https-Zugriff von VLAN40 auf die FW schon an dieser Stelle unterbinden.
Da ich das Prinzip nun (hoffentlich) verstanden habe, habe ich gleich mal eine neue PBR für meinen PC1 (*0.38) angelegt. Dieser konnte bisher nicht auf die FW zugreifen und ich musste jedes mal am Switch umstecken.
Mit dieser PBR (hier macht sie ja Sinn) kann ich nun auch direkt auf die FW zugreifen und muss nicht jedes mal laufen.
Nachfolgend nochmal meine aktuelle Konfiguration:
switch#show ip route
Maximum Parallel Paths: 1 (1 after reset)
IP Forwarding: enabled
Codes: > - best, C - connected, S - static,
R - RIP
Policy Routing
vlan 1
Route Map: Nativ_to_FW
Status: Active
ACL Name: Native_to_FW
Next Hop: 192.168.95.1
Next Hop Status: Active
S 0.0.0.0/0 [1/4] via 192.168.0.1, 01:07:05, vlan 1
C 192.168.0.0/24 is directly connected, vlan 1
C 192.168.40.0/24 is directly connected, vlan 40
C 192.168.95.0/24 is directly connected, gi23
switch#show access-lists
Extended IP access list VLAN40_to_FW
deny tcp 192.168.40.0 0.0.0.255 any 192.168.95.1 0.0.0.1 443 ace-priority 5
permit tcp 192.168.40.0 0.0.0.255 any any www ace-priority 10
permit tcp 192.168.40.0 0.0.0.255 any any 443 ace-priority 12
permit icmp 192.168.40.0 0.0.0.255 192.168.95.1 0.0.0.1 ace-priority 20 type any code any
Extended IP access list Native_to_FW
permit ip 192.168.0.0 0.0.0.255 192.168.95.1 0.0.0.255 ace-priority 10Vielen Dank für euren Beistand, eure Tipps und den anderen Blickwinkel auf das Problem.
Ich hatte übersehen sie zu deployen
Kann im Eifer des Gefechts schon mal passieren. 🤣Ich habe deshalb meine ACL folgendermaßen angepasst und meinem PBR für VLAN40 zugeordnet. Unerwarteter Weise konnte PC2 aber weiterhin die UI der Firewall aufrufen.
Das liegt daran das deine inverse ACL Maske falsch ist! Eine inverse Maske zu einer 32 Bit Hostmaske (255.255.255.255) lautet logischerweise 0.0.0.0 und nicht das was du da eingegeben hast, denn das wäre eine ebenfalls falsche inverse 31 Bit Maske.Im KlickiBunti muss man m.E. (geraten da kein GUI User) auch host statt net klicken.
Korrigiere das, dann klappt es auch mit der ACL.
Tip:
Du solltest das keineswegs nur Port bezogen auf den Port TCP 443 limitieren sondern auf ALLES. Kein Gast soll egal wie auf die FW IP zugreifen können! Also:
deny ip 192.168.40.0 0.0.0.255 192.168.95.1 0.0.0.0
Moin,
schön, dass Du nun einen Schritt weiter bist.
Laut der letzten Konfiguration hast Du ja jetzt nur ein PBR für das Subnetz 192.168.0.0/24.
Demnach dürfte jetzt dieses Subnetz über die FW in das Internet gehen.
Für das VLAN40 hast Du kein PBR aktiv. D.h. Geräte aus VLAN40 gehen über die statische Default-Route und somit über Deinen Router 1 (192.168.0.1) ins Internet.
Die ist eben genau dann nicht obsolet, wenn Du Geräte im VLAN40 über die FW ins Internet ausleiten willst. Ohne PBR greift die Default-Route.
VG,
Torsten
schön, dass Du nun einen Schritt weiter bist.
Laut der letzten Konfiguration hast Du ja jetzt nur ein PBR für das Subnetz 192.168.0.0/24.
Demnach dürfte jetzt dieses Subnetz über die FW in das Internet gehen.
Für das VLAN40 hast Du kein PBR aktiv. D.h. Geräte aus VLAN40 gehen über die statische Default-Route und somit über Deinen Router 1 (192.168.0.1) ins Internet.
Ich habe mir dann überlegt, wenn der Weg aus dem VLAN40 zum Transfernetz bereits bekannt ist, dann ist ja meine PBR obsolet bzw. doppelt gemoppelt. Sie würde ja ohnehin nur auf P2 (*95.1) der FW weiterleiten.
Die ist eben genau dann nicht obsolet, wenn Du Geräte im VLAN40 über die FW ins Internet ausleiten willst. Ohne PBR greift die Default-Route.
VG,
Torsten
1
Ui - vielen Dank für euer Feedback.
Das nehme ich natürlich gerne an und habe ich gleich umgebaut. Wenn dann möchte ich es doch gleich möglichst ordentlich machen.
Und du aqui hast mich natürlich gleich auffliegen lassen, dass ich das über das KlickiBunti UI gemacht habe. Aber für eine komprimierte Darstellung führt am CLI wohl nichts vorbei.
Was habe ich versucht mit den ACLs zu bezwecken?
@acl VLAN40_to_FW:
1) Ping direkt auf die FW ist erlaubt
2) Alle anderen direkten Zugriffe auf die FW sind gesperrt.
3+4) http/https Zugriff wird geroutet
5) Rest wird gesperrt
@acl VLAN1_to_FW
1) Direktzugriff von PC1 (*0.38) auf Firewall ist erlaubt
2) Alle anderen direkten Zugriffe auf die FW sind gesperrt.
In der Zeit zwischen meinen beiden Posts habe ich mich um die Firewall-Konfiguration "gekümmert" bzw. habe ich versucht zu verstehen, warum ich aus VLAN40 nicht ins Internet komme. Ein Ping von PC2 auf 8.8.8.8 führt zum Timeout. Das VLAN40 am Switch verhält sich genauso.
Führe ich den Ping dagegen direkt auf der FW aus, funktioniert er.
Sobald ich meinen PC1 direkt auf einem freien FW-Port anschließe, klappt der Internetzugriff auch wunderbar.
Ich hoffe ihr könnt mir auch hier nochmal helfen.
Den CLI Output möchte ich - wenn nicht unbedingt notwendig - vorerst nicht posten. Da werden so viele Informationen ausgegeben (öffentliche IP, MAC Adressen)...
Hier die konfigurierten Interfaces. Einzige "Besonderheit" - P2 ist ein Layer2 Access-Port.
Das Inside-Interface mit den physischen Ports:
Die beiden Security Zones
Und schließlich noch die NAT-Konfiguration:
Sowie die ACL:
Als Route habe ich derzeit nur die Rückroute zum Switch konfiguriert.
Warum kann die FW den Zugriff vom Switch bzw. PC2 nicht weiterrouten, den Zugriff vom lokalen FW-Port aber schon?
Vielen Dank.
Das nehme ich natürlich gerne an und habe ich gleich umgebaut. Wenn dann möchte ich es doch gleich möglichst ordentlich machen.
Und du aqui hast mich natürlich gleich auffliegen lassen, dass ich das über das KlickiBunti UI gemacht habe. Aber für eine komprimierte Darstellung führt am CLI wohl nichts vorbei.
switch#show ip route
Maximum Parallel Paths: 1 (1 after reset)
IP Forwarding: enabled
Codes: > - best, C - connected, S - static,
R - RIP
Policy Routing
vlan 1
Route Map: VLAN1_to_FW
Status: Active
ACL Name: VLAN1_to_FW
Next Hop: 192.168.95.1
Next Hop Status: Active
vlan 40
Route Map: VLAN40_to_FW
Status: Active
ACL Name: VLAN40_to_FW
Next Hop: 192.168.95.1
Next Hop Status: Active
S 0.0.0.0/0 [1/4] via 192.168.0.1, 01:53:15, vlan 1
C 192.168.0.0/24 is directly connected, vlan 1
switch#show access-lists
Extended IP access list VLAN40_to_FW
permit icmp 192.168.40.0 0.0.0.255 host 192.168.95.1 ace-priority 20 type any code any
deny ip 192.168.40.0 0.0.0.255 host 192.168.95.1 ace-priority 30
permit tcp 192.168.40.0 0.0.0.255 any any www ace-priority 40
permit tcp 192.168.40.0 0.0.0.255 any any 443 ace-priority 50
deny ip host 192.168.40.0 any ace-priority 60
Extended IP access list VLAN1_to_FW
permit ip host 192.168.0.38 host 192.168.95.1 ace-priority 10
deny ip 192.168.0.0 0.0.0.255 host 192.168.95.1 ace-priority 30Was habe ich versucht mit den ACLs zu bezwecken?
@acl VLAN40_to_FW:
1) Ping direkt auf die FW ist erlaubt
2) Alle anderen direkten Zugriffe auf die FW sind gesperrt.
3+4) http/https Zugriff wird geroutet
5) Rest wird gesperrt
@acl VLAN1_to_FW
1) Direktzugriff von PC1 (*0.38) auf Firewall ist erlaubt
2) Alle anderen direkten Zugriffe auf die FW sind gesperrt.
In der Zeit zwischen meinen beiden Posts habe ich mich um die Firewall-Konfiguration "gekümmert" bzw. habe ich versucht zu verstehen, warum ich aus VLAN40 nicht ins Internet komme. Ein Ping von PC2 auf 8.8.8.8 führt zum Timeout. Das VLAN40 am Switch verhält sich genauso.
Führe ich den Ping dagegen direkt auf der FW aus, funktioniert er.
Sobald ich meinen PC1 direkt auf einem freien FW-Port anschließe, klappt der Internetzugriff auch wunderbar.
Ich hoffe ihr könnt mir auch hier nochmal helfen.
Den CLI Output möchte ich - wenn nicht unbedingt notwendig - vorerst nicht posten. Da werden so viele Informationen ausgegeben (öffentliche IP, MAC Adressen)...
Hier die konfigurierten Interfaces. Einzige "Besonderheit" - P2 ist ein Layer2 Access-Port.
Das Inside-Interface mit den physischen Ports:
Die beiden Security Zones
Und schließlich noch die NAT-Konfiguration:
Sowie die ACL:
Als Route habe ich derzeit nur die Rückroute zum Switch konfiguriert.
Warum kann die FW den Zugriff vom Switch bzw. PC2 nicht weiterrouten, den Zugriff vom lokalen FW-Port aber schon?
Vielen Dank.
Zu Deiner Inside-Zone gehört zur Zeit nur das Interface VLAN1 (Transfernetz).
Wenn jetzt Datenverkehr aus dem VLAN40 kommt, dann ist die Source-Adresse ja 192.168.40.x
Die gehört aber nicht zur Inside-Zone und entsprechend gibt es auch keine Policy, die hier matched. Ergebnis: Ende-Gelände an der Firewall.
Wenn Du von der Firewall aus 8.8.8.8 anpingst, dann wird mit der Source-Adresse 192.168.95.1 gepingt. Die widerum gehort ja zur Inside-Zone und daher funktioniert das.
Wenn jetzt Datenverkehr aus dem VLAN40 kommt, dann ist die Source-Adresse ja 192.168.40.x
Die gehört aber nicht zur Inside-Zone und entsprechend gibt es auch keine Policy, die hier matched. Ergebnis: Ende-Gelände an der Firewall.
Wenn Du von der Firewall aus 8.8.8.8 anpingst, dann wird mit der Source-Adresse 192.168.95.1 gepingt. Die widerum gehort ja zur Inside-Zone und daher funktioniert das.
2
Einen fatalen Fehler hast du außer dem oben genannten zusätzlich noch in deiner VLAN40_to_FW ACL gemacht!!
Du erlaubst dort kein DNS, also TCP/UDP Port 53. Damit ist dann jegliche DNS Auflösung von Gast Clients mausetot und jeder Internet Zugriff via Browser scheitert was du mit dem nslookup Tool auf einem Testclient in der Eingabeaufforderung (Winblows) auch testen kannst. (Alternativ die bekannten HE.NET Tools aus den jeweiligen App Stores bei mobilen Endgeräten) Sicher nicht gewollt, oder?
Es wird nur bei den Browsern klappen die das betriebssystemeigene DNS umgehen und eigene, hartgecodete DoH Adressen innerhalb der Browser App nutzen. Darauf solltest du es aber nie ankommen lassen und logischerweise immer auch UDP/TCP 53 in dem Segment erlauben.
Also ein
permit udp 192.168.40.0 0.0.0.255 host 192.168.95.1 53 ace-priority 25
permit tcp 192.168.40.0 0.0.0.255 host 192.168.95.1 53 ace-priority 26
sofern die Firewall hier den üblichen Proxy DNS ins Internet spielt.
Ohne DNS kein Internet für die VLAN 40 Gäste!
Du erlaubst dort kein DNS, also TCP/UDP Port 53. Damit ist dann jegliche DNS Auflösung von Gast Clients mausetot und jeder Internet Zugriff via Browser scheitert was du mit dem nslookup Tool auf einem Testclient in der Eingabeaufforderung (Winblows) auch testen kannst. (Alternativ die bekannten HE.NET Tools aus den jeweiligen App Stores bei mobilen Endgeräten) Sicher nicht gewollt, oder?
Es wird nur bei den Browsern klappen die das betriebssystemeigene DNS umgehen und eigene, hartgecodete DoH Adressen innerhalb der Browser App nutzen. Darauf solltest du es aber nie ankommen lassen und logischerweise immer auch UDP/TCP 53 in dem Segment erlauben.
Also ein
permit udp 192.168.40.0 0.0.0.255 host 192.168.95.1 53 ace-priority 25
permit tcp 192.168.40.0 0.0.0.255 host 192.168.95.1 53 ace-priority 26
sofern die Firewall hier den üblichen Proxy DNS ins Internet spielt.
Ohne DNS kein Internet für die VLAN 40 Gäste!
1
Hallo ihr zwei,
Vielen lieben Dank für eure Antworten.
ACL habe ich umgebaut:
Das Problem mit der inside_zone auf der FW klingt logisch. Ich habe das gestern Abend (und auch heute) gleich probiert, aber leider ohne Erfolg. Ich weiß leider nicht wie ich das konkret umsetzen kann. Zur inside_zone kann ich nämlich nur ein konkretes Interface (und kein Netz) hinzufügen:
Ich bin mir momentan nicht sicher in welche Richtung ich weiter suchen soll.
Vielen lieben Dank für eure Antworten.
ACL habe ich umgebaut:
switch#show access-lists
Extended IP access list VLAN40_to_FW
permit icmp 192.168.40.0 0.0.0.255 host 192.168.95.1 ace-priority 20 type any code any
permit udp 192.168.40.0 0.0.0.255 any host 192.168.95.1 domain ace-priority 25
permit tcp 192.168.40.0 0.0.0.255 any host 192.168.95.1 domain ace-priority 26
deny ip 192.168.40.0 0.0.0.255 host 192.168.95.1 ace-priority 30
permit tcp 192.168.40.0 0.0.0.255 any any www ace-priority 40
permit tcp 192.168.40.0 0.0.0.255 any any 443 ace-priority 50
deny ip host 192.168.40.0 any ace-priority 60Das Problem mit der inside_zone auf der FW klingt logisch. Ich habe das gestern Abend (und auch heute) gleich probiert, aber leider ohne Erfolg. Ich weiß leider nicht wie ich das konkret umsetzen kann. Zur inside_zone kann ich nämlich nur ein konkretes Interface (und kein Netz) hinzufügen:
Ich bin mir momentan nicht sicher in welche Richtung ich weiter suchen soll.
- Kann ich das so überhaupt realisieren? z.B. mittels NAT?
- Oder muss die Verbindung zwischen FW und Core-SW ein Trunk werden, damit ich VLAN40 dann zur inside_zone hinzufügen kann (so wie im Tutorial LINK)?
Nein weder noch.
Du musst lediglich zuerst das 40er IP Netz anlegen und musst dies dann der Inside Zone zuweisen.
Du musst lediglich zuerst das 40er IP Netz anlegen und musst dies dann der Inside Zone zuweisen.
hmm...
Das habe ich auch genauso gemacht.
Aber im Dialog Edit Security Zone wo ich das Netz zuweisen möchte (siehe oben), kann ich nur Interfaces auswählen. Auf Create new habe ich nur geklickt, dami ihr seht welche Auswahlmöglichkeiten ich habe.
In der ACL könnte ich zwar ein Netzwerk zuweisen, aber nach meinem Verständnis erlaube ich dann aus der Inside Zone nur dem 40er Netz den Zugriff auf die Outside Zone. Oder liege ich hier falsch?
Nach welchem Befehl in der CLI müsste ich Ausschau halten?
Das habe ich auch genauso gemacht.
Aber im Dialog Edit Security Zone wo ich das Netz zuweisen möchte (siehe oben), kann ich nur Interfaces auswählen. Auf Create new habe ich nur geklickt, dami ihr seht welche Auswahlmöglichkeiten ich habe.
In der ACL könnte ich zwar ein Netzwerk zuweisen, aber nach meinem Verständnis erlaube ich dann aus der Inside Zone nur dem 40er Netz den Zugriff auf die Outside Zone. Oder liege ich hier falsch?
Nach welchem Befehl in der CLI müsste ich Ausschau halten?
Müsste im GUI "Dynamic Auto PAT" sein.
https://www.cisco.com/c/en/us/td/docs/security/firepower/70/configuratio ...
https://www.cisco.com/c/en/us/td/docs/security/firepower/70/configuratio ...
1
Danke für den Tipp! Ich konnte das unter "NAT" konfigurieren.
Die gute Nachricht - ich bin einen Schritt weiter!
Ausgehend von PC2 im VLAN40 habe ich nun den ersten Traffic auf der FW gesehen.
Einziger Wehrmutstropfen, ich kann die Internetseiten nur rudimentär aufrufen, nämlich indem ich die IP Adresse eingebe. nslookup am PC liefert demnach leider auch noch kein Ergebnis - obwohl UDP und TCP Port 53 in der ACL eingetragen sind. Eine dahingehende Einschränkung auf der FW wäre mir auf den ersten Blick nicht aufgefallen.
Testweise habe ich auch mal VLAN1 über die FW geroutet und hier klappt es wunderbar.
Um das Problem mit der nicht funktionierenden Namensauflösung werde ich mich morgen kümmern.
Die gute Nachricht - ich bin einen Schritt weiter!
Ausgehend von PC2 im VLAN40 habe ich nun den ersten Traffic auf der FW gesehen.
Einziger Wehrmutstropfen, ich kann die Internetseiten nur rudimentär aufrufen, nämlich indem ich die IP Adresse eingebe. nslookup am PC liefert demnach leider auch noch kein Ergebnis - obwohl UDP und TCP Port 53 in der ACL eingetragen sind. Eine dahingehende Einschränkung auf der FW wäre mir auf den ersten Blick nicht aufgefallen.
Testweise habe ich auch mal VLAN1 über die FW geroutet und hier klappt es wunderbar.
Um das Problem mit der nicht funktionierenden Namensauflösung werde ich mich morgen kümmern.
Einziger Wehrmutstropfen
https://www.duden.de/rechtschreibung/Wermut"Wehren" muss man sich in der Regel beim Wermut trinken nicht! 🤣
nslookup am PC liefert demnach leider auch noch kein Ergebnis
Bedeutet dann das du zusätzlich noch ein DNS Problem hast!- Welchen DNS Server zeigt dir nslookup denn am PC an den er nutzt und welchen er via DHCP gelernt hat (ipconfig -all)?
- Wenn das die Firewall ist ist DNS denn dort überhaupt aktiviert? Kannst du über die Diagnotics Tools der Firepower deren DNS Funktion checken?
- Prüfe ob es ein Regelwerk gibt das DNS Requests ggf. nur aus dem VLAN 1 erlaubt
"Wehren" muss man sich in der Regel beim Wermut trinken nicht! 🤣
Den hätte ich gestern Abend auch fast gebraucht, nachdem ich mich kurz bevor ich Schluss machen wollte mit einer fehlerhaften ACL vom Core-Switch ausgesperrt habe. --> Mit "heller Begeisterung" habe ich dann das serielle Terminal-Kabel gesucht und bin mit einem alten Laptop zum Switch gepilgert um das Problem zu beheben.... Aber zurück zum eigentlichen Problem:
- Den DHCP Server habe ich heute früh gleich als erstes gecheckt. Hier hatte ich für VLAN40 keinen DNS-Server hinterlegt. Ich habe hier (Domain Name Server IP Address (Option 6)) einfach mal 8.8.8.8 eingetragen woraufhin nslookup auf PC2 ein anderes Ergebnis geliefert hat.
- Das hat alleine aber noch nicht geholfen, denn die ACL für VLAN40 (siehe oben) ging ja davon aus, dass der DNS-Request an die IP der FW geht. Die ACL hat damit die Namensauflösung (wie konfiguriert) geblockt.
- Nachdem ich die ACL (FW-IP rausgenommen) angepasst habe, kann PC2 nun auch erfolgreich eine Internetseite öffnen.
Ganz zufrieden mit ich mit der Lösung des DNS-Problems aber noch nicht.
Wünschenswert wäre nämlich wenn ich am Switch gar keinen DNS-Server angeben müsste und er stattdessen von der FW durchgereicht wird. Alternativ könnte ich mir auch noch vorstellen die FW-IP als DNS-Server einzutragen.
Dazu habe ich allerdings noch keine Idee.
Kommt der DHCP-Server der FW zum Zug, weil ich beispielsweise einen PC direkt auf der FW anstecke, dann werden einerseits die DNS-Server, welche auf der FW konfiguriert sind, verwendet. Und andererseits wird auch der DNS-Suffix vom outside-interface durchgereicht.
Mit "heller Begeisterung" habe ich dann das serielle Terminal-Kabel gesucht und bin mit einem alten Laptop zum Switch gepilgert um das Problem zu beheben...
Daran erkennt man den Profi! 👏 👍Hier hatte ich für VLAN40 keinen DNS-Server hinterlegt.
Du redest dann hier vom DHCP Server auf dem L3 Switch, richtig?? 🤔Die Firepower "sieht" dieses geroutete Netz ja nicht. Zudem ist ihr DHCP Server nicht Relay fähig im Vergleich zu einem Catalyst Switch.
Die ACL hat damit die Namensauflösung (wie konfiguriert) geblockt.
Ähhh... Nein, die dir gepostet ACL gibt ganz im Gegenteil DNS extra frei!! Hier hast du wohl etwas missverstanden?!permit udp 192.168.40.0 0.0.0.255 any host 192.168.95.1 domain ace-priority 25
permit tcp 192.168.40.0 0.0.0.255 any host 192.168.95.1 domain ace-priority 26
Irgendwie redest du jetzt wirr...?!
Wünschenswert wäre nämlich wenn ich am Switch gar keinen DNS-Server angeben müsste
Wie sollte das denn deiner Meinung nach gehen wenn der DHCP Server auf dem Switch den Client mit IP, Gateway und DNS Server Adresse bedienen muss.und er stattdessen von der FW durchgereicht wird.
Das würde auch gehen. Dann verwendest du keinen DHCP Server auf dem Switch sondern konfigurierst dort schlicht und einfach ein DHCP Relay (DHCP Helper Adresse) und forwardest den Request auf den DHCP Server der Firewall die dann einen entsprechenden VLAN 40 Scope haben muss. Das ist die übliche Vorgehensweise und best Practise in segmentierten Netzen die einen zentralen DHCP Server betreiben.Frühere Versionen der Firepower Firmware supportete kein Relay für ihren DHCP Server. Sieht aber so aus als ob sich das mittlerweile ggf. geändert hat:
https://www.cisco.com/c/de_de/support/docs/security/firepower-ngfw/20047 ...
Kann man aber nur hoffen das es nicht nur der Agent only ist auf dem FTD. Versuch macht klug!
Auf einem Cisco Router zu mindestens funktioniert dessen DHCP Server problemlos und fehlerfrei auch mit Relay!! 😉
Sollte das klappen benötigst du keinen DHCP Server mehr auf dem L3 Switch.
Wenn nicht musst du logischerweise den Switch DHCP Server bemühen das der IP, Gateway, DNS Server und DNS-Suffix mitgibt. Oder du verwendest einen separaten DNS Server. Dann idealerweise gleich einen mit Filter wie z.B. Adguard oder PiHole die dann auch gleich alle Clients Werbe- und Malware frei surfen lässt.
Hallo aqui,
Ich fürchte da hab ich auch einfach nur vor mich hin gebrabbelt und nicht weiter darüber nachgedacht.
@acl:
So wie ich die ACL interpretiere kann damit das 40er Netz den DNS-Request nur an die FW weiterleiten. Diese müsste dann die Namensauflösung übernehmen oder weiterleiten, korrekt?
Den DNS-Server kann ich nur am DHCP-Server pflegen.
Was habe ich versucht und was war das Ergebnis mit nslookup auf PC2:
Damit ich 3 und 4 testen konnte, habe ich die ACL vorübergehend folgendermaßen abgeändert. Meine Annahme dafür war, dass der DNS-Request nun nicht mehr an die IP der FW geht, sondern direkt an die Adresse des DNS-Servers und deshalb freigeschalten werden musste:
Ich verstehe aber noch nicht warum die Namensauflösung bei der Konfiguration 3 klappt, bei 2 und 4 aber nicht.
Was ich im Connection Log der FW sehe:
Bei 2) Die DNS-Requests an 192.168.95.1 scheinen nicht auf
Bei 4) Die an 8.8.8.8 dagegen schon
Auf der FW erhalte ich bei show dns folgendes Ergebnis:
@dhcp Relay: Ich denke der Switch könnte das . Zumindest habe ich einen Punkt "DHCP Snooping/Relay" gefunden.
@dhcp auf der FTD schaut ebenfalls vielversprechend aus.
Ich fürchte da hab ich auch einfach nur vor mich hin gebrabbelt und nicht weiter darüber nachgedacht.
@acl:
permit udp 192.168.40.0 0.0.0.255 any host 192.168.95.1 domain ace-priority 25
permit tcp 192.168.40.0 0.0.0.255 any host 192.168.95.1 domain ace-priority 26Den DNS-Server kann ich nur am DHCP-Server pflegen.
- kein DNS-Server gepflegt -> PC2: Die Standardserver sind nicht verfügbar -> ok, klar.
- FW IP (192.168.95.1) gepflegt: PC2: DNS-Request timed out. Server UnKnown, Address: 192.168.95.1
- Öffentlichen DNS eines regionalen Providers gepflegt: Server mit Adresse kann erfolgreich aufgelöst werden!
- Öffentlichen DNS (8.8.8.8 oder 208.67.222.222) gepflegt: DNS-Request timed out. Server UnKnown, Address: ...
Damit ich 3 und 4 testen konnte, habe ich die ACL vorübergehend folgendermaßen abgeändert. Meine Annahme dafür war, dass der DNS-Request nun nicht mehr an die IP der FW geht, sondern direkt an die Adresse des DNS-Servers und deshalb freigeschalten werden musste:
permit udp 192.168.40.0 0.0.0.255 any any domain ace-priority 25
permit tcp 192.168.40.0 0.0.0.255 any any domain ace-priority 26Ich verstehe aber noch nicht warum die Namensauflösung bei der Konfiguration 3 klappt, bei 2 und 4 aber nicht.
Was ich im Connection Log der FW sehe:
Bei 2) Die DNS-Requests an 192.168.95.1 scheinen nicht auf
Bei 4) Die an 8.8.8.8 dagegen schon
Auf der FW erhalte ich bei show dns folgendes Ergebnis:
> show dns
DNS Trusted Source enabled for DHCP Server Configured
DNS Trusted Source enabled for DHCP Client Learned
DNS Trusted Source enabled for DHCP Relay Learned
DNS Trusted Source enabled for DNS Server Configured
DNS Trusted Source not enabled for Trust-any
DNS Trusted Source: Type: IPs : Interface : Idle/Timeout (sec)
DNS Server Configured: 208.67.222.222: <ifc-not-specified> : N/A
DNS Server Configured: 208.67.220.220: <ifc-not-specified> : N/A
DNS Server Configured: 2620:119:35::35: <ifc-not-specified> : N/A
DNS snooping IP cache: 0 in use, 0 most used
Address Idle(sec) Timeout(sec) Hit-count Branch(es)@dhcp Relay: Ich denke der Switch könnte das . Zumindest habe ich einen Punkt "DHCP Snooping/Relay" gefunden.
@dhcp auf der FTD schaut ebenfalls vielversprechend aus.
So wie ich die ACL interpretiere kann damit das 40er Netz den DNS-Request nur an die FW weiterleiten. Diese müsste dann die Namensauflösung übernehmen oder weiterleiten, korrekt?
Das ist absolut korrekt!Bei 2) Die DNS-Requests an 192.168.95.1 scheinen nicht auf
Scheinen tut die Sonne...?!? Was soll uns dieser kryptische Satz sagen??Versteht man das richtig dann sendest du einmal die PC DNS Requests an die 95.1 (FW) und einmal an 8.8.8.8. Google klappt, FW scheitert, richtig?
Zeigt ja dann das die FW ein DNS Problem hat bzw. arbeitet gar nicht als DNS. Oder...blockiert DNS Requests die nicht aus IP Netzen / Zonen kommen die an sie direkt angeschlossen sind.
Da musst du nochmal forschen... Letzteres wahrscheinlicher wenns aus den lokalen Netzen klappt mit ihr als DNS.
Ich verstehe aber noch nicht warum die Namensauflösung bei der Konfiguration 3 klappt
Eigentlich doch ganz logisch. Bei 3, also Google, fragt der PC den ja direkt und umgeht die FW komplett. Das das klappt ist dann klar sofern die 8.8.8.8 erreichbar ist als "das Internet" geht.2 und 4 nutzt ja als DNS die Firewall, die die DNS Auflösung aus den o.a. Gründen verweigert. Das Verhalten ist also erklär- und erwartbar.
DNS Trusted Source not enabled for Trust-any
Da sieht man schon das Elend... 
"DNS Trusted Source not enabled for Trust-any" bedeutet wie oben schon vermutet das nur lokale Netze "Trusted" sind. Das musst du auf die .40.0 /24 anpassen, dann sollte es klappen.
Ich denke der Switch könnte das...
Das ist richtig!Wenn du so oder so den DHCP Server zentral auf der FW pflegst wurde es ggf. Sinn machen dort einen Scope für das 40er Netz einzutragen und es via Relay zu bedienen. Wird sehr wahrscheinlich auch klappen.
Du solltest so oder so dieses Konzept zum Gastnetz (V40) Handling noch einmal in Ruhe überdenken...
Normalerweise legt man so ein Gastnetz niemals routingtechnisch mit auf einen L3 Switch der lokale Netze routet. Auch wenn man mit ACLs den Gasttraffic einschränkt hat man dies Netz aber immer L3-technisch direkt auf dem lokalen Router liegen. ACLs sind bekanntlich nicht stateful und ein Fehler da und man hat Gäste dann vielleicht auch einmal da wo man sie besser nicht haben möchte.
Wenn möglich ist es ggf. sinnvoller das VLAN 40 nur L2-technisch durch den Switch "durchzuschleifen" ohne ein L3 Interface dort. Dies migriert man dann auf die Firewall.
So hat man das L3 Forwarding des Gastnetzes direkt auf der Firewall und kann mit einem deutlich besseren Regelwerk, was auch stateful ist, den Gasttraffic einschränken.
Solche hybriden Designs sind üblicherweise Standard wenn man unsichere Netzsegmente transportieren muss. Nur mal so als Anregung...
Wenn es das denn nun war als Lösung bitte nicht vergessen deinen Thread hier dann auch als erledigt zu schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
