Cloudflare isn't protecting the site, causing security to block IPs and then 521 error, how to fix?

I have previously asked how to fix the error 521 ('https://community.cloudflare.com/t/cloudflare-on-wordpress-site-is-getting-521-web-server-down-error-message/426117/5`). I followed the Cloudflare and the community recommendations, and nothing worked.
Basically, shortly after turning on Cloudflare on the site, I would start noticing IP blocks from the ufw and fail2ban and WordPress Jetpack, but it’s not because of how the firewalls are configured, because they are doing their job, the problem seems to be that Cloudflare is letting through the bad behavior.

For example, after 2 hours, WordPress Jetpack locked me out of the site because it kept saying that my IP address was 162.158.62.132, which is not, and it was flagged for potential security violation.
I have the WP-fail2ban plugin, and the dashboard widget shows login attempts from 162.158.x.x IP range (these IPs are from Cloudflare), but it looks like an everyday bot or attacker trying to guess the username and password for the website.
So, my theory now is that the security is working fine, but Cloudflare and letting the attacks through so, for example, if before, I was getting “attacks” from 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4, and 5.5.5.5, now Cloudflare proxy these addresses with the 162.158.x.x and now are getting blocked by Jetpack and server firewalls.
The IPs are not real, I just picked those to write what I wanted to say because the logs have so many IPs and nothing with a pattern that would let me understand what actual IPs are causing this. Also, even if I knew tomorrow, another set of IPs would try to do the same again.
Why is Cloudflare doing this?
Where are the IP logs in Cloudflare?
How to fix this problem?

Top of the list of problems is that you still haven’t followed @epic.network’s advice to restore visitor IP addresses. That’s why you’re seeing 162.158.62.132 in your logs.

https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs

Which bad behavior is Cloudflare letting through?

3 Likes

The bad behavior I’m referring to are all the constant fake login attempts and the attempts to the xmlrpc.php that shouldn’t happen, which are causing the firewall to block the Cloudflare IPs. I have logs of countless user guessing attempts, which Jetpack, ufw, and frail2ban will always try to block.

No response for failing to “Restore Visitor IP Addresses”? That’s really important here.

While your examples are certainly bad behavior, Cloudflare can’t tell the difference between a site that gets lots of legitimate logins vs one that doesn’t. Same goes for xmlrpc calls.

The easiest fix for these is to create firewall rules. One for xmlrpc. Something like: If path contains xmlrpc.php and IP Address is not in (Jetpack’s list), then Block. And a similar one for login.php for your own IP addresses. Or use Access to protect Login if it’s not feasible to use an IP allow list.

1 Like

Thanks for the reply, my question is can configure “Restore Visitor IP Addresses” while Cloudflare is paused on the site while keeping the website running without interruptions? In other words, can I configure this feature and being able to turn Cloudflare on or off without affecting the website?

Also, I have firewall rules in place to block xmlrpc and only allow Jetpack because it requires it. However, to test what was going on, I removed the blocked, now I put the block again. Also, for the login page is also protected with Jetpack security and fail2ban.

I can understand you saying that “Restore Visitor IP Addresses” is important, but if it’s so, why isn’t this part of the setup in the first place? I researched only many times before trying to set up Cloudflare in the site, and no tutorial in the internet has this feature as part of the steps. All the say is to change the domain name, install the Wordpress plugin, and you are good to go.

Yes. Restore IP only acts on requests coming from Cloudflare.

In case I need to undo the changes after setting up mod_remoteip, it’s just about working backward ([Preformatted text](https://support.cloudflare.com/hc/en-us/articles/200170786#C5XWe97z77b3XZV)), correct?

I mean:

  1. disabling the remoteip configuration.
  2. removing the remoteip.conf file.
  3. modifying the apache2.conf to the original state.
  4. removing the RemoteIPHeader CF-Connecting-IP from the 000-default.conf
  5. disabling the remoteip module.
  6. testing the configuration
  7. restarting the apache server.

Or is there any specific way to disable this feature?

Also, the Cloudflare instructions to set up this solution isn’t very clear. Since Cloudflare no longer maintains the mod_cloudflare, I only have to set up the mod_remoteip, right?
In addition, what are the “Web Server Instructions” for? If I already enabled and configured mod_remoteip, I don’t have to follow the “Web Server Instructions” or the " Restoring original visitor IP with HAProxy," right?

I just need some clarification following the Cloudflare instructions to set up “Restoring original visitor IPs” on a web server with apache.

I’ve followed these instructions from the Cloudflare site, but it’s clear where the steps start and finish. (Removed the link because the forum flagged it.)

Since Cloudflare no longer maintains the “mod_cloudflare,” I only have to set up the “mod_remoteip,” correct? In addition, what’s the “Web Server Instructions” for? If I already enabled and configured mod_remoteip, I don’t have to follow the “Web Server Instructions” or the " Restoring original visitor IP with HAProxy," correct?

Thank you for merging my different questions, can I get an answer?

Correct.

The now deprecated mod_cloudflare.

Not unless you are running HAProxy in front of two or more Apache servers.

Thank you so much for taking the time.

1 Like

@epic.network one last question, in case I need to undo the changes after setting up mod_remoteip, it’s just about working backward and nothing special, right?

Exmaple:

  1. disabling the remoteip configuration.
  2. removing the remoteip.conf file.
  3. modifying the apache2.conf to the original state.
  4. removing the RemoteIPHeader CF-Connecting-IP from the 000-default.conf
  5. disabling the remoteip module.
  6. testing the configuration
  7. restarting the apache server.

Thanks,

You are overthinking it. You don’t need to do any of that. If the connection doesn’t come from the Cloudflare IPs you defined, mod_ip isn’t gong to do anything (unless you defined other critera for it to act on).

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.