8
VPN über Secure Client in doppelt vorhandenes Netz
Hallo,
ich habe folgende Problemstellung:
Über mein Gateway (Sophos XG Firewall) ist ein Netz (IPSec Site to Site VPN) angebunden.
Es handelt sich um das Netz 192.168.1.0/24 (1er Netz)
In dem Netz, in dem mein PC drin ist, habe ich keinen Zugriff auf das angebundene 1er Netz.
Mein PC hat Internetzugriff und darauf läuft ein IPSec Client, der eine Verbindung an ein anderes Netz (ebenfalls 192.168.1.0/24) herstellen soll.
Die Verbindung wird über den IPSec Client korrekt aufgebaut, nur die Geräte im angebundenen Netz erreiche ich leider nicht.
Ist das technisch so überhaupt möglich, wenn das Gateway dasselbe Netz anderweitig bereits kennt oder muss ich natten?
Danke für einen kurzen Gedankenanstoß dazu.
Beste Grüße
ich habe folgende Problemstellung:
Über mein Gateway (Sophos XG Firewall) ist ein Netz (IPSec Site to Site VPN) angebunden.
Es handelt sich um das Netz 192.168.1.0/24 (1er Netz)
In dem Netz, in dem mein PC drin ist, habe ich keinen Zugriff auf das angebundene 1er Netz.
Mein PC hat Internetzugriff und darauf läuft ein IPSec Client, der eine Verbindung an ein anderes Netz (ebenfalls 192.168.1.0/24) herstellen soll.
Die Verbindung wird über den IPSec Client korrekt aufgebaut, nur die Geräte im angebundenen Netz erreiche ich leider nicht.
Ist das technisch so überhaupt möglich, wenn das Gateway dasselbe Netz anderweitig bereits kennt oder muss ich natten?
Danke für einen kurzen Gedankenanstoß dazu.
Beste Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 53572690240
Url: https://administrator.de/contentid/53572690240
Printed on: April 27, 2024 at 10:04 o'clock
8 Comments
Latest comment
Dein Kardinalsfehler ist ein falsches oder mangelhaftes VPN IP Adressdesign im Vorfeld, weil du eins der üblichen "Allerwelts" IP Netze verwendest. Scheinbar hast du die Gefahr der Nutzung solcher Banalnetze die es millionenfach gibt laienhaft ignoriert beim VPN Setup?! Bei einem verantwortungsvollen IP Adressdesign ist sowas immer ein NoGo.
Siehe dazu auch HIER.
Dieser grobe Fehler wird dich also immer und immer wieder einholen.
Langfristig ist es besser das IP Adressdesign zu ändern für dieses Netz. Je schneller desto besser wenn deine Netze noch wachsen sollten.
Natürlich kann man das technisch mit statischem Source- und Destination NAT auf der Firewall problemlos lösen so das diese Netze für das IP Forwarding nicht mehr "gleich" sind. Das ist aber immer eine große Frickelei und macht Sinn für 1-2 Netze aber skaliert nicht.
Langfristig ist es stressfreier die Adressierung zu korrigieren. Its your choice...
Siehe dazu auch HIER.
Dieser grobe Fehler wird dich also immer und immer wieder einholen.
Langfristig ist es besser das IP Adressdesign zu ändern für dieses Netz. Je schneller desto besser wenn deine Netze noch wachsen sollten.
Natürlich kann man das technisch mit statischem Source- und Destination NAT auf der Firewall problemlos lösen so das diese Netze für das IP Forwarding nicht mehr "gleich" sind. Das ist aber immer eine große Frickelei und macht Sinn für 1-2 Netze aber skaliert nicht.
Langfristig ist es stressfreier die Adressierung zu korrigieren. Its your choice...
Moin,
Wie sagte es der Highlander schon: There can be only on /Es kann nur einen geben!
Grundregel bei Netzwerken: IP-netze, die miteinander kommunizieren, müssen disjunkt sein, d.h. es darf sich kein IP-Bereich überlappen. Von daher ist Dein vorhaben zu scheitern verurteilt, solange nicht eines der Subnetzte geändert wird.
Natürlich funktioniert diese Frickelei, ich habe es vo 20 Jahren bei einem ISP für dessen Kunden (auch für größere Adressbereiche) des öfteren durchführen müssen, aber man wird damit garantiert nicht glücklich.
Am besten einfach aus dem 172.16.0.0/12-Bereich sich ein (zufälliges) /24 aussuchen und lokal vergeben und alles wird viel einfacher.
lks
Wie sagte es der Highlander schon: There can be only on /Es kann nur einen geben!
Grundregel bei Netzwerken: IP-netze, die miteinander kommunizieren, müssen disjunkt sein, d.h. es darf sich kein IP-Bereich überlappen. Von daher ist Dein vorhaben zu scheitern verurteilt, solange nicht eines der Subnetzte geändert wird.
Zitat von @aqui:
Natürlich kann man das technisch mit statischem Source- und Destination NAT auf der Firewall problemlos lösen so das diese Netze für das IP Forwarding nicht mehr "gleich" sind. Das ist aber immer eine große Frickelei und macht Sinn für 1-2 Netze aber skaliert nicht.
Natürlich kann man das technisch mit statischem Source- und Destination NAT auf der Firewall problemlos lösen so das diese Netze für das IP Forwarding nicht mehr "gleich" sind. Das ist aber immer eine große Frickelei und macht Sinn für 1-2 Netze aber skaliert nicht.
Natürlich funktioniert diese Frickelei, ich habe es vo 20 Jahren bei einem ISP für dessen Kunden (auch für größere Adressbereiche) des öfteren durchführen müssen, aber man wird damit garantiert nicht glücklich.
Am besten einfach aus dem 172.16.0.0/12-Bereich sich ein (zufälliges) /24 aussuchen und lokal vergeben und alles wird viel einfacher.
lks
@lks
Oha, da musst du wohl nochmal dringend korrigieren...
Oha, da musst du wohl nochmal dringend korrigieren...
- YouTube Link kaputt
- "es darf sich (k)ein IP-Bereich überlappen"
Du weißt doch, dicke Finger auf Tatschtaturen.
* YouTube Link kaputt
Korrigiert
* "es darf sich (k)ein IP-Bereich überlappen"
Korrigiert.
Der Rest: Full ACK
Sind wir ja mal wieder einig.
lks
Hi,
ich muß @aqui und @Lochkartenstanzer widersprechen.
Es ist möglich daß du auf das 192.168.1.0/24 er Netz per VPN Client auf deinem PC zugreifen kannst, auch wenn ein anderes 192.168.1.0/24 Netz auf dem regulären GW definiert ist.
Wenn du einen VPN Client verwendest ist das GW für das remote Netz nicht das Standard GW (in deinem Fall die Sophos XG Firewall) sondern der VPN Client auf deinem PC.
Das Standard GW bekommt von dem anderen, in deinem Fall das Netz mit der gleichen IP Range, nichts mit.
Prüfe, bzw. poste mal die Ausgabe von route -print einmal mit VPN Client und einmal ohne VPN Client.
Mit VPN Client sollte die Route zum 192.168.1.0/24 er Netz über die IP Adresse des VPN Clients eine niedrigere Metrik haben als zu 0.0.0.0 über den Standard Gateway.
Wenn das alles in Ordnung ist liegt der Fehler woanders, z.B. Windows Firewall auf der Gegenseite.
Gruß
CH
ich muß @aqui und @Lochkartenstanzer widersprechen.
Es ist möglich daß du auf das 192.168.1.0/24 er Netz per VPN Client auf deinem PC zugreifen kannst, auch wenn ein anderes 192.168.1.0/24 Netz auf dem regulären GW definiert ist.
Wenn du einen VPN Client verwendest ist das GW für das remote Netz nicht das Standard GW (in deinem Fall die Sophos XG Firewall) sondern der VPN Client auf deinem PC.
Das Standard GW bekommt von dem anderen, in deinem Fall das Netz mit der gleichen IP Range, nichts mit.
Prüfe, bzw. poste mal die Ausgabe von route -print einmal mit VPN Client und einmal ohne VPN Client.
Mit VPN Client sollte die Route zum 192.168.1.0/24 er Netz über die IP Adresse des VPN Clients eine niedrigere Metrik haben als zu 0.0.0.0 über den Standard Gateway.
Wenn das alles in Ordnung ist liegt der Fehler woanders, z.B. Windows Firewall auf der Gegenseite.
Gruß
CH
Kollege @ChriBo hat nicht ganz Unrecht, allerdings ist das nicht die ganze Wahrheit.
Das funktioniert nur dann wenn der VPN Client ein Gateway Redirect macht, sprich bei aktiver VPN Verbindung dann ALLEN Traffic deines Clients in den Tunnel sendet.
Nur dann bekommt er von dem anderen .1.0er Netz nichts mit.
Macht man ein übliches Split Tunneling am Client, also nur relevanten Traffic in den VPN Tunnel dann scheitert das Setup weil der Client dann das .1.0er Netz über die Firewall "doppelt" sieht.
Leider macht der TO keinerlei hilfreiche Angaben zu der Thematik und man kann nur Kristallkugeln.
Das funktioniert nur dann wenn der VPN Client ein Gateway Redirect macht, sprich bei aktiver VPN Verbindung dann ALLEN Traffic deines Clients in den Tunnel sendet.
Nur dann bekommt er von dem anderen .1.0er Netz nichts mit.
Macht man ein übliches Split Tunneling am Client, also nur relevanten Traffic in den VPN Tunnel dann scheitert das Setup weil der Client dann das .1.0er Netz über die Firewall "doppelt" sieht.
Leider macht der TO keinerlei hilfreiche Angaben zu der Thematik und man kann nur Kristallkugeln.
Zitat von @ChriBo:
Hi,
ich muß @aqui und @Lochkartenstanzer widersprechen.
Es ist möglich daß du auf das 192.168.1.0/24 er Netz per VPN Client auf deinem PC zugreifen kannst, auch wenn ein anderes 192.168.1.0/24 Netz auf dem regulären GW definiert ist.
Hi,
ich muß @aqui und @Lochkartenstanzer widersprechen.
Es ist möglich daß du auf das 192.168.1.0/24 er Netz per VPN Client auf deinem PC zugreifen kannst, auch wenn ein anderes 192.168.1.0/24 Netz auf dem regulären GW definiert ist.
Keiner von uns hat das bestritten daß das möglich ist. Aber jemand der in einem Forum danach fragen muß, warum er die anderenClients bei so einem Setup nicht erreicht ist schlicht und einfach überfordert so etwas korrekt umzu setzen. Dann lieber den korrekten Weg gehen und die Netzwerke ändern.
lks
Zitat von @ChriBo:
Mit VPN Client sollte die Route zum 192.168.1.0/24 er Netz über die IP Adresse des VPN Clients eine niedrigere Metrik haben als zu 0.0.0.0 über den Standard Gateway.
Mit VPN Client sollte die Route zum 192.168.1.0/24 er Netz über die IP Adresse des VPN Clients eine niedrigere Metrik haben als zu 0.0.0.0 über den Standard Gateway.
Danke für alle Antworten - natürlich ist das IP-Adressdesign hier nicht sonderlich günstig. Das weiß ich. Ich benötige hier auch nur äußerst selten einen Zugriff auf diesem Weg.
Aber zum eigentlichen Problem:
Ich konnte nun die Verbindung herstellen, indem ich einen anderen VPN Client verwendet habe. Die Metrik ist für das 192.168.1.0/24 Netz über die IP des VPN Clients in dem funktionstüchtigen Fall niedriger, als die 0.0.0.0 Verbindung, danke für den Anstoß - wieder etwas gelernt.
Mit dem kostenpflichtigen bintec elmeg secure Client war der Zugriff trotz stehender Verbindung nicht möglich - mit dem kostenfreien VPN Access Manager von Shrew Soft funktioniert es sofort. Problem ist damit geklärt.