IP Access Rule API error CIDR range | firewallaccessrules.api.validation_error:invalid ip provided

I try to create a Cloudflare IP Access Rule for IP address CIDR range (e.g., 66.249.79.64/27).

When I run the following Cloudflare API curl, it shows the “invalid ip provided” error. How do I whitelist the IP address range (CIDR range) using Cloudflare API4?

This is the sample curl that I run.

curl -X POST “https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules
-H “X-Auth-Email: myemail”
-H “X-Auth-Key: my globle API key”
-H “Content-Type: application/json”
–data ‘{“mode”:“whitelist”,“configuration”:{“target”:“ip”,“value”:“66.249.79.64/27”},“notes”:“Google Bot IP”}’

API curl error message.

{
“result”: null,
“success”: false,
“errors”: [
{
“message”: “firewallaccessrules.api.validation_error:invalid ip provided: 66.249.79.64/27”
}
],
“messages”:

This would be ip_range instead of ip.

https://api.cloudflare.com/#ip-access-rules-for-an-account-create-an-ip-access-rule

2 Likes

When I use ip_range instead of ip it works only for ipv6 CIDR. But when I use ipv4 CIDR, it shows the following error.

firewallaccessrules.api.validation_error:invalid subnet in ip_range provided: 66.249.79.96/27

Only an IPv4 range (CIDR) value of /16 or /24 is allowed for IP Access Rules. (Shamelessly stolen from the dash).
Try updating to a /24 and it should take.

Also, I recommend looking at ‘Firewall rules’ and using the bypass action instead. Will allow you to stick to the /27 and much more granularity.

Using the opportunity :smile: is there a particular reason why that limit is still in place? Now that firewall rules allow it anyhow. Only thing I could imagine is that the CIDR calculation of IP access rules only works with two and three folds of eight bit, and otherwise gives you a 386 SX flashback performance-wise.

Unsure. TBH IP Access Rules are legacy now; with the advent and continued improvement of IP lists in combination with firewall rules i dont see any reason to update IP Access Rules…

If the IP Access Rules are legacy, what is the best way to whitelist the Google and other search engine bot IP addresses? and block malicious IP addresses?

1 Like

But, regarding the order & priority, they do help a lot as they execute before the Firewall Rules, Bot Fight Mode, etc. which mostly causes some false positives lately with Google and similar “good” bots based on the topics here. Firewall Rules don’t help here, if so.

My best guess is a lot of users still use them because of that (having Bot Fight Mode and other security options enabled).

Exactly :point_up:

I wonder if you could split that one into multiple /24s for IP Access Rules?
:thinking: Despite, it might catch a few more outside the range too …

Aha, it’s regarding Google Bot … ugh-oh, you’ve used this, right?:

Furthermore, I don’t have Google ASN neither IP’s allowed nor blocked, neither using cf.client.bot field at my Firewall Rules.
I wonder how does and what kind of type of requests does Cloudflare catch from the Google for you at the Firewall Events? :thinking:
Is it the issue with the indexing or?

True, IP access rules have been called legacy for a quite a while, but there’s still no replacement for their functionality. Want to whitelist an address, only IP access rules allow for that.

2 Likes

IP Access Rules also allow for 50,000 IPs whereas IP lists allow for only 1 - 10 lists and 10,000 IPs overall - even on Enterprise (w/o negotiating a higher limit)

1 Like

You can only split into higher levels. The next valid one from /27 is /32 :slight_smile:

1 Like

I’d say 50k entries, rather than IPs? :thinking:
Just my tought because we can enter IP ranges and ASNs and other things (countries, etc. depending on a plan type) which can contain much more than that (if so) - could be I am wrong.
But yes, if we talk about IPs, then true :+1:

1 Like

Do IP lists allow whitelisting? They only work in the context of firewall rules, right?

1 Like

That’s true.

Yeah.

The issue with IP lists is that it isn’t a true replacement for IP Access Rules.

IP Access Rules can:

  • Apply account-wide (without making a FW rule to reference your list in every zone)
  • Are the only way to bypass Bot protection since it runs before Bots in the traffic flow
  • Can have way more entries

:frowning:

1 Like

That’s the bit I was referring to.

IP access rules are the only way to whitelist an address. So not real legacy :slight_smile:

2 Likes

I use Fail2ban. I configured it to block malicious attacks like SQL injection, 403, 404, URL scanners, and shellshock vulnerability. Once fail2ban blocks the IP address, it passes to Cloudflare IP access rules.

Sometimes Fail2ban blocks Google and Bing bot IPs (false positive). Periodically Google and Bing update the IP address. The easiest way to whitelist these search engine bots is via the Cloudflare IP access rule (using a simple script to pass search engine bot IP via Cloudflare API). It is hard to automatically whitelist these IP addresses from fail2ban.