WS9 NAT-Problem - kein Kontakt zur Außenwelt

[mommi]

Hallo,

seit dem Update von WS8 auf WS9 komme ich mit dne Gästen (WinXP und auch WIN7 sowie den Linuxen SLES10 und SLES11) nicht mehr nach draußen. Ich kann nur noch den Host anpingen . Andere Rechner im Netz des Hostes oder auch im WAN kann ich nicht mal anpingengeschweige mich dort hin conncten(ssh scp). Eingesetzt wird bei allen Gästen NAT.
Bis zur WS 8.02 war das noch kein Problem. VM-WareTools sind mit WS9 aktualisiert.
Die Linuxgäste hatten bisher imer feste Adressen (wegen der Oracle-DB im Gast). Ich hatte hier auch schon mal Testweise auf DHCP umgestellt, was aber nichts gebracht hatte.
Hab ich bei mir was vermurkst und wenn ja kann mir jemand auf die Sprünge helfen.


mommi

[continuum]

Was hast du fuer einen Host ?
Laeuft der NAT-servcie ?

Sind Firewalls aktiv ?

[mommi]

Host ist WIN7 64 bit
NAT-Dienst läuft
Firewall komplett deaktiviert (für den Test) bie WS8 funkionierte es auch mit aktiver Firewall

[continuum]

Hast du es mal mit einer Knoppix LiveCD probiert ? - dabei kannst du sicher davon ausgehen dass die VM richtig konfiguriert ist

[Dayworker]

Hattest du ohne Einspielen der WS9-Tools noch eine Verbindung oder hattest du das gleich mit der Tools-Inst übersprungen?
Ersteres würde für Probleme mit den Tools sprechen, aber bei den allgegenwärtigen Problemen mit der WS9, würde ich eher die WS8 wieder installieren.

Welchen Grund gab es eigentlich für dich, auf die WS9 zu downgraden?

[mommi]

Hallo,

das mit der Knoppix-Live-CD habe ich bisher nicht probiert.

Ich habe auch noch zwei Gäste, bei denen ich die Tools noch nicht aktualisiert habe. Dort habe ich das gleiche Problem.
Die Inträge von der vmnetnat.conf sehen nach meinem bescheidenen Wissen eigentlich ganz richtig aus:
# Windows NAT configuration file
[host]
# NAT gateway address
ip = 192.168.153.2/24
hostMAC = 00:50:56:C0:00:08
# enable configuration; disabled by default for security reasons
#configport = 33445
# VMnet device if not specified on command line
device = vmnet8
# Allow PORT/EPRT FTP commands (they need incoming TCP stream...)
activeFTP = 1
# Allows the source to have any OUI. Turn this one if you change the OUI
# in the MAC address of your virtual machines.
allowAnyOUI = 1
# Controls if (TCP) connections should be reset when the adapter
# they are bound to goes down.
resetConnectionOnLinkDown = 1
# Controls if (TCP) connections should be reset when guest TCP packet's
# destination is the NAT's IP itself.
resetConnectionOnDestLocalHost = 1
[tcp]
# Value of timeout in TCP TIME_WAIT state, in seconds
timeWaitTimeout = 30
[udp]
# Timeout in seconds, 0 = no timeout, default = 30; real value might
# be up to 100% longer
timeout = 30
[dns]
# This section applies only to Windows.
#
# Policy to use for DNS forwarding. Accepted values include order,
# rotate, burst.
#
# order: send one DNS request at a time in order of the name servers
# rotate: send one DNS request at a time, rotate through the DNS servers
# burst: send to three servers and wait for the first one to respond
policy = order
# Timeout in seconds before retrying DNS request.
timeout = 2
# Retries before giving up on DNS request
retries = 3
# Automatically detect the DNS servers (not supported in Windows NT)
autodetect = 1
# List of DNS servers to use. Up to three may be specified
#nameserver1 = 198.41.0.4
#nameserver2 = 192.36.148.17
#nameserver3 = 202.12.27.33
[netbios]
# Timeout for NBNS queries.
nbnsTimeout = 2
# Number of retries for each NBNS query.
nbnsRetries = 3
# Timeout for NBDS queries.
nbdsTimeout = 3
[incomingtcp]
# Use these with care - anyone can enter into your virtual machine through these...
# FTP (both active and passive FTP is always enabled)
# ftp localhost 8887
#8887 = 192.168.27.128:21
# WEB (make sure that if you are using named webhosting, names point to
# your host, not to guest... And if you are forwarding port other
# than 80 make sure that your server copes with mismatched port
# number in Host: header)
# lynx http://localhost:8888
#8888 = 192.168.27.128:80
# SSH
# ssh -p 8889 root@localhost
#8889 = 192.168.27.128:22
[incomingudp]
# UDP port forwarding example
#6000 = 192.168.27.128:6001
[PrivilegedTCP]
autodetect = 1
[PrivilegedUDP]
autodetect = 1




auch die Netzeinstellungen des Gastes wie immer:

eth0 Link encap:Ethernet HWaddr 00:0C:29:FE:52:8A
inet addr:192.168.153.129 Bcast:192.168.153.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fefe:528a/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:100130 errors:0 dropped:0 overruns:0 frame:0
TX packets:22367 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8971791 (8.5 Mb) TX bytes:9080038 (8.6 Mb)
Base address:0x2000 Memory:e8920000-e8940000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:27040813 errors:0 dropped:0 overruns:0 frame:0
TX packets:27040813 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8129045537 (7752.4 Mb) TX bytes:8129045537 (7752.4 Mb)

gustav:~ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.153.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 192.168.153.2 0.0.0.0 UG 0 0 0 eth0
gustav:~ #


Vom Host aus kann ich auch auf den Gast per ssh, ftp, http ohne Probleme zugreifen. Aber mit dem Gast per sshoder ftp ins LAN oder WAN komme ich nicht hin. Auch die Versendung von mail per mail -s und oder auch per lp drucken auf ein Drucker im Lan geht nicht.

Ein Kollege hat auch das Update auf WS9 gemacht und hatte überhaupt kein Problem damit. Also hatte ich es mutiger Weise auch versucht. Zurück auf WS 8 möchte ich ungern, da ich schon 2 Maschinen unter WS9 gebaut habe. Ein Downgrade der HW auf WS8 wir wohl nicht gehen.

[Dayworker]

Ein Downgrade der HW auf WS8 wir wohl nicht gehen.

Die v.HW-Version zu einer niedrigeren zu ändern, geht nur manuell und ist trotzdem leicht machbar.

Ein Kollege hat auch das Update auf WS9 gemacht und hatte überhaupt kein Problem damit.

Das hilft uns nicht weiter, wir kennen weder seine noch deine SW-Config.
W7 möchte auch sämtliche Netzwerk-Interfaces als einen von 4 Netzwerktypen (Privat, Öffentlich, Abeitsplatz, Domäne) eingeordnet bekommen. Das ist bei dir erstmal nicht so wichtig, da du die FW ausgeschaltet hast.
Das es trotzdem nicht funktioniert, könnte auch mit einer Security-Suite ala Norton360 etc oder einem Mac-Filter im Router, Switch etc zusammenhängen, aber dafür lieferst du zuwenig Informationen.

[mommi]

im Einsatz ist hier Symantec Endpoint-Protection 12.1 War aber auch schon unter WS8 so. Hab ich auch schon kommplett deinstalliiert gehabt(zum Test) also Offen wie ein Scheunentor. MAC-Filter auf den Switchen gibt es nicht.
Habe es gerade zu Hause im eigenen Netz versucht, da bekomme ich Zugriff auf mein NAS und die anderen Rechner. Könnte also doch an irgendwelchen Komponenten im Büro liegen.
Eine Traceroute auf dem endetbeim Gateway des Gastes 192.168.153.2
Als ob einer den Stecker mit der WS9 rausgezogen hätte.

[Dayworker]

Wenn sich die MAC-Adresse des NAT-Interfaces beim downgrade auf die WS9 geändert hat, endet die Verbindung logischerweise bei Symantec.
Hat dein Host eigentlich neben IPv6 auch eine IPv4-Adresse?

[mommi]

eigentlich setze ich nur IPV4 ein IPV6 ist kein Thema.
Wenn es aber wegen einer geänderten MAC des NAT-Interfaces bei Symantec schluss sein soll, warum funktioniert es dann zu Hause mit dem gleichen NB.

[Dayworker]

Wenn es aber wegen einer geänderten MAC des NAT-Interfaces bei Symantec schluss sein soll, warum funktioniert es dann zu Hause mit dem gleichen NB.

NB = Notebook?
Du operierst mir mit zu vielen Unbekannten. Die WS9 ist eh schon ein Beispiel sondersgleichen für Flickschusterei im grossem Stil. Wenn du Zuhause und auf Arbeit bei gleicher HW-Ausstattung nicht genau dieselben SW-Gegebenheiten sprich gleicher Versionsnummer, Einstellungen und Updatestand hast, sind jedwede Vergleiche wenig hilfreich.
Falls es ausser der WS-Versionsänderung ansonsten nachweislich keinerlei Unterschiede an *.conf, config.ini und preferences.ini gibt, kann sich die WS9 immer noch an einer Kleinigkeit stören.

Am einfachsten lösen läßt sich das Problem vermutlich mit der Inst der WS8, aber der Fehler kann dir aufgrund der vielen, wahrscheinlich auch undokumentierten Änderungen jetzt auch damit passieren.
Was also ändert sich sonst noch an Hard- und Software zwischen beiden Standorten? Dazu zählen sowohl die NB-Dockingstation als auch jedwede Ersatz- bzw Zusatz-SW für die ach so bösen M$-Beigaben und die beteiligten IP-Konfigurationen. Ist das vielleicht ein HP-Gerät? Läuft darauf ein Prozeß namens Camera.exe?

Wir brauchen mehr Input.


[add]
Schau dir mal exemplarisch How to install Workstation 7 and VMplayer 3 on Windows an. Am Umfang dessen siehst du mal, was alles bei der Inst schon schiefgehen kann und das wird mit WS8 oder 9 eher noch schlimmer.

[mommi]

Nun ja, da bin ich ein wenig blauäugig an das Update rangegangen. Bisher hatte ich nur von der Version 4 zu 5 einmal Stress beim Update gehabt. Damals hatte ich mir die Gäste völlig zerschossen. Seit dem war ich immer ohne Problem durchgekommen.
Als Hardware wird hier ein Notebook Fujitsu Celsius H710 eingesetzt. Hoste ist Win64Bit Enterprise.
Im Büro ist Dockinstation vorhanden, Zuhause nicht.Das kann ich aber erst in der nächsten Woche ohne Dockingstation mal probieren.

Ich würde den Downgrade zur WS8 als erstes mal versuchen.
Die Gäste, die ich mit den aktuellen VM-Tools versorgt habe, würde ich vor dem Downgrade die Tools deinstallieren und dann unter Version 8 wieder installieren.

Was muss ich mit dem Gast den ich unter WS9 erstellt habe anstellen (Gast-OS WIN 7 64Bit)?

[Dayworker]

Laß erstmal die Finger von den Tools, denen wird nicht nur nach VMwares Meinung viel zuviel Aufmerksamkeit geschenkt. Solange du überhaupt irgendwelche VMware-Tools installiert hast, sind bereits alle üblichen Features aktiv und unter Umständen verlierst du auch einige Features mit anderen Tools-Versionen. Die Meldung über die veraltete Tools-Version läßt sich auch unterdrücken und bei allen M$-OS mit Aktivierungszwang würde ich abseits einer Firmen- oder Enterprise-Lizenz sowieso von dieser dauernden Tools-Inst/DeInst absehen. Die HW ändert sich grundlegend und aufgrund dessen wird immer eine Neuaktivierung fällig. Daher installiert man die Tools einmal, schaltet dann auf manuelles Tools-Update und aktiviert erst dann das aktivierungspflichtige M$-OS.
Du mit einer Enterprise-Lizenz bist da aktivierungstechnisch fein raus. Daß ändert aber trotzdem nichts daran, daß jede SW-Inst bzw -Deinstallation auch mal schief laufen kann und ein nichtstartendes System hinterläßt.

Hat die Dockingstation ihren eigenen Netzwerkchip?
Hast du dieses "Autom.Bridging" alias "Autodetect" im "VMware Network Editor" deaktiviert?
Welchem Netzwerkinterface (Lan, Wlan) wurde der VMware-Bridge-Adapter alias "vmnet0" zugewiesen?

Ausgehend von Virtual machine hardware versions sollte die WS8 mit der v.HW-Version 8 klarkommen. Wenn du die statt der 9 in die VMX und VMDK einträgst, startet die VM wieder mit der älteren HW-Version. Das dadurch wieder die HW-Erkennung in Windows durchläuft, sollte dir klar sein und eine vorher angelegte Kopie des gesamten VM-Ordners bewahrt dich vor Problemen.


PS: Beim vDISK-Typ "single growable virtual disk" ist ausserdem noch etwas Vorarbeit mit dem "vmware-vdiskmanager" nötig, da die mitwachsende vDISK mitsamt ihren Parametern in der einzelnen VMDK steckt. Bei allen anderen vDISK-Typen gibt es immer noch eine kleine, wenige KByte-grosse Beschreibungs-VMDK.

[Dayworker]

[incomingtcp]
# Use these with care - anyone can enter into your virtual machine through these...
# FTP (both active and passive FTP is always enabled)
# ftp localhost 8887
#8887 = 192.168.27.128:21
# WEB (make sure that if you are using named webhosting, names point to
# your host, not to guest... And if you are forwarding port other
# than 80 make sure that your server copes with mismatched port
# number in Host: header)
# lynx http://localhost:8888
#8888 = 192.168.27.128:80
# SSH
# ssh -p 8889 root@localhost
#8889 = 192.168.27.128:22

In deiner NAT.conf ist SSH noch deaktiviert, daher kann von aussen niemand zugreifen. Das es vom Host aus trotzdem funktioniert, liegt entweder an Host-only oder der Realisierung der VMware-Netzwerkinterfaces über den Promiscuous-mode der pNic.
Das die VM auf einem ESX(i) keine Probleme macht, ist auch logisch, da es dort kein NAT-Interface gibt und stattdessen die Bridge als VMware-Interface genutzt wird.