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

    pfSense Multi-Path Route mit Metric Support – Alternative?

    Scheduled Pinned Locked Moved Deutsch
    6 Posts 3 Posters 769 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.
    • john.wickJ
      john.wick
      last edited by john.wick

      Hallo zusammen,

      ich sitze gerade an einer neuen Netzwerk-Topologie mit Einsatz von pfSense Endpunkten und einer SonicWall. In meinem beigefügten Diagramm wird dargestellt, was ich machen möchte.

      • Client A und Client B möchten miteinander sprechen.
      • Die SonicWall kennt zwei statische Routen von Subnet 10.0.3.0/24 nach 10.0.2.0/24.
      • Die pfSense C kennt aber nur eine statische Route von Subnet 10.0.2.0/24 nach 10.0.3.0/24.
      • Eine zweite statische Route (rot markiert) zu Subnet 10.0.3.0/24 lässt sich in der pfSense C nicht konfigurieren.
      • Selbes Problem bei den pfSense A und B. Notwendige Routen sind rot markiert.

      Mit einer SonicWall kann ich ein und dasselbe Destination Network über mehrere statische Routen (Multi-Path Route) angeben. Ausfallsicherheit! Leider gelingt mir das mit der pfSense nicht. Dazu habe ich auch das Redmine Ticket #1521 gefunden. Daraus schließe ich, dass ich mit einer pfSense kein statisches Multi-Path Routing mit Einsatz von Metrics konfigurieren kann.

      1. Kann das bitte jemand bestätigen?
      2. Kann mir bitte jemand einen Tipp geben, wie ich das statische Multi-Path Routing z.B. mit Einsatz eines Routing-Protokolls umgehen kann?

      VPN pfSense static routing.jpg

      Vielen lieben Dank,
      John

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        Hallo,

        ist leider so.

        Als Alternative bietet pfSense Gateway-Gruppen (System > Routing > Gateway Groups).
        Du kannst bspw. auf pfSense A die beiden Gateways 10.0.3.1 und 10.0.1.2 einer GW-Gruppe hinzufügen (GW müssen bereits erstellt sein). Dem GW mit der höheren Prio gibst du die niedrigere Tier#. Unter "Trigger Level" kannst du auswählen, unter welchen Umständen auf die nächst höhere Tier umgeschaltet wird.
        Auf diese GW-Gruppe kannst du dann die statische Route für 10.0.3.0/24 setzen.

        Grüße

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

          Das Redmine Ticket ist aber auch steinalt. Da gibt es neuere zu, die das ggf. belegen. Wenn es nur um Ausfallsicherheit geht, dann ist @viragomann da völlig richtig, einfach mit einer Gateway Gruppe machen.

          Ansonsten bin ich mir an Hand deines Diagramms unschlüssig ob das lediglich Failover oder wirklich Multipath Routing sein soll. Egal was, das FRR Package bekommt Multipath Support, in den 2.5-dev Snapshots bereits testweise aktiv.

          Siehe
          https://redmine.pfsense.org/issues/9544
          https://redmine.pfsense.org/issues/9545

          Wenn es um echtes MPTCP geht, da ist bislang der Blocker in Upstream/FreeBSD:
          https://redmine.pfsense.org/issues/4632

          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
          • john.wickJ
            john.wick
            last edited by john.wick

            Hi, Danke für eure Antworten.

            Die Gateway Groups hatte ich auch schon im Blick.

            Habe auch eine angelegt.

            Screen_Shot 2020-03-12 at 16.59.20.png

            Leider taucht die neue Gateway Group in der Liste aller Gateways nicht auf.

            Screen_Shot 2020-03-12 at 16.59.41.png

            Muss ich noch etwas beachten?

            PS: Failover ist vorerst ausreichend.

            1 Reply Last reply Reply Quote 0
            • V
              viragomann
              last edited by

              Ja, Gateway-Groups sind in statischen Routen nicht verfügbar.
              Da musst du nun Policy Routing verwenden. D.h. du definierst eine Firewall-Regel für den Traffic, der auf den jeweiligen Interfaces nach 10.0.3.0/24 erlaubt ist (10.0.3.0/24 als Ziel angeben). In der Regel musst du die Advanced Options erweitern und bei Gateway dir GW-Group auswählen.

              Bezüglich dem Failover: Soweit ich weiß, muss hierfür das GW-Monitoring aktiviert sein. Und monitoren musst du hier sinniger Weise eine IP im Zielnetz 10.0.3.0/24. Du hättest nichts davon, wenn das GW selbst gemonitort wird, also bspw. die pfSense B IP, die VPN zwischen B und der SonicWall aber nicht besteht.
              Also einfach bei jedem GW eine IP fürs Monitoring im Zielnetz auswählen, die auf Ping antwortet. Der Ping wird dann über das jeweilige GW geroutet. D.h. bedeutet natürlich auch, dass die Monitoring-IPs für die Gateways nicht die gleichen sein dürfen.

              1 Reply Last reply Reply Quote 0
              • john.wickJ
                john.wick
                last edited by

                Danke @viragomann, Du hast mir sehr geholfen. 👍

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