Klärungsbedarf/Details zur GW-Gruppe und die pool options?

[mr44er]

Ich bin mir nicht sicher, ob ich die Optionen richtig verstehe, was jeweils das eine oder andere bewirkt und bitte um Aufklärung und Hinweise, wenn ich wo falsch liege. Keine Angst, das artet nicht in multi-WAN vorkauen aus, das rennt grundsätzlich. Mir geht es wirklich nur um die pool options

Es sind zwar mehr Leitungen, aber für die Beispiele bleibe ich bei zwei und einem Clientnetz.

Gegeben sind 2x WAN (nennen wir sie mal A und B), jeweils im betreffenden Interface den dazugehörigen (IPv4 Upstream Gateway) explizit gesetzt, weil es da lautet "If this interface is a multi-WAN interface, select an existing gateway from the list or add a new one using the button above."
Unter System>Gateways>Single haben beide das Häkchen bei Upstream Gateway gesetzt. WAN_A hat prio10, WAN_B hat prio11. Wie ich das verstehe, gilt das erstmal nur für OPNsense selber...also bevorzuge WAN_A, wenn der nicht verfügbar ist, nimm WAN_B. Weiterhin habe ich beide explizit auf weight5 gesetzt. Das monitoring läuft, beide dpinger-Instanzen sind auf grün.

In der Gruppe sind beide in tier1 und das trigger level auf "member down".

Für die GW-Gruppe existieren zwei FW-Regeln, also policy based routing, das triggert auf port 80/TCP und 443/TCP.

Firewall>Settings>Advanced hat Sticky connections aktiv, Shared forwarding aktiv, Disable force gateway deaktiviert

Szenario1 (pool options default)
Client_A surft jetzt forum.opnsense.org an. Vom DNS-Traffic mal abgesehen (und wenn nicht bereits eh schon im cache), alles nachfolgende läuft über einen der beiden GWs, der 50/50 ausgewählt wurde. Sagen wir hier mal, dass GW_A getroffen wurde. Die states bleiben also für Client_A via GW_A offen und solange diese bestehen, geht der traffic ausschließlich über GW_A.

Surft jetzt ein Client_B ebenfalls forum.opnsense.org an, dürfte dieser traffic dann ausschließlich über GW_B rausgehen bzw. an GW_B 'kleben', daher die Bezeichnung sticky (auch hier nur solange die states nicht ablaufen)

Szenario2 (pool options default, Sticky connections deaktiviert)
Client_A surft forum.opnsense.org an. Der traffic geht über beide GWs raus und rein (aber nicht über Kreuz, das reply-to habe ich nicht angetatscht! ), z.B. ganz einfach ausgedrückt das logo und vier der smilies via GW_A und die restlichen smilies über GW_B, eben auch 50/50.

Für Client_B läuft das genau so.

Damit wäre Default: Round Robin, Sticky Address determined by advanced settings abgedeckt, wenn das so stimmt, wie ichs vestehe.

Was bewirken jetzt aber Round Robin: Loops through the translation addresses und Sticky Address: The Sticky Address option can be used with the Round Robin pool type to ensure that a particular source address is always mapped to the same translation address. in den vier weiteren Szenarien mit jeweils Sticky connections an/aus?

Die Frage kam ursprünglich auf, wie ich gegenüber einem free-filehoster die Wartezeit etwas verkürzen kann, wenn man da das trafficlimit aufgebraucht hat. 
Verbindung neu aufbauen und IP erneuern empfinde ich als hässlichen workaround, zumal ich nicht überall dynamische IPs habe.