1906VA hängt bzw. startet 'scheinbar' alle Verbindungen neu

[Pauli]

Hallo,

ich habe nun einige Zeit folgendes Problem mit einem 1906VA:

Bei einem stark bzw. stärker ansteigendem Internet-Traffic hängt der 1906VA für eine Minute komplett ( es geht gar nichts). Danach sehe ich dann plötzlich im Log der Geräteaktivitäten die eingerichteten Gegenstellen als nicht verbunden und dann wieder als verbunden.

Interessant dabei ist, dass aber die Verbindungen laut Status Tabellen genauso wie der Router selbst keinen Neustart gemacht haben (Verbindungs- bzw. Betriebszeit läuft weiter). Ich kann nicht genau sagen seit wann das erstmals aufgetreten ist, bin aber nun auf der Suche nach einem Troubelshooting und weiß nicht wo ich ansetzen soll. Hat jemand einen Tipp was oder wo ich überprüfen soll?

CPU Last liegt in der Regel zwischen 5-10%, es gibt zwei Internetleitungen, einen Loadbalancer und in dieser Zeit auch 0 VPN Verbindungen. Eff.-IPv4-Routing-Tab hat 170 und Verbindungsliste unter Router ca. 400 Zeilen, was dieses Gerät auch schaffen sollte oder?

Danke für jeden Tipp,
Pauli

[Pauli]

Ich habe nun mal den LB 'wegkonfiguriert' und es scheint damit das Verhalten nicht zu geben.

Hat jemand eine Idee warum das ganze Gerät scheinbar für 30 Sekunden weg ist, wenn ich mal einen Browser mit 50 Tabs aufmachen (passiert auch anderweitig, nur damit kann ich es ganz gut provozieren)?

Ich habe schon viele Jahre einen LB den ich für den normalen Traffic nutze. Die Leitungen sind von der Kapazität ähnlich und mittlerweile überwacht das ganz dann die Dynamic Path Selection. Irgendwas scheint hier nicht zu passen, aber bewusst habe ich nichts gerändert nur immer die aktuellste FW eingespielt.

Pauli

[GrandDixence]

Bei praktisch allen aktuell gepflegten LCOS-Versionen wurde vor kurzem ein Fehler in der DoS-Erkennung behoben (halboffene Verbindungen). Vielleicht liegt es an diesem Programmierfehler.

[Pauli]

Danke für den Hinweis, DoS Meldungen hatte ich immer mal und ich bin jetzt zurück auf die 10.80SU8, da das Phänomen irgendwann im Herbst erstmal feststellbar war. Ich werde berichten ...

Der Fehler wurde in der aktuellen RC 10.90 noch nicht behoben oder?

Pauli

[Pauli]

Guten Morgen,

nach vielen Tests mit unterschiedlichen FW habe ich vermutlich die Ursache gefunden:

Ich habe eine Blockliste (Stations-Objekte) mit diversen IP-Bereichen aus China etc., die dann in der ersten FW Regel genutzt wird um Pakete von diesen Quellen zu verwerfen. Natürlich kommt da ein bisschen was zu Stande, sprich das System teilt so ein Stations-Objekt dann in ca. 200 einzelne Objekt auf, was scheinbar bei etwas höherem Trafik den ganzen Router zum Aussteigen bringt.

Also Fazit scheint zu sein, dass ein Lancom Router dieser Klasse es nicht schafft eine größere Anzahl von Objekten zu bearbeiten ohne Probleme zu machen, denn ich wüsste auch nicht was man hier falsch oder ungünstig konfigurieren kann? Gibt es dazu offizielle Aussagen oder Grenzwerte, die sollte man dann ja kennen, wenn das ganze über Lanconfig ohne Probleme konfigurierbar aber nicht funktionell ist?

Sobald ich die Regel deaktiviere kann ich keine Hänger mehr provozieren.

Pauli

[backslash]

Hi Pauli,

200 Filter sind aber ehrlich gesagt "nichts".... ein LANCOM kann eigentlich problemlos mit tausenden arbeiten.

Kann es sein, daß du in die Regel besonders sicher gestalten wolltest und Aktionen wie "Zielport sperren" oder "Absender sperren" eingetragen hast?

BTW: da du schreibst, daß es beim starten eines Browsers mit 50 Tabs passiert: kann es sein, daß das LANCOM das als IDS-Angriff sieht? Hast du schonmal versucht, die IDS-Aktion testweise auf "übertragen" zu stellen?

Gruß
Backslash

[Pauli]

Also nicht 200 Filter sondern ich hatte gesehen das die eine Objektdefinition in 200 aufgeteilt wird, also ich rede von der Objekt-Tabelle der Firewall. Auf der Weboberfläche sehe ich unter Konfiguration > Firewall/QoS > IPv4-Regeln > Objekt-Tabelle aus meinem einen Objekt Blacklist 200 nach der Muster BLACLIST-IP0, BLACLIST-IP1, ... BLACLIST-IP200 werden. Die Filterliste wird dann dadurch 23000 Zeilen stark.

Grundsätzlich ist da nix besonderes an und die Regel sieht so aus:

Name INFO: BLOCK_BLACKLIST
Prot. VALUE: ANY
Source VALUE: BLACKLIST-IP
Destination VALUE: LOCALNET
Action VALUE: BLACKLIST
LB-Policy VALUE:
LB-Switchover VALUE: No
Linked VALUE: No
Prio VALUE: 500
Firewall-Rule VALUE: Yes
Stateful VALUE: Yes
Src-Tag VALUE: 0
Rtg-tag VALUE: 0
Comment VALUE:

Wobei dann die Action nur Pro Session und Verwerfen aktiv hat.

Mach hier der Standard-Haken bei Stateful (wie es auf deutsch heißt Verbindungszustände nachhalten) Sinn oder lieber deaktivieren?

Den Hinweis mit IDS werde ich prüfen ..

Vielen Dank.

[backslash]

Hi Pauli

Also nicht 200 Filter sondern ich hatte gesehen das die eine Objektdefinition in 200 aufgeteilt wird,

das liegt einzig allein daran, daß der Speicherplatz in der Spalte "Description" in der Tabelle "/Setup/IP-Router/Firewall/Objects" auf 64 Zeichen beschränkt ist. Um das "eine " Objekt "BLOCKLIST-IP" definieren zu können, wird es von LANconfig in eine Liste von verketteten Objekten der Form

Code: Alles auswählen

Name                              Description
==================================----------------------------------------------------------------
...
BLOCKLIST-IPXXX                   %aaaa.aaa.aaa.aaa %aaaa.aaa.aaa.aaa %aaaa.aaa.aaa.aaa
...
BLOCKLIST-IP                      BLOCKLIST-IP0 BLOCKLIST-IP1 BLOCKLIST-IP2 BLOCKLIST-IP3

aufgespaltet. Der Konfig-Parser in der Firmnware macht daraus zunächst wieder ein Objekt. Da es aber einzelne IP-Adressen enthält wird für jede dieser Adressen am Ende ein Filter erzeugt...

Mach hier der Standard-Haken bei Stateful (wie es auf deutsch heißt Verbindungszustände nachhalten) Sinn oder lieber deaktivieren?

das ist egal, weil die Regel ja als Aktion "verwerfen" hat. Da das direkt auf dem ersten Paket einer Session wirkt und die Session somit gar nicht zustandekommt, gibt es auch keine überwachbaren Zustände

Gruß
Backslash

[Pauli]

Vielen Dank für die Erläuterungen.

Kann es aber sein, dass Stateful in dem Zusammenhang die Last eklatant erhöht? Ich habe den Punkt bei einfachen Block-Regeln rausgenommen und es scheint aktuell, dass die Hänger nicht auftreten (noch nicht endgültig verifiziert).

Seit dem sind die Werte die im DPS angezeigt werden für die gesamten Sessions auch niedriger. Wobei mir nicht ganz klar ist und ich nirgends finden kann was die verschiedenen Session Kennzahlen aussagen bzw. wo sie herkommen:

Screen_20250116-155452.png

Insbesondere die Gesamt Sessions pro Gegenstelle ist genau was? Aber auch warum ist die Aktive Session unten DPS geringer als im LB?

Danke.

[backslash]

Hi Pauli

Kann es aber sein, dass Stateful in dem Zusammenhang die Last eklatant erhöht?

nun ja, ein bischen Last erzeugt das schon, weil die Zustände auch zur Erkennung von z.B. Portscans oder SYN-Flooding herangezogen werden. Das führt aber sicherlich nicht dazu, daß das Gerät quasi "hängt".

Wobei mir nicht ganz klar ist und ich nirgends finden kann was die verschiedenen Session Kennzahlen aussagen bzw. wo sie herkommen:

sie kommen aus der Firewall... Sobald eine Session angelegt wird, wird die Anzahl der Sessions hochgezählt (aktiv und gesamt). Wenn die Session beendet wird, wird die Anzahl der aktiven Sesions wieder erniedrigt.

insbesondere die Gesamt Sessions pro Gegenstelle ist genau was?

Das sind alle dem Interface (jemals) zogeordneten Sessions (s.o.). Der Zähler ist also streng monoton steigend und kann genutzt werden, um z.B. festzustellen wie viele Sessions in einer Sekunde den Interfaces zugeordnet wurden

Aber auch warum ist die Aktive Session unten DPS geringer als im LB?

Im Loadbalancer werden alle Sesssions gezählt, die über ihn laufen (da gibt es i.Ü. nur aktive Sessions), im DPS werden nur die Sessions gezählt, die aufgrund einer Firewallregel mit DPS-Policy (in deinem Fall LB-STD) zugeordnet wurden.
wenn eine Firewallregel matcht, die keine DPS-Policy hat, dann wird die Session nur im der Loadbalancer gezählt, aber nicht im DPS...

Gruß
Backslash

[Pauli]

OK+Danke, damit kann ich abhaken, dass eine Zahl größer einer Million bei den Gesamt Sessions das Problem ist, wenn diese monoton steigt und nix mit aktiven Sessions zutun hat.

Also bin ich wieder am Anfang und habe keine Ahnung was hier das Problem verursacht. An diesen Werten aus dem Status IP-Router fällt Dir auch nichts ungewöhnliches auf?

Eff.-IPv4-Routing-Tab. 157
Filter-Liste 3554
Verbindungsliste 268
Anzahl-Verbindungen 268
ARP-Fehler 2900
LAN-Filter 28372
LAN-Netzwerk-Fehler 2055
LAN-Routing-Fehler 0
LAN-Rx 13583826
LAN-TTL-Fehler 78
LAN-Tx 14968493
Regeln 37
WAN-Filters 10034
WAN-Netzwerk-Fehler 8395
WAN-Rx 14177709
WAN-TTL-Fehler 24
WAN-Tx 12790038
Zerstoerte-Verbindungen 378328

[backslash]

Hi Pauli,

nein - nur daß aus deinen nur 37 Regeln insgesamt über 3500 Filter erstellt wurden. Da sind einige Stations-Objekte extrem abgerollt worden...

Die Anzahl der Filter wirkt sich aber immer nur beim ersten Paket einer Session aus, weil bei dem der jeweilige Filter gesucht werden muß, um die auszuführenden Aktionen zu bestimmen - aber selbst eine lineare Suche durch 3500 Filter würde zeitilch kaum auffallen... Ein "Ausfall" von 30 Sekunden jedenfalls ist dadurch nicht zu erwarten

Aber dennoch könntest du ggf. an den Stationsobjekten optimieren. So ist es z.B. extrem ungünstig eine Range von x.x.x.1-x.x.x.255 anzugeben. Stattdessen wäre ein Netz x.x.x.0/255.255.255.0 die bessere Wahl, denn das erzeugt nur einen Filter statt 8... (noch schlimmer wäre eine Range von x.x.x.1-x.x.x.254 - denn die erzeugt gleich 14 Filter)

Gruß
Backslash

[Pauli]

Moin.

Super, das ist doch mal wieder ein Tipp, der vielleicht auch mal im Handbuch stehen könnte!

Die Anzahl kommt in der Tat von der Blacklist und dort habe ich auch wie Du sagst den schlechtesten Fall einige male verwendet x.x.x.1-x.x.x.254.

Ich werde mal umbauen und schauen was passiert bzw. ob es besser wird. Irgendwo dort muss der Hund aber begraben liegen, denn wenn ich die eine Regel deaktiviere flutsch alles besser und es gibt auch nicht die Hänger. Allerdings hat wie gesagt das deaktivieren von Stateful in den Block-Regeln was gebracht.

Gruß und vielen Dank, Pauli