5
Windows 7 schickt alle Pakete durchs Gateway
Ein Client mit Windows 7 x64 schickt seit neuestem *alle* Pakete durch das eingestellte Standardgateway, auch zu solchen Adressen, die im gleichen Subnet liegen.
Hallo zusammen,
wie oben angedeutet schickt der Win7-Client alle Pakete - auch zu Adressen, die im gleichen Subnet liegen - durch das Standardgateway.
Warum er das tut, habe ich bisher leider nicht herausgefunden, die Routingtabelle sieht für mich eigentlich so aus, wie sie aussehen sollte - zumindest sind da keine Abweichungen zu einem anderen Client, der dieses Verhalten nicht zeigt:
Etwas zur Konfiguration:
Der Client hat eine reale Netzwerkkarte mit der statisch zugewiesenen IP 192.168.0.10/24, Standardgateway ist 192.168.0.3.
Wenn ich nun auf einen Rechner mit der IP 192.168.0.7 zugreife, werden alle Pakete durch das Gateway geschickt, was erstens das Gateway unnötig belastet und zweitens natürlich auf die Geschwindigkeit drückt.
Die IP-Konfiguration sieht so aus - für mich eigentlich auch alles im Grünen Bereich:
Hier mal ein Traceroute:
Die Schnittstelle habe ich testweise einfach mal neu konfiguriert und neu installiert, in der Hoffnung irgendwelche falschen Einträge zu löschen, geholfen hat es bisher aber nicht.
Hat jemand einen heißen Tipp für mich?
DANKE!!!
Hallo zusammen,
wie oben angedeutet schickt der Win7-Client alle Pakete - auch zu Adressen, die im gleichen Subnet liegen - durch das Standardgateway.
Warum er das tut, habe ich bisher leider nicht herausgefunden, die Routingtabelle sieht für mich eigentlich so aus, wie sie aussehen sollte - zumindest sind da keine Abweichungen zu einem anderen Client, der dieses Verhalten nicht zeigt:
===========================================================================
Schnittstellenliste
15...00 ff e8 0c 40 1f ......TAP-Win32 Adapter V9
11...00 22 15 6c af c1 ......Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller
20...08 00 27 00 fc f8 ......VirtualBox Host-Only Ethernet Adapter
1...........................Software Loopback Interface 1
13...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter
14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
16...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #2
21...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #3
===========================================================================
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.3 192.168.0.10 276
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
169.254.0.0 255.255.0.0 Auf Verbindung 169.254.11.241 276
169.254.11.241 255.255.255.255 Auf Verbindung 169.254.11.241 276
169.254.255.255 255.255.255.255 Auf Verbindung 169.254.11.241 276
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.10 276
192.168.0.10 255.255.255.255 Auf Verbindung 192.168.0.10 276
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.10 276
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 169.254.11.241 276
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.10 276
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 169.254.11.241 276
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.10 276
===========================================================================
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
0.0.0.0 0.0.0.0 192.168.0.3 Standard
===========================================================================
IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
11 276 ::/0 2a02:a00:e000:b:8000::2
11 276 ::/0 fe80::222:2dff:fe27:76d5
1 306 ::1/128 Auf Verbindung
11 28 2a02:a00:e000:b:8000::/65
Auf Verbindung
11 276 2a02:a00:e000:b:8000::d00f/128
Auf Verbindung
20 276 fe80::/64 Auf Verbindung
11 276 fe80::/64 Auf Verbindung
20 276 fe80::6c14:2125:bc61:bf1/128
Auf Verbindung
11 276 fe80::6c67:80b2:a5f1:bbfc/128
Auf Verbindung
1 306 ff00::/8 Auf Verbindung
20 276 ff00::/8 Auf Verbindung
11 276 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
If Metrik Netzwerkziel Gateway
0 4294967295 ::/0 2a02:a00:e000:b:8000::2
===========================================================================Etwas zur Konfiguration:
Der Client hat eine reale Netzwerkkarte mit der statisch zugewiesenen IP 192.168.0.10/24, Standardgateway ist 192.168.0.3.
Wenn ich nun auf einen Rechner mit der IP 192.168.0.7 zugreife, werden alle Pakete durch das Gateway geschickt, was erstens das Gateway unnötig belastet und zweitens natürlich auf die Geschwindigkeit drückt.
Die IP-Konfiguration sieht so aus - für mich eigentlich auch alles im Grünen Bereich:
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : Max
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
Ethernet-Adapter LAN-Verbindung 2:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9
Physikalische Adresse . . . . . . : 00-FF-E8-0C-40-1F
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Ethernet-Adapter LAN-Verbindung:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller
Physikalische Adresse . . . . . . : 00-22-15-6C-AF-C1
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : 2a02:a00:e000:b:8000::d00f(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80::6c67:80b2:a5f1:bbfc%11(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.0.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 2a02:a00:e000:b:8000::2
fe80::222:2dff:fe27:76d5%11
192.168.0.3
DNS-Server . . . . . . . . . . . : 192.168.0.3
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter VirtualBox Host-Only Network:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
Physikalische Adresse . . . . . . : 08-00-27-00-FC-F8
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::6c14:2125:bc61:bf1%20(Bevorzugt)
IPv4-Adresse (Auto. Konfiguration): 169.254.11.241(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 319291431
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-11-6A-53-A6-00-22-15-6C-AF-C1
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Tunneladapter isatap.{E80C401F-07A4-45F0-B609-4424DBE86937}:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Tunneladapter Teredo Tunneling Pseudo-Interface:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Tunneladapter isatap.{70E35D64-F2C1-4282-9F34-CB774D7F6511}:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Tunneladapter isatap.{7E67FA66-990E-403F-B875-92E7EF0CFA00}:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : JaHier mal ein Traceroute:
Routenverfolgung zu 192.168.0.7 über maximal 30 Abschnitte
1 <1 ms <1 ms <1 ms 192.168.0.3
2 <1 ms <1 ms <1 ms 192.168.0.7
Ablaufverfolgung beendet.Die Schnittstelle habe ich testweise einfach mal neu konfiguriert und neu installiert, in der Hoffnung irgendwelche falschen Einträge zu löschen, geholfen hat es bisher aber nicht.
Hat jemand einen heißen Tipp für mich?
DANKE!!!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 142567
Url: https://administrator.de/forum/windows-7-schickt-alle-pakete-durchs-gateway-142567.html
Ausgedruckt am: 10.05.2025 um 19:05 Uhr
5 Kommentare
Neuester Kommentar
Hat es einen bestimmten Grund, warum Du eine ständige Route eingetragen hast, die den selben Inhalt hat wie die erste dynamische? Ich habe solch eine Route nämlich nicht und mir fällt gerade auch nicht ein, wozu die gut sein könnte - aber wie gesagt hast Du ja vielleicht eine Erklärung?!
Was mir außerdem noch auffällt ist, dass die Metrik der dynamischen Gateway-Route bei mir deutlich kleiner ist. Hängst Du hinter vielen Switches? (Gut, eigentlich spricht die hohe Metrik ja gerade nicht dafür, dass die Pakete standardmäßig durchs GW sollen...)
Gruß, kingkong
Was mir außerdem noch auffällt ist, dass die Metrik der dynamischen Gateway-Route bei mir deutlich kleiner ist. Hängst Du hinter vielen Switches? (Gut, eigentlich spricht die hohe Metrik ja gerade nicht dafür, dass die Pakete standardmäßig durchs GW sollen...)
Gruß, kingkong
Woher weisst du denn das der Rechner alle Pakete an lokale Hostadressen immer an das Gateway schickt ???
Hast du das mit einem Wireshark Sniffer auch wirklich mitgesniffert ??? Wenn nicht, ist das ja nur wilde Spekulation, denn das würde der korrekten Funktion eines TCP/IP Stacks vollkommen widersprechen.
Normalerweise sendet der Client 192.168.0.10 zuallererst einen ARP Request an die 192.168.0.7, was du im Sniffer auch sehen solltest. Damit bekommt der die Layer 2 Adresse (Mac) die für die Ethernet Kommunikation mit der Hostadresse 192.168.0.7 ja relevant ist von diesem Client. Danach initiiert er dann über die MAC Adressen eine TCP oder UDP Session je nach Dienst.
Auch wenn er das Paket an das Gateway 192.168.0.3 schickt (er ARPt dann dieses) schickt das Gateway ihm sofort ein ICMP Redirect Paket (Typ 5) zurück und spätestens dann ist die Kommunikation immer lokal.
Würde deine Behauptung von oben also stimmen, dann wäre der gesamte Stack in der grundlegenden Kommunikation vermurkst.
Poste also mal den Verbindungsaufbau von 192.168.0.10 und 192.168.0.7 als Wireshark PCAP Output hier und dann sehen wir mal ob du wirklich recht hast !!!
Das kannst du z.B. mal schnell machen wenn du auf dem 192.168.0.7 Client einen kleinen Webserver_wie_HFS einfach als Datei startest und von 192.168.0.10 eine Browsersession auf ihn öffnest.
ARP Request, Reply und TCP SYN (4 Pakete Trace) die kannst du dann mal posten hier... !
Hast du das mit einem Wireshark Sniffer auch wirklich mitgesniffert ??? Wenn nicht, ist das ja nur wilde Spekulation, denn das würde der korrekten Funktion eines TCP/IP Stacks vollkommen widersprechen.
Normalerweise sendet der Client 192.168.0.10 zuallererst einen ARP Request an die 192.168.0.7, was du im Sniffer auch sehen solltest. Damit bekommt der die Layer 2 Adresse (Mac) die für die Ethernet Kommunikation mit der Hostadresse 192.168.0.7 ja relevant ist von diesem Client. Danach initiiert er dann über die MAC Adressen eine TCP oder UDP Session je nach Dienst.
Auch wenn er das Paket an das Gateway 192.168.0.3 schickt (er ARPt dann dieses) schickt das Gateway ihm sofort ein ICMP Redirect Paket (Typ 5) zurück und spätestens dann ist die Kommunikation immer lokal.
Würde deine Behauptung von oben also stimmen, dann wäre der gesamte Stack in der grundlegenden Kommunikation vermurkst.
Poste also mal den Verbindungsaufbau von 192.168.0.10 und 192.168.0.7 als Wireshark PCAP Output hier und dann sehen wir mal ob du wirklich recht hast !!!
Das kannst du z.B. mal schnell machen wenn du auf dem 192.168.0.7 Client einen kleinen Webserver_wie_HFS einfach als Datei startest und von 192.168.0.10 eine Browsersession auf ihn öffnest.
ARP Request, Reply und TCP SYN (4 Pakete Trace) die kannst du dann mal posten hier... !
@kingkong:
Also ich habe nichts eingetragen, werde aber mal versuchen, die Route zu löschen.
Leider habe ich den Rechner gerade nicht vor mir und per Fernwartung komme ich auch im Moment nicht drauf.
@aqui:
Ich weiß es daher, weil das Gateway mir mit iptraf mitteilt, dass es Daten von 192.168.0.10 nach 192.168.0.7 schaufelt
Es gab ja keine wirklichen Probleme, denn der Rechner konnte ja wunderbar mit anderen kommunizieren, nur haben wir uns gewundert, warum das Gateway manchmal so 80-90 MBit/s durch die Gegend gepöngelt hat und die Latenzzeiten ins Internet so plötzlich hochgingen
Aber danke für die Tipps, ich werde mich mal mit Wireshark dranhängen und den gesamten Verkehr mitlesen.
Also ich habe nichts eingetragen, werde aber mal versuchen, die Route zu löschen.
Leider habe ich den Rechner gerade nicht vor mir und per Fernwartung komme ich auch im Moment nicht drauf.
@aqui:
Ich weiß es daher, weil das Gateway mir mit iptraf mitteilt, dass es Daten von 192.168.0.10 nach 192.168.0.7 schaufelt
Es gab ja keine wirklichen Probleme, denn der Rechner konnte ja wunderbar mit anderen kommunizieren, nur haben wir uns gewundert, warum das Gateway manchmal so 80-90 MBit/s durch die Gegend gepöngelt hat und die Latenzzeiten ins Internet so plötzlich hochgingen
Aber danke für die Tipps, ich werde mich mal mit Wireshark dranhängen und den gesamten Verkehr mitlesen.
Es ist möglich das du am Gateway oder an den beteiligten Engeräten ICMP Redirect (Typ 5)
http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol
deaktiviert hast.
(Bei Winblows heisst das in den ICMP Eigenschaften der Firewall "Umleitungen zulassen") Bei Winblows ist das in der Regel immer unsinnigerweise deaktiviert.
Dann kann es natürlich solche lokalen Umwege geben wenn es mehrere lokale Router geben sollte... Das solltest du also auch nochmal kontrollieren ob dem so ist !!
http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol
deaktiviert hast.
(Bei Winblows heisst das in den ICMP Eigenschaften der Firewall "Umleitungen zulassen") Bei Winblows ist das in der Regel immer unsinnigerweise deaktiviert.
Dann kann es natürlich solche lokalen Umwege geben wenn es mehrere lokale Router geben sollte... Das solltest du also auch nochmal kontrollieren ob dem so ist !!
Exakt das scheint es gewesen zu sein - jedenfalls gehen die Pakete nun direkt durch... Zumindest taucht das Gateway nirgendwo mehr über Wireshark auf.
Die Firewall hatte ich überhaupt nicht im Verdacht, da diese normalerweise deaktiviert ist und überhaupt nicht zur Windows-Firewall gepasst hätte, dass sie etwas zuverlässig blockt.
Irgendein obskures Update scheint die Firewall wohl wieder aktiviert zu haben.
Ich habe jetzt sämtliche Protokolle freigegeben, die Firewall erneut ausgeschaltet und hoffe mal, dass das so bleibt.
Danke!
Die Firewall hatte ich überhaupt nicht im Verdacht, da diese normalerweise deaktiviert ist und überhaupt nicht zur Windows-Firewall gepasst hätte, dass sie etwas zuverlässig blockt.
Irgendein obskures Update scheint die Firewall wohl wieder aktiviert zu haben.
Ich habe jetzt sämtliche Protokolle freigegeben, die Firewall erneut ausgeschaltet und hoffe mal, dass das so bleibt.
Danke!
