Onderwerp: Vsphere client niet over VPN te gebruiken

Hallo,

Ik heb een server en hierop draait ESXi.
Dit werkt allemaal prima, ik heb de management interface tijdelijk op een extern IP gezet.

Voor de beveiliging heb ik Vyatta geinstalleerd en hier een VPN server van gemaakt.
De management interface heb ik op een lokaal IP gezet zodat ik er alleen bij kan als ik VPN verbinding maak.

VPN verbinding maken gaat prima, ik kan pingen naar de esxi server en ik kan inloggen bij vsphere client. Echter blijft hij hangen bij loading inventory. Wel verschijnt er in de vmware eventlog dat ik ingelogd ben.

Ik kan dus eigenlijk vsphere client niet gebruiken.
Wanneer ik de interface weer op het publieke ip zet werkt het prima.

In vyatta staan geen specifieke firewall regels, dus het is waarschijnlijk geen poort die geblokt wordt.

Weet iemand waar dit aan kan liggen?
Of heeft iemand betere suggesties voor de beveiliging.

Ik kan je alleen melden dat wij hier geen problemen mee hebben, meerdere ESXi's achter een VPN hangen.

Misschien een MTU probleem?

MTU heb ik niet specifiek veranderd.
Ik heb hem in mijn Windows PC een keer op 1500 gezet, maar dit heeft niets geholpen.

Even wat rond gelezen over de MTU
De MTU die ik moest gebruiken is 1368, dit heb ik aangepast, maar het werkt nog steeds niet.

Waar heb je deze aangepast? Op de interface van je PC? (niet echt de juiste plek) Kijk ook even naar de configuratie van je VPN oplossing. Wat gebruik je hiervoor? Bij een aantal kun je hier ook MTU/MRU instellen. Mogelijk staat dit hoger ingesteld dan haalbaar.
En hoe kom je op een mtu van 1368?

Ook kan het zijn dat path mtu discovery (pmtu) onderweg ergens gefilterd wordt, of op 1 van de 2 hosts uitgeschakeld staat, maar lijkt mij niet erg waarschijnlijk in dit verhaal.

MTU heb ik met behulp van http://www.dslreports.com/faq/5793 gevonden.

Ik heb hem ook in de VPN server ingesteld, vyatta dus.
Ook op de virtual switch van VMware.

Eigenlijk overal waar deze in te stellen is.

Ik zou nou niet de MTU van mijn ethernet verbindingen gaan aanpassen om een dergelijk probleem op te lossen. Of was dat alleen als test bedoeld? Naar mijn idee kun je die het beste op 1500 laten staan. Buiten dat heeft het het probleem dus niet opgelost.
En als je het linkje hebt uitgevoerd. Welke host heb je dan ge-pingt om tot de mtu te komen? De ESXi server neem ik aan? Kun je verder nog even aangeven welke vpn software je gebruikt? Vyatta is dat niet, want die maken geen vpn software (dacht ik...). Ik denk dat het dus pptp,openvpn,l2tp of ipsec moet zijn. En daar denk ik ook dat je het probleem in moet zoeken.

Kun je trouwens wel andere dingen over de vpn benaderen? Misschien even een groot file met rsync/scp proberen te kopieren. Dan merk je een mogelijk mtu probleem ook meestal vrij snel.

Hier ook, vSphere client zonder problemen via PPTP.

Ik gok zomaar dat hij het juist wel via vyatta doet waarom anders vyatta installeren? Voor zover ik kan zien kun je via vyatta gewoon een vpn opzetten.

Ik gebruik de PPTP VPN van vyatta.
Ik heb overal de MTU gewijzigd, maar niet geholpen, dus als test. Ik heb de ESXi host gepingd om de MTU te bepalen.
Ik zal eens proberen om iets anders te testen over de vpn.

Heb een file transfer over ssh proberen te doen, maar dit is inderdaad ook geen succes.

Heeft iemand een idee hoe ik dit oplos?

Oorspronkelijk geplaatst door hrodenburg

Ik zou nou niet de MTU van mijn ethernet verbindingen gaan aanpassen om een dergelijk probleem op te lossen. Of was dat alleen als test bedoeld? Naar mijn idee kun je die het beste op 1500 laten staan. Buiten dat heeft het het probleem dus niet opgelost.
En als je het linkje hebt uitgevoerd. Welke host heb je dan ge-pingt om tot de mtu te komen? De ESXi server neem ik aan? Kun je verder nog even aangeven welke vpn software je gebruikt? Vyatta is dat niet, want die maken geen vpn software (dacht ik...). Ik denk dat het dus pptp,openvpn,l2tp of ipsec moet zijn. En daar denk ik ook dat je het probleem in moet zoeken.

Kun je trouwens wel andere dingen over de vpn benaderen? Misschien even een groot file met rsync/scp proberen te kopieren. Dan merk je een mogelijk mtu probleem ook meestal vrij snel.

Hallo,

Tja als ik je verhaal lees denk ik niet echt aan MTU e.d. maar eerder aan wat basis zaken zoals gateway en dns.

Zoals anderen al aangeven, er is geen reden dat dit niet werkt onder een VPN.
Ik heb nu niet echt de tijd om het te testen, je hebt het over bestanden oversturen via ssh.. lijkt me niet helemaal de eerste test. Kan je al wel inloggen via SSH? Komt er een reply van die server over SSH?

Ik vraag me gewoon af of je gateway goed staat ingesteld...
Enne al het verkeer voor de vSphere client gaat gewoon over HTTP en HTTPS, dus als je met bijvoorbeeld een wget of een simpele telnet op poort 80 en 443 al geen replies krijgt, dan gaat het daar al fout.

Gateway en DNS etc. is wel gewoon goed ingesteld.
Als ik eenmaal in de VPN zit kan ik ook gewoon naar de servers pingen die hierachter hangen.

Wat mij wel opvalt is dat ik soms een paar keer een nieuwe poging moet doen om VPN verbinding te maken, soms is hij onbereikbaar zegt hij.

Aangezien ping ed. wel werken evenals het inloggen op esxi, maar het fout loopt bij het laden van de inventory bij esxi denk ik toch aan mtu problemen. Dat is in ieder geval de achterliggede gedachte. Ook het mislukken van filetransfer over ssh lijkt dit te bevestigen. Dan verstuur je namelijk packets met de grote nagenoeg gelijk aan de mtu.
Maar inderdaad, kun je wel een terminal over SSH openen? Als de oorzaak inderdaad de mtu size is, zou ik verwachten dat dit wel werkt, omdat je hierbij bijna geen packets met de grootte van de mtu verstuurd. Tenzij je "veel" output naar je console stuurt (ook een goeie test wellicht).

Werkt dit ook niet, dan heeft wellicht wila gelijk en klopt de routering niet.
Controleer even goed of je routes kloppen (ook vooral op de esx server). Hier moet uiteraard in ieder geval een route zijn voor je vpn-client-ip via je vpn server.
Geef anders even aan hoe je de vpn server hebt ingericht (vpn ip range) en wat je op je management netwerk gebruikt en hoe de routes zijn ingesteld.