F5 VPN and vagrant networking problems

[Tom Scanlan]

I've got developers working in office and remote.  When remote, they use an F5 vpn.  This vpn client steals all routes, but we should still be able to use port forwarding to hit the services we need to use.

vagrant up --provider=virtualbox

boots up, and we can vagrant ssh in, but no NAT interface comes up due to the broken networking.  We can cope with this by adding port forwarding rules.

vagrant up --provider=vmware_fusion

fails when it detects a route overlap.  Log at bottom.

If we can prevent it from failing here, I'd expect the box to boot and work with the same limitations as the virtualbox setup. 

Can we force the provider to be a bit less protective?  That would get us to a usable but not ideal state, while now it just fails.

What do other people do when VPN steals all routes?


Noisy details below:
 INFO subprocess: Starting process: ["/usr/sbin/netstat", "-nr", "-f", "inet"]
DEBUG subprocess: Command not in installer, not touching env vars.
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                172.28.45.160      USc            13        0   utun0
default            192.168.0.1        UGSc            0        0     en0
1.1.1.1            172.28.45.160      UHr             0        0   utun0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH             42  1190048     lo0
128.0/1            172.28.45.160      USc             1        0   utun0
172.28.45.160/32   1.1.1.1            USc             0        0   utun0
192.168.0.1/32     link#4             UCS             1        0     en0
192.168.0.1        c4:6e:1f:4f:ae:d2  UHLWIir         4      229     en0    812
208.66.219.49/32   192.168.0.1        UGSc            1        0     en0
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO networking_file: Reading adapters from networking file...
DEBUG networking_file: VNET: 1. KEY: 'DHCP' = 'yes'
DEBUG networking_file: VNET: 1. KEY: 'DHCP_CFG_HASH' = 'F5F486BA172D8E0B8336739C7BA13B687A82EA36'
DEBUG networking_file: VNET: 1. KEY: 'HOSTONLY_NETMASK' = '255.255.255.0'
DEBUG networking_file: VNET: 1. KEY: 'HOSTONLY_SUBNET' = '172.16.137.0'
DEBUG networking_file: VNET: 1. KEY: 'VIRTUAL_ADAPTER' = 'yes'
DEBUG networking_file: VNET: 8. KEY: 'DHCP' = 'yes'
DEBUG networking_file: VNET: 8. KEY: 'DHCP_CFG_HASH' = '309111DC08E1D64C9069599C60131713B9132A24'
DEBUG networking_file: VNET: 8. KEY: 'HOSTONLY_NETMASK' = '255.255.255.0'
DEBUG networking_file: VNET: 8. KEY: 'HOSTONLY_SUBNET' = '192.168.2.0'
DEBUG networking_file: VNET: 8. KEY: 'NAT' = 'yes'
DEBUG networking_file: VNET: 8. KEY: 'VIRTUAL_ADAPTER' = 'yes'
DEBUG networking_file: Pruning adapters that aren't actually active...
DEBUG vmware_driver: Testing route: 172.16.137.0 expects {:name=>"vmnet1", :number=>1, :dhcp=>"yes", :hostonly_netmask=>"255.255.255.0", :hostonly_subnet=>"172.16.137.0", :nat=>nil, :virtual_adapter=>"yes"}
The VMware network device 'vmnet1' can't be started because
its routes collide with another device: 'utun0'. Please
either fix the settings of the VMware network device or stop the
colliding device. Your machine can't be started while VMware
networking is broken.

Routing to the IP '172.16.137.0' should route through 'vmnet1', but
instead routes through 'utun0'.

[Alvaro Miranda Aguilera]

Hello,

My impression here will be if you stop that vagrant box, and turn it on from the VMWare GUI, vmware should give you the same message. If this is correct, then it looks more as a VMWare feature.

On the other hand, if vmware boot ok, and vagrant fail, then that will require more review and seems something more into the vagrant side of things.

Any chance you can do that test?

At any point you can contact support at hashicorp.com for Vagrant + Vmware integration question/issues too.

As for VPN, I personally have a VM where I run the vpn software plenty of issues with different clients, etc.

I can understand is not a valid suggestion for your case, just sharing my personal opinion on vpn.

Thanks

Alvaro.

[Tom Scanlan]

The VM does boot up from the manager.

1. Bring the VM up while not on the VPN, then vagrant halt.
2. Log back into VPN, try to vagrant up and get the usual error.
3. Go to the VMware Virtual Machine library and right click on the shutdown machine and choose Start Up, it comes up.

This leads me to think the problem is in the vagrant provider.

[Alvaro Miranda Aguilera]

Hi Tom

Can you send an email to sup...@hashicorp.com?

Thanks

Alvaro.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/784765f0-0d81-4a19-a969-3ed516099a25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Scanlan]

Thanks, Alvaro.  Sent mail yesterday :)