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'.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vagrant-up/a86c796c-9fe4-4421-8381-6961233abab9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
