FritzBox über DynDNS erreichbar, leitet aber Port nicht weiter

[Mister.X]

Hallo zusammen,

ich nutze die FB 7490 momentan in der aktuellen Firmware.
Ich habe an der FB einen RaspberryPI angeschlossen und wollte eine interne Weiterleitung, wenn ich von extern auf die FritzBox (z.B. mit DynDNS) gehe und dann sogar noch einen Port 8083. Dieser ist lt. FritzBox mit der IP von Raspberry verknüpft.

Dennoch ist es so, dass es keine Weiterleitung zum Raspberrry PI Auswirkung hat.
Sprich: Intern funktioniert das alles gerade

 

[sf3978]

... von extern auf die FritzBox ...

"extern" heißt von einem fremden/anderen (nicht dein eigener) Internetanschluss?

(z.B. mit DynDNS) gehe und dann sogar noch einen Port 8083. Dieser ist lt. FritzBox mit der IP von Raspberry verknüpft.

Starte mal auf deinem PI:

sudo tcpdump -c 5 -vvveni <Interface> port 8083

(Interface ohne spitze Klammern musst Du anpassen).
und scanne danach aus dem Internet diesen Port bzw. die externe IPv4-Adresse deiner FB. Wie ist nach dem scannen, auf deinem PI die Ausgabe von tcpdump?

 

[Mister.X]

Hallo @sf3978 ,
vielen Dank für deinen Antwort.

Also kurz zu deinen Fragen:
Extern = z.B: mit meinem Tablet (nicht im WLAN, LAN verbunden!!) über die SIMCard Zugriff auf die FritzBox bzw. der Versuch, darüber auf den Raspberry zu kommen. Alternativ von der Arbeit von einem PC, der natürlich nicht direkt mit dem Netzwerk zuhause verbunden ist.

Über die TCP-Dump-Anwendung konnte ich herausfinden... der Raspi antwortet anscheinend doch, wenn ich von extern auf die IP zugreife.

pi@raspberrypi:~ $ sudo tcpdump -c 5 -vvveni eth0 port 8083
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:49:11.527071 34:31:c4:4a:c0:78 > b8:27:eb:c4:a0:a9, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 37865, offset 0, flags [DF], proto TCP (6), length 60)
    89.204.154.120.45841 > 192.168.178.39.8083: Flags [S], cksum 0xa850 (correct), seq 2229642516, win 65535, options [mss 1360,sackOK,TS val 90388221 ecr 0,nop,wscale 7], length 0
17:49:11.527454 b8:27:eb:c4:a0:a9 > 34:31:c4:4a:c0:78, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.39.8083 > 89.204.154.120.45841: Flags [S.], cksum 0x6743 (incorrect -> 0xb38f), seq 3406262390, ack 2229642517, win 28960, options [mss 1460,sackOK,TS val 256718944 ecr 90388221,nop,wscale 7], length 0
17:49:11.535670 34:31:c4:4a:c0:78 > b8:27:eb:c4:a0:a9, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 44109, offset 0, flags [DF], proto TCP (6), length 60)
    89.204.154.120.61823 > 192.168.178.39.8083: Flags [S], cksum 0x28c4 (correct), seq 3496450736, win 65535, options [mss 1360,sackOK,TS val 90388221 ecr 0,nop,wscale 7], length 0
17:49:11.535984 b8:27:eb:c4:a0:a9 > 34:31:c4:4a:c0:78, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.39.8083 > 89.204.154.120.61823: Flags [S.], cksum 0x6743 (incorrect -> 0xbc80), seq 3032677948, ack 3496450737, win 28960, options [mss 1460,sackOK,TS val 256718945 ecr 90388221,nop,wscale 7], length 0
17:49:11.586027 34:31:c4:4a:c0:78 > b8:27:eb:c4:a0:a9, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 54, id 37866, offset 0, flags [DF], proto TCP (6), length 52)
    89.204.154.120.45841 > 192.168.178.39.8083: Flags [.], cksum 0x50ca (correct), seq 1, ack 1, win 685, options [nop,nop,TS val 90388226 ecr 256718944], length 0
5 packets captured
5 packets received by filter
0 packets dropped by kernel
pi@raspberrypi:~ $ sudo tcpdump -c 5 -vvveni eth0 port 8083
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:49:22.706807 34:31:c4:4a:c0:78 > b8:27:eb:c4:a0:a9, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 9959, offset 0, flags [DF], proto TCP (6), length 60)
    89.204.154.120.62052 > 192.168.178.39.8083: Flags [S], cksum 0xed39 (correct), seq 2208505279, win 65535, options [mss 1360,sackOK,TS val 90389336 ecr 0,nop,wscale 7], length 0
17:49:22.707163 b8:27:eb:c4:a0:a9 > 34:31:c4:4a:c0:78, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.39.8083 > 89.204.154.120.62052: Flags [S.], cksum 0x6743 (incorrect -> 0x363c), seq 3686079911, ack 2208505280, win 28960, options [mss 1460,sackOK,TS val 256720062 ecr 90389336,nop,wscale 7], length 0
17:49:22.714959 34:31:c4:4a:c0:78 > b8:27:eb:c4:a0:a9, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 1758, offset 0, flags [DF], proto TCP (6), length 60)
    89.204.154.120.56497 > 192.168.178.39.8083: Flags [S], cksum 0xa92a (correct), seq 3181264262, win 65535, options [mss 1360,sackOK,TS val 90389336 ecr 0,nop,wscale 7], length 0
17:49:22.715280 b8:27:eb:c4:a0:a9 > 34:31:c4:4a:c0:78, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.39.8083 > 89.204.154.120.56497: Flags [S.], cksum 0x6743 (incorrect -> 0xcc05), seq 930080787, ack 3181264263, win 28960, options [mss 1460,sackOK,TS val 256720063 ecr 90389336,nop,wscale 7], length 0
17:49:22.766457 34:31:c4:4a:c0:78 > b8:27:eb:c4:a0:a9, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 54, id 9960, offset 0, flags [DF], proto TCP (6), length 52)
    89.204.154.120.62052 > 192.168.178.39.8083: Flags [.], cksum 0xd373 (correct), seq 1, ack 1, win 685, options [nop,nop,TS val 90389344 ecr 256720062], length 0
5 packets captured
5 packets received by filter
0 packets dropped by kernel

oder interpretier ich das gerade falsch?

 

[sf3978]

Hallo @sf3978 ,

pi@raspberrypi:~ $ sudo tcpdump -c 5 -vvveni eth0 port 8083
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:49:22.706807 34:31:c4:4a:c0:78 > b8:27:eb:c4:a0:a9, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 9959, offset 0, flags [DF], proto TCP (6), length 60)
    89.204.154.120.62052 > 192.168.178.39.8083: Flags [S], cksum 0xed39 (correct), seq 2208505279, win 65535, options [mss 1360,sackOK,TS val 90389336 ecr 0,nop,wscale 7], length 0
17:49:22.707163 b8:27:eb:c4:a0:a9 > 34:31:c4:4a:c0:78, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.39.8083 > 89.204.154.120.62052: Flags [S.], cksum 0x6743 (incorrect -> 0x363c), seq 3686079911, ack 2208505280, win 28960, options [mss 1460,sackOK,TS val 256720062 ecr 90389336,nop,wscale 7], length 0

oder interpretier ich das gerade falsch?

Nein, es ist nich falscht. Der PI antwortet mit syn+ack, d. h. die Portweiterleitung ist OK. Evtl. ist der Dienst der auf dem Port 8083 lauscht, nicht richtig konfiguriert.

 

[Mister.X]

Okay. vielen Dank. Dann schau ich dort mal genauer nach...

 

[timo1803]

Hallo zusammen
Ich habe hier das gleiche Anliegen aber ein anderes Problem..
Bei mir funktioniert das Dynamic DNS allerdings glaube ich funktioniert das Port forwarding nicht.
DDNS habe ich so getestet, meine IP auf NOIP.com umgestellt und anschließend die Anwendung auf dem PI gestartet daraufhin wurde die IP auf NOIP wieder verändert (also müsste arbeiten richtig?)
Wie kann ich mich da am besten reindebuggen?
hat jemand Tipps?
schonmal vielen Dank

 

[PeterPawn]

Einfach einen Blick in das PCP-Protokoll der FRITZ!Box werfen ... das steht dann in den Support-Daten und wenn da alles richtig erscheint, bietet die FRITZ!Box einen Paketmitschnitt an, mit dem man solche Probleme genauer unter die Lupe nehmen kann.

 

[timo1803]

hey PeterPawn danke für die schnelle Antwort .
ich hab jetzt gerade so ziemlich jede Funktion der FritzBox durchgeschaut aber einen Sniffer habe ich nicht gefunden..
kann es sein dass man iwelche Einstellungen am PI vornehmen muss? kommt sofort immer diese Fehlermeldung..

 

[PeterPawn]

Für das Auffinden der beiden angesprochenen Punkte im GUI einer FRTZ!Box, reicht oft schon eine Internet-Suche mit "Support-Daten" und/oder "Paketmitschnitt" aus ... ich wurde zumindest sofort fündig, aber ich benutzte dabei auch eine Suchmachine, die eher als Geheimtipp gilt - daher kann ich deren Adresse hier auch nur umschreiben, wenn ich keinen Ärger kriegen will; zum "Entschlüsseln" braucht man aber nur eine POSIX-kompatible Shell.

for i in $(( 42 / 7 )) $(( 7 * 2 )) $(( 3 ** 2 + 5 )) $(( 54 / 9 )) $(( ( 1 << 4 ) - 5 )) $(( 2 ** 2 )) $(( 156 / 6 )) $(( 1 << 1 )) $(( 4 * 3 * 2 - 10 )) $(( 3 * 4 )); do printf "%c" $(expr "abcdefghijklmnopqrstuvwxyz." : ".\{$i\}\(.\).*"); done; printf "\n"

 

[timo1803]

Danke für den kleinen Denkanstoß
ich hab mir jetzt den Paketmitschnitt mal angekuckt und finde es schaut gut aus.. allerdings habe ich das hier gefunden:

network failure und das Datum bzw Uhrzeit schaut verdächtig aus

 

[PeterPawn]

Ne, das ist normal beim Start einer Box, wenn es noch keine Internetverbindung (daher der "network failure") gibt ... man sieht es auch an der U(h)rzeit, daß die Box noch keinen Kontakt zu einem NTP-Server hatte.

Danach sollte halt noch ein Eintrag für das erfolgreiche Mapping kommen - sonst gehen da auch keine Daten von außen rein auf dem Port 443.

 

[timo1803]

Der Pi hängt am Wlan und das Datum zeigt er auch richtig an!?
aber danke für deine tolle Unterstützung, ich schau mal das mapping an

 

[timo1803]

müsste dieser sein?

 

[PeterPawn]

Wenn der RasPi die .62 ist und dort der Port 443 auch "bedient" wird, dann sollte das auch funktionieren ... das müßte man ja problemlos im Paketmitschnitt erkennen können, ob/wann da SYN- und ACK-Pakete kommen und von wem. Selbst wenn das irgendwann mal auf TLS schaltet, sollte der TCP-Fluß ja erkennbar sein.

 

[timo1803]

ich habe allerdings auch etwas gefunden bei dem ich mir nicht sicher bin ob dass so gehört..

und zwar geht es um die externe IP Adresse, diese unterscheidet sich von der, die ich von NOIP nach aussen bekomme..

 

[PeterPawn]

Wie soll das dann gehen? Die FRITZ!Box "denkt" zumindest, daß sie diese Adresse hat (btw ... mach mal was an den Screenshots, das ist ja grausam, wenn da eine Zeile so aussieht) und akzeptiert auch nur Pakete mit dieser Zieladresse auf dem WAN-Interface und wenn da jemand von außen über noip.com eine andere Adresse angesagt bekommt, kann ja auch kaum eine Verbindungsanfrage von außen in irgendeinem Paketmitschnitt zu sehen sein.

Dieser Paketmitschnitt ist eben das Alpha und das Omega ... wenn da kein Request zu sehen ist, kann er auch nicht am RasPi ankommen. Erst wenn da SYN-Pakete von der externen Adresse auftauchen, die Du für den Zugriffsversuch benutzen willst, erst dann lohnt es sich überhaupt, irgendetwas anderes zu untersuchen.

Also besser nicht "raten", sondern systematisch überprüfen und wenn die FRITZ!Box gerade erst die Adresse bezogen haben sollte (die auch hier noch nicht gesetzte Uhrzeit in der Meldung deutet darauf hin), dann braucht es ggf. noch einen Moment, bis das (absichtlich verzögerte) DynDNS-Update ausgeführt wird und es bei noip.com auch die richtige Adresse gibt.

Aber jetzt sollte es auch gut sein mit dem "Ping-Pong" ... wie man so einen Mitschnitt analysieren kann, ist z.B. für Wireshark ganz gut kommentiert und wo man auf der Box mitschneiden sollte (1. Internetverbindung vs. LAN - da ist dann WLAN eingeschlossen, denn LAN ist eine Bridge und kein phys. Interface), muß man halt auch überlegen. Aber das kann Dir niemand abnehmen ... das mußt Du schon selbst machen (und so schwer ist das ja auch nicht, wenn Du Dir zutraust, einen RasPi in Betrieb zu nehmen und als externen Service bereitzustellen).

 

[bass-a]

Hallo,
da dieses Problem zu meinem sehr ähnlich ist, wollte ich kein zweites Thema aufmachen. Vielleicht hat ja einer eine Antwort
Auch bei mir geht es um Freigabeprobleme bzgl. Port-Weiterleitung.
In meiner Fritzbox Ist eine IPv4+IPV6 Freigabe an meinem WLAN-Router als Exposed-Host eingerichtet.
Nach einem IP-Wechsel in der Nacht "schaltet" die FritzBox die IPV4 "Exposed-Host" Freigabe zum Wlan-Router ab. Sprich sie wird noch aktiv angezeigt, fakto macht er aber dicht (es kommen keine Pakete aus dem Inet mehr am WLAN-Router an)
Verbindungen, die aus dem (W)LAN aufgemacht werden funktionieren (Surfen ist ohne weiteres möglich). Der DynDNS Dienst der Fritzbox aktualisiert die IP ohne Probleme bei meinem Anbieter, sprich die Namensauflösung ist korrekt (IPV4+IPV6).
Das komische dabei ist nur, dass es allein IPV4 betrifft, die IPV6-Freigabe funktioniert auch nach IP-wechsel tadellos.
Nach einem Neustart (IP-wechsel eingeschlossen )der FritzBox funktioniert auch die IPV4 Fregabe wieder wunderbar

Ist das ein BUG ? Gibt es ein Workaround ? Das umstellen auf Routing anstatt NAT am WLAN-Router wollte ich vermeiden.

Gibt es eine Möglichkeit (ohne Freetz) die Freigabe auf auf Systemebene zu setzten, ohne Webinterface ?

Folgendes Setup :
INET <----> FritzBox 7412 <----> WLAN ROUTER <---> (W)LAN
________________________________________<----> Webserver
OS : FitzOS 6.83

MFG Andreas

 

[PeterPawn]

Möglicherweise ein bekanntes Problem und möglicherweise auch in der 06.90 behoben:

"Behoben - PCP-Portfreigaben konnten sich sporadisch verstellen"

Ob das für Dich auch gilt und was die eigentliche Ursache bei Dir ist (eine "verschwundene" Freigabe oder eine nicht funktionierende oder eine auf einem anderen Port gelandete), kannst Du nur selbst in den Support-Daten ermitteln.