[erledigt]OpenVPN gibt kein Gateway an die Clients?



  • OpenVPN habe ich am Laufen. Die Clients können über die CARP-Sensen auf das Lokale Netzwer, dort die Rechner sehen und zugreifen.

    Für einen Client möchte ich aber gerne, dass der gesamte Trafic über den Tunel geht. Auch das, was ins Internet weiter geht.
    Wenn ich die entsprechende Option beim Client-Export angebe "Redirect Gateway / Force all client generated traffic through the tunnel. "
    Kann der Client gar nicht mehr in's Internet. OpenVPN vergibt zwar eine IP aus dem Tunnel-Netz, aber kein Gateway. Auf Windows-Clients ist das Netwerk dann automatisch öffentlich, die Firewall macht ziemlich dicht …

    Wo konfiguriert man den DHCP für den OpenVPN? Wie krieg ich das Gateway da rein?

    Ich hab versucht ein Interface für den Tunnel anzulegen (Adapter "ovpns1") und den dazu gehörenden DHCP zu aktivieren. Der behauptet dann aber, dass die Gateway-Adresse nicht im passenden Subnetz läge (obwohl alles in dem Tunnel 10.10.90.0/24 Adressen sind, auch das Gateway) und wird angehalten.

    Hab das nach dem Schema gemacht, nach dem auch das LAN aufgebaut ist:
    Sense 1: 10.10.90.235/24
    Sense 2: 10.10.90.254/24
    vIP: 10.10.90.252

    Aber vermutlich beißt sich der DHCP mit dem Gegenstück von OpenVPN?

    Für mich wäre es nicht wirklich akzeptabel jetzt die IP, DNS und Gateway von Hand auf dem Client einzutragen ...

    PS: http://serverfault.com/questions/398951/openvpn-connection-works-but-no-gateway-is-assigned
    Das wäre eine Lösung für Linux ... ist das auf der Sense genau so über die Konsole zu machen? Am liebsten wäre mir natürlich eine Lösung über das Webinterface ... sonst kann es wieder keine außer mir nachvollziehen.



  • Warum willst du einen DHCP? Das macht doch ohnehin der OVPN Server.
    Wenn du einem Client eine bestimmte IP verpassen möchtest, kannst du das mittles "Client Specific Overrides" bewerkstelligen.

    Wenn es Probleme mit "Redirect Gateway" gibt und der Client nichts ins Internet kann, hat das seine Ursache oft im Outbound NAT. Nachdem der VPN Server eingerichtet ist, mal auf NAT > Outbound gehen und da auf "Save" klicken. Die richtigen Regeln werden meist automatisch angelegt. Wenn nicht, muss man sie händisch hinzufügen.



  • Warum willst du einen DHCP? Das macht doch ohnehin der OVPN Server.
    Wenn du einem Client eine bestimmte IP verpassen möchtest, kannst du das mittles "Client Specific Overrides" bewerkstelligen.

    Das finde ich schade, mir wäre es lieber gewesen, das über den gleichen Weg zu machen, wie für's LAN, aber ok… kann ich erst mal mit leben.

    Wenn es Probleme mit "Redirect Gateway" gibt und der Client nichts ins Internet kann, hat das seine Ursache oft im Outbound NAT. Nachdem der VPN Server eingerichtet ist, mal auf NAT > Outbound gehen und da auf "Save" klicken. Die richtigen Regeln werden meist automatisch angelegt. Wenn nicht, muss man sie händisch hinzufügen.

    Die automatischen NAT-Outbound-Regeln machen leider keinen Sinn bei CARP … anstelle der Virtuellen IP des entsprechenden Interface schreibt der da immer nur die IP des grade aktiven Nodes rein. Da man das nicht mal nachträglich ändern kann, muss ich die von Hand anlegen.

    Aber sobald ich "Redirect Gateway" anhake ist der Client nach dem Connect nur noch in einem "öffentlichen/unbekantes Netzwerk" und hat kein Gateway.

    gruß



  • @bitboy0:

    Die automatischen NAT-Outbound-Regeln machen leider keinen Sinn bei CARP … anstelle der Virtuellen IP des entsprechenden Interface schreibt der da immer nur die IP des grade aktiven Nodes rein. Da man das nicht mal nachträglich ändern kann, muss ich die von Hand anlegen.

    Dann muss die NAT-IP in der Regel eben von Hand geändert werden. Ohne wird es aber nicht klappen.

    @bitboy0:

    Aber sobald ich "Redirect Gateway" anhake ist der Client nach dem Connect nur noch in einem "öffentlichen/unbekantes Netzwerk" und hat kein Gateway.

    Was  heißt "kein Gateway"?
    Der VPN Server ist dein Gateway und du bekommst eine Route gesetzt, die den gesamten IP-Bereich über dieses lenkt, oder etwa nicht?

    Wenn nicht, gib mal deine Routing-Tabelle und etwas mehr von deiner Netzwerk- u. OVPN-Konfiguration bekannt.



  • Kein Gateway heißt: der Client hat:

    • eine IP
    • natürlich die Subnetmaske
    • den DNS

    Aber bei Gateway steht NICHTS … Ohne einen Eintrag bei "DNS" macht Windows die Firewall zu und sagt "keine Internetverbindung"
    Wenn "Redirect Gateway" nicht angehakt ist steht als Netzwerk-Typ bei Windows dann "Domänen-Netzwerk", aber auch da ist der IPV4-Gateway-Eintrag im Client einfach nicht gesetzt.

    Es gibt natürlich Routen ... wie müsste eine Route aussehen, die den ganzen IP-Trafic über den TUN und Sense ins Netz schickt?
    bei dem TUN-Interface steht jedenfalls stoisch "Keine Internetverbindung" in der Netzwerkübersicht bei Windows.

    Thats all!



  • das kein gateway bei der OpenVPN Verbindung gesetzt wird ist normal so weit ich weiß

    es sollte aber eine Route gesetzt werden die dann für das ziel 0.0.0.0 mask 0.0.0.0 deinen OpenVPN Server hat.
    sollte das schon so sein liegt es wohl am Outbound Nat sprich kommt alles bei der PfSense an die weiß aber nicht mit welcher IP es raus soll.

    Hast du denn bei Outbound NAT schon dein OpenVPN Netz eingetragen? musst du dann ja genauso behandeln wie ein loakles Netz.



  • Ich check das alles noch mal durch … komme heute aber nicht mehr dazu.

    Also

    • Outbound ist eingetragen
    • Gateway ist unnötig weil eine Route angelegt werden sollte, die eh vorrang hat.

    Vielleicht hab ich mich irgendwo selber reingelegt...

    ich melde mich, Danke schon mal!

    gruß



  • Also wieder was gelernt …

    Irgendwo in den Rules oder NAT hatte ich was falsch. Nachdem ich es nicht finden konnte, hab ich alle Regeln diesbezüglich noch mal gelöscht und neu angelegt.
    Jetzt geht es! Das der VPN-Client auf dem PC neue Routen einträgt und somit ein Gateway nicht bei den IPV4-Settings auftauchen muss, war mir bisher auch nicht klar.

    Danke für die Hilfe!

    gruß



  • bei den  IPV4-Settings taucht ja nicht irgendein Gateway sondern das Default Gateway.
    Und da gehts ja schon los das sollte es ja nur einmal geben. Das sieht Windows aber anders ;) wenn man zwei Netzwerkkarten hat kann es schon mal sein das es auf beiden ein Default Gateway gibt. Dann entscheidet halt die Metrik was aber auch nicht immer richtig sein muss. Daher ist es besser und sauberer finde ich das über Route zu lösen und so macht es OpenVPN dann ja auch.

    Schön das es nun geht


  • LAYER 8 Moderator

    Das der VPN-Client auf dem PC neue Routen einträgt und somit ein Gateway nicht bei den IPV4-Settings auftauchen muss, war mir bisher auch nicht klar.

    Das liegt wohl zum Teil dran, wie flix87 schon schreibt, dass VPN Clients (oder Tunnel-Tools) selten bis gar nie das Default Gateway anfassen. Denn das würde in jedem Fall immer zu einem kurzen Konnektivitätsverlust führen und das ist für den ein oder anderen nicht hinnehmbar. Zudem soll ja (meistens) interner Traffic weiterlaufen und gerade in größeren Systemumgebungen sind das auch mal mehrere private Netze, die man nicht einfach absäbeln kann. Deshalb wird das meistens mit einem Route Push erledigt. Das hatte damals schon in Windows oft dazu geführt, dass man OpenVPN bspw. als Admin starten musste, da ein normaler User keine Netzwerkroute ändern kann.

    @flix87: Dass es bei mehreren NICs aber mehrere (Default) GWs geben kann oder gibt, ist aber nicht nur Windows-originär. Das trifft man unter UNIX/Linux genauso an, wenn man mehrere Gateways setzt. Wichtig ist dann aber die abgehende Adresse von der ein Paket kommt, dann wird das DefaultGW des entsprechenden Interfaces benutzt. Und dann gibts da ja noch multiple Routing Tables… grusel ;) Aber du hast insofern recht, dass es Windows an der Stelle wohl mehr verwirrt und zu manchmal seltsamen Phänomenen führt, als die anderen OSe. :)



  • @bitboy0
    Die Routen werden nur gesetzt, wenn das irgendwo konfiguriert ist. Zumeist wird es am Server konfiguriert mit den "Local Network/s" bzw. mit "Redirect Gateway", dann bekommt der Client die Routen per push-Kommando gesetzt. Es kann aber auch unabhängig von der Server-Konfiguration direkt am Client konfiguriert werden.

    @flix87
    Der Sinn des setzen von Routen ist, dass nicht zwangsweise der gesamte Traffic über die VPN muss sondern nur bestimmte Netzbereiche. Wenn ich mich zu Wartungszwecken in ein Netz verbinde, benötige ich die VPN nur, um dieses Netz zu erreichen und möchte nicht Audiostreams oder sonstiges Übel über die VPN schicken.


Log in to reply