Allowing Cloudflare IP ranges in CSF firewall

If you host websites on a Linux server and run ConfigServer Security & Firewall (CSF) alongside the Login Failure Daemon (LFD), you know how dependable it is at blocking suspicious login attempts and port scans. But when you put your website behind Cloudflare as a reverse proxy, the networking model changes entirely.

Because all web traffic routes through Cloudflare edge nodes before reaching your server, your machine sees Cloudflare IPs as the origin for every incoming HTTP and HTTPS request. If regular visitors enter the wrong password a few times or trigger firewall alerts, LFD might block the Cloudflare IP itself. When that happens, thousands of legitimate users lose access to your site at once.

Below, we break down how the allow command (csf -a) works under the hood, the cleanest ways to register Cloudflare official subnets, and how to restore visitor real IPs in Nginx or Apache so your access logs remain fully accurate.

How the CSF -a command works under the hood#

The csf -a command allows network addresses through the firewall, but understanding what it changes behind the scenes is essential before opening up subnets.

The basic terminal syntax is:

csf -a [IP_OR_CIDR] [OPTIONAL_COMMENT]

Where:

-a (Allow): writes the IP address or CIDR subnet into /etc/csf/csf.allow.
IP_OR_CIDR: the target address (such as 192.0.2.10) or an entire network block (such as 192.0.2.0/24).
OPTIONAL_COMMENT: a text note enclosed in quotes to explain why that access was granted.

When executed, CSF immediately runs three operations:

Persistent storage: the address is appended to /etc/csf/csf.allow, so the rule remains active after server reboots or firewall reloads (csf -r).
LFD immunity: the Login Failure Daemon stops tracking that address. Failed authentication attempts from that IP will no longer trigger automatic bans.
Immediate packet filtering: CSF inserts rules into your active iptables or nftables chains, allowing packets from that source without waiting for the next scan cycle.

Common examples in daily terminal work:

# Allow a single static IP
csf -a 203.0.113.42

# Allow an IP with an audit comment
csf -a 203.0.113.42 "Remote Management VPN"

# Allow an entire CIDR subnet
csf -a 198.51.100.0/24 "Branch Office Network"

A practical caution: adding an address permanently to csf.allow turns off brute force protection in LFD for that source. If you only need temporary access for maintenance or troubleshooting, use the temporary allow parameter instead:

# Allow an IP for 3600 seconds (1 hour)
csf -tempallow 203.0.113.42 3600 "Temporary maintenance access"

To revoke a previously allowed permanent IP, use the -ar flag:

csf -ar 203.0.113.42

Allowing official Cloudflare IP ranges#

To avoid accidental blocks of legitimate traffic, your firewall must allow Cloudflare edge nodes to communicate with your origin server. Here are two practical ways to handle this.

Option 1: Direct terminal loop#

If your site is currently experiencing false-positive blocks and you need an immediate fix, this bash loop pulls the official IP lists from Cloudflare and registers each entry into CSF:

# Download and allow IPv4 blocks
wget https://www.cloudflare.com/ips-v4 -O - | while read line; do csf -a $line "Cloudflare IPv4"; done

# Download and allow IPv6 blocks
wget https://www.cloudflare.com/ips-v6 -O - | while read line; do csf -a $line "Cloudflare IPv6"; done

# Reload firewall rules
csf -r

This writes each subnet directly to /etc/csf/csf.allow and restores connectivity right away.

Option 2: Dynamic inclusion with the include directive#

CSF supports including external URL lists directly within its configuration files. This keeps your local configuration clean and ensures that official lists are read on every firewall reload.

Open the allow file:

nano /etc/csf/csf.allow

Add the following directives at the bottom of the file:

# Cloudflare IPv4
Include https://www.cloudflare.com/ips-v4

# Cloudflare IPv6
Include https://www.cloudflare.com/ips-v6

Save the file and reload the firewall:

csf -r

Whenever CSF restarts or reloads its rules, it reads the latest subnets directly from Cloudflare.

Restoring visitor real IPs on the web server#

Allowing Cloudflare subnets in CSF resolves connection drops, but stopping here leaves a major blind spot: your web server access logs will only record Cloudflare proxy IPs, hiding who actually made each request.

Without visitor IPs, you cannot investigate targeted scans, identify abusive bots, or protect login forms effectively.

To fix this, configure your web server to read the CF-Connecting-IP HTTP header sent by Cloudflare and replace the proxy address with the real client IP.

Configuration for Nginx#

Make sure the http_realip_module is enabled (it is included in most distribution builds by default) and place this configuration inside the http block or your site configuration in /etc/nginx/conf.d/:

# Trusted Cloudflare proxy subnets
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

# Cloudflare IPv6 subnets
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

# Read real visitor address from Cloudflare header
real_ip_header CF-Connecting-IP;

Validate the syntax and reload Nginx:

nginx -t && systemctl reload nginx

Configuration for Apache#

On Apache, enable the remoteip module:

# On Debian/Ubuntu distributions
a2enmod remoteip

Then create or edit the module configuration file (for example, /etc/apache2/conf-available/remoteip.conf or inside /etc/httpd/conf.d/remoteip.conf):

<IfModule remoteip_module>
    RemoteIPHeader CF-Connecting-IP
    RemoteIPTrustedProxy 173.245.48.0/20
    RemoteIPTrustedProxy 103.21.244.0/22
    RemoteIPTrustedProxy 103.22.200.0/22
    RemoteIPTrustedProxy 103.31.4.0/22
    RemoteIPTrustedProxy 141.101.64.0/18
    RemoteIPTrustedProxy 108.162.192.0/18
    RemoteIPTrustedProxy 190.93.240.0/20
    RemoteIPTrustedProxy 188.114.96.0/20
    RemoteIPTrustedProxy 197.234.240.0/22
    RemoteIPTrustedProxy 198.41.128.0/17
    RemoteIPTrustedProxy 162.158.0.0/15
    RemoteIPTrustedProxy 104.16.0.0/13
    RemoteIPTrustedProxy 104.24.0.0/14
    RemoteIPTrustedProxy 172.64.0.0/13
    RemoteIPTrustedProxy 131.0.72.0/22
    RemoteIPTrustedProxy 2400:cb00::/32
    RemoteIPTrustedProxy 2606:4700::/32
    RemoteIPTrustedProxy 2803:f800::/32
    RemoteIPTrustedProxy 2405:b500::/32
    RemoteIPTrustedProxy 2405:8100::/32
    RemoteIPTrustedProxy 2a06:98c0::/29
    RemoteIPTrustedProxy 2c0f:f248::/32
</IfModule>

Restart Apache to activate the module:

systemctl restart apache2 # or httpd

Testing the setup and monitoring logs#

Once the firewall and web server configurations are in place, monitor your system logs to verify the results:

Check web server access logs: run tail -f /var/log/nginx/access.log and make a request from your browser. The client IP column should show your own home or office IP address instead of a Cloudflare edge IP starting with 172.68. or 162.158..
Review LFD event logs: examine /var/log/lfd.log. If someone attempts to probe login pages or brute force passwords, LFD will log the true origin IP.
Verify CSF status: run csf -g [IP] to verify that Cloudflare edge IPs are recognized as allowed and not blocked by temporary bans.

Aligning these three parts (allowing subnets in CSF, granting LFD immunity, and restoring client IPs in the web server) keeps your applications online without risking broad service interruptions from false-positive firewall bans.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

This post is licensed under CC BY-NC.

Allowing Cloudflare IP ranges in CSF firewall without breaking security

How the CSF -a command works under the hood#

Allowing official Cloudflare IP ranges#

Option 1: Direct terminal loop#

Option 2: Dynamic inclusion with the include directive#

Restoring visitor real IPs on the web server#

Configuration for Nginx#

Configuration for Apache#

Testing the setup and monitoring logs#

Was this article helpful?

Comments

How the CSF -a command works under the hood#

Allowing official Cloudflare IP ranges#

Option 1: Direct terminal loop#

Option 2: Dynamic inclusion with the include directive#

Restoring visitor real IPs on the web server#

Configuration for Nginx#

Configuration for Apache#

Testing the setup and monitoring logs#

Was this article helpful?

See also

Comments