VMware-Forum

Hi

Ich habe heute das neue ESXi-8.0U1-21495797-standard per ISO geupdatet. Vorher war die letzte 8.0.0 drauf.

Auf dem Host hat es 2 vmkernel Ports. Nun ist der eigentliche Port, in der Host Konsole konfiguriert, nicht mehr erreichbar. Der zusätzliche Port, in der Host Konsole nicht angewählt, ist problemlos erreichbar.

Ich kann den Host auf das eigentliche Hauptinterface nicht mehr erreichen. Er lässt sich zwar pingen, aber SSH, Hostclient und vmware WS als remote Konsole werden zurück gewiesen. NFS funktioniert aber.

Ich habe es von zwei Geräten aus getestet. Von beiden Clients konnte ich mich vorher problemlos auf beide vmkernel Adressen verbinden.

Clients: vLAN 101 - 192.168.101.100, 192.168.101.101
vmkernel 101 - 192.168.101.140 ist erreichbar
vmkernel 102 - 192.168.102.140 ist nicht erreichbar

Hatte schon das Managemet Netzwerk am Host zurückgesetzt, getestet (kommt ok, aber der pingt ja nur) sowie den Host neu gestartet. Der Sperrmodus ist deaktiviert.

Es liegt aber schon am Host den Fehlermeldungen nach zu urteilen. Und pingen kann ich ja. Vor dem Update hat es ja auch funktioniert.

Hat da wer einen Plan, was ich da noch tun könnte?

Gruss und danke

MarroniJohny hat geschrieben:Ich habe es von zwei Geräten aus getestet. Von beiden Clients konnte ich mich vorher problemlos auf beide vmkernel Adressen verbinden.

Clients: vLAN 101 - 192.168.101.100, 192.168.101.101
vmkernel 101 - 192.168.101.140 ist erreichbar
vmkernel 102 - 192.168.102.140 ist nicht erreichbar

Verstehe ich das richtig? Die Clients, von denen aus du es versuchst, sind im VLAN 101, das Management im VLAN 102?

Genau ja.

Aber es ist wohl ein Problem mit den Zertifikaten. Kann ich die für das vLAN 102 irgendwie löschen? Muss ich das auf dem Host, oder auf den Clients? Ich nehme an, dass die Clients mit den alten Zertifikaten zugreifen wollen /Spekulatius off

Die Zertifikate sind nicht das Problem - das Fehlerbild wäre IMHO ein anderes.

Warum kommunizierst du quer über VLANs und wie? VLANs dienen doch der Netzwerkseparation - ich verstehe dein Setup nicht.

Der Fehler deutet eher auf die ESXi-Firewall - diese lehnt die eingehenden Verbindungen scheinbar ab.

Das Management vLAN hatte ich eigentlich eingerichtet, weil mein NFS 3.0 Filer kein Passwort unterstützt. Das ist wohl nur für sichere Netzwerke gedacht. Und ich stelle die VMs halt per NFS zur Verfügung. Da habe ich dann alles in die Richtung rein gepackt. Firewall, Switch Admin, NFS Filer, ESXi und sowas.

Und dann halt in der Firewall einzelne Dienste wie den ESXi von dem Desktop zum Management LAN beregelt. Hat bislang super funktioniert.

In der ESXi Firewall habe ich noch nie was gemacht. Bei den Einstellungen sind da "Alle Verbindungen von allen IP Adressen zulassen" drin.

Kann es sein, dass ich da noch einen Dienst starten muss?

Gruss und danke

Nein, die Dienste sind O.K. so.

Wie sieht es mit Firefox von einem leeren, neuen Firefox-Profil aus? Gleicher Fehler?

Kannst du testen, ob eine direkte Verbindung zum Management Interface mit einem Gerät funktioniert, das auch im VLAN 102 ist?

Ja, wenn ich den Laptop an vLAN 102 stöpsle, bekomme ich Zugriff. Muss aber doch irgendwie am ESXi liegen, weil an der Hardwarefirewall habe ich ja nichts verändert. Da ist von Desktop und Laptop in vLAN 101 nach vLAN 102 Client 192.168.102.140 (ESXi) alles auf allow. Und wenn es Zyxel mässig geblockt wäre, käme wohl kein Security Error auf dem Client, sondern 404, oder in der Art.

Noch ein paar Ideen:

- Sind die beiden Karten im ESXi-Host durch das Update vielleicht verwechselt worden (vmnic0 <-> vmnic1)?
- Nach einem ESXi-Neustart kann der physische Switch manchmal Zicken machen - mal neu starten?

- Sind die beiden Karten im ESXi-Host durch das Update vielleicht verwechselt worden (vmnic0 <-> vmnic1)?

- Nein, die beziehen ja beide per DHCP die Adresse 140 über die MAC. Und das normale Interface (102) ist an der MoBo NIC. Passt also schon.

- Nach einem ESXi-Neustart kann der physische Switch manchmal Zicken machen - mal neu starten?

- Ja, Host kalt neu gestartet hatte ich als erstes. Auch über die Host Konsole das Management Network neu gestartet, und alles. Der Adapter 192.168.102.140 ist ausgewählt, wird auch per DHCP auf der Konsole angezeigt und hat Adresse bezogen. Er ist auch erreichbar, halt nur im vLAN 102.

Fehlender Nameserver kann es ja nicht sein, wenn über IP Adresse bezogen wird? Weil vLAN 102 darf nicht nach aussen telefonieren.

Ich meinte den pSwitch neu zu starten.

Ah nein, Modem, FW und Switch noch nicht neu gestartet. Aber morgen früh test ich das mal als Erstes.

Danke soweit

Hmm, ja Switch neu gestartet. Auch IP Adresse statisch vergeben. Der Port will nichts aus einem anderen vLAN hören.

Da ein Gerät im VLAN 102 mit dem ESXi Management normal reden kann, muss es an der Hardwarefirewall liegen - auch wenn du nichts verändert hast.

Hmmm....Browser Cache mal gelöscht ? Hab eben mal nach dem pr_connect_reset_error gegoogelt und da kam das als Tip.

Ja, Browser Cache gelöscht, anderer Browser getestet.

Falsche Firewall Einstellung glaube ich auch nicht, weil nach den Bildern oben (Security Fehler) antwortet der Server ja auf den betreffenden Ports.

Verbindung ist weder zum Hostclient, noch via vmrc, bzw. SSH möglich.

Ich vermute, vmware hat da was eingebaut, dass man nicht aus einem anderen Adressrange zugreifen kann.

Ich vermute, vmware hat da was eingebaut, dass man nicht aus einem anderen Adressrange zugreifen kann.

Wenn dein Client im 192.168.101-Segment steht und mit einer Netzwerkmaske 255.255.255.0 (/24) arbeitet und das vmkernel-Device auf dem ESXi im 192.168.102-Segment steht und mit einer Netzwerkmaske 255.255.255.0 (/24) arbeitet, dann willst du als Admin ja, dass sie sich nicht sehen können. Es sei denn, deine ZyXEL-Firewall stellt die Cross-Segment-Kommunikation via NAT her.

Ja, habe da explizit Interzone Regeln für die betreffenden Clients vom vLAN 101 nach 102 erstellt. Der Server antwortet ja, sieht man an den Security Fehlern aus #1.

Wenn du in der ZyXEL Firewall eine Interzonen-Regel hast, die den Übertritt der Pakete erlaubt, aber sonst nichts tut (NAT), dann bekommt dein ESXi auf seinem 102er-Interface eine Anfrage aus dem 101er Segment - er empfängt das Paket, kann es aber nicht selbst zurückschicken (falsches Netzwerksegment, kein ARP, keine Ethernet-Zieladresse) und müsste es stattdessen es an sein "default gateway" senden. Möglicherweise ist das aus Sicherheitsgründen im aktuellen TCP/IP-Stack nicht mehr erlaubt