Port Forwarding Issue with vagrant on Windows 8.1 #5838
Comments
|
Can I get a status update? Or is there any way I can assist? |
|
I am having this same problem. I tracked it down to the vmnetnat.conf file. The forwarded ports are not being written to this file during vagrant up/reload. You can see this in vagrant up --debug and look for the section about the Windows NAT configuration file. I am able to manually add the forwarded port to this file in VMware Workstation from Edit > Virtual Network Editor ... > NAT. When I do, the port forwarding works. Here is a diff comparing the file set by vagrant with the changes made inside VMware Workstation. Notice the entire [incomingtcp] section is missing. |
|
@PoetikDragon One thing to watch for, if you open the Network Editor at ALL while a VM controlled by Vagrant is running it typically destroys the Vagrant initiated changes. So adding/changing one port will clobber all the other ports Vagrant set up. |
|
@dragon788 Vagrant is not setting up any ports - the entire [incomingtcp] section is deleted by vagrant during up. Supposedly this has been fixed, since it was mentioned in another issue and closed: I'm going to try the latest version and find out. |
|
Update: I reinstalled vagrant and vmware a few days ago and that seemed to do the trick! The [incomingtcp] section was present after The bad news - I destroyed and recreated my environment a few times while reorganizing a project. I did not change the Vagrantfile or puphpet config at all. It is once again deleting the [incomingtcp] section again during EDIT: The plot thickens. I uninstalled git, vmware, and vagrant. After reinstalling I did |
|
@PoetikDragon are you by chance running your 'vagrant up' inside of a Git BASH session, or do you use the Windows cmd.exe or Powershell? |
|
I got the same problem here. Forwarded Ports are not accessible under Windows. I used to start the machine via a zsh session from a cygwin installation. I just tried using plain cmd.exe as admin but the result is the same. Even so vagrant prints out the forwarded ports, non of them are accessible. |
|
Hi, Just trying to help out. Have you tried using bash instead of zsh in Cygwin On Mon, Nov 9, 2015 at 5:22 PM, Alex notifications@github.com wrote:
Ismael Angelo A. Casimpan Jr. |
|
@icasimpan just tried this with the same result. Also plain cmd.exe made no difference. I would be surprised if the shell had that much influence. I'm running on Windows 8.1 with Vagrant 1.7.4 . |
|
With your vagrant halted, open VMware Workstation go into the network
|
|
@dragon788 I tried it, but it doesn't change anything. |
|
Have you tried disabling all plugins like Berkshelf and Bundler? Does it On Tue, Nov 10, 2015 at 2:11 AM, Alex notifications@github.com wrote:
|
|
@dragon788 I now used hashicorp/precise64 and reinstalled Vagrant. No luck either. |
|
@a-zen @PoetikDragon Are you using version 1.7.2 or 1.7.4 of Vagrant and what version of the vagrant-vmware-workstation plugin? |
|
This issue is ongoing though now my machine is Windows 10. @dragon788 I updated everything this week, so now I have Vagrant 1.8.1, VMWare Workstation 12.1.0, and provider plugin version 4.0.6. I was having better luck with the new install, the problem being intermittent instead of constant. I even thought I had figured out a work around - it seemed that rebooting the machine would allow port forwarding to work on the first "vagrant up." I have since found that is not true. I did not change anything in vagrant, vmware, the plugin, the vagrantfile, or the virtual machine but I did a "vagrant reload" when it was working fine and now can't get it to port forward at all, no matter how many times I reboot or up/halt or reload. |
|
Claire, if you open your C:\ProgramData\VMware\vmnetnat.conf file you On Sat, Jan 16, 2016 at 5:07 PM, Claire Matthews notifications@github.com
|
|
@dragon788 Yes, I have both of those sections - [incomingtcp] is no longer being deleted from the file. (Yay) |
|
I'm running into this problem as well. First up don't use Workstation 12.1.0 as So uninstall 12.1.0 and do a clean install of 12.0.1. For me port forwarding will then work fine until I do a I'm having tons of problems with VMware compared to Virtualbox and this bug and the required constant reinstalls are making debugging hard as hell. If this can't be fixed in a week or two I will probably have to get a refund because so far VMware is unusable with Vagrant. |
|
I think the problem is a dodgy string replace on the contents of Which Now if I start filling in the space with random stuff like: And try another Surely these kind of outputs can only be the result of a fragile string replace? Why not parse the conf like an ini file instead? For reference here is the full default file from Workstation 12.0.1. Was it formatted differently in older versions of Workstation? |
|
I believe the cause of this bug is hyphens in the path to the Vagrantfile. First overwrite the Then create a Vagrantfile with forwarded ports in a directory like Now create a Vagrantfile with forwarded ports in a directory with a hypen like Even if your forwarded ports aren't already broken they will be soon as each vagrant up/halt/destroy will corrupt your Looking at the paths of other people in this thread:
|
|
Another thought that just struck me, how many folks here are using Git(Hub) for Windows and/or Git Bash on their systems, and did you allow it to add the executables to the system path? I believe there are versions of at least git and ssh, and if it is prepending itself to the path, if there is a ruby.exe or anything else that Vagrant is looking for, it could be finding the wrong one if it's not a hardcoded path. |
|
Hi. The latest release of the vmware plugin includes a fix that should resolve this issue: If the issue persists after updating, please let me know. Thanks! |
|
It seems fixed to me. I upgraded to VMWare 12.5, Vagrant 1.8.5, and vagrant-vmware 4.0.11 and haven't seen the hyphen related problem since. |
|
Great, thanks for the confirmation! |
|
This issue is not fixed! Reproduced on two separate machines: vagrant 1.8.7 Its related to the vagrant guid for the box. Created a box that was assigned a guid of 1c6766aa-9f5e-4a84-9ab3-ab68adf3b2da After booting could not access the mapped ports on localhost. But using the ip assigned to the box was able to access services on the guest. Looking at C:\ProgramData\VMware\vmnetnat.conf the entire [incomingtcp] was missing from the file. halted the vagrant box. Opened the VMware Virtual Network Editor and Reset Defaults, to restore the [incomingtcp] back to C:\ProgramData\VMware\vmnetnat.conf After that we performed the following: Renamed the directory .vagrant\machines\default\vmware_workstation\1c6766aa-9f5e-4a84-9ab3-ab68adf3b2da to .vagrant\machines\default\vmware_workstation\cc6766aa-9f5e-4a84-9ab3-ab68adf3b2da (note the only char changed is the first char from a 1 to a c). We then updated the paths in .vagrant\machines\default\vmware_workstation\action_provision and .vagrant\machines\default\vmware_workstation\id to contain the new directory name. And then re-upped the vagrant box. Box came up and port forwarding was functioning and the C:\ProgramData\VMware\vmnetnat.conf file contained the expected [incomingtcp] section and data. My coworker and I expect that the vagrant-vmware-workstation plugin is attempting to edit the C:\ProgramData\VMware\vmnetnat.conf file and failing. We have also seen it write to this file with extra line feeds on the comment lines that wrap the port forwarding sections. Our best guess, since we cannot review the code is that the code to edit the vmnetnat.conf is somehow getting screwed up by the backslash and its being interpreted as a control/escape character. Once the vmnetnat.conf file is messed up its pretty much messed up for good and the only way to get back to a working state is to reset theVMware Virtual Network Editor defaults. |
|
For what it's worth I still haven't seen this bug since upgrading but then again I've only been using the same 1-3 boxes recently. My original suspicion for the bug was that it was a text replace bug like a badly escaped regex as hyphens have special meanings in regex. "\1" also has special meaning. |
|
That's our suspicion as well. Its using a regex to parse the # VAGRANT-BEGIN: and # VAGRANT-ENDS and replace the block between. Kinda feels like the old "you can't parse HTML with a regex" problem. But without seeing the code its just a guess. Whatever it is, its not fixed with just a vagrant reload as stated here: https://www.vagrantup.com/docs/vmware/known-issues.html And as stated once the vmnetnat.conf file is messed up its unlikely to be fixed, except for resetting the virtual networking default because the [incomingtcp] header is completely removed. |
|
Same problem with C:\ProgramData\VMware\vmnetnat.conf getting corrupted by vagrant 2.0.0 using VMware Workstation Pro 12 on Windows 10 x64. Tried fix from @ilude but failed. Any idea? Thanks |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
I am able to hit the port when I target the machine directly, but attempting to use localhost fails with an ERR_CONNECTION_REFUSED message. Firewall is off completely, and these commands are being run with administrator privileges.
Versioning Info:
Vagrant: 1.7.2
VMware Workstation: 11.1.0 build-2496824
Vagrantfile:
running:
As you can see from the following netstat output, the designated ports are not bound at all.
For comparison, here is the vm's netstat output. As you can see, there _are_ entries for the desired ports, although they seem rather circuitous.
The text was updated successfully, but these errors were encountered: