Windows-Firewall und Business-Anwendungen — Eingehende Regeln über das Installationsprogramm registrieren

„Auf dem Entwicklungsrechner läuft alles problemlos, aber nachdem wir es beim Kunden installiert haben, kommt der Client nicht mit dem Server zusammen.“ „Beim ersten Start ist irgendeine Warnung aufgetaucht, und anscheinend hat jemand vor Ort abgebrochen.“ „netstat zeigt, dass der Port lauscht, aber vom Nachbar-PC aus kommt nichts an.“ — Im Umfeld der Einführung von Business-Anwendungen gehören Anfragen dieser Art zu den absoluten Klassikern unter den Meldungen „keine Verbindung möglich“. Und ganz oben auf der Liste der Ursachen steht hartnäckig die Windows-Firewall (Windows Defender Firewall).

Das Tückische daran ist, dass das Problem auf dem Entwicklungsrechner unsichtbar bleibt. Dort hat man beim Debug-Lauf in Visual Studio selbst auf „Zulassen“ geklickt oder ist ohnehin Administrator — und liefert die App aus, ohne die standardmäßige Blockierung eingehenden Verkehrs je bemerkt zu haben. Beim Kunden dagegen bedient ein normaler Benutzer ohne Administratorrechte die Maschine, und das Netzwerk wird per GPO verwaltet. Es ist also nicht so, dass „etwas, das eigentlich funktionieren sollte, nicht funktioniert“ — die Realität ist vielmehr: „der Entwicklungsrechner hat nur zufällig funktioniert“.

Dieser Artikel richtet sich an Entwickler von Business-Anwendungen, die bei ihrer selbst entwickelten Anwendung auf „keine Verbindung beim Kunden“ stoßen, sowie an IT-Verantwortliche in kleinen und mittleren Unternehmen, die solche Meldungen entgegennehmen. Er vermittelt zunächst das nötige Minimum zum Standardverhalten der Windows-Firewall und ihrem Profilmechanismus und arbeitet sich dann durch das Design eingehender Regeln, die praktische Registrierung über das Installationsprogramm sowie die Schritte zur Fehlereingrenzung bis hin zu den Besonderheiten unter GPO-/Intune-Verwaltung — alles gestützt auf Primärquellen mit Stand August 2026.

1. Das Wichtigste zuerst

• Der Standard der Windows-Firewall lautet „eingehend blockieren, ausgehend erlauben“. Eingehender Verkehr, der keine Antwort auf eine Anfrage ist, wird verworfen, sofern er nicht mit einer Regel übereinstimmt.¹
• Eine eingehende Regel wird nur für Anwendungen vom Servertyp benötigt, die einen Port abhören. Eine Client-App, die nur selbst eine Verbindung aufbaut, kommuniziert bereits mit den Standardeinstellungen. Grenzen Sie hier zuerst ein.¹
• Es gibt drei Profile (Domäne/Privat/Öffentlich). Domäne wird automatisch angewendet, sobald ein Domänencontroller erkannt wird; Öffentlich ist der Standard für nicht identifizierte Netzwerke. Regeln werden pro Profil aktiviert oder deaktiviert.¹
• Sie dürfen den Produktivbetrieb nicht diesem „Wichtige Warnung“-Dialog überlassen. Bricht ein Administrator ab, wird eine Blockierregel erstellt, und bei einem Benutzer ohne Administratorrechte wird unabhängig von der gedrückten Schaltfläche eine Blockierregel erstellt. Der Dialog erscheint erst wieder, wenn die erstellte Regel gelöscht wird.²
• Die Schlussfolgerung lautet: Registrieren Sie die eingehenden Regeln einer Business-Anwendung über das Installationsprogramm. Microsoft selbst empfiehlt, die Regel vor dem ersten Start zu platzieren und die Benachrichtigung bei eingehendem Verkehr zu deaktivieren.²
• Entwerfen Sie Regeln nach dem Prinzip minimaler Rechte. Bauen Sie sie um Programm + Protokoll + Port herum auf, beschränken Sie das Profil auf Domäne/Privat und die Remote-IP auf das benötigte Subnetz. Im Programmpfad sind Platzhalter nicht zulässig.²³
• Die Fehlereingrenzung erfolgt in der Reihenfolge Test-NetConnection → Get-NetFirewallRule → pfirewall.log. Das Firewall-Protokoll wird standardmäßig nicht geschrieben — erst wenn Sie die Protokollierung verworfener Pakete aktivieren, erscheinen Einträge.⁴⁵⁶
• Die vollständige Deaktivierung durch Stoppen des Dienstes wird nicht unterstützt. Unter GPO-/Intune-Verwaltung kann das „Zusammenführen lokaler Regeln“ deaktiviert sein; in diesem Fall wirken lokale Regeln nicht. Beantragen Sie in diesem Fall die zentrale Verteilung der Regel bei der IT-Abteilung.¹²

2. Das Standardverhalten genau verstehen — Eingehend ist standardmäßig blockiert, ausgehend standardmäßig erlaubt

Zunächst die Grundlage präzise klären. Die Windows-Firewall ist eine hostbasierte Firewall, die in allen Editionen standardmäßig aktiviert ist, und ihr Standardverhalten lässt sich in zwei Zeilen zusammenfassen.¹

• Eingehend (inbound): wird vollständig blockiert, sofern es sich nicht um eine Antwort auf eine Anfrage (solicited) handelt oder mit einer Regel übereinstimmt
• Ausgehend (outbound): wird vollständig erlaubt, sofern es nicht mit einer Regel übereinstimmt

Aus diesen beiden Zeilen ergibt sich die für Business-Anwendungen wichtigste Unterscheidung: Eine eingehende Regel wird nur für die „lauschende“ Seite benötigt.

• Eine Client-App, die nur selbst eine Verbindung zu einem internen Webserver, Datenbankserver oder Kernsystem aufbaut → grundsätzlich keine Regel nötig. Die Rückpakete der Verbindung gelten als „Antwort auf eine Anfrage“ und passieren standardmäßig.
• Eine Anwendung oder ein Windows-Dienst vom Servertyp, die/der über TCP, gRPC oder ein eigenes Protokoll einen Port öffnet und auf Verbindungen wartet → eine eingehende Regel ist zwingend erforderlich.
• Ein Sonderfall ist eine Konfiguration, bei der Named Pipes remote genutzt werden. Eine remote genutzte Named Pipe läuft nicht über einen eigenen Port der Anwendung, sondern über SMB (TCP 445), sodass nicht eine Regel für die Anwendung, sondern eine Regel für die Dateifreigabe (SMB) benötigt wird.
• Eine weitere Ausnahme sind hochsichere Umgebungen, in denen der ausgehende Standard ausdrücklich auf Blockieren umgestellt wurde. Diese Konfiguration findet sich nur in manchen Organisationen, aber wenn sie vorliegt, muss auch für Client-Apps eine ausgehende Regel beantragt werden.²

flowchart TB
    APP["Kommunikation der eigenen Anwendung erfassen"] --> Q{"Öffnet sie einen Port und<br/>wartet auf Verbindungen?"}
    Q -- "Wartet nicht<br/>(verbindet nur als Client)" --> C1["Eingehende Regel grundsätzlich nicht nötig<br/>Rückverkehr passiert als „Antwort“"]
    Q -- "Wartet<br/>(Servertyp / Callback-Empfang)" --> S1["Eingehende Regel zwingend erforderlich<br/>-> Registrierung über Installer, Abschnitt 5"]
    C1 -.-> EX["Ausnahme: In hochsicheren Umgebungen mit<br/>ausgehend standardmäßig blockiert eine ausgehende Regel beantragen"]

Der Fall „eine App, die eigentlich Client sein sollte, in Wirklichkeit aber auch lauscht“ (Empfang von Ergebnis-Callbacks, Funktion als Benachrichtigungsendpunkt für einen anderen Prozess und Ähnliches) wird leicht übersehen. Ist unklar, über welche Kommunikationsart die eigene Anwendung lauscht, lohnt sich als Referenz für die Designphase auch „Wie man die passende Interprozesskommunikation unter Windows wählt“.

2.1. Profile und der „Netzwerkstandort“

Regeln werden pro Netzwerk-profil angewendet. Es gibt drei Profile.¹

Welches Profil gerade angewendet wird, lässt sich mit Get-NetConnectionProfile prüfen, und der Wechsel zwischen Privat und Öffentlich erfolgt mit Set-NetConnectionProfile.¹ Ein in der Praxis häufiger Vorfall ist, dass das Netzwerk beim Kunden in einer Arbeitsgruppenumgebung als „Öffentlich“ eingestuft wird und eine eingehende Regel, die auf Domäne/Privat beschränkt wurde, deshalb nicht greift. Wenn „die Regel existiert, aber nichts durchkommt“, verdächtigen Sie zuerst eine falsche Profilzuordnung, bevor Sie den Inhalt der Regel prüfen.

2.2. Rangfolge der Regeln

Wenn mehrere Regeln vorliegen, richtet sich die Auswertung nicht nach einer gewichteten Rangliste, sondern nach den folgenden durchgängigen Prinzipien.²

1. Eine explizite Erlauben-Regel hat Vorrang vor der Standardblockierung
2. Eine explizite Blockieren-Regel hat Vorrang vor einer widersprechenden Erlauben-Regel
3. Soweit Punkt 2 dem nicht entgegensteht, hat die spezifischere Regel Vorrang

Die praktische Konsequenz lautet: „Sobald irgendwo eine Blockierregel existiert, gewinnt keine noch so große Zahl später hinzugefügter Erlauben-Regeln dagegen.“ Und genau eine solche Blockierregel erzeugt, wie das nächste Kapitel zeigt, jener Dialog ganz still im Hintergrund.

3. Was der Dialog „Wichtige Warnung“ wirklich ist — warum Sie ihn nicht dem Produktivbetrieb überlassen dürfen

Wenn eine Anwendung zum ersten Mal beginnt, auf einem Port zu lauschen (listen), und weder eine Erlauben-Regel noch eine vom Administrator definierte Regel für diese Anwendung existiert, zeigt Windows den bekannten Dialog „Windows-Sicherheitshinweis“ mit der Meldung, dass „einige Funktionen dieser App von der Windows Defender Firewall blockiert werden“. Das Verhalten ist eindeutig spezifiziert.²

• Wird er einem Benutzer mit Administratorrechten angezeigt: Mit „Zugriff zulassen“ wird eine Erlauben-Regel erstellt. Klickt man dagegen auf „Abbrechen“, wird eine Blockierregel erstellt — normalerweise zwei, eine für TCP und eine für UDP.
• Wird er einem Benutzer ohne Administratorrechte angezeigt: Unabhängig von der gewählten Option wird eine Blockierregel erstellt.
• In beiden Fällen erscheint der Dialog nicht mehr, bis die erstellte Regel gelöscht wird, und die Kommunikation bleibt weiterhin blockiert.

flowchart TB
    L["Anwendung beginnt, auf einem Port zu lauschen"] --> Q1{"Gibt es eine zur Anwendung<br/>passende Regel?"}
    Q1 -- "Ja" --> R1["Regel wird befolgt<br/>(kein Dialog)"]
    Q1 -- "Nein" --> Q2{"Ist die eingehende<br/>Benachrichtigung aktiviert?"}
    Q2 -- "Deaktiviert" --> R2["Stille Blockierung<br/>(keine Regel wird erstellt)"]
    Q2 -- "Aktiviert" --> DLG["Dialog „Wichtige Warnung“"]
    DLG -- "Administrator klickt „Zugriff zulassen“" --> OK["Erlauben-Regel wird erstellt"]
    DLG -- "Administrator klickt „Abbrechen“" --> NG1["Blockierregel wird erstellt"]
    DLG -- "Benutzer ohne Administratorrechte<br/>(jede Aktion)" --> NG2["Blockierregel wird erstellt"]
    NG1 --> NEVER["Dialog erscheint nicht mehr,<br/>bis die Regel gelöscht wird"]
    NG2 --> NEVER

Der Dialog wirkt also wie ein „Mechanismus, der den Benutzer um Erlaubnis bittet“, funktioniert im Umfeld von Business-Anwendungen aber tatsächlich als „Mechanismus, der im Moment, in dem ein normaler Benutzer ihn berührt, eine Blockierregel einbrennt“. Startet der für die Einführung Zuständige die Anwendung erstmals unter einem Administratorkonto und klickt im Dialog auf Zulassen, wirkt die entstandene Erlauben-Regel für den gesamten PC, sodass ab dem nächsten Tag auch normale Benutzer zunächst kommunizieren können. Trotzdem bleiben Risiken: wenn ein normaler Benutzer als Erster auf einen Lauschvorgang trifft, der bei der Funktionsprüfung während der Einführung nicht durchlaufen wurde, wenn das angewendete Netzwerkprofil vom Zeitpunkt der Einführung abweicht, und wenn sich der exe-Pfad durch ein Update ändert (Abschnitte 4 und 5).

Microsoft selbst nennt für Geräte, die nicht von Administratoren genutzt werden, ausdrücklich die folgenden bewährten Methoden.²

1. Die benötigten Regeln vor dem ersten Start der Anwendung platzieren (über das Installationsprogramm oder zentrale Verteilung)
2. Die eingehende Benachrichtigung deaktivieren (schaltet man die Benachrichtigung ab, entfällt die automatische Regelerstellung zur Laufzeit vollständig)

Die Benachrichtigung lässt sich mit Set-NetFirewallProfile -NotifyOnListen False oder über Gruppenrichtlinien deaktivieren.⁷ „Wenn der Dialog erscheint, lassen wir jemanden vor Ort einfach zulassen“ ist kein Betriebsverfahren, sondern eine vorprogrammierte Störung. Eingehende Regeln werden bei der Installation registriert — das ist die Schlussfolgerung dieses Artikels, und sie deckt sich mit Microsofts eigener Empfehlung.

4. Design eingehender Regeln — Programm-, Port- und Dienstangabe

Nun geht es um den Inhalt der zu registrierenden Regel. Es gibt grob drei Arten der Zielangabe, und Sie entscheiden, ob Sie sie einzeln oder kombiniert einsetzen.

Darüber hinaus schränken Sie den Geltungsbereich weiter ein. Auch Microsofts eigene Designempfehlung lautet: „Eingehende Regeln so spezifisch wie möglich gestalten.“²

• Profil einschränken: Beschränken Sie die eingehende Regel einer Business-Anwendung, die nur innerhalb des Unternehmens genutzt wird, auf Domäne/Privat und aktivieren Sie sie nicht für Öffentlich. Das verhindert den Vorfall, dass sich der lauschende Port der ganzen Welt öffnet, sobald ein Notebook mit einem externen WLAN verbunden wird.
• Remote-IP einschränken: Steht die Verbindungsquelle fest, grenzen Sie -RemoteAddress auf dieses Subnetz ein. Für Heim- und Kleinnetzwerke wird die Einschränkung über das Schlüsselwort LocalSubnet empfohlen.²³
• Richtung und Anzahl: Lauscht die Anwendung nur über TCP, genügt eine einzige TCP-Regel. Erstellen Sie nicht aus Gewohnheit sowohl eine TCP- als auch eine UDP-Regel, so wie es der Dialog automatisch tut.

„Vom nötigen Absender, zum nötigen Port, nur für das nötige Programm“ — das Design eingehender Regeln lässt sich vollständig auf diesen einen Satz minimaler Rechte zurückführen.

5. Registrierung in der Praxis über das Installationsprogramm — netsh und New-NetFirewallRule

5.1. Voraussetzung: Administratorrechte sind erforderlich

Das Hinzufügen und Entfernen von Firewall-Regeln ist eine Konfigurationsänderung für den gesamten Computer, daher muss dies mit Administratorrechten (einem erhöhten Prozess) ausgeführt werden.⁸ Da ein Installationsprogramm normalerweise bereits mit Administratorrechten läuft, ist es sinnvoll, die Regelregistrierung in den Installationsvorgang zu integrieren. Das ist kein Grund, die Anwendung selbst als Administrator auszuführen — diese Abgrenzung wird ausführlich in „Wann werden unter Windows tatsächlich Administratorrechte benötigt?“ behandelt.

5.2. Registrierung mit netsh advfirewall

Klassisch, aber aus jedem Installationsprogramm leicht aufrufbar, ist netsh advfirewall firewall add rule.⁸

rem "add rule" fügt auch dann hinzu, wenn bereits eine Regel mit demselben Namen
rem existiert; um Neuinstallation, Reparatur und Update-Wiederholungen abzusichern,
rem die gleichnamige Regel zuerst löschen und dann neu registrieren
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem Eingehende Erlauben-Regel mit Programm-, Port- und Profileinschränkung
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem Bei der Deinstallation: nach Name löschen
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule ersetzt eine vorhandene gleichnamige Regel nicht, sondern fügt unter demselben Namen eine weitere hinzu. Führen Sie deshalb nicht zuerst delete rule aus, vermehren sich die Regeln bei jeder erneuten Ausführung, und alte Erlauben-Regeln überleben selbst ein Update, das Pfad oder Geltungsbereich geändert hat (beim ersten Durchlauf meldet das vorangestellte delete rule zwar, dass „keine passende Regel“ gefunden wurde, die Batch-Ausführung läuft aber weiter, sodass diese Reihenfolge unproblematisch ist. Wertet Ihr Installationsprogramm Erfolg oder Misserfolg über den Exit-Code aus, prüfen Sie stattdessen das Ergebnis des abschließenden add rule). Mit remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet lässt sich auch die Verbindungsquelle eingrenzen.⁸ Da das Löschen alle namensgleichen Regeln auf einmal entfernt, ist es sicherer, den Regelnamen mit einem eigenen Firmenpräfix eindeutig zu machen.

5.3. Registrierung mit PowerShell (New-NetFirewallRule)

Für feinere Kontrolle steht das NetSecurity-Modul zur Verfügung. -DisplayName ist erforderlich, und -Profile lässt sich durch Kommas getrennt (ohne Leerzeichen) mehrfach angeben.³

# Registrierung (wird erhöht aus dem Installationsprogramm heraus ausgeführt). Da
# -Name der eindeutige Bezeichner ist, würde eine erneute Ausführung bei
# Neuinstallation, Reparatur oder Update mit einem Fehler abbrechen, weil eine
# Regel mit demselben Namen bereits existiert. Idempotent machen, indem die
# vorhandene gleichnamige Regel zuerst entfernt und dann neu erstellt wird
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 eingehend)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# Bei der Deinstallation: kein Fehler, falls die Regel nicht existiert
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

Dass hier -Name ausdrücklich angegeben wird, hat einen Grund. -Name ist der eindeutige Bezeichner der Regel, und lässt man ihn weg, wird ein Zufallswert zugewiesen. Der Anzeigename (-DisplayName) kann sich je nach Gebietsschema ändern, daher rät Microsoft, -Name als Schlüssel zu verwenden, um eine Regel aus einem Skript heraus zu identifizieren.³ Betrachten Sie ein fest vergebenes -Name auch als notwendig, damit der Deinstaller zuverlässig nur seine eigene Regel entfernt.

5.4. Wenn ein Update den exe-Pfad ändert

Eine Regel mit Programmangabe legt das Ziel über den vollständigen Pfad fest. Das heißt: Ändert ein Update den Installationsort oder den exe-Namen, bleibt die Regel zwar bestehen, verliert aber ihr Ziel, und das Lauschen wird erneut blockiert. Die exe am neuen Pfad wird dabei als „Anwendung ohne Regel“ behandelt, sodass in Umgebungen mit aktivierter Benachrichtigung der Dialog aus Kapitel 3 erneut erscheint und sich bei jeder Interaktion eines normalen Benutzers eine Blockierregel einbrennt. In Umgebungen, in denen die Benachrichtigung wie in Kapitel 3 empfohlen deaktiviert ist, schlägt es sogar ohne Dialog stillschweigend fehl. Besonders leicht passiert dieser Vorfall bei einer Ablage in versionsnummerierten Ordnern oder bei einem Selbstupdate-Mechanismus, bei dem sich der Ablageort verschiebt.

flowchart TB
    V1["v1.0 wird installiert<br/>Regel zeigt auf die exe im v1.0-Ordner"] --> UP["Update legt in den v1.1-Ordner ab<br/>Pfad der ausgeführten exe ändert sich"]
    UP --> MISS["Regel am alten Pfad verliert ihr Ziel<br/>(Regel besteht, wirkt aber nicht)"]
    MISS --> Q{"Ist die eingehende<br/>Benachrichtigung aktiviert?"}
    Q -- "Aktiviert" --> DLG["Dialog erscheint erneut<br/>Berührung durch normalen Benutzer erzeugt Blockierregel"]
    Q -- "Deaktiviert" --> SILENT["Kein Dialog,<br/>stille Blockierung"]
    MISS -.->|"Abhilfe"| FIX["Pfad über Updates hinweg fest halten<br/>oder alte Regel im Update-Prozess löschen und neu registrieren"]

Die Abhilfe ist einfach und läuft auf eines der folgenden hinaus:

• Den Installationsort fest wählen, sodass sich der vollständige Pfad der exe über Updates hinweg nicht ändert
• Bei einem Update, das den Pfad ändert, die alte Regel durch den Updater löschen und unter dem neuen Pfad neu registrieren lassen (die Befehle aus 5.2/5.3 auch im Update-Prozess ausführen)

Bei einer MSI ist es die bewährte Vorgehensweise, die Regelregistrierung als benutzerdefinierte Aktion einzubinden, die nach der Dateiablage ausgeführt wird (und bei der Deinstallation entsprechend als löschende benutzerdefinierte Aktion). Toolsets wie WiX bieten auch Erweiterungen, mit denen sich Firewall-Regeln deklarativ beschreiben lassen. Welche Verteilungsmethode Sie wählen, bestimmt, an welcher Stelle Sie das implementieren; siehe dazu auch „Die Wahl der Verteilungsmethode für Windows-Apps“. Ein weiteres klassisches Problem bei der Einführung beim Kunden, Fehlalarme der Virenschutzsoftware, wird in „Umgang mit Fehlalarmen von Microsoft Defender“ behandelt.

6. Fehlerbehebung — Triage-Ablauf für „keine Verbindung möglich“

Legen Sie das Vorgehen bei eingehenden Meldungen als feste Reihenfolge fest. Der Gesamtablauf sieht wie folgt aus.

flowchart TB
    S["Meldung: keine Verbindung vom Client"] --> N["Serverseite: netstat -ano"]
    N -- "Lauscht nicht" --> APP["Problem liegt vor der Firewall<br/>Anwendungs-/Dienstseite untersuchen"]
    N -- "LISTENING" --> T["Clientseite: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["Erreichbarkeit ist in Ordnung<br/>Anwendungsschicht (Authentifizierung/Protokoll) untersuchen"]
    T -- "False" --> P["Serverseite: Get-NetConnectionProfile<br/>angewendetes Profil prüfen"]
    P -- "Stimmt nicht mit dem Regelziel überein" --> FIXP["Profilangabe der Regel überprüfen"]
    P -- "Stimmt überein" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>Erlauben-Regel vorhanden? Blockierregel eingemischt?"]
    R --> LOGCHK["Verwerfen (DROP) über pfirewall.log nachweisen"]

Eine Ergänzung zu Schritt 4. Da die Bedingungen für Port und Programm nicht in der Regel selbst, sondern im Filterobjekt liegen, muss man für die Rückwärtssuche von Regeln über einen Port den Weg über den Filter gehen.⁵⁷

# Regeln zum Port 50051 rückwärts ermitteln
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# Herkunft der Regel (lokal oder GPO) nachverfolgen
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

Das Firewall-Protokoll (pfirewall.log) aus Schritt 5 zeichnet standardmäßig nichts auf. Der Standardpfad lautet %windir%\system32\logfiles\firewall\pfirewall.log, die standardmäßige Höchstgröße beträgt 4.096 KB, und geschrieben wird erst, wenn Sie entweder „verworfene Pakete protokollieren“ oder „erfolgreiche Verbindungen protokollieren“ aktivieren.⁶ Auf einer einzelnen Maschine können Sie es wie folgt aktivieren.⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

Das Protokoll ist eine Textdatei, in der zeilenweise festgehalten wird, ob verworfen (DROP) oder erlaubt (ALLOW) wurde, sowie Protokoll, Quell-/Ziel-IP und -Port — damit lässt sich zweifelsfrei klären, ob „das SYN vom Client angekommen und verworfen wurde“ oder ob „es überhaupt nicht angekommen ist“. Beachten Sie, dass in Umgebungen, in denen die Protokollierung per Richtlinie konfiguriert wurde, dem Protokollordner mitunter das Schreibrecht fehlt (FullControl für den Dienst mpssvc), sodass die Datei nicht erstellt wird; in diesem Fall müssen Sie den Ordner manuell anlegen und die ACL vergeben.⁶

Für noch tiefere Untersuchungen können Sie die Überwachungsrichtlinie „Paketverwerfung der Filterplattform überwachen“ aktivieren; dann wird bei jedem Verwerfen das Sicherheitsereignis 5152 protokolliert. Da das Ereignisaufkommen jedoch sehr hoch ist, empfiehlt Microsoft stattdessen das pro Verbindung protokollierte Ereignis 5157 (Verbindung der Filterplattform). Das ist ein Werkzeug für die Dauer der Fehlereingrenzung, nicht für den Dauerbetrieb.⁹

Zum Schluss noch eine klare Warnung vor einer Vorgehensweise, die Sie zur Fehlereingrenzung nicht anwenden dürfen. Die komplette Deaktivierung durch Stoppen des Firewall-Dienstes (MpsSvc) wird nicht unterstützt und verursacht Probleme auf Betriebssystemebene, etwa ein nicht funktionierendes Startmenü oder fehlschlagende Updates von Store-Apps. Wenn Sie zur Überprüfung unbedingt deaktivieren müssen, lassen Sie den Dienst laufen und deaktivieren stattdessen mit Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False das Profil — und setzen es unmittelbar nach der Prüfung wieder zurück.¹⁷ Steht die Firewall einmal als Ursache fest, besteht die richtige Maßnahme nicht darin, die Deaktivierung dauerhaft zu belassen, sondern darin, eine einzige korrekte Regel hinzuzufügen.

7. Hinweise unter zentraler Organisationsverwaltung — Umgebungen, in denen lokale Regeln nicht wirken, und wie man sie richtig beantragt

Es gibt Umgebungen, in denen eine über das Installationsprogramm registrierte Regel nicht wirkt. Organisationen, die ihre Firewall zentral über GPO oder Intune (CSP) verwalten, können pro Profil das „Zusammenführen lokaler Regeln“ (AllowLocalPolicyMerge) deaktivieren. Ist diese Einstellung deaktiviert, werden Regeln, die von einem lokalen Administrator — einschließlich des Installationsprogramms — erstellt wurden, nicht angewendet, und Regeln für Anwendungen, die eingehende Verbindungen benötigen, müssen zwingend zentral über GPO/CSP verteilt werden.²

flowchart TB
    GPOR["Über GPO/Intune verteilte Regeln"] --> EFF["Menge der tatsächlich wirksamen Regeln<br/>(ActiveStore)"]
    LOCAL["Lokal erstellte Regeln<br/>(einschließlich Installer-Registrierung)"] --> Q{"Zusammenführen lokaler Regeln<br/>(AllowLocalPolicyMerge)"}
    Q -- "Aktiviert (Standard)" --> EFF
    Q -- "Deaktiviert" --> DROP["Regel existiert, wird aber nicht angewendet<br/>-> auf zentrale Verteilung über GPO/CSP umstellen"]

Aus Entwickler- und Einführungssicht ist eine realistische Absicherung Folgendes:

• Die Regelregistrierung im Installationsprogramm so gestalten, dass sie „nicht fehlschlägt“ (die Registrierung selbst gelingt in jedem Fall, sodass sich das Problem nicht über einen Fehler erkennen lässt — nehmen Sie eine Konnektivitätsprüfung nach der Einführung in Ihr Vorgehen auf)
• Mit Schritt 4 aus Kapitel 6 (-TracePolicyStore) prüfen, ob die wirksamen Regeln aus lokaler Quelle oder aus GPO stammen⁵
• Stellt sich heraus, dass lokale Regeln in dieser Umgebung nicht wirken, auf einen Antrag zur Regelverteilung bei der IT-Abteilung umsteigen

Übergeben Sie beim Antrag die folgenden Angaben vollständig zusammen. Eine Firewall-Regel lässt sich erst erstellen, wenn Richtung, Programm, Port und Geltungsbereich vollständig vorliegen, sodass diese Tabelle unmittelbar als „Netzwerkspezifikation der Business-Anwendung“ dient.

Auch aus Sicht der IT-Abteilung ist der Aufwand mit und ohne diese Tabelle grundverschieden. Umgekehrt neigt eine bloße Bitte „bitte diesen Port öffnen“ ohne weitere Angaben, wie in Kapitel 4 gezeigt, zu übermäßiger Freigabe. Beachten Sie außerdem, dass sich die Kommunikationsanforderungen rund um Dateifreigaben und Authentifizierung in Domänenumgebungen auch durch andere Verschärfungen als die Firewall ändern, etwa durch verpflichtende Signierung. Siehe dazu auch „SMB-Signierung und LDAP-Channel-Binding“.

8. Zusammenfassung

• Der Standard der Windows-Firewall ist eingehend blockiert, ausgehend erlaubt. Eine eingehende Regel wird nur für lauschende Anwendungen vom Servertyp benötigt; wer nur als Client eine Verbindung aufbaut, braucht grundsätzlich keine.
• Regeln werden pro Profil (Domäne/Privat/Öffentlich) angewendet. Der erste Verdächtige, wenn „die Regel existiert, aber nichts durchkommt“, ist eine falsche Profilzuordnung.
• Der Dialog „Wichtige Warnung“ erstellt bei Abbruch oder bei der Aktion eines Benutzers ohne Rechte eine Blockierregel und erscheint danach nicht mehr. Sie dürfen den Produktivbetrieb nicht diesem Dialog überlassen.
• Registrieren Sie die eingehenden Regeln einer Business-Anwendung über das Installationsprogramm — das ist der einzige Grundsatz. Setzen Sie die Registrierung mit Administratorrechten um und verwenden Sie durchgängig, auch beim Löschen, ein fest vergebenes -Name.
• Bauen Sie Regeln um Programm + Protokoll + Port herum auf und grenzen Sie sie über Profil und Remote-IP ein. Vergessen Sie nicht, die Regel neu zu registrieren, wenn ein Update den exe-Pfad ändert.
• Grenzen Sie mechanisch in der Reihenfolge netstat → Test-NetConnection → Profilprüfung → Get-NetFirewallRule (ActiveStore) → pfirewall.log ein. Eine Deaktivierung durch Stoppen des Dienstes wird nicht unterstützt.
• Unter GPO-/Intune-Verwaltung kann das Zusammenführen lokaler Regeln deaktiviert sein. Beantragen Sie in diesem Fall die Verteilung bei der IT-Abteilung mit vollständigen Angaben zu Regelname, Richtung, Programm, Port, Remote-IP und Profil.

Verwandte Artikel

• Wie man die passende Interprozesskommunikation unter Windows wählt — Entscheidungstabelle für Named Pipes / TCP / gRPC / Shared Memory / COM
• Die Wahl der Verteilungsmethode für Windows-Apps - MSI/MSIX/ClickOnce/xcopy/eigener Updater
• Wann werden unter Windows tatsächlich Administratorrechte benötigt? - UAC, geschützte Bereiche und wie man es am Design erkennt
• Wenn Ihre selbst entwickelte Windows-App als Virus eingestuft wird — Umgang mit Fehlalarmen von Microsoft Defender und der Umgang mit Leistungseinbußen
• SMB-Signierung und LDAP-Channel-Binding — Die „andere Hälfte“ der NTLM-Abwehr in der Praxis schließen
• Wie man Windows-Dienste erstellt und betreibt — Von der Abgrenzung zum Taskplaner bis zur Umwandlung eines BackgroundService in einen Dienst

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt das Design von Installationsprogrammen für Business-Anwendungen vom Servertyp (einschließlich Registrierung und Entfernung von Firewall-Regeln), die Ursachenuntersuchung von „keine Verbindung möglich“ in der Umgebung beim Kunden sowie die Zusammenstellung von Netzwerkanforderungen im Hinblick auf eine Einführung unter GPO-Verwaltung. Es reicht, mit der Eingrenzung von „funktioniert auf dem Entwicklungsrechner, aber nicht beim Kunden“ zu beginnen.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Braucht auch eine App, die nur als Client eine Verbindung zum Server aufbaut, eine Firewall-Regel?

Grundsätzlich nicht. Da die Windows-Firewall standardmäßig eingehenden Verkehr blockiert und ausgehenden erlaubt, kann eine Client-App, die nur selbst eine Verbindung aufbaut, unter den Standardeinstellungen problemlos kommunizieren. Eine eingehende Regel wird nur für die Seite benötigt, die einen Port öffnet und auf Verbindungen wartet — also für Anwendungen vom Servertyp. Es gibt jedoch zwei Ausnahmen. In hochsicheren Umgebungen ist mitunter auch der ausgehende Verkehr standardmäßig blockiert; dann muss zusätzlich eine ausgehende Regel beantragt werden. Und selbst eine „Client“-App braucht eine eingehende Regel für den Teil, der selbst einen Port zum Empfang von Ergebnisbenachrichtigungen offenhält.

Reicht es nicht, im Dialog „Windows-Sicherheitshinweis“ auf „Zugriff zulassen“ zu klicken?

Im Moment schon, aber Sie können den Produktivbetrieb nicht darauf verlassen. Wenn ein Benutzer mit Administratorrechten diesen Dialog abbricht, wird eine Blockierregel erstellt. Und bei einem Benutzer ohne Administratorrechte wird unabhängig von der gewählten Schaltfläche eine Blockierregel erstellt. Sobald eine Regel einmal erstellt wurde, erscheint der Dialog nie wieder, bis diese Regel gelöscht wird, und die Kommunikation schlägt weiterhin fehl. Bei Business-Anwendungen, die vor Ort von normalen Benutzern bedient werden, entsteht so leicht der Zustand, dass „jemand hat einmal abgebrochen, und seitdem funktioniert die Verbindung nie wieder“. Microsoft selbst empfiehlt, die Regel bereits vor dem ersten Start der App zu platzieren, um genau das zu vermeiden.

Sollte eine eingehende Regel eher über den Port oder über das Programm definiert werden?

Grundsätzlich kombiniert man beides, statt sich auf eines allein zu verlassen. Die Programmangabe grenzt das Ziel über den vollständigen Pfad der exe ein, verliert aber bei einer Update-bedingten Pfadänderung ihr Ziel (Platzhalter sind nicht zulässig). Die Portangabe macht den Antrag an die IT-Abteilung eindeutig, lässt aber auch jeden anderen Prozess durch, der auf demselben Port lauscht. Bei einer produktiven Business-Anwendung ist das Muster minimaler Rechte: die Regel um „Programm + Protokoll + Port“ herum aufbauen, das Profil auf Domäne/Privat beschränken und die Remote-IP auf das Subnetz des Clients eingrenzen. Nur wenn der Port dynamisch ist, verwendet man die Programmangabe allein.

Die vom Installationsprogramm registrierte Regel scheint auf dem PC beim Kunden nicht zu wirken. Woran liegt das?

Es ist sehr wahrscheinlich, dass die Firewall beim Kunden zentral über GPO oder Intune verwaltet wird und dort das „Zusammenführen lokaler Regeln“ (AllowLocalPolicyMerge) deaktiviert ist. Ist diese Einstellung deaktiviert, existiert eine lokal erstellte Regel zwar im Profil, wird aber nicht angewendet — Regeln können dann nur noch zentral über GPO/CSP verteilt werden. Prüfen Sie mit Get-NetFirewallRule -PolicyStore ActiveStore die Gesamtheit der wirksamen Regeln und beantragen Sie die Verteilung der Regel bei der IT-Abteilung. Wenn Sie im Antrag Regelname, Richtung, Programmpfad, Protokoll und Port, Remote-IP-Bereich sowie Profil vollständig zusammenstellen, geht er in der Regel beim ersten Mal durch.

Darf man die Firewall zur Fehlereingrenzung vorübergehend deaktivieren?

Vermeiden Sie unbedingt eine Deaktivierung durch Stoppen des Dienstes (MpsSvc). Das ist eine von Microsoft nicht unterstützte Vorgehensweise und verursacht Probleme auf Betriebssystemebene, etwa dass das Startmenü nicht mehr funktioniert oder Updates von Store-Apps fehlschlagen. Wenn Sie zur Fehlereingrenzung unbedingt deaktivieren müssen, ist die korrekte Methode, den Dienst weiterlaufen zu lassen und stattdessen mit Set-NetFirewallProfile -Enabled False das Profil zu deaktivieren. Aber auch das sollte sich auf wenige Minuten beschränken, um zu prüfen, ob die Firewall die Ursache ist — sobald die Prüfung abgeschlossen ist, sofort wieder aktivieren. Ein dauerhafter Betrieb mit deaktivierter Firewall tauscht ein Problem, das sich mit einer einzigen zusätzlichen Regel lösen ließe, gegen die völlige Schutzlosigkeit des gesamten PCs ein.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.