14
Falsche MAC-Adresse für das Default-Gateway im ARP-Cache
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:CC:DD: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:CC:DD: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:CC:DD: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 enthält, die gar nicht die IP-Adresse 192.168.2.1 konfiguriert hat.
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.
Datax
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:CC:DD: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:CC:DD: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:CC:DD: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 enthält, die gar nicht die IP-Adresse 192.168.2.1 konfiguriert hat.
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.
Datax
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 61798357126
Url: https://administrator.de/contentid/61798357126
Printed on: April 28, 2024 at 04:04 o'clock
14 Comments
Latest comment
Da "die beste Route" je nach Einstellung über entsprechende Protokolle den jeweiligen Nachbarn mitgeteilt wird ...
... würde ich von einer Fehlkonfiguration ausgehen ... mutmaßlich in der Sopjos-Firewall ...
... oder im nächsten routenden Switch/Router
Sind ETH1 und ETH3 am selben Switch angeschlossen, deutet das auf eine fehlerhafte VLAN-Konfiguration hin ...
Genaueres werden dir sicher unsere Spezis hier schreiben, evtl. solltest du ein Netzwerkdiagram posten ...
... würde ich von einer Fehlkonfiguration ausgehen ... mutmaßlich in der Sopjos-Firewall ...
... oder im nächsten routenden Switch/Router
Sind ETH1 und ETH3 am selben Switch angeschlossen, deutet das auf eine fehlerhafte VLAN-Konfiguration hin ...
Genaueres werden dir sicher unsere Spezis hier schreiben, evtl. solltest du ein Netzwerkdiagram posten ...
Es ist sehr wahrscheinlich kein grundsätzlicher Fehler der Firewall selber sondern deiner Layer 2 Infrastruktur wie ein ähnlicher Thread in der Sophos Knowledgebase zeigt:
https://community.sophos.com/utm-firewall/f/management-networking-loggin ...
Vermutlich ist irgendwo in deinem Netzwerk ein Fehler bei der Trennung der Layer 2 Broadcasts Domains zwischen eth1 und eth3 Interface passiert.
Häufig liegt das in einem Patching Fehler das eine Layer 2 Domain über eine irgendwie geartete Bridge oder falsches VLAN versehentlich zusammengesteckt wurde. Außer Patching Fehler kann es auch andere Gründe haben wie einen unsauberer Link Aggregation Trunk der zyklisch solche Broadcasts in andere L2 Segmente forwardet. Das kann man aber jetzt nur raten, da du nicht genauer beschreibst was an diesen Interfaces liegt.
Vermutlich sorgen dann durch diesen Effekt irrtümlich geflutete Spanning Tree BPDUs dafür das intermittierend hie und da mal Ports in den Blocking Mode gehen was dann auch die wechselnde Funktion erklären würde das es mal geht und mal nicht.
Da musst du also nochmal im L2 Setup genau hinsehen...
https://community.sophos.com/utm-firewall/f/management-networking-loggin ...
Vermutlich ist irgendwo in deinem Netzwerk ein Fehler bei der Trennung der Layer 2 Broadcasts Domains zwischen eth1 und eth3 Interface passiert.
Häufig liegt das in einem Patching Fehler das eine Layer 2 Domain über eine irgendwie geartete Bridge oder falsches VLAN versehentlich zusammengesteckt wurde. Außer Patching Fehler kann es auch andere Gründe haben wie einen unsauberer Link Aggregation Trunk der zyklisch solche Broadcasts in andere L2 Segmente forwardet. Das kann man aber jetzt nur raten, da du nicht genauer beschreibst was an diesen Interfaces liegt.
Vermutlich sorgen dann durch diesen Effekt irrtümlich geflutete Spanning Tree BPDUs dafür das intermittierend hie und da mal Ports in den Blocking Mode gehen was dann auch die wechselnde Funktion erklären würde das es mal geht und mal nicht.
Da musst du also nochmal im L2 Setup genau hinsehen...
Zitat von @aqui:
Es ist sehr wahrscheinlich kein grundsätzlicher Fehler der Firewall selber sondern deiner Layer 2 Infrastruktur wie ein ähnlicher Thread in der Sophos Knowledgebase zeigt:
https://community.sophos.com/utm-firewall/f/management-networking-loggin ...
Vermutlich ist irgendwo in deinem Netzwerk ein Fehler bei der Trennung der Layer 2 Broadcasts Domains zwischen eth1 und eth3 Interface passiert.
Es ist sehr wahrscheinlich kein grundsätzlicher Fehler der Firewall selber sondern deiner Layer 2 Infrastruktur wie ein ähnlicher Thread in der Sophos Knowledgebase zeigt:
https://community.sophos.com/utm-firewall/f/management-networking-loggin ...
Vermutlich ist irgendwo in deinem Netzwerk ein Fehler bei der Trennung der Layer 2 Broadcasts Domains zwischen eth1 und eth3 Interface passiert.
Werde mir die VLAN-Konfiguration auf den Switchen mal anschauen.
Verstehe aber trotzdem nicht, warum dann auf einen ARP-Request für die IP-Adresse 192.168.2.1 eine falsche MAC-Adresse "gelernt" wird.
Selbst wenn 2 VLANs miteinander verbunden sind, sollte doch nur das Gerät sich mit seiner MAC-Adresse melden,
das auch wirklich die 192.168.2.1 anliegen hat oder nicht!?
Was ich mir vorstellen kann, ist, dass die Sophos-Firewall die ARP-Requests für die 192.168.2.1 über 2 Netzwerkkarten empfängt und dann erkennt, dass sie ja selbst das Gerät mit der 192.168.2.1 ist und dann einfach mit der MAC-Adresse der Netzwerkkarte antwortet, über die sie den ARP-Request empfangen hat. Also ohne zu prüfen, ob sie auch wirklich mit der MAC-Adresse der Netzwerkkarte antwortet, auf der auch wirklich die 192.168.2.1 konfiguriert ist (eth3). Sieht für mich stark danach aus. Sie empfängt den ARP-Request über beide Netzwerkkarten (eth1 + eth3) und antwortet mal mit der MAC-Adresse von "eth1" und mal mit der MAC-Adresse von "eth3".
Und das wiederum spricht dafür, was du bereits geschrieben hast. Dass "eth1" und "eth3" auf Layer-2 verbunden sind.
Danke schon mal für die Infos
.
Toben in deinem Netzwerk zufällig irgendwelche Stürme? Auch wellenartig?
ART Stürme?
Broadcast Stürme?
Ist die Sophos ein HA-Mitglied?
ART Stürme?
Broadcast Stürme?
Ist die Sophos ein HA-Mitglied?
ART Stürme??? 🤔
Ist das Kunst oder kann das weg...?! Heute ist ja Freitag... 🐟
Liegen eth1 und eth3 fälschlicherweise in einer gemeinsamen L2 Domain antwortet die Sophos mit beiden Interfaces/Macs auf einen ARP Requests. Dann kommt es zu einer Race Condition und der Letzte oder Schnellste gewinnt.
Deine Option mit dem Empfang über 2 NICs wäre auch eine denkbare Möglichkeit. Letztlich aber, wie du auch sagst, wieder ein Indiz für eine unsaubere Layer 2 Trennung irgendwo im Netz.
Interessant wäre es sicher einmal wenn man an einem dieser betroffenen Clients einmal einen Wireshark Trace so eines fehlgelaufenen ARP Requests mitsniffen könnte. Sicherlich kein leichtes Unterfangen wenn es nur sporadisch auftritt und nicht reproduzierbar ist.
Vielleicht könntest du es versuchen zu provozieren indem du zyklisch den ARP Cache mit arp -d löschst und z.B. neu pingst.
Ist das Kunst oder kann das weg...?! Heute ist ja Freitag... 🐟
eine falsche MAC-Adresse "gelernt" wird.
Wenn du den Sophos KB Artikel gelesen hättest steht es da. Liegen eth1 und eth3 fälschlicherweise in einer gemeinsamen L2 Domain antwortet die Sophos mit beiden Interfaces/Macs auf einen ARP Requests. Dann kommt es zu einer Race Condition und der Letzte oder Schnellste gewinnt.
Deine Option mit dem Empfang über 2 NICs wäre auch eine denkbare Möglichkeit. Letztlich aber, wie du auch sagst, wieder ein Indiz für eine unsaubere Layer 2 Trennung irgendwo im Netz.
Interessant wäre es sicher einmal wenn man an einem dieser betroffenen Clients einmal einen Wireshark Trace so eines fehlgelaufenen ARP Requests mitsniffen könnte. Sicherlich kein leichtes Unterfangen wenn es nur sporadisch auftritt und nicht reproduzierbar ist.
Vielleicht könntest du es versuchen zu provozieren indem du zyklisch den ARP Cache mit arp -d löschst und z.B. neu pingst.
ARP Stürme.
Du Clown.
Du Clown.
Wenn es das war bitte nicht vergessen deinen Thread hier als erledigt zu markieren!
Habe mal eine Zeichnung gemacht, damit man den Netzwerkaufbau besser verstehen kann.
In der Port-Group A, an die "eth0" angeschlossen ist, ist keine VLAN-ID angegeben. "eth0" ist
auf der Sophos-Firewall eine ganz "normale" (Untagged)-Netzwerkschnittstelle.
Wenn ich mich nun per "SSH" mit dem Aruba-Switch verbinde, dann kann ich die MAC-Adresse
von "eth3" (MAC-Adresse=GG:HH:II:JJ:KK:LL) im VLAN1 sehen, was meiner Meinung nach nicht sein dürfte.
Ich gebe also folgenden Befehl ein:
show mac-address GG:HH:II:JJ:KK:LL (MAC-Adresse von "eth3")
Die Ausgabe ist dann:
1/A1 VLAN1
1/A1 VLAN5
1/A1 VLAN6
1/A1 VLAN7
Die MAC-Adresse von "eth0" (MAC-Adresse= AA:BB:CC:DD:EE:FF) ist nur im VLAN1 sichtbar,
was ja richtig ist.
show mac-address AA:BB:CC:DD:EE:FF
Die Ausgabe ist dann:
1/A1 VLAN1
Auf der Netzwerkkarte "eth0" ist die IP-Adresse 192.168.2.1/24 konfiguriert. Diese IP ist das Gateway
für die PCs, die sporadisch keinen Internetzugang haben, weil sie dann die MAC-Adresse von
"eth3" der Firewall im ARP-Eintrag für die 192.168.2.1 eingetragen haben.
In der Port-Group A, an die "eth0" angeschlossen ist, ist keine VLAN-ID angegeben. "eth0" ist
auf der Sophos-Firewall eine ganz "normale" (Untagged)-Netzwerkschnittstelle.
Wenn ich mich nun per "SSH" mit dem Aruba-Switch verbinde, dann kann ich die MAC-Adresse
von "eth3" (MAC-Adresse=GG:HH:II:JJ:KK:LL) im VLAN1 sehen, was meiner Meinung nach nicht sein dürfte.
Ich gebe also folgenden Befehl ein:
show mac-address GG:HH:II:JJ:KK:LL (MAC-Adresse von "eth3")
Die Ausgabe ist dann:
1/A1 VLAN1
1/A1 VLAN5
1/A1 VLAN6
1/A1 VLAN7
Die MAC-Adresse von "eth0" (MAC-Adresse= AA:BB:CC:DD:EE:FF) ist nur im VLAN1 sichtbar,
was ja richtig ist.
show mac-address AA:BB:CC:DD:EE:FF
Die Ausgabe ist dann:
1/A1 VLAN1
Auf der Netzwerkkarte "eth0" ist die IP-Adresse 192.168.2.1/24 konfiguriert. Diese IP ist das Gateway
für die PCs, die sporadisch keinen Internetzugang haben, weil sie dann die MAC-Adresse von
"eth3" der Firewall im ARP-Eintrag für die 192.168.2.1 eingetragen haben.
Falls dir aufgefallen ist, dass Multi-Interface-Router in verschiedenen Vlans die selbe Mac haben, dann ist das nicht ungewöhnlich.
Der böse Buhmann ist sehr wahrscheinlich der vSwitch mit einer fehlerhaften Einstellung des Promiscous Mode oder Mac Isolation.
https://kb.vmware.com/s/article/1002934
Geraten sieht das nach ESXi aus.
Es wäre zudem besser von der Konfig den vSwitch immer mit dedizierten VLAN Tags für die VMs zu konfigurieren als mit 4095 zu arbeiten!
Siehe dazu HIER und auch HIER.
https://kb.vmware.com/s/article/1002934
Geraten sieht das nach ESXi aus.
Es wäre zudem besser von der Konfig den vSwitch immer mit dedizierten VLAN Tags für die VMs zu konfigurieren als mit 4095 zu arbeiten!
Siehe dazu HIER und auch HIER.
Zitat von @aqui:
Der böse Buhmann ist sehr wahrscheinlich der vSwitch mit einer fehlerhaften Einstellung des Promiscous Mode oder Mac Isolation.
https://kb.vmware.com/s/article/1002934
Geraten sieht das nach ESXi aus.
Der böse Buhmann ist sehr wahrscheinlich der vSwitch mit einer fehlerhaften Einstellung des Promiscous Mode oder Mac Isolation.
https://kb.vmware.com/s/article/1002934
Geraten sieht das nach ESXi aus.
Ja, okay. Das werde ich prüfen.
Den "Promiscous Mode" muss ich dann bei dem betreffenden vSwitch deaktivieren, richtig?
Es wäre zudem besser von der Konfig den vSwitch immer mit dedizierten VLAN Tags für die VMs zu konfigurieren als mit 4095 zu arbeiten!
Siehe dazu HIER und auch HIER.
Siehe dazu HIER und auch HIER.
Ja, da hast du Recht.
Wie kann man das denn umstellen?
In einer Port-Group kann man meines Wissens immer nur eine einzelne VLAN-ID angeben.
Korrigiere mich gerne falsch ich damit falsch liege. ^^
Danke schon mal für die Infos
.Wie kann man das denn umstellen?
Einfach einmal die beiden dir geposteten Links klicken und die Screenshots ansehen! 😉In einer Port-Group kann man meines Wissens immer nur eine einzelne VLAN-ID angeben
Das ist richtig.
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.
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.
1
