search

laravel / homestead

MIT License
3.86k stars 1.45k forks source link

MacOS - Connection Timeout After Starting VM #1092

Closed pseudoramble closed 5 years ago

pseudoramble commented 5 years ago

First, thanks for the neat project and all the help! I'm new to Laravel & Homestead, but it's made life a lot easier so far.

Initially when I set up Homestead it seemed to work without issue. However after my initial setup I have issues and pretty consistently receive connection timeout issues when attempting to navigate to the app via browser. This started after switching networks with the host machine (I was at one office and then went to another office). I was able to get it to work by repeatedly reprovisioning/changing IP addresses/hostnames the other day, but it does not appear to be working again.

Right now I'm able to SSH into the vagrant box, and I can see that ngnix is started when I do something like service nginx status. I have not seen any specific logs that indicate something is wrong with the VM itself, but I'm not sure where I should be looking.

Some things I have tried include:

Versions

A lot of issues can be resolved by simply updating vagrant, provider or homestead.

Note: Virtualbox users, please upgrade to ~5.2. You will show as up-to-date from the ~5.0 version when you About -> Check for Updates. You'll need to download a newer version of Virtualbox.

Host operating system

OS X Mojave

Homestead.yaml

---
ip: "192.168.99.99"
memory: 2048
cpus: 1
provider: virtualbox

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ~/Code/laravel/
      to: /home/vagrant/code

sites:
    - map: app.test
      to: /home/vagrant/code/app/public

databases:
    - homestead

Vagrant destroy & up output

Gist.

Expected behavior

Should be able to start vagrant and be able to load the application at the URL app.test.

Actual behavior

Most of the time I receive at Connection Timeout when attempting to load the application. Once in a rare while after vagrant up --provision it will work.

Steps to reproduce

  1. Install latest vagrant box for Homestead.
  2. Clone Homestead & check out 8.2.0
  3. Configure Homestead.yaml as described above
  4. Start the machine and attempt to browse to app.test.

References

pseudoramble commented 5 years ago

One other thing that may or may not be of interest - I do have Docker/Kitematic running on the host machine as well (which uses VirtualBox I believe). After a restart of the host machine, I noticed it was also attempting to use an IP address in the 192.168.99.x range and having some issues starting up. So maybe the issues is a conflict here.

Is it possible that these tools can conflict with one another so that either A) I can't run both at the same time or B) I need to carefully set each one up to avoid a conflict?

svpernova09 commented 5 years ago

Show us the full output of vagrant destroy && vagrant up, your Gist is cut off.

Stop using vagrant --provision and use vagrant destroy && vagrant up so you always get a clean base box.

One other thing that may or may not be of interest - I do have Docker/Kitematic running on the host machine as well (which uses VirtualBox I believe). After a restart of the host machine, I noticed it was also attempting to use an IP address in the 192.168.99.x range and having some issues starting up. So maybe the issues is a conflict here.

I've run both without issues, but obviously, you cannot run them on the same IP. I run my virtualbox VMs on 192.168.10.x, VMware on 192.168.20.x (Vmware is annoying). As long as the range you tell Homestead to use isn't your local network's range, you shouldn't have an issue. (My network range at home is 192.168.1.x so no issues with Homestead on 192.168.10.x.

Should be able to start vagrant and be able to load the application at the URL app.test.

You'll need to map the app.test domain to the IP in your OS' host file before the domain name will work.

Another thing to test is look for this line during vagrant up:

==> homestead-7: Forwarding ports...
    homestead-7: 80 (guest) => 8000 (host) (adapter 1)

Then try to view http://localhost:8000 ^ that port number (8000) and see if your site shows up. If it does, Vagrant is working and you just need to map the domain name to your IP.

IllyaMoskvin commented 5 years ago

It's possible that your office network is in some way reserving the 192.168.*.* range. I've run into similar issues when attempting to use VMs while connected to VPN. You mentioned that:

This started after switching networks with the host machine (I was at one office and then went to another office). I was able to get it to work by repeatedly reprovisioning/changing IP addresses/hostnames the other day, but it does not appear to be working again.

It sounds like there might be an IP conflict in play. What happens if you connect to the office network and ping 192.168.99.99 (or whatever you define in Homestead.yaml), before launching Homestead? Do you get a response?

Right now I'm able to SSH into the vagrant box [...]

I believe this is possible because the vagrant box forwards port 22 on guest to port 2222 on host. When you run vagrant ssh, you're actually connecting to localhost:2222. When I had trouble with VPNs, I could still connect to my guest via the forwarded ports (e.g. http://localhost:8000).

What does the "Network" tab in your VM's settings look like in VirtualBox?

deviantintegral commented 5 years ago

One way to troubleshoot is to run traceroute <ip of VM>. If there's a routing conflict, you'll see the trace go to an external address. netstat -rn will also show the various destinations and their gateways.

There's two other classes of reserved networks for private addresses, so if netstat doesn't show any 10.*.*.* or 172.16-32.*.* addresses, you could try switching to one of those.

Finally, since you mentioned "office" I've seen both VPN and security software mess up networking. For example, I often have to reboot after using Cisco's notoriously unstable "AnyConnect" VPN client to fix Vagrant and Docker networking. Something to double check at least.

pseudoramble commented 5 years ago

First, thanks for all the replies and sorry for my delay getting back. I managed to get it running yesterday after a reboot of the host machine and doing a vagrant destroy && vagrant up. Once I did that I was working with it for a few hours no problem.

At the end of the day, I connected to the VPN (using AnyConnect as you said @deviantintegral funny enough) and did a few unrelated tasks, disconnected from the VPN, and then left my laptop (on the same physical network) overnight. And then this morning when I came back, I was unable to connect to the machine. After rebooting the host machine, and running vagrant up I was able to reconnect to the VM no problem.

So clearly I need to eliminate some variables to figure out the specific cause 😄 but I'm now thinking it has to do with switching networks, and more specifically the VPN messing with settings. Since this seems like a weird environment problem, I'll close this issue. That being said, I'll report back what I find for others.

To address some of the questions:

IllyaMoskvin commented 5 years ago

Bleh. We use AnyConnect too, and it causes the same issues for us. I found two issues so far:

  1. When connected to VPN, if I have my hosts file configured with e.g. 192.168.10.10 example.test, I cannot access my website via http://example.test.
  2. After disconnecting from VPN on a macOS host, this issue persists.

Interestingly, when using Homestead on a Windows 10 host, I do not encounter the second issue. I do still encounter the first issue, but with a different error.

As @deviantintegral mentioned, the only reliable way we found to restore VM usability after disconnecting from VPN is to restart the host.

The fact that we cannot develop and deploy at the same time (using the same machine) is a deal-breaker for us institutionally, so in the near-ish future, we'll be putting some resources into trying to resolve this issue gracefully. I'll try to follow up with more info when and if we do. In the meantime, this is the most promising lead we found:

https://superuser.com/questions/987150/virtualbox-guest-os-through-vpn

However, if you are encountering the first issue I mentioned – http://example.test doesn't work – then there's a potential work-around. I'm writing this from memory, so apologies for any mistakes.

First, ensure that your HTTP/S ports are being forwarded when you run vagrant up:

==> homestead-7: Forwarding ports...
    homestead-7: 80 (guest) => 8000 (host) (adapter 1)
    homestead-7: 443 (guest) => 44300 (host) (adapter 1)

Then, in your /etc/hosts or C:\Windows\System32\Drivers\etc\hosts, instead of doing this:

192.168.10.10       foo.test
192.168.10.10       bar.test

...try this:

127.0.0.1       foo.test
127.0.0.1       bar.test

...and access your websites using http://foo.test:8000 and http://bar.test:8000.

This is nice because it allows you to run multiple websites on the same Homestead box, but still take advantage of port-forwarding. That said, IIRC, I tested this with an API service, not an actual website that needed to load assets from the server. I don't know if this technique will work well for all cases.

If anyone has tips on how to get Cisco AnyConnect VPN to play nice with VMs, please do share!

deviantintegral commented 5 years ago

so in the near-ish future, we'll be putting some resources into trying to resolve this issue gracefully

If your organization contracts with Cisco directly, it would be wonderful to get this raised as a bug report. I just had a colleague report an additional issue with mDNS refusing to resolve to the VM after disconnecting. Unfortunately, I'm at an agency and it's our clients who often require Cisco's VPN to get onto their networks, so our ability to troubleshoot and report bugs is limited given Cisco's closed nature.

IllyaMoskvin commented 4 years ago

I've been meaning to follow up on this for a while. We never did find a permanent fix.

Our sysadmin found that running this command after disconnecting from VPN:

sudo route -n add -net 192.168.10.0/24 -interface vboxnet0

...seems to fix the issue without requiring us to restart the host. You may need to adjust the net and interface options to match your VM's network settings.

If you see the following message:

$ sudo route -n add -net 192.168.10.0/24 -interface vboxnet0
route: writing to routing socket: File exists
add net 192.168.10.0: gateway vboxnet0: File exists

You can try deleting the existing route, and then run the add command again:

$ sudo route -n delete -net 192.168.10.0/24
delete net 192.168.10.0
$ sudo route -n add -net 192.168.10.0/24 -interface vboxnet0
add net 192.168.10.0: gateway vboxnet0

It's worthwhile to note that AnyConnect has been updated several times since we started encountering these issues. I haven't been encountering this issue quite as much anymore, but that might just be because my recent projects haven't required VPN as much as previous ones. I do still have to use the :8000 port-forwarding method described above whenever using VMs while on VPN.