search

clong / DetectionLab

Automate the creation of a lab environment complete with security tooling and logging best practices
MIT License
4.6k stars 980 forks source link

Networks with custom subnet/mask values are not supported #602

Closed coffeegist closed 2 years ago

coffeegist commented 3 years ago

Description of the issue:

When bringing the machines up, while "Verying vmnet devices are healthy", the following error is generated:

==> logger: Successfully added box 'bento/ubuntu-18.04' (v202012.21.0) for 'vmware_desktop'!
==> logger: Cloning VMware VM: 'bento/ubuntu-18.04'. This can take some time...
==> logger: Checking if box 'bento/ubuntu-18.04' version '202012.21.0' is up to date...
==> logger: Verifying vmnet devices are healthy...
Vagrant failed to create a new VMware networking device. The following
error message was generated while attempting to create a new device:

  Networks with custom subnet/mask values are not supported on this platform

Please resolve any problems reported in the error message above and
try again.

To clarify, VMWare Fusion version is 12.1.0. I believe it's related to this issue: https://github.com/hashicorp/vagrant/issues/12052

A work around can be found here: https://www.vagrantup.com/docs/providers/vmware/known-issues#big-sur-related-issues

Modifying all cfg.vm.network lines in the Vagrantfile allows things to stand up. Example below:

    #cfg.vm.network :private_network, ip: "192.168.38.105", gateway: "192.168.38.1", dns: "8.8.8.8"
    cfg.vm.network :private_network

However, the obvious issues here are that static IPs don't seem possible at a first glance

clong commented 3 years ago

Hi @coffeegist - I think you may be able to use fix-second-network.ps1 to assign an address to the interface you create, but yeah, it looks like it's not possible to do via the Vagrantfile in Big Sur.

However, also realize a lot of the IPs in the lab are hardcoded to those values to take the guesswork out of DNS and DHCP reservations from my end. Changing IP addresses will more than likely break stuff - it's a tradeoff I had to make between flexibility and stability.

clong commented 3 years ago

A bit more history on this here: https://github.com/clong/DetectionLab/issues/269

cybagard commented 3 years ago

My work around:

  1. Get VNET_1_HOSTONLY_SUBNET from /Library/Preferences/VMware Fusion/networking
  2. Patch logger_bootstrap.sh to assign static IP address to eth1
  3. Find & Replace all old subnets (192.168.38.*) with VNET_1_HOSTONLY_SUBNET within the Vagrant directory
  4. Replace cfg.vm.network :private_network, ip: * with cfg.vm.network :private_network only in Vagrantfile
  5. Use scripts/fix-second-network.ps1 to assign static IP within VNET_1_HOSTONLY_SUBNET

Change list of files:

modified: Vagrantfile modified: logger_bootstrap.sh modified: resources/guacamole/user-mapping.xml modified: scripts/configure-ou.ps1 modified: scripts/install-microsoft-ata.ps1 modified: scripts/install-osquery.ps1 modified: scripts/install-splunkuf.ps1 modified: scripts/install-velociraptor.ps1 modified: scripts/join-domain.ps1 modified: scripts/provision.ps1

clong commented 2 years ago

Added as a wishlist item: https://www.detectionlab.network/customization/feature_requests/

clong commented 2 years ago

Hi all,

I failed to understand that this issue crops up even on brand new installs of VMware fusion. I thought this was only happening for people who were trying to run DetectionLab on custom (e.g. not 192.168.56.x/24) subnets. However, the good news is that I have a fix! This happens is if there is no pre-existing VMNET adapter mapped to the 192.168.56.x network -- the fix is simply to create one. On MacOS:

In this example, I'll be creating a vmnet2 interface, but if you already have one, change "2" to a different number (e.g. 7).

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_7_DHCP no
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_2_HOSTONLY_SUBNET 192.168.56.0
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_2_HOSTONLY_NETMASK 255.255.255.0
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_2_VIRTUAL_ADAPTER yes
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

I just tested this and it seems to be working great. Sorry for the misunderstanding!

denisbereng commented 10 months ago

Hi all,

I failed to understand that this issue crops up even on brand new installs of VMware fusion. I thought this was only happening for people who were trying to run DetectionLab on custom (e.g. not 192.168.56.x/24) subnets. However, the good news is that I have a fix! This happens is if there is no pre-existing VMNET adapter mapped to the 192.168.56.x network -- the fix is simply to create one. On MacOS:

In this example, I'll be creating a vmnet2 interface, but if you already have one, change "2" to a different number (e.g. 7).

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_7_DHCP no
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_2_HOSTONLY_SUBNET 192.168.56.0
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_2_HOSTONLY_NETMASK 255.255.255.0
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli vnetcfgadd VNET_2_VIRTUAL_ADAPTER yes
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

I just tested this and it seems to be working great. Sorry for the misunderstanding!

I guess first line VNET_7 is a typo, otherwise works great