VPN Einwahl bei Nutzung zwei gleichen Netzwerken?



  • Hallo Team,

    ich habe ein Netzwerk (Serverseitig) mit IP Adressenbereich 192.168.2.x/24. Das Transportnetzwerk ist ein 172.10.17.x/24. Mein Prolem ist jetzt aber, dass mein Clientnetzwerk ebenfalls den Adressbereich 192.168.2.x/24 verwendet. Nun sind Geräte aus dem Remotenetzwerk nicht erreichbar. (das hat schon einmal funktioniert). Wenn ich auf der pfSense konfiguriere, dass ich alles an traffic durch den Tunnel schicken möchte, ändert das nichts an dem Verhalten. Ich weiß, dass Ziel und Quellnetzwerk nicht gleich sein sollen, da es beim Routing Probleme geben kann.

    Aber den Adressbereich des Kundennetzwerks kann man sich leider nicht immer aussuchen - und ich selbst will auch nicht immer umstellen müssen.
    Gibt es denn eine Möglichkeit das Problem zu beheben?
    Wenn ich mit dem Kundennetzwerk verbunden bin, brauche ich keine Verbindung zu meinen eigenen Geräten im LAN. Eigentlich sollte JEDER Traffic durch den Tunnel geschickt werden.

    Ich freue mich auf eure Antworten,

    liebe Grüße,
    Christian



  • Hallo!

    Die beste Lösungsmöglichkeit ist gewiss ein weniger verbreitetes Netzwerk zu verwenden.

    Wenn das nicht in Frage kommt und die Clients im eigenen Netz für den Zeitraum der VPN nicht erreicht werden müssen, kannst du dir eine statische Route für das Remote-Netz setzen.

    Um welche Art VPN geht es da? Dazu hast du keine Angaben gemacht, aber genau das ist das Thema.
    Server?
    Client?
    Wer verwaltet den Server?

    Wenn man mehr weiß, kann man auch mehr od. bessere Antworten geben.



  • Hallo,

    danke für die schnelle Antwort.
    Es handelt sich um ein VPN zwischen Client und Server. (sofern ich deine Frage richtig verstanden habe?)
    Mein Kunde soll sich aus Privaten Netzwerken bei sich in der Firma einwählen können, wenn er mit seinem Notebook unterwegs ist. Da er dort auch das Netzwerk nicht beeinflussen kann, wenn er zb. in einem Hotel ist, ist die Lösung der Verwendung eines nicht so verbreiteten Netzwerks nicht möglich.
    Die Geräte im eigenen Netzwerk (Clientseitig) müssen nicht mehr erreicht werden können. Eine Statische Route sollte somit reichen - ich bin relativ neu in diesem Bereich.

    Wie/Wo und vor allem Was ist dafür einzustellen?

    liebe Grüße,
    Christian



  • Um welche Art VPN geht es da? Dazu hast du keine Angaben gemacht, aber genau das ist das Thema.
    Server?
    Client?
    Wer verwaltet den Server?

    Server: OpenVPN, PPTP, IPSec?

    Die Fragen habe ich gestellt, weil unterschiedliche VPN Lösungen das Routing unterschiedlich handhaben.
    Es gibt welche, bei denen das Setzen der Routen vorgesehen ist und die Routen am Server konfiguriert werden können. Es gibt Clients, die bei Verbindung Routen auch unabhängig vom Server Setting setzen können.

    Unabhängig davon kann man sich die Routen auch im Betriebssystem des Client Rechners setzen.

    Okay, nachdem keine Detailangaben kommen, rate ich weiter: Du hast pfSense erwähnt und dass du konfiguriert hast, den ganzen Traffic über den Tunnel zu routen. Daraus schließe ich auf OpenVPN. Das ist zwar die meist verwendete aber nicht die einzige VPN Lösung auf pfSense.
    Wenn ich richtig liege, dann nimm den Haken bei Redirect Gateway wieder weg, dann bekommst du unmittelbar darunter 2 Felder für lokale Netze f. IPv4 u. v6. Trag bei IPv4 dein lokales Netz 192.168.2.0/24 ein, dann wird es funktionieren. Mit lokal ist übrigens serverseitig gemeint.
    Für alles was du da einträgst wird am Client, sofern dieser push route beherrscht, eine Route gesetzt.



  • Achso! sorry - mein Fehler. Du liegst richtig - es handelt sich um OpenVPN.
    Ich werde die Variante mal versuchen. Interessant ist, dass das schon mal funktioniert hat - ich habs dann offensichtlich bei der Fehlersuche wegen einem anderen Problem wieder "Kaputtrepariert".
    Ich schau mir das die nächsten Tage an und melde mich nochmal!

    vielen Dank erstmal!

    lg. Christian


  • Moderator

    Also beim beschriebenen Roadwarrior Szenario (Kunde mit Notebook möchte in sein Firmennetzwerk) sollte das ganz unabhängig des lokal verwendeten Netzes klappen, in dem der Client das Default GW auf den Tunnel gesetzt bekommt und entsprechend das LAN des Firmennetzes als Route gepusht wird. Das ist gar keine große Sache.

    Schwierig wird eher eine LAN-LAN-Kopplung in welcher beide Seiten die gleichen Netze verwenden. Das ist meistens nur über unschöne/häßliche NATtings zu Regeln, bei denen die Geräte dann beim Tunneln umgeschrieben werden.

    Grüße



  • Also beim beschriebenen Roadwarrior Szenario (Kunde mit Notebook möchte in sein Firmennetzwerk) sollte das ganz unabhängig des lokal verwendeten Netzes klappen, in dem der Client das Default GW auf den Tunnel gesetzt bekommt

    Das Default GW wirkt sich nicht auf das Routing eines konfigurierten Netzwerks auf einem Interface aus. Ein Rechner routet eine IP, die zu einem Subnetz eines drauf eingerichtet Netzwerkinterfaces gehört, immer über dieses Interface.
    Mit eine statischen Route kann man das aber ändern.


  • Moderator

    Natürlich wirkt es sich nicht aus wenn das Netz lokal erreichbar ist. Trotzdem kann es mit präziserer Maske überschrieben werden. Spezifischer sticht allgemeiner. Da muss ich ggf. nicht mal mit statischer Route kommen, es genügt schon - je nach Anwendungsfall - wenn der OpenVPN Server ggf. die paar Server pusht (als /32) auf die ich zugreifen muss/will. Dazu kommt, dass häufig in großen WLAN Installationen gerne auch mal Netze größer /24 vergeben werden, womit dann auch ein Problemfall wegfallen kann.

    Trotzdem muss ich cyberexpress widersprechen:
    "Da er dort auch das Netzwerk nicht beeinflussen kann, wenn er zb. in einem Hotel ist, ist die Lösung der Verwendung eines nicht so verbreiteten Netzwerks nicht möglich."
    Das stimmt so nicht. Natürlich kann er vor Ort das Netz nicht beeinflussen, trotzdem kann man dem Problem eher aus dem Weg gehen, wenn man nicht gerade die 5-10 meistgenutzten LAN Netze bei sich einsetzt, was geradezu nach Problemen schreit, wenn man VPNs aufbaut. Also bspw.

    • 192.168.{0,1,100,168,178,200,254,255}.0/24
    • 10.{0-10}.{0-10}.0/24

    Häufig sind es genau die, die Probleme machen.



  • Hallo Viragomann,

    Wenn ich richtig liege, dann nimm den Haken bei Redirect Gateway wieder weg, dann bekommst du unmittelbar darunter 2 Felder für lokale Netze f. IPv4 u. v6. Trag bei IPv4 dein lokales Netz 192.168.2.0/24 ein, dann wird es funktionieren. Mit lokal ist übrigens serverseitig gemeint.

    Leider funktioniert das bei mir nicht.

    Ich habe jetzt folgende Einstellungen:

    IPv4 Tunnel Network: 172.16.0.0/24
    Redirect Gateway (Haken raus)
    IPv4 Local Network/s: 192.168.2.0/24    (das ist auch das Netzwerk wo die Geräte stehen, die ich erreichen möchte - mein Clientnetzwerk hat den gleichen Bereich)

    Anbei noch ein Screenshot der aktuellen Routingtabelle.
    Hast du noch eine Idee?

    lg. Christian




  • Hi!

    Da hast du die Route nicht gesetzt bekommen. Es steht alles auf "Auf Verbindung", d.h. es geht nicht über ein spezielles Gateway.
    Unter Gateway müsste dein VPN-GW aufscheinen. Wenn du DHCP verwendest ist das normalerweise deine IP - 1 od. eben der DHCP-Sever, der bei "ipconfig /all" für den VPN-Adapter angezeigt wird.

    Ein Grund für das Problem sehe ich allerdings auch nicht.

    Was verwendest du für einen Client?
    Mit dem von OpenSSL, dem man über das Client Export Tool bekommt, funktioniert es bei mir und Kollegen anstandslos.

    Der Client muss aber mit Admin-Rechten gestartet werden, damit es geht. Das wollte meiner aber ohnehin von Beginn an so.

    Ansonsten, vergewissere dich, dass am OVPN-Server unter Client Settings der Haken bei "Address Pool" gesetzt und der darunter bei Topology nicht gesetzt ist, wenn er nicht unbedingt benötigt wird.

    Ob das push_route Kommando gesendet wird, ist übrigens auch am Server im OVPN Log zu sehen. Sieht bei mir so aus:

    send_push_reply(): safe_cap=940

    bzw. am Client wird das geloggt:

    ADD_ROUTES

    Sollte nichts helfen, würde ich mich nach einem anderen Client umsehen, oder erst mal den aktuellen neu installieren / updaten.
    Auf meinem Network Manager in Linux bspw. kann ich die gewünschten Routen auch manuell einstellen. Diese werden dann bei Verbindungsaufbau gesetzt und beim Trennen wieder gelöscht. Ich nehme an, dass das auch manche Windows Clients können.

    Allerletzter Ausweg: Route manuell setzen:
    In der cmd mit Admin-Rechten:

    route add 192.168.2.0 mask 255.255.255.0 172.16.0.1
    

    Das am Ende ist deine VPN-GW IP wie oben beschrieben. Gilt für diesen Fall, dass deine IP wie im Screeshot 172.16.0.2 ist.
    Da fällt mir auf, das ist untypisch für IP Pools b. aktuellen OVPN-Server. Bei mir ist die erste IP, die vergeben wird, die 6. Ev. fehlt o.g. Haken. Bitte unbedingt checken.
    Route löschen:

    route delete 192.168.2.0
    

    Wie JeGr erwähnt hat, könnte es auch Sinn machen, Routen für einzelne Hosts zu setzen anstatt fürs gesamte Subnetz. Dann eben bspw. 192.168.2.26 und mask 255.255.255.255 verwenden. Auch am Server mögl. durch Eingabe v. 192.168.2.26/32. Wenn mehrere, durch Kommata trennen.
    Auf der Windows CMD können auch mehrere Routen gesetzt werden und wenn es IPs sind, die im eigenen Netz ohnehin nicht existieren, kann man die Routen auch permanent in die Registry eintragen. Dazu vor add die Option "-p" einfügen.
    Aber Vorsicht: Bei Netzerweiterung könnte einem das dann am Kopf fallen.

    Meine Empfehlung ist immer noch mein erstes Komment in meinem ersten Posting oben.

    Na dann, gutes Gelingen.



  • Hallo,

    super Sache! Das wars!

    Ansonsten, vergewissere dich, dass am OVPN-Server unter Client Settings der Haken bei "Address Pool" gesetzt und der darunter bei Topology nicht gesetzt ist, wenn er nicht unbedingt benötigt wird.

    Genauergesagt war der Topology Haken gesetzt. (ich weiß nicht genau, was ich damit jetzt gemacht habe) aber es funktioniert jetzt Einwandfrei!

    zu deiner Frage: Ja - ich verwende den normalen client, den ich übüer client-export im Bereich "openVPN" exportieren kann.

    Vielen Dank für die Unterstützung!

    lg. Christian