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

    OPENVPN TAB Site2Site und Mobile IKEv2

    Scheduled Pinned Locked Moved Deutsch
    4 Posts 2 Posters 480 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.
    • P
      pressakey
      last edited by

      Moin,

      habe folgende config

      Ein Site2Site OPENVPN TAB Layer 2 (kein TUN!!!) welches 192.168.99.0/24 über 192.168.11.0/30 verbindet ->Funktioniert, beide Seiten könne sich sehen.

      Auf der Serverseite ist noch ein Mobile IPSEC IKEv2 in das man über 10.0.0.0/24 Zugriff auf 192.168.99.0/24 bekommt.

      Wenn ich mich nun über das IPSEC einwähle komme ich nur auf die Serverseite, aber nicht auf die Client-Seite des OPENVPN.

      Normalerweise würde ich jetzt im OPENVPN bei Remotenetzwerke noch die 10.0.0.0 eintragen, aber das scheint bei TAB Layer2 nicht zu funktionieren.

      Was kann ich tun? ...ausser alles auf tun layer3 zu ändern :-)

      JeGrJ 1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator @pressakey
        last edited by

        @pressakey Hi,

        zuerst ist es TAP und nicht Tab. :)

        Dann stellt sich die Frage wenn überhaupt auf einer Seite schon mehrere Sachen geroutet werden, warum dann überhaupt der Versuch ein Layer2 Bridging via VPN zu machen mit TAP statt einfach nen stinknormalen Tunnel? Was bringt es ein? Wofür muss es das tun?

        Ansonsten wird es sehr wahrscheinlich schlichtweg dran liegen, dass Geräte per Einwahl in einem Transfernetz auf der anderen Bridge Seite schlicht nicht gesehen werden. Wie auch, sie haben dort ja keinen ARP und nichts und keiner bekommt was vom 10er Netz mit. Der Einzige Versuch könnte sein, auf der Client Seite eine Route für das 10er Netz einzutragen und es auf die Adresse der pfSense auf der anderen Seite zeigen zu lassen damit wenigstens die Chance besteht, dass die Pakete zu der richtigen Seite und Quelle geschickt werden.

        Davon abgesehen würde ich heute in der Praxis eigentlich keinen TAP/Bridge Tunnel mehr bauen wenn nicht wirklich verdammt gute Gründe dafür sprechen. Und das normale Argument "wir haben halt auf beiden Seiten die gleichen IPs" zählt dafür überhaupt nicht. Dafür gibts 1:1 Subnet Mapping wenn das unbedingt sein muss :)

        Cheers

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        P 1 Reply Last reply Reply Quote 1
        • P
          pressakey @JeGr
          last edited by pressakey

          @jegr Moin,

          danke für die Antwort.

          Ja- das leidige Thema wieso so und nicht anders und überhaupt. Selbstverständlich habe ich gute Gründe für das TAB: Politik und der üblich vergleich: Wer hat den Größten? ;-) Und so bekomme ich meine Vorgaben. :-)))

          Aber Spaß bei Seite: Meine Befürchtung war, das es schon am Übergang zwischen IPSEC und OPENVPN hängt und ich habe versucht schon auf der Serverseite zu Routen und hab mich da verrannt weil ich es unbedingt auf dieser Seite lösen wollte. Aber du lagst völlig richtig. Eine einfache Route auf der Clientseite löste das Probelm. Danke!

          JeGrJ 1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator @pressakey
            last edited by

            @pressakey Schön dass es geklappt hat.

            Trotzdem gibt es für mich keinen sinnvollen bzw logischen Grund heute Bridge Tap Tunnel so zu nutzen oder zu bauen. Die Gründe würden mich da interessieren. und mit längsten hat das nichts zu tun sondern mit sauberem Netz und Debugging sowie ARP und L2 was dadurch nicht gegeben ist. Da braucht man schon sehr gute Gründe.

            Cheers

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

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