minikube: hyperv: ssh: connectex: A connection attempt failed because the connected party did not properly respond

@briansmith Just in case it might help. I had this exact same issue (and was getting very frustrated!)…

i would run the command (minikube start --vm-driver=hyperv --hyperv-virtual-switch="Default Switch" --v=7) at first it would pick up the IPV4 address and issue the SSH commands… after a few commands it would seem to lose the IPV4 address and only get the IPV6 address (which then wouldnt accept SSH). Ever time I ran it it would fail at a different point, the IPV4 address seemingly just randomly dropping off. The annoyance was that the script constantly asked for the IP which seemed to be in a state of flux.

The solution for me (and I hope this solves it for a few other people) was to not use WIFI. When i used a wired/ethernet connection all those problems went away and it all worked fine and minikube installed without a problem. I dont know if its something to do with HyperV / Default Switch and wireless network cards but I would advise trying with a wired connection.

Hope this helps you / others who might be seeing this.

I have the same problem with IPv4, so use of IPv6 should not be an issue:

minikube start --vm-driver=hyperv --hyperv-virtual-switch=pvs --kubernetes-version=“v1.10.0” --v =7 --alsologtostderr --memory=4096

I0713 13:08:25.938050   15900 cluster.go:83] Machine state:  Running
Waiting for SSH to be available...
Getting to WaitForSSH function...
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM minikube ).state
[stdout =====>] : Running

[stderr =====>] :
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM minikube ).networkadapters[0]).ipaddresses[0]
[stdout =====>] : 192.168.1.114

[stderr =====>] :
SSH binary not found, using native Go implementation
&{{{<nil> 0 [] [] []} docker [0x83ffb0] 0x83ff60  [] 0s} 192.168.1.114 22 <nil> <nil>}
About to run SSH command:
exit 0
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.

With native client result is the same

[stderr =====>] :
Using SSH client type: native
&{{{<nil> 0 [] [] []} docker [0x83ffb0] 0x83ff60  [] 0s} 192.168.1.114 22 <nil> <nil>}
About to run SSH command:
exit 0
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.

I have the same problem. When I start in Git bath with admin with:

minikube start --vm-driver=“hyperv” --hyperv-virtual-switch=“k8s” --v=7 --alsologtostderr

finally got:

[stderr =====>] : Using SSH client type: native &{{{<nil> 0 [] [] []} docker [0x83ffb0] 0x83ff60 [] 0s} fe80::215:5dff:fec8:6504 22 <nil> <nil>} About to run SSH command: exit 0 Error dialing TCP: dial tcp [fe80::215:5dff:fec8:6504]:22: connectex: A connection attempt failed because the conne cted party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

The culprit turned out to be that I was connected to a corporate VPN (using the Cisco client)

… disconnected from corporate VPN (cisco) and was able to start minikube. Thanks!

This likely warrants no action, but I’m commenting here in case it helps someone else. I faced this exact same problem on Minikube v1.6.2. I tried explicitly specifying the “Default Switch”, an internal switch, and an external switch and also not specifying a switch at all: none of these made a difference.

The culprit turned out to be that I was connected to a corporate VPN (using the Cisco client) that is notorious for causing internet connection issues with a variety of programs. Once in a while it causes local network issues too. This instance may be related to #1265 (had a hard time following that issue).

You should use an external network, an internal network with a dhcp server or the new default switch

On Monday, March 5, 2018, Harsh Kumar notifications@github.com wrote:

Is there a work around for this issue… Have hit the same while trying to run minikube on WINDOWS 10

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.< https://ci4.googleusercontent.com/proxy/c2BjZHrYN0dkYOE6Lww1xD2EnApOmsoF1zamx9Gh1BRC2WNe56nYroRV5zzzbNSj0fMB_U1WBVD8QstTUiwCGlq9qf9mbq1Zl8kZCzbwiO1-i89mPaQZ9ZprLyn5GeFXsfuWZuz1XhgZQExrh_31Odm7Mi3qcg=s0-d-e1-ft#https://github.com/notifications/beacon/AAAHZrufGiRzzi2lXlWxTgmHOWBZmFBWks5tbTw9gaJpZM4RZxGW.gif

–

Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ]