Routen mehrerer Subnetze über eine VPN-Verbindung mit Lancom und Zyxel

Ja, muss man leider wieder kristallkugeln aber bei der Hardware, dem Schlüsselwort "Main Mode" und dem Fehlerbild spricht vieles für IPsec.
Damit ist dann auch klar das mit Routen an sich die Thematik nicht zu lösen ist.
Bekanntlich wird der relevante Traffic den IPsec in den Tunnel forwardet immer mit den Phase 2 SAs definiert. Im Zyxel VPN Gateway, Address Rule. Hier müssen auf beiden Seiten für die Netze C und D einfach 2 SAs dazugetragen werden und fertig ist der Lack.
Hier findest du ein paar Threadbeispiele zu der Thematik.
2 PfSensen mit OpenVPN verbinden 1x Server 1x Client (Hier P2 Policy des Mikrotik!)
PfSense IPsec hub and spoke

Es wäre sehr außergewöhnlich wenn sich auf der Zywall nicht mehrere Phase 2 SAs definieren liessen, denn das kann sogar jeder China Router vom Grabbeltisch.
Sollte das wider Erwarten doch der Fall sein musst du die Phase 2 mit der Subnetzmaske etwas erweitern um alle 3 Netze B, C und D in eine CIDR Range zu bringen für die SA Definition.
Beispiel:
Die 3 Netze sind z.B. 172.16.10.0 /24, 172.16.20.0 /24 und 172.16.60.0 /24 dann kannst du die Phase 2 SA auf beiden Seiten mit einem 18 Bit Prefix auf 172.10.0.0 /18 (255.255.192.0) definieren um alle diese 3 Netze mit nur einer P2 SA in den Tunnel zu routen.

Die grundsätzliche Frage die sich stellt ist, warum du solch einen Frickelkram auf beiden Seiten mit überflüssigen Router Kaskaden überhaupt machst?! Beide Router, Digitalisierungs- und Fritzbox, sind beides aktive VPN Router die sich auch problemlos per IPsec VPN im Main Mode direkt koppeln lassen würden um so ein deutlich effizienteres und aus Betriebskosten sparsameres VPN zu betreiben. Beide supporten zudem mehrere P2 SAs. (Siehe auch hier)
Auch Lancom und Zywall könnte man kaskadenfrei betreiben. Aber warum einfach und effizent machen wenn es umständlich und teuer auch geht...

2 öffentliche IP Netze in einem VPN?? 🤔
Nundenn... dann bist du zumindestens mit der Zywall dann chancenlos das zum Laufen zu bringen zumindestens mit der Ausstattung, die mit der Gängelei dann eigentlich eine Frechheit ist!
Ersetze die mit einer pfSense oder OPNsense oder einem Mikrotik und schon ist dein Problem umfassend gelöst. Oder...kaufe teure Lizenzen und unterstütze dieses Modell weiter.

OK, das ist dann natürlich OK.
Kann man machen und wäre eine mögliche Workaround Lösung allerdings sollte man dann immer auf dem Radar haben das damit dann sämtlicher Traffic der Location A durch den Tunnel geht und an B ausgekoppelt wird. Man ist also vollständig auf B angewiesen.
Normal sind die P2 SAs (und dazu gehört auch ein Redirect) vom Routing abgekoppelt. Einige FW Hardware Plattformen bieten die Option lokale Netze dann vom Gateway Redirekt auszunehmen was sich aber einzig auf lokale Netze aber nicht auf remote Netze bezieht.
Es ist also mehr als fraglich ob lokales Routing die Redirect SA überwindet. Du müsstest dann mit einer Policy Based Routing Route Map sagen das alles was nicht 192.168.1.0/24, 100.102.0.0/15 und 188.144.0.0/15 ist als next Hop Gateway die Provider Gateway IP oder das Interface Internet verwenden soll.
Ob das aber klappt und die Zywall überhaupt PBR kann musst du klären.

Vermutlich wird es langfristig gesehen deutlich besser und technisch sauberer sein die Zywall gegen eine Standard konforme Firewall wie OPNsense oder pfSense o.ä. zu tauschen um sich all dieser proprietären Zywall IPsec Hürden zu entledigen. Die P2 SAs so zu limitieren und Endanwender zu gängeln ist ein Unding und NoGo.

👏 👍
Das "No-proposal-matched" bedeutet das die Krypto Policies nicht übereinstimmen mit dem Gegenüber. Das kann aber normal sein wenn du wie üblich mehrere Policies anbietest von denen das Gegenüber ggf. einige nicht kennt und dann nur diese Unbekannten anmeckert. Manche bieten per Default oft noch solche Steinzeit Verfahren wie DES oder 3DES an die andere schon längst rausgeschmissen haben so das es je nach Logging dann zu solchen Meldungen kommen kann.
Das er dann "Successfully connected to peer VPN_2_USG" sagt, zeigt aber das es zumindestens eine Policies gibt die auf beiden Seiten gemensam ist und die Peers sich einigen konnten. Im Endeffekt also OK.
Interessant (und auch etwas gruselig) ist das der Lancom trotz Gateway Redirect mit 0.0.0.0/0 dennoch statische Routen benötigt und lokalen Traffic dennoch nicht in den Tunnel routet was sehr unüblich ist in eine Redirect Setup. Aber nundenn...wenns klappt ist ja alles gut?!

Nur zur Klarstellung: Selbstverständlich kann man auf der ZyWALL derselben IKE-Policy (Phase 1) mehrere IPSec-Policies (Phase 2) zuordnen. Aber dafür muss man eben - anderes als beim LANCOM - auch mehrere komplette Phase2-Policies erstellen. In der GUI des LANCOM ist das oberflächlich betrachtet etwas einfacher. "Unter der Haube" passiert aber auch beim LANCOM letztlich nichts anderes. Hätte man dies so konfiguriert (und das wäre naheliegend gewesen, weil dies standardkonform und "der kleinste gemeinsame Nenner" zwischen IPSec-Gateways verschiedener Hersteller ist), wären letztlich 3 parallel aktive IPSec-SAs etabliert worden. Das hätte vermutlich problemlos funktioniert (im Übrigen auch im Main-Mode statt Aggressive-Mode). Das Problem ist jedoch, dass üblicherweise die kommerziellen Gateways eine lizenztechnische Beschränkung bzgl. der maximalen Anzahl der parallel aufgebauten IPSec-SAs haben - schliesslich soll man bei höherem Bedarf auch das entsprechend teurere größere Modell oder ein Lizenzupgrade erwerben... Die USG20 war zu Beginn auf 10 parallele IPSec-SAs beschränkt - später wurde das meiner Erinnerung nach auf 20 aufgebohrt. Die ZyWALL wäre also nicht das Problem gewesen, sondern der LANCOM, der auf lediglich 3 parallele IPSec-SAs limitiert ist. Für die hier in Rede stehende Site-to-Site-Verbindung hätte das gereicht, aber der TO hat ja am LANCOM auch noch einen Tunnel Richtung Homeoffice terminiert. DAS war sein Kernproblem - was sich aber dadurch lösen liess, dass beide Gateways es zulassen, auch Traffic welcher nicht in der Phase2-Policy explizit beschrieben ist, per Policyrouting zwangsweise durch den Tunnel zu schieben.

Und wenn wir schon mal beim Klug###ern sind...
@akar00: Sowohl der LANCOM als auch die ZyWALL sind EOL und erhalten regulär keine Firmwareupdates mehr. Diese Geräte weiterhin produktiv zu nutzen, erscheint fahrlässig - erst recht bei einer Zusammenschaltung mit der TI.

Gruß
sk

Danke nochmal an @sk für die Details! Wirft etwas mehr Licht auf die Thematik. Das auch da lizenztechnisch schon Hand angelegt wird ist bedenklich und 3 als Limit eigentlich frech. Gut, über EoL Hardware muss man dann auch nicht mehr groß meckern. Verglichen damit ist im Vergleich Cisco auch mit älteren 880er EoL Routern ja liberal ohne SA Limits... 😉

Die Lösung war nicht stabil und lief nur im Aggressive Mode, weil Deine Konfiguration falsch war. Der Fehler war, dass Du auf der ZyWALL drei parallele Gateway-Policies (Phase 1/IKE-SA) für das gleiche Remote-Gateway konfiguriert hast. Wie soll die Box da die richtige Policy während des Handshakes auswählen? Vermutlich hast Du den dämlichen Konfigurationsassistenten benutzt - dann kommt soetwas dabei heraus...
Richtig wäre gewesen, lediglich zwei zusätzliche VPN-Policies (Phase 2/IPSec-SA) zu konfigurieren und diese einfach an die bereits vorhandene (und eindeutige) Gateway-Policy zu binden.

Freilich nützt Dir das aber nichts, wenn das Limit des LANCOM bei 3 parallelen VPN-Tunneln liegt. Allerdings ist es nicht bei allen Herstellern so, dass das Limit nach der Anzahl der IPSec-SAs berechnet wird - manche berechnen auch nach der Anzahl unterschiedlicher VPN-Peers bzw. IKE-SAs (z.B. Cisco Firepower). Wie der LANCOM diesbezüglich "tickt", weiss ich leider nicht. Da das Limit aber so auffällig niedrig gesetzt ist, würde es mich nicht wundern, wenn letzteres der Fall wäre. "Versuch macht kluch..."

Gruß
sk

Das ist Unsinn, denn die SAs haben keinen Bezug zur Anzahl der Tunnel. Auch da ist es nur ein Tunnel aber mit 3 SAs dann eben. Aggressive Mode ist auch nur bedingt sicher, besonders im TI Umfeld aber wenn du damit leben kannst...warum nicht.

In der Tat sind die Begrifflichkeiten nicht bei allen Herstellern konsistent, was zu Missverständnissen führen kann. Auch ist die GUI der ZyWALL in diesem Punkt schon durchaus speziell. Ich hatte deshalb obenstehend versucht, durch Erläuterungen in den Klammern kenntlich zu machen, was an der jeweiligen Stelle konfiguriert wird. Auch habe ich eigentlich versucht, den Terminus "Tunnel" im Kontext der Limitierungen so gut es geht zu vermeiden und klargestellt, dass eventuelle Limitierungen je nach Hersteller unterschiedlich ausgestaltet sein können: Manche Hersteller limitieren z.B. die maximale Anzahl der VPN-Peers, andere zählen hingegen die Anzahl der parallel etablierten Phase2-SAs.
Die ZyWALLs machen m.W. letzteres - jedenfalls zeigen sie im VPN-Monitor jede etablierte Phase2-SA separat und mit jeweils eigenen Countern an. Daran aber die Limitierung festzumachen, finde ich allerdings auch nicht schlüssig, da sie es - anders als die ZyNOS-basierenden Vorgängermodelle - zulassen, per Policyroute auch IP-Traffic "hindurch zu schieben", der gar nicht in dieser Phase2-SA definiert ist. Vermutlich ist auch das - wie viele Begrifflichkeiten und Vordefinitionen in der GUI der kleineren Geräte der Linux-basierenden Modellreihen - ein Überbleibsel bzw. "Erbe" aus der alten ZyNOS-Geräteserie.

Ich fürchte, da liegt ein Missverständnis vor:
Zum Zeitpunkt meines Einsteigens in diesen Thread, hattest Du schon eine funktionierende Lösung gefunden. Mir ging es eigentlich nur um die Klarstellung, dass es auch auf der ZyWALL möglich ist, mehrere Remote-Netze in Richtung des selben VPN-Peers zu konfigurieren. Das war von Dir zuvor etwas missverständlich dargestellt worden und aqui hatte sich in Unkenntnis der ZyWALL darüber gewundert, dass dies nicht möglich sein soll.
Es war nicht meine Intention, die bereits gefundene Lösung als nachteilig zu qualifizieren und Dich zu einem anderen Lösungsweg zu bewegen. Wenn das so stabil und ohne negative Seiteneffekte funktioniert, dann ist alles prima und diese Umsetzung zweifelohne auch eleganter, als drei separate Phase2-Policies. Es hätte aber auch anders laufen können: Die Verwendung von 0.0.0.0/0 als Remote-Netz hätte auch dazu führen können, dass der LANCOM ungewollt sämtlichen Traffic an Ziele, zu denen er keine andere höherwertige Route kennt, in den VPN-Tunnel leitet. Dann wäre im Zweifel der andere Lösungsansatz als ein dem Standard entsprechender "kleinster gemeinsamer Nenner" zwischen VPN-Gateways verschiedener Hersteller zu verfolgen gewesen.

Gruß
sk