@kira12 Das Problem dürfte da eher das fehlende/mangelnde Verständnis sein, von denjenigen, die diese vermeintlichen "HowTos" schreiben und propagieren. Das reicht von "works for me" über "sie wissen es nicht besser" bis zu "mir egal, ich mach das Video eh nur für Klicks" Howtos, daher ist es in der Masse eher schwierig zu wissen, ob etwas wirklich sinnvoll/gut ist oder nicht.
Daher würde ich an der Stelle immer zuerst offizielle Quellen lesen und die neue Doku mit zusammengefügten Inhalten aus dem ehem. Buch und der off. Doku ist dahingehend wirklich gut und erklärt die Grundlagen auch für Themen wie Rule-Processing-Order und Co. Wenn man das im Kopf hat dazu, erklärt es sich von selbst ob/warum manche Regeln weiter oben stehen müssen als andere und warum es - wie in deinem Fall - überhaupt keinen Sinn machen kann.
Wichtig sind lediglich drei Dinge, wenn du policy routing machst (also mit Regeln):
Überlegen, WANN deine Regel zutrifft und ob es alle Fälle trifft, die du so routen möchtest (also ob du dir mit Regeln darüber oder darunter irgendwas abgräbst o.ä.)
Das richtige Gateway setzen oder die entsprechende GatewayGruppe
Daran denken, dass ein erzwungenes Gateway in einer Regel auch Verkehr DORT hinschickt, der ansonsten mit Gateway * woanders hin laufen würde!
Beispiel für #3: Du hast ein 4-er Konstrukt. WAN, WAN2, DMZ, LAN. Auf dem LAN legst du nun eine Regel an, dass nicht wie bisher any any via * sondern any any via Failover_Gateway_xy geroutet wird. Damit willst du automatisch von WAN auf WAN2 und zurück schwenken wenn WAN mal kaputt gehen sollte. Wenn du sonst aber keine anderen Regeln hast, kommst du jetzt nicht mehr auf deine DMZ Hosts. Warum? Weil vorher mit * alles über die Routing Table geroutet wurde - und da steht natürlich drin: DMZ ist ein lokales Netz, da route ich direkt hin! Jetzt wird alles über WAN oder WAN2 gezwungen. Auch Sachen AN die DMZ die eigentlich lokal wäre.
Wie gehts besser? Entweder man legt generell als sein Default Gateway jetzt nicht mehr WAN oder WAN2 fest sondern direkt eine Failover Gruppe (geht NUR mit Failover! Gruppen, KEINE Loadbalancing Gruppen!). Dann muss man an den Regeln NICHTS ändern, denn "*" steht dann automatisch für "default" und default ist ja WAN bzw. WAN2 je nach Failover Status. Das ist recht neu seit 2.4 und deshalb sprechen viele alte Howtos noch überhaupt nicht davon, dass das heute auch ohne Regeln geht!
Alternativ mit PBR also via Regeln: Man erstellt einfach eine Regel mit Source LANnet und Dest DMZnet (oder einem beliebigen lokalen Alias), das dann wie bisher Traffic einfach mit Gateway * erlaubt. Alles was dann "ins Internet" gehen soll bekommt dann mit einer LANnet to any Regel das Failover oder Loadbalancer Gateway zugewiesen.
Alleine daraus sieht man schon, dass die Howtos mit "Failover Regel ganz nach oben" kompletter Unfug sind, denn praktisch muss diese eher Richtung unten positioniert werden, wenn vorher noch anderer Traffic über bspw. VPNs, interne Netze, VLANs, IPSEC/OVPN Tunnel etc. geroutet werden soll. Daher: lieber informieren oder hier fragen bevor man fragwürdigen 08/15 Howtos folgt, die jemand einfach zusammengeklickt hat.
@kira12 said in MultiWan LoadBalancing und Failover:
z.B. https://forum.netgate.com/topic/58507/multi-wan-dual-and-policy-based-routing-with-failover/3
Alleine was man in dem Thread nachfolgend von bspw. phil liest, ist nochmal genau das was ich beschrieben habe. Die 3 Regeln, die im ersten Topic beschrieben werden einfach blind anzulegen bringt überhaupt nichts bzw. nur etwas, wenn man bisher lediglich vom LAN eine allow any Regel hatte und sonst nichts. Oder auch:
a) You only want 1 rule for each from/to set of addresses - the system will use the first rule it matches, later rules will therefore not be matched/used.
b) The more specific rules must be first in the list, then the specific traffic gets matched and the "other general crud" falls through to match the later general rule.
Man braucht keine 3 Regeln, sondern man wählt für jede Regel aus, ob man diese über ein spezifisches Gateway (LB, Failover, default) schickt oder nicht. Und wie in b) beschrieben, spezifischere Regel bzw. enger gefasste Regeln müssen natürlich on top stehen, sonst würden sie bei einer any any Regel nie abgearbeitet werden. Ansonsten passiert das, was er in https://forum.netgate.com/post/407576 beschreibt. Die Regeln werden gar nicht erst abgearbeitet.
Und zu guter Letzt ist der Beitrag von 2017 und damit lange vor der neuen Default Gateway Switching Methode entstanden. Heute würde das hier problemlos funktionieren OHNE irgendwelche Regeln zu verändern:
failovergw.gif
Einfach ein FO-Gateway anlegen (Tier1 WAN1, Tier2 WAN2 bspw.), dieses als Default Gateway hinterlegen, speichern, fertig. Damit gilt für alle Interfaces und Regeln mit Gateway * automatisch ein Failover 1->2. Ohne Anpassung irgendwelcher Regeln. Wenn man das dann zusätzlich übersteuern möchte um ggf. bestimmten Traffic NUR über 1 oder 2 rauszuschicken oder manchen Traffic dann "Loadbalancen" möchte, kann man das problemlos machen.
Cheers
\Jens
