I am not able to connect to docker daemon on junos vpn

[ggupta2008]

OS: Yosemite 10.10.5
Docker : docker -v
Docker version 1.10.1, build 9e83765

Issue: docker-machine env dev
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: i/o timeout
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

Docker-machine:
docker-machine version 0.6.0, build e27fb87

Hostfile changes on VPN:

BEGIN hosts added by Pulse

193.195.47.37 rcnsslvpn.blabla.com

END hosts added by Pulse

debug logs:
docker --debug ps
DEBU[0000] Trusting certs with subjects: [010U
guptga1]
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

VBox logs: attached
VBox.txt

[itrion]

Mac OS X El Capitan 10.11.6
Docker version 1.10.3, build 20f81dd
docker-machine version 0.6.0, build e27fb87

I'm having the same problem any help/advice to solve this problem would be awesome:

I deleted the default VM and all the host-only adapters in VBox. After that I created a new docker machine:

-> docker-machine create default -d virtualbox
Running pre-create checks...
Creating machine...
(default) Copying /Users/itrion/.docker/machine/cache/boot2docker.iso to /Users/itrion/.docker/machine/machines/default/boot2docker.iso...
(default) Creating VirtualBox VM...
(default) Creating SSH key...
(default) Starting the VM...
(default) Check network to re-create if needed...
(default) Found a new host-only adapter: "vboxnet0"
(default) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env default

Then, when I run

-> docker-machine env default

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/itrion/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
# Run this command to configure your shell: 
# eval $(docker-machine env default)

The problem comes when I connect to the VPN using the Pulse Secure client for Mac:

-> docker-machine env default
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: i/o timeout
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers

If I try to regenerate the certs I get:

-> docker-machine regenerate-certs default
Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Waiting for SSH to be available...
Detecting the provisioner...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...

This machine has been allocated an IP address, but Docker Machine could not
reach it successfully.

SSH for the machine should still work, but connecting to exposed ports, such as
the Docker daemon port (usually <ip>:2376), may not work properly.

You may need to add the route manually, or use another related workaround.

This could be due to a VPN, proxy, or host file configuration issue.

You also might want to clear any VirtualBox host only interfaces you are not using.

I then tried two things:

1. I suspected the problem was reachability of the network so I changed the route table to use the vboxnet internet interface when going to the docker-machine ip

-> route get 192.168.99.100
     route to: 192.168.99.100
destination: 192.168.99.100
    gateway: <vpn IP>
   interface: utun0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1400         0

-> sudo route add 192.168.99.100 -interface vboxnet0
change host 192.168.99.100: gateway vboxnet0

-> sudo route change -net 192.168.99.0 -interface vboxnet0
change net 192.168.99.0: gateway vboxnet0

-> route get 192.168.99.100
route to: 192.168.99.100
destination: 192.168.99.100
interface: vboxnet0
      flags: <UP,HOST,DONE,LLINFO,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 

2. I followed the advices here: Cannot access docker when running VPN (Cisco AnyConnect) boot2docker/boot2docker#628

about adding forwarding rule on the vbox machine but the same happens. :(

[volkertb]

I described a workaround using emulated serial connections and/or client VMs in the other VPN topic you mentioned, @itrion. boot2docker/boot2docker#628 (comment)

Perhaps these workarounds would be useful and practical to you as well. In the meantime, I'm going to open an issue here requesting automatic serial fallback in docker-machine. That would make things more practical for sure.

[marcellodesales]

Same problem here... While working with Docker / Minikube in a development flow connected in VPN Junos :(

@volkertb Any updates with the new Docker Engine in MacOS?

[volkertb]

@marcellodesales I have no idea. There have been no responses to my request in issue #3762 lately. 😞

[marcellodesales]

@volkertb I got minikube to work to forward calls to Docker Engine in a VM...

kubernetes/minikube#1099 (comment)

Maybe you guys can use the same strategy for machine?

[volkertb]

@marcellodesales Yeah, connecting to VMs through localhost (127.0.0.0/8) is indeed a full-proof way to go when working with a VPN. That's the only IP route that a VPN cannot touch.