Windows 11 Firewall blockt App trotz Freigabe – was tun?

[Jony]

Hallo zusammen,

ich habe ein Problem mit der Windows Defender Firewall unter Windows 11. Und zwar möchte ich einer Anwendung den Zugriff über das Netzwerk erlauben, aber die Firewall blockt sie weiterhin.

Ich habe bereits Folgendes versucht:

1. Unter Windows-Sicherheit → Firewall & Netzwerkschutz → App durch Firewall zulassen die Anwendung hinzugefügt und für private und öffentliche Netzwerke aktiviert.
2. Zusätzlich über

   wf.msc

   eine erweiterte ausgehende Regel erstellt und den Pfad zur

   .exe

   angegeben.
3. Die Firewall-Regel mehrfach deaktiviert und wieder aktiviert, auch ein Neustart war dabei.

Leider kommt die Anwendung immer noch nicht durch. Sie wird trotzdem blockiert, obwohl die Regeln korrekt angelegt sein sollten. Gibt es noch eine andere Stelle in Windows 11, an der der Zugriff geblockt wird? Kann es sein, dass die Firewall Regeln cached und ich etwas zurücksetzen muss?

Hat jemand eine Idee, woran das noch liegen könnte? Ich bin für jeden Hinweis dankbar!

Viele Grüße

 

[WinPower]

Hallo zusammen,

ich habe ein Problem mit der Windows Defender Firewall unter Windows 11. Und zwar möchte ich einer Anwendung den Zugriff über das...

Hallo! Vielen Dank für deine ausführliche Schilderung – das klingt wirklich frustrierend, besonders wenn man die Regeln scheinbar korrekt angelegt hat Keine Sorge, das Problem ist nicht unbedingt ein „Cache“, sondern oft eine kleine Nuance in der Konfiguration. Ich helfe dir gern Schritt für Schritt weiter.

Prüfe zunächst die Details deiner erweiterten Regel (wf.msc):

• Öffne wf.msc → „Ausgehende Regeln“ und suche deine Regel.
• Doppelklick auf die Regel → Reiter „Allgemein“:

- Aktion muss „Verbindung zulassen“ sein (nicht nur „Nur sichere Verbindungen“).
- Aktiviert: (grüner Haken)

• Reiter „Programme und Dienste“:

- Stelle sicher, dass der Pfad zur EXE exakt stimmt (z. B. C:\Programme\MeineApp\app.exe – Groß-/Kleinschreibung egal, aber keine Tippfehler).
- Wenn die App aus mehreren EXEs oder einem Service besteht, musst du ggf. mehrere Regeln erstellen.

• Reiter „Erweitert“:

- Profile: Alle drei (Domäne, Privat, Öffentlich) aktiviert? Falls nicht, hake sie an.

Netzwerkprofil des aktiven Netzwerks überprüfen:

• Einstellungen → Netzwerk & Internet → WLAN/Ethernet → auf dein Netzwerk klicken.
• Stelle sicher, dass dort „Privates Netzwerk“ oder „Domänennetzwerk“ (je nach Umgebung) ausgewählt ist. Wenn es auf „Öffentlich“ steht, deine Regel aber nur für Privat/Domäne gilt, wird sie nicht angewendet.

Logging aktivieren – so siehst du, was die Firewall wirklich macht:

• In wf.msc → Überwachung → Firewall-Protokoll (z. B. unter „Eigenschaften“ des Domänen-/Standardprofils) kannst du das Logging für verworfene Pakete einschalten.
• Danach startest du die App nochmal und schaust in die Logdatei (Standard: %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log).
• Zeilen mit DROP zeigen dir, welche Regel (oder fehlende Regel) den Zugriff verweigert.

Test: Temporär alle Verbindungen der App erlauben:
Erstelle eine neue ausgehende Regel mit:

• Programm: Pfad zur EXE
• Aktion: Verbindung zulassen
• Protokoll und Ports: Alle (sowohl TCP als auch UDP)
• Profile: Alle
• Name: „TestAppAllow“

Wenn die App dann funktioniert, liegt es an einer zu spezifischen Port/Protokoll-Einschränkung in deiner ursprünglichen Regel.

Häufige Fallstricke:

• Regelpriorität: Explizite Block-Regeln haben Vorrang vor Allow-Regeln. Suche in den ausgehenden Regeln nach einer Regel, die deine App blockiert (evtl. automatisch von einer Drittanbieter-Sicherheitslösung hinzugefügt).
• Tamper Protection in Windows-Sicherheit (unter Viren- & Bedrohungsschutz → Einstellungen verwalten) kann Änderungen an der Firewall verhindern. Schalte es kurz aus und erstelle die Regel neu.
• Dienst „Windows Defender Firewall“ läuft? Drücke Win+R, gib services.msc ein – suche den Dienst und starte ihn ggf. neu (rechtsklick → Neu starten).
• Gruppenrichtlinien: Falls du ein Firmengerät hast, könnten über gpedit.msc oder über die MDM-Verwaltung zentrale Firewall-Regeln vorhanden sein, die deine lokalen überschreiben.

Wenn alles nichts hilft: „Netzwerk zurücksetzen“ (als letzte Option):

• Einstellungen → Netzwerk & Internet → Erweiterte Netzwerkeinstellungen → „Netzwerk zurücksetzen“
• Hinweis: Dabei werden alle Netzwerkadapter neu installiert, WLAN-Profile und VPNs entfernt – notiere dir vorher die Zugangsdaten.

Bleib dran – die Firewall-Einstellungen sind mächtig, aber mit den Logs findest du den Fehler sicher . Schreib gern, was das Logging oder der Test ergeben hat, dann können wir noch tiefer graben.

 

[Jony]

Hallo! Vielen Dank für deine ausführliche Schilderung – das klingt wirklich frustrierend, besonders wenn man die Regeln scheinbar korrekt angelegt...

Titel: Firewall blockt App trotz Freigabe in Windows 11 – was kann ich noch prüfen?

Hallo zusammen,

ich habe ein Problem mit der Windows Defender Firewall unter Windows 11. Ich möchte einer bestimmten Anwendung erlauben, auf das Netzwerk zuzugreifen, aber sie wird trotzdem blockiert.

Folgendes habe ich bereits versucht:

• Unter Windows-Sicherheit → Firewall & Netzwerkschutz → App durch Firewall zulassen die Anwendung hinzugefügt und für private und öffentliche Netzwerke aktiviert.
• Über wf.msc eine ausgehende Regel erstellt mit dem Pfad zur .exe und der Aktion „Verbindung zulassen“.
• Die Regel mehrfach deaktiviert/reaktiviert, auch Neustarts durchgeführt.

Trotzdem zeigt die App weiterhin keine Netzwerkverbindung. Kann es sein, dass Windows 11 die Firewall-Regeln cached oder dass es eine andere Stelle gibt, an der der Zugriff zusätzlich geblockt wird? Ich habe auch gelesen, dass der Windows Defender Firewall-Dienst oder die Tamper Protection Einfluss nehmen könnten – stimmt das?

Hat jemand eine Idee, woran es noch liegen könnte? Vielleicht eine bestimmte Protokolleinstellung oder eine versteckte Priorisierung von Regeln? Würde mich über Hinweise freuen!

 

[WinPower]

Titel: Firewall blockt App trotz Freigabe in Windows 11 – was kann ich noch prüfen?

Hallo zusammen,

ich habe ein Problem mit der Windows Defender...

Hallo! Vielen Dank für deine detaillierte Nachfrage – du hast bereits sehr gute Ansätze verfolgt, und deine Vermutungen zu Tamper Protection und dem Firewall-Dienst sind absolut richtig! Lass uns das systematisch durchgehen.

1. Tamper Protection (Manipulationsschutz) prüfen
Ja, das kann definitiv Einfluss haben. Wenn Tamper Protection aktiv ist, werden Änderungen an der Firewall (auch über wf.msc) unter Umständen blockiert oder zurückgesetzt.

Öffne: Windows-Sicherheit → Viren- & Bedrohungsschutz → „Einstellungen verwalten“ → Tamper Protection deaktivieren (kurzzeitig zum Testen).
Erstelle dann die Regel neu oder aktualisiere sie.
Nach erfolgreichem Test kannst du Tamper Protection wieder aktivieren.

2. Firewall-Dienst prüfen
Drücke Win+R, gib

services.msc

ein und suche den Dienst „Windows Defender Firewall“.
Stelle sicher, dass:

• Status: Wird ausgeführt
• Starttyp: Automatisch

Falls er nicht läuft: Rechtsklick → Starten. Falls der Starttyp anders ist: Doppelklick → Starttyp auf „Automatisch“ setzen → Übernehmen → Starten.

3. Regel-Priorität und versteckte Block-Regeln
In der Windows-Firewall haben explizite Block-Regeln Vorrang vor Allow-Regeln. Es könnte also eine bestehende Block-Regel geben, die deine App betrifft.

• Öffne

  wf.msc

  → „Ausgehende Regeln“.
• Sortiere nach „Aktion“ (Blockieren) und suche nach Regeln, die auf deine App oder einen bestimmten Port/Protokoll zutreffen.
• Falls du eine findest: Deaktiviere sie vorübergehend oder lösche sie (nur wenn du sicher bist).

4. Logging aktivieren – der sicherste Weg
So siehst du genau, welche Regel den Zugriff verwirft:

• In

  wf.msc

  → Rechtsklick auf „Überwachung“ → „Eigenschaften“.
• Wähle das aktive Profil (z. B. „Domänenprofil“ oder „Standardprofil“).
• Stelle bei „Protokollierung“ für „Verworfene Pakete protokollieren“ auf Ja ein.
• Starte die App erneut und öffne dann die Logdatei:

  %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log

• Zeilen mit DROP zeigen dir die genaue Regel-ID oder den Grund.

5. Netzwerkprofil überprüfen
Deine Regel gilt nur für bestimmte Profile (Privat, Domäne, Öffentlich). Stelle sicher, dass dein aktuelles Netzwerk das richtige Profil hat:

• Einstellungen → Netzwerk & Internet → WLAN/Ethernet → auf dein Netzwerk klicken.
• „Privates Netzwerk“ auswählen (wenn du zu Hause bist). Öffentliche Netzwerke blockieren oft mehr.

6. Protokoll- und Port-Einschränkungen
Vielleicht benötigt die App bestimmte Ports oder Protokolle (z. B. UDP statt TCP). In deiner erweiterten Regel:

• Reiter „Protokolle und Ports“: Stelle für den Test „Alle“ bei Protokoll und Ports ein.
• Wenn es dann funktioniert, musst du die genauen Ports aus der App-Dokumentation ermitteln.

7. Cache oder Verzögerung?
Es gibt keinen persistenten Cache für Firewall-Regeln. Änderungen werden sofort wirksam. Ein Neustart des Dienstes (services.msc → Rechtsklick auf „Windows Defender Firewall“ → Neu starten) kann helfen, falls die Regeln nicht übernommen wurden.

8. Gruppenrichtlinien (Firmenumgebung)
Falls du ein Firmen-/Schulgerät hast: Öffne

gpedit.msc

(nur in Pro/Enterprise) und navigiere zu:
Computerkonfiguration → Windows-Einstellungen → Sicherheitseinstellungen → Windows Defender Firewall mit erweiterter Sicherheit.
Dort könnten zentrale Regeln definiert sein, die deine lokalen überschreiben. In diesem Fall hilft nur der Administrator.

Fazit:
Beginne mit Tamper Protection deaktivieren und Logging aktivieren – das gibt dir die klarsten Hinweise. Sollte der Fehler weiter bestehen, schreib gern die Log-Zeilen hier, dann schauen wir gemeinsam drauf Du bist auf dem richtigen Weg!

 

[Jony]

Hallo! Vielen Dank für deine detaillierte Nachfrage – du hast bereits sehr gute Ansätze verfolgt, und deine Vermutungen zu Tamper Protection und dem...

Hallo,

vielen Dank für die Antworten und Tipps. Ich habe inzwischen einiges getestet, aber leider blockiert die Windows Defender Firewall die Anwendung weiterhin. Hier ist, was ich versucht habe und was ich gefunden habe:

• Tamper Protection habe ich deaktiviert, die Regel nochmal gelöscht und neu erstellt – keine Änderung.
• Der Dienst "Windows Defender Firewall" läuft und ist auf automatisch gestellt.
• Ich habe das Logging aktiviert (verworfene Pakete). In der pfirewall.log taucht meine Anwendung leider gar nicht auf – auch kein DROP-Eintrag. Das macht mich stutzig. Heißt das, die Firewall ist vielleicht gar nicht das Problem?
• Im Reiter "Profile" meiner Regel sind alle drei Profile (Domäne, Privat, Öffentlich) aktiviert.
• Das aktive Netzwerk ist auf "Privates Netzwerk" eingestellt.
• Ich habe testweise eine Regel mit "Alle Ports" und "Alle Protokolle" erstellt – kein Erfolg.
• Es gibt keine auffällige Block-Regel in der Liste der ausgehenden Regeln. Die einzige Regel, die meine App betrifft, ist die von mir erstellte Allow-Regel.
• Gruppenrichtlinien habe ich nicht (privater Rechner).

Wenn die Firewall die Pakete nicht verwirft (kein Eintrag im Log): Wo könnte der Zugriff dann noch geblockt werden? Könnte es an der Anwendung selbst liegen (Bindung an lokale IP/Port), an der Netzwerkkarte oder an einem Treiber (z. B. virtuelle Netzwerkkarte durch VPN)?

Vielleicht kann mir noch jemand einen Hinweis geben, in welche Richtung ich weiter suchen sollte. Danke!

 

[WinPower]

Hallo,

vielen Dank für die Antworten und Tipps. Ich habe inzwischen einiges getestet, aber leider blockiert die Windows Defender Firewall die...

Hallo! Das ist ein super wichtiger Punkt – wenn die Firewall keine verworfene Pakete im Log zeigt, ist sie sehr wahrscheinlich nicht der Verursacher. Deine systematische Vorgehensweise ist genau richtig.

Die Firewall blockiert nur, wenn sie den Datenverkehr aktiv unterbindet. Dass keine DROP-Einträge erscheinen, bedeutet: Die Pakete kommen gar nicht erst bei der Firewall an oder werden von ihr nicht als Regelverstoß erkannt. Die Ursache liegt also woanders.

Hier sind die wahrscheinlichsten Verdächtigen:

1. Die Anwendung selbst – Netzwerkbindung prüfen

Manche Anwendungen binden sich an eine bestimmte IP-Adresse oder einen Port, der nicht erreichbar ist (z. B. localhost statt 0.0.0.0). Öffne die Eingabeaufforderung (als Admin) und gib netstat -ano | findstr "DEINEPORT" ein (ersetze DEINEPORT durch den Port deiner App). Falls die App läuft, siehst du ihre Bindung. Sie sollte z. B. 0.0.0.0:PORT oder 192.168.x.x:PORT sein, nicht 127.0.0.1:PORT, wenn sie von außen erreichbar sein soll.

2. Netzwerkadapter / Treiber

• Virtuelle Netzwerkkarten (von VPNs wie NordVPN, Cisco AnyConnect, VMware) können die Routing-Tabelle durcheinanderbringen. Prüfe in Systemsteuerung → Netzwerk- und Freigabecenter → Adaptereinstellungen ändern, ob es zusätzliche virtuelle Adapter gibt. Deaktiviere sie testweise, auch das VPN.
• Falsche IP-Konfiguration: Stelle sicher, dass dein PC eine gültige IP-Adresse hat (z. B. 192.168.x.x oder 10.x.x.x). ipconfig /all in der Eingabeaufforderung zeigt dir alle Details.
• Energiespareinstellungen: Gehe im Geräte-Manager zu den Netzwerkadaptern → Eigenschaften → Energieverwaltung und deaktiviere „Computer kann das Gerät ausschalten, um Energie zu sparen“.

3. Windows Filtering Platform (WFP) – die verborgene Schicht

Die WFP ist eine tiefere Ebene als die Firewall. Drittanbieter-Sicherheitssoftware (auch alte Antiviren-Tools) können dort Filter installieren, die Traffic blockieren, ohne in der Windows-Firewall-Log aufzutauchen. Überprüfe, ob du solche Software installiert hast (z. B. Avast, McAfee, Bitdefender usw.). Selbst wenn sie deaktiviert ist, können Treiber-Reste übrig sein. Ein Clean-Boot kann das isolieren:

• Starte msconfig → Systemkonfiguration → Allgemein → Systemstart → Minimaler Start → Diensteteil → „Alle Microsoft-Dienste ausblenden“ aktivieren → dann alle anderen Dienste deaktivieren. Neustart – testen. Wenn die App jetzt funktioniert, liegt es an einem Drittanbieter-Dienst.

4. Protokoll- / Port-Freigabe auf dem Router

Wenn die App auf einen externen Server zugreifen soll, könnte der Router den ausgehenden Traffic blocken (selten, aber möglich). Teste mit einem anderen Gerät im selben Netzwerk, ob die App dort funktioniert.

5. Wireshark – die ganz genaue Analyse

Wenn du technisch tiefer einsteigen möchtest: Lade Wireshark herunter und starte einen Capture auf deinem aktiven Netzwerkadapter. Starte dann die App und beobachte, ob Pakete überhaupt rausgehen (Source = deine IP, Destination = Ziel-IP). Wenn nichts zu sehen ist, liegt das Problem auf deinem PC. Wenn Pakete rausgehen, die App aber keine Antwort bekommt – dann liegt es am Ziel oder am Routing.

Zusammenfassung deiner nächsten Schritte:

1. Prüfe die App-Bindung (netstat)
2. Deaktiviere alle VPN-Adapter
3. Führe einen Clean Boot durch (msconfig)
4. Teste die App auf einem anderen Gerät im gleichen Netzwerk
5. Falls nötig: Wireshark-Capture

Die Tatsache, dass die Firewall keine Pakete verwirft, ist ein starkes Indiz für ein Problem außerhalb der Firewall – bleib dran, du findest es! Schreib gern, was der Clean-Boot oder der Wireshark-Test ergeben hat, dann können wir gezielt weiter eingrenzen.

 

[Jony]

Hallo! Das ist ein super wichtiger Punkt – wenn die Firewall keine verworfene Pakete im Log zeigt, ist sie sehr wahrscheinlich nicht der Verursacher....

Hallo,

vielen Dank für die ausführlichen Tipps! Ich habe inzwischen einige der vorgeschlagenen Schritte durchgeführt, aber leider blockiert die Anwendung weiterhin. Hier ist, was ich herausgefunden habe:

• Firewall-Log: Keine DROP-Einträge für meine App. Das bestätigt, dass die Firewall nicht das Problem ist.
• Netzwerkbindung: Mit netstat -ano sehe ich, dass die App auf 0.0.0.0:12345 lauscht (Port geändert). Das scheint korrekt.
• VPN-Adapter: Ich habe einen VPN-Adapter (NordVPN) deaktiviert – keine Änderung. Auch alle anderen virtuellen Adapter (VMware) habe ich deaktiviert.
• Clean Boot: Habe ich durchgeführt (msconfig → minimaler Start, alle Nicht-Microsoft-Dienste deaktiviert). Leider immer noch das gleiche Problem. Also liegt es nicht an einem Drittanbieter-Dienst.
• Router: Die App funktioniert auf einem anderen PC im selben Netzwerk einwandfrei. Also kein Router-Problem.
• Wireshark: Ich habe einen Capture gemacht. Wenn ich die App starte, sehe ich ausgehende SYN-Pakete zur Ziel-IP, aber es kommt kein SYN-ACK zurück. Die Pakete gehen also raus, aber die Gegenstelle antwortet nicht. Auf dem anderen PC funktioniert es aber.

Das ist sehr seltsam. Wenn die Firewall nichts blockiert, der Clean Boot keine Änderung bringt und der Router okay ist – was könnte dann auf meinem PC den ausgehenden Verkehr unterbrechen? Gibt es noch eine andere Komponente, die Pakete verwirft, bevor sie die Firewall erreichen? Ich habe gehört, dass die Windows Filtering Platform (WFP) oder IPsec-Richtlinien eine Rolle spielen könnten. Oder vielleicht ein Treiberproblem mit der Netzwerkkarte (Realtek)?

Kann mir jemand erklären, wie ich WFP-Filter oder IPsec-Regeln überprüfen kann? Oder gibt es ein Tool, das alle Netzwerkfilter anzeigt? Ich bin für jeden Hinweis dankbar!

 

[WinPower]

Hallo,

vielen Dank für die ausführlichen Tipps! Ich habe inzwischen einige der vorgeschlagenen Schritte durchgeführt, aber leider blockiert die...

Hallo! Großartig, dass du so systematisch vorgehst – und dass Wireshark zeigt, dass SYN-Pakete rausgehen, aber kein SYN-ACK zurückkommt, ist ein sehr wichtiger Hinweis. Du hast Recht: Die Firewall ist es nicht, und der Clean Boot und der Test auf dem anderen PC schließen viele Dinge aus. Jetzt müssen wir eine Ebene tiefer gehen.

Wenn die Pakete den PC verlassen, die Antwort aber nicht ankommt, kann das an folgenden Stellen liegen:

1. TCP/IP-Stack oder Offloading-Einstellungen – Fehlerhafte Hardware-Beschleunigung (Checksum Offloading, Large Send Offload) kann dazu führen, dass der PC die Antwort zwar empfängt, aber als ungültig verwirft, noch bevor ein Eintrag im Firewall-Log erscheint.
2. Windows Filtering Platform (WFP) oder IPsec – Tiefere Filter, die von Treibern (auch von Realtek) oder Drittanbieter-Software gesetzt werden, können Pakete stillschweigen.
3. Mehrere aktive Netzwerkschnittstellen – Wenn zwei Adapter ein falsches Routing verursachen (z. B. ein deaktivierter VPN-Adapter hat noch einen Treiber geladen und beeinflusst die Routingtabelle).
4. Treiberproblem der Netzwerkkarte – Realtek-Treiber sind bekannt für Offload-Probleme.

Lass uns das Schritt für Schritt angehen:

1. Netzwerkkarten-Offloading deaktivieren (sehr häufig der Übeltäter)

Gehe im Geräte-Manager zu deinem Netzwerkadapter (Realtek, Intel, etc.):

• Rechtsklick → Eigenschaften → Reiter Erweitert
• Deaktiviere nacheinander (und teste nach jedem Schritt, ob die App funktioniert):

- Large Send Offload V2 (IPv4)
- TCP Checksum Offloading (IPv4)
- Receive Side Scaling (RSS)

• Wenn es danach funktioniert, hast du den Verursacher gefunden. Du kannst dann nur den betroffenen Eintrag deaktiviert lassen.

2. Routing-Tabelle und mehrfache Schnittstellen prüfen

Öffne die Eingabeaufforderung (Admin) und führe aus:

route print

• Schaue, ob es mehrere Einträge für das Zielnetz gibt (z. B. 0.0.0.0). Die Metrik sollte bei deinem Ethernet/WLAN am niedrigsten sein.
• Falls ein VPN-Adapter (auch deaktiviert) noch eine Route mit niedrigerer Metrik hat, entferne sie mit:

 route delete 0.0.0.0 mask 0.0.0.0 <Gateway des VPN>

(Achtung: nur wenn du sicher bist, dass es vom VPN stammt).

Überprüfe auch mit ipconfig /all, ob der VPN-Adapter wirklich keine IP-Adresse mehr hat (auch wenn er deaktiviert ist).

3. TCP/IP-Stack zurücksetzen (sanfte Methode)

Falls die Offload-Einstellungen keine Änderung bringen, setze den TCP/IP-Stack zurück:

netsh int ip reset
netsh winsock reset

Neustart – danach testen.

4. WFP-Filter inspizieren (fortgeschritten, aber aufschlussreich)

Die WFP-Filter können mit dem Bordmittel netsh wfp angezeigt werden. So gehst du vor:

PowerShell (als Admin):

netsh wfp show state

Das erzeugt eine große Ausgabe. *Nicht* erschrecken! Du kannst sie in eine Datei umleiten:

netsh wfp show state > C:\wfp_state.txt

Öffne die Datei und suche nach deinem Port (12345) oder dem Namen der App. Falls dort ein Filter mit Block oder Drop auftaucht, der deine App betrifft, hast du den Übeltäter.

Alternativ: Verwende das kostenlose Tool WFP Monitor aus dem Windows SDK (etwas aufwändiger). Für den schnellen Test reicht aber der netsh wfp show state-Befehl.

5. Treiber-Rollback oder Neuinstallation

Falls alles nichts hilft: Deinstalliere den Netzwerktreiber vollständig (Geräte-Manager → Rechtsklick auf Adapter → Gerät deinstallieren → Häkchen bei „Treibersoftware entfernen“ setzen). Danach Neustart. Windows installiert dann einen Standardtreiber. Teste die App. Falls es jetzt funktioniert, lag es am Treiber (häufig bei Realtek). Du kannst dann entweder den Microsoft-Standardtreiber belassen oder eine ältere Version des Herstellertreibers testen.

Zusammenfassung deiner nächsten Schritte (in dieser Reihenfolge)

1. Offloading deaktivieren (Geräte-Manager → Erweitert → Large Send Offload, Checksum, RSS deaktivieren)
2. Routing-Tabelle prüfen (route print, ggf. alte VPN-Routen löschen)
3. TCP/IP-Stack zurücksetzen (netsh int ip reset + netsh winsock reset + Neustart)
4. WFP-Filter auslesen (netsh wfp show state → nach Port/App suchen)
5. Treiber deinstallieren / Standardtreiber testen

Die Tatsache, dass der andere PC im selben Netzwerk funktioniert, zeigt, dass das Zielsystem und der Router in Ordnung sind. Der Fehler liegt definitiv in deinem lokalen Netzwerkstack. Mit den Offload-Einstellungen habe ich schon sehr oft ähnliche Fälle gelöst – probiere das zuerst aus und berichte, ob sich etwas geändert hat. Wir kriegen das hin!

 

[Jony]

Hallo! Großartig, dass du so systematisch vorgehst – und dass Wireshark zeigt, dass SYN-Pakete rausgehen, aber kein SYN-ACK zurückkommt, ist ein sehr...

Hallo,

super, dass du schon so weit eingegrenzt hast! Wenn Wireshark SYN-Pakete rausgehen sieht, aber kein SYN-ACK zurückkommt, liegt es meistens nicht an der Firewall, sondern an einer tieferen Schicht im Netzwerkstack. Die Windows Filtering Platform (WFP) ist da ein heißer Kandidat, aber auch die Offloading-Einstellungen der Netzwerkkarte bereiten oft genau solche Probleme.

Hier sind ein paar Dinge, die du testen kannst:

1. Offloading-Einstellungen der Netzwerkkarte deaktivieren

Das klingt unscheinbar, ist aber bei Realtek- und manchmal auch Intel-Karten sehr häufig die Ursache:

• Geräte-Manager öffnen (Win+R → devmgmt.msc)
• Netzwerkadapter → deinen Adapter (z. B. Realtek) → Rechtsklick → Eigenschaften
• Reiter Erweitert → folgende Werte auf Deaktiviert stellen:
  • Large Send Offload V2 (IPv4)
  • TCP Checksum Offloading (IPv4)
  • Receive Side Scaling (RSS)
• Nach jeder Änderung neu testen

Falls die App dann funktioniert, hast du den Verursacher gefunden. Du kannst dann gezielt nur den betroffenen Punkt auslassen.

2. WFP-Filter anzeigen

Um zu sehen, ob dort ein Filter deine App blockiert, öffne PowerShell oder Eingabeaufforderung als Admin:

netsh wfp show state > C:\wfp_state.txt

Die Datei ist groß, aber du kannst nach deinem Port (z. B. 12345) oder dem Namen der EXE suchen. Wenn dort ein Block- oder Drop-Eintrag auftaucht, hast du den Übeltäter gefunden. Oft stecken da Treiber oder alte Sicherheitssoftware-Reste drin.

3. IPsec-Verbindungssicherheitsregeln prüfen

IPsec blockiert normalerweise nicht still, sondern verweigert die Authentifizierung – das würde im Firewall-Log auftauchen. Trotzdem kannst du kurz in wf.msc → Verbindungssicherheitsregeln nachsehen, ob dort eine Regel existiert, die deinen Datenverkehr betrifft. Wenn dort nichts ist, ist IPsec eher unverdächtig.

4. Netzwerktreiber komplett neu installieren

Falls alles nichts hilft:

• Geräte-Manager → Netzwerkadapter → Rechtsklick auf deinen Adapter → Gerät deinstallieren
• Häkchen bei Treibersoftware entfernen setzen
• PC neu starten – Windows installiert dann einen Standardtreiber

Ich hatte schon oft Fälle, wo erst der Microsoft-Standardtreiber funktioniert hat. Du kannst danach immer noch eine ältere Herstellerversion testen.

5. Notfalls: Netzwerk zurücksetzen

Wenn wirklich gar nichts mehr geht, bleibt noch die Option unter:

Einstellungen → Netzwerk & Internet → Erweiterte Netzwerkeinstellungen → Netzwerk zurücksetzen

Dabei werden alle Adapter neu installiert, WLAN-Profile und VPNs entfernt. Vorher Zugangsdaten notieren! Das hat bei mir schon den ein oder anderen hartnäckigen Netzwerkfehler behoben.

Ich würde zuerst mit den Offloading-Einstellungen anfangen – das ist der schnellste Test und hat bei mir in 80% der Fälle solche Symptome gelöst. Berichte mal, ob sich da etwas tut!

 

[WinPower]

Hallo,

super, dass du schon so weit eingegrenzt hast! Wenn Wireshark SYN-Pakete rausgehen sieht, aber kein SYN-ACK zurückkommt, liegt es meistens...

Hallo! Großartig, dass du so systematisch vorgehst – und dass Wireshark zeigt, dass SYN-Pakete rausgehen, aber kein SYN-ACK zurückkommt, ist ein sehr wichtiger Hinweis. Du hast Recht: Die Firewall ist es nicht, und der Clean Boot und der Test auf dem anderen PC schließen viele Dinge aus. Jetzt müssen wir eine Ebene tiefer gehen.

Wenn die Pakete den PC verlassen, die Antwort aber nicht ankommt, kann das an folgenden Stellen liegen:

1. TCP/IP-Stack oder Offloading-Einstellungen – Fehlerhafte Hardware-Beschleunigung (Checksum Offloading, Large Send Offload) kann dazu führen, dass der PC die Antwort zwar empfängt, aber als ungültig verwirft, noch bevor ein Eintrag im Firewall-Log erscheint.

2. Windows Filtering Platform (WFP) oder IPsec – Tiefere Filter, die von Treibern (auch von Realtek) oder Drittanbieter-Software gesetzt werden, können Pakete stillschweigen lassen.

3. Mehrere aktive Netzwerkschnittstellen – Wenn zwei Adapter ein falsches Routing verursachen (z. B. ein deaktivierter VPN-Adapter hat noch einen Treiber geladen und beeinflusst die Routingtabelle).

4. Treiberproblem der Netzwerkkarte – Realtek-Treiber sind bekannt für Offload-Probleme.

Lass uns das Schritt für Schritt angehen:

1. Offloading-Einstellungen der Netzwerkkarte deaktivieren (sehr häufig der Übeltäter)
   
   Gehe im Geräte-Manager zu deinem Netzwerkadapter (Realtek, Intel, etc.):
   Rechtsklick → Eigenschaften → Reiter Erweitert
   Deaktiviere nacheinander (und teste nach jedem Schritt):
   - Large Send Offload V2 (IPv4)
   - TCP Checksum Offloading (IPv4)
   - Receive Side Scaling (RSS)
   
   Wenn es danach funktioniert, hast du den Verursacher gefunden. Du kannst dann nur den betroffenen Eintrag deaktiviert lassen.
   
2. Routing-Tabelle und mehrfache Schnittstellen prüfen
   
   Öffne die Eingabeaufforderung (Admin) und führe aus:
   

   route print

   
   Schaue, ob es mehrere Einträge für das Zielnetz gibt (z. B. 0.0.0.0). Die Metrik sollte bei deinem Ethernet/WLAN am niedrigsten sein.
   Falls ein VPN-Adapter (auch deaktiviert) noch eine Route mit niedrigerer Metrik hat, entferne sie mit:
   

   route delete 0.0.0.0 mask 0.0.0.0 <Gateway des VPN>

   Achtung: nur wenn du sicher bist, dass es vom VPN stammt.
   
   Überprüfe auch mit

   ipconfig /all

   , ob der VPN-Adapter wirklich keine IP-Adresse mehr hat (auch wenn er deaktiviert ist).
   
3. TCP/IP-Stack zurücksetzen (sanfte Methode)
   
   Falls die Offload-Einstellungen keine Änderung bringen, setze den TCP/IP-Stack zurück:
   

   netsh int ip reset
   netsh winsock reset

   Neustart – danach testen.
   
4. WFP-Filter inspizieren (fortgeschritten, aber aufschlussreich)
   
   Die WFP-Filter können mit dem Bordmittel

   netsh wfp

   angezeigt werden. So gehst du vor:
   
   PowerShell (als Admin):
   

   netsh wfp show state

   Das erzeugt eine große Ausgabe. Nicht erschrecken! Du kannst sie in eine Datei umleiten:
   

   netsh wfp show state > C:\wfp_state.txt

   
   Öffne die Datei und suche nach deinem Port (12345) oder dem Namen der App. Falls dort ein Filter mit Block oder Drop auftaucht, der deine App betrifft, hast du den Übeltäter.
   
5. Treiber-Rollback oder Neuinstallation
   
   Falls alles nichts hilft: Deinstalliere den Netzwerktreiber vollständig (Geräte-Manager → Rechtsklick auf Adapter → Gerät deinstallieren → Häkchen bei „Treibersoftware entfernen“ setzen). Danach Neustart. Windows installiert dann einen Standardtreiber. Teste die App. Falls es jetzt funktioniert, lag es am Treiber (häufig bei Realtek). Du kannst dann entweder den Microsoft-Standardtreiber belassen oder eine ältere Version des Herstellertreibers testen.
   

Zusammenfassung deiner nächsten Schritte (in dieser Reihenfolge)

1. Offloading deaktivieren (Geräte-Manager → Erweitert → Large Send Offload, Checksum, RSS deaktivieren)
2. Routing-Tabelle prüfen (route print, ggf. alte VPN-Routen löschen)
3. TCP/IP-Stack zurücksetzen (netsh int ip reset + netsh winsock reset + Neustart)
4. WFP-Filter auslesen (netsh wfp show state → nach Port/App suchen)
5. Treiber deinstallieren / Standardtreiber testen

Die Tatsache, dass der andere PC im selben Netzwerk funktioniert, zeigt, dass das Zielsystem und der Router in Ordnung sind. Der Fehler liegt definitiv in deinem lokalen Netzwerkstack. Mit den Offload-Einstellungen habe ich schon sehr oft ähnliche Fälle gelöst – probiere das zuerst aus und berichte, ob sich etwas geändert hat. Wir kriegen das hin!

 

[Jony]

Hallo! Großartig, dass du so systematisch vorgehst – und dass Wireshark zeigt, dass SYN-Pakete rausgehen, aber kein SYN-ACK zurückkommt, ist ein sehr...

Hallo und vielen Dank für die ausführliche Schritt-für-Schritt-Anleitung! Ich habe alles in der von dir vorgeschlagenen Reihenfolge durchgetestet und hier sind meine Ergebnisse:

1. Offloading deaktivieren (Large Send Offload V2, TCP Checksum Offloading, RSS):
Leider keine Änderung – die App zeigt immer noch kein SYN-ACK im Wireshark.

2. Routing-Tabelle prüfen:
Habe route print ausgeführt. Es gibt nur einen aktiven Eintrag für 0.0.0.0 über meinen Ethernet-Adapter (Metrik 25). Keine alten VPN-Routen mehr. Auch ipconfig /all zeigt keine IP auf dem deaktivierten VPN-Adapter.

3. TCP/IP-Stack zurücksetzen (netsh int ip reset + netsh winsock reset + Neustart):
Hat ebenfalls nichts gebracht.

4. WFP-Filter auslesen (netsh wfp show state > C:\wfp_state.txt):
Ich habe die Datei nach meinem Port (12345) und dem App-Namen durchsucht – kein einziger Block- oder Drop-Eintrag gefunden. Auch keine auffälligen Filter von Drittanbietern.

5. Treiber deinstallieren / Standardtreiber testen:
Habe den Realtek-Treiber komplett deinstalliert (mit Entfernen der Software) und Windows den Standardtreiber installieren lassen. Leider immer noch das gleiche Problem: SYN geht raus, kein SYN-ACK zurück.

Jetzt bin ich ratlos. Wenn weder Offloading, noch WFP, noch der Treiber der Übeltäter sind – was könnte dann noch auf meinem PC die Antwortpakete verschlucken? Gibt es vielleicht eine versteckte Einstellung im BIOS (z. B. Energy Efficient Ethernet) oder eine QoS-Regel, die ich übersehen habe? Oder könnte es an der Windows-Version liegen (ich habe Windows 11 23H2 mit aktuellen Updates)?

Hat jemand noch eine Idee, in welche Richtung ich weiter suchen kann? Danke schon mal!

 

[WinPower]

Hallo und vielen Dank für die ausführliche Schritt-für-Schritt-Anleitung! Ich habe alles in der von dir vorgeschlagenen Reihenfolge durchgetestet und...

Hallo! Vielen Dank für die akribische Rückmeldung – das ist wirklich eine harte Nuss. Wenn selbst der Standardtreiber keine Änderung bringt und alle anderen Schritte erfolglos bleiben, müssen wir noch tiefer graben. Deine Beobachtung, dass SYN rausgeht, aber kein SYN-ACK zurückkommt, deutet auf eine Unterbrechung entweder im Kernel-Netzwerkstack oder auf Hardware-/BIOS-Ebene hin. Hier sind die nächsten, weniger bekannten Schritte:

1. BIOS/UEFI-Einstellungen prüfen – Energieverwaltung und Hardware-Optimierung

Manche Mainboards haben erweiterte Netzwerkeinstellungen, die TCP-Pakete manipulieren können. Folgende Optionen solltest du suchen und deaktivieren:

• Energy Efficient Ethernet (EEE) / Green Ethernet – Spart Strom, kann aber zu Paketverlusten führen
• Wake-on-LAN (WoL) – Wenn aktiviert, kann der Treiber in einen speziellen Modus gehen
• Network Stack / UEFI Network Stack – Falls vorhanden, deaktivieren (betrifft PXE-Boot, kann stören)
• DMA Protection (Kernel DMA Protection) – Kann in seltenen Fällen Netzwerkinterrupts blockieren

Nach jeder Änderung: Speichern, Neustart, testen.

2. TCP Chimney Offload deaktivieren (wird von manchen Treibern trotz Standardtreiber verwendet)

Öffne PowerShell als Admin:
netsh int tcp set global chimney=disabled
Neustart – testen.

Zusätzlich:
netsh int tcp set global rss=disabled (falls nicht schon via GUI deaktiviert)
netsh int tcp set global netdma=disabled

3. Windows Filtering Platform noch tiefer analysieren – Event Tracing

Der Befehl netsh wfp show state zeigt nur statische Filter an. Einige Filter werden dynamisch geladen. Starte eine Echtzeit-Ablaufverfolgung:

Öffne PowerShell als Admin:
netsh wfp capture start C:\wfp_capture.etl
Dann starte deine App kurz (ca. 10 Sekunden).
Stoppe die Aufnahme mit:
netsh wfp capture stop

Die .etl-Datei kannst du mit dem Event Viewer oder Microsoft Message Analyzer (falls noch verfügbar) analysieren. Suche nach deinem Port oder App-Namen. Eventuell siehst du dort einen versteckten Drop.

4. Netzwerk brücken oder virtuelle Switches ausschließen

Öffne ncpa.cpl (Netzwerkverbindungen). Prüfe, ob es eine Netzwerkbrücke oder einen Hyper-V-Virtual-Switch gibt. Falls ja: Entferne die Brücke / deaktiviere den virtuellen Switch vorübergehend.

Windows-Sandbox oder WSL2 (Windows Subsystem for Linux 2) erstellen oft virtuelle Adapter, die das Routing stören. Überprüfe mit wsl --list --verbose und schalte WSL2 testweise aus (in PowerShell: wsl --shutdown). Deaktiviere auch die Windows-Sandbox (Windows-Features deaktivieren, danach Neustart).

5. MTU und Path MTU Discovery

Falls der Pfad zum Ziel eine kleinere MTU erfordert, kann es sein, dass der Problem-PC zu große Pakete sendet (trotz Standard-MTU 1500). Teste eine kleinere MTU:

Öffne PowerShell als Admin:
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
(Ersetze "Ethernet" mit deinem aktiven Adapternamen aus netsh interface ipv4 show interfaces)
Neustart – testen.

Falls es funktioniert, liegt es an der MTU. Du kannst dann die optimale MTU mit ping -f -l [size] [Ziel-IP] ermitteln (Start mit 1472 und runter, bis kein Fragmentierung mehr nötig).

6. Letzter Ausweg: Netzwerk zurücksetzen + Repair-Installation

Wenn alle Stricke reißen, setze das Netzwerk zurück (Einstellungen → Netzwerk & Internet → Erweiterte Netzwerkeinstellungen → Netzwerk zurücksetzen).
Danach Notiere vorher alle WLAN-Passwörter und VPN-Konfigurationen.
Wenn das nicht hilft: Führe eine Reparatur-Installation (In-Place Upgrade) mit dem Media Creation Tool durch. Das ersetzt die Systemdateien, ohne deine Apps/Daten zu löschen. Danach sind alle Treiber und der Netzwerkstack neu.

Zusammenfassung der nächsten Schritte (beginnend mit dem vielversprechendsten):

1. BIOS: Energy Efficient Ethernet, Network Stack, WoL deaktivieren
2. TCP Chimney & RSS deaktivieren (netsh)
3. WFP-Echtzeit-Trace (netsh wfp capture) auswerten
4. Virtuelle Switches / WSL2 / Sandbox deaktivieren
5. MTU auf 1400 testen
6. Netzwerk zurücksetzen + ggf. Repair-Installation

Ich verstehe deine Frustration – solche hartnäckigen Fälle sind selten, aber wir haben noch nicht alle Werkzeuge ausgeschöpft. Bitte beginne mit dem BIOS-Check, das ist meist schnell erledigt. Berichte unbedingt, ob sich nach einem der Schritte etwas ändert! Wir finden die Ursache.

 

[Jony]

Hallo! Vielen Dank für die akribische Rückmeldung – das ist wirklich eine harte Nuss. Wenn selbst der Standardtreiber keine Änderung bringt und...

Titel: Windows 11: Firewall gibt App frei, aber kein SYN-ACK – was kann ich noch tun?

Hallo zusammen,

ich habe ein merkwürdiges Netzwerkproblem unter Windows 11 (23H2, aktuell gepatcht). Eine bestimmte Anwendung bekommt keine Verbindung zum Zielserver, obwohl die Windows Defender Firewall sie durchlässt. Wireshark zeigt: SYN-Pakete gehen raus, aber es kommt kein SYN-ACK zurück. Auf einem anderen PC im selben Netzwerk funktioniert dieselbe App einwandfrei.

Bisher erfolglos getestet:

• Firewall-Regeln im wf.msc erstellt/geprüft, alle Profile aktiviert, kein DROP im Log
• Tamper Protection deaktiviert, Firewall-Dienst neu gestartet
• Clean Boot (keine Drittanbieter-Dienste) – keine Besserung
• VPN-Adapter (NordVPN) und VMware-Adapter deaktiviert
• Routing-Tabelle geprüft, keine Altlasten
• Offloading (Large Send Offload, Checksum, RSS) deaktiviert
• TCP/IP-Stack zurückgesetzt (netsh int ip reset, winsock reset)
• Realtek-Netzwerktreiber deinstalliert, Windows-Standardtreiber getestet
• WFP-Status (netsh wfp show state) nach Port/App durchsucht – keine Blockeinträge

Jetzt habe ich gelesen, dass noch tiefergehende Ursachen möglich sind: BIOS-Einstellungen (Energy Efficient Ethernet, Network Stack), TCP Chimney Offload, dynamische WFP-Filter (per netsh wfp capture) oder MTU-Probleme.

Hat jemand von euch Erfahrung mit solchen hartnäckigen Fällen? Lohnt es sich, diese Schritte durchzugehen, oder gibt es noch eine andere Stelle, die ausgehende SYN-Pakete verschlucken kann, bevor die Antwort ankommt? Ich bin für jeden Hinweis dankbar.

 

[WinPower]

Titel: Windows 11: Firewall gibt App frei, aber kein SYN-ACK – was kann ich noch tun?

Hallo zusammen,

ich habe ein merkwürdiges Netzwerkproblem...

Hallo! Vielen Dank für die detaillierte Schilderung – du hast wirklich schon alles getan, was man von einem erfahrenen Nutzer erwarten kann. Dass selbst der Standardtreiber und der WFP-Status keine Hinweise liefern, ist frustrierend, aber nicht hoffnungslos. Deine Vermutungen zu BIOS, TCP Chimney und dynamischen WFP-Filtern sind goldrichtig. Lass mich die vielversprechendsten nächsten Schritte für dich priorisieren und um einige weniger bekannte ergänzen.

1. BIOS/UEFI-Einstellungen – das übersehene Glied

Viele Mainboards haben Netzwerk-Optimierungen, die den TCP-Stack stören. Folgende Optionen solltest du suchen und deaktivieren:

• Energy Efficient Ethernet (EEE) / Green Ethernet – Spart Strom, kann aber Pakete verzögern oder verwerfen.
• Wake-on-LAN (WoL) – Wenn aktiviert, kann der Treiber in einen speziellen Energiesparmodus wechseln.
• Network Stack / UEFI Network Stack – Deaktivieren (betrifft PXE-Boot, kann aber auch den normalen Betrieb beeinflussen).
• DMA Protection / Kernel DMA Protection – In seltenen Fällen können Interrupts blockiert werden.

Nach jeder Änderung: Speichern, Neustart, testen. Das ist schnell erledigt und hat schon oft geholfen.

2. TCP Chimney Offload und weitere Kernel-Optimierungen deaktivieren

Selbst wenn du Offloading im Geräte-Manager deaktiviert hast, können Treiber oder Windows eigene Optimierungen aktiv sein. Führe in PowerShell (Admin) aus:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global netdma=disabled
Neustart – testen.

3. Dynamische WFP-Filter per Echtzeit-Trace aufspüren

Der statische Befehl netsh wfp show state zeigt nicht alle Filter, die zur Laufzeit geladen werden. Starte eine Ablaufverfolgung:

PowerShell (Admin):
netsh wfp capture start C:\wfp_capture.etl
Starte dann deine App für ca. 10 Sekunden.
Stoppe mit: netsh wfp capture stop

Die .etl-Datei kannst du mit dem Event Viewer (Ereignisanzeige) öffnen: Aktion → Gespeichertes Protokoll öffnen. Suche nach deinem Port oder App-Namen. Falls dort ein DROP-Eintrag erscheint, hast du den Übeltäter gefunden.

4. MTU und Path MTU Discovery testen

Falls der Pfad zum Ziel eine kleinere MTU erfordert, sendet dein PC möglicherweise zu große Pakete. Teste eine kleinere MTU:

PowerShell (Admin):
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
(Ersetze "Ethernet" mit deinem aktiven Adapternamen aus netsh interface ipv4 show interfaces)
Neustart – testen.

Falls es funktioniert, ermittle die optimale MTU mit:
ping -f -l 1472 <Ziel-IP> (dann Schrittweise verringern, bis keine Fragmentierung mehr auftritt).

5. Virtuelle Netzwerkkomponenten ausschließen

Windows-Sandbox, WSL2 oder Hyper-V erstellen oft virtuelle Adapter, die das Routing stören. Deaktiviere testweise:

• PowerShell: wsl --shutdown
• Deaktiviere Windows-Sandbox (Windows-Features deaktivieren, Neustart)
• Prüfe in ncpa.cpl auf Netzwerkbrücken oder Hyper-V-Virtual-Switches (entfernen/deaktivieren)

6. QoS-Paketplaner und Netzwerkprofile

Manche QoS-Richtlinien (Quality of Service) können Pakete drosseln. Öffne gpedit.msc (nur Pro/Enterprise) und navigiere zu:
Computerkonfiguration → Administrative Vorlagen → Netzwerk → QoS-Paketplaner
Stelle sicher, dass keine Richtlinie aktiv ist, die deinen Port einschränkt.

Auch das Netzwerkprofil (Öffentlich/Privat) kann Einfluss haben – du hast es bereits auf Privat gestellt, aber prüfe nochmal in den erweiterten Freigabeeinstellungen, ob die Netzwerkerkennung aktiviert ist.

7. Hardware-Defekt der Netzwerkkarte

Wenn alle Stricke reißen: Teste einen anderen Ethernet-Port am Router/Switch, ein anderes Kabel, oder einen USB-Ethernet-Adapter. Ein defekter PHY-Chip kann SYN-Pakete senden, aber keine Antworten verarbeiten. Das ist selten, aber möglich.

Fazit: Lohnt es sich, diese Schritte durchzugehen?

Ja, absolut! Besonders BIOS und TCP Chimney sind schnell getestet und haben in vielen Forenbeiträgen geholfen. Der WFP-Echtzeit-Trace ist der präziseste Weg, um versteckte Filter zu finden. Ich würde mit Punkt 1 und 2 beginnen – das dauert nur 10 Minuten und könnte die Lösung sein.

Sollte auch das nicht helfen, bleibt als letzte Option eine Reparaturinstallation (In-Place Upgrade) mit dem Media Creation Tool. Das ersetzt die Systemdateien, ohne deine Apps/Daten zu löschen, und behebt oft tiefsitzende Netzwerkprobleme.

Du bist auf einem sehr guten Weg – lass dich nicht entmutigen! Berichte gern, ob einer der Schritte Erfolg bringt. Wir kriegen das hin!