Navigation

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

    Multi Wan Port Forwarding

    Deutsch
    2
    5
    2089
    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.
    • M
      Marv21 last edited by

      Hallo miteinander,
      Mein Netzwerk sieht so aus

      WAN 1  DSL->Fritzbox->PFsense
      WAN 2  Cable->Pfsense (Default Gateway)
      LAN    PFsense ->LAN

      Ich würde gerne, wenn jemand über die IP von WAN1 zum Port 1234 das er nach einer internen IP Adresse weitergereicht wird.
      Dazu habe ich eine Portforwardregel hinzugefügt. Die Funktioniert auch super solande WAN1 das Default Gateway ist. Sobald aber WAN2 das Default ist, funktioniert es nicht mehr.
      Meine Vermutung ist das der Traffic bei WAN1 reinkommt und versucht über WAN2 wieder rauszukommen.
      Kann ich das irgendwie ändern?

      OpenVPN funktioniert ohne Probleme, wenn ich über die WAN1 Verbindung mich verbinde.

      2. Frage
      Wenn ich Versuche während das Default Gateway Wan2 ist eine VPN Verbindung mit dem OpenVPn auf WAN1 zu erstellen, geht es nicht, warum?
      Ist es nicht das gleiche als wenn ich von außen komme?
      WAN2 raus->Internetwelt->WAN1 rein?

      Hoffe ihr könnt mir helfen:/

      1 Reply Last reply Reply Quote 0
      • M
        Marv21 last edited by

        Ich brauche so etwas wie eine reply-to Rule, wie leg ich sowas an? Wieso geschiet das nicht automatisch?

        HILFE

        1 Reply Last reply Reply Quote 0
        • M
          Marv21 last edited by

          Habe nun eine Regel unter dem LanInterface erstellt, welche den Traffic des betreffenden Ports immer über das richtige Gateway laufen lässt.
          Nachteile daran:

          • Mehr Aufwand
          • Port ist immer nur von einem WAN erreichbar :/
          1 Reply Last reply Reply Quote 0
          • JeGr
            JeGr LAYER 8 Moderator last edited by

            Es gibt keine "reply-to" Rule. Traffic, der eingeht, wird auch entsprechend der incoming-Rule ins LAN gelassen. Wenn dort dann das default GW ein anderes als das eingehende Interface ist, ist es klar, dass der Traffic auf der Rückreise falsch abbiegt.

            Möglichkeit 1 hast du bereits selbst gefunden, eine Regel für den entsprechenden Endpunkt im LAN zu erstellen (Quelle) und dann als Gateway das andere Interface, wo der Traffic herkommt. Natürlich ist der Port dann nur über ein WAN erreichbar, aber du hast auch oben geschrieben, dass dein Forwarding auch nur auf WAN1 eingerichtet ist. Wo ist also das Problem?

            Möglichkeit 2: ein 1:1 NAT anlegen, dann wird auch der Rücktraffic natürlich wieder dorthin geroutet, wo er herkam. Das willst du aber wahrscheinlich nicht, da beim 1:1 NAT alle Ports bzw. die komplette externe IP von WAN1 dann auf die interne Adresse geschickt wird.

            Ansonsten wäre es praktisch wenn du genauer sagen würdest was du zu tun gedenkst. Meines Erachtens hast du bereits das erreicht, was du im ersten Post beschreibst. Einkommende Anfragen auf 1234 auf WAN1 sollen auf Interne IP X Port Y weitergereicht werden. Dann braucht es auf dem LAN eben eine Regel die Verkehr von X/Y abgehend wieder statisch auf WAN1 herausroutet, statt auf das Default GW.

            Wenn das egal auf welchem WAN klappen soll, fehlt dir eh die Grundvoraussetzung: nämlich ein dynamisches Gateway (Failover Pool), welches ein favorisiertes Interface hat (bspw. WAN1) und im Falle dessen Niederganges statt dessen auf das andere WAN routet. Gleichso muss eben auch das Portforwarding auf beiden WANs eingerichtet sein, ansonsten macht es keinen Sinn.

            Grüße
            JeG

            1 Reply Last reply Reply Quote 0
            • M
              Marv21 last edited by

              @JeG:

              Es gibt keine "reply-to" Rule. Traffic, der eingeht, wird auch entsprechend der incoming-Rule ins LAN gelassen. Wenn dort dann das default GW ein anderes als das eingehende Interface ist, ist es klar, dass der Traffic auf der Rückreise falsch abbiegt.

              Möglichkeit 1 hast du bereits selbst gefunden, eine Regel für den entsprechenden Endpunkt im LAN zu erstellen (Quelle) und dann als Gateway das andere Interface, wo der Traffic herkommt. Natürlich ist der Port dann nur über ein WAN erreichbar, aber du hast auch oben geschrieben, dass dein Forwarding auch nur auf WAN1 eingerichtet ist. Wo ist also das Problem?

              Möglichkeit 2: ein 1:1 NAT anlegen, dann wird auch der Rücktraffic natürlich wieder dorthin geroutet, wo er herkam. Das willst du aber wahrscheinlich nicht, da beim 1:1 NAT alle Ports bzw. die komplette externe IP von WAN1 dann auf die interne Adresse geschickt wird.

              Ansonsten wäre es praktisch wenn du genauer sagen würdest was du zu tun gedenkst. Meines Erachtens hast du bereits das erreicht, was du im ersten Post beschreibst. Einkommende Anfragen auf 1234 auf WAN1 sollen auf Interne IP X Port Y weitergereicht werden. Dann braucht es auf dem LAN eben eine Regel die Verkehr von X/Y abgehend wieder statisch auf WAN1 herausroutet, statt auf das Default GW.

              Wenn das egal auf welchem WAN klappen soll, fehlt dir eh die Grundvoraussetzung: nämlich ein dynamisches Gateway (Failover Pool), welches ein favorisiertes Interface hat (bspw. WAN1) und im Falle dessen Niederganges statt dessen auf das andere WAN routet. Gleichso muss eben auch das Portforwarding auf beiden WANs eingerichtet sein, ansonsten macht es keinen Sinn.

              Grüße
              JeG

              Danke für deine Antwort:

              Sorry wenn ich das so sage aber deine Antwort ist leider Blödsinn.
              Anscheinend gibt es inmoment einen Bug in Pfsense das wenn das erste Interface gleichzeitig das WAN1 und gleichzeitig als Default Gateway funktioniert, Nating nicht richtig funktioniert.

              Nachdem ich die beiden em0 und ue0 jeweils zwischen WAN1 und WAN2(opt1) getauscht hatte (assignment geändert). Klappt alles reibunglos.
              Die Reply-to rules werden ohne Probleme angelegt (macht Pfsense automatisch).
              Kann man sich unter rules.debug auch anschaun.

              Es funktioniert nun alles so wie es soll, trotzdem danke für deinen Input.

              Ich habe jetzt (wenn man von einer neuinstallation ausgeht), nur die Failover/loadbalancing route in der Lan->All Regel als Gateway hinterlegt, und zwei Nat-rules (für jedes interface eine) angelegt.

              Sieht man im Bild, klappt hervorragen.

              http://forum.pfsense.org/index.php/topic,57927.0.html (hier wurde das ganze auf englisch durchgekaut, bzw. die suche nach dem Fehler läuft noch)


              1 Reply Last reply Reply Quote 0
              • First post
                Last post

              Products

              • Platform Overview
              • TNSR
              • pfSense Plus
              • Appliances

              Services

              • Training
              • Professional Services

              Support

              • Subscription Plans
              • Contact Support
              • Product Lifecycle
              • Documentation

              News

              • Media Coverage
              • Press
              • Events

              Resources

              • Blog
              • FAQ
              • Find a Partner
              • Resource Library
              • Security Information

              Company

              • About Us
              • Careers
              • Partners
              • Contact Us
              • Legal
              Our Mission

              We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

              Subscribe to our Newsletter

              Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

              © 2021 Rubicon Communications, LLC | Privacy Policy