Unitymedia Sperrt Unitymedia Ports ?

[mril]

Erst einmal guten Tag.

Ich besitze eine 6360 FritzBox und kann keinen einzigen Port freigeben. Ich habe es sogar mit dem "Exposed Host" probiert, ohne Erfolg.

Beispielszenario:
Antivirus ausgeschaltet.
Meine Fritzbox bezieht eine ipv4 Adresse.
Ich öffne den 7000 UDP Port in der Fritzbox an meinen PC
Ich füge eine neue Eingehende und Ausgehen Regel (UDP 7000 Zulassen) in den Windows Firewall Einstellungen hinzu.
Ohne Erfolg

Beispielszenario 2:
Antivirus ausgeschaltet.
Meine Fritzbox bezieht eine ipv4 Adresse.
"Exposed Host" an meinen Computer aktiviert.
Firewall komplett ausgeschaltet.
Ohne Erfolg

Hat jemand eine Ahnung was hier abgeht?. Ich kann mich noch daran erinnern, dass ich mal vor 2 jahren Unity/KabelBW angerufen hab warum ich meine Ports nicht öffnen kann (da ging es um den 6112 Port). War auf jeden Fall ein langes Gespräch, Unity meinte sie sperren keine Ports. Komischerweise konnte ich an diesem Tag (nach dem Gespräch) den 6112 benutzen, er wurde auch als "Opened" angezeigt, ein Tag später ging wieder nichts. Also ich weiß auch nicht mehr weiter.

Für den Port Check benutze ich diese Seite hier
http://www.yougetsignal.com/tools/open-ports/

 

[tq1199]

Für den Port Check benutze ich diese Seite hier
http://www.yougetsignal.com/tools/open-ports/

Schau mal mit dieser Seite, ob der TCP-Port 8089 deiner FB6360 offen ist.

BTW: Ich habe auch eine FB6360 mit einer externen IPv4-Adresse (von UM) und da wird kein einziger Port von UM gesperrt.

 

[mril]

Ja, ist er -.-

 

[tq1199]

Ja, ist er -.-

OK, dann hast Du eine externe IPv4-Adresse von UM. Evtl. liegt es an der Konfiguration deines Computers, weil das mit den freigegebenen Ports nicht funktioniert.

 

[conscience]

Was ist eine "externe IPv4-Adresse von UM" ??

 

[MartinDJR]

Meine Fritzbox bezieht eine ipv4 Adresse.

Bist du dir wirklich sicher, dass du eine global eindeutige IPv4-Adresse bekommst und kein DS-Lite hast?

Ohne Erfolg

Wie genau äußert sich das?

Oder genauer: Von welchem Computer aus versuchst du, auf den Rechner zuhause zuzugreifen?

 

[tq1199]

Bist du dir wirklich sicher, dass du eine global eindeutige IPv4-Adresse bekommst und kein DS-Lite hast?

Bei DS-Lite wird der TCP-Port 8089 der FritzBox nicht als offen angezeigt, wenn man diesen TCP-Port aus dem Internet über die externe IPv4-Adresse (der FritzBox) scannt.

 

[MartinDJR]

Bei DS-Lite wird der TCP-Port 8089 der FritzBox nicht als offen angezeigt, wenn man diesen TCP-Port aus dem Internet über die externe IPv4-Adresse (der FritzBox) scannt.

Es ist zwar sehr unwahrscheinlich, aber soviel ich weiß, ist es bei einem CGNAT (also auch bei DS-Lite) durchaus auch möglich, dass ein bestimmter Port fälschlicherweise als "offen" angezeigt wird, wenn man exakt im "richtigen" Moment testet.

 

[tq1199]

..., dass ein bestimmter Port fälschlicherweise als "offen" angezeigt wird, wenn man exakt im "richtigen" Moment testet.

Warum deiner Meinung nach im "richtigen Moment"? Da müsste der Provider ja eine Portfreigabe, vom AFTR-Gateway (... als border device mit der aus dem Internet "sichtbaren" IPv4-Adresse), zu einem Gerät auf dessen TCP-Port 8089 gelauscht wird, konfigurieren.

Wie lange dauert dieser "richtige Moment"? D. h. ich kann den Portscan aus dem Internet, nach 1 Stunde oder nach 5 Stunden oder am nächsten Tag wiederholen und wenn dann der Port noch immer offen ist, habe ich kein DS-Lite?

Z. B. (m)eine FritzBox-cable als "border device", an einer Kopfstelle (CMTS) von Unitymedia:

<i>
</i>08:40:31.367106 B 00:0#:##:##:##:## ethertype IPv4 (0x0800), length 393: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) 10.217.252.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 349, hops 1, xid 0x5669e3dd, Flags [Broadcast] (0x8000) Client-IP 109.###.###.### Your-IP 109.###.###.### Server-IP 85.216.127.10 Gateway-IP 10.217.252.1 Client-Ethernet-Address ##:25:06:##:##:## Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 10.217.252.1 Lease-Time Option 51, length 4: 3600 Subnet-Mask Option 1, length 4: 255.255.252.0 Vendor-Option Option 43, length 65: 104.116.116.112.58.47.47.97.99.115.46.112.114.111.118.46.107.97.98.101.108.98.119.46.100.101.58.55.53.52.55.47.108.105.118.101.47.67.80.69.77.97.110.97.103.101.114.47.67.80.69.115.47.103.101.110.101.114.105.99.84.82.54.57.0 Default-Gateway Option 3, length 4: 109.###.###.1 Domain-Name-Server Option 6, length 8: 82.212.62.40,78.42.43.40 MTU Option 26, length 2: 576 END Option 255, length 0

(... diese Informationen werden von der CMTS per broadcast zur Verfügung gestellt).

Und hier ein Portscan aus dem Internet, auf die IP-Adresse dieser FritzBox-cable:

<i>
</i> ~ $ sudo nping -c 1 --tcp --flags syn -g 34345 -p 8089 109.###.###.###
Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2016-02-09 08:53 CET
SENT (0.0641s) TCP 91.###.###.##:34345 > 109.###.###.###:8089 S ttl=64 id=37387 iplen=40 seq=3023972162 win=1480
RCVD (0.0822s) TCP 109.###.###.###:8089 > 91.###.###.##:34345 SA ttl=63 id=0 iplen=44 seq=4230720385 win=5840 <mss 1460>
Max rtt: 17.874ms | Min rtt: 17.874ms | Avg rtt: 17.874ms
Raw packets sent: 1 (40B) | Rcvd: 1 (46B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.12 seconds

auf die Client-IP/Your-IP. Mit Hilfe der "Client-Ethernet-Address" kann ich das Gerät auch als AVM-Gerät identifizieren (was bei einem AFTR-Gerät/Gateway ja nicht der Fall sein wird).

 

[MartinDJR]

Warum deiner Meinung nach im "richtigen Moment"? Da müsste der Provider ja eine Portfreigabe, vom AFTR-Gateway (... als border device mit der aus dem Internet "sichtbaren" IPv4-Adresse), zu einem Gerät auf dessen TCP-Port 8089 gelauscht wird, konfigurieren.

Zunächst habe ich auch gedacht, dass es sich bei den CGNATs in den AFTRs um "symmetric NATs" handeln würde.

Dem spricht jedoch entgegen, dass es eine Möglichkeit gibt, wie zwei Rechner, die beide an DS-Lite-Anschlüssen hängen, mittels UDP Daten austauschen können: Es handelt sich wohl eher um "port restricted cone NATs".

Falls TCP an dieser Stelle genau so implementiert ist wie UDP, würde es genügen, wenn zuvor irgendwer eine TCP-Verbindung aufgemacht hat und der NAT dabei zufällig Port Nr. 8089 als Source-Port rausgesucht hätte: Im Endeffekt würde der AFTR dann für einige Sekunden eine Portweiterleitung von Port 8089 an denjenigen Port machen, der beim Aufbau der TCP-Verbindung der eigentliche Source-Port war...

Wie lange dauert dieser "richtige Moment"?

Mal davon abgesehen, dass so eine Konstellation so gut wie nie vorkommt (der Source-Port von TCP-Verbindungen ist i.d.R. nicht offen) definitiv keine Stunde.

Aber meine Frage - ob es mit Sicherheit kein DS-Lite ist - hat sich eigentlich an User "mril" gerichtet...

 

[mril]

Bist du dir wirklich sicher, dass du eine global eindeutige IPv4-Adresse bekommst und kein DS-Lite hast?

Wie genau äußert sich das?
Oder genauer: Von welchem Computer aus versuchst du, auf den Rechner zuhause zuzugreifen?

Ich habe es mit der http://www.yougetsignal.com/tools/open-ports/ Webseite versucht
Der 8089 Port ist Offen

 

[MartinDJR]

Wie genau äußert sich das?
Oder genauer: Von welchem Computer aus versuchst du, auf den Rechner zuhause zuzugreifen?

Ich habe es mit der http://www.yougetsignal.com/tools/open-ports/ Webseite versucht
Der 8089 Port ist Offen

Das war nicht meine Frage.

Ich wollte wissen, wie du herausgefunden hast, dass die Portweiterleitung nicht funktioniert.

Hintergrund:

Die meisten Router können eine Portweiterleitung "zurück" nicht machen. Wenn du also z.B. an einem Webbrowser auf einem Computer, der selbst am entsprechenden Router "angeschlossen" (damit ist auch WLAN gemeint) ist, deine Portweiterleitung auszuprobieren, funktioniert das nicht.

Wenn du es über dein Handy versucht hast, könnte es sein, dass du in WLAN-Reichweite warst und das Handy die Verbindung über WLAN hergestellt hat - also auch wieder über den Router...

Möglicherweise gibt es auch Provider, die bestimmte IP-Adressen auf der Blacklist haben - möglicherweise die IP-Adressen von "Heimanschlüssen"... Gerade Mobilfunkprovider sollen da ja angeblich manchmal einiges wegfiltern.

 

[hajodele]

Wenn es nur genau um den Port 8089 geht.
Hier habe ich was mit der 7490, was auch bei den Kabelboxen zutreffen kann: http://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/1472_Wie-ist-die-FRITZ-Box-vor-Angriffen-auf-Port-8089-geschuetzt/

Grundsätzlich gibt es selbstverständlich einige Ports, die der Router einfach für sich selbst zwingend braucht.

 

[tq1199]

Wenn es nur genau um den Port 8089 geht.

Nein, wenn es um die Portweiterleitung geht, dann geht es nicht um den TCP-Port 8089. Diesen Port (... an dem die FritzBox lauscht und nicht weitergeleitet ist) hat der TE nur deshalb aus dem Internet gescannt, um festzustellen ob er evtl. DS-Lite hat oder nicht hat.

 

[tq1199]

Hintergrund:

Die meisten Router können eine Portweiterleitung "zurück" nicht machen. Wenn du also z.B. an einem Webbrowser auf einem Computer, der selbst am entsprechenden Router "angeschlossen" (damit ist auch WLAN gemeint) ist, deine Portweiterleitung auszuprobieren, funktioniert das nicht.

BTW: Bei der FB6360-cable funktioniert das, denn die FB6360 kann Hairpin-NAT. Hier ein Beispiel, aus meinem WLAN an einen in der FB6360 weitergeleiteten Port:

<i>
</i>:~$ sudo nping -c 1 --tcp --flags syn -g 45456 -p ***** 109.###.###.###
Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2016-02-11 21:57 CET
SENT (0.0479s) TCP 192.168.178.21:45456 > 109.###.###.###:***** S ttl=64 id=25695 iplen=40 seq=4092694980 win=1480
RCVD (0.0543s) TCP 109.###.###.###:***** > 192.168.178.21:45456 SA ttl=62 id=0 iplen=44 seq=3585018147 win=28280 <mss 1414>
Max rtt: 6.088ms | Min rtt: 6.088ms | Avg rtt: 6.088ms
Raw packets sent: 1 (40B) | Rcvd: 1 (44B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.13 seconds

Wenn man aber den Port aus dem Internet erreichen will, sollte man nicht aus dem (W)LAN, sondern schon aus dem Internet scannen.

 

[MartinDJR]

Bei der FB6360-cable funktioniert das, denn die FB6360 kann Hairpin-NAT.

Danke für die Info - ich kenne de FB6360 nicht.

In diesem Fall sollte der Fragesteller mal ganz explizit diesen Versuch machen und sich von einem zweiten Rechner am Router aus auf den weitergeleiteten Port (mit der externen IP-Adresse) verbinden:

Wenn das nicht klappt, liegt es mit Sicherheit an der FritzBox, denn dabei werden keine Daten über's Kabel gesendet.

 

[koax]

Antivirus ausgeschaltet.

Und was ist mit einer Firewall des Rechners?

 

[mril]

In diesem Fall sollte der Fragesteller mal ganz explizit diesen Versuch machen und sich von einem zweiten Rechner am Router aus auf den weitergeleiteten Port (mit der externen IP-Adresse) verbinden:
Wenn das nicht klappt, liegt es mit Sicherheit an der FritzBox, denn dabei werden keine Daten über's Kabel gesendet.

Werde ich heute Abend versuchen.

Und was ist mit einer Firewall des Rechners?

Von meinem ersten Post

Beispielszenario:
Antivirus ausgeschaltet.
Meine Fritzbox bezieht eine ipv4 Adresse.
Ich öffne den 7000 UDP Port in der Fritzbox an meinen PC
Ich füge eine neue Eingehende und Ausgehen Regel (UDP 7000 Zulassen) in den Windows Firewall Einstellungen hinzu.
Ohne Erfolg

Beispielszenario 2:
Antivirus ausgeschaltet.
Meine Fritzbox bezieht eine ipv4 Adresse.
"Exposed Host" an meinen Computer aktiviert.
Firewall komplett ausgeschaltet.
Ohne Erfolg

 

[koax]

Firewall komplett ausgeschaltet.
Ohne Erfolg

Was je nach Firewall nicht unbedingt endgültig aussagekräftig ist.
Ich habe schon in der Vergangenheit erlebt, dass erst das Deinstallieren einer Firewall Erfolg brachte.

 

[tq1199]

Ich öffne den 7000 UDP Port in der Fritzbox an meinen PC

BTW: Für lauschende UDP-Ports sind die Internet-Tools die Du nutzt, nicht geeignet.

Dafür solltest Du dort wo auf dem UDP-Port 7000 gelauscht wird, z. B. tcpdump oder wireshark oder gleichwertig nutzen:

<i>
</i>sudo tcpdump -vvveni any udp port 7000

Auf dem scannenden Gerät im Internet, z. B. nping oder nmap oder gleichwertig.

Ich habe das bei mir, mit der FB6360, einem lauschenden UDP-Port auf dem Client der FB, nping (auf einem Gerät im Internet) und tcpdump (auf dem Client der FB) getestet und es funktioniert.

EDIT:

Maßgebend ist dann das, was tcpdump oder wireshark anzeigt. Erwarte nicht immer eine Antwort, vom lauschenden UDP-Port (... Konfiguration Server gegen udp-flood-attack & Co. ?) zurück an nping oder zurück an nmap, denn das UDP-Protokoll reagiert anders als das TCP-Protokoll (z. B. auf das syn mit syn+ack, etc., etc.).