As well there are virtual appliances available as well that run on many Hypervisors as well without a Firewall. If you set it up on your own, you just need to understand how TCP works. What connection tracking is, and how a firewall limit your scan capabilities with internal states, tables and counters. As well different Kernel Security might break your access to PCAP like shown above.
You make it on your own or you buy it 
That´s simple. We are happy to help …
I understand virtual appliances is an option for small / medium installations. In my case, it’s a very large installation with targets of up to 50,000 IPs. So I fear the virtual appliance model won’t fit.
Then you are lost Try to calculate 50,000*65535 TCP Ports = 3276750000 connection Just for a ALL TCP portscan Not one single NVT executed as well. I would advice to divide such a big network into many sensors and a mix of physical and virtual appliances. To scan and process such a big network you need at least one GSM 6500 as hardware accelerated scanner Good luck setting this up.
Well, the scanner is not scanning 65535 ports of 50,000 machines simultaneously. In general the setup is more to scan 20 hosts simultaneouslly with 4 NVTs per host. This makes a total of 80 NVTs run simultaneously, which is perfectly doable. And with gvm-9, this setup is working fine enough. A target of 50,000 IPs takes between 1 to 2 weeks to perform completely depending on the number of hosts alive. Perhaps we are missing some probes due to the fact the kernel is a default one, but nothing which would ruin the objective of those campaigns.
I have difficulties to understand though what are the main diffs from gvm-9 to gvm-11 from that perspective. What worked with gvm-9 somehow would definitely not work with gvm-11 due to that limitation ? Or would it be more or less the same ?
First the session table does have a timeout around 1-4h, forget GVM-9 it´s end of life and no longer supported.
GVM-11 will do. And this limitation is valid for any scanner or high load application. You simply can´t run such a big installation without exactly tuning your system to your needs.
I am aware of performant scan setups with multiple Class-A networks but this needs to be highly tuned.
NAT and session tracking needs to identify for a period of time the state of every connection, and this will not work in your scenario.
Well, I guess the only way to know for sure is to experiment…I’m moving out of gvm-9, of course. So I’ll try in my lab with both default kernel and home made kernel and see if the results are significantly different. Thanks for the explainations.
@Lukas, thank you a lot for all these explanations.
This is one of the threads I learned the most about the differences between Community and Enterprise Editions (apart from the feeds), and the corresponding limitations and challenges and thus reasons for certain choices.
It’s very clear and completely logical.
So I have recompiled an home made kernel with everything related to netfilter / apparmor / SELinux fully disabled (there was no reference to GRSecurity), rebooted with my new kernel. But sadly I have exactly the same error message in the logs:
lib misc:MESSAGE:2020-02-14 09h46.57 utc:26714: enp0s3: You don’t have permission to capture on that device (socket: Operation not permitted)
I’ll try to launch the scanner with root permissions, see if that makes any difference. Appart from that is there anything else I could try ?
Thanks !
Have you checked the obvious ?
First check with TCPDUMP, and then give permissions …
Yes, I’ve checked the obvious and I’m still getting that error.
So tcpdump works ?
Yes, tcpdump works as my gvmd user. I can capture traffic without issue. However gvmd is still complaining about this error.
Note; the following command was also necessary for tcpdump to work:
> sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
Did you set this to all binaries needed by the Scanner and the OSPd ?
A strace -f -e file might help.
No 
I’ve just added the setcap to the following files:
7 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/ospd-scanner/bin/ospd-openvas 8 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/wmic 9 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/winexe10 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/sbin/openvas
And so far I can’t see the error anymore (scan is still under way, but normally this error pop up quite frequently)
No I need to test it again with a normal kernel, see if that make any difference.
Thanks !
By the way, this is all GRSecurity So it was not disabled
Okay, thanks for the lesson. I thought it was something added to the kernel, like SELinux
Just finished my tests; I confirm the default kernel is perfectly fine. There is no need to remove netfilter / SELinux / etc… from the kernel. Disabling it is enough. That’s good news because it means there is no need to recompile our kernels to have gvm working on linux 
Back to the initial message:
In GVM < 11 it was required to run the openvassd daemon as root so that it is capable to do package forgery:
Please note that although you can start
openvassdas a user without elevated privileges, it is recommended that you startopenvassdasrootsince a number of Network Vulnerability Tests (NVTs) require root privileges to perform certain operations like packet forgery. If you runopenvassdas a user without permission to perform these operations, your scan results are likely to be incomplete.
openvas-scanner/INSTALL.md at v6.0.1 · greenbone/openvas-scanner · GitHub
IIUC since GVM-11 openvassd is just openvas which is called by ospd-openvas (See https://community.greenbone.net/t/goodbye-otp/1739, OpenVAS = Open Vulnerability Assessment Scanner - Greenbone Community Edition - Greenbone Community Forum) and to my understanding (which seems to be confirmed by the MR below) you can either run ospd-openvas as root (discouraged) or setup sudo by following the description in the MR (seem this hasn’t made it into the documentation).
I confirm; ospd-openvas needs to run as a regular user, while openvas binary needs to run with root privileges. For reference, the following needs to be done for openvas:
Edit sudoers file with visudo as root and add the following:
Allow the user running ospd-openvas, to launch openvas with root permissions
gvm ALL = NOPASSWD: /opt/gvm/sbin/openvas
Enable packet capture capability for GVM regular user: (where gvm is the user running GVM)
groupadd pcap
usermod -a -G pcap gvm
chgrp pcap /usr/sbin/tcpdump
chmod 750 /usr/sbin/tcpdump
sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/wmic
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/winexe
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/openvas-nasl
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/openvas-nasl-lint
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/ospd-scanner/bin/ospd-openvas
Not sure it’s necessary to do this for all binaries though, but at least this setup works.