Detailfrage zum Multi-WAN-load-balacing Algorithmus

[mscd]

Hallo zusammen,

ich nutze (Gründe vorhanden ;-)) eine OPNsense 21.7 (A) hinter einer weiteren 21.7er (B) ... sozusagen "Router A an Router B". Die zweite OPNsense (B) macht LoadBalacing im Multi-WAN auf zwei 1 GBit/s Kabelmodems. Nun beobachte ich leider, dass eigentlich nur eines der beiden Modems tatsächlich genutzt wird, obwohl eine entsprechende Gateway-Gruppe im gleichen Tier (und identischer Gewichtung) von mir eingerichtet wurde, und es eine entsprechende Firewall-Regel mit Policy-Einstellung auf die Gateway-Gruppe gibt.

Für mich stellt sich gerade die Frage, wie das RoundRobin-Verfahren hier bei der OPNsense im Detail funktioniert? Könnte es evtl. ein Problem sein, dass mein LoadBalancer (die zweite OPNsense (B) in der obigen Konstruktion) "nur" als Quelladresse diverser Clientanfrage, welche sich hinter der ersten OPNsense (A) befinden, immer nur die (gleiche) IP von der A-Kiste sieht (wegen der NAT)?
Ich dachte eigentlich, dass dies kein Problem sein dürfte, da im RoundRobin doch alle neuen Anfragen (egal welche Quell-IP) gleichmäßig auf die verschiedenen Gateways verteilt werden ... oder sehe ich das gerade falsch?

Besten Dank und schöne Grüße,
mscd

[trendchiller]

NATtet denn die OPNsense A oder routet sie ?
Bei NAT sieht die OPNsense B tatsächlich nur eine Adresse als Quelle

[mscd]

Sie macht NAT … wäre „Routing“ besser? Funktional geht soweit ja alles … bis auf die Tatsache, dass an der B-Kiste das RoundRobin nicht sauber läuft … wobei ich hier der Meinung bin, dass die Gateway-Gruppen (etc.) richtig konfiguriert sind … sticky connections ist auf der B-Kiste aktiv.

Grüße und Dank,
mscd

[trendchiller]

Doppel-NAT macht keinen Sinn.
NAT nur an der „Außenseite“ zum Internet.
Wenn Du das NAT deaktivierst und sie routet, sieht die andere OPNsense nun die quell ips und wird dann auch LB machen

[mscd]

Blöde Frage ... wenn die erste A-Firewall kein NAT (für die dahinterstehenden Clients) macht, wie soll eine Rückantwort über die B-Firewall dann den Client erreichen?

Beispiel:
http-Anfrage an google.de von Client 192.168.1.100/24 geht an die Gateway-Adresse 192.168.1.254/24 (von Firewall A) ... über das dortige Interface 10.0.0.1/24 an Firewall B 10.0.0.2/24 ... dort weiter (mit NAT) an die Kabelmodems ...

... die Rückpakete kommen nun bis zur Firewall B ... nur Firewall B hat keine Ahnung wie der Client 192.168.1.100/24 (dessen Subnetz hinter A hängt) zu erreichen ist ...

Das kann doch so nicht funktionieren, oder?

P.S.: Müsste ich (ohne doppeltes NAT) dann noch entsprechende statische Routen auf B setzen?

[trendchiller]

Beide Firewalls müssen mit den richtigen Routen ausgestattet sein. Dann gehen die Pakete auch durch

[mscd]

Ok Danke ... ich glaub ich lern echt gerade wieder was dazu ... Danke ...

... als doppeltes NAT lässt sich vermeiden nur auf B müssen für die Subnetze (hinter A) entsprechende Routen gesetzt werden.

[trendchiller]

Korrekt !

[mscd]

... trotzdem sind wir ein wenig von meiner eigentlichen Frage abgekommen, da ich beim MulltiWan-RoundRobin davon ausgegangen bin, dass auch z.B. mehrere Anfragen (zu verschiedenen Zielen) eines EINZIGEN Clients sauber auf die einzelnen Gateways verteilt werden müssten ... der Algorithmus kann doch nicht so "doof" implementiert sein, dass er alle Anfragen einer Quelle immer auf die selbe Leitung raus schickt, oder etwa doch?

[trendchiller]

Das ist in der Tat merkwürdig.
LB verteilt die Last schon gleichmäßig, wie sich das allerdings verhält mit einer Quelle (wegen NAT) vermag ich gerade nicht zu sagen.
Sticky Connections sind aktiviert ? (Firewall -> Settings -> Advanced)

[mscd]

Ja ist auf der B-Firewall aktiviert … aber da gehts ja eigentlich auch immer um das Tupel Source/Target.

[trendchiller]

Ja, das stimmt …
Schau mal, ob es Änderungen bringt, wenn das NAT aus ist.
Sonst könntest Du es noch mit Policy-Based Routing probieren: welches Protokoll geht wohin.
Habe da aber derzeit kein System zur Hand, um zu helfen

[JeGr]

> Ja ist auf der B-Firewall aktiviert … aber da gehts ja eigentlich auch immer um das Tupel Source/Target.

Und B ist die Loadbalancende? Dann ist es doch klar? Wenn Kiste A NATtet und alles auf ihre WAN Adresse (10.x) umschreibt, sieht B immer nur die WAN Adresse als Absender und wird laut stickyness immer alles auf einem WAN halten. Wenn A aber NICHT NATtet (also automatische Outbound NAT AUS!) und keine Regeln hat und B sabuere Routen für den Rückweg hat, dann sieht sie andere Absendeadressen und kann pro Source auch anfangen die Clients auf andere Links zu verteilen. Oder du machst eben Stickyness aus, dann kanns eben sein, dass du Probleme in Richtung Sessions, Cookies etc. hast wenn sich innerhalb der gleichen Session die IP ändert weil zu viel Zeit zwischen Requests ablief.

Cheers