Messages

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?

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

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

Hallo zusammen,

unter /var/log/filter.log findet man (meiner Kenntnis nach) die raw-Log-Einträge des Paketfilters ... mich wundert hier nur gerade, dass diese Datei in meinem Fall nur Einträge der letzten Minuten beinhaltet ... lässt sich (zumindest per Shell) ein längerfristiges Filter-Log der Firewall einsehen/durchsuchen?

Schöne Grüße,
mscd

OK, Danke ... sehe es gerade ... passt aber dann z.B. nicht so sauber zur Doku hier:

https://www.thomas-krenn.com/de/wiki/OPNsense_HA_Cluster_einrichten#Konfiguration

bzw.

https://docs.opnsense.org/manual/how-tos/carp.html#setup-interfaces-basic-firewall-rules

Hallo zusammen,

ich betreibe zwei OPNsense-Appliances im HA-Verbund über CARP. Die PFSYNC-Leitung ist hierbei eine direkte Verbindung zwischen Firewall A und Firewall B, wobei auf dem zugehörigen Interface eine "allow-ANY-Regel" im Firewall-Ruleset hinterlegt ist.
Mir ist gerade unklar, ob ich hierbei noch zusätzlich für jedes weitere Interface, welches ich per CARP (und virtueller IP) hochverfügbar machen will, noch eine ALLOW-ANY-Regel für das CARP-Protokoll hinterlegen muss. Da ich mit mehreren VLANS arbeite, habe ich derzeit eine Interface-Gruppe angelegt ... darauf dann im Firewall-Ruleset "Allow CARP from ANY to ANY".
Da ich gerne unnötige Regeln vermeiden möchte, stellt sich für mich die Frage, ob bei eigenständiger/dedizierter PFSYNC-Leitung überhaupt noch CARP-Traffic auf den anderen Interfaces läuft und welche Regeln hier entsprechend zu pflegen sind.
In der HA-Doku der pfSense kann ich - komischer Weise - nämlich keinen Hinweise auf entsprechende Firewall-Regeln für die CARP-Interfaces finden.

Schöne Grüße und Dank,
mscd

Thanks a lot for your reply ... i did some testing with "shared forwarding" disabled (WAN-load-balancing with two WAN-interfaces, both in Tier1) and activated "sticky connections" feature ... and it seems to work now.

=> So I think there must be a bug in the implementation of "shared forwarding" in conjunction to multiWAN-balancing?!

Update: With "sticky connections" turned off, client connections seem to work stable ... on the other hand, I thought one should activate "sticky connections" in the WAN-balancing use-case due to the possibility of https-session-problems.

So what?

Same problem here with "sticky connections" turned on (OPNsense 21.1.7) ... this is really disappointing ! ... WAN-load-balancing is a "must-have-feature" in a "production-use-ready" firewall appliance.

Any hints to get this properly working? If I deactivate "sticky connections" (which seems to be counterintuitive for me) the client-connections seem to behave more stable.

Best regrads,
mscd

Same problem here (OPNsense 21.1.7, two WAN-links, both with static/internal IPs as exposed hosts behind ADSL-routers, one link untagged WAN-port the other TAGGED VLAN, both in tier1, load-balancing) ... the interesting thing is ... disabling "sticky connections" (stickiness = 0) seems to solve the problematic behavior, but otherwise, I think this setting should be activated in the load-balancing case (https-session-problems).

At the moment I can't figure out how to get WAN-balancing properly working with "sticky connections". Any advice?

Best regards,
mscd

Hello folks,

I am observing a similar behavior/problems with OPNsense 21.1.7, although I already deactivated uplink monitoring of WAN-interfaces completely (e.g. per ping to 1.1.1.1 or 8.8.8.8 ).
WAN-LoadBalancing is not working properly ... half of the connections get stuck ... by using one WAN-interface alone, everything seems to be fine.

Any further advice/hints to this problem?

Best regards,
mscd

Hello folks,

any solutions yet to that problem? I would like to get a transparent squid web-proxy running in combination with multi-wan-load-balancing. "tcp_outgoing_address 127.0.0.1" (in /usr/local/etc/squid/pre-auth/custom.conf) doesn't do the trick ... any hints?

Best regards,
mscd

Hello folks,

is it possible to get the (transparent) squid web-proxy working with multi-wan-load-balancing? I am used to that behavior from a Sophos SG230 and now I am wondering that this doesn't seem to work (without special hacks) on the OPNsense 21.x.

Best regards,
mscd

Hallo zusammen,

an meiner OPNsense hängen derzeit zwei DSL-Router. Gemäß folgender Anleitung

https://www.thomas-krenn.com/de/wiki/OPNsense_Multi_WAN

habe ich eine WAN-LoadBalancing-Gruppe erstellt, welche auch soweit scheinbar funktioniert.
Da der gesamte HTTP(S)-Verkehr diverser lokaler Subnetze per NAT-Regel auf der OPNsense transparent durch den dortigen squid-WebProxy geleitet wird, ist mir aktuell unklar, ob der squid-proxy ebenfalls das WAN-LoadBalancing-Gateway benutzt oder den gesamten Traffic "nur" über das aktuelle Standard-Gateway anfrägt.

Ich benötige den transparenten squid-Proxy für einen kategorisierten WebFilter (blacklisting). Seitens einer mir bekannten Sophos UTM läuft dort auch jeglicher WebProxy-Traffic sauber über das Load-Balacing ... ist das bei der OPNsense auch so möglich?

Schöne Grüße und besten Dank für jegliche Hinweise,
mscd

Ja soweit (schon) klar ... da ich insgesamt 15 Subnetze/VLANs hab, hätte ich am besten halt gerne EINE Regel, welche sich um das ungeloggte drop der Broadcast-Pakete kümmert. Daher rührt meine Anfrage.

Schöne Grüße und Dank,
mscd