ARP Anfragen laufen falsch herum ab?

[DotNet]

Folgende Situation: Ein PC (192.168.178.25) ist mit einem DSL-Router (192.168.178.1) verbunden. Auf diesem PC wird der gesamte Netzwerkverkehr mit Wireshark mitgeschnitten. Dieser PC ruft nun eine Internetseite auf, z.B. die Startseite von U-Labs. Damit auf Schicht 3 eine Kommunikation stattfinden kann, benötigt der PC die MAC-Adresse des Routers als Gateway, um zu ihm eine Verbindung aufzubauen.

Logisch gesehen müsste daher folgendes passieren:
ARP Broadcast: Wer hat 192.168.178.1?
Router antwortet auf die Broadcast mit seiner MAC-Adresse

Soweit die Theorie. In der Praxis ist es jedoch genau umgekehrt: Ich erhalte sogar drei Broadcasts, in denen, der Router die IP des Rechners anfrägt ("Who has 192.168.178.25? Tell 192.168.178.1"). Laut ARP Request ist der Sender die Fritz-Box. Aber wieso bekomme ich einen ARP Request von der Fritz! Box? Das kann logisch doch gar nicht sein, dass die einen ARP Broadcast sendet, wenn ich noch nicht mal eine Verbindung aufgebaut habe - denn dazu bräuchte mein Client ja die MAC der Fritz! Box, die er nicht haben kann, weil weder ein ARP Request gesendet wurde, noch eine ARP-Response empfangen.

[Leuchtturmwärter]

Wenn dein Browser-Request die allererste Kommunikation zwischen dem PC und der Fritzbox wäre, würdest du ihn auch als erstes sehen.
Nun wird er das allerdings nicht sein, und zwar aus einer Vielzahl von Gründen:

1. Gibt es einen sogeannten "ARP-Cache". Jedes moderne Betriebssystem hält einen solchen vor, unter Windows kannst du dir den aktuellen Inhalt mit arp -a auf der Konsole (cmd oder Powershell) anschauen und mit arp -d * leeren.
Hier speichert der Netzwerkstack des Betriebssystems die Ergebnisse von ARP-Anfragen zwischen, immerhin ändern sich die MAC-Adressen in der Regel nicht so häufig.
(Und falls sie es doch tun, bekommt man keine Antwort auf die Anfrage an die alte MAC und kann immernoch mit ARP nachfragen)
Einerseits wird damit das Netzwerk nicht so mit Broadcasts voll gespammt - gerade in größeren Ethernet Segmenten zählen Broadcasts zu den problematischeren Netzwerkverkehren, weil Switche sie an alle verbundenen Knoten weiterleiten müssen.
Andererseits beschleunigst du den Netzwerkverkehr, weil nicht immer erst auf die Antwort gewartet werden muss.

2. Dein PC hat vorher schon etwas im Internet getan, z.B. hat Windows nach Updates gefragt oder auch nur ausprobiert, ob das Internet erreichbar ist, um in der Taskleiste im Netzwerksymbol die Info "Internetzugriff" darstellen zu können.
Da hat sich dein PC schon bei der Fritzbox bekannt gemacht, und die sucht für den zurücklaufenden Verkehr nach deinem Rechner.

3. Die Fritzboxen haben ein paar aktive Netzwerkmonitoring - Funktionalitäten. Das siehst du z.B. im Webinterface unter Heimnetzwerk. Alle Infos, die da stehen, pollt die FB ab und zu, z.B. ob auf der IP auf Port 80 ein Webserver läuft.

4. Während der IP-Vergabe über DHCP ist es üblich, einen ARP-Request auf eine IP auszuführen, BEVOR sie vergeben wird. Antwortet jemand, wird die IP nicht vergeben, da sie ja schon in Verwendung ist. Entsprechend könnte das was du da siehst auch die Fritzbox sein, die die .25 an ein anderes Gerät vergeben will, und sicherheitshalber vorher nochmal nachfragt.

5. fällt mir gerade nicht ein, gibt aber noch einige weitere Möglichkeiten, die dein Phänomen erklären können.

Wenn du dich eher mit dem theoretischen Ablauf von Netzwerkkommunikation auseinander setzen möchtest, ist der Cisco Packet Tracer zu empfehlen. Den gibts bei Cisco nach einer Registrierung kostenlos (den Kurs musst du nicht machen, um an die Software zu kommen). Eigentlich ist der für Cisco-Trainings und -Zertifizierungen, ist zum lernen aber auch gut geeignet.
Hier kannst du virtuelle Netzwerke aus PC und Servern, Switches, "Heimrouter" wie Fritzboxen bis hin zu Routern für Internet Service Provider Backbones zusammenklicken und sehen, was auf der Leitung passiert - einige Anwendungen wie HTTP werden IIRC sogar ebenfalls simuliert. Ausserdem kannst du hier von Einwahlmodem bis zu 40Gbit/s-Glasfasertrunks auch andere Layer1/2 Technologien zum Vergleich anschauen.