Scan Design Behaviors
The Ignore firewall-generated TCP RST packets and Ignore firewall-generated TCP SYN-ACK packets settings were introduced because some firewalls respond to probes in ways that make non-existent hosts appear alive. For example, a firewall might send RST packets on behalf of all IPs behind it or issue SYN+ACK packets on certain ports for hosts that do not actually exist. This behavior creates ghost assets, IPs that appear alive only because the firewall is replying. The presence of a firewall alone does not guarantee this behavior, but when it occurs, it typically looks like this:
-
RSTs: In certain stealth or aggressive filtering modes, firewalls reply to probes with RST packets even when no host exists. Normally, a non-existent host would not re-spond at all, but this behavior makes every IP behind the firewall appear alive. This is often done to prevent IP scanners from identifying active hosts.
-
SYN+ACKs: Some firewalls generate SYN+ACK packets as part of DoS protection or proxying. If these replies are sent for non-existent IPs, the scanner interprets them as live hosts.
To address this, the ignore options were added. When enabled, the scanner first checks whether replies received from a firewall or real hosts. Because firewalls do not mark their packets, the scanner infers this by analyzing header-level patterns such as TTL and IPID values. If many IPs share identical TTLs and clustered IPIDs, it suggests a single intermediary device is generating responses rather than multiple independent systems.
However, leaving these options enabled when no such firewall behavior exists can cause legitimate hosts to be incorrectly flagged as “behind a firewall,” simply because their TTL and IPID values align. For this reason, enable these options only when this behavior is confirmed in your environment.
This logic applies mainly to network-block scans. Scanning a range provides multiple samples, making it easier to detect patterns (for example, more than 10 hosts with the same TTL and similar IPID) that indicate firewall proxying. When a block is flagged as proxied, the scanner skips full VM scans. You can disable the pre-scan step, but doing so increases scan times because every IP is treated individually. While this removes the optimization of bulk host discovery, the results for single IPs and large blocks remain similar.
When you scan a single netblock or any number of netblocks, the scanning process consistently follows the same behavior across all network segments. The newly added ignore options are attempted by the system:
- Ignore firewall-generated TCP RST packets
- Ignore firewall-generated TCP SYN-ACK packets
The Ignore firewall-generated TCP RST packets option attempts to identify and suppress TCP RESET packets generated by firewalls during host discovery, reducing false positives in scan and map results. While detection is not always accurate, it improves reliability when scanning smaller ranges, for larger ranges, all RESET packets are ignored to optimize performance.
The Ignore firewall-generated TCP SYN-ACK packets option suppress TCP SYN-ACK packets that appear to be generated by firewalls or other filtering devices rather than actual hosts. These devices may respond with SYN-ACK packets using the target host’s IP address, causing false positives in host discovery. The system uses heuristics to identify such packets and exclude them from scan and map results to improve accuracy.
When should they be enabled?
The Ignore firewall-generated TCP RST packets and Ignore firewall-generated TCP SYN-ACK packets should be enabled when you receive packets that are generated from the firewall specifically reset (RST) and synchronization and acknowledgement (SYN-ACK) packets. The scanner ignores such packets during the scanning process. These are not mandatory fields. Depending on the network environment, you need to activate the options.
No Vulnerabilities Match Your Filters for These Hosts
This message appears when the scan engine categorizes certain hosts as not vulnerable during early scan phases, typically in large netblock scans. It may result from firewall behavior, lack of open ports, or proxy-like traffic patterns that prevent full vulnerability assessment. To improve scan coverage, consider disabling the Ignore firewall-generated TCP RST and SYN-ACK options and placing the scanner inside the target network segment.
The following are the two scenarios:
Options Profile - Scenario 1
Host Discovery: TCP Standard Scan, UDP Standard Scan, ICMP settings are Off. But the following settings are On:
- Ignore firewall-generated TCP RST packets: On
- Ignore firewall-generated TCP SYN-ACK packets: On
By analyzing packet captures, you can see that the IP ID and TTL values are consistent across all packets. This strongly indicates that the firewall is responding to the target, a conclusion that can only be reached through packet capture analysis.
Since you have activated the options to Ignore firewall-generated TCP RST packets and Ignore firewall-generated TCP SYN-ACK packets, these responses are being ignored in the processing because they originate from the firewall.

When IPs are scanned separately rather than as part of a netblock, you will get information about the target asset via the QID. This is because the scanner uses optimization logic during netblock scans to reduce scan duration and rapidly checks whether any TCP or UDP ports are open during the host discovery process. If no open ports are found, it skips the scanning of that asset.
Option Profile - Scenario 2
Host Discovery: TCP Standard Scan, UDP Standard Scan, ICMP settings are Off, But the following settings are Off:
- Ignore firewall-generated TCP RST packets: Off
- Ignore firewall-generated TCP SYN-ACK packets: Off
As mentioned earlier, assets will fall under this category during netblock scans when no TCP or UDP ports are detected. This occurs because the scanner uses optimization logic to reduce scanning duration for the netblock.
The Option Profile includes Ignore firewall-generated TCP RST packets and Ignore firewall-generated TCP SYN-ACK packets settings. If these options are selected by default in your configuration, then you should adjust them based on your specific network environment requirements.