17
Default-Gateway und policy-based-routing PBR auf Cisco Switch
Hallo und ein frohes neues Jahr nachträglich wünsche ich Allen,
meine Umstrukturierung der Netzwerkstruktur beinhaltet auch die Einführung VLANs und einer pfSense Firewall. Hier erstmal ein grober Überblick mit dem aktuellen Ist-Stand:
Der Cisco C3560 switch ist mit der pfSense Firewall mittels eines 802.1q trunks verbunden, durch welchen die einzelnen VLANs übertragen werden und anschließend am jeweiligen interface der pfSense landen. Somit kann die pfSense diverse Dienste anbieten, z.B. läuft auf dem em0_vlan200 interface auf der pfSense Box ein DHCP-Server, der die Workstations aus dem VLAN200 Netzk mit DHCP-leases versorgt.
Als default-Gateway nutzen alle Hosts (außer die DMZ-Hosts) den Cisco C3560 root switch, z.B.
Server aus dem VLAN100 haben das default gw 172.19.100.253
Workstations aus dem VLAN200 nutzen das gw 172.19.200.253
die Rechner aus dem Horror-16er-Netz nutzen 172.16.254.1
Der Cisco 3560 switch hat als default-route eingetragen ==> 0.0.0.0/0 via 172.19.253.254 und somit werden alle Pakete, die nicht näher definiert wurden am c3560 switch an die pfSense weitergeleitet. Dort kann ich dann zentral durch die Policys/Firewall-Rules steuern, wer ins Internet darf, was er darf, usw...
Allerdings steh ich dabei vor folgendem Problem und bin mir nicht sicher, welchen Lösungsansatz ich anstreben sollte.
Szenario:
Der ServerA mit IP 172.19.100.1/24 sendet einen ICMP ping an die öffentliche Internet-Adresse 8.8.8.8. Allerdings schlägt der Ping fehl. Ich habe das gemonitored und debugged und der Grund hierfür liegt nicht an einer firewall-Beschränkung sondern an einem Routing-Problem. Das Paket erreicht zwar das Ziel, aber das generierte ICMP-Antwortpaket wird über einen anderen Pfad geschickt. Aus diesem Grund schlägt der Ping-Befehl, welcher am ServerA ausgeführt wird, fehl.
Was passiert?
Das Paket wird von ServerA auf die Reise geschickt und trägt SIP=172.19.100.1 und DIP=8.8.8.8. Der ServerA schaut in seinen routing table und schickt das Paket an das default gw welches das 172.19.100.253 ist, also der cisco switch. Der cisco Switch wiederum schaut in seinen routing table und schickt das Paket weiter mittels der default route 0.0.0.0, die auf 172.19.253.254 zeigt. Das bedeutet, dass das Paket das VLAN253 interface 172.19.253.253 am Cisco-Switch verläßt und am VLAN253 interface 172.19.253.254 in der pfSense-Box eintrifft. Die pfSense Kiste sieht nun, dass das Paket für das öffentliche Internet destiniert ist und schickt es über sein em1/WAN interface raus ins Internet.
Der Host 8.8.8.8 generiert schnürt nun das ICMP Antwortpaket (ICMP echo reply) mit dem Ziel ServerA. Die pfSense möchte nun dieses Antwortpaket (nachdem es NAT durchlaufen hat) zum ServerA schicken, weil destination IP = 172.19.100.1 draufsteht. pfSense schaut in sein routing table und da pfSense ein VLAN100 interface bereits besitzt, wird das Paket durch dieses Interface auf die Reise geschickt. Das Paket verläßt das VLAN100 interface 172.19.100.254 und landet im cisco switch auf dem VLAN100 interface 172.19.100.253. Der cisco switch schickt dann über das selbe interface VLAN100 an den Zielhost 172.19.100.1.
Allerdings scheint der "ping"-Befehl damit nicht zu funktionieren, der ping schlägt fehl. Ich VERMUTETE daher, dass es am unterschiedlichen Transportweg liegt. Daher habe ich das mit einem einfachen Test ausprobiert:
auf dem cisco-switch habe ich folgende statische kurzzeitig manuell hinzugefügt:
- conf t
- ip route 8.8.8.8 255.255.255.255 172.19.100.254
Dadurch forciere ich, dass alle Anfragen die an 8.8.8.8 gerichtet sind, über das VLAN100 interface den cisco-switch verlassen. Und damit klappt dann sofort der Ping! Also denk ich, dass ich mit meiner Vermutung richtig lag.
Nun mach ich mir Gedanken, wie ich das richtigerweise lösen sollte und liebäugle momentan mit folgendem Lösungsansatz ==> Policy-Based-Routing (PBR) auf dem Cisco-Switch
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/f ...
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/f ...
Damit kann ich nämlich dem cisco-switch beibringen, dass er anhand bestimmter Regeln das Routing durchführt. Das würde dann so aussehen auf dem cisco-Switch:
- access list 1 permit 172.19.100.0 0.0.0.255
- route-map vlan100
- match ip address 1
- set ip next-hop 172.19.100.254
- int vlan 100
- ip policy route-map vlan100
Dasselbe dann fürs VLAN200 wäre dann...
- access list 2 permit 172.19.200.0 0.0.0.255
- route-map vlan200
- match ip address 2
- set ip next-hop 172.19.200.254
- int vlan 200
- ip policy route-map vlan200
Wenn nun ein Paket auf dem cisco-Switch eintrifft, dann wird anhand diesem PBR geprüft und gehandelt. Ein Paket aus der Quelle 172.19.100.0/24 würde somit als nächsten Hop 172.19.100.254 tragen, und demnach den cisco-Switch zwangsweise über das VLAN100-interface mit der IP 172.19.100.253 verlassen.
Damit PBR auf dem cisco-Switch funktioniert, muss einerseits das entsprechende image IPSERVICES vorhanden sein (das habe ich auch) und WCCP darf nicht aktiviert sein (denn WCCP und PBR funktioniert laut Cisco nicht!). Außerdem muss das sdm template von "default" --auf--> "routing" abgeändert werden, damit PBR genutzt werden kann.
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software ...
Bei diesem Wechsel des templates muss der switch zwangsweise reloaded (=rebooted) werden und man sollte sich im Klaren sein, dass die Leistung entsprechend angepasst wird (siehe Link). Ich hab mal mit show mac address-table | in Total geprüft wieviel mein switch momentan eigentlich so abarbeiten tut, und mit ~300 Einträgen sollte das IMHO kein Problem darstellen.
Ich würde jedoch gerne die Meinung der Profis hören, was meint ihr dazu? Oder würdet ihr das ganz anders lösen und falls ja wie? Ich freue mich auf eure Meinungen und Anregungen.
Besten Dank im Voraus und viele Grüße,
Panguu.
meine Umstrukturierung der Netzwerkstruktur beinhaltet auch die Einführung VLANs und einer pfSense Firewall. Hier erstmal ein grober Überblick mit dem aktuellen Ist-Stand:
Der Cisco C3560 switch ist mit der pfSense Firewall mittels eines 802.1q trunks verbunden, durch welchen die einzelnen VLANs übertragen werden und anschließend am jeweiligen interface der pfSense landen. Somit kann die pfSense diverse Dienste anbieten, z.B. läuft auf dem em0_vlan200 interface auf der pfSense Box ein DHCP-Server, der die Workstations aus dem VLAN200 Netzk mit DHCP-leases versorgt.
Als default-Gateway nutzen alle Hosts (außer die DMZ-Hosts) den Cisco C3560 root switch, z.B.
Server aus dem VLAN100 haben das default gw 172.19.100.253
Workstations aus dem VLAN200 nutzen das gw 172.19.200.253
die Rechner aus dem Horror-16er-Netz nutzen 172.16.254.1
Der Cisco 3560 switch hat als default-route eingetragen ==> 0.0.0.0/0 via 172.19.253.254 und somit werden alle Pakete, die nicht näher definiert wurden am c3560 switch an die pfSense weitergeleitet. Dort kann ich dann zentral durch die Policys/Firewall-Rules steuern, wer ins Internet darf, was er darf, usw...
Allerdings steh ich dabei vor folgendem Problem und bin mir nicht sicher, welchen Lösungsansatz ich anstreben sollte.
Szenario:
Der ServerA mit IP 172.19.100.1/24 sendet einen ICMP ping an die öffentliche Internet-Adresse 8.8.8.8. Allerdings schlägt der Ping fehl. Ich habe das gemonitored und debugged und der Grund hierfür liegt nicht an einer firewall-Beschränkung sondern an einem Routing-Problem. Das Paket erreicht zwar das Ziel, aber das generierte ICMP-Antwortpaket wird über einen anderen Pfad geschickt. Aus diesem Grund schlägt der Ping-Befehl, welcher am ServerA ausgeführt wird, fehl.
Was passiert?
Das Paket wird von ServerA auf die Reise geschickt und trägt SIP=172.19.100.1 und DIP=8.8.8.8. Der ServerA schaut in seinen routing table und schickt das Paket an das default gw welches das 172.19.100.253 ist, also der cisco switch. Der cisco Switch wiederum schaut in seinen routing table und schickt das Paket weiter mittels der default route 0.0.0.0, die auf 172.19.253.254 zeigt. Das bedeutet, dass das Paket das VLAN253 interface 172.19.253.253 am Cisco-Switch verläßt und am VLAN253 interface 172.19.253.254 in der pfSense-Box eintrifft. Die pfSense Kiste sieht nun, dass das Paket für das öffentliche Internet destiniert ist und schickt es über sein em1/WAN interface raus ins Internet.
Der Host 8.8.8.8 generiert schnürt nun das ICMP Antwortpaket (ICMP echo reply) mit dem Ziel ServerA. Die pfSense möchte nun dieses Antwortpaket (nachdem es NAT durchlaufen hat) zum ServerA schicken, weil destination IP = 172.19.100.1 draufsteht. pfSense schaut in sein routing table und da pfSense ein VLAN100 interface bereits besitzt, wird das Paket durch dieses Interface auf die Reise geschickt. Das Paket verläßt das VLAN100 interface 172.19.100.254 und landet im cisco switch auf dem VLAN100 interface 172.19.100.253. Der cisco switch schickt dann über das selbe interface VLAN100 an den Zielhost 172.19.100.1.
Allerdings scheint der "ping"-Befehl damit nicht zu funktionieren, der ping schlägt fehl. Ich VERMUTETE daher, dass es am unterschiedlichen Transportweg liegt. Daher habe ich das mit einem einfachen Test ausprobiert:
auf dem cisco-switch habe ich folgende statische kurzzeitig manuell hinzugefügt:
- conf t
- ip route 8.8.8.8 255.255.255.255 172.19.100.254
Dadurch forciere ich, dass alle Anfragen die an 8.8.8.8 gerichtet sind, über das VLAN100 interface den cisco-switch verlassen. Und damit klappt dann sofort der Ping! Also denk ich, dass ich mit meiner Vermutung richtig lag.
Nun mach ich mir Gedanken, wie ich das richtigerweise lösen sollte und liebäugle momentan mit folgendem Lösungsansatz ==> Policy-Based-Routing (PBR) auf dem Cisco-Switch
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/f ...
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/f ...
Damit kann ich nämlich dem cisco-switch beibringen, dass er anhand bestimmter Regeln das Routing durchführt. Das würde dann so aussehen auf dem cisco-Switch:
- access list 1 permit 172.19.100.0 0.0.0.255
- route-map vlan100
- match ip address 1
- set ip next-hop 172.19.100.254
- int vlan 100
- ip policy route-map vlan100
Dasselbe dann fürs VLAN200 wäre dann...
- access list 2 permit 172.19.200.0 0.0.0.255
- route-map vlan200
- match ip address 2
- set ip next-hop 172.19.200.254
- int vlan 200
- ip policy route-map vlan200
Wenn nun ein Paket auf dem cisco-Switch eintrifft, dann wird anhand diesem PBR geprüft und gehandelt. Ein Paket aus der Quelle 172.19.100.0/24 würde somit als nächsten Hop 172.19.100.254 tragen, und demnach den cisco-Switch zwangsweise über das VLAN100-interface mit der IP 172.19.100.253 verlassen.
Damit PBR auf dem cisco-Switch funktioniert, muss einerseits das entsprechende image IPSERVICES vorhanden sein (das habe ich auch) und WCCP darf nicht aktiviert sein (denn WCCP und PBR funktioniert laut Cisco nicht!). Außerdem muss das sdm template von "default" --auf--> "routing" abgeändert werden, damit PBR genutzt werden kann.
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software ...
Bei diesem Wechsel des templates muss der switch zwangsweise reloaded (=rebooted) werden und man sollte sich im Klaren sein, dass die Leistung entsprechend angepasst wird (siehe Link). Ich hab mal mit show mac address-table | in Total geprüft wieviel mein switch momentan eigentlich so abarbeiten tut, und mit ~300 Einträgen sollte das IMHO kein Problem darstellen.
Ich würde jedoch gerne die Meinung der Profis hören, was meint ihr dazu? Oder würdet ihr das ganz anders lösen und falls ja wie? Ich freue mich auf eure Meinungen und Anregungen.
Besten Dank im Voraus und viele Grüße,
Panguu.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 259824
Url: https://administrator.de/forum/default-gateway-und-policy-based-routing-pbr-auf-cisco-switch-259824.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
17 Kommentare
Neuester Kommentar
Guten Abend Panguu,
das Verhalten würde ich als normal bezeichnen. Ich würde behaupten, wenn die pfSense das Default Gateway ist, wird der Ping problemlos funktionieren. EInem Client eine manuelle IP-Adresse geben und testen.
Warum ist der Switch überhaupt das Default-Gateway in dem VLAN? Was ist deine Idee dabei?
Wenn du die VLANs nicht durch die pfSense Regeln sauber trenen möchtest und jedes VLAN darf alles im Anderen erreichen, würde ich den Cisco als Default Gateway belassen, den Trunk zwischen Switch und pfSense auflösen und ein Transfernetz mit einer Subnetzmaske /30 einrichten.
Gruß,
Dani
das Verhalten würde ich als normal bezeichnen. Ich würde behaupten, wenn die pfSense das Default Gateway ist, wird der Ping problemlos funktionieren. EInem Client eine manuelle IP-Adresse geben und testen.
Warum ist der Switch überhaupt das Default-Gateway in dem VLAN? Was ist deine Idee dabei?
Wenn du die VLANs nicht durch die pfSense Regeln sauber trenen möchtest und jedes VLAN darf alles im Anderen erreichen, würde ich den Cisco als Default Gateway belassen, den Trunk zwischen Switch und pfSense auflösen und ein Transfernetz mit einer Subnetzmaske /30 einrichten.
Gruß,
Dani
Hi Dani,
natürlich würde es funktionieren, wenn ich allen Hosts im LAN als default gw die IP der pfSense geben würde, aber als Router möchte ich eigentlich den Cisco 3560 nutzen. Der Grund dafür war eigentlich:
- der Cisco C3560 hat eine deutlich höhere Schalt-/Rechenkapazität
- der Cisco C3560 läuft zuverlässig und ohne Probleme mit jahrelanger uptime. Das ist eben ein Cisco und dafür kosten die auch einiges, weil sie viel können und das auch zuverlässig tun
- der Cisco C3560 router im Vorfeld schon einige Sachen hin- und her zwischen verschiedenen Netzen. Da sind einige statische Routen eingetragen und aktiv
wieso denn, ich kann doch mit ACLs genau regeln welches VLAN wohin darf und wohin eben nicht. Was meintest du damit?
kannst du das näher erläutern bitte? wenn ich dich richtig verstanden habe, dann meinst du also dass die Verbindung zwischen Cisco-Switch und der pfSense über ein einziges Netz, z.B. VLAN253 stattfinden soll? Dann könnte ich aber keine Dienste gezielt bereit stellen, z.B. möchte ich den DHCP-Server auf der pfSense dazu nutzen, damit dieser leases für VLAN200 oder auch VLAN15 verteilt. Oder eben Squid-Proxy-Dienst bereitstellen, für VLAN123 und VLAN200. Oder eben Dienst xyz .... das könnte ich ja dann schlecht lösen, oder nicht?
Danke und Gruß,
Panguu
natürlich würde es funktionieren, wenn ich allen Hosts im LAN als default gw die IP der pfSense geben würde, aber als Router möchte ich eigentlich den Cisco 3560 nutzen. Der Grund dafür war eigentlich:
- der Cisco C3560 hat eine deutlich höhere Schalt-/Rechenkapazität
- der Cisco C3560 läuft zuverlässig und ohne Probleme mit jahrelanger uptime. Das ist eben ein Cisco und dafür kosten die auch einiges, weil sie viel können und das auch zuverlässig tun
- der Cisco C3560 router im Vorfeld schon einige Sachen hin- und her zwischen verschiedenen Netzen. Da sind einige statische Routen eingetragen und aktiv
Wenn du die VLANs nicht durch die pfSense Regeln sauber trenen möchtest und jedes VLAN darf alles im Anderen erreichen, würde ich den Cisco als Default Gateway belassen, ...
wieso denn, ich kann doch mit ACLs genau regeln welches VLAN wohin darf und wohin eben nicht. Was meintest du damit?
den Trunk zwischen Switch und pfSense auflösen und ein Transfernetz mit einer Subnetzmaske /30 einrichten.
kannst du das näher erläutern bitte? wenn ich dich richtig verstanden habe, dann meinst du also dass die Verbindung zwischen Cisco-Switch und der pfSense über ein einziges Netz, z.B. VLAN253 stattfinden soll? Dann könnte ich aber keine Dienste gezielt bereit stellen, z.B. möchte ich den DHCP-Server auf der pfSense dazu nutzen, damit dieser leases für VLAN200 oder auch VLAN15 verteilt. Oder eben Squid-Proxy-Dienst bereitstellen, für VLAN123 und VLAN200. Oder eben Dienst xyz .... das könnte ich ja dann schlecht lösen, oder nicht?
Danke und Gruß,
Panguu
Zitat von @panguu:
Dann könnte ich aber keine Dienste gezielt bereit stellen, z.B. möchte ich den DHCP-Server auf der pfSense dazu nutzen, damit dieser leases für
VLAN200 oder auch VLAN15 verteilt.
Dann könnte ich aber keine Dienste gezielt bereit stellen, z.B. möchte ich den DHCP-Server auf der pfSense dazu nutzen, damit dieser leases für
VLAN200 oder auch VLAN15 verteilt.
Doch. DHCP-Relay auf dem Layer3-Switch einrichten.
Zitat von @panguu:
Oder eben Squid-Proxy-Dienst bereitstellen, für VLAN123 und VLAN200. Oder eben Dienst xyz
Oder eben Squid-Proxy-Dienst bereitstellen, für VLAN123 und VLAN200. Oder eben Dienst xyz
Der lauscht dann halt nur auf vlan253, ist aber von den anderen VLANs aus per Routing erreichbar. Wenn nicht gewünscht, wird das per ACL unterbunden.
wieso denn, ich kann doch mit ACLs genau regeln welches VLAN wohin darf und wohin eben nicht. Was meintest du damit?
Viele kommen mit der ACL nicht klar. Da ich dich nicht kenne, war ich etwas voreilig.dann meinst du also dass die Verbindung zwischen Cisco-Switch und der pfSense über ein einziges Netz, z.B. VLAN253 stattfinden soll
Völlig unabhängig, ken Trunk, etc... Zum Beispiel: Cisco 192.168.45.1/30 und Firewall 192.168.45.2/30. Somit richtest du für die VLANs routen auf der pfSense ein und los geht's...Oder eben Squid-Proxy-Dienst bereitstellen
Wird weiterhin funktionieren.z.B. möchte ich den DHCP-Server auf der pfSense dazu nutzen, damit dieser leases für VLAN200 oder auch VLAN15 verteilt
Ich würde behaupten, wenn du für jedes VLAN auf den Switch ein DHCP-Relay auf die pfSense einrichtest, sollte es funktionieren.Bei uns ziehen 3 VLANs (10,20,30) die IP-Adressen über die Firewall aus dem VLAN40. Auf der Firewall ist ein DHCP-Relay eingetragen, mehr nicht. Somit sollte das funktionieren. 1000% kann es dir @aqui sagen.
Oder eben Squid-Proxy-Dienst bereitstellen
Kein Problem, dann wird der Proxy eben mit 192.168.45.2 angesprochen und nicht mit der jeweiligen VLAN pfSense IP-Adresse.Gruß,
Dani
Grundlagen zu so einem Setup erklärt auch dieser Thread:
Cisco Router 2 Gateways für verschiedene Clients
Ein paar Anmerkungen zu deinem Packet Flow der fast richtig ist:
Im Ergebnis stimmt aber deine Beschreibung
"Der Cisco C3560 switch ist mit der pfSense Firewall mittels eines 802.1q trunks verbunden, durch welchen die einzelnen VLANs übertragen werden und anschließend am jeweiligen interface der pfSense landen."
Das darf natürlich eigentlich nicht so sein, denn so hast du ja 2 parallele Router in jedem VLAN ?! Einmal die pfSense und einem den L3 Switch.
Ist dem so wäre das grundsätzlich kein gutes Design und führt dann auch zu den beschriebenen Problemen.
Der Cisco sollte generell die VLANs routen und der Trunk zur pfSense sollte grundsätzlich NUR die VLANs beinhalten die kein L3 Interface auf dem Switch haben. So bleiben deine Wege dann aucheinzigartig// und du würdest die PBR ersparen. Mal abgesehen davon das ein paralleler Router auch ein Sicherheitsrisiko darstellen kann !
Ggf. ist das aber auch nur fehlerhaft beschrieben von dir und du hast es genau so gemacht ?!
Also eigentlich ist der Weg klar....
Klar würde PBR das fixen aber man bräuchte es gar nicht wenn man das L3 Design entsprechend anpasst.
Cisco Router 2 Gateways für verschiedene Clients
Ein paar Anmerkungen zu deinem Packet Flow der fast richtig ist:
Der Host 8.8.8.8 generiert schnürt nun das ICMP Antwortpaket (ICMP echo reply) mit dem Ziel ServerA
Das ist schlicht falsch, denn Server A hat eine private RFC 1918 IP die der Host 8.8.8.8 nicht sieht. Was er sieht ist die öffentliche IP deines NAT Routers oder Firewall als Ziel !zum ServerA schicken, weil destination IP = 172.19.100.1 draufsteht
Nein nicht ganz.. Es steht NICHT in der Destination IP (da steht die öffentliche IP) sondern die pfSense ermittelt die lokale Ziel IP aus ihrer NAT Translation Tabelle !Im Ergebnis stimmt aber deine Beschreibung
Ich VERMUTETE daher, dass es am unterschiedlichen Transportweg liegt. Daher habe ich das mit einem einfachen Test ausprobiert:
Eigentlich nein, denn im lokalen Netz kannst du unterschiedliche Routing Pfade nutzen. Das sollte eigentlich keinen Einfluss auf die Funktion haben, denne s ändert ja an der Adresstruktur des Paketes nichts. Daran kann es also eigentlich nicht liegen. Ist zwar unsauber aber kann nicht der eigentliche Grund sein. Besser wäre ein Traceroute gewesen der beide Richtungen anzeigt.Damit kann ich nämlich dem cisco-switch beibringen, dass er anhand bestimmter Regeln das Routing durchführt.
Das ist der richtige Weg, allerdings schafft ein Satz in deiner Designbeschreibung doch gehörige Bauchschmerzen:"Der Cisco C3560 switch ist mit der pfSense Firewall mittels eines 802.1q trunks verbunden, durch welchen die einzelnen VLANs übertragen werden und anschließend am jeweiligen interface der pfSense landen."
Das darf natürlich eigentlich nicht so sein, denn so hast du ja 2 parallele Router in jedem VLAN ?! Einmal die pfSense und einem den L3 Switch.
Ist dem so wäre das grundsätzlich kein gutes Design und führt dann auch zu den beschriebenen Problemen.
Der Cisco sollte generell die VLANs routen und der Trunk zur pfSense sollte grundsätzlich NUR die VLANs beinhalten die kein L3 Interface auf dem Switch haben. So bleiben deine Wege dann aucheinzigartig// und du würdest die PBR ersparen. Mal abgesehen davon das ein paralleler Router auch ein Sicherheitsrisiko darstellen kann !
Ggf. ist das aber auch nur fehlerhaft beschrieben von dir und du hast es genau so gemacht ?!
aber als Router möchte ich eigentlich den Cisco 3560 nutzen
Das ist auch richtig und sollte auch unbedingt so bleiben, nur den Fehler hast du selber gemacht das du in allen VLANs die pfSense parallel geschaltet hast. Genau das ist der grundlegende Fehler des Layer 3 Designs !Also eigentlich ist der Weg klar....
- Der L3 Switch ist zentraler Router für die VLANs die untereinander geroutet werden sollen und dürfen
- Nur ein separates Transfer VLAN vom L3 Switch zur pfSense für den Internet Zugang. Default Route auf dem L3 Switch.
- Alle VLANs die sicherheitshalber isoliert sein sollen bekommen KEIN vlan Interface auf dem Switch sondern einzig auf der Firewall. Nur einzig diese VLANs und das Transfer VLAN sind im Trunk zur pfSense.
Klar würde PBR das fixen aber man bräuchte es gar nicht wenn man das L3 Design entsprechend anpasst.
Hallo aqui und Rest,
ich glaube exakt das ist das Problem, so wie du es erörtert hast. Ich hab da wohl einen Designfehler eingebaut und deswegen bin ich mir an diesem Schritt nicht mehr sicher gewesen. Als ich die pfSense aufgesetzt habe, nutzte ich anfangs nur ein einziges Transfer-VLAN, das war das VLAN253. Ich hab also auf dem cisco switch das VLAN253 interface mit der IP 172.19.253.253/24 erstellt und ein VLAN253 interface auf der pfsense mit der IP 172.19.253.254/24
Allerdings wollte ich sämtliche Zugriffslisten zentral auf der pfSense konfigurieren, weil die firewall ja bekanntlich auch dafür da ist und über WebGUI das ganz easy geht. Auf der pfSense möchte ich erlauben wer wohin darf oder eben bestimmte Sachen verbieten. Ich möchte gerne den DHCP-Server der pfsense nutzen, um Leases an VLAN15 und VLAN200 und VLAN123 zu verteilen mit verschiedenen Konfigurationen. Auch wollte ich den squid auf der pfSense nutzen, damit mittels wccp (so wie du es mir vor einiger Zeit in meinem anderen Posting vorgeschlagen und erklärt hattest) auf dem cisco alle Webanfragen der Workstations auf den transparenten squid auf pfSense weitergereicht werden.
Nun verstehe ich nicht: wenn ich nur ein einziges VLAN253 nutze zwischen dem cisco switch und der pfSense... wie sollte ich dann auf der pfSense in der Lage sein, Sachen wie "VLAN100/subnet 172.19.100.0/24 darf ins Internet", "VLAN20/subnet 172.19.200.0/24 darf NICHT ins Internet", "VLAN44/subnet 172.19.44.0/24 darf xyz", usw.... ???
ich glaube exakt das ist das Problem, so wie du es erörtert hast. Ich hab da wohl einen Designfehler eingebaut und deswegen bin ich mir an diesem Schritt nicht mehr sicher gewesen. Als ich die pfSense aufgesetzt habe, nutzte ich anfangs nur ein einziges Transfer-VLAN, das war das VLAN253. Ich hab also auf dem cisco switch das VLAN253 interface mit der IP 172.19.253.253/24 erstellt und ein VLAN253 interface auf der pfsense mit der IP 172.19.253.254/24
Allerdings wollte ich sämtliche Zugriffslisten zentral auf der pfSense konfigurieren, weil die firewall ja bekanntlich auch dafür da ist und über WebGUI das ganz easy geht. Auf der pfSense möchte ich erlauben wer wohin darf oder eben bestimmte Sachen verbieten. Ich möchte gerne den DHCP-Server der pfsense nutzen, um Leases an VLAN15 und VLAN200 und VLAN123 zu verteilen mit verschiedenen Konfigurationen. Auch wollte ich den squid auf der pfSense nutzen, damit mittels wccp (so wie du es mir vor einiger Zeit in meinem anderen Posting vorgeschlagen und erklärt hattest) auf dem cisco alle Webanfragen der Workstations auf den transparenten squid auf pfSense weitergereicht werden.
Nun verstehe ich nicht: wenn ich nur ein einziges VLAN253 nutze zwischen dem cisco switch und der pfSense... wie sollte ich dann auf der pfSense in der Lage sein, Sachen wie "VLAN100/subnet 172.19.100.0/24 darf ins Internet", "VLAN20/subnet 172.19.200.0/24 darf NICHT ins Internet", "VLAN44/subnet 172.19.44.0/24 darf xyz", usw.... ???
Als ich die pfSense aufgesetzt habe, nutzte ich anfangs nur ein einziges Transfer-VLAN, das war das VLAN253. Ich hab also auf dem cisco switch das VLAN253 interface mit der IP 172.19.253.253/24 erstellt und ein VLAN253 interface auf der pfsense mit der IP 172.19.253.254/24
Das ist der richtige Weg ! du kannst sogar einen /30 Maske da verwenden denn du brauchst ja nur 2 IPs 
Allerdings wollte ich sämtliche Zugriffslisten zentral auf der pfSense konfigurieren,
Zugriffslisten auf WAS ? Internet oder auch die VLANs unter sich ??Letzteres machst du in deinem aktuellen Konzept immer mit Cisco Access Listen auf dem Catalyst !!
über WebGUI das ganz easy geht
Beim Cisco im CLI auch. Allerdings sind die ACLs nicht stateful aber der Switch kann damit performanter umgehen und wirklich wichtig ist es ja ins gefährliche Internet was die pfSense ja weiter macht.Ich möchte gerne den DHCP-Server der pfsense nutzen, um Leases an VLAN15 und VLAN200 und VLAN123 zu verteilen mit verschiedenen Konfigurationen
Das ist ja auch kein Thema ! Die ip helper Adressen auf dem Cisco sind deine Freunde !Generell ist es aber besser einen zenralen DHCP Server zu verwenden so das du nur einen Punkt hast an dem du zentral DHCP verwaltest !
Das ist erheblich sinnvoller und auch sicherer.
Ein kleiner raspberry Pi reicht wenn du nicht irgendwoe eh einen Winblows Server am glühen hast:
Netzwerk Management Server mit Raspberry Pi
Alle sicherheitsrelevanten VLAN Segmente ohne L3 Switchinterface kannst du ja weiter von der pfSense bedienen lassen obwohl man hier ja eher weniger DHCP macht und statische IPs verwendet.
Außerdem kann der Catalyst auch DHCP Server spielen wenn alle Stricke reissen. Auch mit Mac Adress spezifischer Optionsvergabe. IOS Beispiel dazu findest du hier:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
wie sollte ich dann auf der pfSense in der Lage sein, Sachen wie "VLAN100/subnet 172.19.100.0/24 darf ins Internet", "VLAN20/subnet 172.19.200.0/24 darf NICHT ins Internet",
Na komm jetzt....das meinst du als pfSense User nicht im Ernst, oder ?? Tip: Die Absender IP aus diesen VLANs steht ja im IP Paket das an der pfSense ankommt und du richtest ganz einfach am pfSense Interface im VLAN 253 ein Deny (FW Regel) ein bei diesen Absender IPs oder Netzen...ganz einfach
du kannst sogar einen /30 Maske da verwenden denn du brauchst ja nur 2 IPs
Jup, hast Recht. Hat mir Dani ja auch schon vorgeschlagen... eine /30 er Maske würde vollkommen genügenZugriffslisten auf WAS ? Internet oder auch die VLANs unter sich ?? Letzteres machst du in deinem aktuellen Konzept immer mit Cisco Access Listen auf dem Catalyst !!
Nunja, auf dem Cisco switch werden ja die VLANs geroutet und das ist der erste Anlaufpunkt der Pakete, da sie sich hier alle treffen und entsprechend weiterverarbeitet werden. Alle Pakete, die dann an die DMZ oder das INTERNET gerichtet sind, werden zur pfSense weitergeleitet. Und ich würde gerne komfortabel über die WebGUI von pfSense regeln können, wer eben bestimmte Sachen im Internet oder der DMZ erreichen darf und wer nicht. Beispiele:
- auf dem cisco Switch habe ich ja als default gw 0.0.0.0 die 172.19.253.254 angegeben, so dass vom cisco switch unbekannte Routenanfragen einfach an die pfSense weitergeleitet werden. Damit hätte aber jeder Host, der nicht explizit durch eine ACL vorher am cisco switch geblockt wurde, Zugriff aufs Internet. Ich will den Workstations aus VLAN200 (172.19.200.0/24) verbieten, dass sie direkt ins Internet dürfen. Aber ich möchte den Server aus VLAN100 (172.19.100.0/24) direkten Zugriff ins Internet erlauben (z.B. für Updates ziehen, oder sonstigen Zwecken, ohne zwangsweise einen Proxy nutzen zu müssen). Nun wirst du sagen, dass ich das ja direkt am cisco switch mit ACLs regeln kann, ist ja auch richtig, das weiß ich. Allerdings: wenn ich fein granulierte Regeln aufsetzen möchte die auf Protokolle, Ports, bestimmte Bereiche, oder Applikationslayer greifen sollen, dann wird's halt irgendwann mit Cisco ACLs (extended) ziemliches Gefrickel per Cisco ACLs. Ich finde auf der WebGUI von pfSense kann man so etwas viel komfortabler steuern. Vor allem hab ich bei pfSense auch einen super Überblick was gerade so geblockt wird, und kann direkt daraus auch weitere Regeln erstellen lassen. Das alles beim cisco switch regeln, wäre etwas blöd meiner Ansicht nach.
Aus diesem Grunde wollte ich solche Zugriffs-Steuerungen an der pfSense verwalten können.
Wenn ich aber nur eine einzige Transport-Leitung zwischen Cisco Switch <--und--> pfSense nutze, wie du vorgeschlagen hast, kann ich dann trotzdem noch auf der pfSense diese Regeln aufstellen und nutzen obwohl die pfSense die VLANs ja selbst gar nicht kennt? Würde es genügen wenn ich z.B. eine Regel erstelle:
Src= 172.19.100.0/24 Dst=any Protocol=any Action=Allow
(um die Server aus VLAN100 172.19.100.0/24 den Internetzugriff zu erlauben und durch den Wegfall weiterer Regeln ein impliziertes BLOCK ANY OTHER zu setzen) ?
Würde das funktionieren?
Falls ja, dann kann ich also all meine VLAN-interfaces von der pfSense wieder entfernen und nur das VLAN253 lassen als Transport zwischen cisco <--->pfSense, das habe ich ja schon bereits in Nutzung.
Aaaaber: mit dem DHCP-Server hätte ich noch Verständnisprobleme:
ich möchte eigentlich den DHCP-Server der pfSense verwenden, um verschiedene VLANs/Subnets damit zu bedienen. Momentan sind es folgende:
- VLAN15 (192.168.15.0/24) das sind WLAN-Gäste
- VLAN200 (172.19.200.0/24) das sind die Workstations
- VLAN123 (172.19.123.0/24) Testumgebung
Würde ich auf der pfSense nur eine einzige Schnittstelle verwenden wie oben beschrieben (VLAN253 als Transport zwischen Cisco-Switch und pfSense), dann kann ich den DHCP-Server doch nur auf diesem interface arbeiten lassen. Der DHCP-Server müsste also zwangsweise auf dem VLAN253-Interface arbeiten. Und da mein VLAN253-Interface so aussieht...
würde demnach ein aktiviert DHCP-Server auf diesem VLAN253 so aussehen...
Der DHCP-Server würde zwangsweise das subnet 172.19.253.0/24 bedienen wollen, das will ich aber gar nicht. Ich will ja 192.168.15.0/24 und 172.19.200.0/24 vom DHCP-Server bedienen lassen. Wie soll das dann funktionieren? Beim VLAN15 (192.168.15.0/24) könnte ich das noch problemlos hinkriegen, weil dieses VLAN15 kein interface auf meinem cisco-Switch hat, da es sich um WLAN-Gäste handelt und die nix auf meinem cisco switch (produktives Netz) zu suchen haben. Ich könnte also mein VLAN15 interface auf der pfSense belassen und somit den DHCP-Server auf dem vlan15-interface mit der IP 192.168.15.254/24 auf der pfSense arbeiten lassen. Aber das VLAN200 für die Workstations HAT ein interface auf dem cisco switch und zwar 172.19.200.253/24.
so dass vom cisco switch unbekannte Routenanfragen einfach an die pfSense weitergeleitet werden. Damit hätte aber jeder Host, der nicht explizit durch eine ACL vorher am cisco switch geblockt wurde,
Nein, das ist falsch !Du brauchst keine ACLs am Cisco wenn es dir nur um den Internet Zugang geht ! Diesen kannst du mit der FW Regel zentral an der pfSense regeln. Der tiefere Sinn einer Firewall
Hier machst du vermutlich einen Denkfehler bei den FW Regeln, oder ??
Nun wirst du sagen, dass ich das ja direkt am cisco switch mit ACLs regeln kann
Nein, genau nicht !Internet regelt man dann zentral an der FW für alle VLANs !
Aus diesem Grunde wollte ich solche Zugriffs-Steuerungen an der pfSense verwalten können.
Ist ja auch der richtige Weg...!Wenn ich aber nur eine einzige Transport-Leitung zwischen Cisco Switch <--und--> pfSense nutze, wie du vorgeschlagen hast, kann ich dann trotzdem noch auf der pfSense diese Regeln aufstellen und nutzen obwohl die pfSense die VLANs ja selbst gar nicht kennt?
Ja natürlich !Diese Pakete kommen doch alle an der pfSense mit den entsprechenden Absender IP Adressen so an der pfSense an !
Folglich kannst du sie also auch zentral mit einer Regel verwalten. Hier liegt vermutlich dein Denkfehler, da du denkst das der IP Header irgendwie irgendwo umgeschrieben wird und nur noch die IP des Transfernetzes dadrin steht, was natürlich Unsinn ist, denn dann würde die Routing Info ja verloren gehen !!
Würde das funktionieren?
Ja, genau so !Falls ja, dann kann ich also all meine VLAN-interfaces von der pfSense wieder entfernen und nur das VLAN253 lassen als Transport zwischen cisco <--->pfSense, das habe ich ja schon bereits in Nutzung.
Genau so ist es.... Ünrigens: Ein kurzer Wireshark oder ein TCPDUMP auf der pfSense hätte dir das im Handumdrehen gezeigt ich möchte eigentlich den DHCP-Server der pfSense verwenden,
Sagt dir das Thema ip helper address bei Cisco etwas:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configurat ...
Da müsste man jetzt nur mal klären ob die pfSense als zentraler DHCP Server agieren kann. Hab ich auch noch nicht probiert.
Falls alle Stricke reissen kann der Cisco DHCP Server für jedes VLAN spielen wenn du keinen zentralen einsetzen willst oder es mit der pfSense nicht klappt.
Nein, das ist falsch ! Du brauchst keine ACLs am Cisco wenn es dir nur um den Internet Zugang geht ! Diesen kannst du mit der FW Regel zentral an der pfSense regeln.
Ich meinte eigentlich damit:
der cisco switch hat von mir die route 0.0.0.0/0 via 172.19.253.254 verpasst bekommen. Wenn ein HostX im VLAN200 (z.B. 172.19.200.123/24) z.B. "ping 8.8.8.8" absetzt, dann wird seine Anfrage durch den cisco switch verarbeitet. Der cisco Switch sieht, dass dst ip=8.8.8.8 unbekannt ist, und leitet das weiter an die pfSense auf 172.19.253.254. Das gilt natürlich nur, wenn ich das nicht explizit am cisco switch schon vorher durch eine ACL geblockt hätte (was ich aber nicht hab).
Ich denke aber wir meinen dasselbe und ich hab das schon richtig verstanden. Die Firewall-Regeln-Geschichte ist mir klar. Auch "ip helper", also die DHCP-Weiterleitung ist mir klar. Was aber leider immer noch unklar ist ==> der letzte Abschnitt meines vorherigen Kommentars bezüglich DHCP-Server auf pfSense und Interface. Wie soll ich denn drei verschiedene Subnets mit pfSense's DHCP-Server bedienen, wenn es kein Interface für dieses Netz gibt?
Zitat von @panguu:
Wie soll ich denn drei verschiedene Subnets mit pfSense's DHCP-Server bedienen, wenn es kein Interface für dieses Netz gibt?
Wie soll ich denn drei verschiedene Subnets mit pfSense's DHCP-Server bedienen, wenn es kein Interface für dieses Netz gibt?
Hast Recht. Die pfSense hat da - wenn ich mich Recht entsinne - eine Designlimitierung. Die DHCP-Konfiguration ist interfacebezogen. Zwar kann man meiner Erinnerung nach durchaus mehrere Scopes pro Interface anlegen, diese müssen aber in der Range liegen, die sich aus der IP-Konfiguration des Interfaces ergibt.
Dann wird Dir wohl nichts anderes übrig bleiben, als den DHCP-Dienst auf einem der Server zu betreiben.
Gruß
sk
Hmmm...blöd 
ich wollte ja eigentlich weg von meinem bisherigen DHCP-Server und diesen auf der pfSense verwenden. Vor allem könnten den auch die Kollegen bedienen ohne Linux-Kenntnisse. Das ist nämlich bei meinem aktuellen ISC-DHCP-Server als Cluster nicht möglich, ich bin der einzige der den konfigurieren und anpassen kann für unsere Wünsche. Nunja, jetzt frag ich doch mal andersrum:
was würde denn dagegen sprechen, wenn ich alles so belasse wie es ist und auf dem cisco switch einfach nur PBR aktiviere und wie im Ursprungspost vorgeschlagen die policy-gesteuerten Route festlege, á-la:
Ich müsste wie gesagt lediglich das sdm template von "default" auf "routing" abändern, damit solche PBR Regeln genutzt werden könnten. Wie seht ihr das? Könnte ich das denn so lösen?
ich wollte ja eigentlich weg von meinem bisherigen DHCP-Server und diesen auf der pfSense verwenden. Vor allem könnten den auch die Kollegen bedienen ohne Linux-Kenntnisse. Das ist nämlich bei meinem aktuellen ISC-DHCP-Server als Cluster nicht möglich, ich bin der einzige der den konfigurieren und anpassen kann für unsere Wünsche. Nunja, jetzt frag ich doch mal andersrum:was würde denn dagegen sprechen, wenn ich alles so belasse wie es ist und auf dem cisco switch einfach nur PBR aktiviere und wie im Ursprungspost vorgeschlagen die policy-gesteuerten Route festlege, á-la:
- access list 1 permit 172.19.100.0 0.0.0.255
- route-map vlan100
- match ip address 1
- set ip next-hop 172.19.100.254
- int vlan 100
- ip policy route-map vlan100
Dasselbe dann fürs VLAN200 wäre dann...
- access list 2 permit 172.19.200.0 0.0.0.255
- route-map vlan200
- match ip address 2
- set ip next-hop 172.19.200.254
- int vlan 200
- ip policy route-map vlan200
Wenn nun ein Paket auf dem cisco-Switch eintrifft, dann wird anhand diesem PBR geprüft und gehandelt. Ein Paket aus der Quelle 172.19.100.0/24 würde somit > als nächsten Hop 172.19.100.254 tragen, und demnach den cisco-Switch zwangsweise über das VLAN100-interface mit der IP 172.19.100.253 verlassen.
- route-map vlan100
- match ip address 1
- set ip next-hop 172.19.100.254
- int vlan 100
- ip policy route-map vlan100
Dasselbe dann fürs VLAN200 wäre dann...
- access list 2 permit 172.19.200.0 0.0.0.255
- route-map vlan200
- match ip address 2
- set ip next-hop 172.19.200.254
- int vlan 200
- ip policy route-map vlan200
Wenn nun ein Paket auf dem cisco-Switch eintrifft, dann wird anhand diesem PBR geprüft und gehandelt. Ein Paket aus der Quelle 172.19.100.0/24 würde somit > als nächsten Hop 172.19.100.254 tragen, und demnach den cisco-Switch zwangsweise über das VLAN100-interface mit der IP 172.19.100.253 verlassen.
Ich müsste wie gesagt lediglich das sdm template von "default" auf "routing" abändern, damit solche PBR Regeln genutzt werden könnten. Wie seht ihr das? Könnte ich das denn so lösen?
der cisco switch hat von mir die route 0.0.0.0/0 via 172.19.253.254 verpasst bekommen. Wenn ein HostX im VLAN200 (z.B. 172.19.200.123/24) z.B. "ping 8.8.8.8" absetzt, dann wird seine Anfrage durch den cisco switch verarbeitet. Der cisco Switch sieht, dass dst ip=8.8.8.8 unbekannt ist, und leitet das weiter an die pfSense auf 172.19.253.254. Das gilt natürlich nur, wenn ich das nicht explizit am cisco switch schon vorher durch eine ACL geblockt hätte (was ich aber nicht hab).
Alles genau richtig, ändert aber nichts am Ergebnis das all diese Pakete dann an der pfSense in einem zentralen Regelset behandelt werden können wie oben schon beschrieben.OK, hast du ja auch selber schon erkannt
Was dein DHCP Problem anbetrifft solltest du besser den ISC Cluster weiter betreiben. Einen besseren und flexibleren DHCP Server kannst du nicht bekommen und es macht dann erheblich mehr Sinn sich mal einen Kollegen zu schnappen und ihm das kurz beizubringen wie der zu customizen ist. Dann seit ihr wenigstens zu zweit und könnt euch vertreten.
Letztendlich fährst du mit dem Konzept besser. Du solltest niemals schlecht geschulte Mitarbeiter als Grund nehmen ein an sich gutes Konzept aufzuweichen !
Ich werde das in Erwägung ziehen, aber dennoch würde mich interessieren WAS gegen der vorgeschlagenen PBR-Möglichkeit spricht, bzw. warum ich das NICHT machen sollte. Einfach auch deshalb, um dazuzulernen.
Da spricht natürlich nichts dagegen. Dir stehen ja beide Konfig Optionen offen
Ich hab das nun anderweitig gelöst und zwar musste ich bei diesem Weg den cisco switch nicht sohin abändern, dass das sdm template auf "routing" gesetzt werden müsste. Der cisco switch blieb soweit unangetastet, ich hab lediglich auf eure Empfehlung hin die interface VLAN253 IP von 172.19.253.253/24 auf 172.19.253.253/30 abgeändert. Dann auf der pfSense hab ich entsprechend im VLAN253 interface ebenfalls die IP abgeändert von 172.19.253.254/24 auf 172.19.253.254/30. Das ist also mein Transfernetz welches über VLAN253 läuft und im Subnet 172.19.253.253/30 arbeitet welches genau 2 Hosts zulässt (.253 und .254).
Dann hab ich auf der pfSense überflüssige VLAN-interfaces und dessen IP-Adressen rausgehauen und nur diejenigen belassen für die ich DHCP-Serverdienste anbieten möchte. In meinem Fall wären das fürs VLAN200 (=workstations&printer), VLAN15 (=WLAN-Gäste) und VLAN123 (=Testumgebung).
Dann hab ich in der pfSense unter System==>Routing==>Gateway folgenden Eintrag hinzugefügt:
Name: Transport2Cisco
Interface: em0_VLAN253
Gateway: 172.19.253.253
und im nächsten Reiter namens [Routes] hab ich dann einfach eine große Route für meine Subnets hinzugefügt, so dass all meine Subnetze quasi greifen. Dadurch wird die pfSense forciert, das TransportNetz, also cisco-Gateway auf 172.19.253.253 zu nutzen, also auch für diejenigen Netze, die normalerweise ein eigeen VLAN-Interface auf der pfSense besitzen (z.B. 123 und 200):
Network: 172.19.0.0/16, Gateway: Transport2Cisco 172.19.253.253
Soweit geht das auch alles. Spricht irgendwas dagegen was ich jetzt wieder übersehe?
Dann hab ich auf der pfSense überflüssige VLAN-interfaces und dessen IP-Adressen rausgehauen und nur diejenigen belassen für die ich DHCP-Serverdienste anbieten möchte. In meinem Fall wären das fürs VLAN200 (=workstations&printer), VLAN15 (=WLAN-Gäste) und VLAN123 (=Testumgebung).
Dann hab ich in der pfSense unter System==>Routing==>Gateway folgenden Eintrag hinzugefügt:
Name: Transport2Cisco
Interface: em0_VLAN253
Gateway: 172.19.253.253
und im nächsten Reiter namens [Routes] hab ich dann einfach eine große Route für meine Subnets hinzugefügt, so dass all meine Subnetze quasi greifen. Dadurch wird die pfSense forciert, das TransportNetz, also cisco-Gateway auf 172.19.253.253 zu nutzen, also auch für diejenigen Netze, die normalerweise ein eigeen VLAN-Interface auf der pfSense besitzen (z.B. 123 und 200):
Network: 172.19.0.0/16, Gateway: Transport2Cisco 172.19.253.253
Soweit geht das auch alles. Spricht irgendwas dagegen was ich jetzt wieder übersehe?
Nein, nichts übersehen, hört sich alles gut und richtig an !
