Dual WAN

    Hallo zusammen,


    ich würde gern ein spezielleres Routing-Szenario bauen, finde dazu aber leider kaum Informationen, die mir weiterhelfen.


    Hintergrund ist folgender:

    Wegen CGNAT bei der DG würde ich gern eine Public IPv4 Adresse per ipip6 Tunnel vom Netcup Hosting nutzen (eine zweite IPv4 Adresse bekommt man da ja relativ einfach, und die lässt sich sehr simpel routen). Netcup vServer läuft unter Debian, zu Hause läuft ein Edgerouter 4. Der Tunnel steht auch schon, läuft soweit - ich kann also mit den Clients im LAN komplett über das "Tunnel-Gateway" ins Netz gehen. Allerdings habe ich ja nun quasi ein Dual WAN Szenario, so dass ich zwei Default Gateways nutzen könnte. Der "Umweg" über den ipip6 Tunnel ist ja quasi eine Krücke, so dass ich den zunächst nur für eingehende TCP Verbindungen nutzen möchte, nicht aber für den "regulären" Internet-Traffic.


    Heißt also: wenn sich jemand von außen zu der Netcup-Public IP verbindet, wird dies über Portweiterleitungen und NAT vom Edgerouter ins LAN weitergeleitet. Antwortpakete der LAN Hosts sollen natürlich auch wieder über diese Public IP und über den Tunnel rausgehen. Aller anderer Traffic der Hosts (bei dem Verbindungen vom LAN aus aufgebaut werden), sollen aber direkt über das CGNAT Gateway der DG geroutet werden.


    Hat jemand eine Idee, in welche Richtung ich da weiter recherchieren müsste? Sind die klassischen Load-Balancing Lösungen hier vergleichbar? Da geht es ja auch um die Konfiguration von zwei Default Gateways. Allerdings fürchte ich, dass hier eingehende Verbindungen gar nicht berücksichtigt werden, oder? Ist Tagging der Pakete über Firewall-Regeln ein Ansatz? Damit habe ich leider noch keine Erfahrungen.


    Ich wäre Euch sehr dankbar für Eure Gedanken dazu. Falls das Szenario unklar ist oder ich grundsätzliche Denkfehler mache, lasst uns gern noch mehr Details zu dem Setup austauschen.


    Danke schonmal!

    • Offizieller Beitrag

    Du möchtest über Interface B ankommende Verbindungen vollständig über Interface B abwickeln, während alle anderen Verbindungen Interface A nutzen sollen. Das ist möglich und es gibt mehrere Varianten.


    Einfach und eher "klassisch" ist Source-NAT, so dass diese Verbindungen alle vom VPS zu kommen scheinen. Mit einer Route, die alle Pakete zu dieser Adresse durch Interface B (den Tunnel) schickt, ist das Thema dann erledigt. Der Nachteil dieser Methode ist, dass der Server die echten Adressen der Clients nicht sieht.


    Die Variante für Fortgeschrittene hat diesen Nachteil nicht. Unter Linux ist das Stichwort Policy Routing. Damit kann die Routing Entscheidung von mehr Attributen abhängig gemacht werden, indem verschiedene Routing-Tabellen z.B. in Abhängigkeit von der Source-IP-Adresse verwendet werden. Wenn man dann eine zusätzliche Tabelle festlegt, die für Pakete mit der öffentlichen IP-Adresse als Source-Adresse verwendet werden, dann wird diese Tabelle ausgehend genau für die Verbindungen genutzt, die über diese IP Adresse ankommen.


    Wenn man das auf einem Server im LAN realisieren möchte, der mehrere Router zur Auswahl hat, aber für beide Arten von Verbindungen die gleiche (nicht-öffentliche) Adresse verwendet, kann man auch mit Connection-Tracking und Firewall-Markierungen (fwmark) arbeiten, aber für den beschriebenen Anwendungsfall ist das unnötig kompliziert.


    Welche Funktionalität Ubiquiti verfügbar macht und wie das da konfiguriert wird, kann ich dir aber nicht sagen.

    Zitat von alfalfa

    Die Variante für Fortgeschrittene hat diesen Nachteil nicht. Unter Linux ist das Stichwort Policy Routing. Damit kann die Routing Entscheidung von mehr Attributen abhängig gemacht werden, indem verschiedene Routing-Tabellen z.B. in Abhängigkeit von der Source-IP-Adresse verwendet werden. Wenn man dann eine zusätzliche Tabelle festlegt, die für Pakete mit der öffentlichen IP-Adresse als Source-Adresse verwendet werden, dann wird diese Tabelle ausgehend genau für die Verbindungen genutzt, die über diese IP Adresse ankommen.

    Danke für Deine Hinweise!

    Die zitierte Variante mit PBR klingt spannend. Hatte ich auch schon kurz überlegt, aber war mir nicht sicher, ob das hier greift. Die meisten Infos dazu erklären ja, wie ich Tabellen anlege, die abhängig von der Source Adresse der LAN Hosts zu den verschiedenen Gateways routen. Wenn ich Dich aber nun richtig verstanden habe, müsste ich mir anschauen, wie ich die Tabellen-Selektion anhand der eingehenden Pakete von Interface B machen könnte (erkennbar an der Source IP der eingehenden Pakete). Ausgehende Pakete würden dann also entsprechend der bereits bekannten, eingehenden Verbindungsaufbauten von Interface B abgeglichen und nur über Interface B geroutet, wenn sie zu einer solchen bekannten Verbindung gehören? Wird das per Connection Tracking realisiert?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    • Offizieller Beitrag

    Der Router hat zwei "WAN"-Adressen, eine aus 100.64.0.0/10 direkt vom Anschluss und eine öffentliche auf dem Tunnelinterface. Damit Verbindungen, die über den Tunnel hereinkommen, den Server erreichen, muss der Router Destination-NAT (Port-Forwarding) machen. Die Antworten vom Server schreibt der Router auf dem Weg zurück wieder auf seine öffentliche Adresse als Source um. Das passiert in Folge der Portweiterleitung automatisch durch Connection-Tracking. Wenn ein solches Paket den Router verlässt, kann man mit Policy Based Routing für diese Source-Adresse eine andere Routing-Tabelle und darin den Tunnel als Interface auswählen. Ich kann hier wie gesagt nur das Konzept beschreiben, da ich nicht weiß, wie Ubiquiti diese Funktionen umsetzt.

    Danke Dir!

    Ich habe mal nach Beispielen für den Edgerouter und Source-Address PBR gesucht. Da gab es Beispiele, die mit der nicht-öffentlichen Source IP Adresse des LAN-Hosts die Tabelle wählen. Meine Befürchtung ist, dass die Firewall des Routers die Policies auswertet, bevor die Source-Adresse per NAT getauscht wird. Schau mal das Diagramm unter "LAN Incoming Traffic" von Ubiquiti (das zweite auf der Seite):


    https://help.ui.com/hc/en-us/a…-processed-by-EdgeRouter-


    Wenn ich das richtig sehe, wird SNAT als letztes ausgeführt. Würde der Ansatz, den Du beschrieben hast, dann überhaupt funktionieren können?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    • Offizieller Beitrag

    Entschuldige bitte, das hatte ich falsch in Erinnerung. Ich habe das gerade mal nachgebaut und tatsächlich werden die Policy Rules vor der NAT-Umkehr ausgewertet, so dass die einfache Entscheidung auf Basis der Source-Adresse nicht funktioniert, wenn der Router Port-Forwarding macht. Anhand der Server-Adresse kann man nicht unterscheiden, welche Routing-Tabelle verwendet werden soll. In dem Fall ist dann doch die Entscheidung auf der Basis einer Firewall-Markierung nötig. Die einfachere Lösung funktioniert nur für Dienste auf dem Router selbst.

    Gut zu wissen! Ich hänge zunächst erstmal noch mit meinem Testsetup fest. Habe es erstmal auf einem Edgerouter-X hinter meiner Fritzbox von meinem alten DSL-Provider testen wollen, um nicht gleich am Hauptanschluss zu experimentieren. Leider hat die Fritzbox hier offenbar einen Bug. Die Tunnel ipip6 Pakete vom nachgelagerten Edgerouter-X werden von der Fritzbox nicht korrekt nach draußen weitergeleitet. Wenn ich per Mirroring-Port am Switch zwischen den Routern lausche, sehe ich die Tunnel Pakete in beide Richtungen noch. Im lan-Mitschnitt der Fritzbox sind dann aber die Pakete einer Richtung verschwunden. Eingehende ipip6 Pakete vom ISP kommend sehe ich noch, die Antwortpakete dazu vom Edgerouter verschluckt die Fritzbox leider. Fritzbox 7560, Firmware ist 7.28, Edgerouter-X ist als Exposed Host eingetragen und bekommt ein /60 von der Firtzbox zugeteilt. Der Tunnel läuft aber direkt über die DHCPv6 IA_NA Adresse am WAN-Port des Edgerouters. Keine Ahnung, warum die Fritzbox das nicht durchlässt.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.