PCs empfangen falsche MAC-Adresse für das Default-Gateway

[Datax]

Hallo Leute,

ich brauche mal einen Tipp von euch.

Habe hier ein Netzwerk, in welchem mehrere PCs sporadisch keinen Internetzugang haben.

Habe bereits rausgefunden, dass im Fehlerfall (Internetzugang funktioniert nicht) im ARP-Cache eines der betroffenen PCs eine falsche MAC-Adresse für das Default-Gateway eingetragen ist. Die IP-Adresse für das Default-Gateway ist die 192.168.2.1.

Mal angenommen, dass die MAC-Adresse AA:BB:CCD:EE:FF die richtige MAC-Adresse
und GG:HH:II:JJ:KK:LL die falsche MAC-Adresse für die 192.168.2.1 ist.

Im Fehlerfall sieht also der ARP-Eintrag für das Default-Gateway so aus:
192.168.2.1 GG:HH:II:JJ:KK:LL (falsche MAC-Adresse)

Wenn der Internetzugang funktioniert, sieht der ARP-Eintrag so aus:
192.168.2.1 AA:BB:CCD:EE:FF (richtige MAC-Adresse)

Was ich bereits rausfinden konnte, ist, dass die falsche MAC-Adresse (also die GG:HH:II:JJ:KK:LL, um beim Beispiel zu bleiben) zur "eth3"-Netzwerkkarte der Sophos-Firewall im besagten Netzwerk gehört.

Die richtige MAC-Adresse für die 192.168.2.1 (also die AA:BB:CCD:EE:FF) gehört
zur "eth1"-Netzwerkkarte der Sophos-Firewall. Auf der Netzwerkkarte "eth1" ist also
die IP-Adresse 192.168.2.1/24 konfiguriert.

Für mich stellt sich die Frage wie es passieren kann,
dass für die 192.168.2.1 ein ARP-Eintrag entstehen kann, der die MAC-Adresse
einer Netzwerkkarte der Sophos-Firewall enthält, die gar nicht die IP-Adresse 192.168.2.1 konfiguriert hat.

Auf der "eth3"-Netzwerkkarte selbst ist keine IP-Adresse konfiguriert, lediglich auf den VLAN-Interfaces,
die auf "eth3" angelegt sind. Diese VLAN-Interfaces liegen in den VLANs 5 - 7.

Die "eth1"-Netzwerkkarte der Sophos-Firewall ist am Aruba-Switch im VLAN 1 angeschlossen und ist auf der Sophos-Firewall
eine ganz "normale" Netzwerkkarte, also kein VLAN-Interface.

Hat jemand einen Tipp für mich wie ich bei Suche nach der Ursache vorgehen kann?
Wie kann so ein fehlerhafter ARP-Eintrag zustande kommen?
Wie kann ich dafür sorgen, dass dauerhaft die richtige MAC-Adresse im ARP-Cache für die 192.168.2.1 eingetragen wird?

Der Fehler tritt sporadisch auf. Sprich, die vom besagten Fehler betroffenen PCs haben auch manchmal
die richtige MAC-Adresse für das Default-Gateway im ARP-Cache und können problemlos den Internetzugang nutzen.
Sporadisch wird dann wieder die falsche MAC-Adresse für die 192.168.2.1 "gelernt" und der Internetzugang fällt dann aus.

Habe einen Netzwerkplan mit angehangen. Die Sophos-Firewall läuft virtuell auf einem ESXi-Server, der an einem Aruba-Switch angeschlossen ist.

Datax

 

[riversource]

Diese VLAN-Interfaces liegen in den VLANs 5 - 7.

Welche IP-Bereiche nutzen die?

Aus deinem Schaubild werde ich nicht schlau. Was macht dieser merkwürdige "Virtual Switch 1"? Warum nutzen beide Portgruppen "VLAN ID All"? Warum haben beide Ports am Aruba Switch die VLAN IDs 5-7 und das untagged VLAN drin? Da sehe ich direkt haufenweise Möglichkeiten, dass die VLANs vermischt werden, und dann ist klar, woher das Problem kommt.

 

[Datax]

Das ist einfach aus dem "VMware vCenter" übernommen, also die Darstellung mit den Port-Groups sowie dem vSwitch.

Es ist halt ein virtueller Switch, der die am vSwitch angeschlossenen Port-Groups mit den physikalischen Netzwerkkarten des ESX-Servers verbindet.

Im vSwitch ist konfiguriert, dass die 2. NIC des ESX-Servers als Fallback-Netzwerkkarte arbeitet. Über die 2. NIC geht also nur Datenverkehr, wenn zuvor die 1. NIC ausgefallen (defekt gegangen ist). Aus dem Grund muss
der Port am Aruba-Switch, an dem die 2. Netzwerkkarte (Physical NIC 2) des ESX-Servers angeschlossen ist,
natürlich identisch konfiguriert sein.

Die Port-Group A ist nicht als "VLAN ID All" konfiguriert. Weiß ich nicht, wo du das gesehen hast.
Die Port-Group A ist so konfiguriert, dass kein VLAN-Tag übertragen wird, deshalb steht dort einfach nur "VLAN ID:".

Bei Port-Group B werden alle VLAN-Tags, die von der Sophos-Firewall kommen (5 -7) weitergereicht.
Im "vCenter" gibt es die Einstellung "VLAN ID All" für eine Port-Group, durch die es egal ist, welches VLAN-Tag da reingeflattert kommt.

VLAN5 ist das Netz 192.168.5.0/24
VLAN6 ist das Netz 192.168.6.0/24
VLAN7 ist das Netz 192.168.7.0/24

 

[t-6]

Welche genaue MAC-Adresse haben denn jetzt überhaupt die richtigen/falschen 192.168.2.1? Oder anders gefragt: Wo ist der mutmaßliche Telekom-Router angeschlossen & konfiguriert der nicht im Schaubild ist? Warum hat die Sophos die IP 192.168.2.1 auf dem mutmaßlichen WAN-Interface (eth0) konfiguriert, obwohl das die klassische "interne" LAN IP eines Speedports ist?

btw, noch ein Ansatz: Sofern es sich hier um ein klassisches Netzwerk in Baumstruktur handelt mit der Sophos als "Stamm", sollten die PCs überhaupt nicht die IP 192.168.2.1 als Gateway bekommen sondern eher etwas aus ihrem eigenen Subnetz bspw. 192.168.7.1 für VLAN7 usw.
Kann es sein dass PCs die du bspw. am Aruba-Switch an einem untagged VLAN7-Port angeschlossen hast (respektive tagged VLAN7 & im PC entsprechend konfiguriert) trotzdem - wenigstens ab und zu - eine IP aus dem Bereich 192.168.2.x bekommen?

Schreib mal bitte noch mehr Informationen dazu wie du die Netze an der Sophos konfiguriert hast, gerne auch die jeweiligen DHCP-Einstellungen, und auch was du dir denkst wie es funktionieren sollte. Hier fehlt einfach noch einiges an Infos.

 

[Datax]

Welche genaue MAC-Adresse haben denn jetzt überhaupt die richtigen/falschen 192.168.2.1? Oder anders gefragt: Wo ist der mutmaßliche Telekom-Router angeschlossen & konfiguriert der nicht im Schaubild ist? Warum hat die Sophos die IP 192.168.2.1 auf dem mutmaßlichen WAN-Interface (eth0) konfiguriert, obwohl das die klassische "interne" LAN IP eines Speedports ist?

Die richtige MAC-Adresse für 192.168.2.1 ist die MAC-Adresse der eth0-Netzwerkkarte der Sophos-Firewall.
Das ist die MAC-Adresse AA:BB:CCD:EE:FF, um beim Beispiel von #1 zu bleiben.

Es gibt keinen Speedport-Router. Wie kommst du darauf? Die 192.168.2.1 liegt wie gesagt auf der eth0-Netzwerkkarte der Firewall.

Die PCs im Netz 192.168.2.0/24 beziehen ihren Internetzugang über die Firewall. Als Default-Gateway bekommen die PCs in diesem Netz (das ist übrigens VLAN1) die 192.168.2.1 mitgeteilt.

Das Problem, das diese PCs haben, ist wie gesagt, dass sie für die 192.168.2.1 nicht die MAC-Adresse von "eth0" der Firewall, sondern die MAC-Adresse von "eth3" der Firewall "lernen" (ARP-Eintrag). Die PCs sollen für die 192.168.2.1 die MAC-Adresse von "eth0" der Firewall lernen, da eben auf "eth0" die 192.168.2.1 liegt.

Auf "eth3" direkt liegt gar keine IP-Adresse. Auf "eth3" sind lediglich VLAN-Interfaces für die VLANs 5 - 7 konfiguriert. Die Firewall hat also auch in den VLANs 5 - 7 jeweils eine eine IP-Adresse.

IP der Firewall im VLAN5 = 192.168.5.1/24
IP der Firewall im VLAN6 = 192.168.6.1/24
IP der Firewall im VLAN7 = 192.168.7.1/24

btw, noch ein Ansatz: Sofern es sich hier um ein klassisches Netzwerk in Baumstruktur handelt mit der Sophos als "Stamm", sollten die PCs überhaupt nicht die IP 192.168.2.1 als Gateway bekommen sondern eher etwas aus ihrem eigenen Subnetz bspw. 192.168.7.1 für VLAN7 usw.
Kann es sein dass PCs die du bspw. am Aruba-Switch an einem untagged VLAN7-Port angeschlossen hast (respektive tagged VLAN7 & im PC entsprechend konfiguriert) trotzdem - wenigstens ab und zu - eine IP aus dem Bereich 192.168.2.x bekommen?

Schreib mal bitte noch mehr Informationen dazu wie du die Netze an der Sophos konfiguriert hast, gerne auch die jeweiligen DHCP-Einstellungen, und auch was du dir denkst wie es funktionieren sollte. Hier fehlt einfach noch einiges an Infos.

Es geht lediglich um das Netz 192.168.2.0/24, das ist VLAN1.
Die Geräte in den VLANs 5 - 7 haben keine Probleme.

Selbstverständlich bekommen die Geräte der VLANs 5 - 7 nicht die 192.168.2.1 als Default-Gateway, was man übrigens unter Windows gar nicht so konfigurieren kann. Man würde direkt beim Abspeichern der Einstellungen der Netzwerkkarte eine Fehlermeldung bekommen.

Default-Gateway der Geräte im VLAN5 = 192.168.5.1 (Sophos-Firewall)
Default-Gateway der Geräte im VLAN6 = 192.168.6.1 (Sophos-Firewall)
Default-Gateway der Geräte im VLAN7 = 192.168.7.1 (Sophos-Firewall)

In sämtlichen VLANs in diesem Netzwerk (VLAN1, VLANs 5 - 7) bekommen die Geräte per "DHCP" als Default-Gateway die IP-Adresse der Sophos-Firewall im jeweiligen IP-Netz zugewiesen (also wie oben aufgeführt).

 

[Raijin]

Beobachte doch mal mittels WireShark / tcpdump die ARP-Kommunikation.

Über ARP wird die MAC des Gateways ermittelt, indem der Client einen ARP-Request per Broadcast an FF:FF:FF:FF:FF:FF schickt mit der IP des Gateways im Gepäck. "Who has 192.168.2.1? Tell 192.168.2.34" steht da sinngemäß drin. Jeder Netzwerkteilnehmer bekommt diesen Broadcast und derjenige, der besagte IP-Adresse hat - das Gateway - antwortet darauf mit einem Unicast an den Absender des ARP-Requests.

Es ist nun anzunehmen, dass in deinem Fall unterschiedliche ARP-Reply Nachrichten ankommen. Entweder antwortet die Sophos tatsächlich mit der falschen MAC in der Reply Nachricht oder aber der ARP-Reply wird vom anderen Interface aus geschickt. Letzteres müsste man dadurch sehen können, dass die MAC des Absenders nicht mit der MAC im Reply übereinstimmt.

 

[Hammelkopp]

Welches Sophos Interface hat denn die falsche MAC d.h. welches VLAN Interface?

 

[Datax]

Beobachte doch mal mittels WireShark / tcpdump die ARP-Kommunikation.

Über ARP wird die MAC des Gateways ermittelt, indem der Client einen ARP-Request per Broadcast an FF:FF:FF:FF:FF:FF schickt mit der IP des Gateways im Gepäck. "Who has 192.168.2.1? Tell 192.168.2.34" steht da sinngemäß drin. Jeder Netzwerkteilnehmer bekommt diesen Broadcast und derjenige, der besagte IP-Adresse hat - das Gateway - antwortet darauf mit einem Unicast an den Absender des ARP-Requests.

Es ist nun anzunehmen, dass in deinem Fall unterschiedliche ARP-Reply Nachrichten ankommen. Entweder antwortet die Sophos tatsächlich mit der falschen MAC in der Reply Nachricht oder aber der ARP-Reply wird vom anderen Interface aus geschickt. Letzteres müsste man dadurch sehen können, dass die MAC des Absenders nicht mit der MAC im Reply übereinstimmt.

Ja, das hatte ich auch schon gemacht. Die Firewall beantwortet die ARP-Requests für die 192.168.2.1 über beide Interfaces (eth0 + eth3).

Die ARP-Replies, die über "eth3" versendet werden, sorgen dann für den defekten Internetzugang.

Ggf. muss ich das Linux-OS der Firewall "überreden" nur noch von dem Interface ARP-Replies zu beantworten, das auch wirklich die angefragte IP-Adresse konfiguriert hat. Habe im Internet gelesen, dass es Kernel-Parameter gibt, über die man das ARP-Verhalten des Linux-OS steuern kann.

Interessant ist, dass das Setup so wie es aktuell angeschlossen und konfiguriert ist (Firewall, Aruba-Switch, ESX-Server, Verkabelung) jahrelang problemlos funktioniert hat. Vielleicht hat ein Firmware-Update der Firewall mal irgendwann das Problem ins Netzwerk "geholt".

Welches Sophos Interface hat denn die falsche MAC d.h. welches VLAN Interface?

Die Geräte im Netz 192.168.2.0/24 sollen die MAC-Adresse von "eth0" der Firewall für die 192.168.2.1 "bekommen".

Wenn die Geräte für die 192.168.2.1 die MAC-Adresse von "eth3" bekommen, funktioniert der Internetzugang nicht.

 

[riversource]

Es sieht so aus, als ob da deine VLAN/Routing Konfiguration nicht zusammenpasst. Die Broadcasts werden von eth3 beantwortet, aber an das IP-Netz kommt das Interface nicht ran. Ich denke, das wirst du noch strikter trennen müssen.

 

[Raijin]

Das sehe ich auch so. Wenn mehrere Interfaces desselben Geräts den Broadcast empfangen - durch eine fehlerhafte VLAN-Konfiguration - dann antworten sie auch darauf. Im Idealfall umgeht man das eben dadurch, dass Teilnehmer des 192.168.2.0/24 Subnetzes auch nur die Schnittstelle der Firewall sehen, auf der die 192.168.2.1 konfiguriert ist. Letztendlich ist das vorliegende Problem mit der Situation vergleichbar, wenn man einem Gerät auf ein und demselben Interface mehrere IP-Adressen gibt. Dies ist ja technisch möglich, weil IP-Adressen auf Layer 3 laufen und mehrere Subnetze sich dieselbe Layer 2 teilen können. In ähnlicher Form scheint das hier auch der Fall zu sein, wenn die einzelnen Schnittstellen der Firewall sich durch unsaubere Trennung der VLANs eben auch auf demselben Layer 2 Netzwerk wiederfinden. ARP ist nun mal Layer 2 und somit weitestgehend Subnetz-unabhängig, weshalb auch die anderen Schnittstellen der Firewall auf den ARP-Request antworten können.

Ich vermute mal, dass es im vorliegenden Fall an VLAN 1 liegt, das ggfs alle Ports ungeachtet ihrer VLAN-Zugehörigkeit abdeckt und somit "verbindet". Deswegen landen mutmaßlich ARP-Requests, die eigentlich innerhalb der Broadcast-Domäne der jeweiligen VLANs bleiben sollten, dort wo sie gar nicht hingehören.


Man kann Linux zwar beibringen, dass ARP-Requests nur für das empfangende Interface beantwortet werden. Dafür ist arp_ignore bzw. arp_announce verantwortlich. Eventuell kann man es auch mit arp_filter probieren. Genau kann ich das aber nicht sagen, weil ich - mit korrekter VLAN-Konfiguration - noch nicht die Notwendigkeit hatte, mich damit zu beschäftigen.

So oder so würde ich allerdings vorher versuchen, das Problem über die VLAN-Konfiguration zu lösen. Ansonsten könnten in Zukunft womöglich auch noch andere Broadcasts zum Problem werden, weil ein Broadcast als solcher ja nicht definiert was passieren soll, sondern das Protokoll, welches den Broadcast nutzt (hier: ARP). Ich weiß zB nicht wie sich DLNA-Broadcasts in solchen Fällen verhalten oder oder oder...

 

[Datax]

So oder so würde ich allerdings vorher versuchen, das Problem über die VLAN-Konfiguration zu lösen. Ansonsten könnten in Zukunft womöglich auch noch andere Broadcasts zum Problem werden, weil ein Broadcast als solcher ja nicht definiert was passieren soll, sondern das Protokoll, welches den Broadcast nutzt (hier: ARP). Ich weiß zB nicht wie sich DLNA-Broadcasts in solchen Fällen verhalten oder oder oder...

Ja, in Ordnung. Danke für die Infos.

Ich denke der Grund für diese ARP-Problematik ist der, dass letztlich "eth0" UND "eth3" im VLAN1 angeschlossen sind.

Danke an alle für die Unterstützung.

 

[Datax]

Habe die IP-Adresse 192.168.2.1 von "eth1" auf "eth3" umgezogen und "eth1" deaktiviert.

Das Problem ist gelöst. Die PCs im 192.168.2.0/24 bekommen nun immer die MAC-Adresse von "eth3" der Sophos-Firewall für die IP-Adresse 192.168.2.1 (Default-Gateway).

Der Umzug der IP-Adresse 192.168.2.1 auf "eth3" war die Lösung mit dem geringsten Aufwand. Von der Auslastung der Netzwerkkarte "eth3" her ist es nicht schlimm, dass nun ein weiteres Netz darüber läuft.