40
Firewall Migration - Hilfe zum Thema Routing
Hallo zusammen,
ich bin dabei unsere alte Firewall (Firewall-01) zu einer neuen (Firewall-02) zu migrieren. Da hier einiges einzurichten bzw. zu übernehmen ist, mache ich das Schritt für Schritt und möchte mit den Site-to-Site VPN Tunneln zu den anderen Standorten z.b. mit Firewall-03 anfangen.
Ich möchte erreichen, dass das
Default-VLAN 192.168.100.0 sowie
VLAN 40 192.168.40.0
vom entfernten Standort aus erreichbar ist. Wahrscheinlich ganz banal, aber ich habe gerade einen knoten im Hirn. 😅
In der "alten" Welt funktioniert alles so wie es soll.
Netzwerk Hauptstandort:
- Aruba-Switch mit Default-VLAN und VLAN 40. Das Default-Gateway des Switch ist die alte Firewall-01.
- alte Firewall-01 ist weiterhin als Gateway (Internet-Proxy, VPNs usw.) parallel aktiv und auf den Client-PCs eingetragen.
- auf den Client-PCs welche das VLAN 40 erreichen müssen ist eine statische Route eingetragen.
- es soll nämlich direkt über den Switch geroutet werden und nicht über die Firewall-01 (wg. Durchsatz)
Ziel:
- Wie erreiche ich es, dass vom entfernten Netz 192.168.13.0, das Default-VLAN und VLAN 40 erreichbar sind?
- Firewallregeln lassen aktuell noch alles durch, somit wird kein ping oder traceroute behindert.
Was nicht funktioniert:
- ich habe auf der neuen Firewall-02 eine statische Route in das VLAN 40 192.168.40.0 gesetzt.
- somit kann Firewall-02 das VLAN 40 erreichen.
- allerdings ist das VLAN 40 nicht aus dem VPN erreichbar, weil die Rückroute fehlt
- diese kann ich meiner Meinung nach nicht setzen, da sich das Gateway dafür ja in einem anderen Subnetz ist (192.168.100.250)
- wenn ich tracert ausführe wird (weil das Netz unbekannt ist) zur Firewall-01 weitergeleitet. Meine Route zu 192.168.100.250 wird ignoriert.
- es müsste sich ja stattdessen ein Gateway im gleiche Subnetzbereich 192.168.40.x befinden. Was mich zur Variante 2 führt:
Variante 2: VLAN taggen
- die og. Route habe ich wieder entfernt
- ich habe das VLAN 40 am entsprechenden Interace getaggt und auf der Firewall-02 mit der IP 192.168.40.252 angelegt um das VLAN 40 der Firewall-02 bekannt zu machen.
- dann kann ich auf den Geräten im VLAN 40 eine statische Rückroute eintragen:
- Somit klappt der ping. Ist das aber so richtig? Woher weiß ich, dass die Pakete immer diesen Weg in jede Richtung nutzen?
Im traceroute von einem Client im VPN bekomme ich nämlich folgenden Zeitüberschreitung, ich weiß nicht woher diese kommt:
Variante 3: SNAT
- ich habe auf der neuen Firewall-02 eine SNAT Regel angelegt, die das ankommende entfernte Netz 192.168.13.0 auf die IP der Firewall-02 192.168.100.250 maskiert
- somit ist auf den Client-PCs keine Rückroute mehr erforderlich.
- allerdings bekomme ich immernoch bei der Routenverfolgung eine Zeitüberschreitung:
Was ist denn der Beste/richtige weg die Netze bekannt zu machen?
Vielen Dank.
ich bin dabei unsere alte Firewall (Firewall-01) zu einer neuen (Firewall-02) zu migrieren. Da hier einiges einzurichten bzw. zu übernehmen ist, mache ich das Schritt für Schritt und möchte mit den Site-to-Site VPN Tunneln zu den anderen Standorten z.b. mit Firewall-03 anfangen.
Ich möchte erreichen, dass das
Default-VLAN 192.168.100.0 sowie
VLAN 40 192.168.40.0
vom entfernten Standort aus erreichbar ist. Wahrscheinlich ganz banal, aber ich habe gerade einen knoten im Hirn. 😅
In der "alten" Welt funktioniert alles so wie es soll.
Netzwerk Hauptstandort:
- Aruba-Switch mit Default-VLAN und VLAN 40. Das Default-Gateway des Switch ist die alte Firewall-01.
- alte Firewall-01 ist weiterhin als Gateway (Internet-Proxy, VPNs usw.) parallel aktiv und auf den Client-PCs eingetragen.
- auf den Client-PCs welche das VLAN 40 erreichen müssen ist eine statische Route eingetragen.
- es soll nämlich direkt über den Switch geroutet werden und nicht über die Firewall-01 (wg. Durchsatz)
192.168.40.0 MASK 255.255.255.0 192.168.100.254Ziel:
- Wie erreiche ich es, dass vom entfernten Netz 192.168.13.0, das Default-VLAN und VLAN 40 erreichbar sind?
- Firewallregeln lassen aktuell noch alles durch, somit wird kein ping oder traceroute behindert.
Was nicht funktioniert:
- ich habe auf der neuen Firewall-02 eine statische Route in das VLAN 40 192.168.40.0 gesetzt.
- somit kann Firewall-02 das VLAN 40 erreichen.
- allerdings ist das VLAN 40 nicht aus dem VPN erreichbar, weil die Rückroute fehlt
- diese kann ich meiner Meinung nach nicht setzen, da sich das Gateway dafür ja in einem anderen Subnetz ist (192.168.100.250)
- wenn ich tracert ausführe wird (weil das Netz unbekannt ist) zur Firewall-01 weitergeleitet. Meine Route zu 192.168.100.250 wird ignoriert.
1 <1 ms <1 ms <1 ms 192.168.40.254
2 <1 ms <1 ms <1 ms 192.168.100.30
3 * * * Zeitüberschreitung der Anforderung.- es müsste sich ja stattdessen ein Gateway im gleiche Subnetzbereich 192.168.40.x befinden. Was mich zur Variante 2 führt:
Variante 2: VLAN taggen
- die og. Route habe ich wieder entfernt
- ich habe das VLAN 40 am entsprechenden Interace getaggt und auf der Firewall-02 mit der IP 192.168.40.252 angelegt um das VLAN 40 der Firewall-02 bekannt zu machen.
- dann kann ich auf den Geräten im VLAN 40 eine statische Rückroute eintragen:
192.168.13.0 MASK 255.255.255.0 192.168.40.252Im traceroute von einem Client im VPN bekomme ich nämlich folgenden Zeitüberschreitung, ich weiß nicht woher diese kommt:
Routenverfolgung zu 192.168.40.11 über maximal 30 Hops
1 <1 ms <1 ms <1 ms 192.168.13.250
2 * * * Zeitüberschreitung der Anforderung.
3 1 ms 1 ms <1 ms 192.168.40.11Variante 3: SNAT
- ich habe auf der neuen Firewall-02 eine SNAT Regel angelegt, die das ankommende entfernte Netz 192.168.13.0 auf die IP der Firewall-02 192.168.100.250 maskiert
- somit ist auf den Client-PCs keine Rückroute mehr erforderlich.
- allerdings bekomme ich immernoch bei der Routenverfolgung eine Zeitüberschreitung:
Routenverfolgung zu 192.168.40.11 über maximal 30 Hops
1 <1 ms <1 ms <1 ms 192.168.13.250
2 * * * Zeitüberschreitung der Anforderung.
3 1 ms 1 ms <1 ms 192.168.40.11Was ist denn der Beste/richtige weg die Netze bekannt zu machen?
Vielen Dank.
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: 671470
Url: https://administrator.de/forum/firewall-migration-hilfe-zum-thema-routing-671470.html
Ausgedruckt am: 01.04.2025 um 16:04 Uhr
40 Kommentare
Neuester Kommentar
Ja, das ist ganz banal aber um dir hier jetzt nicht alle 4 möglichen Lösung en Detail präsentieren zu müssen weil man dein Protokoll kristallkugeln muss wäre es sehr hilfreich wenn du uns aufklären könntest WELCHES der zahllosen VPN Protokolle du denn verwendest für die Site-2-Site Kopplung?? 🤔
Hilfreich wäre auch zu wissen WER der VPN Responder und wer der Initiator ist?
Wenn es die übliche IPsec IKEv2 Konfig ist musst du nichts weiter tun als eine zusätzliche 2te Phase 2 einrichten. Also eine Phase 2 für das .100.0er Netz und eine weitere für das .40.0er Netz.
Fertisch... Guckst du auch hier und bei 2 SAs hier
Die lokalen Netze kennt die Firewall ja so oder so alle da sie direkt dran sind und die remoten VPN Netze lernt sie automatisch mit den Phase 2 SAs der VPN Konfig.
NAT innerhalb von VPN Tunneln sollte man niemals machen wenn man transparent routen will oder muss. Aktives NAT bedeutet immer eine routingtechnische Einbahnstrasse und ist wenig zielführend.
Hilfreich wäre auch zu wissen WER der VPN Responder und wer der Initiator ist?
Wenn es die übliche IPsec IKEv2 Konfig ist musst du nichts weiter tun als eine zusätzliche 2te Phase 2 einrichten. Also eine Phase 2 für das .100.0er Netz und eine weitere für das .40.0er Netz.
Fertisch... Guckst du auch hier und bei 2 SAs hier
Was ist denn der Beste/richtige weg die Netze bekannt zu machen?
Du musst da nichts bekannt machen!Die lokalen Netze kennt die Firewall ja so oder so alle da sie direkt dran sind und die remoten VPN Netze lernt sie automatisch mit den Phase 2 SAs der VPN Konfig.
NAT innerhalb von VPN Tunneln sollte man niemals machen wenn man transparent routen will oder muss. Aktives NAT bedeutet immer eine routingtechnische Einbahnstrasse und ist wenig zielführend.
Ja ist ein IPsec VPN, die Netze sind auf beiden Seiten eingerichtet.
Firewall-02 ist Responder.
entfernte Firewall-03 Initiator.
Genauso wie es bei der "alten" Firewall-01 auch war. Da geht alles.
Da aber die Clients im 40er Netz nicht die Firewall-02 als Standardgateway haben, fehlt ja diesen der Rückweg denke ich.
Firewall-02 ist Responder.
entfernte Firewall-03 Initiator.
Genauso wie es bei der "alten" Firewall-01 auch war. Da geht alles.
Da aber die Clients im 40er Netz nicht die Firewall-02 als Standardgateway haben, fehlt ja diesen der Rückweg denke ich.
Da aber die Clients im 40er Netz nicht die Firewall-02 als Standardgateway haben, fehlt ja diesen der Rückweg denke ich.
Ahhhsooo... Ja, sorry, da musst du natürlich dann auf dem Default Gateway was die Clients im 40er Netz haben eine statische Route für diese remoten Netze mit der Firewall-02 als Gateway IP.Woher soll deren Standard Gateway sonst wissen wie diese Netze zu erreichen sind! Worst Case verwendet es sein Default Gateway und damit landet der Rücktraffic, wie du schon richtig vemutest, im IP Nirwana.
Guten Morgen, @aqui
Genau das war mein knoten im Hirn 😅
Also muss ich die Route auf dem Aruba-Switch eintragen, weil das das Default-Gateway der Clients im 40er Netz ist.
Zumindestens während der Migrationszeit, solange die neue Firewall-02 noch nicht (überall) Standardgateway ist.
Danke für den Tipp zum NAT. Ich schalte die SNAT-Regel wieder ab!
Die Default-Route am Switch setzen wäre eine der Lösungen? Was gibt es noch?
da musst du natürlich dann auf dem Default Gateway was die Clients im 40er Netz haben eine statische Route für diese remoten Netze mit der Firewall-02 als Gateway IP.
Genau das war mein knoten im Hirn 😅
Also muss ich die Route auf dem Aruba-Switch eintragen, weil das das Default-Gateway der Clients im 40er Netz ist.
Zumindestens während der Migrationszeit, solange die neue Firewall-02 noch nicht (überall) Standardgateway ist.
Danke für den Tipp zum NAT. Ich schalte die SNAT-Regel wieder ab!
Ja, das ist ganz banal aber um dir hier jetzt nicht alle 4 möglichen Lösung en Detail präsentieren zu müssen
Die Default-Route am Switch setzen wäre eine der Lösungen? Was gibt es noch?
Also muss ich die Route auf dem Aruba-Switch eintragen
Jepp, ganz genau wenn der Switch das Default Gateway der Clients ist.Was gibt es noch?
Du könntest dynamisches Routing (RIPv2, OSPF etc.) auf Switch und Firewalls aktivieren, dann benötigst du keinerlei Frickelei mehr mit statischen Routen.
Hab Dank!
Was ist nun eigentlich "nicht richtig" wenn ich das 40er Netz der neuen Firewall-02 bekannt mache?
Also ich meine die neue Firewall-02 mit einem "Bein" ins 40er Netz stelle?
- ich habe das VLAN 40 am entsprechenden Interace getaggt und auf der neuen Firewall-02 ein VLAN Interface mit der IP 192.168.40.252 angelegt, um das VLAN 40 der Firewall-02 bekannt zu machen.
- dann kann ich auf den Geräten im VLAN 40 eine statische Rückroute eintragen, da diese somit einen Weg zur Firewall-02 haben:
- Nachteil ist hier aber dass es auch noch das Default-Gateway im 40er Netz 192.168.40.254 gibt.
Was ist nun eigentlich "nicht richtig" wenn ich das 40er Netz der neuen Firewall-02 bekannt mache?
Also ich meine die neue Firewall-02 mit einem "Bein" ins 40er Netz stelle?
- ich habe das VLAN 40 am entsprechenden Interace getaggt und auf der neuen Firewall-02 ein VLAN Interface mit der IP 192.168.40.252 angelegt, um das VLAN 40 der Firewall-02 bekannt zu machen.
- dann kann ich auf den Geräten im VLAN 40 eine statische Rückroute eintragen, da diese somit einen Weg zur Firewall-02 haben:
192.168.13.0 MASK 255.255.255.0 192.168.40.252- Nachteil ist hier aber dass es auch noch das Default-Gateway im 40er Netz 192.168.40.254 gibt.
Was ist nun eigentlich "nicht richtig" wenn ich das 40er Netz der neuen Firewall-02 bekannt mache?
Die Frage ist etwas unverständlich. Du hast doch alles richtig gemacht?! 2te P2 mit dem 40er installiert, also alles richtig gemacht!Wenn die Firewall ein Bein im 40er Netz hat, dann kennt sie das auch. Alle Endgeräte im 40er Netz, auch wenn die ein anderes Gateway haben, können dann so oder so auf sie zugreifen über ihre 40er IP, weil ja eigenes Netz. Da brauchts dann logischerweise kein Routing.
dann kann ich auf den Geräten im VLAN 40 eine statische Rückroute eintragen
Das wäre routingtechnisch der komplett falsche Weg, denn routen sollen in einem IP Netz niemals die einzelnen Endgeräte selber sondern immer die Router! Dafür sind sie ja da...Wenn die Clients im .40er Netz also als Default Gateway den L3 Switch haben (mal geraten mit der .40.254) und das .13.0er Netz ist per VPN über die neue Firewall-02 erreichbar kommt diese IP Route natürlich auf den L3 Switch und NICHT auf ein Endgerät.
ip route 192.168.13.0 255.255.255.0 192.168.40.252
Wenn ein Client jetzt eine Session auf ein Endgerät im remoten 13er Netz machen will "merkt" er das das ja nicht sein lokales Netz ist und ARPt nach seinem Default Gateway also dem L3 Switch und schickt ihm den Request fürs 13er Netz.
Der sieht in seine Routing Tabelle, sieht die o.a. Router und forwardet den Request an die FW-02 und die weiss dann wie sie das 13er netz erreicht.
Einfache IP Routing Logik. (Siehe dazu auch hier)
dass es auch noch das Default-Gateway im 40er Netz 192.168.40.254 gibt.
Was ist damit gemeint?? Gateway der Endgeräte?Die Frage ist etwas unverständlich. Du hast doch alles richtig gemacht?!
Ich frage deswegen, weil ich bei einem tracert eine Zeitüberschreitung erhalte. Ich kann mir noch nicht erklären welches Gerät da angesprochen wird und schließlich die verbindung dennoch klappt. Daher meine Vermutung, dass ich noch einen Fehler mache:
Routenverfolgung zu 192.168.40.11 über maximal 30 Hops
1 <1 ms <1 ms <1 ms 192.168.13.250
2 * * * Zeitüberschreitung der Anforderung.
3 1 ms 1 ms <1 ms 192.168.40.11Ich habe die statische Route auf den Clients im 40er Netz nur manuell eingetragen, weil nur eine handvoll Geräte aus dem 40er Netz über das VPN 192.168.13.0 erreichbar sein sollen.
Was ist damit gemeint?? Gateway der Endgeräte?
Das 40er Netz hat als Default-Gateway den Switch mit 192.168.40.254.
Der Switch hat wiederum als Default-Gateway die alte Firewall-01. Alles soweit richtig.
Nur eine überschaubare Anzahl an Geräten im 40er Netz haben eine manuelle route auf das Bein / VLAN Interface auf der Firewall-02 mit der IP 192.168.40.252.
Also am Schluss verstehe ich es so, dass meine Variante nicht "falsch" ist. Aber besser ist es die Route am L3 Switch einzutragen.
Bleibt nur noch zu klären woher die Zeitüberschreitung stammt. 🤔
Guten Morgen,
das routing funktioniert wie erwartet, nachdem ich die Route auf dem L3 Switch gesetzt habe:
Allerdings bekomme ich aus dem entfernten Netz immernoch den Timeout.
Wie bekomme ich raus, welcher Hop das ist?
das routing funktioniert wie erwartet, nachdem ich die Route auf dem L3 Switch gesetzt habe:
tracert 192.168.13.250Routenverfolgung zu 192.168.13.250 über maximal 30 Hops
1 * <1 ms * 192.168.40.254
2 <1 ms <1 ms <1 ms 192.168.40.252
3 <1 ms <1 ms <1 ms 192.168.13.250Allerdings bekomme ich aus dem entfernten Netz immernoch den Timeout.
Wie bekomme ich raus, welcher Hop das ist?
tracert 192.168.40.11Routenverfolgung zu 192.168.40.11 über maximal 30 Hops
1 <1 ms <1 ms <1 ms 192.168.13.250
2 * * * Zeitüberschreitung der Anforderung.
3 1 ms 1 ms <1 ms 192.168.40.11das routing funktioniert wie erwartet
Glückwunsch! 👏weil ich bei einem tracert eine Zeitüberschreitung erhalte.
Das liegt vermutlich daran das du Traceroute mit DNS Namensauflösung gestartet hast!Üblicherweise nehmen viele Provider ihre Infrastruktur Adressen aus guten Gründen nicht ins DNS auf.
Besser also tracert -d 192.168.40.11. Oder...einen nicht ICMP basierten Traceroute verwenden denn viele Blocken auch ICMP Echo und Echo Reply auf ihren Infrastruktur Adressen. All das führt zu Timeouts auf dem Pfad.
Aber besser ist es die Route am L3 Switch einzutragen.
Jepp, genau richtig! Kein Routing auf einzelnen Endgeräten!Wenn man es wider Erwarten dennoch partout will ist es immer besser diese Route dann via DHCP Server über die Option 121 an die Clients zu verteilen um die nicht alle einzeln anfassen zu müssen.
Wie gesagt: Keine gute Idee! Routing gehört wie der Namen schon sagt auf Router oder Firewalls als zentrale L3 Instanz.
Danke! Das tracert -d brachte aber keinen Erfolg.
Der traceroute direkt auf der entfernten Firewall-03 zeigt garkeine Routenverfolgung an, zum Host 192.168.40.11. Sollte da nicht auch was zu sehen sein?
Der traceroute direkt auf der entfernten Firewall-03 zeigt garkeine Routenverfolgung an, zum Host 192.168.40.11. Sollte da nicht auch was zu sehen sein?
Das liegt abgesehen vom DNS, meist daran das die ICMP Echo und Time exceeded Typen blockiert sind. Dann scheitern ICMP basierte Traceroutes.
Früher gab es mal pathping bei Winblows. K.A. ob es das bei Win 10 und 11 noch gibt. Wenn es allerdings auch ICMP nutzt bringt es nix.
Wenn du einen unixoiden Rechner zur Hand hast nutze das dortige Traceroute mit dem "-T" Schalter was dann auf TCP SYN Basis rennt. Z.B. traceroute -T -n 192.168.40.11
Früher gab es mal pathping bei Winblows. K.A. ob es das bei Win 10 und 11 noch gibt. Wenn es allerdings auch ICMP nutzt bringt es nix.
Wenn du einen unixoiden Rechner zur Hand hast nutze das dortige Traceroute mit dem "-T" Schalter was dann auf TCP SYN Basis rennt. Z.B. traceroute -T -n 192.168.40.11
Hi, ja hab ein Linux.
als erstmal traceroute -T -n 192.168.40.11 funktioniert:
traceroute ohne Parameter läuft ins leere:
Und ganz merkwürdig ein ping funktioniert nicht, immer einmal bei jedem mal wenn ich den ping starte:
Wireshark auf 192.168.40.11
als erstmal traceroute -T -n 192.168.40.11 funktioniert:
traceroute ohne Parameter läuft ins leere:
Und ganz merkwürdig ein ping funktioniert nicht, immer einmal bei jedem mal wenn ich den ping starte:
Wireshark auf 192.168.40.11
traceroute ohne Parameter läuft ins leere:
Zeigt das ICMP irgendwo blockiert wird und erwartungsgemäß TCP nicht.immer einmal bei jedem mal wenn ich den ping starte:
Das kann normal seon bei langsamen Rechnern wenn die noch ARPen müssen vorab. Der ARP Cache hält aber ein paar Minuten so das es danach auf Schlag klappen sollte.Das "DUP! besagt das es irgendwo Probleme gibt denn der ICMP Frame mit der Sequence Number "3" ist doppelt am Empfänger angekommen was eigentlich niemals der Fall sein sollte. 🤔
Der Wireshark Trace zeigt eigentlich auch bilderbuchmässig wechselnde Requests und Replys wie es sein soll...
Der Redirect ist normal weil 2 Gateways im 40er Netz sind.
Genaugenommen geht die Routing Logik von oben so:
- 40er Client öffnet eine Session auf ein Endgerät im remoten 13er Netz
- Er "merkt" das das nicht sein lokales 40er Netz ist und ARPt nach seinem Default Gateway also dem L3 Switch und schickt ihm den Request fürs 13er Netz.
- Der sieht in seine Routing Tabelle, sieht die o.a. Route via FW-02 und "merkt" das das Next Hop Gateway im gleichen Netz wie der Client liegt und sendet diesem ein ICMP Redirect mit der lokalen 40er Gateway IP für das Gateway zum 13er Netz
- Der Client ARPt dann die diese IP aus dem Redirect (FW-02) und forwardet den Request und allen Folgetraffic dann direkt an die FW-02 und die weiss dann wie sie das 13er Netz erreicht.
Works as designed...
⚠️ Aufgepasst bei Winblows. ICMP Redirect ist generell erlaubt. Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirect 1=> enable und 0=> disable. Das sollte im Default auf 1 stehen.
Einen Strich durch die Rechnung macht oftmals die Winblows Firewall ("Firewall mit erweiterter Sicherheit"). Dort fehlt häufig eine entsprechende ICMP Regel fürs eingehende ICMP Redirect.
Fehlt die, führt trotz Aktivierung im OS Windows den Redirect nicht aus und sämtlicher Traffic durchläuft dann 2mal den L3 Switch als "Durchlauferhitzer" und belastet unnötigerweise das Netz!
Fatal bei zeitkritischen oder performancehungrigen Anwendungen. Da lohnt also immer die Kontrolle ob das sauber funktioniert!
Alles klar!
ICMP Redirect ist an
Die WF ist aus
Habe den Tunnel testweise nochmal "zurückgebaut" auf die "alte" Firewall-01.
Die Zeitüberschreitung kommt nicht, wenn ich den tracert wieder ausführe.
Die FW01 ist überall als Standardgateway. Auf allen Clients und auf dem Switch.
Da ist alles sauber. Ich vermute hier könnte der Zusammenhang sein 🤔
Komisch!
ICMP Redirect ist an
Die WF ist aus
Einen Strich durch die Rechnung macht oftmals die Winblows Firewall ("Firewall mit erweiterter Sicherheit"). Dort fehlt häufig eine entsprechende ICMP Regel fürs eingehende ICMP Redirect.
Fehlt die, führt trotz Aktivierung im OS Windows den Redirect nicht aus und sämtlicher Traffic durchläuft dann 2mal den L3 Switch als "Durchlauferhitzer" und belastet unnötigerweise das Netz! face-sad
Fehlt die, führt trotz Aktivierung im OS Windows den Redirect nicht aus und sämtlicher Traffic durchläuft dann 2mal den L3 Switch als "Durchlauferhitzer" und belastet unnötigerweise das Netz! face-sad
Habe den Tunnel testweise nochmal "zurückgebaut" auf die "alte" Firewall-01.
Die Zeitüberschreitung kommt nicht, wenn ich den tracert wieder ausführe.
Die FW01 ist überall als Standardgateway. Auf allen Clients und auf dem Switch.
Da ist alles sauber. Ich vermute hier könnte der Zusammenhang sein 🤔
Das "DUP! besagt das es irgendwo Probleme gibt denn der ICMP Frame mit der Sequence Number "3" ist doppelt am Empfänger angekommen was eigentlich niemals der Fall sein sollte. 🤔
Komisch!
Die FW01 ist überall als Standardgateway.
Oben sagtest du aber das der L3 Switch überall Gateway ist was in einem L3 Switchkonzept ja der übliche Standard ist.Was etwas unverständlich an deinem Setup ist ist die Frage WARUM du überhaupt die FW-02 direkt in das 40er VLAN hängst?? Dazu besteht doch für ein Testsetup eigentlich keinerlei Veranlassung.
Es reicht doch wenn die einzig und allein im 100er Netz ist mit separater IP .100.250.
Um Traffic für das remote 13er Netz dann testweise über die neue FW zu leiten reicht es doch einfach eine statische Route auf dem L3 Core Switch von
ip route 192.168.13.0/24 gateway:192.168.100.250
hinzuzufügen!
Das Default Gateway dort auf die .100.30 bleibt bestehen.
Das bewirkt dann das der L3 Core Switch alles was ans 13er Netz geht jetzt über die FW-02 sendet.
Das ist doch viel einfacher und erspart dir die unnötige Frickelei die 02er ins 40er Netz zu hieven.
Wenn du willst das alles wieder über die 01 geht dann löschst oder deaktvierst du diese Route wieder auf dem l3 Core.
Hi,
Nein das hatte ich nicht geschrieben, sondern:
Das 100er Netz ist das Default-VLAN und hat nur aus dem Grund die FW01 (192.168.100.30) als Default-Gateway, weil das 100er Netz nicht so einfach die anderen VLAN ereichen soll.
Das 100er Netz soll keinen Zugriff in andere VLANs haben.
Die Firewall-01 ist für alle Clients und für den Switch das Default Gateway.
Es ist ja eigentlich auch kein Testsetup, sondern ich ziehe ja alles nach und nach von der FW01 zur FW02 rüber.
Also brauche ich doch kein "Bein" von der FW02 ins 40er Netz.
Danke, das probiere ich aus!
Nein das hatte ich nicht geschrieben, sondern:
- alte Firewall-01 ist weiterhin als Gateway (Internet-Proxy, VPNs usw.) parallel aktiv und auf den Client-PCs eingetragen.
Das 100er Netz ist das Default-VLAN und hat nur aus dem Grund die FW01 (192.168.100.30) als Default-Gateway, weil das 100er Netz nicht so einfach die anderen VLAN ereichen soll.
Das 100er Netz soll keinen Zugriff in andere VLANs haben.
Die Firewall-01 ist für alle Clients und für den Switch das Default Gateway.
Es ist ja eigentlich auch kein Testsetup, sondern ich ziehe ja alles nach und nach von der FW01 zur FW02 rüber.
Das ist doch viel einfacher und erspart dir die unnötige Frickelei die 02er ins 40er Netz zu hieven.
Also brauche ich doch kein "Bein" von der FW02 ins 40er Netz.
Danke, das probiere ich aus!
Guten Morgen @aqui,
also die route auf dem L3 Core Switch:
funktioniert ebenfalls.
Das VLAN 40 habe ich auf der FW02 wieder deaktiviert.
Aber ich benötige ja dennoch auf der FW02 (192.168.100.250) einen Weg in das VLAN 40er Netz. Sonst kennt diese das VLAN 40 ja nicht.
Dazu habe ich eine statische Route auf der FW02 ins 40er Netz gemacht. So war und ist es auch auf der alten FW01.
Ohje, ich hoffe nicht, dass ich etwas falsch beschrieben habe. Ich passe die Grafik mal ähnlich deiner aus L3 Switchkonzept an. Nicht, dass wir die ganze Zeit aneinander vorbei reden. 🙈
Mein Aufbau sieht nämlich schon etwas anders aus. Ich habe kein reines Koppel-VLAN um das Internet anzubinden wie dort beschrieben. Sondern die FW ist im Hauptnetzwerk (default VLAN). So ist ja in der Regel auch der klassische Aufbau in z.b. Heimnetzwerken.
Der Grund des Aufbaus ist, dass Clients aus dem 100er nicht ohne weiteres Zugriff auf die anderen VLANs erhalten.
Hätte das 100er Netz den L3 Switch als Gateway, könnten alle Clients in den beiden VLANs untereinander kommunizerieren.
Dann müsste ich um das einzuschränken mit ACLs auf dem L3 Switch arbeiten, was die Administration komplexer macht.
Jetzt könnte man meinen, dass man ja auch alles über die Firewall-01 routen könnte. Das schafft diese aber Hardwaretechnisch nicht. Gerade Backups der Server usw. erzeugen zuviel Datentraffic um diese darüber zu schleifen.
also die route auf dem L3 Core Switch:
ip route 192.168.13.0/24 gateway:192.168.100.250Das VLAN 40 habe ich auf der FW02 wieder deaktiviert.
Aber ich benötige ja dennoch auf der FW02 (192.168.100.250) einen Weg in das VLAN 40er Netz. Sonst kennt diese das VLAN 40 ja nicht.
Dazu habe ich eine statische Route auf der FW02 ins 40er Netz gemacht. So war und ist es auch auf der alten FW01.
Ohje, ich hoffe nicht, dass ich etwas falsch beschrieben habe. Ich passe die Grafik mal ähnlich deiner aus L3 Switchkonzept an. Nicht, dass wir die ganze Zeit aneinander vorbei reden. 🙈
Mein Aufbau sieht nämlich schon etwas anders aus. Ich habe kein reines Koppel-VLAN um das Internet anzubinden wie dort beschrieben. Sondern die FW ist im Hauptnetzwerk (default VLAN). So ist ja in der Regel auch der klassische Aufbau in z.b. Heimnetzwerken.
Der Grund des Aufbaus ist, dass Clients aus dem 100er nicht ohne weiteres Zugriff auf die anderen VLANs erhalten.
Hätte das 100er Netz den L3 Switch als Gateway, könnten alle Clients in den beiden VLANs untereinander kommunizerieren.
Dann müsste ich um das einzuschränken mit ACLs auf dem L3 Switch arbeiten, was die Administration komplexer macht.
Jetzt könnte man meinen, dass man ja auch alles über die Firewall-01 routen könnte. Das schafft diese aber Hardwaretechnisch nicht. Gerade Backups der Server usw. erzeugen zuviel Datentraffic um diese darüber zu schleifen.
Aber ich benötige ja dennoch auf der FW02 (192.168.100.250) einen Weg in das VLAN 40er Netz. Sonst kennt diese das VLAN 40 ja nicht.
Das ist richtig!Dort trägst du unter Routing ein:
Zielnetz: 192.168.40.0/24 Gateway: <IP_adresse_switch_100er_netz>
So war und ist es auch auf der alten FW01.
Bingo! Muss ja da identisch sein. Ich habe kein reines Koppel-VLAN um das Internet anzubinden wie dort beschrieben.
Ja, klar, das entfällt ja auch weil du sehr wahscheinlich deine Firewall direkt am Internet hast und keine Router Kaskade betreibst mit einem NAT Router davor, richtig?Deine Zeichnung ist so auch absolut korrekt!
Prima! ☺️
Nein, keine Kaskade. Die Firewall hängt direkt am Internet.
Einen Anwendungsfall habe ich noch und noch nicht darüber gesprochen!
Es gibt den Anwendungsfall, dass das entfernte Netz 192.168.13.0 sowie RoadWarrior VPN Clients, die über dieses Netz mit der IP 10.200.10.0/24 (OpenVPN) ankommen in das 100er Netz müssen.
Das 100er Netz ist über den Site-to-Site IPsec Tunnel bekannt.
Nun müsste ja eine Route auf dem Default-Gateway des 100er Netz, also auf der FW01 192.168.100.30 reichen.
192.168.13.0/24 GW:192.168.100.250 und
10.200.10.0/24 GW:192.168.100.250
Dann SOLLTE der trace ja wie folgt sein:
Ping vom Client 192.168.100.xx auf 192.168.13.xx oder 10.200.10.xx
1. 192.168.100.30
2. 192.168.100.250
3. 192.168.13.250
4. 192.168.13.11
Oder eben
1. 192.168.100.30
2. 192.168.100.250
3. 10.200.10.1
4. 10.200.10.11
Nur klappt hier aus irgendeinem Grund der Rückweg nicht immer!
Der Ping klappt aber nur sporadisch und bricht irgendwann ab. Verstehe ich nicht. 🤔
Es funktioniert nur robust, wenn ich diese Routen auf der FW01 entferne und stattdessen auf den Client im 100er Netz setze. (Obwohl ich das ja eigentlich nicht machen sollte).
Habe ich da einen Denkfehler?
Nein, keine Kaskade. Die Firewall hängt direkt am Internet.
Einen Anwendungsfall habe ich noch und noch nicht darüber gesprochen!
Es gibt den Anwendungsfall, dass das entfernte Netz 192.168.13.0 sowie RoadWarrior VPN Clients, die über dieses Netz mit der IP 10.200.10.0/24 (OpenVPN) ankommen in das 100er Netz müssen.
Das 100er Netz ist über den Site-to-Site IPsec Tunnel bekannt.
Nun müsste ja eine Route auf dem Default-Gateway des 100er Netz, also auf der FW01 192.168.100.30 reichen.
192.168.13.0/24 GW:192.168.100.250 und
10.200.10.0/24 GW:192.168.100.250
Dann SOLLTE der trace ja wie folgt sein:
Ping vom Client 192.168.100.xx auf 192.168.13.xx oder 10.200.10.xx
1. 192.168.100.30
2. 192.168.100.250
3. 192.168.13.250
4. 192.168.13.11
Oder eben
1. 192.168.100.30
2. 192.168.100.250
3. 10.200.10.1
4. 10.200.10.11
Nur klappt hier aus irgendeinem Grund der Rückweg nicht immer!
Der Ping klappt aber nur sporadisch und bricht irgendwann ab. Verstehe ich nicht. 🤔
Es funktioniert nur robust, wenn ich diese Routen auf der FW01 entferne und stattdessen auf den Client im 100er Netz setze. (Obwohl ich das ja eigentlich nicht machen sollte).
Habe ich da einen Denkfehler?
RoadWarrior VPN Clients, die über dieses Netz mit der IP 10.200.10.0/24 (OpenVPN) ankommen in das 100er Netz müssen.
Das ist kein Thema und kinderleicht. Du trägst einfach eine 2te Phase 2 mit dem 10.200.10.0/24er netz in die Site-2-Site Konfig ein wie du das ja auch schon gemacht hast. Eine Route ist bei IPsec nicht erforderlich, denn das wird durch die Phase 2 SAs bekanntlich erledigt. Siehe dazu auch hier.
Kardinalsfrage ist aber WO das Client OpenVPN terminiert wird? Passiert das auch auf der FW?
Leider fehlt diese Angabe in der Zeichnung oben!
Wenn nicht, musst du eine statische Route auf der FW zum OpenVPN Server eintragen um das 10.200.10.0er Netz bekannt zu machen wenn es nicht selber auf der FW liegt!
Zusätzlich musst du natürlich auch die Route ins 100er Netz den OpenVPN Clients über die Konfig distribuieren! Es sei denn du machst einen Gateway Redirect am OpenVPN Setup. Leider fehlt auch diese Information ob Redirect oder Split Tunneling so das eine lösungsorientierte Antwort schwer möglich ist ohne kristallkugeln zu müssen.
Alle Details dazu erklärt dir das OpenVPN Tutorial und seine weiterführenden Links!
Guten Morgen @aqui,
vielen Dank für vielen Tipps zur Lösungsfindung!
Die Netze:
(entfernter Standort)
(Hauptstandort)
Auf dem L3 Switch gibt es folgende routen:
OpenVPN:
Das OpenVPN läuft über die entfernte FW03. OpenVPN Clients verbinden sich zu dieser um die Ressourcen des Netzwerks dort nutzen zu können und zusätzliche Ressourcen können dann über den Site-to-Site Tunnel hier am Standort angezapft werden. (wie z.b. das 100er und 40er Netz)
(Genauso funktionierte es bis jetzt über die alte FW01. Nur die neue zickt noch rum.)
Hier noch eine Grafik mit OpenVPN:
Die Routen werden von der FW03 (OpenVPN Server) zum Client gepusht. Hier ein Auszug der Routingtabelle vom OpenVPN Client 10.200.10.3.
Die richtigen route sind da:
Was funktioniert:
Was nicht funktioniert:
Ich habe auf dem Default-GW des 100er Netz, nämlich auf der Firewall-01, eine statische Route gesetzt:
10.200.10.0/24 GW: 192.168.100.250 (Firewall-02)
192.168.13.0/24 GW: 192.168.100.250 (Firewall-02)
entferntes Netz:
Der ping aus dem 13ner Netz oder OpenVPN -> ins 100er Netz ist manchmal kurz da dann kommt wieder Zeitüberschreitung. 🤔
(Firewallregeln und Windows-Firewall sind "freigeschaltet")
Zwischenlösung:
Nur wenn ich am Client im 100er Netz der erreicht werden soll, eine Route ins 10.200.10.0 Netz setze funktioniert es.
Mein Problem ist also der Weg von FW01 zu FW02!🤔
So sollte das Paket laufen, gestrichelte Pfeile, aber irgendwo biegt es dann auf dem Rückweg falsch ab:
vielen Dank für vielen Tipps zur Lösungsfindung!
Die Netze:
(entfernter Standort)
- 10.200.10.0/24 (OpenVPN),
- 192.168.13.0/24 (remote Netz),
(Hauptstandort)
- 192.168.100.0/24 (Default-VLAN),
- 192.168.40.0/24 (VLAN 40),
- 0.0.0.0/0 GW: 192.168.100.30 (Firewall-01)
- 192.168.0.13.0/24 GW: 192.168.100.250 (Firewall-02)
- 10.200.10.0/24 GW: 192.168.100.250 (Firewall-02)
OpenVPN:
Das OpenVPN läuft über die entfernte FW03. OpenVPN Clients verbinden sich zu dieser um die Ressourcen des Netzwerks dort nutzen zu können und zusätzliche Ressourcen können dann über den Site-to-Site Tunnel hier am Standort angezapft werden. (wie z.b. das 100er und 40er Netz)
(Genauso funktionierte es bis jetzt über die alte FW01. Nur die neue zickt noch rum.)
Hier noch eine Grafik mit OpenVPN:
Die Routen werden von der FW03 (OpenVPN Server) zum Client gepusht. Hier ein Auszug der Routingtabelle vom OpenVPN Client 10.200.10.3.
Die richtigen route sind da:
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
...
192.168.13.0 255.255.255.0 10.200.10.1 10.200.10.3 281
192.168.40.0 255.255.255.0 10.200.10.1 10.200.10.3 281
192.168.100.0 255.255.255.0 10.200.10.1 10.200.10.3 281
...
===========================================================================
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
0.0.0.0 0.0.0.0 192.168.13.250 Standard
===========================================================================Was funktioniert:
- Das entfernte 13ner Netz kann wie gewünscht das 40er Netz am Hauptstandort erreichen und umgekehrt ✅
- Das entfernte OpenVPN kann das 40er Netz am Hauptstandort erreichen und umgekehrt ✅
Was nicht funktioniert:
Ich habe auf dem Default-GW des 100er Netz, nämlich auf der Firewall-01, eine statische Route gesetzt:
10.200.10.0/24 GW: 192.168.100.250 (Firewall-02)
192.168.13.0/24 GW: 192.168.100.250 (Firewall-02)
- das 100er Netz kann das entfernte 13ner Netz erreichen ✅ aber nicht umgekehrt 🛑
- das 100er Netz kann das entfernte OpenVPN Netz erreichen ✅ aber nicht umgekehrt 🛑
entferntes Netz:
- das 13ner Netz und das entfernte OpenVPN können das 100er Netz nicht konstant erreichen! Das Paket scheint auf dem Rückweg einmal falsch "abzubiegen" 🛑
Der ping aus dem 13ner Netz oder OpenVPN -> ins 100er Netz ist manchmal kurz da dann kommt wieder Zeitüberschreitung. 🤔
(Firewallregeln und Windows-Firewall sind "freigeschaltet")
Zwischenlösung:
Nur wenn ich am Client im 100er Netz der erreicht werden soll, eine Route ins 10.200.10.0 Netz setze funktioniert es.
Mein Problem ist also der Weg von FW01 zu FW02!🤔
So sollte das Paket laufen, gestrichelte Pfeile, aber irgendwo biegt es dann auf dem Rückweg falsch ab:
Ich habe auf dem Default-GW des 100er Netz, nämlich auf der Firewall-01, eine statische Route gesetzt:
Das geht so vermutlich nicht, denn jetzt bekämpfen sich die Phase 2 SAs des bestehenden Site-to-Site Tunnels die ja über die P2 ebenfalls diese Routen im FW Kernel setzen mit den statischen Routen, die die gleichen IP Netze nochmal via FW2 zum remoten Standort schickenAbgesehen davon ist es schlechtes IP Design das Default Gateway in einem L3 Design mit einem zentralen L3 Core Switch auf die Firewall zu legen.
Das Default Gateway sollte IMMER der L3 Core Switch sein für die IP Segmente die an ihm angeschlossen sind! Er (und nur er) hat dann eine Default Route auf die Firewall.
So kannst du dann nur durch Änderung der Gateway IP den Traffic über die FWs schicken.
Bei 2 Default Routen kannst du der 2ten eine schlechtere Metrik geben so das primär immer die erste genommen wird und im Ausfall die 2te. Mit Änderung der metrik kannst du dann auch das primäre Gateway ändern.
Bei gleicher Metrik macht der Switch ein Session basiertes Balancing über beide Gateways.
Das wäre ein deutlich bessere IP Design.
Das 2te Problem ist das die FW3 2mal die gleichen P2s ins Zielnetz auf ihrer Seite sieht. Sollte ein Tunnel überhaupt zustande kommen kann es passieren das du ein Routing Loop oder asymetrisches Routing hast.
Für den Test ist es sinnvoller das Default Gateway auf dem L3 Switch entweder auf die FW1 zeigen lässt ODER die FW2. Die statischen Routen ins 13er und OVPN Netz sollten dort entfallen! Langfristig soll ja die FW2 die 1er so oder so ersetzen, oder?
So kannst du sicherstellen das im testfalle dann sauber entweder nur die FW1 oder nur die FW2 genutzt werden.
Noch besser ist es zusätzlich die FW1 noch zu kappen oder runterzufahren das deren Tunnel auf der FW3 runtergehen und nur die FW2 aktiv ist. Das verhindert dann asymetrisches Routing und ggf. Loops.
Hi @aqui.
Ich bin jetzt leicht verwirrt. 😉
Meinst du es so, dass auf der FW01 ebenfalls ein Site-to-Site Tunnel zur entfernten FW03 besteht? Wenn ja, dem ist nicht so. Der Tunnel ist zwar da, aber deaktiviert. Die Netze habe ich im Tunnel sicherheitshalber entfernt.
Das GW auf die FW02 umzulegen ist aktuell nicht möglich, weil noch andere sachen über die FW01 laufen und die FW02 noch nicht bis zum Ende konfiguriert ist.
Das habe ich verstanden. Aber der Grund des Aufbaus ist, dass Clients aus dem 100er nicht ohne weiteres Zugriff auf die anderen VLANs erhalten.
Hätte das 100er Netz den L3 Switch als Gateway, könnten alle Clients in den beiden VLANs untereinander kommunizerieren.
Dann müsste ich um das einzuschränken mit ACLs auf dem L3 Switch arbeiten, was die Administration komplexer macht.
Kannst du das bitte etwas genauer erklären? Auf der FW03 existiert nur
1x Site-to-Site zur FW02
1x OpenVPN Gateway
Es gibt eigentlich keine zwei gleiche wege ins Zielnetz (40er und 100er).
Der ist zwar da aber deaktivert.
Ich bin jetzt leicht verwirrt. 😉
Das geht so vermutlich nicht, denn jetzt bekämpfen sich die Phase 2 SAs des bestehenden Site-to-Site Tunnels die ja über die P2 ebenfalls diese Routen im FW Kernel setzen mit den statischen Routen, die die gleichen IP Netze nochmal via FW2 zum remoten Standort schicken
Meinst du es so, dass auf der FW01 ebenfalls ein Site-to-Site Tunnel zur entfernten FW03 besteht? Wenn ja, dem ist nicht so. Der Tunnel ist zwar da, aber deaktiviert. Die Netze habe ich im Tunnel sicherheitshalber entfernt.
Abgesehen davon ist es schlechtes IP Design das Default Gateway in einem L3 Design mit einem zentralen L3 Core Switch auf die Firewall zu legen
Langfristig soll ja die FW2 die 1er so oder so ersetzen, oder?
Genau, wenn ich alles "rübergezogen" habe.Für den Test ist es sinnvoller das Default Gateway auf dem L3 Switch entweder auf die FW1 zeigen lässt ODER die FW2.
Das Default-GW auf dem L3 Switch ist die FW01.Das GW auf die FW02 umzulegen ist aktuell nicht möglich, weil noch andere sachen über die FW01 laufen und die FW02 noch nicht bis zum Ende konfiguriert ist.
Das habe ich verstanden. Aber der Grund des Aufbaus ist, dass Clients aus dem 100er nicht ohne weiteres Zugriff auf die anderen VLANs erhalten.
Hätte das 100er Netz den L3 Switch als Gateway, könnten alle Clients in den beiden VLANs untereinander kommunizerieren.
Dann müsste ich um das einzuschränken mit ACLs auf dem L3 Switch arbeiten, was die Administration komplexer macht.
Das 2te Problem ist das die FW3 2mal die gleichen P2s ins Zielnetz auf ihrer Seite sieht. Sollte ein Tunnel überhaupt zustande kommen kann es passieren das du ein Routing Loop oder asymetrisches Routing hast.
Kannst du das bitte etwas genauer erklären? Auf der FW03 existiert nur
1x Site-to-Site zur FW02
1x OpenVPN Gateway
Es gibt eigentlich keine zwei gleiche wege ins Zielnetz (40er und 100er).
Noch besser ist es zusätzlich die FW1 noch zu kappen oder runterzufahren das deren Tunnel auf der FW3 runtergehen und nur die FW2 aktiv ist. Das verhindert dann asymetrisches Routing und ggf. Loops.
Die FW01 hat keinen aktiven Tunnel zur FW03.Der ist zwar da aber deaktivert.
Meinst du es so, dass auf der FW01 ebenfalls ein Site-to-Site Tunnel zur entfernten FW03 besteht?
Davon muss man ja laut deiner Zeichnung ausgehen. Wer sollte denn sonst den VPN S2S Tunnel bedienen zur FW03. Das ist ja das bestehende Netz, oder?Der Tunnel ist zwar da, aber deaktiviert.
Aaahhsoo...ok dann ist das sauber! Dann vergiss den ganzen Einwand von oben!Das GW auf die FW02 umzulegen ist aktuell nicht möglich, weil noch andere Sachen über die FW01 laufen
OK, dann belasse es so mit den 2 separaten, statischen Routen dort. Wie gesagt, diese Routen zu den FW3 Netzen die dann über die FW2 gehen gehören dann auf den L3 Switch und NICHT auf die FW1 wenn für alle Endgeräte der L3 Switch das default Gateway ist.
Hi @aqui:
Der gelbe Blitz soll nur eine von zwei WAN Verbindung symbolisieren.
Der gestrichelte Pfeil ist die zweite WAN Verbindung über die der Site-to-Site Tunnel zwischen FW02 und entfernter FW03 aufgebaut ist.
Die FW01 baut keinen Tunnel mehr zur FW03 auf.
Und hier nochmal zur besseren Darstellung was aktuell noch nicht funtkioniert:
Ich habe auf dem Default-GW des 100er Netz, nämlich auf der FW01, eine statische Route gesetzt:
10.200.10.0/24 GW: 192.168.100.250 (Firewall-02)
192.168.13.0/24 GW: 192.168.100.250 (Firewall-02)
entferntes Netz:
Achtung: das 100er Netz hat als Default-GW die FW01 (192.168.100.30)
Der ping aus dem 13ner Netz oder OpenVPN -> ins 100er Netz ist manchmal kurz da dann kommt wieder Zeitüberschreitung. 🤔
(Firewallregeln und Windows-Firewall sind "freigeschaltet")
Zwischenlösung:
Nur wenn ich am Client im 100er Netz der erreicht werden soll, eine Route ins 10.200.10.0 Netz setze funktioniert es.
Wenn ich vermeiden sollte am Client eine Route zu setzen muss ich die Route doch auf dessen Default-GW setzen?! Das Default-GW ist für das 100er Netz die FW01 (192.168.100.30).
Also müssten die Route doch eigentlich da drauf?
Fazit:
Mein Problem ist also der Weg vom 100er Netz-> zu seinem Default-GW FW01 -> und von diesem zur FW02 -> welche den Site-to-Site zur FW03 aufbaut
So sollte das Paket laufen, gestrichelte Pfeile, aber irgendwo biegt es dann auf dem Rückweg falsch ab:
Ich entferne alle übrigen Netzwerk-Grafiken im Thread, da das sonst nur verwirrt.
Meinst du es so, dass auf der FW01 ebenfalls ein Site-to-Site Tunnel zur entfernten FW03 besteht?
Davon muss man ja laut deiner Zeichnung aussehen. Wer sollte denn sonst den VPN S2S Tunnel bedienen zur FW03. Das ist ja das bestehende Netz, oder?Der gelbe Blitz soll nur eine von zwei WAN Verbindung symbolisieren.
Der gestrichelte Pfeil ist die zweite WAN Verbindung über die der Site-to-Site Tunnel zwischen FW02 und entfernter FW03 aufgebaut ist.
Die FW01 baut keinen Tunnel mehr zur FW03 auf.
Und hier nochmal zur besseren Darstellung was aktuell noch nicht funtkioniert:
Ich habe auf dem Default-GW des 100er Netz, nämlich auf der FW01, eine statische Route gesetzt:
10.200.10.0/24 GW: 192.168.100.250 (Firewall-02)
192.168.13.0/24 GW: 192.168.100.250 (Firewall-02)
- das 100er Netz kann das entfernte 13ner Netz erreichen ✅ aber nicht umgekehrt 🛑
- das 100er Netz kann das entfernte OpenVPN Netz erreichen ✅ aber nicht umgekehrt 🛑
entferntes Netz:
- das 13ner Netz und das entfernte OpenVPN können das 100er Netz nicht konstant erreichen! Das Paket scheint auf dem Rückweg einmal falsch "abzubiegen" 🛑
Achtung: das 100er Netz hat als Default-GW die FW01 (192.168.100.30)
Der ping aus dem 13ner Netz oder OpenVPN -> ins 100er Netz ist manchmal kurz da dann kommt wieder Zeitüberschreitung. 🤔
(Firewallregeln und Windows-Firewall sind "freigeschaltet")
Zwischenlösung:
Nur wenn ich am Client im 100er Netz der erreicht werden soll, eine Route ins 10.200.10.0 Netz setze funktioniert es.
Wenn ich vermeiden sollte am Client eine Route zu setzen muss ich die Route doch auf dessen Default-GW setzen?! Das Default-GW ist für das 100er Netz die FW01 (192.168.100.30).
Also müssten die Route doch eigentlich da drauf?
Fazit:
Mein Problem ist also der Weg vom 100er Netz-> zu seinem Default-GW FW01 -> und von diesem zur FW02 -> welche den Site-to-Site zur FW03 aufbaut
So sollte das Paket laufen, gestrichelte Pfeile, aber irgendwo biegt es dann auf dem Rückweg falsch ab:
Ich entferne alle übrigen Netzwerk-Grafiken im Thread, da das sonst nur verwirrt.
OK, sofern der primäre FW03 Tunnel von FW01 deaktiviert ist für den 02er Test, ist das alles perfectly OK so wie oben dargestellt!! 👍
Hast du noch eine Idee warum der Weg sauber vom 100er Netz-> zu seinem Default-GW FW01 -> und von diesem zur FW02 -> welche den Site-to-Site zur FW03 aufbaut funktioniert, aber nicht umgekehrt?
Der Rückweg müsste ja wie folgt dann sein:
13ner Netz-> zu seinem Default-GW FW03 -> über den Site-to-Site zur FW02 -> diese kennt das 100ner -> Client der den ping gesendet hat mit Default-GW FW01
Da bricht der ping immer mal wieder ab. Kommt wieder und bricht wieder ab.
Der Rückweg müsste ja wie folgt dann sein:
13ner Netz-> zu seinem Default-GW FW03 -> über den Site-to-Site zur FW02 -> diese kennt das 100ner -> Client der den ping gesendet hat mit Default-GW FW01
Da bricht der ping immer mal wieder ab. Kommt wieder und bricht wieder ab.
Vermutlich ist an der FW01 das ICMP Redirect deaktiviert. Viele Firewall Hersteller machen sowas im Default Setup.
Die Auswirkung ist dann fatal, denn normalerweise würde die FW01 an anfragende Clients einen ICMP Redirect schicken um die Clients zu informieren das sie das FW02 Gateway im gleichen Netz direkt erreichen können OHNE das die Clients ihren Traffic in diese Netze immer über die .30 als unnötigen Durchlauferhitzer senden.
Insofern dann fatal weil aller lokaler Traffic dann über die Firewall und sehr wahrscheinlich dann durch ihr Regelwerk muss und dort keine Regel existiert.
Firewall haben für Redirects üblicherwiese einen Schalter um das zu verhindern und so Redirects in solchen Setups sinnvollerweise freizugeben.
Hier z.B. am Beispiel einer pfSense und OPNsense Firewall:
So ein asymetrisches Wegeblocking weist immer auf solche Redirect Problematiken hin oder auch asymetrisches Routing.
Da ist der Wireshark immer dein bester Freund.
Die Auswirkung ist dann fatal, denn normalerweise würde die FW01 an anfragende Clients einen ICMP Redirect schicken um die Clients zu informieren das sie das FW02 Gateway im gleichen Netz direkt erreichen können OHNE das die Clients ihren Traffic in diese Netze immer über die .30 als unnötigen Durchlauferhitzer senden.
Insofern dann fatal weil aller lokaler Traffic dann über die Firewall und sehr wahrscheinlich dann durch ihr Regelwerk muss und dort keine Regel existiert.
Firewall haben für Redirects üblicherwiese einen Schalter um das zu verhindern und so Redirects in solchen Setups sinnvollerweise freizugeben.
Hier z.B. am Beispiel einer pfSense und OPNsense Firewall:
Da ist der Wireshark immer dein bester Freund.
Die Auswirkung ist dann fatal, denn normalerweise würde die FW01 an anfragende Clients einen ICMP Redirect schicken um die Clients zu informieren das sie das FW02 Gateway im gleichen Netz direkt erreichen können OHNE das die Clients ihren Traffic in diese Netze immer über die .30 als unnötigen Durchlauferhitzer senden.
Hi, danke das sieht gut aus! Ich habe diese Optionen:
ICMP über Gateway zulassen
Gateway leitet Pings weiter
und der ping funktioniert ohne zusätzliches Firewallregel auf FW01!
Allerdings sehe ich im FW01 Firewall-Log, dass die Verbindung darüber geblockt werden. Dann wird diese ja doch zum Durchlauferhitzer.
Möchte ich nämlich aus dem entfernten 13ner Netz FW03 auf das lokale 100er Netz mit RDP zugreifen, sehe ich im FW01 Firewall-Log -> Port 3389 blockiert.
Auch im Wireshark kommt nichts auf 3389 rein.
Der ICMP Redirect von FW01 zu FW02 funktioniert also nicht vollständig / richtig, denn pings funktionieren jetzt ja!
Dann wird diese ja doch zum Durchlauferhitzer.
Das wäre natürlich blöd, denn so hast du den Traffic immer doppelt auf dem Segment und belastest damit die Endgeräte mit unnötigem Traffic. Das es sinnfrei ist lokalen Traffic nochmal überflüssigerweise durch das regelwerk zu jagen ist auch klar.Auf Routern oder Firewalls lässt man genau deswegen immer ICMP Redirects auf den lokalen LAN Interfaces zu. Jeder Router oder Firewall hat einen Schalter dafür wie du ja oben siehst. Wenn eine OpenSource Firewall sowas hat sollte eine kommerzielle es ja allemal haben!
Gut, auf der anderen Seite ist das bei dir ja auch nur temporär wenn die 02er langfristig die 01er ersetzen soll. Dann kann man sicher auch temporär mit dem Mehr an Traffic auf dem Segment leben?!
sehe ich im FW01 Firewall-Log -> Port 3389 blockiert. Auch im Wireshark kommt nichts auf 3389 rein.
Ist dann erwartbar wenn es keinen Redirect gibt und/oder die lokale Regel fehlt.Der ICMP Redirect von FW01 zu FW02 funktioniert also nicht vollständig
Bedenke das Ping ICMP Typ 8, Code 0 ist und Redirect ICMP Typ 5, Code 0-3! (Siehe hier)Aus Sicht einer Firewall sind das 2 völlig verschiedene Pakete die auch unterschiedliche Regelwerke bedingen. Eine "Gateway leitet Pings weiter" bezieht sich also ausschliesslich nur auf Pings.
1
Guten Morgen @aqui:
Folgendes gibt:
Ja, genau. Aber esgeht jetzt 😀:
Ich war zu ungeduldig. Mit der Option ICMP über Gateway zulassen + ICMP-Umleitungen protokollieren
kurz warten, geht es jetzt!
Verbindungen ping, RDP laufen ohne Firewallregel und im Firewall-Log taucht auch nichts auf! 🥳
Somit wird die FW01 nicht zum Durchlauferhitzer. Es hat einfach einen moment gedauert bis die routen intern bekannt waren.
Jeder Router oder Firewall hat einen Schalter dafür wie du ja oben siehst. Wenn eine OpenSource Firewall sowas hat sollte eine kommerzielle es ja allemal haben!
Folgendes gibt:
* ICMP auf Gateway zulassen: Das Gateway antwortet auf alle ICMP-Pakete.
- ICMP über Gateway zulassen: Bei Auswahl dieser Option werden ICMP-Pakete über das Gateway weitergeleitet, wenn die Pakete aus einem internen Netzwerk stammen, also einem Netzwerk ohne Standardgateway.
- ICMP von externen Netzwerken über Gateway zulassen: Bei Auswahl dieser Option werden ICMP-Pakete über das Gateway weitergeleitet, wenn die Pakete aus einem externen Netzwerk stammen, z.B. dem Internet.
- ICMP-Umleitungen protokollieren: Die ICMP-Umleitungen werden von Routern gegenseitig verschickt, um eine bessere Route zu einem Paketziel zu finden. Router ändern daraufhin ihre Routing-Tabellen und leiten das Paket auf der vermeintlich besseren Route zum gleichen Ziel weiter. Wenn Sie diese Option wählen, werden alle ICMP-Umleitungen im Firewallprotokoll protokolliert.
Hinweis – Wenn diese Option aktiviert ist, gelten die ICMP-Einstellungen für alle ICMP-Pakete, einschließlich Ping und Traceroute – wenn sie über ICMP gesendet werden –, auch wenn die zugehörigen Ping- und Traceroute-Einstellungen deaktiviert sind.
Gut, auf der anderen Seite ist das bei dir ja auch nur temporär wenn die 02er langfristig die 01er ersetzen soll. Dann kann man sicher auch temporär mit dem Mehr an Traffic auf dem Segment leben?!
Ja, genau. Aber esgeht jetzt 😀:
Ich war zu ungeduldig. Mit der Option ICMP über Gateway zulassen + ICMP-Umleitungen protokollieren
kurz warten, geht es jetzt!
Verbindungen ping, RDP laufen ohne Firewallregel und im Firewall-Log taucht auch nichts auf! 🥳
Somit wird die FW01 nicht zum Durchlauferhitzer. Es hat einfach einen moment gedauert bis die routen intern bekannt waren.
Bedenke das Ping ICMP Typ 8, Code 0 ist und Redirect ICMP Typ 5, Code 0-3!
Danke für den Hinweis. Habe Gateway leitet Pings weiter wieder deaktiviert.kurz warten, geht es jetzt!
Glückwunsch! 👏 💪Works as designed!
Bleibt ja dann nur noch den Thread als erledigt zu schliesen.
Wie kann ich einen Beitrag als gelöst markieren?
Ja super! Ich danke dir vielmals! Den Thread setze ich gleich auf gelöst. ✅
Eine Frage zum Abschluss: Wenn die FW02 dann "produktiv" wird und die FW01 demontiert wird muss ich die route auf L3 Switch wieder entfernen.
Richtigerweise wäre in einem korrekten L3 Design der L3-Core Switch auch für mein 100er Netz das Default-GW und nicht die FW01. Habe ich verstanden.
Nun würden aber alle Netze ohne Einschränkung untereinander kommunizieren können.
Was ist aber, wenn ich das nicht möchte? (in meinem Design kann das 100er Netz, da es ein anderes Default-GW hat FW01 -nicht mit den anderen Netzen sprechen. Das ist so gewünscht!)
Kann ich das nur über ACLs auf dem L3 steuern?
Eine Frage zum Abschluss: Wenn die FW02 dann "produktiv" wird und die FW01 demontiert wird muss ich die route auf L3 Switch wieder entfernen.
Richtigerweise wäre in einem korrekten L3 Design der L3-Core Switch auch für mein 100er Netz das Default-GW und nicht die FW01. Habe ich verstanden.
Nun würden aber alle Netze ohne Einschränkung untereinander kommunizieren können.
Was ist aber, wenn ich das nicht möchte? (in meinem Design kann das 100er Netz, da es ein anderes Default-GW hat FW01 -nicht mit den anderen Netzen sprechen. Das ist so gewünscht!)
Kann ich das nur über ACLs auf dem L3 steuern?
wird muss ich die route auf L3 Switch wieder entfernen.
Da kannst sie ja mal drauflassen und sehen was passiert...! Ja logisch, denn sie würde ja zu einer nicht mehr existenten IP Adresse zeigen und die Pakete dann ins IP Nirwana senden. Sagt einem auch schon der gesunde IT Verstand.
Mit anderen Worten, Ja die müssen dann natürlich wieder weg. Der Switch hat dann einzig und allein nur noch eine Default Route (0.0.0.0/0) auf die alte, neue FW02 ex 01.
würden aber alle Netze ohne Einschränkung untereinander kommunizieren können.
Das ist richtig! Der L3 Switch ist für alle angeschlossenen Endgeräte der Default Router.Eine besondere Bedeutung hat dann wieder das 100er Netz, denn Clients dort fragen für externe Netze ja zuerst auch wieder den Switch und der sendet...du ahnst es schon...wie oben wieder ein ICMP Redirect weil die alte, neue FW02 ex 01 dort direkt zu erreichen ist. Diesmal ist da aber keine weitere Firewall dazwischen und du musst nur sicherstellen in der IP Interface Konfig des Switches das dort in jedem Falle ICMP Redirects erlaubt sind. Üblicherwiese ist das Default bei L3 Switches. Kann man aber zur Sicherheit nochmal im Handbuch checken oder wenn man es wasserdicht haben will mit dem Wireshark.
Was ist aber, wenn ich das nicht möchte?
Ja, richtig ohne Reglementierung können zu mindestens die IP Netze am L3 Switch ohne Einschränkungen miteinander kommunizieren. Ein L3 Switch arbeitet wie ein Router üblicherweise nach einem Blacklisting Prinzip. Es ist alles erlaubt was nicht extra verboten wurde.Bei der Firewall ist das genau umgekehrt da gilt bekanntlich eine Whitelisting Logik.
Die Kommunikation der IP Netze am L3 Switch steuerst du also in der Tat mit ACLs und alles was in remote Netze geht via Firewall kannst du dort über ein Regelwerk steuern.
Willst du das nicht am Switch machen musst du dein L3 Switchkonzept dort aufgeben und den Switch zu einem einfachen L2 Switch degrarieren und ihn dann per L2 Trunk an die Firewall anflanschen.
Idealerweise dann natürlich mit einem LACP LAG (Link Aggregation) weil es bei lokalem Routing in so einem L2 Konzept prinzipbedingt zu einer Verdoppelung des Traffics kommt was man dann mit einem LACP LAG wieder kompensiert.
Ein hiesiges Tutorial schildert so ein L2 Konzept mit zentraler Firewall Anbindung.
Besten Dank nochmal für die Aufklärung und Erklärung!
Jedenfalls funktioniert die Kommunikation jetzt in der Migrationsphase wie gewünscht. ✅🙏
Das L3-Konzept aufgeben und alles über die Firewall laufen zu lassen, wird aber leider daran scheitern, dass diese leistungsmäßig einen Flaschenhals darstellt.
Es müssten dann z.b. Terrabyteweise Backups über die FW gepumpt werden.
Jedenfalls funktioniert die Kommunikation jetzt in der Migrationsphase wie gewünscht. ✅🙏
Das L3-Konzept aufgeben und alles über die Firewall laufen zu lassen, wird aber leider daran scheitern, dass diese leistungsmäßig einen Flaschenhals darstellt.
Es müssten dann z.b. Terrabyteweise Backups über die FW gepumpt werden.
Einen Einwand wie man die kommunikation unter den VLANs einschränken kann, habe ich aber doch noch 😂
Neues Beispiel mit VLAN 30:
Ich lege eine neue VLAN ID 30 nur auf dem L3-Core Switch an, aber trage dort kein IP-Netz ein.
Das VLAN 30 tagge ich auf den Anschluss-Port der FW01 zusätzlich.
Dann lege ich auf der FW01 ein neue VLAN-fähige Schnittstelle mit IP 192.168.30.254/24 mit VLAN-Tag 30 an.
Jetzt läuft der Verkehr vom 30er Netz erstmal nur zur FW01. Dort kann ich über FW-Regeln den Zugriff vom 100er Netz in das 30er Netz erlauben.
Neues Beispiel mit VLAN 30:
Ich lege eine neue VLAN ID 30 nur auf dem L3-Core Switch an, aber trage dort kein IP-Netz ein.
Das VLAN 30 tagge ich auf den Anschluss-Port der FW01 zusätzlich.
Dann lege ich auf der FW01 ein neue VLAN-fähige Schnittstelle mit IP 192.168.30.254/24 mit VLAN-Tag 30 an.
Jetzt läuft der Verkehr vom 30er Netz erstmal nur zur FW01. Dort kann ich über FW-Regeln den Zugriff vom 100er Netz in das 30er Netz erlauben.
dass diese leistungsmäßig einen Flaschenhals darstellt.
Das ist auch der Grund warum L3 Switching Konzepte hier immer best Practise und erste Wahl sind, weil in Wirespeed. Das sollte oben auch lediglich nur die andere Variante technisch aufzeigen. aber trage dort kein IP-Netz ein. Das VLAN 30 tagge ich auf den Anschluss-Port der FW01 zusätzlich.
OK, das ist ein klassisches und übliches hybrides Konzept wie es z.B. bei Gastnetzen usw. immer umgesetzt wird, denn die will man ja keinesfalls IP-technisch auf seinem internen Switch haben und immer direkt an der FW.Man "schleift" dieses VLAN dann quasi L2-technisch nur durch über den Core.
auf der FW01 ein neue VLAN-fähige Schnittstelle mit IP 192.168.30.254/24 mit VLAN-Tag 30 an.
Das ist richtig!Jetzt läuft der Verkehr vom 30er Netz erstmal nur zur FW01. Dort kann ich über FW-Regeln den Zugriff vom 100er Netz in das 30er Netz erlauben.
Genau richtig wenn man ein strikteres und vor allem stateful Regelwerk dort etabliert will oder muss. ACLs sind bekanntlich nicht stateful!1
Danke für die Bestätigung! So ist's bereits eingerichtet und läuft! 👍
1
Works as designed!! 😉
1
