MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway

JeGr

@viragomann said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

Vielleicht war es ein einmaliger Vorfall, aber zusammen mit allem anderen, was in jüngerer Zeit über die Aufspaltung Plus-CE publik wurde sieht für mich doch irgendwie so aus, als wollte man von der Community profitieren, sollte es was geben, aber nichts zurückgegen. Wissensaustausch auf der Einbahnstraße also. Da stehen Gewinner und Verlierer von vornherein fest.

Ist ja eher andersrum. Die Plus hatte das Problem zuerst, irgendwie hat man es wegbekommen und lustigerweise geht der gleiche Fix wohl nicht in der CE. Treiber? OS? Irgendwas anderes? Wer weiß. Die haben aber eben gleich mehrere Baustellen aktiv offen. Und wenn sie wüssten wie schnell es geht hätten sies sicher ins Ticket geschrieben. Wenn aber da vor 6 Tagen drinsteht, dass es nachvollziehbar ist und jemand recht zuversichtlich ist, dass er ggf. nen Fix hat, dann wirds wohl potentiell nicht mehr so lange dauern. Aber wenn du sowas aufmachst oder offen hast, dann willst du den Fix da sicher auch nicht rushen um das nächste Problem aufzumachen oder das gleiche Ding bei der Plus wieder einzuführen. Regression Bugs sind eben immer fies :)

Die Frage bezüglich ZFS war, ob jemand Erfahrung mit Snapshots und Rollbacks hat.

Tatsächlich noch nicht, keine Zeit gehabt. Und aktuell leider sehr viel mit Support, Seminaren und Workshops zu tun. Das nimmt gerade ganz gut zu, da sich viele aktuell nach Alternativen umsehen, nachdem es bei den Hardware Firewall Herstellern gerade auch ständig kracht ;)

m0nji

Kurze Frage in die Runde:
Seit dem 2.5.1 Update will mein OpenVPN nicht mehr wirklich über mein 2. WAN Interface (nicht Default Interface).
Die Verbindung kann aufgebaut werden(Win Clinet --> pfSense) aber sobald man dann auf eine interne Ressource z.b. über RDP oder HTTP zugreifen will, stürzt der Tunnel ab.
Kann das jemand bestätigen, dass es mit dem verlinkten Bug zusammenhängt? So richtig matchen kann ich das mit dem Bugreport nicht, weil ich kein Port Forwarding nutze sondern direkt eine Firewall Rule auf dem WAN2 Interface

Das sind die letzten Logeinträge im OpenVPN Client

2021-04-20 14:26:20 IPv4 MTU set to 1500 on interface 12 using service
2021-04-20 14:26:26 Initialization Sequence Completed
2021-04-20 14:27:04 read TCP_CLIENT: Unknown error (code=10060)
2021-04-20 14:27:04 Connection reset, restarting [-1]
2021-04-20 14:27:04 SIGUSR1[soft,connection-reset] received, process restarting

slu

So wie es aussieht muss man auf die 2.6.0-dev wechseln, keine schöne Situation.
Wenn ich wüsste ob wir hier von 2 Wochen oder 2 Monaten sprechen...

fireodo

@slu said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

Wenn ich wüsste ob wir hier von 2 Wochen oder 2 Monaten sprechen...

Diese Frage wird wohl nicht mal das Netgate-Team beantworten können ...

Grüße,
fireodo

slu

@fireodo
naja es gibt ja ein Patch der auch schon im 2.5.er Zweig ist...

JeGr

@slu So wie es aussieht muss man auf die 2.6.0-dev wechseln, keine schöne Situation.

Warum sollte man auf 2.6dev wechseln müssen?

slu

@jegr

pfSense 2.5.1 kann ich nicht einsetzten wegen dem Bug.
2.5.0 hat aber das openssl Problem was mit dem HAProxy unschön ist.

Was mache ich jetzt?

Oder ist das openssl Problem keines für den Use Case pfSense?

fireodo

@slu said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

Was mache ich jetzt?

In den englischsprachigen Kommentaren sagen einige dass ein Wechsel zur 2.6 devel sinnvoll wäre weil es dort dieses Problem nicht gibt - aber unter Umständen handelt man sich anderweitig noch größeren Ärger ein ...
Meine 5 Cents ...

Grüße,
fireodo

slu

@fireodo said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

In den englischsprachigen Kommentaren sagen einige dass ein Wechsel zur 2.6 devel sinnvoll wäre weil es dort dieses Problem nicht gibt - aber unter Umständen handelt man sich anderweitig noch größeren Ärger ein ...

Jap, das ist genau der Punkt. Für diese Systeme möchte ich nicht auf 2.6 devel gehen.
Bei meiner privaten Netgate Appliance hab ich damit kein Schmerz...

JeGr

Verstehe das Problem nicht. Wenn es in 2.6-dev jetzt sauber läuft und entsprechend ein Fix damit gerade getestet wird, dann gibts auch nen Backport oder zumindest Cherry Picking mit Patch für 2.5 in naher Zukunft. Lief so in der Vergangenheit auch, verstehe nicht warum jetzt gerade jeder in Panik ist, dass es jetzt nicht mehr so sein sollte. Und kommt mir nicht mit dem Plus Kram, denn egal was Plus ist oder wird (oder eben nicht ist/wird) wurde von Anfang an kommuniziert, dass Bugfixes, Security Fixes etc etc. alle weiterhin bearbeitet und ordentlich umgesetzt werden. Dass man aber nach dem Wireguard Rollback und den Problemen mit VPN auf 2.5 und dem Forwarding Kram in 21.2 bzw. 2.5.1 jetzt eben NICHT nen Schnellschuß Patch raushauen möchte sondern ordentlich testen muss, versteht sich für mich ebenfalls von selbst.

Würde daher die Redmine Issues im Auge behalten und abwarten.

2.5.0 hat aber das openssl Problem was mit dem HAProxy unschön ist.

Habe ich aktuell gerade wegen Überlastung an anderer Stelle nicht auf dem Schirm, was gibt es da?
Da ich gerade selbst nen kleinen HAproxy Bug reported hatte, habe ich da nichts gesehen, dass es irgendein OpenSSL/HAproxy Problem gibt. Oder gehts generell einfach um den OpenSSL Bugfix auf 1.1.1k der dann erst mit 2.5.1 drin ist?

slu

@jegr said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

Lief so in der Vergangenheit auch, verstehe nicht warum jetzt gerade jeder in Panik ist, dass es jetzt nicht mehr so sein sollte. Und kommt mir nicht mit dem Plus Kram, denn egal was Plus ist oder wird (oder eben nicht ist/wird) wurde von Anfang an kommuniziert, dass Bugfixes, Security Fixes etc etc. alle weiterhin bearbeitet und ordentlich umgesetzt werden.

keine Sorge um Plus gehts mir nicht und ich bin mir sicher das es ein Fix gibt, die Frage ist nur wann weil..
..mir ist unklar wie groß das openssl problem ist
..ich in 10 Jahren noch nie das Problem hatte nicht updaten zu können und ich keine Ahnung hab was passiert wenn jetzt Packetupdates kommen (z.B. es ist was gegen die neue OpenSSL Version gebaut bzw. verwendet das).

Da ich gerade selbst nen kleinen HAproxy Bug reported hatte, habe ich da nichts gesehen, dass es irgendein OpenSSL/HAproxy Problem gibt

Vielleicht hab ich das auch nur falsch verstanden, stecke in dem Problem nicht tief genug drin.

https://forum.netgate.com/topic/162586/openssl-cve-2021-3449-cve-2021-3450?_=1619176564095

https://redmine.pfsense.org/issues/11755

Während ich geschrieben hab hast Du editiert, hoffe meine Antwort passt noch :)

viragomann

@slu said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

und ich keine Ahnung hab was passiert wenn jetzt Packetupdates kommen (z.B. es ist was gegen die neue OpenSSL Version gebaut bzw. verwendet das).

Wen die Branches in System > Update > System Update und Update Settings auf deiner aktuellen Version gesetzt sind, sollte kein Paket gezogen werden, das nicht kompatibel ist.

JeGr

@slu said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

https://redmine.pfsense.org/issues/11755

Jup, was Virago sagt. Wenn der Branch sauber gesetzt ist, kann man auch aktuell mit 2.4.5-p1 Pakete installieren ohne aus Versehen auf 2.5 upzudaten, etc. Also kommts drauf an, was man ausgewählt hat.

2.6 auf nem Entwicklungssystem OK, zu Hause auch, live wäre mir das eher nicht so recht.
Wenn 2.5.0 das Einzige Problem OpenSSL ist, dann würde ich 2.5 nehmen, denn was ich bislang zu den beiden Lücken gelesen habe - obwohl sie korrekt "hoch" eingestuft sind - sind es DoS Angriffsflächen. Also im Dümmsten Fall fliegt der HAproxy eben weg und stirbt. Wenn du aber MultiWAN hast und grad von den Forwards betroffen bist, warum auch immer die nicht so wollen wie sie sollen, dann würde ich ggf. eher bei 2.5 bleiben als ganz zurückzurollen auf 2.4 - aber das muss jeder selbst entscheiden. Besser wirds da bspw. mit OpenSSL ja auch nicht. :)

slu

@jegr said in MutiWAN NAT/Port Forward pfSense 2.5.1 fehlerhaft != default Gateway:

Jup, was Virago sagt. Wenn der Branch sauber gesetzt ist, kann man auch aktuell mit 2.4.5-p1 Pakete installieren ohne aus Versehen auf 2.5 upzudaten, etc. Also kommts drauf an, was man ausgewählt hat.

interessant, das war mir nicht klar, wieder was gelernt.

Wenn 2.5.0 das Einzige Problem OpenSSL ist, dann würde ich 2.5 nehmen, denn was ich bislang zu den beiden Lücken gelesen habe - obwohl sie korrekt "hoch" eingestuft sind - sind es DoS Angriffsflächen. Also im Dümmsten Fall fliegt der HAproxy eben weg und stirbt. Wenn du aber MultiWAN hast und grad von den Forwards betroffen bist, warum auch immer die nicht so wollen wie sie sollen, dann würde ich ggf. eher bei 2.5 bleiben als ganz zurückzurollen auf 2.4 - aber das muss jeder selbst entscheiden. Besser wirds da bspw. mit OpenSSL ja auch nicht. :)

Hast mich überzeugt, ich bleibe bei der 2.5.0 vorerst :)
Mal sehen ob der HAProxy irgendwann mal weg ist...

JeGr

@slu https://redmine.pfsense.org/issues/11805

sollte also hoffentlich nicht lange dauern, es benötigt aber auf jeden Fall ein 2.5.2 da Kernel Level Fix. Deshalb gibts auch nirgends einen Hotfix oder sonstwas zum Einspielen und wenn es ein Kernel Fix ist, dauert es entsprechend länger, weil die ganze Release Kette dann getestet werden muss. Darum zieht sichs auch so lange.

Erklärt auch warum Plus dieses Mal nicht betroffen ist, weil es wohl eine Regression war, also irgendeine Kernel Anpassung hat das wieder mit reingebracht obwohls schon raus war. Vielleicht einfach human-error und vom falschen Stand aus nen Rebase vom Git gemacht oder whatever. Da aber Plus und CE (minimal) andere Kernels haben (schon immer wegen Treibern für ARM etc.) ist das erklärbar.

Cheers

slu

@jegr
ja der Aufwand für diesen Fix ist leider höher als gedacht.

Mal sehen wann sich was tut, ich hatte auf ein -p1 gehofft.
Im Moment steht das Ticket auf 2.6.0, mal sehen...

slu

Was mich wirklich wundert, nach wie vor steht nichts in den Known Issues, das verstehe ich nicht.
Die Leute rennen weiterhin in dieses Problem...

oNe

Hallo in die Runde,

hier ist auch ein 2.5.1-Geplagter, der von den Fehlern nichts wusste und nun arge Probleme nach dem Update hat.
DNS ging auf der pfsense nicht mehr - da habe ich mir schnell geholfen und nen pihole ins Netz genommen.
Was aber viel schlimmer ist, dass IPSec-Tunnel ständig wegbrechen. Bzw sie sind Online, aber es geht kein Traffic mehr rüber. Manchmal läuft es Stunden durch und manchmal ist nach 5Minuten wieder Ende.

Weiß schon jemand mehr bzgl. Patches? Habe hier in der Produktivumgebung kein gutes Gefühl mit Dev-Versionen.

Das ganze läuft auf einer Netgate XG-7100.

Danke für eine Rückmeldung und liebe Grüße

dennis_w

Ich stelle mich mal in der Geplagten Reihe hinten an.
Habe seit zwei Wochen Probleme mit OpenVPN Latenz. Das fällt produktiv aber nur bei den VoIP Verbindungen auf. Unterbrüche von bis zu 3 Sekunden im Gespräch. Alle anderen Dienste (Mail, Fileshare, etc.) laufen stabil. Dennoch stehen mir 50 User auf den Füssen, weil sie nicht mehr sauber telefonieren können.

Endlosping vom Client zum Server durch den Tunnel wirft unregelmäßig hohe Latenzen (3000ms) und Timeouts raus. Aussen herum Ping ohne Tunnel direkt auf eine public IP erzeugt zur gleichen Zeit keine Auffälligkeiten. Liegt also definitiv am Tunnel.

Hab zum Testen auf eine derbe Hardware gewechselt. Das hat die Latenz zwar von 3200ms auf 1500ms runtergebracht. Unterbrüche im Gespräch bleiben aber.

Ein downgrade auf die vorher verwendete 2.4.4 funktioniert einwandfrei aber ich will eigentlich den Open SSL Exploit schliessen.

Hat die 2.5.0 die 1.1.1k noch nicht drin und die hat das Gateway Problem nicht?

Gruss
Dennis

oNe

Wie lange war deine Downtime für das Downgrade ungefähr?
Überlege wirklich diesen Schritt zu gehen, aber habe keine Ahnung vom nötigen Zeitfenster.
CFG der 2.4.5/19.1 habe ich glücklicherweise.

Ein weiteres Problem ist übrigens noch, dass ich keine DHCP-Leases mehr ansehen kann.

Zu Hause läuft alles problemlos, allerdings in virtualisierter Umgebung ohne Multi-WAN.