Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    LAN hinter OpenVPN-Client nicht direkt zu erreichen

    Scheduled Pinned Locked Moved Deutsch
    3 Posts 1 Posters 3.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • O
      orcape
      last edited by

      Hi,

      ich habe seit längerer Zeit einen LAN-to-LAN OpenVPN-Tunnel zwischen einem ALIX-pfSense (Server) und einem DD-WRT-Router am laufen.
      Der Server und dessen LAN ist vom Remoten Netz aus dank "push" Eintrag problemlos zu erreichen.
      An der direkten Erreichbarkeit des DD-WRT OpenVPN-Client LAN beiß ich mir aber immer wieder die Zähne aus.
      Sowohl Route Einträge auf dem Server (auf´s remote LAN) verweisend, noch Route add Einträge haben da nichts geholfen.
      Auch alle Konfigurationsvorschläge zu Iptables bringen nichts.
      Anfangs hatte ich einen WRT54 und da sollte es wohl am NAT des Tunnels liegen.
      Jetzt habe ich einen E3000, bei dem kann das Tunnel-NAT separat abgeschaltet werden.
      Das Ergebnis ist das gleiche. Ein Zugriff per ssh vom Server ist nur über den remoten Router möglich, nicht direkt.
      Hier mal ein Thread aus der Zeit mit dem WRT54….
      http://www.dd-wrt.com/phpBB2/viewtopic.php?t=152940&highlight=
      Was ich direkt remote erreiche ist das WAN, diese IP kann ich von meinem PC der am pfSense hängt, anpingen und die IP des Tunnelendpunkts auf dem DD-WRT Router, 10.10.8.6.
      Status: OpenVPN

      server-dedalus UDP:1194 Client connections
      Common Name Real Address Virtual Address Connected Since Bytes Sent Bytes Received
      dedalus-ca 78.55.117.223:32772 10.10.8.6 Sun Nov 4 16:58:04 2012 51558 49420

      Ich tippe also auf ein Routingproblem im DD-WRT OpenVPN-Client Router.
      Die Routingtabellen sind auf dem Link zu sehen.
      Danke im vorraus für jeden Lösungsvorschlag.

      Gruß orcape

      1 Reply Last reply Reply Quote 0
      • O
        orcape
        last edited by

        Hi Leuts,

        nachdem ich weitere untaugliche Versuche zum verbinden beider Netze mit route, iroute usw. "gefahren" habe,
        auch Routing-Einträge im VPN-Client waren zwecklos, bin ich irgendwie auf die Idee gekommen aus dem /24 er Tunnelnetz ein /30 er zu machen.
        Der Eintrag im pfSense VPN-Status sieht nicht mehr so aus….

        server-dedalus UDP:1194 Client connections
        Common Name    Real Address    Virtual Address    Connected Since    Bytes Sent    Bytes Received
        dedalus-ca    78.55.117.223:32772    10.10.8.6    Sun Nov 4 16:58:04 2012    51558    49420

        sondern....

        Peer to Peer Server Instance Statistics
        Name Status Connected Since Virtual Addr Remote Host Bytes Sent Bytes Received
        server-dedalus UDP:1194 up Sat Nov 10 12:13:03 2012 10.10.8.1 92.227.158.107 8177 7526

        ....so.
        Nun funktioniert der Tunnel wie er soll. Ich erreiche das remote Netz und von Remote aus meine Netzwerkfreigaben.

        Leider weiß ich immer noch nicht, wieso das die Änderung der Netzmaske bewirken kann.
        Kann mir das vielleicht mal einer von den Profi´s erklären.  ;)

        Gruß orcape

        1 Reply Last reply Reply Quote 0
        • O
          orcape
          last edited by

          Hi,

          Thema erledigt.
          Bei den Servereinstellungen bzw. den dazugehörigen Clientzuweisungen hatte sich ein Fehler eingeschlichen.
          Dadurch wurde von der pfSense ein Tunnel mit 4 ip´s kreiert.
          10.10.8.1, 10.10.8.2 point-to-point (Server)
          10.10.8.6, 10.10.8.5 point-to-point (Client)
          Ab pfSense 2.0.1 gehört der push und iroute Befehl für das remote Netz in
          "Client Specific Override"
          Damit erstellt pfSense einen Tunnel mit 2 IP´s und das LAN-to-LAN funktioniert ohne Probleme.
          Gruß orcape

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.