Greenbone Community Containers 22.4 Network Dies

I just installed the Greenbone Community Containers 22.4 on a Debian Bookwork VM so I can scan our network. However, when I run the docker compose up command, it takes down the network on the VM so that it cannot access anything and I cannot access it from anything other than using VMRC. Has anyone else run into this?

Can you please describe the symptoms related to this observation? For example if your VM is not configured properly to begin with it will not have access to other hosts on the network.

1 Like

Note that running Docker within a VM could also cause various issues in general.

Everything on the VM works great until I bring up the Docker stack. At that point I can access the GSA interface locally, but not unless I am on the remote console for the VM. If I bring the stack down, the network comes back up. If installing the stack on a VM is not recommended, it might be a good idea to list that in the requirements.

Please consult the Docker documentation about such topics, this is not relevant to the Greenbone software stack and also depends on the used Docker technology itself. For example for Docker Desktop:

Documenting every corner case of software not provided by Greenbone (like Docker) is just not feasible.

2 Likes

I was running Docker on a Debian Linux VM. I do not like the idea of running Docker on a Windows machine. Even if it is not a VM. I have multiple other docker containers & stacks running on VMs without issues, its only this one that takes down the network of the VM.

I would verify that you are running the official Greenbone Docker containers.

Those are the directions I followed to install. I have it running compiled from source now. Took longer, but it is working as of right now.

Ah, it wasn’t an advise to run Docker on Windows but just as a reference that at least Docker Desktop (which seems to run either Mac, Linux, or Windows) has infos like e.g.:

In general, we recommend running Docker Desktop natively on either Mac, Linux, or Windows. However, Docker Desktop for Windows can run inside a virtual desktop provided the virtual desktop is properly configured.

or

Docker doesn’t support running Docker Desktop for Mac inside a VM.

Currently i can’t find anything special in the docker compose file specific to any networking besides networks: default:

But there could be still some conflicts with the network used by the VM and the default used by Docker causing the seen behavior.

That’s why it was mentioned that the problem could originate from the usage of Docker within a VM which could cause unexpected behavior not related to the Greenbone Docker containers itself.

2 Likes

It is important that Docker uses the term “virtual desktop” here because that is different than a virtual machine. Virtual desktop is described as:

preconfigured image of operating systems and applications in which the desktop environment is separated from the physical device used to access it.

“serparated from the physical device used to access it” means that the OS is virtualized on a separate hardware and accessed via remote desktop, rather than a VM such as VirtualBox or HyperV running on the same physical device as the host hypervisor.

From the sounds of this disclosure from Docker, and that the OP is running Windows → Linux VM → Greenbone Docker containers, my suggestions would be to either:

  • Run the Greenbone source code inside the Linux VM (which the OP has done)
  • Run the Greenbone Docker containers on Windws natively using Windows Docker Desktop (which the OP says they don’t want to do)
  • Use Greenbone Cloud Service (GCS) which takes away all the pain of managing any of the infratructure itself. :smiley:
1 Like

The Linux VM was running in vSphere. So technically Linux. And I don’t know how you think running the Greenbone Docker containers in Windows is the native way to do it as Docker was released for Linux way before Windows. And from Greenbone Community Containers 22.4 - Greenbone Community Documentation
Currently the docs support the following distributions

  • Debian stable (bookworm)
  • Ubuntu 22.04 LTS
  • Fedora 35 and 36
  • CentOS 9 Stream

Hi smccloud, I didn’t mean that Windows was the native release target for Docker. I mean running Docker on Windows bare-metal as opposed to within a Type-2 hypervisor on Windows was more likely to work. Other users on this forum have described success running the containers in Windows.

I found it hard to follow your description of the situation to identify what information you provided was relevant. Since you said: “I do not like the idea of running Docker on a Windows machine.” which to me implies that you were considering running Docker bare-metal on a Windows machine.

But then you finally come to provide the information that you are using VSphere which is infact a Type-1 hypervisor that will not run within Windows. Maybe you can provide a more accurate and complete details for you situation right at the start next time. :smiley:

Ultimately, I was not implying that Windows ws the first release target for Docker.