2.5.2 entwickelt sich IMHO sehr gut

JeGr

@p54 kommt aber hart drauf an, wie man das eben im Devel-Team organisiert hat und was damit gemeint ist. Wir nutzen selbst auch Redmine intern und der Feedback Status ist bei uns intern im Team. Sprich der Status symbolisiert, dass der Ticket-Eigentümer noch mit/von irgendwem Feedback einholt oder nachfragen muss und es deshalb nicht weiter geht. Also quasi ein Blocker. Da ich keinen Einblick habe, wie Netgate das nutzt kann @fireodo natürlich recht haben und es sind User gemeint, es kann aber genauso gut internes Feedback durch Testbenches oder andere Prozesse gemeint sein :)

fireodo

@jegr said in 2.5.2 entwickelt sich IMHO sehr gut:

natürlich recht haben und es sind User gemeint, es kann aber genauso gut internes Feedback durch Testbenches oder andere Prozesse gemeint sein :)

Ich bezog mich hauptsächlich auf diese von Jim (Pingle) getätigte Aussage auf redmine:
"Will hold open for now to wait for additional feedback, but can be closed if none is received before release." (11805)
als Antwort auf mehrere User Posts.

Schönes WoE,
fireodo

JeGr

@fireodo Ja klar, war auch keine direkte Kritik an dir. Man weiß nur nicht ob das generell so gehandhabt wird oder in dem Fall nur. Trotzdem gut erkannt :)

Was sich jetzt bei der 2.5.2RC im letzten Snapshot m.E. auch verbessert hat ist das OVPN reconnection handling. Ich hatte dazu schon nen Bugpost aufgemacht, da bei gesetzten "explicit exit notifiy" auf 1 oder 2 gerade Tunnel einem schön um die Ohren geflogen sind. Sprich: statt exit notify hat die entsprechende Seite den Tunnel beendet statt nur mitzubekommen, dass die Gegenstelle sich abgemeldet hat. Bei S2S Tunneln hatte das die Auswirkung, dass - sollte es gesetzt gewesen sein - sich bei einem Restart der Seite A die Seite B einfach den Service beendet hat. Seite A konnte nach Restart dann nicht mehr verbinden.

Gleiches Spiel gabs bei RAS Clients auch, dann war der ganze Server weg. Das habe ich zumindest in letzter Instanz jetzt bei RAS Clients (Tunnel noch keine Zeit) nicht mehr, statt dessen wird jetzt - extrem sauber und schnell! - erkannt, dass der Client sich disconnected hat und der Client steht nicht mehr elend lang in der Connection list bis er timeouted (wenn in der Client Conf explicit-exit-notify drin ist natürlich). Umgekehrt ist es beim Server dann so, dass Clients sofort(!) auf Stufe gelb wechseln und nach 5s die Verbindung neu aufbauen, wenn vom Server ein "Restarte" kommt. Sehr gut, weil man damit die Downtime bei Änderungen an der Config minimieren kann - nach 10s sind die Clients wieder da. (5s timeout, 5s beim User/Passwort Dialog)

Muss noch das Verhalten bei S2S testen, sieht aber bislang sehr gut aus.

p54

@jegr Ah sehr guter Hinweis mit dem timeout, danke. cya

JeGr

@jegr said in 2.5.2 entwickelt sich IMHO sehr gut:

Muss noch das Verhalten bei S2S testen, sieht aber bislang sehr gut aus.

Mein erster Test zwischen 2.5.2RC und 2.6 war bei Tunnelsetup auf den ersten Blick wieder genau das beschriebene Problem. Hat man einen Tunnel und auf beiden Enden Retry Once ausgewählt wird bei Restart einer Seite der Tunnel auf der anderen Seite beendet (entsprechender Prozess stirbt).

Irgendwie kann ich nicht glauben, dass das Absicht sein soll.

slu

Guten Morgen, ich hab sehr gute Nachrichten!

Alle die über ein ABO Verfügen erhalten bald die 2.5.2:
https://redmine.pfsense.org/projects/pfsense/repository/revisions/1fe8f376e40d17284bce10006b5103f3d1386023/diff/tools/templates/pkg_repos/pfSense-repo.conf

:)

fireodo

@slu said in 2.5.2 entwickelt sich IMHO sehr gut:

Alle die über ein ABO Verfügen

Was heisst das konkret - muss man sich irgendwo anmelden, oder?

slu

@fireodo said in 2.5.2 entwickelt sich IMHO sehr gut:

Was heisst das konkret - muss man sich irgendwo anmelden, oder?

Ach jetzt hast Du mir so schnell den Spaß genommen, wärst Du am Freitag [1] dabei gewesen...
Nein Du brauchst natürlich kein Abo...!

[1] https://forum.netgate.com/topic/164613/pfsense-usergroup-008-2021-07-02-17-00

fireodo

@slu said in 2.5.2 entwickelt sich IMHO sehr gut:

Ach jetzt hast Du mir so schnell den Spaß genommen, wärst Du am Freitag [1] dabei gewesen...
Nein Du brauchst natürlich kein Abo...!

Ich kann den Post ja schnell löschen ...

slu

@fireodo

slu

Und jetzt findet sie auch der Updater :)

JeGr

@slu Jup, gerade kam das Announcement, dass die Freigabe raus ist. Officially released.

Bob.Dig

Läuft... bis jetzt.

fireodo

@bob-dig said in 2.5.2 entwickelt sich IMHO sehr gut:

Läuft... bis jetzt.

Auch hier ... bisher keine Auffälligkeiten, aber das Update ist ja noch "jung"

slu

@fireodo said in 2.5.2 entwickelt sich IMHO sehr gut:

@bob-dig said in 2.5.2 entwickelt sich IMHO sehr gut:

Läuft... bis jetzt.

Auch hier ... bisher keine Auffälligkeiten, aber das Update ist ja noch "jung"

Schon zwei Systeme auf 2.5.2 keine Probleme soweit.

p54

Auch hier alles herrlich. Sieht wirklich gut aus. Schönen Abend euch.

Gladius

Nach einigem Zögern bin ich jetzt auf 2.5.2. Der Sprung von 2.4.5 gleich auf 2.5 war mir zu heiß.
Hoffe, daß es keine Probleme mit OpenVPN gibt. OpenVPN nutze ich in verschiedenen Szenarien.

Update verlief über GUI verlief glatt!

LG
Gladius

noplan

@gladius said in 2.5.2 entwickelt sich IMHO sehr gut:

eine Probleme mit OpenVPN gibt

und gabs Probleme ?

wir haben alle heiklen openVPN boxen
mit ignore openVPN2.5 config gesetzt .. .. bisher keine bekannten Probleme
ein paar haben das update noch gar nicht mitbekommen

Gladius

@noplan

Wie erhofft läuft OpenVPN 2.5.2 serverseitig stabil. Werde mal CHACHA20-POLY1305 für den Datenkanal ausprobieren. Bisher ist es vorzugsweise AES-256-GCM.

LG
Gladius

JeGr

@gladius said in 2.5.2 entwickelt sich IMHO sehr gut:

Wie erhofft läuft OpenVPN 2.5.2 serverseitig stabil. Werde mal CHACHA20-POLY1305 für den Datenkanal ausprobieren. Bisher ist es vorzugsweise AES-256-GCM.

Macht auf x64 absolut keinen Sinn. Man sollte sich informieren, was für was gedacht ist.
Zitat:

ChaCha20-Poly1305 is much faster than AES on systems that do not have AES hardware (anything mobile or ARM).

Das war der Grund warum Cloudflare am CDN Entrypoint Chacha20 gepusht hat, damit mobile Seiten schneller werden. Oder Mobile VPN. Aber für alles, was AES-NI inside hat und x64 ist, bringt Chacha20 keinen wirklichen Gewinn und ist langsamer als AES-GCM.

Einfach für Roadwarrior beides in die Cipherlist, RW Mobiles auf Chacha und Rechner/Tunnel auf GCM, done.