Investigate an IP block

cPFence v4+ blocks can come from reputation policy, login abuse, connection protection or a custom policy.

Compare the incident reason with current policy before changing access. The address is hidden. Select the image for full size; use browser Back to return.

1. Check the IP status on the affected server.
2. In IPDB summary, open the incident’s Details. Compare the time, reason and Current policy.
3. Review relevant service and system logs. As root, grep -F '192.0.2.10' /var/log/syslog searches the current system log; substitute the actual address.
4. If local logs are sparse, review reputation and the current blocklist. A firewall block can occur before an application records a request.
5. For a verified client, correct excessive connections or use a narrow whitelist. Check access after the change.

Many mail or FTP sessions can add up

Several users or devices behind one IP can reach the connection limit. Reduce parallel IMAP/FTP sessions before raising the server-wide threshold. Raising it weakens protection.

A whitelist is an access exception, not evidence that the source is safe. Use DDNS whitelisting for an administrator whose IP changes. If a listed IP is compromised, investigate the activity or request delisting from its source rather than hiding the warning.