verliert nach einiger Zeit TCP, ICMP läuft ohne Probleme

[MadCat]

Hi,

habe vor einiger Zeit meinen Server von WHS 2011 auf Win10 pro x64 1709 umgestellt.

Greife auf den Server normal per remote-Deskop zu. Alternativ kann ich auch
per IPMI-mgmt-kvm drauf zugreifen.

Nach einiger Zeit passiert folgendes:

Alle lokal laufenden Anwendungen haben keinen Zugriff auf auch lokal laufende Netzwerk basierenden Dienste.

D.h. lokales Traytool für Mailserver kann sich selbst über die 127.0.0.1 nicht verbinden, telnet auf localhost 80 (webfrontend des Webservers) geht ebenfalls nicht.
Es gehen dann auch keinerlei Verbindungen nach "draußen", sprich surfen, Updates des AVs, etc. - alles schlägt fehl.

ICPM (ping und traceroute, wie auch Nameserverabfragen) laufen einwandfrei.

D.h. ich kann localhost und auch Webseiten per Namensauflösung pingen oder einen Traceroute dahin aufrufen.

Interessant dabei ist, dass von außen kommende Dienste, wie der Zugriff auf den oben erwähnten Mailserver, oder auch Gameserverinstanzen, TS-Server und eben halt auch auf den Server via RDP weiterhin möglich sind. Ebenso klappt weiterhin der Zugriff auf die freigegeben Laufwerke.

Nach einem Neustart läuft das eine weile ganz normal, Firewall wurde auch schon deaktiviert, AV ebenfalls.

Treiber wurden alle auf aktuellst möglichen Stand gezogen.
Windowsupdate ist auch komplett up to date.

Rechnerkonfig:

Supermicro X10SLM-F
Intel i3-4130T
8 GB DDR 3 ECC
div Laufwerke...

Mir gehen so langsam die Ideen aus...

[xiao didi *]

Mal ins Blaue geraten: Zu viele eingehende TCP-Verbindungen? Desktop Versionen unterstützen maximal 20.

[MadCat]

Hi,

hmmm, also die einzelnen Zugriffe vom Mailserver, die offen gehaltenen Ports für die laufenden Games/TS sind irgendwann mal so viel, dass der TCP-Stack keine weiteren Verbindungen zulässt?

Das wäre ne Möglichkeit. Das spricht auch für die weiterhin möglichen Zugriffe von außen...

Gibts da ne Möglichkeit per registy-Eintrag zu erhöhen?

EDIT: grad mal netstat aufgerufen... da laufen schon ein paar Bildschirme an Verbindungen durch...

Hab da was bzgl. Registry gefunden:

"EnableConnectionRateLimiting=0"

Hab den Schlüssel mal erstellt und warte mal ab...

[xiao didi *]

Hab da was bzgl. Registry gefunden:

"EnableConnectionRateLimiting=0"

Hab den Schlüssel mal erstellt und warte mal ab...
Das bezieht sich wohl nur auf halboffene TCP-Verbindungen.

Ob man das Limit für eingehende Verbindungen erhöhen kann, weiß ich nicht und hab dazu auch nichts gefunden. Ich würde auch bezweifeln, dass das geht, da das Limit wohl nur dazu dient, Server Versionen zu bevorteilen.

[MadCat]

Hi,

heute Morgen war es wieder so weit:

Seitenweise

TCP 192.168.77.100:65416 fritz:49000 SCHLIESSEN_WARTEN
bei netzstat

Hab kurz gesucht und gefunden, das es wohl die Statusinfos via upnp der F!B sind.
Hab upnp in der F!B kurzerhand für diese Statusinfos deaktiviert.
Mal sehen, ob das was bringt.

[MadCat]

hmmm,

trotz abgeschaltetem upnp der F!B sieht die netstat-sache nicht besser aus:
TCP-Statistik für IPv4

Aktiv geöffnet = 19821
Passiv geöffnet = 21319
Erfolglose Verbindungsversuche = 36
Zurückgesetzte Verbindungen = 6751
Aktuelle Verbindungen = 944
Empfangene Segmente = 640667
Gesendete Segmente = 669530
Erneut übertragene Segmente = 545

Irgendwie mal schauen, was der Unterschied zu meiner Workstation ist...

[Exxtreme]

Man kann das Limit schon erhöhen indem man ein paar DLLs austauscht. Nur ist das ein Lizenzverstoß. Und ja, das Limit haben alle Home und Workstation-Versionen von Windows drinne. Nur bei den Serverversionen ist es nicht da.

[stimulator]

Wenn man einfach mal googelt ob das Problem noch relevant ist?

https://www.google.is/search?q=tcp+half+open+windows

Das gibt's wohl schon seit Vista SP2 nicht mehr.

[MadCat]

Hi,

So sieht es heute Abend aus:

TCP-Statistik für IPv4

Aktiv geöffnet = 62189
Passiv geöffnet = 67865
Erfolglose Verbindungsversuche = 254
Zurückgesetzte Verbindungen = 23967
Aktuelle Verbindungen = 1496
Empfangene Segmente = 1795330
Gesendete Segmente = 1894944
Erneut übertragene Segmente = 2193

Schon imposant.

TCP 192.168.77.100:49182 fritz:49000 SCHLIESSEN_WARTEN
Davon sind 1333 wie die o.g.

Zum Vergleich mal 'ne normale Workstation:

TCP-Statistik für IPv4

Aktiv geöffnet = 1248
Passiv geöffnet = 942
Erfolglose Verbindungsversuche = 41
Zurückgesetzte Verbindungen = 816
Aktuelle Verbindungen = 34
Empfangene Segmente = 228405
Gesendete Segmente = 214588
Erneut übertragene Segmente = 2740

[stimulator]

Wenn Du testweise das mal in eine Eingabeaufforderung mit Adminrechten eingibst:

netsh advfirewall firewall add rule name="FritzFix" dir=out remoteport=49000 protocol=tcp action=block

Das sollte zumindest schonmal verhindern, dass Dir die lokalen Ports ausgehen die Du für neue Verbindungen brauchst.

[MadCat]

Hi,

danke für die FW-regel. Hab die Kiste jetzt nochmal rebootet und schaue, ob sich das wieder hochschaukelt.
Zudem hab ich mal ein Ticket bei AVM wegen des Port 49000 auf gemacht.
Mal gespannt, ob dir mir einen Hinweis geben können.
Meine anderen W10-Rechner machen da keine Verbindung hin auf.

...

Nach dem Neustart werden erwartungsgemäß keine Verbindungen mehr aufgebaut. Wurde ja durch die FW-Regel unterbunden.

Vielleicht muss ich doch mal den wireshark installieren und das mitsniffen.
Wäre schon interessant zu sehen, was da stattfindet.

So sieht das jetzt nach Neustart und Start aller angedachten Applikationen:

TCP-Statistik für IPv4

Aktiv geöffnet = 548
Passiv geöffnet = 426
Erfolglose Verbindungsversuche = 84
Zurückgesetzte Verbindungen = 59
Aktuelle Verbindungen = 220
Empfangene Segmente = 23017
Gesendete Segmente = 24565
Erneut übertragene Segmente = 56
Mal in einer Stunde schauen, aber da dürfte ja nix mehr passieren.

EDIT @ 2225:

Verbindungen sind nun bei unter 150. Und das bei allen geplant laufenden Diensten - das sind IMHO nicht wenig.

EDIT @ 2348:

Regel läuft super. Auf dem Port antwortet übrigens ein Webserver auf der F!B - mit einem 404.

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=62301&stc=1&d=1515451793

Hab mal die relevanten Pakete mitgeschnitten und pcapng angehangen (gezippt).
Ich werde da nicht ganz schlau draus...

EDIT @ 0649:

Hab dem vorher keine Beachtung geschenkt:

"TR-064 (Ports 49000/49443)"

https://www.janrufmonitor.de/tr-064-aktivieren/

Die Option ist bei mir aktiv, aber auf dem Server ist keine Software installiert, die mit der F!B sprechen können müsste.
Die Option ist wegen der FritzFone-App für mein Mobiltelefon an.

Also warum sollte nun mein Server versuchen, die TR-064-Schnittstelle an der F!B zu benutzen? Und auf Grund welchen Prozesses?

[stimulator]

Wenn Du unter wf.msc die Firewall-Regel wieder rauslöschst, kann Du im Resource Monitor (perfmon.exe /res) im Netzwerk-Reiter bei TCP-Verbindungen sehen welche Anwendung den Zielport 49000 braucht.

[MadCat]

Hi,

ist was von Intel...

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=62307&stc=1&d=1515516186

Intel(r) Energy Checker SDK. ESRV Service queencreek

Könnte entweder über die Netzwerkkarte, eher über die RSTe-Software/Treiber kommen... Ggf. auch über den automatischen (schon deinstallierten) Treiberupdater von Intel...

EDIT:

der Driver-Helper war doch noch drauf *runterschmeiss*

EDIT2:

Service ist weg... >_> boah, was für ein Müll. Und das alles nur deswegen, weil ich keinen passenden RSTe für mein Board und Win10 gefunden hatte.

@p2hicy nochmal vielen Dank! Ohne die ganzen Tipps wäre das sicher noch ausgeartet ^^