Messages

Nachdem es heute wieder einen Ausfall gab, habe ich weiter gesucht...wenigstens bin ich nicht alleine mit dem Problem:

https://forum.netgate.com/topic/172075/my-ipsec-service-hangs/68
https://forum.netgate.com/topic/165661/charon-becoming-unresponsive/35
https://redmine.pfsense.org/issues/13014

Folgende Reports habe ich vergessen:
https://github.com/strongswan/strongswan/issues/268
https://github.com/strongswan/strongswan/issues/566

Gibst ein einsprechendes Ticket bei uns? Wenn nicht bitte aufmachen: https://github.com/opnsense/core/issues/new?assignees=&labels=&template=bug_report.md&title=

Und auch die 23.1 probieren denn da hat sich viel bei IPsec getan...


Grüsse
Franco

Danke, werde ich machen  :)

https://github.com/opnsense/core/issues/6308

Gibst ein einsprechendes Ticket bei uns? Wenn nicht bitte aufmachen: https://github.com/opnsense/core/issues/new?assignees=&labels=&template=bug_report.md&title=

Und auch die 23.1 probieren denn da hat sich viel bei IPsec getan...


Grüsse
Franco

Danke, werde ich machen  :)

Interessant, aber warum suchst du nach einer Lösung bei der "Konkurrenz" `?

PfSense und OPNSense haben zwar gemeinsame Wurzel aber da hat sich viel verändert über die Jahre.

Solange ich keine Lösung habe, suche ich nach allem was meinem Problem ähnelt, völlig egal ob "Konkurrenz" oder nicht. Und offenbar gibt es eben insbesondere passende Meldungen im pfSense - aber auch im OPNsense-Lager (siehe bspw. https://forum.opnsense.org/index.php?topic=22224.0).

Nachdem es heute wieder einen Ausfall gab, habe ich weiter gesucht...wenigstens bin ich nicht alleine mit dem Problem:

https://forum.netgate.com/topic/172075/my-ipsec-service-hangs/68
https://forum.netgate.com/topic/165661/charon-becoming-unresponsive/35
https://redmine.pfsense.org/issues/13014

Zusammengefasst:

- noch keine Lösung (seit 1,5 Jahren?!)
- Ursache wahrscheinlich charon.vici queue "Überlauf"
- Problem scheint begünstigt zu werden wenn a) es mehrere Phase 2 Verbindungen mit dem gleichen Subnetz gibt und b) wenn versucht wird nicht aktive Verbindungen zu starten (z.B. durch "interesting traffic" oder keep-alive-Pings)

Es ist also ganz klar der Strongswan der "abschmiert", alle IPsec-Tunnel mit runterreißt und ggf. auch die Webgui blockiert. In keinem einzigen Log gibt es (zeitlich) passende Einträge. Das ipsec/latest.log bleibt einfach stehen bis zum Neustart des Dienstes.

Ich werde meinerseits erstmal auf doppelte Phase 2 Tunnel prüfen, jegliches keep-alive abschalten und den Counter der charon.vici queue monitoren.

Hallo zusammen,

ich möchte dazu noch ergänzen, dass es sich um einen CARP-Failovercluster handelt.

Zwischenzeitlich wurden beide Knoten auf die aktuelle Version 22.7.10 aktualisiert.
Es wurde zuerst der zweite Knoten (CARP Backup) geupdated, dann ein Failover ausgeführt und anschließend der
erste Knoten geupdated. Aktuell laufen die Tunnel also auf dem 2. Knoten der nun vorübergehend Master ist.

Leider kam es gestern dennoch auch wieder zu zwei Totalausfällen.

Habt ihr irgendwelche Ansätze wie ich das weiter analysieren kann?

Viele Grüße

Hallo zusammen,

wir nutzen seit ein paar Monaten OPNsense 22.7.3 als IPsec-Server unter Hyper-V (Xeon E5-2650 v2 @ 2.60GHz (4 cores, 4 threads), 2GB RAM). Das Ganze hängt nicht direkt im Internet sondern wird durch unsere externe Hardware-Firewall (auch OPNsense) geNATed.
In dieser Woche kam es nun aber leider schon zu 3 Ausfällen (1x am 10.01., 2x am 12.01.).

Der Ablauf ist dabei immer:
1. Monitoring meldet dass der Agent nicht mehr erreicht werden kann
2. Die zurzeit 21 IPsec-Tunnel sterben einige Minuten später - das IPsec latest.log ist ebenfalls tot
3. Das Webinterface reagiert nicht mehr oder nur sehr sehr langsam
4. Über SSH führen wir "Reload all services" oder "/usr/local/etc/rc.restart_webgui" aus
5. Wir stoppen/starten den IPsec-Dienst über das Webinterface oder über SHH mit "ipsec stop" und "ipsec start"
Beim letzten Mal haben wir statt Neustart der Dienste einfach einen Reboot gemacht.

In den Logs habe ich bisher keinerlei Hinweise gefunden was da eigentlich passiert und was die Ursache ist. Vielleicht schaue ich an der falschen Stelle oder das Logging ist nicht "gesprächig genug" eingestellt.
Das einzig auffällige im Monitoring ist, dass sich direkt vor dem Ausfall die Anzahl an Threads vervierfacht (ca. 200 statt normal ca. 50).

Die einzige Änderung am System im Vergleich zu der Zeit vor dem ersten Crash ist, dass 3 neue Tunnel hinzugekommen sind. Ob die Schuld sind? Oder dadurch irgendeine Grenze erreicht wurde und wir bestimmte Parameter anpassen müssen?

Bitte helft mir dem Problem auf die Schliche zu kommen.

Hallo zusammen,

wir setzen seit Mai 2022 OPNsense (derzeit Release 22.7.7) als externe Firewall ein und hatten am 02.01. zum ersten Mal und heute am 13.01. schon wieder mit Ausfällen zu kämpfen.

Das äußert sich so, dass alle Verbindungen plötzlich sehr träge sind oder mehrfach unterbrochen werden (z.B. OpenVPN-Tunnel für Homeoffice, SIP-Telefonie). Arbeiten ist dann quasi unmöglich und unsere Systeme sind von außen nicht mehr vernünftig erreichbar, sodass wir gezwungen sind den Server als Notlösung zu rebooten.
Danach läuft alles wieder ohne Probleme.

Leider haben wir überhaupt keinen Ansatz was da überhaupt passiert und wo die Ursache liegen könnte. Über das Webinterface konnte ich in den Logs bisher keine Hinweise finden, außer zeitlich passende Error-Einträge bzgl. DNS-Auflösung von URL-Aliasen und GeoIP-URL aber das ist wahrscheinlich nur ein Symptom. Im Monitoring gibt es scheinbar auch keine Auffälligkeiten wie etwa CPU-Load.

Bitte helft mir, das ganze zu analysieren. Vielleicht schaue ich ja nur nicht an den richtigen Stellen, habe Logging nicht verbose genug eingestellt oder ähnliches  :(

Weitere Infos:
Hardware-Server Fujitsu Primergy mit Xeon E3-1220 V2 @ 3.10GHz (4 cores, 4 threads), 4 GB RAM angeschlossen an Telekom Glasfaser 100 Mbit synchron und Telekom SIP.
Das System ist eine reine Firewall, also kein VPN oder sonstige Services aktiv.
Es kommt GeoIP Blocking zum Einsatz, Aliase dadurch insgesamt 545954 (Firewall Maximum Table Entries auf 2000000 erhöht).
Es werden diverse Dinge rein und raus "geNATed": OpenVPN, IPsec, VOIP, Webserver, SFTP, Mail, Jitsi
Ansonsten sollte alles ziemlich Standardkonfiguration sein.