VMware-Forum

Hallo
ich habe folgendes Problem und hoffe hier den entscheidenden Tip zu bekommen. Inzwischen versuche ich schon mehrere Tage auf einen grünen Zweig zu kommen, allerdings ohne erfolgt.
Eckdaten:
Host OS Version: Windows 7 Enterprise, 64-bit 6.1.7601, Service Pack 1
VmWare: Workstation 9.0.2 build-1031769
Gast OS Version: Windows 7 Professional 32-bit, Service Pack 1

Grundsätzlich möchte ich in der VmWare die Software TwinCat betreiben, die über die Ports 48897 TCP / 48898 TCP-UDP/ 48899 UDP auf eine SPS System, installiert auf einem separaten IPC zugreift.
Der Verbindungsaufbau erfolgt immer aus dem Guest System heraus.

Problem 1 / Versuch 1 => NAT
Eigentlich würde ich gerne über die NAT Umsetzung aus der VmWare heraus kommunizieren.
Die Internetverbindung und Standardfunktionen funktionieren auch soweit, jedoch nicht die Kommunikation auf den benannten Port.
Den Rechner, auf dem die Controllersoftware läuft kann ich per Remote Desktop erreichen, so dass ich mir sicher bin, dass das TCP Routing aus dem Guest System heraus richtig funktioniert.

Es scheint mir, als ob die VMware den Verbindungsaufbau aus dem Guest System auf den benannten Port blockt.
- Firewall im Guest System deaktiviert
- Ports sind per Virtual Network Editor richtig in das Guest System weitergeleitet

Problem 2 / Versuch 2 => Network bridged
Das VMware/Guest System soll über den DHCP Server meines Routers eine eigene IP zugewiesen bekommen.
Das System meldet sich auch beim Router an und bekommt eine IP zugewiesen, jedoch wird in der nächsten Sekunde die Netzwerkverbindung wieder getrennt und es wird eine neue IP angefordert.
Das unterbrechen und Neuanmelden ist eine unendliche Schleife.
Das Guest System meldet „Es liegt ein IP Konflikt im Netzwerk vor“, obwohl das System eine IP zugewiesen bekommt, die definitive nicht im Netzwerk vergeben ist.

Problem 3 / Versuch 3 => Network bridged / feste IP
Vergebe ich im Guest System eine feste IP kann ich wie gewünscht auch mit eingeschalteter Firewall mit meinem Controller kommunizieren.

Hat von euch einer eine Idee warum zu mindestens der Versuch 2 nicht funktioniert?

Danke für eure Antworten

Deine Versuche 1 & 3 zeigen, dass die SPS-Kommunikation nicht mit dem NAT-Modul der WS 9 kompatibel zu sein scheint.

Der Versuch 2 scheint ein Bug (?) in der Workstation 9 zu sein - du bist nicht der Einzige mit diesem Problem:

http://vmware-forum.de/viewtopic.php?t=28317

Falls dein Router aber auch eine FritzBox ist, liegt es vielleicht auch am DHCP-Server der Router.

Dein VM soll vom Router eine IPv4- oder IPv6-Adresse bekommen?
Welcher Router?

Hallo zusammen,

inzwischen bin ich weitergekommen. Die Konstellation, wie unter Versuch 1 beschrieben funktioniert nun. Ich kann auf meine Steuerung / TwinCat per NAT zugreifen.

Folgendes brachte die Lösung.
Die Ports 48897 TCP / 48898 TCP / 48898 UDP / 48899 TCP wurden per Port forwarding in die VM geleitet.
Wichtig war, dass im AMS Router der TwinCat nicht die TCP /IP Adresse der VmWare angegeben werden muste, sonder die des Host Systems.

Wichtig ist auch, da bin ich wahrscheinlich mehrere male drüber gestolpert, dass der AMS Router auf dem TwinCat Zielsystem neu gestartet wird, wenn eine neue Route eingerichtet wird. Ansonsten übernimmt er die nicht.

Vielleicht hilft dem ein oder anderen diese Information weiter.

Versuch zwei habe ich nicht weiter verfolgt.

Das man bei NAT die Portweiterleitung auf den Host einrichten muß, ist eigentlich logisch. Der Gast ist aus Sicht einen anderen Rechners, aufgrund des völlig anderen IP-Bereiches und damit sicherlich auch Netzwerkmaske, vollkommen unsichtbar.
Wenn du die VM mit Bridge-Interface eingerichtet hättest, wäre die Portweiterleitung im Router direkt auf den Gast einfacher gewesen, da du bei NAT ja nicht nur die Weiterleitung im Router sondern auch noch im VMware-NAT-Interface vornehmen muß. Standardmäßig leitet VMware ja keine Ports weiter.

ich bin anfänglich nicht davon ausgegangen, dass ich die Portweiterleitung einrichten hätte müssen, da auf dem gleichen Weg der Remote Desktop auf den IPC funktionierte.
Auch beim Zugriff auf die Steuerung wird der Verbindungsaufbau aus dem Gast System heraus aufgebaut.

Im Bridged Modus hatte ich immer das Problem, dass zwar eine IP vom Router vergeben, jedoch 1 Sekunde später die Verbindung resetet wurde. Ob die VmWare oder der Router das Problem war, ist und bleibt fraglich.

Mit einer festen IP in der VmWare im bridged Modus wollte ich nicht arbeiten, da ich von verschiedenen Netzen aus mit dem System arbeite und dies für mich ständiges abändern der Settings bedeutete.

Remote Desktop in die weite Welt funktioniert unabhängig von einer Portweiterleitung. Lediglich am Zielort brauchst du wieder eine Weiterleitung.
Da du jedoch bei Remote Desktop auch einen Zielort mit abweichenden Port ansprechen kannst, ist es kein Problem diesen nach intern auf den richtigen weiterzuleiten. Darüber könntest du dann abzüglich von geschätzten 5000 bereits andersweitig belegten Ports noch gut 60000 auf interne Port ummappen. Natürlich nur vorausgesetzt, daß zum einen der interne IP-Bereich groß genug und zum anderen dein Router soviele Einträge verwalten kann.

DHCP ist und bleibt was für Leute mit einfachen Anwendungen ohne Netzwerkkenntnisse. Virtualisierung muß zu seiner Funktion so tief eingreifen, daß man sich den Erfolg nicht mit dem DHCP-Krapf versauen sollte.

Dazu kommt, daß die in vielen Notebook verbauten WLan-Chip so ihre Problem mit dem Promiscuous-Mode haben und dieser ist nötig, um das VMware-Bridge-Interface aufbauen zu können und viel wichtiger, an diesem ist nachher auch NAT und Host-only angeflascht. Du kannst mit einem WLan-Chip aber deine Erolfgsquote erhöhen, wenn du VMware nicht das Auto-Detect/Bridging überläßt und deine Nic's im Rechner manuell den jeweiligen VMnetX zuweist. Wenn du ein NB hast, verfügt dieses sowohl über einen WLan- als auch einen normalen, kabelgebundenen Lan-Chip. Mit aktivem Auto-Detect/Bridging wird garantiert der inaktive, weil nichtangeschlossene Lan-Chip mit dem VMnet0 (Bridge) betraut. Als Ergebnis funktionieren dann die Netzwerkverbindungen im Gast überhaupt nicht oder es kommt zu schwer nachvollziehbaren Problemen.
Weshalb VMware immer noch dieses, von uns seit Jahren als Ballast empfundene Auto-Detect/Bridging, einsetzt, mußt du mal selbst VMware fragen. Höchstwahrscheinlich aber, weil in einen normalen stationären Rechner meist keine zwei Nic's vorkommen und es daher dort auch keine Probleme gibt. NBs waren meines Wissens noch nie offiziell als Virtualisierungs-Host vorgesehen und mit älteren AMD-Mobil-CPUs haben einige VMware-Produkte sogar ihren Dienst komplett verweigert. Aber das nur mal so am Rande...