12
Windows 10 blockiert bzw. missachtet Portfreigabe von TCP 11001
Hi,
die Applikation PasswordSafe & Repository 7 nutzt zum Sync mit dem iPhone den Port 11001
Während der Software Installation wurden in der Windows 10 hauseigenen Defender Firewall zwei Eingehende Regeln, einmal für UPD und einmal für TCP, mit allen Portfreigaben angelegt.
Beim Sync meldet das iPhone aber, dass der PC Cient nicht erreichbar ist.
Mit "tcping 192.168.x.y 11001" habe ich via Console die Portfreigabe auf dem Rechner getestet. Mit der Meldung "No response" auf den Port fiel das Negativ aus. Dann habe ich mit "netstat -an" getestet, ob der Port hier angezeigt wird - aber auch negativ
Daraufhin habe ich explizit den Port 11001 in der Defender Firewall als Eingehende Regel eingetragen und Aktiviert. "tcping 192.168.x.y 11001" lieferte, auch nach einem Windwos Restart "No response" zurück.
Der letzte Test war dann, die Windows Defender Firewall für die Domäne, sprich für Privat und Öffentlich, abzuschalten und den Sync-Test zu wiederholen. Ergebnis: der Sync funktioniert
Frage: Warum blockiert Windows 10, ich nehme an die Firewall, trotz default-Regel durch das Programm selbst in der Firewall, inkl. meiner gezielt für den Port 11001 eingetragenen Regel, den Sync ? Warum blockiert Windows 10 diese Portfreigabe ?
Wäre cool, wenn Ihr eine Idee habt.
VG, Josh
die Applikation PasswordSafe & Repository 7 nutzt zum Sync mit dem iPhone den Port 11001
Während der Software Installation wurden in der Windows 10 hauseigenen Defender Firewall zwei Eingehende Regeln, einmal für UPD und einmal für TCP, mit allen Portfreigaben angelegt.
Beim Sync meldet das iPhone aber, dass der PC Cient nicht erreichbar ist.
Mit "tcping 192.168.x.y 11001" habe ich via Console die Portfreigabe auf dem Rechner getestet. Mit der Meldung "No response" auf den Port fiel das Negativ aus. Dann habe ich mit "netstat -an" getestet, ob der Port hier angezeigt wird - aber auch negativ
Daraufhin habe ich explizit den Port 11001 in der Defender Firewall als Eingehende Regel eingetragen und Aktiviert. "tcping 192.168.x.y 11001" lieferte, auch nach einem Windwos Restart "No response" zurück.
Der letzte Test war dann, die Windows Defender Firewall für die Domäne, sprich für Privat und Öffentlich, abzuschalten und den Sync-Test zu wiederholen. Ergebnis: der Sync funktioniert
Frage: Warum blockiert Windows 10, ich nehme an die Firewall, trotz default-Regel durch das Programm selbst in der Firewall, inkl. meiner gezielt für den Port 11001 eingetragenen Regel, den Sync ? Warum blockiert Windows 10 diese Portfreigabe ?
Wäre cool, wenn Ihr eine Idee habt.
VG, Josh
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 566680
Url: https://administrator.de/forum/windows-10-blockiert-bzw-missachtet-portfreigabe-von-tcp-11001-566680.html
Ausgedruckt am: 29.03.2025 um 12:03 Uhr
12 Kommentare
Neuester Kommentar
Hi,
der Listener ist unabhängig von den Firewall-Regeln. Wenn er Dir also beim netstat keinen Listener für diesen Port angezeigt hat, dann lief zu diesem Zeitpunkt kein Prozess, welcher diesen Port abhörte. Also klar, dass Deine Verbindung dann nicht laufen konnte. Ich schätze, Du hast Dich selbst getäuscht? Beim letzten Test lief der betreffende Prozess dann?
E.
der Listener ist unabhängig von den Firewall-Regeln. Wenn er Dir also beim netstat keinen Listener für diesen Port angezeigt hat, dann lief zu diesem Zeitpunkt kein Prozess, welcher diesen Port abhörte. Also klar, dass Deine Verbindung dann nicht laufen konnte. Ich schätze, Du hast Dich selbst getäuscht? Beim letzten Test lief der betreffende Prozess dann?
E.
Moin,
Was beides darauf hindeutet, dass der Port nicht offen ist. Allerdings nicht, weil die FW das blockiert, sondern weil dahinter kein Dienst lauscht. Wenn netstat -an nicht zurückgibt, dass auf dem Port gehorcht wird, dann horcht da auch nichts.
Weil da immer noch nichts horcht.
Du hast also vorsichtshalber alle drei Profile ausgeschaltet?
Das lässt nur zwei Schlüsse zu: Entweder wurde durch eine andere Aktion der Dienst gestartet und es ist Zufall, dass das Abschalten der FW gleichzeitig geschah. Oder der Vorgang wird über einen anderen Port angestoßen und der Dienst, der auf dem Port horcht, wird so erst gestartet. Und dieser Port wird blockiert.
hth
Erik
Zitat von @Joshk1:
Mit "tcping 192.168.x.y 11001" habe ich via Console die Portfreigabe auf dem Rechner getestet. Mit der Meldung "No response" auf den Port fiel das Negativ aus. Dann habe ich mit "netstat -an" getestet, ob der Port hier angezeigt wird - aber auch negativ
Mit "tcping 192.168.x.y 11001" habe ich via Console die Portfreigabe auf dem Rechner getestet. Mit der Meldung "No response" auf den Port fiel das Negativ aus. Dann habe ich mit "netstat -an" getestet, ob der Port hier angezeigt wird - aber auch negativ
Was beides darauf hindeutet, dass der Port nicht offen ist. Allerdings nicht, weil die FW das blockiert, sondern weil dahinter kein Dienst lauscht. Wenn netstat -an nicht zurückgibt, dass auf dem Port gehorcht wird, dann horcht da auch nichts.
Daraufhin habe ich explizit den Port 11001 in der Defender Firewall als Eingehende Regel eingetragen und Aktiviert. "tcping 192.168.x.y 11001" lieferte, auch nach einem Windwos Restart "No response" zurück.
Weil da immer noch nichts horcht.
Der letzte Test war dann, die Windows Defender Firewall für die Domäne, sprich für Privat und Öffentlich, abzuschalten und den Sync-Test zu wiederholen.
Du hast also vorsichtshalber alle drei Profile ausgeschaltet?
Ergebnis: der Sync funktioniert
Das lässt nur zwei Schlüsse zu: Entweder wurde durch eine andere Aktion der Dienst gestartet und es ist Zufall, dass das Abschalten der FW gleichzeitig geschah. Oder der Vorgang wird über einen anderen Port angestoßen und der Dienst, der auf dem Port horcht, wird so erst gestartet. Und dieser Port wird blockiert.
hth
Erik
Hi,
Danke für deine Rückmeldung. Hilft zum Nachdenken. Mir kam selbst der Gedanke, Du hast mich hierbei bestätigt, dass netstat "nur" etwas anzeigt, was A) Dauerhaft geöffnet ist oder B) gerade in Benutzung ist.
Was nur zufällig Geöffnet wird, wenn ein Programm es benötigt, ist sonst in netstat nicht zu sehen. Ein Denkfehler von mir. Zumindest verstehe ich "netstat -an" so, richtig?
Frage: wie kann man herausfinden, welcher Listener für diesen Port verantwortich ist? Und, welcher Dienst gestartet sein muss, damit dieser Port auf, zB. eine Sync-Anfrage, reagiert?
@eriko hat mich nämlich auf eine Idee gebracht, Danke dafür.
Ich kann nicht sagen, ob beim erfolgreichen Sync der Port via "netstat -an" zu sehen gewesen wäre (ich nehme es aber an), dafür war der Sync zw. iPhone und Windows 10 Laptop zu schnell erledigt, und ich hatte es erst gar nicht versucht mir anzeigen zu lassen.
Aber, und hier greife ich nochmal die Anmerkung von @eriko auf, ich habe den Sync ein weiteres Mal gestartet, und dieser ist wieder mit der gleichen Fehlermeldung abgebrochen. PC-Client nicht gefunden, überprüfen Sie die IP, ist der Port offen usw.
Sprich, beim ersten erfolgreichen Sync war es Zufall, weil..., weil irgendetwas gerade in dem Sync-Moment, den Listener oder einen Dienst welcher auf den Port 11001 horcht, gestartet hat, oder dieser lief gerade zufälligerweise.
Liege ich mit dem Gedanken auch daneben, dass ich mit "tcping 192.168.x.y 11001" den Port-Status abfragen kann, geöffnet, vorhanden, oder sonst etwas? Wenn dem nicht so ist. Hmm? Mit welchem Command-Befehl kann man denn aktive oder bereite, kommunikationsfähige Ports abfragen?
Joshk1
Danke für deine Rückmeldung. Hilft zum Nachdenken. Mir kam selbst der Gedanke, Du hast mich hierbei bestätigt, dass netstat "nur" etwas anzeigt, was A) Dauerhaft geöffnet ist oder B) gerade in Benutzung ist.
Was nur zufällig Geöffnet wird, wenn ein Programm es benötigt, ist sonst in netstat nicht zu sehen. Ein Denkfehler von mir. Zumindest verstehe ich "netstat -an" so, richtig?
Frage: wie kann man herausfinden, welcher Listener für diesen Port verantwortich ist? Und, welcher Dienst gestartet sein muss, damit dieser Port auf, zB. eine Sync-Anfrage, reagiert?
@eriko hat mich nämlich auf eine Idee gebracht, Danke dafür.
Ich kann nicht sagen, ob beim erfolgreichen Sync der Port via "netstat -an" zu sehen gewesen wäre (ich nehme es aber an), dafür war der Sync zw. iPhone und Windows 10 Laptop zu schnell erledigt, und ich hatte es erst gar nicht versucht mir anzeigen zu lassen.
Aber, und hier greife ich nochmal die Anmerkung von @eriko auf, ich habe den Sync ein weiteres Mal gestartet, und dieser ist wieder mit der gleichen Fehlermeldung abgebrochen. PC-Client nicht gefunden, überprüfen Sie die IP, ist der Port offen usw.
Sprich, beim ersten erfolgreichen Sync war es Zufall, weil..., weil irgendetwas gerade in dem Sync-Moment, den Listener oder einen Dienst welcher auf den Port 11001 horcht, gestartet hat, oder dieser lief gerade zufälligerweise.
Liege ich mit dem Gedanken auch daneben, dass ich mit "tcping 192.168.x.y 11001" den Port-Status abfragen kann, geöffnet, vorhanden, oder sonst etwas? Wenn dem nicht so ist. Hmm? Mit welchem Command-Befehl kann man denn aktive oder bereite, kommunikationsfähige Ports abfragen?
Joshk1
Hi,
neben der Port-Freischaltung in der Firewall, muss ich zusätzlichen noch einen Dienst "Aktiv" starten, der den Port 11001 abhört?
Wenn ja, wie bekomme ich heraus, welcher Dienst das ist?
Gibt es ein Tool, ein Commandline-/ oder auch ein GUI-Tool, mit dem man sich die Ports, und die dazugehörenden Dienste anzeigen lassen kann, was quasi zusammen korrespondiert?
PS: ich habe noch einmal explizit in der Software "PasswordSafe & Repository 7" nachgesehen - zum Sync mit der dazugehöhrenden Mobil-App (gleicher Hersteller) muss der Port "TCP 11001" in der Firewall des jeweilgen PC-Client freigeschaltet sein. Es muss der Port 11001 sein. Wie im ersten Post von mir beschrieben, habe ich die Regel eingetragen - und dann sogar das System gebootet.
@eriko: ich bin in meinem anderen Antwort Thread auf einige Pkte deiner Antwort eingegangen, bzw. habe Bezug darauf genommen.
Joshk1
neben der Port-Freischaltung in der Firewall, muss ich zusätzlichen noch einen Dienst "Aktiv" starten, der den Port 11001 abhört?
Wenn ja, wie bekomme ich heraus, welcher Dienst das ist?
Gibt es ein Tool, ein Commandline-/ oder auch ein GUI-Tool, mit dem man sich die Ports, und die dazugehörenden Dienste anzeigen lassen kann, was quasi zusammen korrespondiert?
PS: ich habe noch einmal explizit in der Software "PasswordSafe & Repository 7" nachgesehen - zum Sync mit der dazugehöhrenden Mobil-App (gleicher Hersteller) muss der Port "TCP 11001" in der Firewall des jeweilgen PC-Client freigeschaltet sein. Es muss der Port 11001 sein. Wie im ersten Post von mir beschrieben, habe ich die Regel eingetragen - und dann sogar das System gebootet.
@eriko: ich bin in meinem anderen Antwort Thread auf einige Pkte deiner Antwort eingegangen, bzw. habe Bezug darauf genommen.
Joshk1
Moin,
es muss nicht unbedingt der Port 11001 sein, sondern den Port kann man frei konfigurieren, siehe http://help.passwordsafe.de/ios/8.0/de/topic/wlan-synchronisation
Du stellst ja die IP und den Port auf PC-Seite ein und trägst die Konfiguration dann in der iPhone-App ein.
Es könnte auch noch ein Problem sein, dass das iPhone über WLAN und der PC über Kabel mit dem Netzwerk verbunden ist, da könnte eventuell der Router dazwischenfunken und die Kommunikation WLAN - LAN unterbinden.
Du könntest auch mal Deine genaue Firewallregel hier posten, eventuell versteckt sich da noch ein Fehler.
Ansonsten wäre es eventuell noch hilfreich, wenn der PC eine statische IP-Adresse im LAN hat und nicht per DHCP ggf. eine neue IP bekommt.
Das iPhone muss dann natürlich via WLAN im selben IP-Adressbereich sein. Beispiel: PC hat die IP 192.168.2.10, dann muss das iPhone ebenfalls eine IP im Bereich 192.168.2.* haben (also bspw. nicht mit dem Gastnetz o.ä. verbunden sein).
Gruß
cykes
es muss nicht unbedingt der Port 11001 sein, sondern den Port kann man frei konfigurieren, siehe http://help.passwordsafe.de/ios/8.0/de/topic/wlan-synchronisation
Du stellst ja die IP und den Port auf PC-Seite ein und trägst die Konfiguration dann in der iPhone-App ein.
Es könnte auch noch ein Problem sein, dass das iPhone über WLAN und der PC über Kabel mit dem Netzwerk verbunden ist, da könnte eventuell der Router dazwischenfunken und die Kommunikation WLAN - LAN unterbinden.
Du könntest auch mal Deine genaue Firewallregel hier posten, eventuell versteckt sich da noch ein Fehler.
Ansonsten wäre es eventuell noch hilfreich, wenn der PC eine statische IP-Adresse im LAN hat und nicht per DHCP ggf. eine neue IP bekommt.
Das iPhone muss dann natürlich via WLAN im selben IP-Adressbereich sein. Beispiel: PC hat die IP 192.168.2.10, dann muss das iPhone ebenfalls eine IP im Bereich 192.168.2.* haben (also bspw. nicht mit dem Gastnetz o.ä. verbunden sein).
Gruß
cykes
Moin,
Gerne.
Das freut mich.
So ist es. Wenn netstat -an beim betroffenen Port nicht in der Statusspalte "LISTEN" (oder je nach Version und Spracheinstellung was entsprechendes in einer anderen Sprache) ausgibt, dann horcht da auch nichts. Dann braucht man auch keine Firewall.
Auf welchem Port die Anfragen eingehen, könntest Du z. B. mit Wireshark oder tcpdump rausfinden. Welcher Dienst gestartet sein muss, ist schon schwieriger. Schau mal in den Diensten nach, ob Du da was Entsprechendes findest. Da wäre mal interessant, wie der gestartet wird (Automatisch, Automatisch verzögert oder manuell).
Einfach mal auf der Powershell vor dem Syncversuch
eingeben. Je nach Spracheinstellung musst Du den Suchstring anpassen.
Aber, und hier greife ich nochmal die Anmerkung von @eriko auf, ich habe den Sync ein weiteres Mal gestartet, und dieser ist wieder mit der gleichen Fehlermeldung abgebrochen. PC-Client nicht gefunden, überprüfen Sie die IP, ist der Port offen usw.
Sprich, beim ersten erfolgreichen Sync war es Zufall, weil..., weil irgendetwas gerade in dem Sync-Moment, den Listener oder einen Dienst welcher auf den Port 11001 horcht, gestartet hat, oder dieser lief gerade zufälligerweise.
Das ahnte ich doch. Und ich ahne noch was. So ein Problem haben wir mit einem Server. Der Dienst steht auf "Automatisch". Wenn der Server hochfährt, geht der Start des Dienstes manchmal schief und manchmal nicht. Warum? Er hängt von einem anderen Dienst ab und es kommt zu einer race condition. Sprich: Startet der grundlegende Dienst schnell genug, dann wird auch der Server korrekt gestartet. Startet er nicht schnell genug, dann läuft das Starten des Dienstes gegen die Wand. Lösung: Dienst auf "Automatisch (verzögerter Start)" umstellen und alles ist gut. Nach dem Update immer schön dran denken.
hth
Erik
Gerne.
Hilft zum Nachdenken.
Das freut mich.
Mir kam selbst der Gedanke, Du hast mich hierbei bestätigt, dass netstat "nur" etwas anzeigt, was A) Dauerhaft geöffnet ist oder B) gerade in Benutzung ist.
So ist es. Wenn netstat -an beim betroffenen Port nicht in der Statusspalte "LISTEN" (oder je nach Version und Spracheinstellung was entsprechendes in einer anderen Sprache) ausgibt, dann horcht da auch nichts. Dann braucht man auch keine Firewall.
Frage: wie kann man herausfinden, welcher Listener für diesen Port verantwortich ist? Und, welcher Dienst gestartet sein muss, damit dieser Port auf, zB. eine Sync-Anfrage, reagiert?
Auf welchem Port die Anfragen eingehen, könntest Du z. B. mit Wireshark oder tcpdump rausfinden. Welcher Dienst gestartet sein muss, ist schon schwieriger. Schau mal in den Diensten nach, ob Du da was Entsprechendes findest. Da wäre mal interessant, wie der gestartet wird (Automatisch, Automatisch verzögert oder manuell).
Ich kann nicht sagen, ob beim erfolgreichen Sync der Port via "netstat -an" zu sehen gewesen wäre (ich nehme es aber an), dafür war der Sync zw. iPhone und Windows 10 Laptop zu schnell erledigt, und ich hatte es erst gar nicht versucht mir anzeigen zu lassen.
Einfach mal auf der Powershell vor dem Syncversuch
while($true){netstat -an | select-string "LISTEN" >>netstat.txt;start-sleep 1} eingeben. Je nach Spracheinstellung musst Du den Suchstring anpassen.
Aber, und hier greife ich nochmal die Anmerkung von @eriko auf, ich habe den Sync ein weiteres Mal gestartet, und dieser ist wieder mit der gleichen Fehlermeldung abgebrochen. PC-Client nicht gefunden, überprüfen Sie die IP, ist der Port offen usw.
Sprich, beim ersten erfolgreichen Sync war es Zufall, weil..., weil irgendetwas gerade in dem Sync-Moment, den Listener oder einen Dienst welcher auf den Port 11001 horcht, gestartet hat, oder dieser lief gerade zufälligerweise.
Das ahnte ich doch. Und ich ahne noch was. So ein Problem haben wir mit einem Server. Der Dienst steht auf "Automatisch". Wenn der Server hochfährt, geht der Start des Dienstes manchmal schief und manchmal nicht. Warum? Er hängt von einem anderen Dienst ab und es kommt zu einer race condition. Sprich: Startet der grundlegende Dienst schnell genug, dann wird auch der Server korrekt gestartet. Startet er nicht schnell genug, dann läuft das Starten des Dienstes gegen die Wand. Lösung: Dienst auf "Automatisch (verzögerter Start)" umstellen und alles ist gut. Nach dem Update immer schön dran denken.
hth
Erik
Hallo,
Dein „sprich“ kann ich nicht nachvollziehen.
„Domäne“ ist keine Zusammenfassung von „privat und öffentlich“.
Das ist eine dritte Gruppe (für PCs, die in einer Domäne an einem Domaincontroller konfiguriert sind).
Gruß,
Jörg
Der letzte Test war dann, die Windows Defender Firewall für die Domäne, sprich für Privat und Öffentlich, abzuschalten und den Sync-Test zu wiederholen. Ergebnis: der Sync funktioniert
Dein „sprich“ kann ich nicht nachvollziehen.
„Domäne“ ist keine Zusammenfassung von „privat und öffentlich“.
Das ist eine dritte Gruppe (für PCs, die in einer Domäne an einem Domaincontroller konfiguriert sind).
Gruß,
Jörg
Zitat von @Joshk1:
Frage: wie kann man herausfinden, welcher Listener für diesen Port verantwortich ist?
z.B. mit PSEXEC als SYSTEM "netstat -b" ausführen.Frage: wie kann man herausfinden, welcher Listener für diesen Port verantwortich ist?
psexec -s netstat -anb
Moin,
du kannst das ganze am "Server", wo der Dienst/Programm läuft, auch visualisieren in dem du den Taskmanager öffnest und unter Leistung unten auf " Ressourcen Monitor" klinkst.
Im Bereich Netzwerk werden dann alle Programme aufgeführt welche derzeit eine Verbindung aufgebaut haben und eben auch jene, welche auf einem Port lauschen. Ist dein Tool dort nicht aufgeführt, wird dir netstat immer sagen, das dort nichts vorhanden ist. Des weiteren würdest du dort auch alle von deinem Tool genutzten Ports sehen.
Gruß
Spirit
du kannst das ganze am "Server", wo der Dienst/Programm läuft, auch visualisieren in dem du den Taskmanager öffnest und unter Leistung unten auf " Ressourcen Monitor" klinkst.
Im Bereich Netzwerk werden dann alle Programme aufgeführt welche derzeit eine Verbindung aufgebaut haben und eben auch jene, welche auf einem Port lauschen. Ist dein Tool dort nicht aufgeführt, wird dir netstat immer sagen, das dort nichts vorhanden ist. Des weiteren würdest du dort auch alle von deinem Tool genutzten Ports sehen.
Gruß
Spirit
Moin
Wenn wir vom Mateso-Produkt reden:
A) der Sync-Assistent für die mobilen Geräte läuft nicht im Hintergrund. Den muss man für jeden Sync manuell starten, sonst antwortet da gar nichts auf 11001.
B) ich habe bei meiner Konfig die Applikation in der Win-Firewall freigegeben, funktioniert wunderbar. Ist nicht so filigran wie separate Ports, aber da der Dienst eh nur ein paar Sekunden läuft, kann man das mMn schon so machen.
Gruß
Bernhard
Wenn wir vom Mateso-Produkt reden:
A) der Sync-Assistent für die mobilen Geräte läuft nicht im Hintergrund. Den muss man für jeden Sync manuell starten, sonst antwortet da gar nichts auf 11001.
B) ich habe bei meiner Konfig die Applikation in der Win-Firewall freigegeben, funktioniert wunderbar. Ist nicht so filigran wie separate Ports, aber da der Dienst eh nur ein paar Sekunden läuft, kann man das mMn schon so machen.
Gruß
Bernhard
Moin,
mit Powershell geht das Port prüfen wessentlich effektiver.
sid-500.com/2018/02/02/powershell-test-open-tcp-ports-with-test-openport-multiple-hosts-multiple-port-numbers/
Auch Ping kann mit Powershell effektiver ersetzt werden.
sid-500.com/2017/06/30/the-modern-version-of-ping-test-connection/
mit Powershell geht das Port prüfen wessentlich effektiver.
sid-500.com/2018/02/02/powershell-test-open-tcp-ports-with-test-openport-multiple-hosts-multiple-port-numbers/
Auch Ping kann mit Powershell effektiver ersetzt werden.
sid-500.com/2017/06/30/the-modern-version-of-ping-test-connection/
Zitat von @Tektronix:
mit Powershell geht das Port prüfen wessentlich effektiver.
sid-500.com/2018/02/02/powershell-test-open-tcp-ports-with-test-openport-multiple-hosts-multiple-port-numbers/
mit Powershell geht das Port prüfen wessentlich effektiver.
sid-500.com/2018/02/02/powershell-test-open-tcp-ports-with-test-openport-multiple-hosts-multiple-port-numbers/
Das Skript ist absolut geil.
Leider kann man nicht überall einfach so Skripte ausführen.
