2 Standorte gleiches internes Netz, Site-to-Site IPsec

Hallo Holger,

Herzlich willkommen hier in der Community !

(Sorry, my German-speaking brain isn't creating thoughts at the moment. )

Here's another resource that describes the solution you're trying: More VPN between same subnets.

If you still need help, please insert pictures of the Edits of the IPsec Connection and Remote Gateway from each Standort.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Hallo Bob,

hier einige weitere Screenshots:

Standort 1:

Standort 2:

Kannst Du einen Fehler finden ?

Vielen Dank für deine Hilfe !

Gruß Holger

In Standort 1, sind VPN_UTM2 und VPN_UTM1 umgekehrt.

MfG - Bob

Sorry, Bilder verwechselt. Hier die richtigen Screenshots von Standort 1:

Der Tunnel ist grün, trotzdem kann ich von Standort 1 nicht 192.168.169.230 an Standort 2 erreichen.

MfG Holger

If ping is enabled, do you get a response if you ping 192.168.190.230 from Standort 1?

MfG - Bob (Bitte auf Deutsch weiterhin.)

Moin Holger

Deine Konfiguration sieht eigentlich gut aus.

Die Frage ist, wie sprichst Du die Gegenseite an?

Wenn Du von Standort A ein System in Standort B erreichen willst, musst Du die IP nutzen, die Du dem Standort B in Standort A für das System zugeornet hast.

Beispiel: 192.168.169.1-A will 192.168.169.1-B erreichen -> Du musst also die Fake-Netz-IP von Standort B ansprechen: Ping 192.168.190.1

Du solltest in den NAT-Regeln und in den automatischen Firewallregeln das Logging aktivieren (in den NAT-Regeln unter "advanced"  "Log initial packets" -> die werden im Log als weiße Linien angezeigt und in den automatischen FW-Regeln unter "advanced" "Log traffic" -> die werden dann grün angezeigt).

Noch ein Hinweis: Deine ssl-Pool-Netze erreichen sich über Dein Konstrukt gegenseitig (allerdings nur, wenn sie sich unterscheiden). Aber sie erreichen nicht das gegenüberliegende LAN.
Hier musst Du ebenfalls noch mit 1:1-Regeln arbeiten. Am einfachsten genauso wie bei deiner LAN-Übersetzung.

Oh - und noch ein Hinweis: Wenn Du ICMP in den Logs sehen willst, musst Du unter "Firewall", Reiter "ICMP" den Haken bei "Gateway forwards pings" rausnehmen und auch die traceroute-Haken entfernen (das hat Bob bestimmt auch in seinen "Rulz" beschrieben).

LG, Janbo

Der Ping auf 192.168.190.230 ist erfolgreich.

Mit den 180 und 190er Adressen kann ich jetzt arbeiten.

Allerdings löst das mein Problem noch nicht ganz (oder ich verstehe es nur nicht richtig):

Ich habe am Standort 1 derzeit zwei VM's (DC und Exch) im Netz 192.168.169.0 laufen.

Diese sollen an Standort 2 wechseln, aber für Domain-Member am Standort 1 erreichbar bleiben.

Also muß ich doch auch das Netz 192.168.169.0 direkt ansprechen können ?

Oder wie kann ich das realisieren ? Die IP's von DC und Exch will ich ungern ändern, und das ganze Netz am Standort 1 ändern auch nicht wirklich. Evtl. eine Route ?

Würde es funktionieren am Standort 1 ein Netz 192.168.169.0/25 und am Standort 2 ein Netz 192168.169.192/26 anzulegen und damit eine Site-to-Site IPsec ?

Vielen Dank für eure Bemühungen !

Gruß Holger

Hallo Holger,

In each LAN, local resources will be reached in 192.168.169.0/24.  When trying to reach resources in the other LAN, 180 and 190 are needed as Janbo precised and you confirmed.  Is this a DNS problem where you need FQDNs resolved to 180/190 for resources in the other LAN?

Certainly, if you can alter the subnets on one or both sites, that would be preferable.  I prefer to use subnets in 172.16.0.0/12 for subnets not in homes, reserving 192.068.0.0/16 for homes and hotspots and 10.0.0.0/8 for large business like IBM.

Cheers - Bob

Moin Holger

Bob hat es ja schon bestätigt. Das Beste ist natürlich immer, wenn sich die Netze der beiden Sites unterscheiden und das tun sie, wenn Du sie mit größeren Masken "klein" schneidest. Das geht natürlich nur, wenn die Hosts auf der jeweils anderen Seite unterschiedliche IP-Adressen zum gegnüberliegenden Netz haben. Außerdem musst Du an jedem Host in beiden Standorten die IP-Konfiguration anpassen (Maske und ggf. auf einer Seite auch das Gateway).

Es macht mich aber stutzig, dass Du nicht die beiden 25er Netze angesprochen hast (192.168.169.0/25 und 192.168.169.128/25), weil Du jetzt das gesamte Netz 192.168.169.128/26 nicht abdeckst. Hosts in diesem Netz würden die anderen Hosts nicht mehr erreichen (außer, Du legst dafür ein VLAN und auf der UTM des Standortes noch ein Interface an) oder routest es auf dem Standortswitch.

Wenn Du aber soviel anfassen musst, ist es vielleicht sinnvoller, Du denkst darüber nach, ob Du dann nicht doch in Standort 1 ein Neues Netz wählst (siehe Bob's Vorschlag).

Du sprichst aber auf einmal auch davon, dass Du DCs von einem Standort in den anderen verschieben willst. Eventuell kannst Du auch einmal schreiben, was überhaupt hinter den ganzen Ideen steckt - eventuell können wir da ja auch mit ganz anderen Ideen helfen.

Beispiel: Du kannst auch einen RED-Tunnel zwischen die UTMs spannen und die entstehenden RED-Interfaces mit Deinem jeweiligen LAN "bridgen". In diesem Fall kannst mit ARP-Forwarding sogar eine virtuelle Layer2-Verbindung zwischen den Netzen herstellen. Hier brauchst Du dann gar nicht zu routen sondern kannst Hosts auf der anderen Seite mit deren originaler IP erreichen. Auch hier dürfen IPs natürlich nicht doppelt vorkommen -> Du hast dann ja ein "Switching" über beide Standorte.
Gemacht habe ich das bisher nur mit RED-Boxen für Migrationszwecke - aber mit zwei UTMs müsste das eigentlich auch gehen.

Wie gesagt: Schreib doch einfach mal, was Du vorhast :-)

LG, Janbo

Moin Holger

Bob hat es ja schon bestätigt. Das Beste ist natürlich immer, wenn sich die Netze der beiden Sites unterscheiden und das tun sie, wenn Du sie mit größeren Masken "klein" schneidest. Das geht natürlich nur, wenn die Hosts auf der jeweils anderen Seite unterschiedliche IP-Adressen zum gegnüberliegenden Netz haben. Außerdem musst Du an jedem Host in beiden Standorten die IP-Konfiguration anpassen (Maske und ggf. auf einer Seite auch das Gateway).

Es macht mich aber stutzig, dass Du nicht die beiden 25er Netze angesprochen hast (192.168.169.0/25 und 192.168.169.128/25), weil Du jetzt das gesamte Netz 192.168.169.128/26 nicht abdeckst. Hosts in diesem Netz würden die anderen Hosts nicht mehr erreichen (außer, Du legst dafür ein VLAN und auf der UTM des Standortes noch ein Interface an) oder routest es auf dem Standortswitch.

Wenn Du aber soviel anfassen musst, ist es vielleicht sinnvoller, Du denkst darüber nach, ob Du dann nicht doch in Standort 1 ein Neues Netz wählst (siehe Bob's Vorschlag).

Du sprichst aber auf einmal auch davon, dass Du DCs von einem Standort in den anderen verschieben willst. Eventuell kannst Du auch einmal schreiben, was überhaupt hinter den ganzen Ideen steckt - eventuell können wir da ja auch mit ganz anderen Ideen helfen.

Beispiel: Du kannst auch einen RED-Tunnel zwischen die UTMs spannen und die entstehenden RED-Interfaces mit Deinem jeweiligen LAN "bridgen". In diesem Fall kannst mit ARP-Forwarding sogar eine virtuelle Layer2-Verbindung zwischen den Netzen herstellen. Hier brauchst Du dann gar nicht zu routen sondern kannst Hosts auf der anderen Seite mit deren originaler IP erreichen. Auch hier dürfen IPs natürlich nicht doppelt vorkommen -> Du hast dann ja ein "Switching" über beide Standorte.
Gemacht habe ich das bisher nur mit RED-Boxen für Migrationszwecke - aber mit zwei UTMs müsste das eigentlich auch gehen.

Wie gesagt: Schreib doch einfach mal, was Du vorhast :-)

LG, Janbo

Ah, thinking outside the box!  I really like the RED bridge solution, Janbo - BRAVO!

Holger, you would still need to change the IP of "Internal (Address)" on one of the UTMs, but changing other fixed IPs would be much less of a challenge.  Also less work with internal DNS and DHCP.

Cheers - Bob

Das mit dem RED klingt ja ganz gut.

Ich beschreibe den Zustand mal etwas genauer:

Derzeit existiert Standort 1 mit kompletter Infrastruktur, DC, Exchange, Clients usw als ein Netz (192.168.169.0/24)

Dazu ist jetzt Standort 2 gekommen, mit besserem (schnellerem) Internet und besseren räumlichen Gegebenheiten.

Daher der Plan das Netz von Standort 1 auf Standort 2 auszudehnen und dort die Server aufzustellen.

Die Clients bleiben allerdings weiterhin am Standort 1.

Nun ist es die Herausforderung beide Standorte mit möglichst wenig Aufwand zu verbinden.

Wie schon gesagt, das Netz von Standort 1 komplett zu ändern wäre sehr aufwändig, von der Menge her.

Und die IP´s der Server, die an Standort 2 verlagert werden sollen, zu ändern ist ja nun auch nicht gerade der goldene Weg.

Daher mein "Wunsch" nach gleichem internen Netz auf beiden Seiten.

Wäre das mit RED realisierbar ?

Gruß Holger

Moin Holger

Ja. Meines Erachtens schon. Du müsstest Dich einmal einlesen in das Konzept, ein RED-Interafce mit einem lokalen Interface zu "bridgen".

Allerdings ist eine Sache zu bedenken: Ein RED-Tunnel hat mehr Overhead als ein IPSec-Tunnel - der Netto-Durchsatz ist also geringer. Ob das in Deinem Fall ins Gewicht fällt, müsstest Du ausprobieren.

UND: Und das ist wahrscheinlich der größte Klotz: Dein Internet-Breakout kann nur noch in einem Standort genutzt werden, weil die zweite UTM das Netz ja nicht mehr routet sondern nur noch zur ersten UTM "switcht". Der gesamte Internet-Traffic (z.B. von Standort 2) geht dann erst durch den RED-Tunnel und dann in Standort 1 ins Internet. Das ist bestimmt nicht in Deinem Sinne.
Mit den Einwahlnetzen der beiden Standorte wird es dann noch einmal komplexer. Man kann da "rumtrixen", wenn Du mit einem zusätzlichen Gateway auf einem Switch/Router in Standort 2 arbeitest, dass dort über ein Transfernetz (VLAN) auf dieselbe UTM zeigt. Aber das ist alles seeeehr weit entfernt von der wichtigsten Regel der IT: "keep it simple" :-)

Also ein tolles Konzept für Migrationen - aber für den Dauerbetrieb eher nicht so geeignet.

Ganz ehrlich - auch, wenn Du Dich davor scheust:
Ich würde an Deiner Stelle den IP-Bereich zusammen mit den Servern in den Standort 2 verschieben und danach in Standort 1 ein neues IP-Netz einführen (fließende Migration mit RED-Bridge und anschließendem Umschalten oder als BigBang an einem Wochenende).

Wenn im Standort 1 eh hauptsächlich Clients sind, sollten diese auch alle dynamisch konfiguriert werden (über DHCP). Das gilt sowohl für Clients, als auch für Drucker etc. Wenn Du das vorbereitest, ist die Umschaltung eigentlich nach einem Neustart der Systeme bereits geschafft.

Den DHCP kannst Du trotzdem auf dem Windows-Server belassen, wenn Du auf der UTM ein Relay einrichtest - ich würde es aber lieber im Standort machen - z.B. durch die UTM.

Dann hättest Du "nur" noch IPSec-Tunnel, Routing und Firewallregeln.
-> Jedes Netz kann jedes andere Netz erreichen, Du brauchst nicht zu NATten, kannst alle Funktionen der UTM "normal" benutzen (insbesondere auch QoS, IPS, ATP etc.).
Internet "rein" und "raus" inkl. WAF für Deinen Exchange kannst Du ebenfalls in jeweils dem Standort konfigurieren, wo Du es brauchst.
Und wenn Du mal Probleme hast, steigst Du auch nach einem Jahr noch durch die Konfiguration durch, ohne dass Du jedes Mal Dein Hirn verdrehen - oder mit Wireshark Deine Pakete analysieren musst. ;-)

Und in wenigen Jahren steigst Du sowieso auf eine neue Firewall ohne RED-Funktoinen um, weil die SG demnächst eingestampft wird und XG/XGS kein nutzbares Produkt ist. Insbesondere RED-Verwaltung und Bridgen von Interfaces ist mit der XG totaler Schrott...

Bob weist ja auch darauf hin und ich kann mich da selber so richtig reinquatschen: "Keep it simple" :-)

Liebe Grüße aus Hamburg, Janbo

Vielen Dank Janbo !

Hab mir das in ein paar ruhigen Minuten nochmal durch den Kopf gehen lassen und hab den "harten Schritt" gewählt.

Die Standorte haben nun unterschiedliche interne Netze, der Tunnel ist konfiguriert und die entsprechenden Regeln sind auch angelegt. Somit klappt der Verkehr zwischen den Netzen/Standorten.

Nur einen Punkt konnte ich noch nicht abhaken:

Wenn ich von extern über SSL-VPN an einem Standort eingewählt bin, kann ich noch nicht das Netz am anderen Standort erreichen.

Obwohl ich die Netze mit in der Regel drin habe...

Kannst Du mir da bitte weiterhelfen ?

Viele Grüße Holger

Vielen Dank auch an BAlfson, super Hilfe hier im Forum !

Viele Grüße Holger

Moin

Gern.

Wie sehen die die beiden Einwahlnetze aus -> Welchen "VPN-Pool" nutzt Du in den jeweiligen Standorten?

Janbo

Hallo,

Fehler gefunden ! Unter Fernzugriff > SSL sollten bei den lokalen Netzen auch wirklich alle drin stehen...

Gruß Holger