Avast! Antivirus seems to conflict with Vagrant port forwarding...

[Sean Quinn]

I've noticed that, with no other VMs or servers running on my host, that attempting to forward any guest port to host ports 80 and 8080 always fails due to a collision. After playing around with a few things, I tried turning off the Avast! Web Shield and lo-and-behold calling vagrant up worked without a problem.

Short of disabling Web Shield, is there any way to get port forwarding playing nicely with Vagrant?

I've just begun using Vagrant, and I'm experimenting with Puppet and Chef to see which I prefer more for several web projects. I'm attempting to leverage Vagrant and adopt more of a DevOps culture for these projects as part of a move from a Windows 7 XAMPP machine to something that will be closer (identical?) to what will be released on an EC2 instance.

Thanks!

[Rich Burroughs]

I've never used that AV software but I Googled it and their docs say it has a built in firewall. I'm guessing you'll need to allow the forwarding somehow in that app. How to do that is really a question of how their software works, it's not really a Vagrant issue.

Rich

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sean Quinn]

Cheers.

I agree that it isn't really an issue with Vagrant (which is why I came to Google Groups rather than pursuing this line of questions in say, a GitHub issue). I was hoping that someone might have experienced this issue before and found a workable solution. I'll have to dig around and see if I can't find a way of allowing port forwarding through their firewall / web shield.

Even if it isn't specifically an issue with Vagrant; are there any networking options which either obviate the need for port forwarding or make it so that the network the VM is on is effectively the same as the host? My knowledge of virtualization is limited at best, but I want to avoid complicating development setup. The whole point is to have a more-or-less out of the box solution for setting up a development environment with relative ease.

[Rich Burroughs]

The networking options available depend some on the provider you're using. If you're using Virtualbox, I believe a setting up a public network in Vagrant uses the bridged mode in Virtualbox. That would get the guest a real IP on the same network as the host. If you're using DHCP it will get handed an actual IP by the DHCP server.

http://docs.vagrantup.com/v2/networking/public_network.html

But there's still no guarantee that would just work for you. No one's going to be able to tell you what will work out of the box for you without knowing what it is exactly that the firewall on the host is doing. I really think that's where you should start, reading the documentation for that product so you know what it's doing. It may very well block the connections by default whether they're port forwarded or not.

Rich

--

[Francis Addai]

Hey Sean,

Did you also try changing the port number from 8080 to say, 8089? That's what I would do, if there is a collision in the port you are forwarding to, try changing it to another and see how it pans out.

[Sean Quinn]

Thanks for all replies and the help; there were a set number of ports that wouldn't work (typical web ports, 80, 8080, 8443, etc.). However using something arbitrary like port 1234 worked fine with the port forwarding. I never explicitly tried port 8089.

After everything, it looks like the issue was with avast; they were doing something internally that (as far as I could tell) couldn't be configured, at least short of disabling their Web Shield. After updating avast! Free Antivirus from version 2014.9.0.2008 to 2014.9.9.2011 the issue with port forwarding went away. I added an answer to a question I asked on superuser.com identifying this "resolution": http://superuser.com/a/691379/283469

So as it stands it looks like my problem is resolved. Though I hate being held hostage to other services that may-or-may not break in the future or be broken still.

One additional solution I'm looking at leveraging as a "just in case" is to allow systems to provide an override to some of the Vagrant configuration options from an external file that can be read, so that if the defaults don't work out of the box for a developer s/he can change it to something that does. For instance, if the port forwarding should cease working for whatever reason due to a change in firewall software or a more stringent anti-virus the developer can modify their port forwarding without having to change a common file that is managed in source control.