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

„Auf dem Entwicklungsrechner läuft es, aber sobald es auf dem PC des Kunden installiert ist, kann ein anderes Gerät nicht verbinden.“ In solchen Meldungen kommt der Verdacht auf die Windows-Firewall vor. Dass keine Verbindung zustande kommt und dass die Firewall sie blockiert, ist jedoch nicht dasselbe. Manchmal lauscht die App gar nicht; manchmal sind Ziel oder Port falsch; manchmal passt die Zulassungsregel nicht zu den Bedingungen des Netzes.

Auf einem Entwicklungsrechner bleiben oft Zulassungsregeln aus der Vergangenheit stehen. Wer das Verhalten in diesem Zustand prüft, reproduziert nicht, wie eine frische Einführungsstelle sich verhält. Statt vorauszusetzen, dass jemand die Warnung beim ersten Start zulässt, muss das Einführungsverfahren des Produkts festhalten, welcher Verkehr von wem in welcher Phase erlaubt wird. Auch Microsoft empfiehlt, die benötigten Regeln vor dem ersten Start der App zu platzieren.¹

Dieser Artikel nimmt als Hauptbeispiel eine Fachanwendung, die TCP-Verbindungen von einem anderen Gerät entgegennimmt, und arbeitet Regelentwurf, die Einbindung der Registrierung ins Installationsprogramm und die Prüfreihenfolge, wenn beim Kunden keine Verbindung zustande kommt. Er geht von Windows 11 und Windows Server aus; die technischen Erklärungen stützen sich auf die am 8. September 2026 geprüften öffentlichen Unterlagen von Microsoft. Produktnamen, Pfade, Ports und IP-Bereiche in den Befehlen sind Beispiele. Ersetzen Sie sie passend zu Ihrer Umgebung.

1. Zuerst die Kernaussage

Drei Punkte gehören an den Anfang.

• Ob eine eingehende Regel nötig ist, entscheidet die Richtung des Verkehrs, nicht der Name der App. Unterscheiden Sie, ob sie nur selbst Verbindungen aufbaut oder auf neuen Verkehr von einem anderen Gerät wartet.²
• Platzieren Sie die benötigten Regeln vor dem ersten Start. Auf Geräten, auf denen lokale Verwaltung zulässig ist, ist das Installationsprogramm eine Option; auf zentral verwalteten Geräten die Verteilung über GPO, Intune oder einen vergleichbaren Mechanismus.¹
• Wenn etwas ausfällt, prüfen Sie in der Reihenfolge Lauschzustand, TCP-Verbindung, Profil, Regeln, Protokoll. Wichtig ist, weder allein aus der Existenz einer Regel auf Zulassung zu schließen noch allein aus einem fehlenden Protokolleintrag auf Nichterreichen.³⁴⁵⁶

Die Schlussfolgerung dieses Artikels, „über das Installationsprogramm registrieren“, bedeutet nicht, die verwaltete Richtlinie der Organisation zu überschreiben. Sie bedeutet, die für den Verkehr nötigen Einstellungen in einem Einführungsschritt mit klarer Verantwortung zu schaffen, nicht in der ersten Bedienung durch den Nutzer.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (35 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

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

Die Windows-Firewall ist eine hostbasierte Firewall, die den Verkehr des Geräts steuert, auf dem sie läuft. Standardmäßig blockiert sie eingehenden Verkehr, der weder Antwort auf eine Anfrage noch Treffer einer Zulassungsregel ist, und sie erlaubt ausgehenden Verkehr, sofern nicht etwa eine Blockierregel greift. Das sind Windows-Standardwerte, und sie sind keine Garantie, dass der Administrator beim Kunden sie nicht geändert hat.²

Verbindet sich etwa ein Auftragseingabe-Client mit TCP 50051 auf dem Auftragsserver, nimmt die Serverseite die neue Verbindung entgegen. Der Client öffnet keinen eingehenden Port derselben Nummer, um Antworten auf dieser Verbindung zu empfangen.²

Entfernte Named Pipes laufen über SMB. Übliches direkt gehostetes SMB verwendet TCP 445, daher löst eine Zulassung nur für die exe der eigenen App das Problem nicht unbedingt. Unterscheiden Sie lokale Named Pipes von der Nutzung über das Netz. SMB-Authentifizierung und Zugriffsrechte sind zusätzlich nötig.⁷⁸

Die folgende Abbildung, ausgehend vom Standard „eingehend blockiert“, dient dazu, die Teile zu finden, die Verbindungen von einem anderen Gerät entgegennehmen. „Eingehende Regel erforderlich“ heißt, dass eine Einstellung den eingehenden Verkehr erlauben muss; decken vorhandene verwaltete Regeln das bereits ab, muss die App keine doppelte Regel hinzufügen. Verkehr, der auf demselben PC bleibt, und UDP-Verkehr werden von dieser TCP-Verbindungsabbildung getrennt behandelt.

flowchart TB
    APP["Den Verkehr der eigenen App 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 oder Rückrufempfang)" --> S1["Eingehende Regel erforderlich<br/>-> Registrierung über Installer (Kapitel 5)"]
    C1 -.-> EX["Ausnahme: wo der Ausgang standardmäßig blockiert ist<br/>in einer Hochsicherheitsumgebung, eine ausgehende Regel beantragen"]

In Umgebungen, in denen der ausgehende Standard auf Blockieren umgestellt wurde, oder in denen eine Regel den ausgehenden Verkehr der App ausdrücklich verbietet, braucht auch die verbindende Seite eine Zulassung. Man kann nicht pauschal sagen: „es ist ein Client, also ist die Firewall belanglos“.¹ Wer den Kommunikationsmechanismus selbst sortieren will, siehe auch wie man ein Verfahren zur Interprozesskommunikation wählt.

2.1. Profile und der „Netzwerkstandort“

Jede Regel trägt die Bedingung, in welchen Netzwerkprofilen sie wirksam ist. Die typische Anwendung ist wie folgt.²

Das aktuell verbundene Netz prüfen Sie mit dem folgenden Befehl. Auf Geräten mit mehreren Adaptern oder einem VPN gleichen Sie nicht nur den Namen, sondern auch die für den Verkehr verwendete Schnittstelle ab.²

Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Eine auf Domäne und Privat begrenzte Regel gilt nicht, wenn der betreffende Verkehr zum Profil Öffentlich gehört. Wichtig ist jedoch, das Netz nicht nur deshalb auf Privat umzustellen oder die Regel auf alle Profile zu weiten, damit Verkehr durchkommt. Legen Sie mit dem Administrator fest, wie weit das Netz des Kunden vertraut wird und für welche Profile die App zugelassen ist.

2.2. Vorrang der Regeln

Bei gewöhnlichen Zulassungs- und Blockierregeln hat eine ausdrückliche Zulassung Vorrang vor dem Standard „eingehend blockiert“, aber eine ausdrückliche Blockierregel, die denselben Verkehr trifft, hat Vorrang vor einer kollidierenden Zulassungsregel. Es gewinnt nicht, was zuletzt hinzugefügt wurde.¹

Wenn also „wir haben eine Zulassungsregel hinzugefügt und nichts hat sich geändert“, prüfen Sie, ob die Zulassungsbedingungen passen, und außerdem Blockierregeln, die auf dieselbe App oder denselben Port zutreffen. Allein dass eine Regel fremden Verkehr stoppt, stoppt nicht den gesamten Verkehr auf dem Gerät. Besondere Umgehungsregeln mit IPsec-Authentifizierung sind ein anderer Entwurf als die gewöhnlichen Zulassungsregeln dieses Artikels.

3. Was der Dialog „Wichtige Warnung“ wirklich ist — warum man sich nicht darauf verlassen darf

Beginnt eine App ohne passende Regel zu lauschen, erscheint je nach Konfiguration und Laufzeitbedingungen die Meldung, einige Funktionen dieser App würden von der Windows Defender Firewall blockiert. Auf verwalteten Geräten, auf denen Benachrichtigungen ausgeschaltet sind, erscheint sie nicht; das Ausbleiben einer Warnung ist kein Beleg, dass der Verkehr erlaubt wurde.¹

Microsoft beschreibt das Verhalten, wenn die Benachrichtigung angezeigt wird, wie folgt.¹

Bleibt eine so erzeugte Regel stehen, bringt ein Neustart der App dieselbe Abfrage nicht zurück. Wurde insbesondere eine Blockierregel erzeugt, reicht das Hinzufügen einer Zulassungsregel allein möglicherweise nicht. Nach Prüfung, woher jede Regel stammt und ob sie nötig ist, räumt der Administrator sie in begrenztem Umfang auf. Die App darf eine Blockierregel, die die Organisation absichtlich verteilt hat, niemals löschen.

Die nächste Abbildung zeigt, wie aus der Benachrichtigung eine Regel entsteht. Die Bedingungen, unter denen die Benachrichtigung tatsächlich erscheint, und der Wortlaut auf dem Bildschirm unterscheiden sich je nach OS und Verwaltungseinstellung.

flowchart TB
    L["Eine App beginnt, auf einem Port zu lauschen"] --> Q1{"Gibt es eine Regel, die<br/>zu dieser App passt"}
    Q1 -- "Ja" --> R1["Die Regel gilt<br/>(kein Dialog erscheint)"]
    Q1 -- "Nein" --> Q2{"Sind eingehende Benachrichtigungen<br/>aktiviert"}
    Q2 -- "Deaktiviert" --> R2["Still blockiert<br/>(es wird keine Regel erzeugt)"]
    Q2 -- "Aktiviert" --> DLG["Dialog Wichtige Warnung"]
    DLG -- "Administrator wählt Zugriff zulassen" --> OK["Eine Zulassungsregel wird erzeugt"]
    DLG -- "Administrator wählt Abbrechen" --> NG1["Eine Blockierregel wird erzeugt"]
    DLG -- "Benutzer ohne Administratorrechte<br/>(jede Wahl)" --> NG2["Eine Blockierregel wird erzeugt"]
    NG1 --> NEVER["Der Dialog erscheint nicht wieder,<br/>bis die Regel gelöscht wird"]
    NG2 --> NEVER

Auch wenn jemand sie bei der Einführung einmal zulässt, bleiben die Bedingungen: eine andere Funktion beginnt zu lauschen, das Netzwerkprofil ändert sich, ein Update ändert den Pfad der exe. Zuerst den benötigten Verkehr zu erfassen und die Regeln vor dem ersten Start bereitzustellen, macht die Einführung reproduzierbarer.¹

Für Geräte, die Nicht-Administratoren nutzen, empfiehlt Microsoft, Regeln im Voraus zu platzieren und eingehende Benachrichtigungen zu deaktivieren. Benachrichtigungen lassen sich mit Set-NetFirewallProfile -NotifyOnListen False oder über die Gruppenrichtlinie steuern, aber das ist eine Entscheidung dessen, der die geräteweite Benachrichtigungsrichtlinie verwaltet. Es ist kein Grund für das Installationsprogramm einer Fachanwendung, ohne Erlaubnis eine Benachrichtigungseinstellung zu ändern, die auch andere Apps betrifft. Das Abschalten der Benachrichtigungen erlaubt den benötigten Verkehr nicht.¹⁹

4. Entwurf eingehender Regeln — nach Programm, nach Port, nach Dienst

Schreiben Sie zuerst die Kommunikationsspezifikation getrennt nach Ein-/Ausgang, TCP/UDP, Lauschport, ausführender Instanz, Gegenstelle und verwendetem Netz auf. Kombinieren Sie das dann zu den Bedingungen der Regel.¹⁰

An -Program übergeben Sie die exe, die den Verkehr tatsächlich ausführt, nicht eine Verknüpfung oder einen Starter. Lauscht ein anderer Dienst oder Hostprozess, muss der Entwurf zu dieser ausführenden Instanz passen. Auch bei dynamischen Ports öffnen Sie nicht sofort alle Ports bedingungslos; erwägen Sie, wie weit Sie nach Programm, Dienst, Gegenstelle und so weiter eingrenzen können.¹⁰³

Darüber hinaus begrenzen Sie die verwendeten Netze mit -Profile und die Gegenstelle mit -RemoteAddress. Sitzt der Auftragseingabe-Client etwa fest in 172.16.10.0/24, geben Sie diesen Bereich an. LocalSubnet ist eine Angabe, die man in kleinen Netzen nutzen kann, bedeutet aber nicht, dass „alle Standorte im Unternehmen“ oder „die andere Seite des VPN“ automatisch enthalten sind. Prüfen Sie den tatsächlichen Weg und die Quelladresse, wie die empfangende Seite sie sieht.¹¹⁰

Eine Funktion, die nur TCP nutzt, braucht UDP nicht vorsorglich erlaubt. Und soll eine nur interne Funktion auch auf Öffentlich gelten, müssen Notwendigkeit und die Begrenzung der Gegenstelle gesondert erklärbar sein. Ausgangspunkt des Regelentwurfs ist, nur den Verkehr durchzulassen, den Sie brauchen, für das Programm, das Sie brauchen, von den Gegenstellen, die Sie brauchen.

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

5.1. Voraussetzung: Administratorrechte sind nötig

Das Registrieren, Ändern oder Löschen geräteweiter Firewall-Regeln läuft mit erhöhten Administratorrechten. Auch ein Benutzer in der Gruppe Administratoren kommt nicht unbedingt ohne UAC-Erhöhung aus.¹¹

Legen Sie den Registrierungsschritt in die erhöhte Phase des Installationsprogramms, muss die App selbst nicht dauerhaft als Administrator laufen. Umgekehrt hat ein benutzerbezogenes Installationsprogramm, das vollständig als Standardbenutzer durchläuft, keine Berechtigung, geräteweite Regeln zu ändern. Machen Sie in dem Fall eine gesonderte, vom Administrator ausgeführte Einrichtung oder die Verteilung der Regel durch die Organisation zur Einführungsvoraussetzung. Halten Sie die Situationen, die Administratorrechte erfordern, getrennt von den Rechten, die die App für den Alltag braucht.

Das Folgende setzt voraus, dass Ihre eigene exe auf einem festen Port lauscht und dass das Gerät dem Installationsprogramm die Verwaltung lokaler Regeln gestattet. Es enthält nichts, das Einschränkungen einer verwalteten Richtlinie aufhebt.

5.2. Registrieren mit netsh advfirewall

Mit netsh können Sie Programm, TCP-Port, Profile und Gegenstelle gemeinsam wie folgt angeben. Das ist ein Beispiel für die Erstanlage auf einem Gerät, das dieselbe Regel noch nicht hat. Es setzt die Ausführung als Batchdatei aus einer als Administrator gestarteten Eingabeaufforderung voraus.¹¹

@echo off
netsh advfirewall firewall add rule ^
  name="MyCompany OrderServer TCP 50051 In" ^
  dir=in action=allow enable=yes ^
  program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" ^
  protocol=TCP localport=50051 ^
  profile=domain,private remoteip=172.16.10.0/24
if errorlevel 1 exit /b 1

Dasselbe add rule zu wiederholen aktualisiert nichts, und es können immer mehr Regeln desselben Namens entstehen. Löschen und neu anlegen hat das eigene Problem: schlägt die Registrierung nach dem Löschen fehl, ist die Regel weg. Für Produkte, die Reparatur und Update wiederholen, empfiehlt sich ein Entwurf, der eine Kennung festlegt und die vorhandene Regel aktualisiert, wie im nächsten Abschnitt.

Der Entfernungsbefehl ist getrennt. Führen Sie die folgende Löschung nur bei der Deinstallation aus; hängen Sie sie nicht an das Ende der Registrierungsbatch oben. Sie trifft Regeln, die dem Namen entsprechen, verwenden Sie also einen Namen, der nicht mit anderen Produkten kollidiert.¹¹

netsh advfirewall firewall delete rule name="MyCompany OrderServer TCP 50051 In"

Halten Sie Exitcodes und Fehlerausgabe im Protokoll des Installationsprogramms fest und unterscheiden Sie „Registrierung fehlgeschlagen“, „bereits gelöscht“ und „keine Berechtigung“. Wichtig ist auch, dem Nutzer nicht mitzuteilen, die Kommunikationsvorbereitung sei abgeschlossen, wenn die Registrierung in Wahrheit fehlgeschlagen ist.

5.3. Registrieren mit PowerShell (New-NetFirewallRule)

Das NetSecurity-Modul in PowerShell trennt -Name, das die Regel identifiziert, von -DisplayName, das auf dem Bildschirm erscheint. Für die Kennung eines Skripts verwenden Sie ein festes -Name, das von Anzeigesprache und Formulierungsänderungen unberührt bleibt.¹⁰

Als Nächstes ein Beispiel für Installation, Reparatur und Update, das beim erneuten Ausführen derselben Verarbeitung keine Regeln vervielfacht. Es verwendet Set-NetFirewallRule, wenn die Regel schon existiert, und New-NetFirewallRule, wenn nicht. Der Parameter zum Aktualisieren des Anzeigenamens ist -NewDisplayName.¹²

# Für Installation, Reparatur und Update. Als Administrator ausführen.
$ErrorActionPreference = "Stop"
$ruleName = "MyCompany-OrderServer-In"
$displayName = "MyCompany OrderServer (TCP 50051 inbound)"
$program = "C:\Program Files\MyCompany\OrderServer\OrderServer.exe"

if (-not (Test-Path -LiteralPath $program -PathType Leaf)) {
    throw "Ausführbare Datei nicht gefunden: $program"
}

# Einstellungen der lokalen Regel, die dieses Produkt besitzt.
# Gegenstelle und Profile durch mit dem Administrator vor Ort vereinbarte Werte ersetzen.
$settings = @{
    PolicyStore   = "PersistentStore"
    Direction     = "Inbound"
    Action        = "Allow"
    Enabled       = "True"
    Program       = $program
    Protocol      = "TCP"
    LocalPort     = 50051
    Profile       = @("Domain", "Private")
    RemoteAddress = "172.16.10.0/24"
}

# „Die Regel existiert nicht“ von einem Fehlschlag der Abfrage selbst unterscheiden.
$existing = @(Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq $ruleName })

if ($existing.Count -eq 0) {
    New-NetFirewallRule -Name $ruleName -DisplayName $displayName @settings |
        Out-Null
} else {
    Set-NetFirewallRule -Name $ruleName -NewDisplayName $displayName @settings
}

Dieses Beispiel ändert nur die Regel im PersistentStore, deren Namen Ihr Unternehmen verwaltet. Verwenden Sie dieselbe Kennung nicht für einen anderen Zweck. Und in einem Produkt, das später Bedingungen wie einen Quellport oder einen Dienst hinzugefügt hat, entwerfen Sie die Übernahme dieser Bedingungen ausdrücklich mit. Set-NetFirewallRule setzt nicht jede nicht angegebene Bedingung in den Ausgangszustand zurück.¹²

Das Löschen gehört in die folgende nur für die Deinstallation vorgesehene Verarbeitung. Sie löscht nichts, wenn die Zielregel fehlt, versteckt aber einen Fehlschlag der Abfrage oder des Löschens selbst nicht.⁵⁹

# Für die Deinstallation. Nicht unmittelbar nach der Registrierung ausführen.
$ErrorActionPreference = "Stop"
Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq "MyCompany-OrderServer-In" } |
    Remove-NetFirewallRule -ErrorAction Stop

Das sind Beispiele für die Registrierung, keine Implementierung der Transaktion des gesamten Installationsprogramms. Wenn Sie sie in ein Produkt einbauen, bestätigen Sie, dass eine fehlgeschlagene Einstellungsänderung an das Installationsprogramm gemeldet wird, dass ein fehlgeschlagenes Update auf die alte Version und die alten Einstellungen zurückkann, und dass die Deinstallation nur die eigenen Regeln löscht.

5.4. Wenn ein Update den exe-Pfad ändert

Eine programmbezogene Regel verwendet den registrierten Pfad als Bedingung. Existiert etwa eine Regel für die exe im Ordner v1.0, lauscht nach einem Update die exe im Ordner v1.1, dann trifft die alte Regel die neue exe nicht mehr.¹¹⁰

Die nächste Abbildung betrifft den Fall, in dem Sie nur von dieser Regel mit altem Pfad abhingen. Sie stellt nicht einheitlich Fälle dar, in denen eine andere wirksame Zulassungsregel existiert, oder Laufzeitbedingungen, in denen keine Benachrichtigung erscheint.

flowchart TB
    V1["v1.0 ist installiert<br/>die Regel zeigt auf die exe im Ordner v1.0"] --> UP["Ein Update legt sie in den Ordner v1.1<br/>der Pfad der ausgeführten exe ändert sich"]
    UP --> MISS["Die Regel mit altem Pfad verliert ihr Ziel<br/>(die Regel bleibt, wirkt aber nicht)"]
    MISS --> Q{"Sind eingehende Benachrichtigungen<br/>aktiviert"}
    Q -- "Aktiviert" --> DLG["Der Dialog erscheint erneut<br/>eine Blockierregel, wenn ein normaler Benutzer reagiert"]
    Q -- "Deaktiviert" --> SILENT["Auch kein Dialog<br/>still blockiert"]
    MISS -.->|"Abhilfe"| FIX["Den Pfad über Updates hinweg fest halten<br/>oder die alte Regel im Update löschen und neu registrieren"]

Die Abhilfe ist, den vollständigen Pfad der exe über Updates hinweg fest zu halten oder die Regel im Updateschritt auf den neuen Pfad zu ändern. Mit dem Verfahren aus Abschnitt 5.3 können Sie die Regel mit demselben -Name auf den neuen Pfad aktualisieren. Wählen Sie Löschen der alten Regel und erneute Registrierung, implementieren Sie auch den Wiederherstellungsweg bei Fehlschlag, sodass nie nur eine alte, breite Zulassungsregel übrig bleibt.

Für MSI gibt es Mechanismen, die Regeln deklarativ behandeln, etwa die Firewall-Erweiterung von WiX. Bevor Sie Befehle aus einer eigenen Custom Action starten, prüfen Sie, welche Bedingungen das verwendete Werkzeug unterstützt und wie es Update und Entfernen behandelt.¹³ Die Überlegungen zu den Verteilungsverfahren stehen in Wahl des Verteilungsverfahrens für Windows-Apps, die Erkennung durch Antivirus in Umgang mit Fehlalarmen von Microsoft Defender.

6. Fehlersuche — Ein Eingrenzungsablauf für „es kommuniziert nicht“

Kommt eine Meldung, sammeln Sie zuerst Quelle und Ziel, den verwendeten Namen oder die IP-Adresse, TCP/UDP und den Port, den Zeitpunkt des Fehlschlags und den Fehler der App. Das folgende Beispiel ist ein Auftragsserver, der TCP verwendet. Mischen Sie nicht die Punkte, die Sie auf dem Server prüfen, mit denen, die Sie vom tatsächlichen Client aus testen.

TcpTestSucceeded=True in der Abbildung bedeutet, dass die TCP-Verbindung zum geprüften Ziel gelungen ist. Es garantiert nicht, dass Authentifizierung, TLS und Datenaustausch der App gelungen sind, und auch nicht, dass ausgehender Verkehr der Fachanwendung, die eine andere exe ist, erlaubt ist.⁴

flowchart TB
    S["Vom Client aus keine Kommunikation"] --> N["Auf dem Server: netstat -ano"]
    N -- "Lauscht nicht" --> APP["Ein Problem vor der Firewall<br/>App- oder Dienstseite untersuchen"]
    N -- "Es ist LISTENING" --> T["Auf dem Client: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["Erreichbarkeit ist in Ordnung<br/>die App-Schicht untersuchen (Authentifizierung, Protokoll)"]
    T -- "False" --> P["Auf dem Server: Get-NetConnectionProfile<br/>das wirksame Profil prüfen"]
    P -- "Passt nicht zum Geltungsbereich der Regel" --> FIXP["Die Profileinstellung der Regel überprüfen"]
    P -- "Es passt" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>Zulassungsregeln und eingemischte Blockierregeln prüfen"]
    R --> LOGCHK["Verwerfungen (DROP) in pfirewall.log messen"]

1. Beim Lauschzustand sehen Sie Adresse und Prozess, nicht nur den Port. Auch bei LISTENING ist eine Bindung nur an 127.0.0.1 oder ::1 kein Lauschen, zu dem ein anderes Gerät einfach verbinden kann. Prüfen Sie, ob auf der betreffenden LAN-Adresse gelauscht wird und ob ein anderer Prozess denselben Port verwendet. Gleichen Sie die PID aus netstat -ano mit dem Task-Manager oder einem ähnlichen Werkzeug ab; mit den nötigen Rechten zeigt netstat -abno auch die exe. Prüfen Sie IPv4 und IPv6 getrennt.³

2. Den TCP-Verbindungstest führen Sie vom tatsächlichen Client aus. Im folgenden Beispiel prüfen Sie RemoteAddress, SourceAddress, InterfaceAlias und TcpTestSucceeded.⁴

# Auf dem Client ausführen. Name und Port an die Umgebung anpassen.
Test-NetConnection -ComputerName sv01 -Port 50051 -InformationLevel Detailed

Ein False macht die Windows-Firewall nicht zur feststehenden Ursache. Namensauflösung, Ziel, Weg, VPN, Netzwerkgeräte und Verkehrskontrollen eines anderen Produkts sind ebenfalls Kandidaten. Ist es umgekehrt True, bestätigen Sie zuerst, dass das Ziel der beabsichtigte Server ist, und sehen dann die Zieleinstellungen der Fachanwendung, ihre Authentifizierung und ihr Protokoll an. Ein Test mit einer IP-Adresse eignet sich zum Vergleich der TCP-Erreichbarkeit, verhält sich aber nicht unbedingt wie namensbasierte Authentifizierung oder Zertifikatsprüfung. Der Parameter -Port dieses Cmdlets ist ein TCP-Test und dient nicht der Entscheidung, ob UDP gelingt oder scheitert.⁴

3. Das Profil und 4. die Regeln prüft man an den Einstellungen, die tatsächlich gelten. Get-NetFirewallRule sieht standardmäßig den lokalen persistenten Speicher. Um die aktuelle Richtlinie einschließlich dessen zu sehen, was von GPO und Ähnlichem kommt, geben Sie -PolicyStore ActiveStore an. Prüfen Sie nicht nur, dass die Regel existiert, sondern auch die Einstellungen auf der Profilseite.⁵¹⁴

# Auf dem Server als Administrator ausführen.
Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
        AllowInboundRules, AllowLocalFirewallRules

$rules = @(Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Where-Object { $_.Enabled -eq "True" -and $_.Direction -eq "Inbound" })

$rules | Select-Object Name, DisplayName, Action, Profile,
    PolicyStoreSourceType, PolicyStoreSource

In einer Konfiguration, in der AllowInboundRules deaktiviert ist, reicht das Hinzufügen einer Zulassungsregel nicht, um eingehenden Verkehr zu erlauben. Ob lokale Regeln überhaupt gelten, beurteilt man zusammen mit der verwalteten Richtlinie in Kapitel 7. Bei nicht konfigurierten Werten wie NotConfigured schließen Sie aus dieser Zeichenfolge allein nicht auf erlaubt oder nicht erlaubt; bestätigen Sie die wirksamen Einstellungen mit dem Administrator.¹⁵

Programm, Port und Adresse liegen auf den der Regel zugeordneten Filterobjekten. Das folgende Beispiel zeigt jede der Bedingungen Ihrer eigenen Regel. Für $rules verwenden Sie, was der Befehl oben geholt hat.^5161718

$targetRules = @($rules | Where-Object { $_.Name -eq "MyCompany-OrderServer-In" })
$targetRules | Get-NetFirewallApplicationFilter | Select-Object Program
$targetRules | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort, RemotePort
$targetRules | Get-NetFirewallAddressFilter | Select-Object LocalAddress, RemoteAddress

# Auch Blockierregeln untersuchen, deren Namen von der eigenen Regel abweichen.
$rules | Where-Object { $_.Action -eq "Block" } |
    Select-Object Name, DisplayName, Profile, PolicyStoreSourceType, PolicyStoreSource

Auch bei Blockierregeln prüfen Sie die Filter der Kandidatenregeln ebenso. Ist ein Dienst angegeben, sehen Sie auch diese Bedingung an, mit Get-NetFirewallServiceFilter und Ähnlichem. Eine Suche nach genauer Übereinstimmung wie LocalPort -eq 50051 allein verfehlt Regeln, die Any oder einen Portbereich angeben. Schließen Sie nicht: „es ist in der Suche nicht erschienen, also gibt es keine kollidierende Regel“.¹⁷⁵

5. Beim Protokoll aktivieren Sie die Aufzeichnung und reproduzieren dann das Problem. Standardmäßig zeichnet das Firewall-Protokoll weder erlaubten noch verworfenen Verkehr auf. Der Standardort ist %windir%\system32\logfiles\firewall\pfirewall.log, die Standardhöchstgröße 4.096 KB. Beginnen Sie damit, die Einstellungen des betreffenden Profils und den tatsächlichen Ort zu prüfen.⁶

# Auf dem Server. Zuerst nur lesen und keine Einstellungen ändern.
Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, LogBlocked, LogAllowed, LogFileName, LogMaxSizeKilobytes

Ist die Verwerfungsaufzeichnung deaktiviert, holen Sie die Zustimmung des Administrators und aktivieren sie nur für das Zielprofil, etwa mit Set-NetFirewallProfile -Profile Private -LogBlocked True. Private ist hier ein Beispiel. Zeichnen Sie die Einstellungen auf, wie sie waren, und stellen Sie nach der Untersuchung die ursprünglichen Werte wieder her. Sind die Einstellungen zentral verwaltet, lässt die Verwaltungsseite sie ändern; es ist nicht nötig, zuerst erlaubten Verkehr in großen Mengen aufzuzeichnen oder jedes Profil zu ändern.⁹⁶

Gibt es ein DROP, das zu Reproduktionszeit, Quell-IP, Ziel-IP, Protokoll und Port passt, können Sie bestätigen, dass der Verkehr verworfen wurde. Das Fehlen einer solchen Zeile allein belegt jedoch nicht, dass „das Paket nie ankam“. Bestätigen Sie zuerst, dass die Protokolleinstellungen gelten, dass Sie nicht an einem anderen Ort suchen, dass die Datei aktualisiert wird und dass es kein Problem mit Schreibrechten gibt. Kombinieren Sie das bei Bedarf mit einer Paketerfassung oder Ähnlichem. Wird die Protokolldatei nie erzeugt, folgen Sie auch dem Verfahren von Microsoft zur Prüfung des Ordners und der Rechte von mpssvc.⁶

Zum weiteren Nachforschen sind die Überwachungsereignisse 5152 und 5157 der Windows Filtering Platform Kandidaten. Die Prüfung je Paket erzeugt sehr viele Ereignisse, daher verweist Microsoft für die Überwachung blockierter Verbindungen auf das ereignisweise 5157. Bestätigen Sie Überwachungsrichtlinie und Aufzeichnungsmenge mit dem Administrator und engen Sie Umfang und Zeitraum auf das Nötige ein.¹⁹

Machen Sie das Deaktivieren der Firewall nicht zum ersten Diagnoseschritt und nicht zur dauerhaften Abhilfe. Das Anhalten des Dienstes MpsSvc ist insbesondere von Microsoft nicht unterstützt. Auch wenn ein Administrator in einer isolierten Laborumgebung einen Vergleichstest fährt, lassen Sie den Dienst laufen, begrenzen die Änderung auf das betreffende Profil und machen das Wiederherstellen der ursprünglichen Einstellungen zur Pflicht. Die Produktion braucht eine zum Grund passende Korrektur der Einstellung, nicht flächendeckend entfernte Abwehr.²

7. Hinweise unter zentraler Verwaltung — Umgebungen, in denen lokale Regeln nicht wirken, und wie man einen Antrag stellt

In Umgebungen, in denen die Firewall über GPO oder Intune zentral verwaltet wird, lässt sich die Zusammenführung lokaler Regeln profilweise deaktivieren. Dann kann das Installationsprogramm eine Regel im lokalen persistenten Speicher anlegen, sie gilt aber nicht als Einstellung, die Verkehr erlaubt. Ein erfolgreicher Registrierungsschritt und das Erreichen der wirksamen Richtlinie sind zwei verschiedene Dinge.¹

„Lokal erzeugte Regeln“ in der Abbildung meint gewöhnliche lokale Regeln wie die in Abschnitt 5 im PersistentStore erzeugten. Sie werden anders behandelt als Regeln, die über die lokale Gruppenrichtlinie konfiguriert sind. Es geht nicht darum, in einen anderen Speicher zu schreiben, um die Einschränkung zu umgehen; es ist eine Unterscheidung, damit Sie und der Administrator des Kunden sich auf eine einzige Verteilungsquelle einigen.¹

flowchart TB
    GPOR["Von GPO oder Intune verteilte Regeln"] --> EFF["Die tatsächlich wirksame Regelmenge<br/>(ActiveStore)"]
    LOCAL["Lokal erzeugte Regeln<br/>(einschließlich Registrierung durch das Installationsprogramm)"] --> Q{"Zusammenführung lokaler Regeln<br/>(AllowLocalPolicyMerge)"}
    Q -- "Aktiviert (Standard)" --> EFF
    Q -- "Deaktiviert" --> DROP["Die Regel existiert, wird aber nicht angewendet<br/>-> auf zentrale Verteilung über GPO oder CSP umstellen"]

In einer solchen Umgebung erzeugen Sie lokale Regeln nicht immer wieder neu, sondern bitten die IT-Abteilung um die Verteilung der Regel. Das Installationsprogramm sollte unterscheiden, ob es die Regel selbst verwaltet oder die Verteilung durch die Verwaltungsseite voraussetzt, und so entworfen sein, dass es die Verwaltungsrichtlinie nicht von sich aus ändert.

Ein Antrag braucht mindestens die folgenden Angaben. Bitte TCP 50051 öffnen allein legt nicht fest, welches Gerät, wessen Verkehr oder wie weit die Zulassung reicht.

Beenden Sie die Einführungstests nicht mit Verbindungen vom Entwicklungsrechner oder vom Server selbst; führen Sie sie am tatsächlichen Nutzungsort und mit den tatsächlichen Rechten aus. Gibt es mehrere Wege, etwa einen über VPN, prüfen Sie jeden Weg. Scheitert die Authentifizierung, nachdem die TCP-Verbindung durch ist, gehen Sie zu einer von der Firewall getrennten Untersuchung über. Zu den verwandten Themen Authentifizierung und Verkehrsschutz siehe auch SMB-Signierung und LDAP Channel Binding.

8. Zusammenfassung

Der Umgang mit der Windows-Firewall endet nicht bei „bei der Warnung zulassen“ oder „einen Port öffnen“. Der Ausgangspunkt ist, die Verkehrsrichtungen der App zu erfassen, Programm, Port, Gegenstelle und Profil gemeinsam zu entwerfen und die benötigten Einstellungen vor dem ersten Start zu platzieren.¹¹⁰

Ist lokale Verwaltung zulässig, machen Sie Registrieren, Aktualisieren und Löschen der Regel zur Verantwortung des Installationsprogramms. Werden die Geräte über GPO oder Intune verwaltet, übergeben Sie dieselbe Kommunikationsspezifikation dem Administrator und lassen sie verteilen. Machen Sie zur Bedingung einer abgeschlossenen Einführung nicht, dass eine Regel erzeugt werden konnte, sondern dass die beabsichtigten Gegenstellen mit der tatsächlichen App kommunizieren können und kein unnötiger Bereich erlaubt ist.

Wenn der Verkehr scheitert, prüfen Sie der Reihe nach Lauschadresse und ausführende Instanz, TCP-Verbindung, Profil, wirksame Richtlinie und Verwerfungsprotokoll. Statt zu „es verbindet nicht, also ist es die Firewall“ oder „es gibt kein Protokoll, also kam nichts an“ zu springen, trennt das, was jedes Ergebnis gesagt hat, von dem, was Sie noch nicht wissen, und macht den nächsten Ort klar.

Verwandte Artikel

• Wie man die Interprozesskommunikation unter Windows wählt — Entscheidungstabelle für Named Pipes / TCP / gRPC / Shared Memory / COM
• Wahl des Verteilungsverfahrens 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 die selbst entwickelte Windows-App als Virus gilt — Umgang mit Fehlalarmen von Microsoft Defender und mit den Leistungsfolgen
• SMB-Signierung und LDAP Channel Binding — Die „andere Hälfte“ der NTLM-Abwehr in der Praxis schließen
• Windows-Dienste erstellen und betreiben — Von der Wahl zwischen Aufgabenplanung und Dienst bis zur Umsetzung eines BackgroundService

Verwandte Beratungsleistungen

Neben der Entwicklung von Windows-Fachanwendungen übernimmt die KomuraSoft LLC den Entwurf von Installationsprogrammen einschließlich Firewall-Regeln, die Ursachensuche bei Verbindungsfehlern beim Kunden und technische Beratung für Einführungen unter zentraler Verwaltung. Wenn Sie sich melden, lassen sich mit Quelle und Ziel, Kommunikationsverfahren, Reproduktionsschritten sowie Fehlern oder Protokollen der Untersuchungsumfang konkret machen.

• 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?

In einer Umgebung, in der ausgehender Verkehr standardmäßig erlaubt ist, braucht eine App, die nur selbst Verbindungen aufbaut und deren Antworten entgegennimmt, normalerweise keine eigene eingehende Regel. Das ändert sich, wenn eine Organisationsrichtlinie den Ausgang einschränkt oder eine ausdrückliche Blockierregel existiert. Auch eine App, die Client heißt, braucht für jeden Teil, der auf Rückrufe oder Benachrichtigungen von einem anderen Gerät wartet, erlaubten eingehenden Verkehr. Entscheiden Sie nach der tatsächlichen Richtung des Verkehrs, nicht nach dem Namen der App.

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

Es ist sicherer, das Produktions-Einführungsverfahren nicht von dieser einen Bedienung abhängig zu machen. Microsoft beschreibt, dass eine Blockierregel entsteht, wenn der Administrator, der die Benachrichtigung sieht, sie abbricht, oder wenn ein Benutzer ohne Administratorrechte darauf reagiert. Eine später hinzugefügte Zulassungsregel lässt den Verkehr nicht durch, solange eine kollidierende Blockierregel existiert. Platzieren Sie die benötigten Regeln vor dem ersten Start, entweder über das Installationsprogramm oder über den Administrator der Organisation.

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

Für eine eigene App, die auf einem festen Port lauscht, ist die Grundlage, den vollständigen Pfad des Programms mit Protokoll und lokalem Port zu kombinieren und Remote-IP sowie Profil auf den tatsächlich benötigten Bereich einzugrenzen. Anpassungen sind je nach Konfiguration nötig, etwa bei dynamischen Ports oder der Ausführung als Dienst. Bei einer programmbezogenen Regel muss der Updatevorgang Pfadänderungen der exe berücksichtigen; eine breite Zulassung nur über den Port sollte man nicht leichtfertig anlegen.

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

Ein erfolgreiches Registrieren der Regel allein sagt nicht, dass der Verkehr erlaubt ist. Prüfen Sie die Lauschadresse, den Pfad der exe, das Profil, die Remote-IP und etwaige kollidierende Blockierregeln. Ist darüber hinaus die Zusammenführung lokaler Regeln per GPO oder Intune deaktiviert, wird die vom Installationsprogramm erzeugte Regel nicht angewendet. Umgehen Sie in dem Fall die verwaltete Richtlinie nicht; lassen Sie die IT-Abteilung die Regel verteilen.

Darf man die Firewall zur Fehlereingrenzung vorübergehend deaktivieren?

Untersuchen Sie zuerst den Lauschzustand, die wirksame Richtlinie und das Verwerfungsprotokoll. Das vollständige Deaktivieren der Firewall machen Sie nicht zur Routine, und insbesondere vermeiden Sie das Anhalten des Dienstes MpsSvc, das Microsoft nicht unterstützt. Auch wenn ein Administrator sie in einer isolierten Testumgebung vorübergehend deaktivieren muss, lassen Sie den Dienst laufen, begrenzen die Änderung auf das betreffende Profil, zeichnen die vorherigen Einstellungen auf und stellen sie sofort wieder her.

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.