16
TCP Verbindungsblock finden
Moin,
ich habe etwas kniffliges.
RZ
Server1, IP 200.1.2.3, TCP 40.000 - 40.100
Server2, IP 200.1.2.4, TCP 40.000 - 40.100
(IP und Ports geändert)
von einem Standort eines Kunden kann man von einem Tag auf den Anderen auf 200.1.2.3:40050 nicht mehr zugreifen.
Alle anderen Ports gehen. Auf Server2 gehen alle Ports.
Vorher funktioniert dies ca. 4 Jahre ohne Störungen.
PCs sind Windows 10, ohne AD, nur hinter einer FB, vDSL 100MBit Telekom, keine Sicherheitssoftware.
Auch mein Notebook dort vor hat das gleiche Problem.
-> Es liegt also nicht an den PCs.
Die FB wurde neu gestartet, resetet und ausgetauscht.
Außerhalb funktioniert die Verbindung einwandfrei.
Der Server hat keine Firewall sondern nur einen IP-Filter.
Da kann gar keinen Port blocken werden.
Die Software hat keinen IP-Filter und sagt "da kommt nichts an".
Der RZ-Betreiber versichert, dass da nichts geblockt wird.
Im RZ kann/darf ich keinen Sniffer nutzen. Der RZ-Betreiber will sich nicht beteiligen.
Also bleiben nur:
- Telekom letzte Meile
- Telekom Backbone
- RZ
Wie bekomme ich raus wo das Datenpaket wegkommt?
Stefan
ich habe etwas kniffliges.
RZ
Server1, IP 200.1.2.3, TCP 40.000 - 40.100
Server2, IP 200.1.2.4, TCP 40.000 - 40.100
(IP und Ports geändert)
von einem Standort eines Kunden kann man von einem Tag auf den Anderen auf 200.1.2.3:40050 nicht mehr zugreifen.
Alle anderen Ports gehen. Auf Server2 gehen alle Ports.
Vorher funktioniert dies ca. 4 Jahre ohne Störungen.
PCs sind Windows 10, ohne AD, nur hinter einer FB, vDSL 100MBit Telekom, keine Sicherheitssoftware.
Auch mein Notebook dort vor hat das gleiche Problem.
-> Es liegt also nicht an den PCs.
Die FB wurde neu gestartet, resetet und ausgetauscht.
Außerhalb funktioniert die Verbindung einwandfrei.
Der Server hat keine Firewall sondern nur einen IP-Filter.
Da kann gar keinen Port blocken werden.
Die Software hat keinen IP-Filter und sagt "da kommt nichts an".
Der RZ-Betreiber versichert, dass da nichts geblockt wird.
Im RZ kann/darf ich keinen Sniffer nutzen. Der RZ-Betreiber will sich nicht beteiligen.
Also bleiben nur:
- Telekom letzte Meile
- Telekom Backbone
- RZ
Wie bekomme ich raus wo das Datenpaket wegkommt?
Stefan
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: 94114308285
Url: https://administrator.de/forum/tcp-verbindungsblock-finden-94114308285.html
Ausgedruckt am: 29.03.2025 um 10:03 Uhr
16 Kommentare
Neuester Kommentar
Hängt beim Kunden zwischen den Clients und der Fritzbox noch eine Firewall? Vermutlich nicht sonst hättest du das wohl geschrieben.
Im RZ in dem die Zielserver stehen wird der Fehler eher nicht liegen, weil es ja von überall geht nur intern vom Kunden aus nicht.
Ich würde den Fehler jetzt auch beim Provider vermuten. Es wird aber wohl schwierig werden dem das zu vermitteln. Bei einer Fritzbox als Gateway vermute ich nämlich einfach mal einen ziemlich einfachen Vertrag mit dem entsprechenden technischen Hintergrund an der Hotline.
Das einzige was du noch testen kannst ist an der Fitzbox bspw. ein LTE-USB-Modem anzuklemmen oder einen LTE-Router per LAN. Wenn es dann funktioniert kannst du dir sicher sein, dass es der Weg vom Kunden über den Provider zum Server-RZ ist.
Manuel
Im RZ in dem die Zielserver stehen wird der Fehler eher nicht liegen, weil es ja von überall geht nur intern vom Kunden aus nicht.
Ich würde den Fehler jetzt auch beim Provider vermuten. Es wird aber wohl schwierig werden dem das zu vermitteln. Bei einer Fritzbox als Gateway vermute ich nämlich einfach mal einen ziemlich einfachen Vertrag mit dem entsprechenden technischen Hintergrund an der Hotline.
Das einzige was du noch testen kannst ist an der Fitzbox bspw. ein LTE-USB-Modem anzuklemmen oder einen LTE-Router per LAN. Wenn es dann funktioniert kannst du dir sicher sein, dass es der Weg vom Kunden über den Provider zum Server-RZ ist.
Manuel
Es funktioniert auf der einen IP ja nur der eine Port nicht. Dann muss das Routing ja eigentlich passen.
Alles ohne Befund. Tracert ist ja nur die IP und andere Ports an der gleichen IP gehen.
Nur dieser Port hat ein Timeout.
Stefan
Nur dieser Port hat ein Timeout.
Stefan
Zitat von @manuel-r:
Es funktioniert auf der einen IP ja nur der eine Port nicht. Dann muss das Routing ja eigentlich passen.
Hm, habe ich überlesen. - Mein fehler.Es funktioniert auf der einen IP ja nur der eine Port nicht. Dann muss das Routing ja eigentlich passen.
Betrifft das den Port 40050? Oder ist dieser sinngemäß gemeint?
Ich frage deshalb, weil laut IANA Portnumbers sind einige Ports zwischen 40000-40404 reserviert.
Gruss Penny.
Zitat von @manuel-r:
Hängt beim Kunden zwischen den Clients und der Fritzbox noch eine Firewall? Vermutlich nicht sonst hättest du das wohl geschrieben.
NeinHängt beim Kunden zwischen den Clients und der Fritzbox noch eine Firewall? Vermutlich nicht sonst hättest du das wohl geschrieben.
Zitat von @Penny.Cilin:
Betrifft das den Port 40050? Oder ist dieser sinngemäß gemeint?
Ich frage deshalb, weil laut IANA Portnumbers sind einige Ports zwischen 40000-40404 reserviert.
ich glaube es ist 41189. Es funktionierte seit mehrere Jahren störungsfrei. Aus den anderen Filialen funktioniert es weiterhin. Ich habe so etwas noch nie in den letzten 30 Jahren gehabt. Sehr strange.Betrifft das den Port 40050? Oder ist dieser sinngemäß gemeint?
Ich frage deshalb, weil laut IANA Portnumbers sind einige Ports zwischen 40000-40404 reserviert.
Stefan
Moin,
ist ein Linux vorhanden? Dann wäre
eine Möglichkeit, den pösen Purschen zu identifizieren.
hth
Erik
ist ein Linux vorhanden? Dann wäre
traceroute -T -p 40050 200.1.2.3eine Möglichkeit, den pösen Purschen zu identifizieren.
hth
Erik
Mach ein traceroute (unter linux) auf den Port.
traceroute 200.1.2.3 -p 40050 und vergleiche das mit einen traceroute zu den anderen Ports
Dann siehst Du obdas Paket es genauso weit schafft, wie die anderen.
lks
Meine 2ct:
Wenn alles andere geht und nur ein Port von einem Standort aus nicht, dann muss dort eine Firewall werkeln.
Traceroute wird allerdings oft geblockt, daher etwas vorsichtig.
Sicher das die fritzbox nicht doch irgendwas macht?
Die hat auch eine firewall oder vielleicht auch einen Bug in der Firmware?
Überall gleiche Firmware und FBs?
Ist aber interessant ...
Wenn alles andere geht und nur ein Port von einem Standort aus nicht, dann muss dort eine Firewall werkeln.
Traceroute wird allerdings oft geblockt, daher etwas vorsichtig.
Sicher das die fritzbox nicht doch irgendwas macht?
Die hat auch eine firewall oder vielleicht auch einen Bug in der Firmware?
Überall gleiche Firmware und FBs?
Ist aber interessant ...
1Zitat von @Deepsys:
Meine 2ct:
Wenn alles andere geht und nur ein Port von einem Standort aus nicht, dann muss dort eine Firewall werkeln.
Traceroute wird allerdings oft geblockt, daher etwas vorsichtig.
Meine 2ct:
Wenn alles andere geht und nur ein Port von einem Standort aus nicht, dann muss dort eine Firewall werkeln.
Traceroute wird allerdings oft geblockt, daher etwas vorsichtig.
traceroute mit den richtigen Paremetern sollte schon funktionieren. Insbesondere wenn man es auf bestimmte Ports "abrichtet".
lks
Ich probiere dass aus und melde mich, kann aber ein paar Tage dauern bis ich ein potables Linux (USB Stick) dort habe.
Moin @StefanKittel,
dafür brauchst du kein portables Linux und überhaupt keinen Pinguin.
Das geht auch 1A mit Windows, aber leider nicht mit dem onboard "tracert". 😭
Mit Nmap klappt das aber auch unter Windows. 😁
https://nmap.org/download.html
Einmal gegen einen Port der funktioniert, z.B. ...
... und danach gegen den der nicht funktioniert, ...
... dann die Ergebnisse gegeneinander vergleich und schon solltest du sehen wo es klemmt. 😉
Gruss Alex
Ich probiere dass aus und melde mich, kann aber ein paar Tage dauern bis ich ein potables Linux (USB Stick) dort habe.
dafür brauchst du kein portables Linux und überhaupt keinen Pinguin.
Das geht auch 1A mit Windows, aber leider nicht mit dem onboard "tracert". 😭
Mit Nmap klappt das aber auch unter Windows. 😁
https://nmap.org/download.html
Einmal gegen einen Port der funktioniert, z.B. ...
nmap -Pn --traceroute -p 40000 200.1.2.3... und danach gegen den der nicht funktioniert, ...
nmap -Pn --traceroute -p 40050 200.1.2.3... dann die Ergebnisse gegeneinander vergleich und schon solltest du sehen wo es klemmt. 😉
Gruss Alex
Was ist das für ne Server-Anwendung? Im einfachsten Fall ist das irgendein Web-Interface o. ähnliches, dann würde ich mal erstmal mit Telnet schauen ob ich da irgendwas sehe. Telnet auf den Port und schauen ob da irgendwas erstmal antwortet...
Zitat von @MysticFoxDE:
Moin @StefanKittel,
dafür brauchst du kein portables Linux und überhaupt keinen Pinguin.
Moin @StefanKittel,
Ich probiere dass aus und melde mich, kann aber ein paar Tage dauern bis ich ein potables Linux (USB Stick) dort habe.
dafür brauchst du kein portables Linux und überhaupt keinen Pinguin.
Den onboard-Pinguin von Windows (WSL) kann man auch nutzen.
Das geht auch 1A mit Windows, aber leider nicht mit dem onboard "tracert". 😭
Kommt drauf an, ob man WSL als "onboard" definiert oder nicht.
Dann kann nan sich auch gleich wsl, cygwin oder "nur" ein richtiges traceroute installieren.
lks
Zitat von @maretz:
Was ist das für ne Server-Anwendung? Im einfachsten Fall ist das irgendein Web-Interface o. ähnliches, dann würde ich mal erstmal mit Telnet schauen ob ich da irgendwas sehe. Telnet auf den Port und schauen ob da irgendwas erstmal antwortet...
Was ist das für ne Server-Anwendung? Im einfachsten Fall ist das irgendein Web-Interface o. ähnliches, dann würde ich mal erstmal mit Telnet schauen ob ich da irgendwas sehe. Telnet auf den Port und schauen ob da irgendwas erstmal antwortet...
Telnet bekam auf dem Port keine Verbindung.
Laut Sniffer kam ja schlicht nichts zurück. Kein abgelehnt oder so. Nur NULL.
