The following sections cover common error scenarios related to the network check and the gateway.
Initial situation:
The gateway is shown as connected, and the scan can be initiated.
Issue:
The network check stops after starting and the gateway is then shown as offline. Only after a reboot is the gateway shown as connected again.
Possible cause #1:
This error suggests that the scanner and the gateway have been assigned the same IP address. These two IP addresses must absolutely be different.
The IP address of the scanner is specified in Step 2 on the configuration page in the platform. The IP address of the gateway, on the other hand, is configured directly on the gateway.
Possible Cause #2:
Missing Firewall Permissions. The gateway must be able to reach external addresses. For the network check to work correctly, the IP address of the gateway must be able to access the following URLs:
443/tcp outgoing to 45.135.106.140
443/tcp outgoing to https://gateway.lywand.com (217.72.202.36)
443/tcp outgoing to https://gpublic.azurecr.io (Update-Service)
Initial situation:
The scan was started and completed. In the infrastructure table of internal network targets, a timestamp is visible in the “Last checked” column.
Problem:
The scan didn’t yield any results. The scanned network devices are listed in the check insights, but no vulnerabilities are displayed.
Possible cause #1:
This issue indicates that the scanner couldn’t reach the targets within the scope. Therefore, the necessary firewall permissions should be checked:
The scanner's IP address must be able to fully reach the devices to be checked in the internal network. It must be possible to access all ports of these devices.
Possible Cause #2:
The scanner's IP address is being used by another system on the same network. During configuration, the scanner must be assigned an IP address that is still free in the network.
Situation & Issue:
Scans are generally completed and vulnerabilities are found. However, the number of vulnerabilities found fluctuates between the network checks performed (even though no vulnerabilities were resolved).
Possible Cause #1:
The IP address of the scanner is being used by another system in the same network. When configuring, it is essential to assign the scanner an IP address that is still free in the network.
Possible Cause #2:
The scanner is blocked by a web application firewall (WAF) or similar during the check. This may only be the case for a short time and does not necessarily affect all targets. This can lead to timing problems, which then affect the scan results.
Initial situation:
The scan was able to start and is "in progress".
Issue:
Depending on the scope of the check and the load on the scan cluster, it can take several hours to complete a scan. However, if the network check takes an extended period of time without finishing or stays stuck at the same percentage of progress, this could indicate an issue.
Possible cause #1:
If the network check takes an unusually long time, it may indicate a overload of the Greenbone Scan Cluster. In this case, the duration of the scan will increase. However, the scan will be completed as soon as the load issue is resolved. It's unlikely that the scan will be aborted in this case, though it cannot be completely ruled out.
Possible Cause #2:
This issue may also indicate that the targets within the scan scope are not reachable by the scanner. Consequently, the necessary firewall permissions should be checked:
The IP address of the scanner must be able to fully reach the devices to be tested within the internal network. It must be possible to reach all ports of these devices.
