VMware-Forum

Sehr geehrte Damen und Herren,
seit einigen Tage nutze ich VMware Workstation (15.5.6 build-16341506) auf meinem PC (windows 10 x64, 32 GB Ram, 16 Kerne)
und habe in meiner virtuellen Umgebung Kali Linux (Debian 10 x64) aus beruflichen Gründen laufen, welches über das VMware NAT an
das lokale Lan angebunden ist.
Leider fällt immer nach einiger Zeit die Netzwerkfunktionalität bei einiger Auslastung (z.B. div. Portscans) flach und auch einfache Pings funktionieren nicht mehr.
Wenn ich den VMware Nat Dienst neustarte geht es wieder einige Zeit. Von daher vermute ich, dass der Fehler irgendetwas mit Timeouts oder einer vollen NAT-Tabelle zu tun hat. Wie kann ich das troubleshooten ? Gibt es irgendwelche Logs ? Kann ich Timeouts anpassen oder die NAT Tabelle manuell erweitern ? Oder liegt der Fehler vlt irgendwo ganz anders ?

Die häufigsten Probleme sind:

• 2 oder mehr NICs im Host/Wirt stecken und nur 1 ist mit einem Router verbunden
• bei 2 oder mehr NICs überläßt man VMware trotzdem das Auto-Bridging zu übernehmen
• in Sec-Suite/Antivirus wurden keine Ausnahmen sowohl für den VMware-Programmeordner als auch VMDK-Dateien angelegt

Die Punkte 1 und 2 kannst du in der WS ganz einfach über den VMware-Netzwerk-Editor (vmnetcfg.exe) einstellen, sollte auch in der aktuelle Version einen eigenen Win-Startmenueintrag haben und in der WS gibt es auch einen Menupunkt zu den Netzwerkeinstellungen. Die voreingestellten VMnet0 (Bridge), VMnet1 (Host-only) und VMnet8 (VMware-NAT) würde ich nicht bzw ggf (VMnet1 und VMnet8) nur den genutzten IP-Bereich ändern. Die erste und für die Funktion des VMware-Netzwerks wichtigste NIC weist man manuell dem VMnet0 und alle weiteren NIC entsprechend einem noch unbenutzen VMnetX zwischen 2 bis 7 und 9 bis je nach WS-Version fast unbegrenzt zu. Es besteht also inzwischen kein Grund mehr, die voreingestellten VMnetX zu verstellen. Hintergrund ist, daß in der VMware-Welt beim Sprechen über "Host-only" und "VMware-NAT" immer von den dafür voreingestellten VMnetX ausgegangen wird.
Die erste NIC ist deshalb so wichtig, weil es in der WS keine feste Reihenfolge der NICs gibt. Landet eine NIC im Offline-Zustand auf dem VMnet0, stottert die ganze VMware-Netzwerkumgebung. Deshalb überläßt man VMware bei mehr als einer NIC im Host nicht mehr die Zuweisung zu den VMnetX.

Bei mehr als einer NIC im Host gibt es eine zusätzliche Besonderheit und zwar wenn die VMware-Bridge (VMnet0) eingesetzt werden soll. In diesem Fall weist man allen VMs gleich das Custom-Interface zu und kann dann im sich darunter öffnenden Menu das gewünschte VMnetX auswählen. Andernfalls könnte eine VM im falschen Subnetz arbeiten.

Die Portscans von nmap haben unter Umständen ein aggressives Timing (Pakete/s) und wenn zusätzlich der zu scannende Bereich (Anzahl der Hosts) nicht klein ist, dann können locker mehrere Tausend "Verbindungen" entstehen, die der arme NAT-Dienst der Workstation alle im Speicher halten soll.

Keine wirklich gute Idee.

hilmbert hat geschrieben:Sehr geehrte Damen und Herren,
seit einigen Tage nutze ich VMware Workstation (15.5.6 build-16341506) auf meinem PC (windows 10 x64, 32 GB Ram, 16 Kerne)
und habe in meiner virtuellen Umgebung Kali Linux (Debian 10 x64) aus beruflichen Gründen laufen, welches über das VMware NAT an
das lokale Lan angebunden ist.
Leider fällt immer nach einiger Zeit die Netzwerkfunktionalität bei einiger Auslastung (z.B. div. Portscans) flach und auch einfache Pings funktionieren nicht mehr.
Wenn ich den VMware Nat Dienst neustarte geht es wieder einige Zeit. Von daher vermute ich, dass der Fehler irgendetwas mit Timeouts oder einer vollen NAT-Tabelle zu tun hat. Wie kann ich das troubleshooten ? Gibt es irgendwelche Logs ? Kann ich Timeouts anpassen oder die NAT Tabelle manuell erweitern ? Oder liegt der Fehler vlt irgendwo ganz anders ?

Hallo,
warum überhaupt NAT?
Kali genatted in einem Netzwerk für bei uns, sofern nicht abgesprochen, für mächtig Ärger sorgen.
Gruß