Problemen met verbinden van vSphere Client op ESXi 6.0

[Sinna]

Voor de een of andere zotte reden (ik zoek er al twee dagen op ) wil mijn vSphere Client (Build 2502222) niet meer verbinden met mijn ESXi 6-server (VMware ESXi Version 6.0.0 Build 2715440), een Dell PowerEdge T420 waar ik ESXi 6 vanaf de Dell Support site geïnstalleerd heb.

Ik krijg telkens dezelfde vage connection error:

An unknown connection error occured. (The request failed because of a connection failure. (Unable to connect to the remote server))

Op basis van http://mediarealm.com.au/articles/2013/ ... sh-tunnel/ ben ik er terug in geslaagd om via een SSH-tunnel te verbinden, maar ik snap echt niet waar het probleem zit.

Ik dacht de oorzaak gevonden te hebben in een blogbericht van 2012 dat slaat op ESXi 5 (http://vmtoday.com/2012/02/vsphere-5-ne ... nectivity/), maar ik heb maar één vmnic gedefinieerd. Het vreemdst van al is dat ik wél kan pingen naar het toestel.

Voor de volledigheid: ik verbind vanuit een ander subnet vanaf een Win8-bak, maar routing is OK, anders zou ik niet kunnen pingen...
Ik weet dat ik in het begin wél verbonden geraakte, maar heb geen idee wat er veranderd is waardoor het opeens niet meer werkt.

[selder]

Kan je eens testen van in hetzelfde subnet?
Wat zegt een NMAP scan op het IP van uw ESXi?
Management netwerk via de console van de ESXi al eens herstart?
En eventueel de Management agents onder het troubleshoot menu?

ICMP wil eigelijk op zich niet zoveel zeggen, dat is echt geen zaligmakende test

[Sinna]

Ik kan momenteel geen vSphere Client lanceren vanop hetzelfde subnet, maar een esxcli-commando komt wél door.

NMAP vanop hetzelfde subnet geeft aan dat de vereiste poorten (443/tcp, 902/tcp) bereikbaar zijn, vanaf het subnet van waar ik wil verbinden is 443/tcp niet bereikbaar, 902/tcp wél. 80/tcp redirect naar 443/tcp maar dat lukt dus niet.

Management network herstarten maakt geen verschil.

Is dat troubleshoot-menu bereikbaar vanaf de DCUI? Indien enkel van daar, dan zal het moeten wachten tot morgen (heb nu geen fysieke toegang tot de console).

Ik heb de firewall-instellingen gecontroleerd voor vSphere Client, maar daar lijkt alles OK.

ICMP wil eigelijk op zich niet zoveel zeggen, dat is echt geen zaligmakende test

Verklaar je nader.

[selder]

Goh, als TCP443 niet bereikbaar is, dan denk ik toch dat je eerst die piste moet onderzoeken ... Zonder TCP443 werkt het niet, al staan alle andere poorten open. Wie weet is het een andere bak die antwoordt ofzo, wij weten de opstelling daar niet hé...

Geen ILO of iDrac om aan de console te geraken?
Als je het management netwerk herstart, dan kan je ook aan de management agents...

Maar door die TCP443 denk ik toch dat het dan eerder daar aan ligt.

Heeft elke machine nog wel de juiste gateway? Doen die gateways wel goed hun ding als ze je 2 subnets moeten routeren?
Misschien dat een traceroute nog iets aan het licht brengt?

ICMP is niet zaligmakend, omdat je dat net zoals alle andere protocollen kan instellen. Zo reageert ons extern IP bijvoorbeeld helemaal niet op ICMP paketten...

[ubremoved_539]

Ik heb hier zopas ook een ESxi 6.0 geinstalleerd welke zelfs in een andere VLAN en subnet zit... werkt prima.

Ik heb ook niets speciaals moeten doen dus zou eigenlijk ook niet meteen een idee hebben.

Het is wel bizar dat je web access niets geeft ?

[Sinna]

Zó ingewikkeld zit het niet in elkaar: Bepaalde PC's in het kantoornetwerk (192.168.A.x) mogen pakketjes versturen en ontvangen naar het servernetwerk (192.168.B.x). Er worden door de firewall (ZyXEL USG 100) geen extra restricties opgelegd wat dat verkeer betreft. Het blijft uitermate vreemd dat het enkel die poort 443 is die met mijn voeten rammelt... De kans dat een andere bak antwoordt is minimaal tot uitgesloten: ik hou een overzicht bij van welk toestel welk IP-adres zichzelf toeëigent of toegewezen krijgt (dmv. fixed DHCP lease).

Qua routeren: die ZyXEL doet dat, en doet dat goed. De default GW op de ESX staat op de ZyXEL (192.168.B.1), de default GW van mijn Win8-PC staat ook op de ZyXEL (192.168.A.1). Een traceroute bevestigt dat (getest van zowel de Win8-PC als de ESX).

Ik ga morgen eens kijken of ik het certificaat opnieuw kan laten genereren. Er begint iets te dagen, maar ik heb geen idee of dát de oorzaak is: ik heb de ESX een ander fixed IP gegeven (wel binnen hetzelfde subnet). Als ik Certificate Management for ESXi Hosts (http://pubs.vmware.com/vsphere-60/index ... 5D0B2.html) lees, dan zou dit wel eens de oorzaak kunnen zijn.

[Sinna]

Ik ben er achter wat het probleem is. Bedankt voor het meedenken iedereen.

Ik had al zo'n donkerbruin vermoeden dat de firewall er voor iets tussen zat, en da's bij deze bevestigd.

Voor de een of andere reden (moet ik nog achterhalen), wordt poort 443 onbereikbaar als ik de vlag Use Policy Route to Override Direct Route zet. Die vlag heb ik nodig om een ander probleem (waarbij de firewall denkt slim te zijn en antwoorden op pakketten die via wan2 binnengekomen zijn, via wan1 uitstuurt ) op te lossen. Na het uitzetten van die vlag kon ik probleemloos verbinden. Door nu gericht een policy route toe te voegen, kan die vlag terug op en blijft mijn ESXi-server bereikbaar.

Me happy Nu nog een bron vinden die mijn wedervaren bevestigt.

[Sasuke]

Lijkt me toch logisch ... als je geen policy route hebt, en je je firewall zegt dat die de direct route moet overriden met een policy route ... dat er dan ook geen route/port beschikbaar is ... niet ?

[Sinna]

Toch niet: ik heb aangegeven dat de policy route voorrang heeft op de direct route. Aangezien ik geen specifieke policy route gedefinieerd had voor dat subnet, ging ik er (verkeerdelijk) van uit dat de direct route genomen zou worden.

[ITnetadmin]

Inderdaad, zo zou ik "override" ook interpreteren.

[ Post made via mobile device ]

[Sinna]

Feit blijft dat enkel 443/tcp hierdoor geaffecteerd werd. Een nmap vanaf het kantoornet gaf hetzelfde resultaat als een nmap van het servernet muv. 443/tcp...
Blijkbaar heb ik een hidden feature ontdekt in de ZyXEL USG-reeks. Gericht zoeken op 't internet levert nl. niets op.