12
Keine Reaktion auf ssh über fritzbox
Hallo an alle,
seit Jahren leitet meine Fritzbox den Port 1122 von außen auf den Port 22 zu meinen Raspberry Pi um. Hat immer funktioniert. Seit Kurzem reagiert der Raspberry von außen nicht mehr. Wenn ich mich aus meinem lokalen 192.168.*.* Netzwerk anmelde, klappt alles wunderbar. Von außen gibt es keine Rückmeldung und irgendwann bricht der ssh-Verbindungsaufbau mit einem timeout ab.
Das Portforwarding der Fritzbox funktioniert aber definitiv. tcpdump zeigt das an (raspi ist der Name im lokalen Netz des Raspberry Pis, giga der des Rechners, von dem ich tcpdump remote auf dem Rapsberry ausgeführt habe, XXXX.dip0.t-ipconnect.de ist der gleiche Rechner giga, allerdings über den Umweg meinName.no-ip.biz, um eine Anfrage von außen zu erreichen):
Das Gleiche (keine Reaktion, dann timeout) passiert übrigens bei einer Weiterleitung des Ports 443 auf meinen Webserver auf dem Raspberry, es scheint also kein Konfigurationsproblem des sshd zu sein. Ich habe weder an der Fritzbox noch am Raspberry aktiv Änderungen (abgesehen von Updates) vorgenommen.
Kann mir jemand einen Tipp geben? Vielen Dank , malkud
seit Jahren leitet meine Fritzbox den Port 1122 von außen auf den Port 22 zu meinen Raspberry Pi um. Hat immer funktioniert. Seit Kurzem reagiert der Raspberry von außen nicht mehr. Wenn ich mich aus meinem lokalen 192.168.*.* Netzwerk anmelde, klappt alles wunderbar. Von außen gibt es keine Rückmeldung und irgendwann bricht der ssh-Verbindungsaufbau mit einem timeout ab.
Das Portforwarding der Fritzbox funktioniert aber definitiv. tcpdump zeigt das an (raspi ist der Name im lokalen Netz des Raspberry Pis, giga der des Rechners, von dem ich tcpdump remote auf dem Rapsberry ausgeführt habe, XXXX.dip0.t-ipconnect.de ist der gleiche Rechner giga, allerdings über den Umweg meinName.no-ip.biz, um eine Anfrage von außen zu erreichen):
root@raspi:~# tcpdump -i br0 port 22 and not host giga
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:13:31.585267 IP XXXX.dip0.t-ipconnect.de.45240 > raspi.ssh: Flags [S], seq 764984743, win 29200, options [mss 1452,sackOK,TS val 306062 ecr 0,nop,wscale 7], length 0
18:13:31.586231 IP raspi.ssh > XXXX.dip0.t-ipconnect.de.45240: Flags [S.], seq 2860013794, ack 764984744, win 28960, options [mss 1460,sackOK,TS val 3593728 ecr 306062,nop,wscale 6], length 0
18:13:31.587771 IP XXXX.dip0.t-ipconnect.de.45240 > raspi.ssh: Flags [R], seq 764984744, win 0, length 0
18:13:32.584226 IP XXXX.dip0.t-ipconnect.de.45240 > raspi.ssh: Flags [S], seq 764984743, win 29200, options [mss 1452,sackOK,TS val 306312 ecr 0,nop,wscale 7], length 0
18:13:32.585168 IP raspi.ssh > XXXX.dip0.t-ipconnect.de.45240: Flags [S.], seq 2875621687, ack 764984744, win 28960, options [mss 1460,sackOK,TS val 3593828 ecr 306312,nop,wscale 6], length 0
18:13:32.586456 IP XXXX.dip0.t-ipconnect.de.45240 > raspi.ssh: Flags [R], seq 764984744, win 0, length 0
18:13:34.588319 IP XXXX.dip0.t-ipconnect.de.45240 > raspi.ssh: Flags [S], seq 764984743, win 29200, options [mss 1452,sackOK,TS val 306813 ecr 0,nop,wscale 7], length 0
18:13:34.588564 IP raspi.ssh > XXXX.dip0.t-ipconnect.de.45240: Flags [S.], seq 2906925394, ack 764984744, win 28960, options [mss 1460,sackOK,TS val 3594029 ecr 306813,nop,wscale 6], length 0
18:13:34.589873 IP XXXX.dip0.t-ipconnect.de.45240 > raspi.ssh: Flags [R], seq 764984744, win 0, length 0
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel
root@raspi:~# Das Gleiche (keine Reaktion, dann timeout) passiert übrigens bei einer Weiterleitung des Ports 443 auf meinen Webserver auf dem Raspberry, es scheint also kein Konfigurationsproblem des sshd zu sein. Ich habe weder an der Fritzbox noch am Raspberry aktiv Änderungen (abgesehen von Updates) vorgenommen.
Kann mir jemand einen Tipp geben? Vielen Dank , malkud
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: 344924
Url: https://administrator.de/forum/keine-reaktion-auf-ssh-ueber-fritzbox-344924.html
Ausgedruckt am: 22.04.2025 um 21:04 Uhr
12 Kommentare
Neuester Kommentar
Vermutlich schluckt die Firewall auf dem Rapsberry die Pakete. Was sagt denn
iptables -L -n -v
Hallo,
mach doch mal die Ports am WAN Deines Routers auf und zeige es allen im Internet!
Gruß
Dobby
mach doch mal die Ports am WAN Deines Routers auf und zeige es allen im Internet!
Kann mir jemand einen Tipp geben?
Benutze IPSec VPN zu Deiner Fritz!Box das ist sicher und da braucht man auch nichts mehr zu öffnen!Gruß
Dobby
Moin,
Was sagen denn die logs?
Hst Du nch irgendetwascauf dem Raspi, das neue chtlokale Verbindunfen blockkiert?
lks
Was sagen denn die logs?
Hst Du nch irgendetwascauf dem Raspi, das neue chtlokale Verbindunfen blockkiert?
lks
Du solltest auch keine IANA Ports nehmen für den Zugriff von außen. Empfehlung ist hier immer die sog. freien Ephemeral Ports zu nehmen in der Range 49152 bis 65535. Damit kollidierst du nicht mit offizell zugewiesenen Ports und zudem sind sie sicherer da klassische Port Scanner zum Angriff diese Ports meist nicht per Default scannen.
Versuche also mal sowas wie 52222 zu nehmen und das Port Forwarding damit zu machen.
Dein tcpdump zeigt ja auch nur einzig Pakete die vom RasPi zum Endgerät gehen aber niemals die andere Richtung. Da bleibt irgendwas hängen.
Möglich auch das du ein Hairpin NAT Problem hast an der FB. Das dürfte das Naheliegenste sein:
https://wiki.mikrotik.com/wiki/Hairpin_NAT
Normal kann einen FB nicht mit Hairpin NAT umgehen und scheitert daran.
Du solltest den Test also in jedem Falle mit einem Endgerät machen was definitiv im Internet bzw. irgendwo remote ist und NICHT in deinem lokalen lokalen Netz.
Also Smartphone z.B. über die Mobilfunk Provider Vewrbindung.
Versuche also mal sowas wie 52222 zu nehmen und das Port Forwarding damit zu machen.
Dein tcpdump zeigt ja auch nur einzig Pakete die vom RasPi zum Endgerät gehen aber niemals die andere Richtung. Da bleibt irgendwas hängen.
Möglich auch das du ein Hairpin NAT Problem hast an der FB. Das dürfte das Naheliegenste sein:
https://wiki.mikrotik.com/wiki/Hairpin_NAT
Normal kann einen FB nicht mit Hairpin NAT umgehen und scheitert daran.
Du solltest den Test also in jedem Falle mit einem Endgerät machen was definitiv im Internet bzw. irgendwo remote ist und NICHT in deinem lokalen lokalen Netz.
Also Smartphone z.B. über die Mobilfunk Provider Vewrbindung.
Vielen Dank schon mal für eure Vorschläge. Ok, Tests mache ich ab sofort von einem Rechner, der sich auch physikalisch nicht in meinem lokalen Netz befindet. Die logs von sshd sagen gar nichts, so als gäbe es keine Verbindungsaufnahme. Ich nehme wie vorgeschlagen einen 5-stelligen Port: keine Änderung.
Das von mir beschriebene Verhalten sieht tatsächlich so wie bei einer firewall aus. Ich kann mich nicht erinnern, eine firewall aktiviert zu haben. iptables ergibt Folgendes:
Hier noch ein paar Infos zur Netzwerkstruktur meines Raspberry:
eth0 -> Fritzbox
wlan0 -> WLAN-Accespoint mit hostapd
eth1 -> Wechselrichter, dessen Netzwerkverkehr geloggt wird
br0 verbindet diese drei physikalischen devices. br0 wird statisch eine IP zugewiesen. Ich habe beobachtet, dass die MAC-Adresse von br0 nicht immer die gleiche ist. Wenn ich es richtig beobachte, erhält br0 eine MAC von den drei physikalischen devices.
Bei laufendem hostapd erscheint bei ifocnfig noch das device mon.wlan0 (keine Ahnung wozu). Der WLAN-Accespoint schaltet sich nach 15min ohne angemeldetem Nutzer ab. Ab und zu scheint dabei br0 zu sterben, so dass ich über crond regelmäßig nachsehe, ob br0 existiert und ggf. wird alles neu eingerichtet. Dabei könnte br0 evtl. eine andere MAC erhalten. Kann man brctl dazu bewegen, eine feste MAC zu vergeben?
In meiner Fritzbox (Heimnetz/Heimnetzübersicht/netzwerkverbindungen) tauchen 1 bis 3 der physikalischen MAC-Adressen (manchmal auch die von br0) als unterschiedliche Geräte auf, die aber natürlich die gleiche IP haben, daher werden alle bis auf eine blockiert (sagt die Fritzbox).
Ich kann leider die Portweiterleitung nicht auf eine IP-Adresse, sondern nur auf eine MAC-Adresse anlegen. Leider beobachte ich, dass die Fritzbox diese MAC-Adresse aber scheinbar eigenmächtig ändert. (Ich gebe beim Erstellen der Weiterleitung das Gerät mit der MAC-Adresse von eth0 an. Nach dem Klicken von OK, zeigt die Fritzbox aber eine Weiterleitung auf das Gerät mit der MAC-Adresse von z.B. wlan0 an) Kann es evtl. daran liegen?
Man könnte natürlich auch statt der bridge den Datenverkehr von wlan0 und eth1 anders an eth0 weiterleiten. Ich weiß aber nicht genau, wie man das bewerkstelligt. Hätte das Sinn?
Ich könnte den Zugriff von außen auch irgendwie anders regeln (wie vorgeschagen), aber ssh erschien mir so simpel und durch die Möglichkeit zu tunneln, kann ich jede beliebige Anwendung über einen geöffneten Port erreichen.
Fragen über Fragen. Bin für jeden Hinweis dankbar. Danke und schöne Grüße, malkud
Das von mir beschriebene Verhalten sieht tatsächlich so wie bei einer firewall aus. Ich kann mich nicht erinnern, eine firewall aktiviert zu haben. iptables ergibt Folgendes:
root@raspi:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 160K packets, 23M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 171K packets, 18M bytes)
pkts bytes target prot opt in out source destination Hier noch ein paar Infos zur Netzwerkstruktur meines Raspberry:
eth0 -> Fritzbox
wlan0 -> WLAN-Accespoint mit hostapd
eth1 -> Wechselrichter, dessen Netzwerkverkehr geloggt wird
br0 verbindet diese drei physikalischen devices. br0 wird statisch eine IP zugewiesen. Ich habe beobachtet, dass die MAC-Adresse von br0 nicht immer die gleiche ist. Wenn ich es richtig beobachte, erhält br0 eine MAC von den drei physikalischen devices.
Bei laufendem hostapd erscheint bei ifocnfig noch das device mon.wlan0 (keine Ahnung wozu). Der WLAN-Accespoint schaltet sich nach 15min ohne angemeldetem Nutzer ab. Ab und zu scheint dabei br0 zu sterben, so dass ich über crond regelmäßig nachsehe, ob br0 existiert und ggf. wird alles neu eingerichtet. Dabei könnte br0 evtl. eine andere MAC erhalten. Kann man brctl dazu bewegen, eine feste MAC zu vergeben?
In meiner Fritzbox (Heimnetz/Heimnetzübersicht/netzwerkverbindungen) tauchen 1 bis 3 der physikalischen MAC-Adressen (manchmal auch die von br0) als unterschiedliche Geräte auf, die aber natürlich die gleiche IP haben, daher werden alle bis auf eine blockiert (sagt die Fritzbox).
Ich kann leider die Portweiterleitung nicht auf eine IP-Adresse, sondern nur auf eine MAC-Adresse anlegen. Leider beobachte ich, dass die Fritzbox diese MAC-Adresse aber scheinbar eigenmächtig ändert. (Ich gebe beim Erstellen der Weiterleitung das Gerät mit der MAC-Adresse von eth0 an. Nach dem Klicken von OK, zeigt die Fritzbox aber eine Weiterleitung auf das Gerät mit der MAC-Adresse von z.B. wlan0 an) Kann es evtl. daran liegen?
Man könnte natürlich auch statt der bridge den Datenverkehr von wlan0 und eth1 anders an eth0 weiterleiten. Ich weiß aber nicht genau, wie man das bewerkstelligt. Hätte das Sinn?
Ich könnte den Zugriff von außen auch irgendwie anders regeln (wie vorgeschagen), aber ssh erschien mir so simpel und durch die Möglichkeit zu tunneln, kann ich jede beliebige Anwendung über einen geöffneten Port erreichen.
Fragen über Fragen. Bin für jeden Hinweis dankbar. Danke und schöne Grüße, malkud
Wenn du mit tcpdump keinerlei inbound SSH Traffic siehst sofern du mit einem wirklich remoten Rechner zugreifst, dann blockt schon die FritzBox diesen Traffic und sie wäre der böse Buhmann.
Was du nochmal machen kannst ist direkt den FritzBox Port mit einem Wireshark zu sniffern ob dort irgendwas SSH mäßiges von außerhalb auftaucht.
Vermutlich wohl nicht und das würde dann sicher bestätigen das die SSH Pakete schon in der FritzBox hängen bleiben und nicht geforwardet werden.
Gut möglich das die FB "denkt" das inbound SSH für sie gedacht ist und deshalb das Port Forwarding unterdrückt. Wäre aber verwunderlich, da m.E. die FB keinen SSH Prozess hat.
Was du nochmal machen kannst ist direkt den FritzBox Port mit einem Wireshark zu sniffern ob dort irgendwas SSH mäßiges von außerhalb auftaucht.
Vermutlich wohl nicht und das würde dann sicher bestätigen das die SSH Pakete schon in der FritzBox hängen bleiben und nicht geforwardet werden.
Gut möglich das die FB "denkt" das inbound SSH für sie gedacht ist und deshalb das Port Forwarding unterdrückt. Wäre aber verwunderlich, da m.E. die FB keinen SSH Prozess hat.
Stimmt ! Das wäre einfacher als mit dem Wireshark.
Für mich sieht das, was er da zeigt, aber sehr nach Inbound-Traffic aus.
Hat der Raspberry denn eine Defaultroute zur Fritzbox und geht darüber ins Internet?
Hat der Raspberry denn eine Defaultroute zur Fritzbox und geht darüber ins Internet?
Hallo an alle,
da das Problem auch auftritt, wenn ich mich von meine Handy über Mobilfunk aus versuche einzuloggen, gehe ich nicht davon aus, dass es sich um inbound-traffic handelt. Aber letztlich kenne ich mich zu wenig aus, um das abschließend zu klären.
In den letzten Tagen hatte ich mich auch an den AVM-Support gewendet. Abschließend sind wir zu dem Punkt gekommen, dass die Fritzbox portforwarding an Netzwerkgeräte, die sich mit mehreren MACs gleichzeitig verbinden, nicht unterstützt.
Als workaround wurd vorgeschlagen, eine Bridging-Mehtode zu verwenden, die eingehende MACs durch eine einzige ersetzt. Ich werde sehen, ob ich etwas finde. Falls ich mein Problem in den Griff bekomme, melde ich mich hier noch einmal. Das kann aber etwas dauern.
Gruß, malkud
da das Problem auch auftritt, wenn ich mich von meine Handy über Mobilfunk aus versuche einzuloggen, gehe ich nicht davon aus, dass es sich um inbound-traffic handelt. Aber letztlich kenne ich mich zu wenig aus, um das abschließend zu klären.
In den letzten Tagen hatte ich mich auch an den AVM-Support gewendet. Abschließend sind wir zu dem Punkt gekommen, dass die Fritzbox portforwarding an Netzwerkgeräte, die sich mit mehreren MACs gleichzeitig verbinden, nicht unterstützt.
Als workaround wurd vorgeschlagen, eine Bridging-Mehtode zu verwenden, die eingehende MACs durch eine einzige ersetzt. Ich werde sehen, ob ich etwas finde. Falls ich mein Problem in den Griff bekomme, melde ich mich hier noch einmal. Das kann aber etwas dauern.
Gruß, malkud
gehe ich nicht davon aus, dass es sich um inbound-traffic handelt.
Hier ist wieder die Sichtweise relevant was "inbound" ist...Der Traffic kommt aus dem Intewrent in deine Fritzbox rein, ist also inbound (eingehend) Traffic an der Fritzbox am WAN/DSL Port.
Die FritzBox leitet das per Portforwarding weitewr und der Traffic geht dann aus dem LAN Intrerface der FritzBox raus (Outbound) auf dein lokales LAN. Dort ist der RasPi für den dieser Traffic gedacht ist, denn das Port Forwarding schiebt ihn ja an die IP des RasPis.
Am LAN Port des RasPis ist also dieser Traffic aus dem Internet wieder inbound.
Eigentlich ganz logisch und einfach zu verstehen. Dafür muss man kein Experte sein und muß sich auch nicht auskennen, das kann auch der Azubi im ersten Lehrjahr logisch nachvollziehen.
Netzwerkgeräte, die sich mit mehreren MACs gleichzeitig verbinden, nicht unterstützt.
Das ist ja ziemlicher Blödsinn. Mac Adressen sind einzigartig und welches Endgerät verbindet sich mit mehreren Mac Adressen gleichzeitig ?? Dein RasPi hat ja auch nur eine einzige Mac Adresse.Da haben die dir einen ziemlichen Bären aufgebunden und dich etwas verar.... um das Thema vom Tisch zu haben !
Ein arp -a auf dem RasPi zeigt das er nur mit einer einzigen Mac connectet. So wie es auch Standard konform ist.
die eingehende MACs durch eine einzige ersetzt.
Was denn für eingehende Macs ?? Das gibt nur eine einzige und das ist die Mac der FB am LAN Port.Wie gesagt.... ein arp -a auf dem RasPi zeigt dir das !!
Wo sollen den mehrere Macs herkommen...das ist Blödsinn, vergiss das.
Das iost ne simple Banalkonfig die mit Portforwarding von TCP 22 auf jedem Baumarkt Router zum Fliegen kommt.
Hallo an alle,
nach zwei Monaten gebe ich einen Statusbericht ab. Auch wenn ich nicht beurteilen kann warum, so führte doch folgendes Verfahren zum Erfolg:
Der Netzwerkbrücke br0 wird eine Fantasie-MAC zugeordnet. Da brctl das wohl nicht kann, habe ich das Kommando
verwendet. Dazu habe ich in /etc/network/interfaces bei der Definition von br0 folgende Zeile eingefügt:
eingefügt.Das ganze funktioniert jetzt mehrere Wochen problemlos. Statt XX:XX:XX:XX:XX:XX:XX:XX verwende ich ntürlich nur die Ziffern 0 bis f.
Schöne Grüße, malkud
nach zwei Monaten gebe ich einen Statusbericht ab. Auch wenn ich nicht beurteilen kann warum, so führte doch folgendes Verfahren zum Erfolg:
Der Netzwerkbrücke br0 wird eine Fantasie-MAC zugeordnet. Da brctl das wohl nicht kann, habe ich das Kommando
ifconfig br0 hw ether XX:XX:XX:XX:XX:XX:XX:XXverwendet. Dazu habe ich in /etc/network/interfaces bei der Definition von br0 folgende Zeile eingefügt:
post-up ifconfig br0 hw ether XX:XX:XX:XX:XX:XX:XX:XXeingefügt.Das ganze funktioniert jetzt mehrere Wochen problemlos. Statt XX:XX:XX:XX:XX:XX:XX:XX verwende ich ntürlich nur die Ziffern 0 bis f.
Schöne Grüße, malkud
