Merkwürdige Verbindungen vom ctlmgr auf Port 80 einiger bekannter Geräte

[frank_m24]

Hallo zusammen,

durch einen Zufall hab ich heute eine merkwürdige Entdeckung gemacht. Und zwar sendet der ctlmgr von der Fritzbox zuweilen Anfragen an gewisse Geräte auf Port 80.

Konkret geht es dabei um Geräte, die ich über eine VPN Verbindung in mein Heimnetz lasse, z.B. mein Handy oder mein Notebook. VPN ist bei mir Wireguard auf einem Raspi. Zuweilen buche ich mich von diesen Geräten auf die Weboberfläche meiner Fritzbox ein. Sobald ich das einmal gemacht habe, fängt der ctlmgr an, diese IP Adressen auf Port 80 zu kontaktieren. Das macht er stundenlang, auch wenn die VPN Verbindung schon gar nicht mehr existiert*). Ungefähr alle 05:30 Minuten schickt die Box ein TCP syn Paket auf die Reise:

17:02:09.623876 IP fritz.box.38675 > 192.168.200.4.http: Flags [S], seq 1951974932, win 29200, options [mss 1460,sackOK,TS val 171431340 ecr 0,nop,wscale 7], length 0
17:02:09.625089 IP fritz.box.39585 > 192.168.200.6.http: Flags [S], seq 277158391, win 29200, options [mss 1460,sackOK,TS val 171431340 ecr 0,nop,wscale 7], length 0
17:07:37.612093 IP fritz.box.41091 > 192.168.200.4.http: Flags [S], seq 1147720454, win 29200, options [mss 1460,sackOK,TS val 171513337 ecr 0,nop,wscale 7], length 0
17:07:37.613818 IP fritz.box.45949 > 192.168.200.6.http: Flags [S], seq 608017337, win 29200, options [mss 1460,sackOK,TS val 171513338 ecr 0,nop,wscale 7], length 0

Interessant: Sie scheint das nur für die VPN Clients zu machen. Lokale Clients bekommen die Pakete anscheinen nicht.

Übrigens: Dass der ctlmgr der Übeltäter ist, hab ich aus den erweiterten Supportdaten ausgelesen. Dort gibt es eine netstat-ähnliche Ausgabe, wo die Informationen drin waren.

Frage: Weiß jemand, was die Box hier macht und wann sie damit aufhört?

*): Deshalb ist es mir aufgefallen, weil das VPN Interface plötzlich dropped Packets in der Statistik hatte. Mit ein bisschen Suchen sind mir dann die Pakete von der Box aufgefallen, die an VPN Clients geschickt wurden, die gar nicht mehr verbunden waren.

 

[Benares]

Könnte es nicht einfach damit zusammenhängen, dass eine Fritzbox immer nach allen internen Geräten sucht, die einen Web-Server betreiben?
Schließlich will sie diese z.B. auch mit Link und nicht nur mit dem Namen z.B. in der Mesh-Übersicht darstellen. Hat evtl. gar nichts mit VPN zu tun.

 

[frank_m24]

Ja, hab ich auch gedacht. Aber externe VPN Clients aus einem völlig anderen Subnetz, die die Box nur über eine statische Route erreicht, tauchen in der Mesh- oder Netzwerkübersicht nicht auf. Deshalb ja meine Verwunderung, dass lokale Clients die Pakete nicht bekommen.

 

[PeterPawn]

externe VPN Clients aus einem völlig anderen Subnetz, [...] tauchen in der Mesh- oder Netzwerkübersicht nicht auf

Du hast doch selbst geschrieben, daß diese Zugriffe erst dann beginnen, wenn von so einem Client auf die FRITZ!Box zugegriffen wurde (von der LAN-Seite). Damit ist das Gerät als "Nachbar*in" (neighbour - AVM verwendet komischerweise immer die britische Schreibweise an dieser Stelle) identifiziert/registriert und das FRITZ!OS versucht jetzt zu erkennen, ob auf diesem Gerät ein Service unter Port 80 zu erreichen ist. Meines Wissens wird auch nur auf Port 80 geprüft, was schon für sich genommen ein Anachronismus ist, denn heutzutage lauten alle Empfehlungen ja auf TLS-Verschlüsselung für HTTP-Übertragungen.

Das passiert (nach meiner Erfahrung jedenfalls) auch für alle anderen LAN-Clients, so lange, bis diese "offene Frage" für die Geräte "geklärt" ist. Danach erhalten sie dann im Array landevices/landevices in der ar7.cfg einen entsprechenden Status mit einem von diesen zwei (gültigen) Werten:

• eLUrlStatusNotAvailable
• eLUrlStatusAvailable

während zuvor der Wert eLUrlStatusUnknown verwendet wird.

Solange das Vorhandensein so eines Services ungeklärt ist, wird in regelmäßigen Intervallen immer wieder versucht, eine Antwort zu erhalten, die eine "Einstufung" erlaubt. Dabei gehört ein "timeout" sicherlich nicht zu den "gültigen" Ergebnissen ... und genau das dürfte für diese Verbindungsversuche das Resultat sein.

Käme da (weil die Clients verbunden sind) eine "Ablehnung" mit einem entsprechenden ICMP-Paket (dazu darf sich das Gerät dann aber eben auch nicht als "black hole" gebärden, sondern muß - ganz "regulär" - auf TCP-Verbindungsversuche zu nicht geöffneten Ports auch mit passenden Protokoll-Meldungen reagieren), würde sich der Status auf eLUrlStatusNotAvailable ändern und die Verbindungsversuche würden auch wieder aufhören ... bis das Gerät wieder "verloren" geht (und damit auch das Ergebnis dieser "Erkundung") - dann beginnt das ggf. wieder von vorne.

Ob so ein Client, der über ein externes Wireguard-Gateway Verbindung zur FRITZ!Box hatte, noch intern "präsent" ist (das muß auch nicht zwangsläufig in der ar7.cfg persistent gespeichert sein), sollte sich in den Supportdaten der Box feststellen lassen. Die Sektion in den Supportdaten trägt den Titel landevices und - je nach FRITZ!OS-Version - dort sollte sogar ein Protokoll verfügbar sein, in dem mit Zeilen à la set url status for ... festgehalten wurde, wann Versuche, den "url status" festzustellen, gestartet wurden und welches Ergebnis diese erbrachten.

 

[frank_m24]

Vielen Dank erst mal!

Käme da (weil die Clients verbunden sind) eine "Ablehnung" mit einem entsprechenden ICMP-Paket (dazu darf sich das Gerät dann aber eben auch nicht als "black hole" gebärden, sondern muß - ganz "regulär" - auf TCP-Verbindungsversuche zu nicht geöffneten Ports auch mit passenden Protokoll-Meldungen reagieren),

Das könnte ich ja im Zweifel über die Firewall des Wireguard-Raspis erledigen lassen. Was wäre da denn besser? Ein tcp-reset oder ein icmp-port-not-reachable?