[Gelöst] FritzBox 7490 - RaspberryPI im Heimnetz aus Gastnetz erreichbar

rerhafnhabu

Mitglied
Mitglied seit
28 Jul 2006
Beiträge
388
Punkte für Reaktionen
41
Punkte
28
Wieso kann ich mit einem an der Fritzbox 7490 im Gastnetz angeschlossenen PC einen Raspberry PI per ssh erreichen,
der im Heimnetz angeschlossen ist?

Auf dem Raspberry PI läuft PiHole, der als DNS-Server in der Fritzbox eingetragen ist und daher für beide Netze zuständig ist.
Ein Ping aus dem Gastnetz auf den RaspberryPI dagegen liefert Zeitüberschreitung.

MS-Copilot gibt diese Antwort:
Wenn dein Raspberry Pi mit Pi-hole als DNS-Server läuft und in der Fritzbox als DNS-Server eingetragen ist, passiert Folgendes:
Die Fritzbox nutzt den Raspberry Pi für alle DNS-Anfragen, auch im Gastnetz.
Das bedeutet: Geräte im Gastnetz fragen die Fritzbox nach DNS-Auflösung → Fritzbox leitet die Anfrage an den Raspberry Pi weiter.
Damit muss die Fritzbox Routing zwischen Gastnetz und Heimnetz erlauben, zumindest für DNS (Port 53) – und möglicherweise auch für andere Dienste wie SSH (Port 22), wenn keine strikte Firewall-Regel aktiv ist.

Kann das jemand so bestätigen?
Sollte ich das unterbinden? (RaspberryPI ist ausschließlich mit einem ssh-Zertifikat erreichbar)
 
Könnt ihr alle nicht mehr selbst denken und/oder suchen und müßt Euch dann am Ende die (falschen) Antworten der KI doch wieder erklären lassen? Ich halte Dir zwar zugute, daß Du den Einsatz der MS-KI "zugibst", aber wenn das Schule macht, korrigieren wir hier irgendwann nur noch solchen Unsinn.

Wenn die FRITZ!Box als DNS-Server im Gastnetz verwendet wird, arbeitet sie als DNS-Forwarder (vielleicht erklärt die KI ja das dann richtig) und es wird nichts zwischen Gastnetz und LAN "geroutet", denn darunter versteht man das Re-Adressieren und die Weiterleitung ankommender Netzwerk-Pakete, deren Payload(!) dann unverändert zum Ziel übertragen wird.

DNS-Forwarder sind aber KEINE Router, erst recht nicht für SSH-Traffic - sie fragen als "Stellvertreter" die ihnen vorgelagerten DNS-Server (wenn die Info nicht schon in ihrem Cache enthalten ist) und speichern im besten Fall die Ergebnisse vom Upstream noch zwischen, bevor sie mit den erhaltenen Informationen die Abfrage des Clients beantworten.
 
Deswegen frage ich ja hier :)
Ich hatte schon einige Suchen durchgeführt, jedoch keine plausible Antwort gefunden.

Ich kann mir das Verhalten einfach nicht erklären, wie ich aus dem Gastnetz auf den PI im Heimnetz komme.
Sollte ja eigentlich nicht so sein.
 
Kommt man (kommst Du) ja gar nicht - da "lügt" CoPilot einfach, weil er keine Ahnung hat, WIE der DNS-Forwarder im FRITZ!OS arbeitet bzw. wie das DNS wirklich funktioniert. Wie man (wieder) sehen kann, sind das alles nur "Wahrscheinlichkeiten" bei den gegebenen Antworten (und sicherlich ist die Frage eines Routings zwischen Gastnetz und LAN oft genug ventiliert worden in den Daten, mit denen trainiert wurde) und da ist keine Spur von einem (wie auch immer gearteten) echten Verständnis - selbst wenn man noch die RFCs zum DNS hinterherfüttern würde.

Wenn Du allerdings Deinen Pi-Hole als (lokalen) DNS-Server befragen läßt von einem Gerät aus dem Gastnetz (mit der FRITZ!Box als Forwarder), dann sieht der eben seinerseits die FRITZ!Box als Quelle der DNS-Anfrage und antwortet darauf auch mit lokalen Adressen aus dem LAN, wenn sich eine Anfrage darauf bezieht. Das heißt aber auch noch nicht, daß da ein "Zugriff" möglich ist - wenn ich ein Telefonbuch lesen kann, muß ich noch lange nicht jemanden anrufen können, der darin verzeichnet ist.

Zwischen Gastnetz und LAN werden IP-Pakete gefiltert und wenn Daten aus dem Gastnetz parallel zu Daten aus dem LAN übertragen werden müssen (das wäre zwischen Repeatern und dem Edge-Router der Fall), dann werden sie zusätzlich "verpackt" (aka gekapselt), damit sie nicht von Geräten im LAN empfangen (genauer: verarbeitet) werden können.

Ich bin mir allerdings nicht sicher, ob der DNS-Forwarder im Rahmen der Prüfung auf "DNS rebinds" (das ist das Beantworten von Anfragen mit lokalen Adressen, womit man ggf. Verbindungen attackieren könnte) schon selbst die Antworten mit Adressen aus dem LAN an Clients im Gastnetz unterbindet - es könnte auch sein, daß das der Fall ist. Dann kriegen die Clients im Gastnetz nicht mal mehr die (IP-)Adressen von Geräten im LAN heraus - um beim Vergleich zu bleiben: Dann finden sie nicht mal mehr die Telefonnummer. Wobei das eben auch kein Problem wäre - s.o.

Oder wolltest Du uns sagen, daß Du tatsächlich (wie auch immer) aus dem Gastnetz auf den Pi-Hole zugreifen kannst (der hoffentlich nicht mit zwei Interfaces ausgestattet ist)? Andererseits schreibst Du ja, daß nicht mal ein "ICMP echo request" (das ist das ping) funktioniert …

EDIT:
Ich hatte schon einige Suchen durchgeführt
Ich hoffe, wir verstehen hierbei unter "Suchen" dasselbe - ICH betrachte Chat-Bots NICHT als Suche.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Peter_Lehmann
Das war doch eine eindeutige Frage im ersten Satz.

Nachher erst hat er für sich selbst auch unter Zuhilfenahme anderer Mittel es zu erklären versucht.
Du unterstellst da m.E. Dinge, die nirgendwo stehen.
Kann mich auch täuschen, aber so habe ich es gelesen und nicht umgekehrt.
 
  • Like
Reaktionen: rerhafnhabu
Der Unterschied von Suche und Chatbot ist mir duchaus bekannt. :)

Zu Konfiguration:
Der Raspberry ist per LAN an Port3 der Fritzbox angeschlossen und hat nur 1 Interface.
In der Box sind 2 Wireguard-VPN und 2 IP-Sec VPN, jedoch alle inaktiv.
An Port 2 ist ein Repeater 1750 im Mesh angeschlossen, mit diesem verbindet sich mein Laptop.
Ein weiterer 1750 ist per WLAN verbunden.

Wenn ich mit Putty via Port 22 auf den PI zugreife funktioniert das.
Aber nur ssh, nicht den Webserver und auch kein Ping.

Und jetzt bin ich auf der Suche nach dem Grund, weshalb ist, was ja eigentlich nicht sein darf (sollte).
 
Und wo ist in dem ganzen Konstrukt jetzt das Gastnetz involviert?

EDIT:
Und ja, ich habe die Frage bisher NICHT richtig verstanden, wenn da in #1 davon die Rede ist, der PC wäre an der FRITZ!Box 7490 "im Gastnetz" angeschlossen - jetzt ist er ja offenbar über einen der vorhandenen Repeater eingebunden. Bei den Angaben, welcher Port da was ist, wäre es auch gut, wenn man die passenden Bezeichnungen verwendet - so ist der intern als eth0 gehandelte Port mit der Bezeichnung LAN1 versehen, was sich dann bis zu eth3 (dessen Name ist dann LAN4) fortsetzt und der Letztgenannte kann auch als dem Gastnetz zugehörig konfiguriert werden.

Vor allem ist mir bei dem nunmehr besser erklärten Problem aber unklar, was dann CoPilot zum DNS von sich gegeben hat - was hat DAS mit der Frage, ob da die Isolation zwischen Gastnetz und Heimnetz nicht funktioniert, zu tun?
 
Zuletzt bearbeitet:
Kannst Du mal ping und ssh Zugriff auf den Pi unter Verwendung der Windows integrierten Powershell bzw. des Terminals testen.
Kannst Du mal alle WLAN ausschalten und denn den PC an LAN 4 anschließen (Gastzugang für LAN 4 aktiv) und auch dann testen.
 
Was zeigt denn der RasPi bei der SSH-Sitzung an, woher diese kommt? Stammt die tatsächlich von einer IP-Adresse aus dem Gastnetz?

Oder ist es am Ende so, daß die SSH-Session über einen Namen (oder eine Adresse) aufgebaut wurde, wo die FRITZ!Box als Edge-Router für den Client im Gastnetz ihrerseits NAT macht (ist das überhaupt IPv4 oder doch IPv6) und dann die Verbindung über NAT-Hairpinning quasi als vom WAN ausgehend behandelt wird?

Wenn der RasPi hier über (s)eine extern erreichbare IPv6-Adresse angesprochen würde und da entweder auf ihm selbst eine Firewall (für andere Dienste) aktiv ist oder nur der SSH-Server an diese (verwendete) Adresse gebunden ist, würde das zumindest erklären, warum die anderen Dienste nicht erreichbar sind. Und dann würde sich das Phänomen darauf reduzieren, daß bei dieser Verbindung der Client aus dem Gastnetz wie jeder x-beliebige andere Client bei eingehenden(!) Verbindungen behandelt wird.

Aber das sind alles nur theoretische Überlegungen, solange über die konkrete Konfiguration nicht genug bekannt ist - den größten Teil davon kann man mit dem Blick auf den RasPi während einer solchen SSH-Session klären.
 
Zuletzt bearbeitet:
Was zeigt denn der RasPi bei der SSH-Sitzung an, woher diese kommt? Stammt die tatsächlich von einer IP-Adresse aus dem Gastnetz?
Daten der letzten Anmeldung am Raspi:
Last login: Sun Aug 3 19:42:07 2025 from 192.168.179.15 - also Gastnetz.

Kannst Du mal ping und ssh Zugriff auf den Pi unter Verwendung der Windows integrierten Powershell bzw. des Terminals testen.
Kannst Du mal alle WLAN ausschalten und denn den PC an LAN 4 anschließen (Gastzugang für LAN 4 aktiv) und auch dann testen.

Anmeldung des Raspi auch möglich, wenn beide WLAN aus sind, der Raspi an LAN 3 und der PC an LAN 4 der Box angeschlossen ist.
Mit dem Windows-ssh kann ich mich ohne Zertifikat nicht anmelden, erreicht wird der Raspi jedoch.

Code:
C:\Users\hg>ping 192.168.1.81
Ping wird ausgeführt für 192.168.1.81 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.1.81:
    Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1
    (100% Verlust),
STRG-C
^C
C:\Users\hg>ssh 192.168.1.81
The authenticity of host '192.168.1.81 (192.168.1.81)' can't be established.
ED25519 key fingerprint is SHA256:aIBiV3x###########0h7GXbzs.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.81' (ED25519) to the list of known hosts.
[email protected]: Permission denied (publickey).

Für ssh existiert für IPv6 eine Portfreigabe TCP, allerdings nicht auf Port 22.
Vom PC am LAN 4 kann ich den Raspi werder über die Lokale IPv4 fd00.. noch die Externe IP (2003...) erreichen ausschließlich über die IPv4

was hat DAS mit der Frage, ob da die Isolation zwischen Gastnetz und Heimnetz nicht funktioniert, zu tun?
Dem liegt meine Überlegung zugrunde, daß die DNS-Auflösung durch den Raspi für beide Netze gilt.
 
Verrate doch mal, wo Du den RPi genau als DNS-Server eingetragen hast? (Unter "Internet" oder "Heimnetz" - erstelle am einfachsten einen Screenshot)
 
192.168.1.81 ist der 1. Raspi mit PiHole um den es geht
192.168.1.85 ist ein 2. Raspi mit PiHole der jedoch nicht mehr angeschlossen ist.
fd00::81 ist ebenfalls der Raspi 1
2a0... ist Adguard auf einem privaten Server
 

Anhänge

  • 2025-08-04 12_22_55-2025-08-03 19_20_58-FRITZ!Box 7490 – Mozilla Firefox.png.png
    2025-08-04 12_22_55-2025-08-03 19_20_58-FRITZ!Box 7490 – Mozilla Firefox.png.png
    76.2 KB · Aufrufe: 29
Also befragt die FRITZ!Box selbst einen bzw. in Deinem Fall mehrere DNS-Server, wovon bei einem bekannt ist, dass dieser eh nicht funktioniert.

Wenn dann sollte die FRITZ!Box weiterhin öffentliche DNS-Server für deren Anfragen kontaktieren und nur im LAN den "DNS-Server" auf den gewünschten "umbiegen" (unter "Heimnetz").

So werden DNS-Anfragen im Gastzugang auch nicht über den PiHole abgefragt - weshalb es jedoch in Deinem Szenario nun möglich zu seien scheint, dass der Zugriff wirklich aus dem 179ger Netz kommt, erschließt sich mir jedoch nicht - den Aufwand dies bei mir umzukonfigurieren tue ich mir jedoch nicht an (auch wenn dieser nur im LAN erreichbar sein soll/ist, würde ich nur die Geräte bzw. IPs im sshd konfigurieren, welche auch wirklich darauf zugreifen sollen/dürfen/müssen).
 
Was steht genau in SSH_CLIENT oder SSH_CONNECTION, wenn das in der SSH-Sitzung vom Windows-PC angezeigt wird? Das ist nicht nur das letzte Login, sondern die beiden IP-Endpoints (Adressen und Ports).

Was steht bzgl. der Netzwerk-Konfiguration (speziell zu den in den Bridges versammelten Interfaces) in den Support-Daten? Aus dem Inhalt der o.a. Environment-Variablen geht dann auch hervor (zumindest aus SSH_CONNECTION), welche Adressen der PC in dieser Verbindung hat.

Gibt es tatsächlich KEINE weiteren Freigaben in der FRITZ!Box für dieses Gerät? Was passiert, wenn Du auch die vorhandene IPv6-Freigabe mal löschst (dann wird das anders behandelt im Router und nicht nur auf dem Client) oder gar IPv6 auf dem RasPi mal komplett (temporär natürlich nur) deaktivierst? An welche Netzwerk-Adressen ist der SSH-Daemon auf dem RasPi gebunden (netstat oder ss)?

Warum ist der vom RasPi verwendete Ed25519-Schlüssel bisher nicht bekannt gewesen, wenn Du da schon vorher Verbindungen aufgebaut hast? Ist das tatsächlich derselbe Key wie zuvor (aka derselbe Hash)? Oder ist das verwendete ssh-Kommando kein Alias für das plink von PuTTY?

In jedem Fall speichere mal die Support-Datei vom derzeitigen Zustand, BEVOR Du weitere Tests machst - dann kann man notfalls, falls das Phänomen verschwindet, immer noch prüfen, woran es vielleicht lag. Ich gehe mal fest davon aus, daß Du die Gerätschaften alle schon mal neu gestartet hast, als Dir das Problem auffiel - das sollte zwar auch nach längerer Laufzeit nicht vorkommen, aber ein paar (asynchron für die drei AVM-Geräte ausgeführte) Updates könnten da ja auch die L2TPv3-Tunnel zwischen dem Master und den Repeatern in Mitleidenschaft gezogen haben und der Traffic wird jetzt nicht mehr richtig gekapselt. Wenn nicht, würde ich das nachholen (also die Neustarts) - aber erst die Support-Daten sichern.

Normal ist dieser Zustand jedenfalls tatsächlich nicht und es ist (und bleibt) interessant, der Ursache auf den Grund zu gehen. Das anfängliche Mißverständnis meinerseits basierte halt darauf, daß Du da auch
Kann das jemand so bestätigen?
gefragt hattest (bezog sich ja wohl auf die KI-Aussage) und ich nicht verstanden hatte, daß es ein existierendes Phänomen war, was den Erklärungsversuch durch CoPilot veranlaßte und nicht nur eine falsche Auskunft der KI (denn die stimmt tatsächlich nicht bzgl. des Routings), die Dich zur Annahme verleitet hätte, da wäre ein Zugriff möglich.

Deshalb (und weil hier seit einiger Zeit immer öfter falsche Ansagen der KI ventiliert werden von Benutzern, die nicht selbst schreiben (wollen oder) können) auch mein anfänglicher Kommentar zur Nutzung von KI - nicht persönlich gemeint und ich entschuldige mich ausdrücklich.
 
Ich habe es unter F!OS 8.10 versucht nachzustellen, was mir nicht gelang.

IPv4 und v6 Server zeigen auf den lokalen PiHole - wie zu erwarten, war keine Kommunikation aus dem Gast- ins Heimnetz möglich, kein Ping und auch kein SSH auf Port 22 oder einem abweichenden (welchen ich in der Regel nutze).

Im Zweifel hätte ich noch mindestens eine 7490 da und könnte es, falls nötig, mit einer solchen kaskadiert und einer frischen PiHole-Instanz (ein 5er hat meinen 3 und 3+ nun endlich abgelöst, somit ist dies ja schnell aufgesetzt) auf F!OS 7.60 ebenfalls nochmals nachstellen
 
Ich habe es unter F!OS 8.10 versucht nachzustellen, was mir nicht gelang.
Mit z. B. F!OS 8.03 und wenn das Gerät aus dem Heimnetz als upstream-DNS-Server (wie beim TE) in der FritzBox eingertragen ist, sind aus dem Gast-Netz alle Ports des Gerätes im Heim-Netz erreichbar. Z. B.:
Code:
$ nc -zvn 192.168.178.13 41832
found 0 associations
found 1 connections:
     1: flags=82<CONNECTED,PREFERRED>
        outif en0
        src 192.168.179.3 port 49987
        dst 192.168.178.13 port 41832
        rank info not available
        TCP aux info available
Connection to 192.168.178.13 port 41832 [tcp/*] succeeded!
Das (in der FritzBox als DNS-Server eingetragene) Gerät aus dem Heim-Netz, muss auch nicht zwingend auf dem Port 53 (UDP und TCP) lauschen.
 
Wenn das tatsächlich auch das Problem beim TO sein sollte, dann würde das bei AVM schon seit Jahren mitgeschleppt, wenn da bei ihm nur eine 7490 (aktuellste Firmware: 07.60) und zwei 1750e (aktuellste Firmware 07.32) im Einsatz sind.

Nicht unmöglich, daß es bisher niemand bemerkt hatte (wenn es nur in bestimmten Konstellationen auftritt, eben wenn da ein lokaler DNS-Server verwendet wird) - aber das wäre schon ein ziemlich dicker Hund und müßte dann eigentlich seitens AVM auch noch weitere Updates für die älteren Geräte nach sich ziehen; denn das könnte sich - je nach Ursache - als handfestes Sicherheitsproblem herausstellen, wenn da die Netze nicht (richtig) voneinander isoliert sind.

Andererseits widerspricht die Feststellung weiter oben, daß kein Zugriff auf den ebenfalls auf dem RasPi laufenden Webserver möglich wäre, dem hier:
sind aus dem Gast-Netz alle Ports des Gerätes im Heim-Netz erreichbar
und man sollte vielleicht doch noch mal die genauen Umstände klären. Auch dabei sollten die Support-Daten helfen können, denn da steht auch vieles zur Netzwerk-Konfiguration drin und auch die Firewall auf dem RasPi könnte dabei noch eine Rolle spielen. Außerdem sollte das ja schnell zu klären sein, indem man einfach den lokalen DNS-Server kurzzeitig durch den der WAN-Verbindung (oder einen anderen öffentlichen) ersetzt.

Ich muss mal nach alten Unterlagen suchen, ob ich tatsächlich in den Zeiten, wo mich das noch interessiert hat, auch mit einem lokalen DNS-Resolver getestet habe … was ich mir anders gar nicht vorstellen kann, denn ich hatte eigentlich immer nur einen lokalen bind9-Server mit einem Uplink auf meinen eigenen Server im Internet im Einsatz. Als ich das getestet habe ("damals", als das Gastnetz eingeführt wurde), war iirc wirklich JEDER Traffic aus dem Gastnetz ins Heimnetz unterbunden, auch das Weiterleiten von UDP-Paketen, für die bekanntlich nicht mal der "Rückweg" funktionieren müßte für Angriffe auf bekanntgewordene Schwachstellen.
 
Ich habe jetzt mal den Linux-PC per WLAN ans Gastnetz gehängt, damit gibt es mehr Testmöglichkeiten.
nmap 192.168.1.81 -Pn -p1-65535 :
Nur Port 22/tcp ist aus dem Gastnetz (192.168.179.14) offen

Auch wenn die DNS-Server v4 und v6 auf "Vom Internetanbieter zugewiesene DNSv4-Server verwenden (empfohlen)" umgestellt sind, bleibt ssh möglich.

Gibt es weitere Dinge die auf dem Raspberry und dem Laptop testen kann?
Die shells stehen bereit :cool:
Ich würde ungern die Freigaben und ganze Konfiguration auf der Fritz!Box ändern, da spielt die Familie nicht mit :-)

DIe AVM-Geräte haben alle den aktuellen-Firmwarestand

Neustart der Box hatte ich Nachts mal gemacht, die Supportdatei leider erst danach erstellt, Problem besteht aber weiterhin.
Die ist 4MB groß und es stehen etliche Dinge drin, die ich ungern veröffentlichen würde (myfritz-Adressen, VPN-Schlüssel (nur die öffentlichen), MAC, Rufnummer etc. )
Teile davon aber gerne.

nicht persönlich gemeint und ich entschuldige mich ausdrücklich.
Danke, aber kein Problem.
Im Nachhinein weiß ich immer genau, wie ich es hätte besser schreiben können.
Manchmal sind meine Aussagen nicht immer so klar, wie ich es beabsichtige.
 
Nur Port 22/tcp ist aus dem Gastnetz (192.168.179.14) offen
Hast Du in deiner FritzBox evtl. eine Portweiterleitung für NAT (IPv4), um deinen PI aus dem v4-Internet auf dem Port 22 zu erreichen?
Lauscht auf deinem PI der sshd evtl. nur auf der IP-Adresse 192.168.1.81?
Starte auf deinem PI im Heim-Netz, vor dem Portscan mit nmap aus dem Gast-Netz (... mit der source-IP-Adresse 192.168.179.14):
Code:
sudo tcpdump -vvveni eth0 src host 192.168.179.14
 
Was steht genau in SSH_CLIENT oder SSH_CONNECTION, wenn das in der SSH-Sitzung vom Windows-PC angezeigt wird? Das ist nicht nur das letzte Login, sondern die beiden IP-Endpoints (Adressen und Ports).
pi@pi1:~ $ echo $SSH_CLIENT
192.168.179.14 57348 22
pi@pi1:~ $ echo $SSH_CONNECTION
192.168.179.14 57348 192.168.1.81 22
 
Kostenlos!

Statistik des Forums

Themen
248,905
Beiträge
2,303,630
Mitglieder
378,538
Neuestes Mitglied
FraSche