Hallo!
Ich rätsle gerade an einem Problem, dass ich mir nicht wirklich erklären kann und hoffe jemand kann mir Tipps (wenigstens wo ich weitersuchen sollte) geben.
Mehrmals am Tag kommt es vor, dass bei mir alle Verbindungen unterbrochen werden und kurz danach wieder da sind. An der Internetverbindung liegt es nicht, das sehe ich am dpinger bzw. hab ich mir vom Provider bestätigen lassen.
Was ich sehe im log:
2021-06-24T14:34:44 configd.py[47025] [e919daad-0451-4a82-8415-623bc661a131] list gateway status
2021-06-24T14:30:50 configd.py[47025] message d485fda5-ea86-4ea2-8ef3-f758f72cd26f [filter.refresh_aliases] returned {"status": "ok"}
2021-06-24T14:30:49 configd.py[47025] [8027f6fc-f0a2-48f3-b5a7-064bb5561c51] updating dyndns VPN_GW
2021-06-24T14:30:49 configd.py[47025] [d485fda5-ea86-4ea2-8ef3-f758f72cd26f] refresh url table aliases
2021-06-24T14:30:49 configd.py[47025] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2021-06-24T14:30:49 configd.py[47025] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2021-06-24T14:30:49 configd.py[47025] generate template container OPNsense/Filter
2021-06-24T14:30:49 configd.py[47025] [cc148b55-e8c0-470f-8618-13d0deb41f63] generate template OPNsense/Filter
2021-06-24T14:30:47 configd.py[47025] [c61598d8-17ae-4659-9dc5-93871b3cf33b] Reloading filter
2021-06-24T14:29:58 configd.py[47025] message 8891af83-638a-4946-b25a-d23d50eace8a [filter.refresh_aliases] returned {"status": "ok"}
2021-06-24T14:29:57 configd.py[47025] [1a5ac345-98b2-43c4-9183-c8d73515bfc3] updating dyndns VPN_GW
2021-06-24T14:29:57 configd.py[47025] [8891af83-638a-4946-b25a-d23d50eace8a] refresh url table aliases
2021-06-24T14:29:57 configd.py[47025] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2021-06-24T14:29:57 configd.py[47025] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2021-06-24T14:29:57 configd.py[47025] generate template container OPNsense/Filter
2021-06-24T14:29:57 configd.py[47025] [706be1f1-77ca-4c1d-95cf-0494ff31b2d7] generate template OPNsense/Filter
2021-06-24T14:29:55 configd.py[47025] [cc3e9799-a436-4fee-8419-d18bfb43cf4a] Reloading filter
2021-06-24T14:29:41 configd.py[47025] message 6e723f60-178e-4cf2-992b-e106109d3aaa [filter.refresh_aliases] returned {"status": "ok"}
2021-06-24T14:29:41 configd.py[47025] [3d0c13b4-1cd8-4d32-b9ee-61fb2818e6fe] updating dyndns VPN_GW
2021-06-24T14:29:41 configd.py[47025] [6e723f60-178e-4cf2-992b-e106109d3aaa] refresh url table aliases
2021-06-24T14:29:41 configd.py[47025] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2021-06-24T14:29:41 configd.py[47025] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2021-06-24T14:29:40 configd.py[47025] generate template container OPNsense/Filter
2021-06-24T14:29:40 configd.py[47025] [794eedd3-3dd0-47a6-bca5-19a75acf741c] generate template OPNsense/Filter
2021-06-24T14:29:39 configd.py[47025] [c09aa6f7-84dc-49e7-8c6f-c82134f9df2d] Reloading filter
2021-06-24T11:20:56 configd.py[47025] [325c0bf0-1171-43b1-86f2-195c2792b273] Retrieve firmware product info
2021-06-24T11:20:56 configd.py[47025] [2a929250-4fba-4646-a5f5-9bd62f6bed2c] request filter log output
unter pfTop sehe ich, dass alle Verbindungen zu diesem Zeitpunkt neu gestartet werden (age 0), was irgendwie klar ist, wenn die Regeln neu initialisiert werden. Ich verstehe nur nicht warum.
Was ich noch sehe, ist eine erhöhte (aber nicht hohe) Zahl an Paketen die von extern geblockt werden.
(http://wan_traffic.png)
Wobei die CPU Last nicht kritisch aussieht.
(http://processor.png)
Im Liveview hat das nach einem distributed Portscan ausgesehen. Die Anzahl der Verbindungsstates war ~3k.
Ich hab OPNsense 21.1.7_1-amd64, läuft virtuell mit 2 cores, 2GB RAM, surricata läuft, monit meldet keine Probleme auch sonst hab ich noch nichts auffälliges gefunden.
Jemand Ideen wo ich suchen soll oder was da schief läuft? Wäre für Hinweise sehr dankbar!
Danke!
Lösung siehe reply #6 (https://forum.opnsense.org/index.php?topic=23668.msg113078#msg113078 (https://forum.opnsense.org/index.php?topic=23668.msg113078#msg113078))
Also selbst wenn die Rules neu laden bleiben die Verbindungen normalerweise offen.
Beispiel: Du hast eine ausgehende SSH Verbindung, erstellst während der Verbindung eine block Rule und drückst auf Übernehmen, die Verbindung bleibt trotzdem offen... Bis zum schließen oder bis der State abgelaufen ist.
Hast du evtl. auf deiner Virtualisierungsplattform noch eine Firewall auf der Schnitstelle aktiv? Vielleicht blockt die ja auch schon was.
Und kannst du das Szenario reproduzieren?
Danke für die Antwort. Zweite FW habe ich nicht, das WAN IF ist per pass-through direkt zu opnsense gemapt. Was mir bei einer anderer Unterbrechung aufgefallen ist, war der angehängte Log. Offenbar ein Portscan oder so.
Hab heute versucht per flood ping die FW zu irritieren, hat keine Auswirkung gehabt.
Heute hatte ich keinerlei Unterbrechungen, die letzten Tage regelmäßig, aber ich wüsste leider nicht wie ich das reproduzieren kann, da mir die Idee für das Kriterium fehlt. Hatte kurz die Virtualisierung in Verdacht, aber ich verstehe nicht, warum keine Probleme auftreten, außer, dass die Filter innerhalb kürzester Zeit mehrfach neu geladen werden. Keine Ahnung, wie ich das auslösen könnte.
Irgendwelche VPN Verbindungen aktiv?
Ich habe das schon seit langer Zeit immer mal wieder, mehrmals am Tag. Dann ist wochenlang Ruhe.
QuoteIrgendwelche VPN Verbindungen aktiv?
Ja, eine dauerhafte openVPN Verbindung, die dann natürlich auch zusammenbricht, aber nach einiger Zeit wieder aufgebaut wird (vom Client).
QuoteIch habe das schon seit langer Zeit immer mal wieder, mehrmals am Tag. Dann ist wochenlang Ruhe.
Das Muster kommt mir bekannt vor.
Irgendwelche Ideen, was die Ursache sein könnte, wo ich weitersuchen kann?
Nope. Geht so seit Jahren. Kann sein, dass es bei pfsene (hatte ich vorher) auch schon so war. NSA/GCHQ resettet den Cache für deine VPN Daten? Keine Ahnung...
Firewall: Settings: Advanced: "Disable State Killing on Gateway Failure" ist deaktiviert?
Grüsse
Franco
Quote from: franco on July 01, 2021, 04:26:58 PM
Firewall: Settings: Advanced: "Disable State Killing on Gateway Failure" ist deaktiviert?
Grüsse
Franco
Öhm, nein, hier nicht (also diese Option ist nicht gewählt).
Im Gateway Protokoll sehe ich für den letzten Zeitpunkt, bei dem ich mich an diesen "Reset" erinnern kann (29-JUN um 09:24):
2021-06-29T10:31:27 dpinger[53488] GATEWAY ALARM: WAN_DHCP (Addr: 9.9.9.9 Alarm: 0 RTT: 83604us RTTd: 54351us Loss: 10%)
2021-06-29T10:31:27 dpinger[8636] WAN_DHCP 9.9.9.9: Clear latency 83604us stddev 54351us loss 10%
2021-06-29T10:30:25 dpinger[31058] GATEWAY ALARM: WAN_DHCP (Addr: 9.9.9.9 Alarm: 1 RTT: 51472us RTTd: 4646us Loss: 22%)
2021-06-29T10:30:25 dpinger[8636] WAN_DHCP 9.9.9.9: Alarm latency 51472us stddev 4646us loss 22%
2021-06-29T09:26:21 dpinger[33754] GATEWAY ALARM: WAN_DHCP (Addr: 9.9.9.9 Alarm: 0 RTT: 62745us RTTd: 41610us Loss: 13%)
2021-06-29T09:26:21 dpinger[8636] WAN_DHCP 9.9.9.9: Clear latency 62745us stddev 41610us loss 13%
2021-06-29T09:25:18 dpinger[58956] GATEWAY ALARM: WAN_DHCP (Addr: 9.9.9.9 Alarm: 1 RTT: 49817us RTTd: 3169us Loss: 22%)
2021-06-29T09:25:18 dpinger[8636] WAN_DHCP 9.9.9.9: Alarm latency 49817us stddev 3169us loss 22%
2021-06-29T09:25:06 dpinger[66332] GATEWAY ALARM: WAN_DHCP (Addr: 9.9.9.9 Alarm: 0 RTT: 50250us RTTd: 3701us Loss: 16%)
2021-06-29T09:25:06 dpinger[8636] WAN_DHCP 9.9.9.9: Clear latency 50250us stddev 3701us loss 16%
2021-06-29T09:24:02 dpinger[25748] GATEWAY ALARM: WAN_DHCP (Addr: 9.9.9.9 Alarm: 1 RTT: 51127us RTTd: 3271us Loss: 22%)
2021-06-29T09:24:02 dpinger[8636] WAN_DHCP 9.9.9.9: Alarm latency 51127us stddev 3271us loss 22%
Der Haken ist also drin? Jedoch schon mal interessant, dass es mit dem Gateway Monitoring zu tun hat. Passiert das auch wenn es aus ist?
Grüsse
Franco
Quote from: franco on July 01, 2021, 05:02:59 PM
Der Haken ist also drin?
Nein, der Haken ist raus ;-)
Quote from: franco on July 01, 2021, 05:02:59 PM
edoch schon mal interessant, dass es mit dem Gateway Monitoring zu tun hat. Passiert das auch wenn es aus ist?
Grüsse
Franco
Ich hatte hin und wieder mal ein paar Monate kein Gatewaymonitoring. Das brachte iirc keine Veränderung.
Systematisch schwer zu untersuchen, da manchmal wirklich wochenlang (monatelang?) nix ist, dann wieder 5x am Tag, dann 2 Tage nix, dann 3x am Tag, das für ein paar Tage und dann ist wieder Ruhe im Karton.
> Nein, der Haken ist raus ;-)
Dann rein damit, denn das wird auch der Grundzustand ab 21.7 für neue Installationen. Das Problem ist aus dem Support bekannt.
Allerdings scheint der Paketverlust ja nicht imaginär zu sein. Hängt da eine Fritzbox oder ähnliches davor?
Grüsse
Franco
Quote from: franco on July 02, 2021, 08:58:12 AM
> Nein, der Haken ist raus ;-)
Dann rein damit, denn das wird auch der Grundzustand ab 21.7 für neue Installationen. Das Problem ist aus dem Support bekannt.
Habsch gestern gemacht. Kann jetzt halt dauern...
Warum ist das überhaupt by default so gesetzt (gewesen)? :-)
Quote from: franco on July 02, 2021, 08:58:12 AM
Allerdings scheint der Paketverlust ja nicht imaginär zu sein. Hängt da eine Fritzbox oder ähnliches davor?
Grüsse
Franco
Ein Kabelrouter des Providers im Modem-Mode (wurde letzthin getauscht, kann's also nicht sein). Sind die Spezialexperten, die letzthin einen Filter im lokalen Kabelnetz eingesetzt hatten, worauf kein Uplink mehr ging und für 10 Tage der Anschluß tot war. Und der Verbindungsaufbau nach Änderung der MAC-Adresse für WAN braucht immer 2-3 Reboots (neue IP wird vergeben, Verbindung steht, Tunnel sind aufgebaut und nach 1-2 Minuten ist das Gateway weg. Reboot Modem und sense. Geht. Oder auch nicht, dann braucht es einen weiteren Reboot. Ich hatte dann mal probiert auf dem WAN einen Hostname zu senden, das brachte aber keine Verbesserung, iirc wurde dann wieder die selbe IP vergeben und das war ja nicht Sinn der Übung).
Will sagen: Die haben ihr Netz nicht so richtig im Griff. Aber sie sind TINA... :-(
Eine interessante Frage.. historischer Kontext:
https://github.com/pfsense/pfsense/commit/af0a477a1fe1
https://redmine.pfsense.org/issues/3183
Das war auch bei uns so bis:
https://github.com/opnsense/core/commit/f80081f110
Bei der Migration von isset -> !empty fiel leider der leere Default Wert unter den Tisch bzw. hat auch hier schon vorher nicht immer funktioniert durch andere Umbau-Aktionen. Dieser seltsame Zustand war in 20.1 noch so und in 20.7 war es dann wieder korrekt mit der Ausnahme, dass der alte Default-Wert nicht mehr gelesen werden kann und als abgewählt galt.
Wir bewegen uns also mit 21.7 zurück auf einen Zustand der der Fork-Situation relativ nahe ist. ;)
Grüsse
Franco
Quote from: franco on July 02, 2021, 09:47:37 AM
Eine interessante Frage.. historischer Kontext:
https://github.com/pfsense/pfsense/commit/af0a477a1fe1
https://redmine.pfsense.org/issues/3183
Das war auch bei uns so bis:
https://github.com/opnsense/core/commit/f80081f110
Bei der Migration von isset -> !empty fiel leider der leere Default Wert unter den Tisch bzw. hat auch hier schon vorher nicht immer funktioniert durch andere Umbau-Aktionen. Dieser seltsame Zustand war in 20.1 noch so und in 20.7 war es dann wieder korrekt mit der Ausnahme, dass der alte Default-Wert nicht mehr gelesen werden kann und als abgewählt galt.
Wir bewegen uns also mit 21.7 zurück auf einen Zustand der der Fork-Situation relativ nahe ist. ;)
Grüsse
Franco
Aha. Bahnhof. ck. Tomate.
Wird wohl dann so besser sein, in Zukunft? :-)
Oder eben in der Vergangenheit. Naja, mal so mal so. :)
Grüsse
Franco
Oh, das sind aber interessante Informationen, danke!
Ich habe den Haken jetzt auch gesetzt, siehe Anhang.
Was ich sehe ist, dass ich am VPN Gateway zu den fraglichen Zeiten packet loss habe, während das default (upstream) Gateway perfekt funktioniert.
Quote from: franco on July 02, 2021, 09:47:37 AM
Das war auch bei uns so bis:
https://github.com/opnsense/core/commit/f80081f110
Dem entnehme ich, dass wenn
irgendein Gateway den Zustand auf "down" ändert, werden alle Verbindungen rückgesetzt, korrekt?
Ein ziemlich radikale Methode ... Ich hab die Option gesehen und darüber nachgedacht, aber offenbar fälschlich angenommen, dass das entweder nur das "default" Gateway oder nur die über das betroffenen Gateway laufenden Verbindungen betrifft. Offenbar sind es aber alle Verbindungen, falls ein beliebiges Gateway das gemonitored wird ausfällt.
Hab den Haken mal gesetzt, werde schauen ob das hilft, alternativ könnte man ja auch die
Packet Loss thresholds höher setzen um das Problem zu reduzieren.